http://tobyinkster.co.uk/message/ http://tobyinkster.co.uk/message/64491.81.2.120.180.1206622391.squirrel%40goddamn.co.uk Re: [foaf-dev] Re: privacy and open data 2008-03-27T12:53:11 2008-03-27T12:53:11 2008-03-27T12:53:11 [I sent this response a little while ago, but it seems to have disappeared into the aether, so I am sending it again. Apologies if your recieve it twice.] Karl Dubost wrote: > My "utopian" FOAF resource, let's say an URI > http://example.org/foaf.rdf > > Mr Smith asking it would get "name" and "email" Ms Boo (a friend of > mine) asking it would get "my address" > > only the relevant part of... [I sent this response a little while ago, but it seems to have disappeared into the aether, so I am sending it again. Apologies if your recieve it twice.] Karl Dubost wrote: > My "utopian" FOAF resource, let's say an URI > http://example.org/foaf.rdf > > Mr Smith asking it would get "name" and "email" Ms Boo (a friend of > mine) asking it would get "my address" > > only the relevant part of the file would be accessible depending on the > acls (system with pgp keys?) Given that HTTPS already includes TLS, it should be feasible to implement a system based on HTTPS. In the following examples, I'm going to use a hypothetical WOT 0.2 schema for RDF. WOT 0.1 defines wot:PubKey to specifically be a PGP/GPG key, but for WOT 0.2 we'll allow it to be any kind of public key, and define a wot:pubKeyType to explicitly declare the type of the key. In lieu of an explicit type being declared, user agents can determine the key type from HTTP headers, heuristics, etc. We also say that for TLS (X.509) keys, wot:hex_id is defined to contain the serial number. The resource <http://example.org/foaf.rdf> is your static public profile. It might contain your name and a few other details that you are happy to share with the world. It should contain enough information for people to be reasonably sure that it's describing *you* and not some other Karl Dubost. It also contains: <http://example.org/foaf.rdf> rdfs:seeAlso <https://example.org/foaf.cgi>; wot:hasKey #myKey. #myKey a wot:PubKey; wot:pubkeyAddress <http://example.org/x509.key>; wot:pubKeyType "X.509"; wot:hex_id "ABC123AB". The first triple there is a link to your "private profile". The rest describe your public key. These are not strictly necessary for this example, as you are acting as the provider of information, but should you wish to consume information, it would be required. Now a client wishing to request additional information about you will make an HTTPS request to your private profile. The request will be encrypted using *their* TLS key. As part of this request they also must include the URI for *their* public profile -- not quite sure what is the best way to do this. For now, let's extend the meaning of the rarely-used "From" HTTP header to allow a URI to be included. Now the HTTPS server will do its usual HTTPS things and verify that the client's TLS cert is valid, and the foaf.cgi script (or whatever: this technique is not limited to the Common Gateway Interface) takes over. The script looks at the From header in the HTTPS request. If this is blank, then it's clear that the client isn't respecting our little cobbled-together protocol. So the script simply returns a carbon copy of the public profile. If it's non-blank, then the script fires off a request to the URI given in the "From" header to retrieve the *client's* public protocol. In particular, this lists the wot:hex_id of the client's TLS key. The script checks the wot:hex_id against the serial number of the certificate used in the HTTPS request. (With Apache CGI, this can be found in the SSL_CLIENT_M_SERIAL environment variable. This may differ in other servers.) If they do not match, something foul is afoot, so the script issues some sort of dire error message. Perhaps even retaliates by sending wilfully incorrect RDF data back. If the wot:hex_id matches the serial number, then we can be reasonably sure (assuming that the client has kept their X.509 private key secure!) that the client really is the person identified by the resource in the "From" header. The script can now freely provide additional information about Karl Dubost to the client, according to the rules that you have defined. It can grant access to information based on the client's profile URI itself -- e.g. you may have declared that <http://example.com/mrs-boo.rdf> is to be allowed access to your address. Your script also (of course) has access to the client's public FOAF profile, so you could configure it such that if their profile reveals a foaf:interest in Cheese, it will reveal that you are president of the Brunei Cheese Lovers' Association. It packages all this information up in a neat little RDF/XML wrapper and sends it back to the client. So all the technology is in place. All that is needed is a few extensions to the WOT schema, proper documentation for this pattern, and a few client and server implementations. -- Toby A Inkster BSc (Hons) ARCS <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/62649.81.2.120.180.1206622777.squirrel%40goddamn.co.uk Re: [foaf-dev] Re: privacy and open data 2008-03-27T12:59:37 2008-03-27T12:59:37 2008-03-27T12:59:37 [I sent this response a little while ago, but it seems to have disappeared into the aether, so I am sending it again. Apologies if your recieve it twice.] Karl Dubost wrote: > My "utopian" FOAF resource, let's say an URI > http://example.org/foaf.rdf > > Mr Smith asking it would get "name" and "email" Ms Boo (a friend of mine) asking it would get "my address" > > only the relevant part of t... [I sent this response a little while ago, but it seems to have disappeared into the aether, so I am sending it again. Apologies if your recieve it twice.] Karl Dubost wrote: > My "utopian" FOAF resource, let's say an URI > http://example.org/foaf.rdf > > Mr Smith asking it would get "name" and "email" Ms Boo (a friend of mine) asking it would get "my address" > > only the relevant part of the file would be accessible depending on the acls (system with pgp keys?) Given that HTTPS already includes TLS, it should be feasible to implement a system based on HTTPS. In the following examples, I'm going to use a hypothetical WOT 0.2 schema for RDF. WOT 0.1 defines wot:PubKey to specifically be a PGP/GPG key, but for WOT 0.2 we'll allow it to be any kind of public key, and define a wot:pubKeyType to explicitly declare the type of the key. In lieu of an explicit type being declared, user agents can determine the key type from HTTP headers, heuristics, etc. We also say that for TLS (X.509) keys, wot:hex_id is defined to contain the serial number. The resource <http://example.org/foaf.rdf> is your static public profile. It might contain your name and a few other details that you are happy to share with the world. It should contain enough information for people to be reasonably sure that it's describing *you* and not some other Karl Dubost. It also contains: <http://example.org/foaf.rdf> rdfs:seeAlso <https://example.org/foaf.cgi>; wot:hasKey #myKey. #myKey a wot:PubKey; wot:pubkeyAddress <http://example.org/x509.key>; wot:pubKeyType "X.509"; wot:hex_id "ABC123AB". The first triple there is a link to your "private profile". The rest describe your public key. These are not strictly necessary for this example, as you are acting as the provider of information, but should you wish to consume information, it would be required. Now a client wishing to request additional information about you will make an HTTPS request to your private profile. The request will be encrypted using *their* TLS key. As part of this request they also must include the URI for *their* public profile -- not quite sure what is the best way to do this. For now, let's extend the meaning of the rarely-used "From" HTTP header to allow a URI to be included. Now the HTTPS server will do its usual HTTPS things and verify that the client's TLS cert is valid, and the foaf.cgi script (or whatever: this technique is not limited to the Common Gateway Interface) takes over. The script looks at the From header in the HTTPS request. If this is blank, then it's clear that the client isn't respecting our little cobbled-together protocol. So the script simply returns a carbon copy of the public profile. If it's non-blank, then the script fires off a request to the URI given in the "From" header to retrieve the *client's* public protocol. In particular, this lists the wot:hex_id of the client's TLS key. The script checks the wot:hex_id against the serial number of the certificate used in the HTTPS request. (With Apache CGI, this can be found in the SSL_CLIENT_M_SERIAL environment variable. This may differ in other servers.) If they do not match, something foul is afoot, so the script issues some sort of dire error message. Perhaps even retaliates by sending wilfully incorrect RDF data back. If the wot:hex_id matches the serial number, then we can be reasonably sure (assuming that the client has kept their X.509 private key secure!) that the client really is the person identified by the resource in the "From" header. The script can now freely provide additional information about Karl Dubost to the client, according to the rules that you have defined. It can grant access to information based on the client's profile URI itself -- e.g. you may have declared that <http://example.com/mrs-boo.rdf> is to be allowed access to your address. Your script also (of course) has access to the client's public FOAF profile, so you could configure it such that if their profile reveals a foaf:interest in Cheese, it will reveal that you are president of the Brunei Cheese Lovers' Association. It packages all this information up in a neat little RDF/XML wrapper and sends it back to the client. So all the technology is in place. All that is needed is a few extensions to the WOT schema, proper documentation for this pattern, and a few client and server implementations. -- Toby A Inkster BSc (Hons) ARCS <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/48933A2D-AEA9-471C-B087-8A021C512206%40g5n.co.uk Re: sketch of a simple authentication protocol 2008-04-03T08:55:38 2008-04-03T08:55:38 2008-04-03T08:55:38 On 2 Apr 2008, at 15:52, Story Henry wrote: > I thought it would be fun to represent your answer [1] with a > Sequence Diagram to make sure I have really understood what you are > saying. It is even simpler that the previous sketch. Yep, that's pretty much it. An additional detail which is missing in your diagramme is: what happens if Romeo's client doesn't send an Agent-Id header (I use... On 2 Apr 2008, at 15:52, Story Henry wrote: > I thought it would be fun to represent your answer [1] with a > Sequence Diagram to make sure I have really understood what you are > saying. It is even simpler that the previous sketch. Yep, that's pretty much it. An additional detail which is missing in your diagramme is: what happens if Romeo's client doesn't send an Agent-Id header (I used HTTP "From" header originally, but it doesn't really matter what the header is called) or Juliette decides she doesn't trust Romeo. I originally specified that a simple copy of the public profile should be returned, but instead I think perhaps a 302 redirect back to the public profile is more appropriate. Also, I'd like to make a bid to explicitly allow XHTML+RDFa to be used for the public profiles (and if implementations are going to need to support it for public profiles, we might as well also allow it for private profiles!). With that in place, a person can decide to use the same URI for: * their (human-readable) homepage; * their FOAF profile for use in this protocol; and * their OpenID identifier. If we insisted that their profile URI be RDF/XML, then that couldn't happen (except perhaps with some sort of content negotiation going on — I've not thought out the details). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/045415A7-DC74-4558-B0D9-353695EC9962%40tobyinkster.co.uk @title 2008-04-16T22:30:38 2008-04-16T22:30:38 2008-04-16T22:30:38 Suggestion: Before #7 in the processing sequence: If the [current element] contains a non-empty @title, then a new triple is generated: Subject: [current subject] Predicate: dcterms:title Object Literal contents of @title. What do people think? Or will this generate too many false positives? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Suggestion: Before #7 in the processing sequence: If the [current element] contains a non-empty @title, then a new triple is generated: Subject: [current subject] Predicate: dcterms:title Object Literal contents of @title. What do people think? Or will this generate too many false positives? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CC30A514-C0FE-4F62-B97E-CB4A6DDADA15%40tobyinkster.co.uk @title 2008-04-16T22:30:38 2008-04-16T22:30:38 2008-04-16T22:30:38 Suggestion: Before #7 in the processing sequence: If the [current element] contains a non-empty @title, then a new triple is generated: Subject: [current subject] Predicate: dcterms:title Object Literal contents of @title. What do people think? Or will this generate too many false positives? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Suggestion: Before #7 in the processing sequence: If the [current element] contains a non-empty @title, then a new triple is generated: Subject: [current subject] Predicate: dcterms:title Object Literal contents of @title. What do people think? Or will this generate too many false positives? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1C2B4260-0810-4D01-8A7C-E2B3E4C0EE5C%40g5n.co.uk @title 2008-04-17T07:17:36 2008-04-17T07:17:36 2008-04-17T07:17:36 Suggestion: Before #7 in the processing sequence: If the [current element] contains a non-empty @title, then a new triple is generated: Subject: [current subject] Predicate: dcterms:title Object Literal contents of @title. What do people think? Or will this generate too many false positives? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Suggestion: Before #7 in the processing sequence: If the [current element] contains a non-empty @title, then a new triple is generated: Subject: [current subject] Predicate: dcterms:title Object Literal contents of @title. What do people think? Or will this generate too many false positives? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/588FB325-8FF9-41F4-955F-2CB56A704275%40g5n.co.uk Re: @title 2008-04-18T14:05:51 2008-04-18T14:05:51 2008-04-18T14:05:51 On 17 Apr 2008, at 09:31, Dan Brickley wrote: > And imagemaps too I hope - > http://www.w3.org/QA/2008/01/rdfa_and_html_imagemap.html > > If anyone with an RDFa parser cares to experimentally extend it so we > can get imagemap path data out as triples, I'd be very happy... I'd be interested in implementing this. As an example, to get this information out: <rdf:RDF xmlns:rdf="http://www... On 17 Apr 2008, at 09:31, Dan Brickley wrote: > And imagemaps too I hope - > http://www.w3.org/QA/2008/01/rdfa_and_html_imagemap.html > > If anyone with an RDFa parser cares to experimentally extend it so we > can get imagemap path data out as triples, I'd be very happy... I'd be interested in implementing this. As an example, to get this information out: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:imreg="http://www.w3.org/2004/02/image-regions#"> <foaf:Person rdf:about="#me"> <foaf:name>Toby Inkster</foaf:name> </foaf:Person> <foaf:Image rdf:about="http://example.com/mypic"> <imreg:region> <imreg:Rectangle rdf:nodeID="#reg"> <imreg:boundingBox>42,17,304,231</imreg:boundingBox> <imreg:regionDepicts rdf:resource="#me" /> </imreg:Rectangle> </imreg:region> </foaf:Image> </rdf:RDF> ... from something like this: <div about="#me" class="figure"> <img src="mypic" alt="Photo of: " usemap="#themap" /> <span class="legend" property="foaf:name">Toby Inkster</span> </div> <map name="themap" id="themap"> <area shape="rect" coords="42,17,304,231" href="#me" rel="imreg:regionDepicts" /> </map> The only extra rules required would be: 1. Any <area> elements have an implicit @typeof attribute of imreg:Rectangle, imreg:Polygon or imreg:Circle depending on the contents of @shape. 2. For any <img> elements with a non-empty @usemap, an implicit imreg:region relationship exists between the image URI and each <area> element within the map. A slight problem though is that it increases parsing complexity significantly, owing to the fact that the <map> element may be anywhere in the page, so may be encountered either before or after the <img> element. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8EB748D6-3DB8-4063-B192-6BED8C9AEC59%40g5n.co.uk Garbage collecting "useless" triples 2008-04-23T19:17:39 2008-04-23T19:17:39 2008-04-23T19:17:39 Is there a publicly available draft of the new processing rules taking into account this resolution yet? <http://www.w3.org/2008/04/03-rdfa-minutes.html#item03> Even just a quick note on the required changes to the algorithm, posted to the mailing list would be a good start. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Is there a publicly available draft of the new processing rules taking into account this resolution yet? <http://www.w3.org/2008/04/03-rdfa-minutes.html#item03> Even just a quick note on the required changes to the algorithm, posted to the mailing list would be a good start. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/27B1B181-CA96-4A7F-89D2-8C0F98BBC0F7%40tobyinkster.co.uk Re: Telecon Agenda - Thursday 1 May 2008, 1500 UTC 2008-04-30T23:13:40 2008-04-30T23:13:40 2008-04-30T23:13:40 Ben Adida wrote: > 2) Implementation Report > http://www.w3.org/2006/07/SWD/RDFa/implementation-report/ > - which implementations should we pick? Any we've missed? > - status of implementations? Cognition <http://buzzword.org.uk/cognition/> has supported RDFa since alpha3 (latest release is alpha7). Support is more or less complete (lacks support for xml:base, but that should be included in alpha8). Written in Perl. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Ben Adida wrote: > 2) Implementation Report > http://www.w3.org/2006/07/SWD/RDFa/implementation-report/ > - which implementations should we pick? Any we've missed? > - status of implementations? Cognition <http://buzzword.org.uk/cognition/> has supported RDFa since alpha3 (latest release is alpha7). Support is more or less complete (lacks support for xml:base, but that should be included in alpha8). Written in Perl. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D2087B4F-F1A2-4F82-8FC4-06C4AA42B77A%40g5n.co.uk Re: Telecon Agenda - Thursday 1 May 2008, 1500 UTC 2008-05-01T06:47:29 2008-05-01T06:47:29 2008-05-01T06:47:29 Ben Adida wrote: > 2) Implementation Report > http://www.w3.org/2006/07/SWD/RDFa/implementation-report/ > - which implementations should we pick? Any we've missed? > - status of implementations? Cognition <http://buzzword.org.uk/cognition/> has supported RDFa since alpha3 (latest release is alpha7). Support is more or less complete (lacks support for xml:base, but that should be included in alpha8). Written in Perl. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Ben Adida wrote: > 2) Implementation Report > http://www.w3.org/2006/07/SWD/RDFa/implementation-report/ > - which implementations should we pick? Any we've missed? > - status of implementations? Cognition <http://buzzword.org.uk/cognition/> has supported RDFa since alpha3 (latest release is alpha7). Support is more or less complete (lacks support for xml:base, but that should be included in alpha8). Written in Perl. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A3B9E13C-CC25-4FEE-8AA2-D0C2F09D66F8%40g5n.co.uk Re: Telecon Agenda - Thursday 1 May 2008, 1500 UTC 2008-05-01T15:10:09 2008-05-01T15:10:09 2008-05-01T15:10:09 On 1 May 2008, at 16:00, Ben Adida wrote: > Lack of support for xml:base is considered a feature :) > http://www.w3.org/2006/07/SWD/track/issues/59 Oh, goody! I wasn't looking forward to that anyway. Cognition doesn't support the <base> element either though. > Maybe you meant xml:lang? xml:lang and the HTML lang attribute are fully supported in the latest released version. While I'm post... On 1 May 2008, at 16:00, Ben Adida wrote: > Lack of support for xml:base is considered a feature :) > http://www.w3.org/2006/07/SWD/track/issues/59 Oh, goody! I wasn't looking forward to that anyway. Cognition doesn't support the <base> element either though. > Maybe you meant xml:lang? xml:lang and the HTML lang attribute are fully supported in the latest released version. While I'm posting, can I ask for someone to contact me off-list about the RDFa test harness? I'm trying to get it working to automatically test the next release of Cognition, but always get "ERROR" even when I can *see* that the correct triples have been generated. I probably need some hand-holding, and don't want to bother the whole list with it, hence my request to contact me off-list... -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/77CAC239-F6CD-4F89-BC40-A7C747CC4533%40g5n.co.uk Re: Updated RDFa Syntax Editor's Draft 2008-05-02T09:59:36 2008-05-02T09:59:36 2008-05-02T09:59:36 Ivan Herman wrote: > I noted that there are two more predefined @rel values. We should > think > about updating the corresponding test case... I don't know whether this is any help, but as my parser does not *just* support RDFa (also supports eRDF, microformats, semantic HTML in general) it includes a big list of known rel values. These are taken from: * Latest HTML 5 draft * HTML 4.0... Ivan Herman wrote: > I noted that there are two more predefined @rel values. We should > think > about updating the corresponding test case... I don't know whether this is any help, but as my parser does not *just* support RDFa (also supports eRDF, microformats, semantic HTML in general) it includes a big list of known rel values. These are taken from: * Latest HTML 5 draft * HTML 4.01 * HTML 3.2 * Latest XHTML 2.0 draft The union of these (with comments beside the values not already included in RDFa) is: alternate appendix archives # HTML 5 author # HTML 5 bookmark chapter cite contact # HTML 5, though note conflict with XFN 1.1 contents copyright external # HTML 5, though more sense to infer from href feed # HTML 5 first glossary help icon index last license made # HTML 3.2 meta next nofollow # HTML 5 noreferrer # HTML 5 p3pv1 pingback # HTML 5 prefetch # HTML 5 prev previous # HTML 3.2 role search # HTML 3.2 section sidebar # HTML 5 start stylesheet subsection tag # HTML 5 top up Perhaps some of these values should be included in RDFa. Or a mechanism should exist for the HTML WG to feed their values back into RDFa once they hit "Recommendation" status? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/554E077B-821D-40BE-8F2E-1D21B802CD99%40g5n.co.uk Biological Taxonomy Vocabulary 0.1 2008-05-08T22:59:58 2008-05-08T22:59:58 2008-05-08T22:59:58 Unable to find a vocabulary that was satisfactory for my needs, I've put together a simple vocabulary for biological taxonomy. The idea is to make it powerful enough to cover 80% of use cases, but still simple for most non-expert biologists to use. Namespace and spec is: http://purl.org/NET/biol/0.1/ I'm posting this to the RDFa mailing list as I thought they might be interested in it ... Unable to find a vocabulary that was satisfactory for my needs, I've put together a simple vocabulary for biological taxonomy. The idea is to make it powerful enough to cover 80% of use cases, but still simple for most non-expert biologists to use. Namespace and spec is: http://purl.org/NET/biol/0.1/ I'm posting this to the RDFa mailing list as I thought they might be interested in it - the spec uses RDFa to provide a full RDF schema for the namespace. (There is a rel=alternate link to an RDF/XML version; and content negotiation serves up the RDF/XML version to agents that specifically request it.) I'm also posting this to the semantic web mailing list because I'd like some feedback on it. It's my first schema, so I'd like to know if I've made any obvious mistakes. Any design anti-patterns that I've triggered. I imagine that including the version number in the namespace URI might count as one, but I should mention that I plan on keeping the same namespace URI for subsequent versions of the spec, provided that they don't introduce changes which directly contradict the initial specification. (e.g. introducing new terms and deprecating old ones should be safe to keep the namespace URI; but if I actually remove terms or radically change their meanings, then I'd move to the /0.2/ URI.) What do people think? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/62835.81.2.120.180.1210329780.squirrel%40goddamn.co.uk Re: Biological Taxonomy Vocabulary 0.1 2008-05-09T10:43:00 2008-05-09T10:43:00 2008-05-09T10:43:00 > Have you checked OBO? > http://www.berkeleybop.org/ontologies/ > > Your proposition has taxonomy and stuff like it, all of that already > covered by most biological vocabularies. My aim has been somewhat different to most existing biological namespaces. Modelled on FOAF, it aims to be small, simple and useful. Anyone with even a moderate (high school level) level of knowledge about biology, and... > Have you checked OBO? > http://www.berkeleybop.org/ontologies/ > > Your proposition has taxonomy and stuff like it, all of that already > covered by most biological vocabularies. My aim has been somewhat different to most existing biological namespaces. Modelled on FOAF, it aims to be small, simple and useful. Anyone with even a moderate (high school level) level of knowledge about biology, and who is reasonably comfortable with RDF can learn a useful subset (hasTaxonomy, Taxonomy, name, commonName, seeAlso) in about five minutes and start using it. Existing taxonomy vocabs tend to follow a theme of every species requiring a unique identifying URI. That approach is not very scalable and certainly not memorable. If you take a look at the FlyBase vocab, the RDF schema weighs in at over 3 MB - and that vocab only covers fruit flies! The vocab I've written does not require species to have a unique URI - as a result the entire spec (which includes a schema in RDFa) is 28 kB (or 50 kB if you include the 22 kB RDF/XML alternative schema as well). But my approach is not fundamentally incompatible with most of the existing vocabs. They can be used in conjunction: <rdf:RDF xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:fb ="&fb;" xmlns:biol="&biol;"> <!-- Here is a flybase class for a particular type of fly. --> <owl:Class rdf:about="&fb;FBsp_00000074"> <!-- Specify that all such flies have a certain taxonomy. --> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&biol;hasTaxonomy" /> <owl:hasValue> <biol:Taxonomy> <biol:name>Drosophila busckii</biol:name> </biol:Taxonomy> </owl:hasValue> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <!-- Kevin is a fly. --> <fb:FBsp_00000074 rdf:ID="kev"> <foaf:name>Kevin the Fly</foaf:name> </fb:FBsp_00000074> </rdf:RDF> -- Toby Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/59731.81.2.120.180.1210344591.squirrel%40goddamn.co.uk Re: Biological Taxonomy Vocabulary 0.1 2008-05-09T14:49:51 2008-05-09T14:49:51 2008-05-09T14:49:51 > This is very interesting, and it's nice to have an example of an RDF > vocabulary that is defined using RDFa. It's obvious that a lot of work > and care went into preparing the HTML+RDFa document. Very well done! <snip> Richard, thanks for your feedback. All good points. Suffice to say, the new namespace URI is: http://purl.org/NET/biol/ns# I can't imagine many people have had time to ... > This is very interesting, and it's nice to have an example of an RDF > vocabulary that is defined using RDFa. It's obvious that a lot of work > and care went into preparing the HTML+RDFa document. Very well done! <snip> Richard, thanks for your feedback. All good points. Suffice to say, the new namespace URI is: http://purl.org/NET/biol/ns# I can't imagine many people have had time to implement it yet, given that I only posted about it about 16 hours ago, but for what it's worth, I'll keep the old documents at the old URI for the next week or so, to allow any early adopters to catch up. -- Toby Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/59817.81.2.120.180.1210346802.squirrel%40goddamn.co.uk Re: Biological Taxonomy Vocabulary 0.1 2008-05-09T15:26:42 2008-05-09T15:26:42 2008-05-09T15:26:42 > Plain text for divisions can lead to spell problems (not only caps) and > the information won't be wrong, but also putting all species names in a > list is not possible. How would you address that? The same could be said for foaf:name. FOAF doesn't have a big list of name URIs that you can choose from, and nor should it. URIs are good, but literals have their place in RDF too. > In Authority y... > Plain text for divisions can lead to spell problems (not only caps) and > the information won't be wrong, but also putting all species names in a > list is not possible. How would you address that? The same could be said for foaf:name. FOAF doesn't have a big list of name URIs that you can choose from, and nor should it. URIs are good, but literals have their place in RDF too. > In Authority you state what I got as the citation. Will you link to any > journal database or have a local citation list? Just saying "Linnaeus, > 1758" is not enough for most cases. A taxonomic authority is similar to a citation, but it's not the same. It's actually closer to a traditional namespacing mechanism. It effectively qualifies the binomial term being used, so "Homo sapiens (Linnaeus, 1758)" means "Homo sapiens, as would have been understood by Linnaeus in 1758". For a citation that is, say, a paper on the species in question, then biol:seeAlso can be used. For a citation justifying your claim that Foo is of species Bar, then you're getting into reification territory. -- Toby Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FCE16B54-7008-44E3-83D3-C94F36C62A12%40g5n.co.uk Re: [RDFa TC] Update 2008-05-27T13:28:19 2008-05-27T13:28:19 2008-05-27T13:28:19 > These b...dy xml literals again... And we always fall back to the same > issue, namely that, although two xml literals may be identical in the > xml infoset sense or, alternatively, in their canonical xml sense, the > sparql implementations may not compare these properly. Would a solution be to have the test case XML literals always result in RDF/XML fragments instead of XHTML or SVG as in th... > These b...dy xml literals again... And we always fall back to the same > issue, namely that, although two xml literals may be identical in the > xml infoset sense or, alternatively, in their canonical xml sense, the > sparql implementations may not compare these properly. Would a solution be to have the test case XML literals always result in RDF/XML fragments instead of XHTML or SVG as in the current test cases? Then the RDF/XML fragments can *themselves* be queried with SPARQL to verify conformance. e.g. <title>Test Case 201</title> <!-- ... --> <div about="#test201" property="[ex:testing]" datatype="rdf:XMLLiteral"> <rdf:RDF> <rdf:Description rdf:about="#embedded"> <dc:title>Foo</dc:title> </rdf:Description> </rdf:RDF> </div> Then, instead of insisting that RDFa implementations produce this or that particular string as an XMLLiteral, just check that they do indeed generate an XMLLiteral; then feed that XMLLiteral itself into SPARQL and query whether #embedded has a dc:title of "Foo". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9DE2AA67-FDE3-442D-9953-A4F4C8423E20%40g5n.co.uk Re: geo location tutorial cut 2008-07-08T16:13:25 2008-07-08T16:13:25 2008-07-08T16:13:25 Steven Pemberton wrote: > I don't think so; it just needs attention. People understand that > there > are things without URIs. You, me, towns, cars, emotions. But isn't one of the key ideas behind RDF that we *give* these things (network non-addressable resources: NNARs) URIs and can then start to describe them. The idea of DBpedia.org is that it automatically gives us a URI for the con... Steven Pemberton wrote: > I don't think so; it just needs attention. People understand that > there > are things without URIs. You, me, towns, cars, emotions. But isn't one of the key ideas behind RDF that we *give* these things (network non-addressable resources: NNARs) URIs and can then start to describe them. The idea of DBpedia.org is that it automatically gives us a URI for the concept behind every page at Wikipedia. That is, while <http:// en.wikipedia.org/wiki/The_Waste_Land> is a URI for a web page discussing a poem by T S Eliot, <http://dbpedia.org/resource/ The_Waste_Land> is intended to be a URI for the poem itself - the NNAR. (See <http://wiki.dbpedia.org/Datasets#h18-4>.) For any (English edition) Wikipedia article X, the following triples hold (or such is the aim of DBpedia.org). @prefix res: <http://dbpedia.org/resource/> . @prefix data: <http://dbpedia.org/data/> . @prefix page: <http://dbpedia.org/page/> . @prefix wiki: <http://en.wikipedia.org/wiki/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix dc: <http://purl.org/dc/terms/> . data:X foaf:primaryTopic res:X ; dc:source wiki:X . page:X foaf:primaryTopic res:X ; dc:source wiki:X . wiki:X foaf:primaryTopic res:X . res:X foaf:page wiki:X . That is, DBpedia.org assigns URIs for every concept that has an article on Wikipedia, which is a separate URI from the article itself. MySpace or its ilk could easily do something similar by creating a subdomain res.myspace.com such that for any user X at MySpace, then: @prefix myspace: <http://www.myspace.com/> . @prefix myres: <http://res.myspace.com/> . myspace:X foaf:primaryTopic myres:X . myres:X foaf:page myspace:X . Then someone could easily make statements like the one mentioned earlier: myres:joe foaf:knows myres:some_band . The solution is not to find easier ways to make statements about things without URIs, but rather we should have more URIs for NNARs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/97B08EE1-BC6C-4C46-A50C-B8F1B1CD916C%40g5n.co.uk Re: RDF vocabulary best practices question... 2008-07-10T21:56:17 2008-07-10T21:56:17 2008-07-10T21:56:17 Manu Sporny wrote: > Is adding synonyms into your vocabulary a valid best practice? For > example, is having audio:title specified as owl:sameAs dc:title > acceptable? I'd also consider using: audio:title rdfs:subPropertyOf dc:title, rdfs:label . Which implies that if a query tool is looking for a dc:title, but can't find one then it may use an audio:title instead. (But not vice versa.)... Manu Sporny wrote: > Is adding synonyms into your vocabulary a valid best practice? For > example, is having audio:title specified as owl:sameAs dc:title > acceptable? I'd also consider using: audio:title rdfs:subPropertyOf dc:title, rdfs:label . Which implies that if a query tool is looking for a dc:title, but can't find one then it may use an audio:title instead. (But not vice versa.) On a property-by-property basis you should consider which of owl:sameAs or rdfs:subPropertyOf is more appropriate. I'm at the beginning of implementing hAudio support in Cognition. (And the first stage of supporting any microformat in Cognition is a mapping to RDF!) I'd be interested in hearing on your progress on this vocabulary - if not on this list or the microformats lists, then off-list. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/2B374CE5-FC35-45BB-9A1A-C1E546DBB249%40tobyinkster.co.uk Re: RDF vocabulary best practices question... 2008-07-11T09:10:14 2008-07-11T09:10:14 2008-07-11T09:10:14 On 10 Jul 2008, at 22:56, Toby A Inkster wrote: > Manu Sporny wrote: > >> Is adding synonyms into your vocabulary a valid best practice? For >> example, is having audio:title specified as owl:sameAs dc:title >> acceptable? > > I'd also consider using: > audio:title rdfs:subPropertyOf dc:title, rdfs:label . Here's another thought. If you say: audio:foo vs:status "unstable" ; rdfs:label "aud... On 10 Jul 2008, at 22:56, Toby A Inkster wrote: > Manu Sporny wrote: > >> Is adding synonyms into your vocabulary a valid best practice? For >> example, is having audio:title specified as owl:sameAs dc:title >> acceptable? > > I'd also consider using: > audio:title rdfs:subPropertyOf dc:title, rdfs:label . Here's another thought. If you say: audio:foo vs:status "unstable" ; rdfs:label "audio foo" ; owl:sameAs dc:foo . Then you are implying: dc:foo vs:status "unstable" ; rdfs:label "audio foo" . Which may not be true. That's a vote in favour of rdfs:subPropertyOf I think. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/4732BA53-703D-4D6F-8F05-7C0ED9845E8E%40g5n.co.uk Extending hCard with RDFa 2008-07-16T22:30:08 2008-07-16T22:30:08 2008-07-16T22:30:08 I mentioned that I was working on an article about extending hCard with RDFa a few weeks ago on the Microformats discussion list, but then went on holiday and forgot about it for a while. Anyway... http://tobyinkster.co.uk/blog/2008/07/16/hcard-rdfa/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I mentioned that I was working on an article about extending hCard with RDFa a few weeks ago on the Microformats discussion list, but then went on holiday and forgot about it for a while. Anyway... http://tobyinkster.co.uk/blog/2008/07/16/hcard-rdfa/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/0EB458E9-53D0-456F-AF8A-38A7574DDE22%40g5n.co.uk Re: RDFa Primer comment 2008-07-16T22:33:47 2008-07-16T22:33:47 2008-07-16T22:33:47 Shane McCarron wrote: > No one is charged with defining RDFa in terms of HTML. For what it's worth... http://buzzword.org.uk/2008/html4plus-example.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Shane McCarron wrote: > No one is charged with defining RDFa in terms of HTML. For what it's worth... http://buzzword.org.uk/2008/html4plus-example.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/63363.81.2.120.180.1216285902.squirrel%40goddamn.co.uk Re: Extending hCard with RDFa 2008-07-17T09:11:42 2008-07-17T09:11:42 2008-07-17T09:11:42 > Now if the @profile support for microformats could be standardized to > use that @id you added as the subject, that would round out the triple > generation quite nicely... I've reproduced the final example in the article here: http://examples.tobyinkster.co.uk/hcard-rdfa.html Submitting that to Cognition's <http://buzzword.org.uk/cognition/> web service yields the following RDF/XML: <?xml ve... > Now if the @profile support for microformats could be standardized to > use that @id you added as the subject, that would round out the triple > generation quite nicely... I've reproduced the final example in the article here: http://examples.tobyinkster.co.uk/hcard-rdfa.html Submitting that to Cognition's <http://buzzword.org.uk/cognition/> web service yields the following RDF/XML: <?xml version="1.0"?> <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:vcard="urn:ietf:rfc:2426#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:ex="http://example.net/people#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcmitype="http://purl.org/dc/dcmitype/" xmlns:hcterms="http://purl.org/uF/hCard/terms/" xmlns:xhv="http://www.w3.org/1999/xhtml/vocab#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <dcmitype:Text rdf:about="http://examples.tobyinkster.co.uk/hcard-rdfa.html"> <dcterms:hasPart> <rdf:Description rdf:nodeID="Section1"> <dcterms:title>My Document</dcterms:title> <dcterms:hasPart> <rdf:Description rdf:nodeID="Section2"> <dcterms:title>Toby Inkster</dcterms:title> </rdf:Description> </dcterms:hasPart> </rdf:Description> </dcterms:hasPart> <foaf:maker rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> <dcterms:identifier rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html" /> <dcterms:type rdf:resource="http://purl.org/dc/dcmitype/Text" /> <hcterms:representative rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> <xhv:author rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> </dcmitype:Text> <vcard:Vcard rdf:about="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby"> <vcard:n> <vcard:Name rdf:nodeID="ContactName1"> <vcard:family-name>Inkster</vcard:family-name> <rdfs:label>Toby Inkster</rdfs:label> <rdf:value>Inkster;Toby</rdf:value> <vcard:given-name>Toby</vcard:given-name> </vcard:Name> </vcard:n> <foaf:made rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html" /> <dcterms:identifier rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> <vcard:bday> <dcterms:W3CDTF> <rdf:value rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1980-06-01</rdf:value> </dcterms:W3CDTF> </vcard:bday> <ex:shoes>10</ex:shoes> <vcard:kind>individual</vcard:kind> <vcard:fn>Toby Inkster</vcard:fn> <ex:height>1.75</ex:height> </vcard:Vcard> </rdf:RDF> http://tobyinkster.co.uk/message/62815.81.2.120.180.1216286083.squirrel%40goddamn.co.uk Re: Extending hCard with RDFa 2008-07-17T09:14:43 2008-07-17T09:14:43 2008-07-17T09:14:43 > Now if the @profile support for microformats could be standardized to use that @id you added as the subject, that would round out the triple generation quite nicely... I've reproduced the final example in the article here: http://examples.tobyinkster.co.uk/hcard-rdfa.html Submitting that to Cognition's <http://buzzword.org.uk/cognition/> web service yields the following RDF/XML: <?xml versio... > Now if the @profile support for microformats could be standardized to use that @id you added as the subject, that would round out the triple generation quite nicely... I've reproduced the final example in the article here: http://examples.tobyinkster.co.uk/hcard-rdfa.html Submitting that to Cognition's <http://buzzword.org.uk/cognition/> web service yields the following RDF/XML: <?xml version="1.0"?> <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:vcard="urn:ietf:rfc:2426#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:ex="http://example.net/people#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcmitype="http://purl.org/dc/dcmitype/" xmlns:hcterms="http://purl.org/uF/hCard/terms/" xmlns:xhv="http://www.w3.org/1999/xhtml/vocab#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <dcmitype:Text rdf:about="http://examples.tobyinkster.co.uk/hcard-rdfa.html"> <dcterms:hasPart> <rdf:Description rdf:nodeID="Section1"> <dcterms:title>My Document</dcterms:title> <dcterms:hasPart> <rdf:Description rdf:nodeID="Section2"> <dcterms:title>Toby Inkster</dcterms:title> </rdf:Description> </dcterms:hasPart> </rdf:Description> </dcterms:hasPart> <foaf:maker rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> <dcterms:identifier rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html" /> <dcterms:type rdf:resource="http://purl.org/dc/dcmitype/Text" /> <hcterms:representative rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> <xhv:author rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> </dcmitype:Text> <vcard:Vcard rdf:about="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby"> <vcard:n> <vcard:Name rdf:nodeID="ContactName1"> <vcard:family-name>Inkster</vcard:family-name> <rdfs:label>Toby Inkster</rdfs:label> <rdf:value>Inkster;Toby</rdf:value> <vcard:given-name>Toby</vcard:given-name> </vcard:Name> </vcard:n> <foaf:made rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html" /> <dcterms:identifier rdf:resource="http://examples.tobyinkster.co.uk/hcard-rdfa.html#hcard_toby" /> <vcard:bday> <dcterms:W3CDTF> <rdf:value rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1980-06-01</rdf:value> </dcterms:W3CDTF> </vcard:bday> <ex:shoes>10</ex:shoes> <vcard:kind>individual</vcard:kind> <vcard:fn>Toby Inkster</vcard:fn> <ex:height>1.75</ex:height> </vcard:Vcard> </rdf:RDF> http://tobyinkster.co.uk/message/61B4D775-1F80-4672-B57E-A1B0F912B32E%40g5n.co.uk Re: SVG in HTML proposal 2008-07-17T14:00:15 2008-07-17T14:00:15 2008-07-17T14:00:15 Just an idea, but how about this: <script type="image/svg" id="myImage"> <![CDATA[ <svg ...> ... </svg> ]]> </script> <img src="#myImage"> Allows the same SVG image to be re-used several times on the same page without bloating the file size. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Just an idea, but how about this: <script type="image/svg" id="myImage"> <![CDATA[ <svg ...> ... </svg> ]]> </script> <img src="#myImage"> Allows the same SVG image to be re-used several times on the same page without bloating the file size. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E1EF2326-7B06-497E-B14F-3F3ABEBA9310%40g5n.co.uk Re: RDFa in HTML 4 2008-07-17T21:15:59 2008-07-17T21:15:59 2008-07-17T21:15:59 Manu Sporny wrote: > <div curieprefix="dcterms http://purl.org/dc/terms/ > media http://purl.org/media# > audio http://purl.org/media/audio#" > about="#a-song" typeof="audio:Recording"> I've suggested it before, but I'll suggest it again. RFC 2731, which was put forward by the Dublin Core crowd many years ago, already offers an HTML-compat... Manu Sporny wrote: > <div curieprefix="dcterms http://purl.org/dc/terms/ > media http://purl.org/media# > audio http://purl.org/media/audio#" > about="#a-song" typeof="audio:Recording"> I've suggested it before, but I'll suggest it again. RFC 2731, which was put forward by the Dublin Core crowd many years ago, already offers an HTML-compatible method for defining prefixes for metadata terms. RFC 2731 has been embraced by eRDF. The syntax is: <link rel="schema.dct" href="http://purl.org/dc/terms/"> These definitions are document wide though, so it may be necessary to refine the syntax to allow them to be scoped to particular elements. Perhaps using: <link about="#section-1" rel="schema.dct" href="http://purl.org/dc/terms/"> to define the CURIE prefix "dct" to be only valid within the element with id="section-1". (This creates an additional limitation that for an element to have CURIE prefix definitions scoped to it, it must have an ID attribute, but this isn't a major limitation.) > There is no HTML4 + RDFa validator, and until we can point web > developers to a tool that validates HTML4 + RDFa, we should not > encourage them to use RDFa in HTML4. I posted this on this mailing list just yesterday - a page using a DTD based on HTML 4.01 Strict, but with RDFa attributes added. http://buzzword.org.uk/2008/html4plus-example.html This *will* validate in the W3C validator, though it would be nice if there was a way to make the "Unable to Determine Parse Mode!" warning disappear. It *will* parse correctly in most (all?) RDFa parsers. > The goal is to enable HTML 4 + RDFa as quickly as possible. Well, Cognition has supported RDFa in HTML 4 (using RFC 2731 for CURIE prefixes) since February. http://buzzword.org.uk/cognition/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E553CFF7-26C2-450F-A9E1-37C2112205B0%40g5n.co.uk Re: Extending hCard with RDFa 2008-07-17T21:19:36 2008-07-17T21:19:36 2008-07-17T21:19:36 On 17 Jul 2008, at 19:18, Martin McEvoy wrote: > I have done quite a lot of work trying to do just as you say (my > exploration of this lead me to RDFa), but in a "microformat" type > way it > relies on the microformats item, type, @id, value and ". [dot]" > which is > used with value to say "here" or "this" > > http://weborganics.co.uk/hRDF/ It's quite an inelegant syntax. Have you looked ... On 17 Jul 2008, at 19:18, Martin McEvoy wrote: > I have done quite a lot of work trying to do just as you say (my > exploration of this lead me to RDFa), but in a "microformat" type > way it > relies on the microformats item, type, @id, value and ". [dot]" > which is > used with value to say "here" or "this" > > http://weborganics.co.uk/hRDF/ It's quite an inelegant syntax. Have you looked at eRDF? It provides a reasonably good way of embedding RDF triples in (X)HTML. Not as powerful as RDFa, but it will work with standard HTML/XHTML DOCTYPEs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C6E5A123-61BD-4B8F-A79D-7489E6E4070D%40g5n.co.uk Re: RDFa in HTML 4 2008-07-17T22:38:49 2008-07-17T22:38:49 2008-07-17T22:38:49 On 17 Jul 2008, at 23:00, Manu Sporny wrote: > The issue with the RFC-2731 approach, unless I'm missing something, is > that it doesn't allow multiple scoped prefix definitions. Take the > following example: > > <div xmlns:dcterms="http://purl.org/dc/terms/" > xmlns:audio="http://purl.org/media/audio#" > about="#welcome-to-the-jungle" typeof="audio:Recording"> > <span... On 17 Jul 2008, at 23:00, Manu Sporny wrote: > The issue with the RFC-2731 approach, unless I'm missing something, is > that it doesn't allow multiple scoped prefix definitions. Take the > following example: > > <div xmlns:dcterms="http://purl.org/dc/terms/" > xmlns:audio="http://purl.org/media/audio#" > about="#welcome-to-the-jungle" typeof="audio:Recording"> > <span property="dcterms:title">Welcome to the Jungle</span> > </div> > > How would we accomplish doing that with the RFC-2731 approach? My suggestion, and bear in mind that I haven't implemented this yet, is that we allow something like: <link about="#node-wttj" rel="schema.dct" href="http://purl.org/dc/terms/"> <link about="#node-wttj" rel="schema.audio" href="http://purl.org/media/audio#"> [...] <div id="node-wttj" about="#welcome-to-the-jungle" typeof="audio:Recording"> <span property="dcterms:title">Welcome to the Jungle</span> </div> One advantage of xmlns attributes over RFC 2731 is that they allow the CURIE prefixes to be defined near to the node where they're used. Extending RFC 2731 slightly further we get: <span about="#node-wttj" rel="schema.dct" resource="http://purl.org/dc/terms/"></span> <span about="#node-wttj" rel="schema.audio" resource="http://purl.org/media/audio#"></span> <div id="node-wttj" about="#welcome-to-the-jungle" typeof="audio:Recording"> <span property="dcterms:title">Welcome to the Jungle</span> </div> The limitation here to fit (largely) into the existing RDFa parsing pattern is that the element which defines a CURIE prefix must be encountered prior to the element which uses the CURIE prefix. Another method could be to repurpose @profile, using a SafeCURIE-like syntax: <head profile="http://www.w3.org/1999/xhtml/vocab [dcterms:http://purl.org/dc/terms/] [audio:http://purl.org/media/audio#]"> which could be extended to be valid on all elements (much like @rel/ @rev were). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/80FC3260-A2BB-4092-A2FA-464892AB01F7%40g5n.co.uk Re: GRDDL profile and transform for RDFa: new version and new license 2008-07-20T22:21:58 2008-07-20T22:21:58 2008-07-20T22:21:58 Fabien Gandon: > Tests 105 and 107: I don’t understand why no triple should be > generated > and more precisely what should be tested to decide whether or not a > triple should be generated in that case. I thought non prefixed name > were considered to be in the default namespace. Do these tests mean > that > non-prefixed predicate names should be ignored? Yes - they should be ignored, excep... Fabien Gandon: > Tests 105 and 107: I don’t understand why no triple should be > generated > and more precisely what should be tested to decide whether or not a > triple should be generated in that case. I thought non prefixed name > were considered to be in the default namespace. Do these tests mean > that > non-prefixed predicate names should be ignored? Yes - they should be ignored, except for the reserved names. http://www.w3.org/TR/rdfa-syntax/#relValues You might also want to consider supporting "made", "previous" and "search", which are rel/rev values defined in the W3C HTML 3.2 spec, but not explicitly reserved in RDFa. The former two are fairly widely used in the wild. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9FA5C2B5-934F-4CFF-B3F2-F6EC61E7F00B%40g5n.co.uk Re: Late, but I have reservations. 2008-07-20T22:22:29 2008-07-20T22:22:29 2008-07-20T22:22:29 Gannon J Dick wrote: > Second, some of my issues may have been dealt with already: > including 1) the syntax incompatibility with DCMI <meta> and > <link>, and 2) the same incompatibility vis-a-vis GRDDL. The syntax of RDFa certainly *differs* from the above, but as far as I know there aren't any situations where the differences cause problems. (Though certainly you could write an XSLT t... Gannon J Dick wrote: > Second, some of my issues may have been dealt with already: > including 1) the syntax incompatibility with DCMI <meta> and > <link>, and 2) the same incompatibility vis-a-vis GRDDL. The syntax of RDFa certainly *differs* from the above, but as far as I know there aren't any situations where the differences cause problems. (Though certainly you could write an XSLT transformation which deliberately misinterprets RDFa and link to it via GRDDL. This is outside of the typical use case of GRDDL though, which generates RDF from microformats and microformat-like HTML, mostly looking at HTML classes.) > The use of RDFa attributes within the <body> element do not > necessarily suffer from the same issue, except for one class of > user - persons (and personal privacy). Persons are one of the key classes of user RDFa is aimed at. ;-) If you publish personal data on the wild, wild web, then you really shouldn't have any expectation of privacy with regard to those data. That is true with or without RDFa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C59F1E54-84B8-495D-A5F4-4181985C48E8%40g5n.co.uk Re: Late, but I have reservations. 2008-07-22T06:45:41 2008-07-22T06:45:41 2008-07-22T06:45:41 > Further, if Persons are a key class of user, what purpose is served > by allowing RDFa in the <head>? The question to ask is what would be served by *disallowing* it? It's simpler for authors to remember and parsers to implement if they can just follow the rule "it's allowed everywhere" rather than worrying about where it is be allowed and where it isn't. Besides which, <title property... > Further, if Persons are a key class of user, what purpose is served > by allowing RDFa in the <head>? The question to ask is what would be served by *disallowing* it? It's simpler for authors to remember and parsers to implement if they can just follow the rule "it's allowed everywhere" rather than worrying about where it is be allowed and where it isn't. Besides which, <title property="dc:title"> offers a quick, easy triple that anyone can implement without any thought. Existing <link rel="stylesheet"> links in <head> will also create triples. > The meta data in the <head> should be reserved for computer magic > tricks, not connectivity code between two humans neither of which > (mostly) ever see the <head>. Yes, many people do not see/cannot change <head>, but as RDFa can be used in the page body, that's fine. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20E29AD9-DFBF-445B-ACDB-E2A780B4CEF4%40g5n.co.uk Re: RDFa test suite addition 2008-07-29T08:34:32 2008-07-29T08:34:32 2008-07-29T08:34:32 The current behaviour of Cognition is that it will happily deal with relative URIs - including normalisation of ".." components - for the subject and object of a triple. But for the predicate, no normalisation currently takes place. In fact, I think that using something like xmlns:ex="http://example.org/ ns/" rel="ex:../foo" is likely to cause problems all over the place - e.g. if output... The current behaviour of Cognition is that it will happily deal with relative URIs - including normalisation of ".." components - for the subject and object of a triple. But for the predicate, no normalisation currently takes place. In fact, I think that using something like xmlns:ex="http://example.org/ ns/" rel="ex:../foo" is likely to cause problems all over the place - e.g. if outputting RDF/XML, Cognition would get confused, because the predicate http://example.org/foo would be outside any defined namespaces. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/F44CE6E6-D24A-4656-B0FD-57E6D9085062%40g5n.co.uk Re: RDFa test suite addition 2008-07-29T20:04:16 2008-07-29T20:04:16 2008-07-29T20:04:16 On 29 Jul 2008, at 18:32, Shane McCarron wrote: > I get what you are saying here... but you scared me with > something. What is Cognition learning about a "namespace" in the > context of RDFa? It should not be learning anything? There are no > namespaces in RDFa. There are prefix values and suffixes. And the > concatenation of these creates URIs (IRIs) that, when dereferenced, > co... On 29 Jul 2008, at 18:32, Shane McCarron wrote: > I get what you are saying here... but you scared me with > something. What is Cognition learning about a "namespace" in the > context of RDFa? It should not be learning anything? There are no > namespaces in RDFa. There are prefix values and suffixes. And the > concatenation of these creates URIs (IRIs) that, when dereferenced, > could mean something. In my opinion Cognition could be learning > about those URIs... but the prefix value is meaningless. Hell, the > prefix value could be "http". It could be "h". It would be > completely legitimate. As I said, it's not so much a problem with the RDFa parsing, but any subsequent RDF/XML output. Say, for example, we have the following RDFa: <div xmlns:ex="http://example.org/ns/" rel="ex:../foo" about="http://example.com/"> Foobar </div> This will be parsed as the following triple: <http://example.com/> <http://example.org/foo> "Foobar". If the parser then is to output to RDF/XML, the result will be something like: <rdf:Description rdf:about="http://example.com/" XXX:YYY="Foobar" /> But won't know what to choose for 'XXX' or 'YYY'. I suppose it could figure out YYY by finding the last slash or hash sign in the predicate, then choose a random string to use for the prefix XXX, but the results are unlikely to be pretty. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/61922157-FFF9-4DB0-A29B-867FBD175C1F%40tobyinkster.co.uk Re: Translation control in HTML5 2008-08-01T08:27:12 2008-08-01T08:27:12 2008-08-01T08:27:12 Ian Hickson <ian@hixie.ch> wrote: > How about a new keyword for "lang", instead, which means "not > translatable" or some such? lang="computer-code" or something. lang="zxx". Jirka Kosek <jirka@kosek.cz> wrote: > <p lang="en">In Germany it is quite common to clink with glasses > before > drinking and to say <em lang="de" translate="no">Prost!</em> as a > toast.</p> > > If you will translat... Ian Hickson <ian@hixie.ch> wrote: > How about a new keyword for "lang", instead, which means "not > translatable" or some such? lang="computer-code" or something. lang="zxx". Jirka Kosek <jirka@kosek.cz> wrote: > <p lang="en">In Germany it is quite common to clink with glasses > before > drinking and to say <em lang="de" translate="no">Prost!</em> as a > toast.</p> > > If you will translate this sentence to French, you of course do not > want > to translate "Prost" <p lang="en">In Germany it is quite common to clink with glasses before drinking and to say <q lang="de">Prost!</q> as a toast.</p> With a general recommendation that certain elements (e.g. <q>, <code>, etc) not be translated unless the user of the translation service has explicitly chosen an option to translate them. Simon Pieters <simonp@opera.com> wrote: > <meta name=notranslate content="code, #logo, .term, :lang(de)"> If this were to go ahead, I'd suggest a default value of: code,kbd,:lang(zxx) I think there are really two separate categories of markup which we want to deal with here though: 1. Stuff that should not be translated because it's not really linguistic content. For example, the contents of <code> or <kbd>; taxonomic names. 2. Stuff that should not be translated because it is more useful in its original language: book titles, certain quotes, etc. It is best if we mark up what these things *are* rather than what we should *do* with them. That is, we should use elements or attributes which indicate *why* they shouldn't be translated, rather than an attribute that simply says that they should not be translated. This is for the same reason that class="warning" is better than class="big- red-bit". We should be able to deal with the first category without adding any additional elements or attributes. The "don't translate <code>, <kbd> or :lang(zxx)" rule seems to mostly cover it. The second category is more difficult as it's something that needs to be determined by the page author. (Though of course, the reader should be able to over-rule the author.) I'd suggest that the easiest way of doing this would be through the lang attribute. I'd suggest that any lang attribute matching this pattern: /(\-xx(\-|$)|\-x\-notrans(\-|$))/i be considered an element which should preferably not be translated. That is, in RFC 4646 terms, a region code of 'XX' (ISO 3166 private use code) or an 'x-notrans' subtag. e.g. the following should not be translated: de-XX de-DE-x-notrans de-XX-x-foobar -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8C2C8198-E7D2-44A5-AA9B-114EF58992AA%40g5n.co.uk Re: Translation control in HTML5 2008-08-01T08:27:46 2008-08-01T08:27:46 2008-08-01T08:27:46 Ian Hickson <ian@hixie.ch> wrote: > How about a new keyword for "lang", instead, which means "not > translatable" or some such? lang="computer-code" or something. lang="zxx". Jirka Kosek <jirka@kosek.cz> wrote: > <p lang="en">In Germany it is quite common to clink with glasses > before > drinking and to say <em lang="de" translate="no">Prost!</em> as a > toast.</p> > > If you will translat... Ian Hickson <ian@hixie.ch> wrote: > How about a new keyword for "lang", instead, which means "not > translatable" or some such? lang="computer-code" or something. lang="zxx". Jirka Kosek <jirka@kosek.cz> wrote: > <p lang="en">In Germany it is quite common to clink with glasses > before > drinking and to say <em lang="de" translate="no">Prost!</em> as a > toast.</p> > > If you will translate this sentence to French, you of course do not > want > to translate "Prost" <p lang="en">In Germany it is quite common to clink with glasses before drinking and to say <q lang="de">Prost!</q> as a toast.</p> With a general recommendation that certain elements (e.g. <q>, <code>, etc) not be translated unless the user of the translation service has explicitly chosen an option to translate them. Simon Pieters <simonp@opera.com> wrote: > <meta name=notranslate content="code, #logo, .term, :lang(de)"> If this were to go ahead, I'd suggest a default value of: code,kbd,:lang(zxx) I think there are really two separate categories of markup which we want to deal with here though: 1. Stuff that should not be translated because it's not really linguistic content. For example, the contents of <code> or <kbd>; taxonomic names. 2. Stuff that should not be translated because it is more useful in its original language: book titles, certain quotes, etc. It is best if we mark up what these things *are* rather than what we should *do* with them. That is, we should use elements or attributes which indicate *why* they shouldn't be translated, rather than an attribute that simply says that they should not be translated. This is for the same reason that class="warning" is better than class="big- red-bit". We should be able to deal with the first category without adding any additional elements or attributes. The "don't translate <code>, <kbd> or :lang(zxx)" rule seems to mostly cover it. The second category is more difficult as it's something that needs to be determined by the page author. (Though of course, the reader should be able to over-rule the author.) I'd suggest that the easiest way of doing this would be through the lang attribute. I'd suggest that any lang attribute matching this pattern: /(\-xx(\-|$)|\-x\-notrans(\-|$))/i be considered an element which should preferably not be translated. That is, in RFC 4646 terms, a region code of 'XX' (ISO 3166 private use code) or an 'x-notrans' subtag. e.g. the following should not be translated: de-XX de-DE-x-notrans de-XX-x-foobar -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6D76608F-7A41-45F4-957A-0887BC5567C4%40tobyinkster.co.uk RE: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal) 2008-08-05T16:56:04 2008-08-05T16:56:04 2008-08-05T16:56:04 Justin James wrote: > like CSS but for semantics That's precisely what GRDDL is - a "semantics sheet", much like a stylesheet - a way to map tag names, class names, etc to RDF triples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Justin James wrote: > like CSS but for semantics That's precisely what GRDDL is - a "semantics sheet", much like a stylesheet - a way to map tag names, class names, etc to RDF triples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/60777.81.2.120.180.1217956163.squirrel%40goddamn.co.uk RE: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal) 2008-08-05T17:09:23 2008-08-05T17:09:23 2008-08-05T17:09:23 Justin James wrote: > like CSS but for semantics That's precisely what GRDDL is - a "semantics sheet", much like a stylesheet - a way to map tag names, class names, etc to RDF triples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Justin James wrote: > like CSS but for semantics That's precisely what GRDDL is - a "semantics sheet", much like a stylesheet - a way to map tag names, class names, etc to RDF triples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/F327C232-C155-497B-9BA1-6D1791D952BC%40g5n.co.uk Re: GRDDL (was: RE: Extensibility strategies) 2008-08-05T23:07:46 2008-08-05T23:07:46 2008-08-05T23:07:46 On 5 Aug 2008, at 20:22, Justin James wrote: > * It is highly complex - Look at the diagrams on that page... > anything that > requires that many transformations and steps is prone to failure and > problems. One misbehaving parser in that chain breaks it. Misbehaving rendering engines have been a major annoyance for authors for ages, but people still use CSS. GRDDL is very much simpler than ... On 5 Aug 2008, at 20:22, Justin James wrote: > * It is highly complex - Look at the diagrams on that page... > anything that > requires that many transformations and steps is prone to failure and > problems. One misbehaving parser in that chain breaks it. Misbehaving rendering engines have been a major annoyance for authors for ages, but people still use CSS. GRDDL is very much simpler than CSS. (Though GRDDL makes use of XSLT which is quite complex - however, many browsers do already have reasonably good XSLT implementations.) > * Confusing - Maybe the spec is still a draft, but I am a smart guy > and it > took way too long for me to "get" this document. Even worse, it > relies upon > having an in-depth understanding of another obscure spec, RDF > (another one I > never heard of until a few days ago). RDF is the thousand-pound gorilla of the metadata world. There is virtually no work going on in the online metadata world that does not somehow involve RDF. If GRDDL couldn't output RDF, then it would be destined to be no more than a plaything. Any solution that aims to do for semantics what CSS has done for style would *have* to use RDF to be taken seriously. RDF is no more complex than CSS. Looking at CSS at a very high level, the syntax is simply: selector { property1: value1; property2: value2; } Any elements selected by the selector get the property-value pairs applied to them. Easy. Of course, when you want to learn what all the valid properties are, their values, how they interact, etc, it becomes more complicated. The same with RDF. The high level view is dead easy: subject1 predicate1 object1 . subject2 predicate2 object2 . And then you just need to know that subjects and predicates are normally expressed as URIs. Objects are sometimes URIs, sometimes literals. e.g. <http://dbpedia.org/resource/Sky> <http://example.com/ns#colour> "blue" . Of course, the deeper you look, the more complicated it gets, with BNodes, and multiple serialisations (Just as HTML5 has different representations - HTML, XHTML and DOM - so does RDF have various different representations, in XML, a text-like format, JSON, etc.), reification, datatypes, CURIEs and so on. But the same can be said of CSS - the deeper you look, the more complicated it gets. Gurus are well-versed in browser-specific hacks, the rules of the cascade, inheritance, default values of properties for different elements, media queries, browser-specific extensions, etc. But at it's heart, the concept of triples, with most of the components being URIs, RDF is actually pretty simple. > * HTML abuse - This seems to be predicated on abusing and mis-using > HTML. > Maybe I am reading it wrong. Not sure why you think that. GRDDL has two main methods of linking to a transformation from an HTML file. The first is very much like CSS... To link to a stylesheet, you use: <link rel="stylesheet" href="style.css"> To link to a "semantics sheet", you use: <link rel="transformation" href="semantics.xslt"> The other uses the HTML <head profile> attribute. Rather than linking to the XSLT file directly, you include the URI for a profile document in your <head profile>, and then the profile document links to the XSLT file. This second method of linking is intended to be not so much used for ad-hoc linking to "semantics sheets" like the first syntax is, but rather for linking to the profiles of Microformats (official ones or otherwise). GRDDL is quite simple and elegant, except for the fact that is specifies that the data transformations must be written in XSLT, which is not very elegant in syntax, not is it an especially well- known programming language amongst most web authors. I think Javascript may have been a better route for them to follow, but I suppose that ship has sailed. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/7260D0DF-8997-4CA4-8308-784142AC3EE8%40g5n.co.uk Test case #31 2008-08-07T20:46:34 2008-08-07T20:46:34 2008-08-07T20:46:34 Cognition seems to fail this because it converts "urn:ISBN: 0752820907" to "urn:isbn:0752820907". According to my reading of RFC 2141, section 2.1, these two URIs are considered identical. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Cognition seems to fail this because it converts "urn:ISBN: 0752820907" to "urn:isbn:0752820907". According to my reading of RFC 2141, section 2.1, these two URIs are considered identical. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/00D620D9-92E1-4E2E-A983-F238FB8DEF2F%40tobyinkster.co.uk Re: Test case #31 2008-08-07T20:49:36 2008-08-07T20:49:36 2008-08-07T20:49:36 On 7 Aug 2008, at 21:46, Toby A Inkster wrote: > Cognition seems to fail this because it converts "urn:ISBN: > 0752820907" to "urn:isbn:0752820907". According to my reading of > RFC 2141, section 2.1, these two URIs are considered identical. Ditto test case #32. Perhaps others. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 7 Aug 2008, at 21:46, Toby A Inkster wrote: > Cognition seems to fail this because it converts "urn:ISBN: > 0752820907" to "urn:isbn:0752820907". According to my reading of > RFC 2141, section 2.1, these two URIs are considered identical. Ditto test case #32. Perhaps others. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/F40E56B5-BD52-436E-AAF3-ABE6BA0D68B1%40g5n.co.uk Re: Test cases #32, #104, #1001 2008-08-07T21:43:30 2008-08-07T21:43:30 2008-08-07T21:43:30 On 7 Aug 2008, at 21:46, Toby A Inkster wrote: > Cognition seems to fail this because it converts "urn:ISBN: > 0752820907" to "urn:isbn:0752820907". According to my reading of > RFC 2141, section 2.1, these two URIs are considered identical. Ditto test case #32. Also, anyone have any idea why this output for test case #104 errors out? It is valid RDF/XML according to the W3C RDF validator.... On 7 Aug 2008, at 21:46, Toby A Inkster wrote: > Cognition seems to fail this because it converts "urn:ISBN: > 0752820907" to "urn:isbn:0752820907". According to my reading of > RFC 2141, section 2.1, these two URIs are considered identical. Ditto test case #32. Also, anyone have any idea why this output for test case #104 errors out? It is valid RDF/XML according to the W3C RDF validator. (URLs are trimmed for readability in this message only - I'm not trimming them when I try the test harness!) <?xml version="1.0"?> <rdf:RDF xmlns:u="http://purl.org/NET/uri#" xmlns:example="http://www.example.org/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dcterms="http://purl.org/dc/terms/"> <rdf:Description rdf:about=".../0104.xhtml"> <dcterms:title>Test 0104</dcterms:title> <dcterms:type rdf:resource="http://purl.org/dc/dcmitype/Text" /> <u:uri rdf:resource=".../0104.xhtml" /> </rdf:Description> <rdf:Description rdf:about=".../0104.xhtml#interfenestration"> <u:uri rdf:resource=".../0104.xhtml#interfenestration" /> <example:size> <rdf:Description rdf:nodeID="Node1"> <rdf:value>17</rdf:value> <example:unit>character</example:unit> </rdf:Description> </example:size> </rdf:Description> </rdf:RDF> Also this in test case #1001: <?xml version="1.0"?> <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:u="http://purl.org/NET/uri#" xmlns:cal="http://www.w3.org/2002/12/cal/icaltzd#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about=".../1001.xhtml"> <dcterms:title>Test 1001</dcterms:title> <dcterms:type rdf:resource="http://purl.org/dc/dcmitype/Text" /> <u:uri rdf:resource=".../1001.xhtml" /> </rdf:Description> <cal:Vevent rdf:about=".../1001.xhtml#event1"> <cal:url rdf:resource="http://freetime.example.org/" /> <cal:summary>Weekend off in Iona</cal:summary> <u:uri rdf:resource=".../1001.xhtml#event1" /> <cal:dtstart rdf:datatype=".../XMLSchema#date">2006-10-21</ cal:dtstart> <cal:dtend rdf:datatype="...1/XMLSchema#date">2006-10-23</ cal:dtend> <cal:location>Iona, UK</cal:location> </cal:Vevent> </rdf:RDF> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A89149C9-C7BE-4AA6-9600-1216DDE03F96%40g5n.co.uk Re: telecon today + RDFa Implementation Report update 2008-08-07T23:08:56 2008-08-07T23:08:56 2008-08-07T23:08:56 OK - past midnight now, so time for me to go to bed. I've spent most of this evening fixing RDFa bugs in Cognition. I can now report that Cognition fails only these tests: Technically fail, but visual inspection shows XML literals are close enough: 11, 92, 102, 103, 1001. Deliberately fail because I think my output is better/more useful than the output required by the spec: 93, 99, 108,... OK - past midnight now, so time for me to go to bed. I've spent most of this evening fixing RDFa bugs in Cognition. I can now report that Cognition fails only these tests: Technically fail, but visual inspection shows XML literals are close enough: 11, 92, 102, 103, 1001. Deliberately fail because I think my output is better/more useful than the output required by the spec: 93, 99, 108, 112. Fail because of URI canonicalisation - I'm not going to change Cognition's behaviour - I think the tests should allow for URI canonicalisation: 31, 32. Fail for some unknown reason - Cognition's output looks OK to me - test harness broken perhaps: 104, 1001. Fail because of actual bugs in Cognition which need to be fixed: 94, 100, 101. The other 84(?) tests are green lights. These results are an internal build - not available for download yet, but you can try it online at http://buzzword.org.uk/cognition/. Yay! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EB74376C-4BE0-42E6-89E0-BD49173DBAF0%40g5n.co.uk Re: Test case #31 2008-08-08T08:13:59 2008-08-08T08:13:59 2008-08-08T08:13:59 On 8 Aug 2008, at 08:44, Hausenblas, Michael wrote: > So, the problem I see here now for us is that we don't do any > normalization in the RDFa TC either. I dunno how others feel but there > are basically two options: either we extend ALL the RDFa TC with > alternatives of normalized (like we did with XMLLiteral, e.g. in TC102 > [4]) or we clarify that issue in the syntax. Could this be raised ... On 8 Aug 2008, at 08:44, Hausenblas, Michael wrote: > So, the problem I see here now for us is that we don't do any > normalization in the RDFa TC either. I dunno how others feel but there > are basically two options: either we extend ALL the RDFa TC with > alternatives of normalized (like we did with XMLLiteral, e.g. in TC102 > [4]) or we clarify that issue in the syntax. Could this be raised as an issue with the SPARQL query engines used by the test? Shouldn't *they* realise that <urn:isbn:0752820907> and <urn:ISBN:0752820907> are equivalent? (Perhaps to do so would be a spec violation - I'm not up to speed on all the minute details of SPARQL.) The obvious solution would of course be to not canonicalise URIs in Cognition, but that seems to be done automatically by a third-party Perl module I use to resolve relative URIs, and I don't especially want to abandon that module. And speaking of the XMLLiteral stuff, the examples with SVG would be a bit easier to pass if you removed *one* of the attributes of <rect/ >. (Because in XML the attributes may appear in either order.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/32D3A5C6-2B6B-434B-8E39-DE7AD596CB15%40g5n.co.uk Re: telecon today + RDFa Implementation Report update 2008-08-08T08:38:24 2008-08-08T08:38:24 2008-08-08T08:38:24 On 8 Aug 2008, at 09:14, Hausenblas, Michael wrote: >> Deliberately fail because I think my output is better/more useful >> than the output required by the spec: 93, 99, 108, 112. > > I'm not sure I can follow. Can you be more specific, please? An example, not taken from the test case: <span about="ex:foo" property="ex:bar" datatype="" >The human brain has about 10¹¹ neurons.<... On 8 Aug 2008, at 09:14, Hausenblas, Michael wrote: >> Deliberately fail because I think my output is better/more useful >> than the output required by the spec: 93, 99, 108, 112. > > I'm not sure I can follow. Can you be more specific, please? An example, not taken from the test case: <span about="ex:foo" property="ex:bar" datatype="" >The human brain has about 10¹¹ neurons.</span> The output demanded by rigourous adherence to the spec is: ex:foo ex:bar "The human brain has about 1011 neurons." Cognition's output is: ex:foo ex:bar "The human brain has about 10[11] neurons." which I feel is slightly more useful. (Of course, "^11" might be even better, but that would require some sort of heuristic to determine whether the superscript has been used as an exponent, or a footnote, or as something else entirely.) Basically, Cognition will convert from text/html to text/plain, not through a simple concatenation of text nodes, but in a manner as close as possible to a text browser (like lynx). I know this deviates from the RDFa spec, and I'm not suggesting that the spec change - I'm just saying that I'm happy to be non-conformant in this regard. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/31CBA0B0-35CB-4B1B-B216-408DF5409B58%40g5n.co.uk Re: <script src=javascript:"..."> should do nothing 2008-08-11T13:22:36 2008-08-11T13:22:36 2008-08-11T13:22:36 This is nasty, I know, but what about: <script src="javascript:return 'window.alert(&quot;hello&quot;)';"> </script> i.e. the 'javascript:' URI is executed and returns a string, the string returned is then treated as if it were the contents of the <script> element. Nasty though it is, that seems to be more consistent with how the 'javascript:' protocol is handled in 'href'. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> This is nasty, I know, but what about: <script src="javascript:return 'window.alert(&quot;hello&quot;)';"> </script> i.e. the 'javascript:' URI is executed and returns a string, the string returned is then treated as if it were the contents of the <script> element. Nasty though it is, that seems to be more consistent with how the 'javascript:' protocol is handled in 'href'. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6C320783-107E-434F-96E2-B5ED5E4C1976%40g5n.co.uk N3 bnode question 2008-08-15T10:08:52 2008-08-15T10:08:52 2008-08-15T10:08:52 It seems that in N3, I have two choices for expressing a blank node: :mydoc1 dc:creator [ foaf:name "Toby Inkster" ] . or :mydoc1 dc:creator _:a . _:a foaf:name "Toby Inkster" . My problem is that although the first syntax is more readable (when dealing with a graph with dozens or more bnodes), it doesn't offer a way of referring to the same bnode multiple times. That is, if... It seems that in N3, I have two choices for expressing a blank node: :mydoc1 dc:creator [ foaf:name "Toby Inkster" ] . or :mydoc1 dc:creator _:a . _:a foaf:name "Toby Inkster" . My problem is that although the first syntax is more readable (when dealing with a graph with dozens or more bnodes), it doesn't offer a way of referring to the same bnode multiple times. That is, if I have: :mydoc1 dc:creator [ foaf:name "Toby Inkster" ] . :mydoc2 dc:creator [ foaf:name "Toby Inkster" ] . It cannot be legitimately concluded that mydoc1 and mydoc2 share an author. (Though I can't imagine there are too many other Toby Inksters in the world.) So I've been trying to find some sort of compromise, such that the first bnode can be given an ID and the others made into references back to that ID. rdf:nodeID makes this very easy for RDF/XML, but unless I'm mistaken this solution cannot be leveraged in N3. So my proposed solution is: :mydoc1 dc:creator [ owl:sameAs _:a ; foaf:name "Toby Inkster" ] . :mydoc2 dc:creator _:a . Or is rdf:nodeID allowed in N3? i.e. :mydoc1 dc:creator [ rdf:nodeID _:a ; foaf:name "Toby Inkster" ] . :mydoc2 dc:creator _:a . Is rdf:nodeID allowed to be used like this? If not, is owl:sameAs a good solution to my quandary? Thanks for reading, and thanks even more if you can answer my questions! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8DCC1293-E9CA-4E7B-ADEA-DADE19EC704C%40g5n.co.uk Re: [Bug 5974] New: Language tag sameness should probably be ASCII case-insensitive 2008-08-19T07:54:18 2008-08-19T07:54:18 2008-08-19T07:54:18 Although something like this is clearly a mistake and should not be allowed: <span lang="fr" xml:lang="de"> Isn't the following a little more of a grey area? <span lang="fr-FR" xml:lang="fr"> Might an improved criterion for conformance be: if @lang and @xml:lang are both present, they must be equal, or one must be a substring of the other, matching the head of the longer string. (All c... Although something like this is clearly a mistake and should not be allowed: <span lang="fr" xml:lang="de"> Isn't the following a little more of a grey area? <span lang="fr-FR" xml:lang="fr"> Might an improved criterion for conformance be: if @lang and @xml:lang are both present, they must be equal, or one must be a substring of the other, matching the head of the longer string. (All case insensitive.) When the attributes conform to the previous condition, the longer attribute value is taken to be the language of the element. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E73F2887-6D0F-474B-95EC-463D54A64B4F%40g5n.co.uk Re: RDFa Question, Clarification 2008-08-19T20:13:57 2008-08-19T20:13:57 2008-08-19T20:13:57 Martin McEvoy wrote: > I have over the last year been studying something I have started > calling > Metaformats - Languages that describe other languages, RDFa is a > Metaformat used to primarily describe RDF vocabularies in html. Martin, although RDFa *can* be used to describe RDF vocabularies, that's not its primary purpose. Its primary purpose is, basically, to do what microformats do -... Martin McEvoy wrote: > I have over the last year been studying something I have started > calling > Metaformats - Languages that describe other languages, RDFa is a > Metaformat used to primarily describe RDF vocabularies in html. Martin, although RDFa *can* be used to describe RDF vocabularies, that's not its primary purpose. Its primary purpose is, basically, to do what microformats do - to add semantics to human-readable HTML. Yes, that includes: > <div id="location" typeof="geo" about="#location"> > <span property="latitude" content="53.7552">N 53.7552</span>, > <span property="longitude" content="-2.3675">W -2.3675</span> > </div> <div xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" typeof="geo:Point" id="location" about="#location"> <span property="geo:lat" content="53.7552">N 53.7552</span> <span property="geo:long" content="-2.3675">W -2.3675</span> </div> > <div id="weborganics" typeof="vcard" about="#weborganics"> > <span property="fn">Martin McEvoy</span> > <span rel="photo"> > <img src="http://weborganics.co.uk/site/photo/1/me.jpg" > alt="weborganics"/> > </span> > Contact: <a rel="email" > href="mailto:info@weborganics.co.uk">Email</a> > Web: <a rel="url" > href="http://weborganics.co.uk/">WebOrganics</a> > </div> <div about="#weborganics" id="weborganics" typeof="v:Vcard" xmlns:v="http://www.w3.org/2006/vcard/ns#"> <span property="v:fn">Martin McEvoy</span> <img src="http://weborganics.co.uk/site/photo/1/me.jpg" alt="weborganics" rel="v:photo" /> Contact: <a rel="v:email" href="mailto:info@weborganics.co.uk">Email</a> Web: <a rel="v:url" href="http://weborganics.co.uk">WebOrganics</a> </div> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C590BFEF-87FB-47AF-A7A4-D1B9B2B2D250%40g5n.co.uk Re: RDFa Question, Clarification 2008-08-20T14:31:43 2008-08-20T14:31:43 2008-08-20T14:31:43 On 20 Aug 2008, at 13:48, Martin McEvoy wrote: > What I mean Is I DON'T want to reference ANY namespaces. Technically RDFa doesn't use namespaces, but uses prefixes, but for the purposes of this discussion, the two are close enough to be used interchangeably. Theoretically, RDFa does allow for the use of unprefixed terms, which get treated as belonging to the "default prefix". However, on... On 20 Aug 2008, at 13:48, Martin McEvoy wrote: > What I mean Is I DON'T want to reference ANY namespaces. Technically RDFa doesn't use namespaces, but uses prefixes, but for the purposes of this discussion, the two are close enough to be used interchangeably. Theoretically, RDFa does allow for the use of unprefixed terms, which get treated as belonging to the "default prefix". However, only a small set of terms (basically the union of the link types defined in HTML 4.01 and XHTML 2) are defined in the default default prefix. Yes, I did use "default default" deliberately in the last sentence, because theoretically if you could point the default prefix to somewhere other than its default URI, then you could create your own unprefixed terms. But RDFa does not define a method for changing the default prefix, so you're stuck with the default default prefix. Perhaps the editors of a future version of RDFa may add a method for authors to change the default prefix, but if that were to happen, it would be a long way down the line. > The reason why I ask this question Is because In the Microformats > Community one of the FIRST thing's that you learn is that > Namespaces for Content has failed and should be avoided, so much > so that even discussing namespaces in Microformats is a "Taboo" > subject. > > see: http://microformats.org/wiki/namespaces-considered-harmful I think you'll find that the opinions found on that page are far from unanimously held, even within the microformats community, let alone the semantic web community as a whole. Namespaces would have made the "title" debate surrounding hAudio a non-issue, but alas namespaces were ruled out of microformats at a very early stage and seem unlikely to make a return. Even if RDFa could be used without prefixes (and indeed it can if the only relationships you wish to describe are those from the HTML/XHTML predefined link types), there is still the bigger issue that the RDFa attributes are not valid in legacy HTML 4.01 and XHTML 1.0. Any time a proposal that does not validate against one of those recommendations is raised on uf-discuss it is shot down pretty quickly. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/15C19A4D-16B7-4220-A44F-4A74339BD2A3%40g5n.co.uk Re: RDFa in HTML 4 2008-08-22T19:59:33 2008-08-22T19:59:33 2008-08-22T19:59:33 Ivan Herman <ivan@w3.org> wrote: > I actually have, in my implementation, an optional feature that > implements exactly that, but with the attribute name @prefix (same > keyword as the one used in SPARQL or turtle...) I've implemented this in Cognition now. (It's not in the 0.1-alpha12 download, but is in the current live web service and will be in the next download.) The syntax I'm using is... Ivan Herman <ivan@w3.org> wrote: > I actually have, in my implementation, an optional feature that > implements exactly that, but with the attribute name @prefix (same > keyword as the one used in SPARQL or turtle...) I've implemented this in Cognition now. (It's not in the 0.1-alpha12 download, but is in the current live web service and will be in the next download.) The syntax I'm using is: prefix="pref1=someURI pref2=someOtherURI" The prefix definitions can be separated by any amount of white space. Is this roughly compatible with your implementation? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/ACB41AFF-7235-465F-9189-7F59A4C79A75%40tobyinkster.co.uk Re: Ubiquity 2008-08-27T20:46:53 2008-08-27T20:46:53 2008-08-27T20:46:53 Martin McEvoy wrote: > Me too :-) > > so much so Transformr has Ubiquity Commands after subscribing to the > commands try "get-rdfa" And I've gone and copied you. ;-) http://srv.buzzword.org.uk/ Just early work. I'm sure with the Javascript RDFa parser a lot more fun is to be had. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Martin McEvoy wrote: > Me too :-) > > so much so Transformr has Ubiquity Commands after subscribing to the > commands try "get-rdfa" And I've gone and copied you. ;-) http://srv.buzzword.org.uk/ Just early work. I'm sure with the Javascript RDFa parser a lot more fun is to be had. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BB2FE166-8D66-487D-A6C6-C43E4E48E7EA%40g5n.co.uk Re: Ubiquity 2008-08-28T09:45:36 2008-08-28T09:45:36 2008-08-28T09:45:36 [Sent this last night, but forgot to use my special W3C-approved e- mail address, so it didn't go through. The W3C list software doesn't like my usual e-mail address because it thinks I am an SMTP daemon!] Martin McEvoy wrote: > Me too :-) > > so much so Transformr has Ubiquity Commands after subscribing to the > commands try "get-rdfa" And I've gone and copied you. ;-) http://srv.buzzword.org.uk/ Just early work. I'm sure with the Javascript RDFa parser a lot more fun is to be had. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> [Sent this last night, but forgot to use my special W3C-approved e- mail address, so it didn't go through. The W3C list software doesn't like my usual e-mail address because it thinks I am an SMTP daemon!] Martin McEvoy wrote: > Me too :-) > > so much so Transformr has Ubiquity Commands after subscribing to the > commands try "get-rdfa" And I've gone and copied you. ;-) http://srv.buzzword.org.uk/ Just early work. I'm sure with the Javascript RDFa parser a lot more fun is to be had. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/2BA55ED7-5BA2-4640-AD9A-71BF18925995%40g5n.co.uk Re: RDFa generalization - expressing Microformats 2008-09-02T09:38:11 2008-09-02T09:38:11 2008-09-02T09:38:11 > <body prefix="uf=http://microformats.org/vocab#"> > > <div typeof="haudio"> > <span property="title">Start Wearing Purple</span> by > <span property="contributor">Gogol Bordello</span> > <span property="published" content="20020514">May 14th, 2002</span> > </div> > > </body> Why not just use something like this: prefix="=http://microformats.org/vocab#" (Yes, that value intention... > <body prefix="uf=http://microformats.org/vocab#"> > > <div typeof="haudio"> > <span property="title">Start Wearing Purple</span> by > <span property="contributor">Gogol Bordello</span> > <span property="published" content="20020514">May 14th, 2002</span> > </div> > > </body> Why not just use something like this: prefix="=http://microformats.org/vocab#" (Yes, that value intentionally starts with an equals sign.) That way you're saying that all unprefixes values come from that vocab - there is no need for the vocab document to define all those "xhv:reserved" triples. So for example, for the following HTML: <body prefix="=http://microformats.org/vocab# dc=http://purl.org/dc/terms/"> <div typeof="haudio"> <span property="title dc:title">Start Wearing Purple</span> by <span property="contributor">Gogol Bordello</span> <span property="published" content="20020514">May 14th, 2002</span> </div> </body> The parser would see the <body> element and become aware that two CURIE prefixes have been defined - "dc" and a default prefix. Then it hits the <div> element and sees the typeof attribute. This contains a unprefixed value, so the default prefix is used and expands to: _:bnode0 a <http://microformats.org/vocab#haudio>. Then the parser hits the first <span> and sees to properties: "title" belonging to the default prefix, and "dc:title" which clearly has the "dc" prefix so creates two triples: _:bnode0 <http://microformats.org/vocab#title> "Start Wearing Purple" ; <http://purl.org/dc/title> "Start Wearing Purple" . (/me wishes turtle had a shorthand for situations like this: two triples which share a subject and object.) That way the RDFa parser has no need to download and parse the vocabulary document. Instead it uses the simple rule that all unprefixed terms belong to the default prefix, and the default prefix may be defined in the same way as other prefixes using prefix="pfx=uri" but by having "pfx" set to the empty string. If no default prefix is defined, then a default default prefix of <http:// www.w3.org/1999/xhtml/vocab#> is assumed. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EBFEE449-FF5D-45A0-AC37-116D6DA530F9%40g5n.co.uk Re: RDFa generalization - expressing Microformats 2008-09-02T16:08:41 2008-09-02T16:08:41 2008-09-02T16:08:41 > It's ugly and not necessary, it will also confuse web authors. OK, the leading equals is dropped from my proposal. > prefix="http://microformats.org/vocab# http://vocabs-r-us.org/vocab#" > > The example above defines two documents that both contain unprefixed > reserved values. We wouldn't know which prefix to use in this case. Well, yes, the disadvantage of my proposal is that there can onl... > It's ugly and not necessary, it will also confuse web authors. OK, the leading equals is dropped from my proposal. > prefix="http://microformats.org/vocab# http://vocabs-r-us.org/vocab#" > > The example above defines two documents that both contain unprefixed > reserved values. We wouldn't know which prefix to use in this case. Well, yes, the disadvantage of my proposal is that there can only be a single unprefixed vocabulary. However, that particular cloud has a silver lining: it eliminates the prospect of collisions between multiple vocabularies. Of course, two different vocabs could be mixed like this: <body prefix="http://microformats.org/vocab#"> <div typeof="hcard"> ... </div> <div typeof="hfoo" prefix="http://vocabs-r-us.org/vocab#"> ... </div> </body> Another advantage of mine is that I could choose to use, say Dublin Core or FOAF as my unprefixed vocabulary, but if you wanted to do the same under your proposed scheme, you'd have to wait for the DCMI organisation or Dan Brickley to add a bunch of "xhv:reserved" triples to their RDF schemas, which they may or may not be willing to do. So to summarise, my proposal compared to yours/Shane's: disadvantages :- * can't mix and match unprefixed vocabs. advantages :- * can still mix and match vocabs, but must give all but one of them a CURIE prefix, or use prefix="" attributes scattered throughout the DOM tree. * does not require parsers to download external files - saves bandwidth - saves time - allows off-line use - simplifies parsers (they don't need to speak HTTP) * avoids vocab collisions. * can be used with existing RDF vocabs such as FOAF, Dublin Core, SIOC, DOAP, etc without requiring their maintainers to modify their schemas. * can be used with non-dereferencable vocab URIs (e.g. URNs) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/08C6CDCB-9F65-49F8-8C27-8EB2FC7E871F%40g5n.co.uk Re: RDFa generalization - expressing Microformats 2008-09-03T08:52:11 2008-09-03T08:52:11 2008-09-03T08:52:11 Manu Sporny wrote: > Collisions between multiple vocabularies that express reserved > words is > easy to deal with - the last reserved word expressed, wins. That's the opposite way round from XMDP. But anyway, say I use: <body prefix="http://microformats.org/vocab# http://vocabs-r-us.org/vocab#"> <div typeof="vcard">...</div> </body> This works fine for... Manu Sporny wrote: > Collisions between multiple vocabularies that express reserved > words is > easy to deal with - the last reserved word expressed, wins. That's the opposite way round from XMDP. But anyway, say I use: <body prefix="http://microformats.org/vocab# http://vocabs-r-us.org/vocab#"> <div typeof="vcard">...</div> </body> This works fine for a week, maybe a month, and then vocabs-r-us.org updates their vocabulary adding a few new terms which conflict with microformats.org terms; vocabs-r-us.org terms are last, so win; and my hCards stop working. OK, that's unlikely with a fairly unique term like "vcard", but Microformats do make use of some less unique terms like "role", "description", "summary", "title", "class", "category", "contact", "label", "key", "item", "note", "type", "value" and "version". The only way to avoid unintentional collisions when vocabs are updated is to have a sort of "central clearing house" system so that microformats.org, and vocabs-r-us.org, and vocabs4u.net or whatever all co-ordinate their efforts to avoid collisions. But that's precisely the sort of centralised un-web-like system that RDFa (and RDF in general) was designed to avoid. If you only allow a single vocab to be the "anointed one" (i.e. to be unprefixed), without depending on the vocab documents themselves for anything, this makes it very clear to the author which vocab he's using when he uses an unprefixed term; and he can be confident that any changes that are made to the vocabs (which are probably out of his control) will not change the meaning of his page. This idea will also be familiar to people who have used XML namespaces or RDF/XML, where for any given node, there can be at most one namespace which is usable without prefixes. We wouldn't be inventing anything new: just applying an old idea — that of the default namespace — to RDF. > What about when the author wants one set of reserved words to shadow > another set of reserved words? For example, "I want to use Dublin > Core's > 'title', not Microformat's 'title'". They'd just assign a non-blank prefix to Dublin Core, and use that. A similar question could be applied to your proposal - what happens if I want to use Dublin Core's "title", but hAudio's "contributor". What prefix attribute should I use? <body prefix="http://microformats.org/vocab# http://purl.org/dc/terms/"> <!-- This won't work as Dublin Core contributor wins over hAudio --> <body prefix="http://purl.org/dc/terms/ http://microformats.org/vocab#"> <!-- This won't work as Microformats title wins over Dublin Core --> The solution is to only allow one vocab to be used for unprefixed terms: <body prefix="http://microformats.org/vocab# dc=http://purl.org/dc/ terms/"> > Not true, you could create your own vocabulary document [to define > unprefixed terms for Dublin Core] But if I do that, then I'm using: <body prefix="http://example.com/my-own-document.html"> And the prefix attribute no longer reflects the actual CURIE prefix that I intend to use (i.e. http://purl.org/dc/terms/) In my proposal, the author can just write: <div prefix="http://purl.org/dc/terms/"> And then all unprefixed CURIEs within that <div> will be from Dublin Core. Not only is this easier than having to create my own DC-to- CURIE mapping document, it is also easier for other authors who come across my page later — they can easily spot the well known and popular Dublin Core URI in the code, and don't need to follow their nose (though of course, they can) to find out what metadata vocab I'm using. > This is not a safe assumption to make because it automatically voids > all of the XHTML reserved words. This is still an open question with my proposal, but not a show stopper. The question is, if an author has defined a default CURIE prefix, and uses rel="license" or another RDFa reserved word, which "wins": the author-defined default prefix, or xhv? Just how "special" is xhv? I don't have any strong feelings either way. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/DFE64301-A333-43A0-82E9-CB7A1C06C64D%40g5n.co.uk Re: profile attribute and conformance [was: Comparing conformance requirements against real-world docs] 2008-09-05T08:44:48 2008-09-05T08:44:48 2008-09-05T08:44:48 Henri Sivonen wrote: > It's interesting to see what preferences (i.e. unresolved arguments) > the tool offers. As author of said tool, I thought I'd weigh in. > Only Strict eRDF is checked by default. "Strict Microformats" and > "Strict GRDDL" mean that the tool forces itself to not recognize class > and rel values if there's no profile URI. Since these are not checked > by default, the develop... Henri Sivonen wrote: > It's interesting to see what preferences (i.e. unresolved arguments) > the tool offers. As author of said tool, I thought I'd weigh in. > Only Strict eRDF is checked by default. "Strict Microformats" and > "Strict GRDDL" mean that the tool forces itself to not recognize class > and rel values if there's no profile URI. Since these are not checked > by default, the developer of the tool has to have concluded that it's > more useful for users of the tool to ignore the profile URI. Don't read too much into that. Consider it an application of Postel's law - being liberal in what I accept from others. The eRDF strictness option is on by default because applying eRDF parsing to pages which haven't been authored with eRDF in mind tends to generate junk. With the strict option enabled, it won't parse eRDF unless it sees the eRDF profile - i.e. the author has opted in. > Also note that actually dereferencing profile URIs for GRDDL discovery > is off by default because it is slow with two exclamation points. For the majority of pages in the wild, Cognition does not need GRDDL. It has built-in support for hCard, hCalendar, XFN and a bunch of other microformats, including experimental support for a number of drafts from the microformats Wiki. If you enable GRDDL and your page provides GRDDL profiles for each microformat you use, then all the microformats on your page are parsed twice (the first time using reasonably fast built-in functions, and the second time using the slower GRDDL process) for no additional benefit. That's why it's off by default. However, if you use a "microformat"[1] that Cognition doesn't have built-in support for - say you've invented your own "hWine" format for marking up your bottle collection - then providing a GRDDL profile, and enabling GRDDL when parsing will allow your data to be parsed, and thereafter used in the same ways that Cognition would be able to use it if it did have built-in support. Overall, a method for pages to link to metadata profiles is needed by HTML. Whether it is head@profile or rel="profile" (or something else entirely) doesn't really matter as far as I'm concerned. That said, from what I can tell, the suggested change from head@profile to rel="profile" appears to be gratuitous "change for the sake of change". I don't see why HTML5 should break existing pages, specifications and tools that use head@profile. ____ 1. I include this term in quotation marks because here I'm mostly referring to formats developed outside the microformats.org community, but labelled "microformats" by their creators. Every time one of these is labelled a "microformat", Tantek turns in his whatever it is that people turn in when they haven't died. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AE03E48E-86E6-4A8C-86AA-ADEDC782AD58%40g5n.co.uk Empty @typeof 2008-09-07T09:30:39 2008-09-07T09:30:39 2008-09-07T09:30:39 What is the meaning of this? <div about="#foo"> <div typeof=""> <span property="dc:title">xyzzy</span> </div> </div> Is "xyzzy" the title of "#foo" or the title of a BNode created by the second <div>? Step #4 and #5 in the processing sequence say "if @typeof is present" then typeof sets a new subject. However, step #6 says of @typeof: "if present, the attribute must... What is the meaning of this? <div about="#foo"> <div typeof=""> <span property="dc:title">xyzzy</span> </div> </div> Is "xyzzy" the title of "#foo" or the title of a BNode created by the second <div>? Step #4 and #5 in the processing sequence say "if @typeof is present" then typeof sets a new subject. However, step #6 says of @typeof: "if present, the attribute must contain one or more URIs" (i.e. not zero or more). Can an empty typeof set a new subject, or is it invalid and thus ignored? It would be nice if the syntax document could be clarified. Yes, I know it would be helpful if I'd raised this issue before RDFa reached PR stage, but I've only just noticed it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9BE4D953-B07D-4FF8-BC36-ACE5144A8DEF%40g5n.co.uk Re: Empty @typeof 2008-09-07T19:40:22 2008-09-07T19:40:22 2008-09-07T19:40:22 On 7 Sep 2008, at 18:36, Micah Dubinko wrote: > My impl produces this: > _:bnode dc:title "xyzzy" Ditto. > Which I think might actually be right. I think this is probably the most useful interpretation, even if the spec does not seem entirely clear on this issue. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 7 Sep 2008, at 18:36, Micah Dubinko wrote: > My impl produces this: > _:bnode dc:title "xyzzy" Ditto. > Which I think might actually be right. I think this is probably the most useful interpretation, even if the spec does not seem entirely clear on this issue. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B86DB379-07DD-41AE-8400-C8E5A1D5738B%40g5n.co.uk Re: profile attribute and conformance [was: Comparing conformance requirements against real-world docs] 2008-09-08T08:20:04 2008-09-08T08:20:04 2008-09-08T08:20:04 On 7 Sep 2008, at 14:20, Henri Sivonen wrote: > * A prominent (the most prominent?) microformat-to-RDF converter > ignores profile for microformats and rel=transform by default, so > authors can have their stuff consumed even without the profile. Just because the profile is not required, it does not mean that it is ignored. e.g. for parsing XFN <http://gmpg.org/xfn/>, the profile (if su... On 7 Sep 2008, at 14:20, Henri Sivonen wrote: > * A prominent (the most prominent?) microformat-to-RDF converter > ignores profile for microformats and rel=transform by default, so > authors can have their stuff consumed even without the profile. Just because the profile is not required, it does not mean that it is ignored. e.g. for parsing XFN <http://gmpg.org/xfn/>, the profile (if supplied) is may be used to determine which version of XFN (1.0 or 1.1) is in use. XFN 1.1 defines a handful of additional terms over XFN 1.0 including rel=contact, which was (until recently) in conflict with the definition of rel=contact in HTML5 - so there was (until recently) a very important reason to differentiate between XFN 1.0 and XFN 1.1. Conflicts in naming schemes pop up all the time (look at Twitter's hCards). Profiles offer a means to disambiguate. > Given that you are doing what you are doing (regardless of *why* > you are doing it), what incentive is there for authors to use > profile? What do they gain if they use it? What incentive is there > for the users of your software to change the default settings? What incentive is there for authors to validate against HTML 4.01 Strict instead of HTML 4.01 Transitional? A warm fuzzy feeling certainly, but it's more than that. While Cognition gets robustness from following the second part of Postel's Law ("be liberal in what you accept from others"), authors get their robustness from following the first part ("be conservative in what you do"). > Have you analyzed your logs to see if your users do change the > defaults often? Just over 20% seem to. I've not checked which defaults are changed most often. >> Overall, a method for pages to link to metadata profiles is needed >> by HTML. > > How does this follow? Follow from what you quoted? It doesn't. From what you quoted, a profile mechanism is potentially useful, but far from necessary. It follows from what you snipped: > However, if you use a "microformat"[1] that Cognition doesn't have > built-in support for - say you've invented your own "hWine" format > for marking up your bottle collection - then providing a GRDDL > profile, and enabling GRDDL when parsing will allow your data to be > parsed, and thereafter used in the same ways that Cognition would > be able to use it if it did have built-in support. Basically, if you create your own "microformat"[1], thanks to profiles and GRDDL, you don't need to beg and plead parser programmers to implement support for it - any GRDDL parser (of which Cognition is one) will automatically start picking it up. Are there alternative ways HTML5 could implement profiles other than <head profile>? Yes, of course. But does it make sense to replace one profile mechanism, with dozens of implementations and used by millions of pages, with a different one (rel="profile")? Perhaps, but I'm not convinced by the arguments I've seen so far. Replacing <head profile> with rel="profile" is feasible in the same sense that replacing <style> with <script type="text/css"> would be feasible. Fairly easy changes to make as far as implementations are concerned, yet utterly pointless. Why change an existing mechanism unless there are real benefits to be had? ____ 1. Footnote in http://www.w3.org/mid/DFE64301-A333-43A0-82E9- CB7A1C06C64D@g5n.co.uk -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EA5B6017-DDB1-4213-8CEB-CB711324671B%40g5n.co.uk Re: Comments on PR-rdfa-syntax-20080904 2008-09-11T07:46:30 2008-09-11T07:46:30 2008-09-11T07:46:30 Danny Ayers wrote: > > The primer is aimed mainly at authors, whilst this document is aimed > > primarily at implementers. The general feeling is that the RDFa spec > > should be self-contained, and provide everything that an implementer > > needs to produce an XHTML+RDFa processor. > > Reasonable aim. For what it's worth, I think the syntax document does fulfil that aim. Juts using the syntax... Danny Ayers wrote: > > The primer is aimed mainly at authors, whilst this document is aimed > > primarily at implementers. The general feeling is that the RDFa spec > > should be self-contained, and provide everything that an implementer > > needs to produce an XHTML+RDFa processor. > > Reasonable aim. For what it's worth, I think the syntax document does fulfil that aim. Juts using the syntax document and test cases as my guide, I've been able to produce a mostly compliant implementation. (The majority of my non-compliance issues are whitespace and XMLLiteral stuff, which I do hope to fix eventually, but not at a high priority.) > I don't see any problem with X triples generated by the RDFa processor > and Y triples generated by the GRDDL processor being analyzed > separately for conformance purposes, yet both being part of the graph > expressed by the document. If this doesn't convince you, I'll do my > best to make the case better. For what it's worth, in Cognition although the RDFa *module* produces only the triples specified in the syntax doc, various other modules (for GRDDL, microformats, document structure, eRDF, etc) produce other triples and they all go into the same triple store. You can't then retrieve a specific graph of just the RDFa triples, or just the GRDDL triples. (Though when you run it, you can pass command-line options to disable and enable modules, so you could disable all modules except RDFa, and get just the RDFa triples that way.) > > The general point is that as we refined the spec, we always ensured > > that nothing we did would jeopardise the consistent use of the same > > rules in other markup languages. > > XML markup, even HTML5...but httpd log files? It's a bit of a stretch to call httpd log files "markup", isn't it? RDFa can be applied to any markup language that provides a tree-like node structure such that each node can take named string properties akin to HTML/XML attributes. That could be XML or HTML, but also JSON, in-memory C data structures, appropriately structured SQL database tables and so forth. (I'm half tempted to implement an RDFa parser for JSON as proof-of-concept.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/90C5C91A-59BF-4BA8-A55A-4566ADC640B0%40tobyinkster.co.uk Re: RDFa and Microformats 2008-09-12T05:47:41 2008-09-12T05:47:41 2008-09-12T05:47:41 Martin McEvoy wrote: > My response would have been *If* the RDFa community decided that > Microformats are expressing semantics( which is Acknowledged ) and > should be somehow ported to RDFa, Microformats do this using mainly > using just Class attributes If you are going to "bring them to the > fold" > @class should be added to RDFa as one of its properties. I think you'll find it's actuall... Martin McEvoy wrote: > My response would have been *If* the RDFa community decided that > Microformats are expressing semantics( which is Acknowledged ) and > should be somehow ported to RDFa, Microformats do this using mainly > using just Class attributes If you are going to "bring them to the > fold" > @class should be added to RDFa as one of its properties. I think you'll find it's actually a lot more complicated than that. Firstly, in microformats different classes have entirely different parsing models. In hCard for instance: vcard = Look inside for properties. fn = Use the contents as the property. url = Ignore contents, use the link. tel = Look inside for class="type" and class="value". There are all kinds of special cases. Even in hAudio, which you've had a part in designing, and I think is certainly one of the better authored microformat specs, there are some parsing oddities. i.e. figuring out the type of audio being described (is it an album, is it a recording, or is it a track on an album) requires looking for the presence of two different properties and deciding based on the combination of which exist; rel=tag is handled differently from other microformats that use rel=tag (in hAudio the node contents are used, in others the URL is used); item opacity and propagation of values from parent to child item; etc. Adding all these rules to the RDFa specification would massively bloat it. Parsing existing microformats as part of the RDFa parsing model would be massively complicated. And despite the fact that class names are often re-used by new microformats, this would not help parsing future microformats unless the mfo/hroot question were to be resolved. Such an endeavour would not only be bad for RDFa, but would seriously constrain the future direction of microformats too. > All existing Microformated pages, > Millions of them, could then potentially become part of RDFa in that > way almost instantly and So Supporting Microformats in the best way > and > not *breaking* them. RDFa is "just" a representation of RDF. And microformats can already be parsed as RDF - that's the point of GRDDL. Despite the fact that XSLT is a horrible, horrible abomination, I think that GRDDL, not RDFa, is probably the best hope for bringing microformats into the "upper case Semantic Web". I believe Microformats and RDFa can happily co-exist. They both have different syntaxes, but once you've converted them both to the abstract RDF model, you can use pretty simple rules to combine the data from each. The aim to strive towards should be: different syntaxes, separate parsing models, but at the end one data model. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/0ADE144A-5BA1-41AF-A155-2F119E7951B1%40g5n.co.uk Re: RDFa and Microformats 2008-09-12T09:46:17 2008-09-12T09:46:17 2008-09-12T09:46:17 Martin McEvoy wrote: > My response would have been *If* the RDFa community decided that > Microformats are expressing semantics( which is Acknowledged ) and > should be somehow ported to RDFa, Microformats do this using mainly > using just Class attributes If you are going to "bring them to the > fold" > @class should be added to RDFa as one of its properties. I think you'll find it's actuall... Martin McEvoy wrote: > My response would have been *If* the RDFa community decided that > Microformats are expressing semantics( which is Acknowledged ) and > should be somehow ported to RDFa, Microformats do this using mainly > using just Class attributes If you are going to "bring them to the > fold" > @class should be added to RDFa as one of its properties. I think you'll find it's actually a lot more complicated than that. Firstly, in microformats different classes have entirely different parsing models. In hCard for instance: vcard = Look inside for properties. fn = Use the contents as the property. url = Ignore contents, use the link. tel = Look inside for class="type" and class="value". There are all kinds of special cases. Even in hAudio, which you've had a part in designing, and I think is certainly one of the better authored microformat specs, there are some parsing oddities. i.e. figuring out the type of audio being described (is it an album, is it a recording, or is it a track on an album) requires looking for the presence of two different properties and deciding based on the combination of which exist; rel=tag is handled differently from other microformats that use rel=tag (in hAudio the node contents are used, in others the URL is used); item opacity and propagation of values from parent to child item; etc. Adding all these rules to the RDFa specification would massively bloat it. Parsing existing microformats as part of the RDFa parsing model would be massively complicated. And despite the fact that class names are often re-used by new microformats, this would not help parsing future microformats unless the mfo/hroot question were to be resolved. Such an endeavour would not only be bad for RDFa, but would seriously constrain the future direction of microformats too. > All existing Microformated pages, > Millions of them, could then potentially become part of RDFa in that > way almost instantly and So Supporting Microformats in the best way > and > not *breaking* them. RDFa is "just" a representation of RDF. And microformats can already be parsed as RDF - that's the point of GRDDL. Despite the fact that XSLT is a horrible, horrible abomination, I think that GRDDL, not RDFa, is probably the best hope for bringing microformats into the "upper case Semantic Web". I believe Microformats and RDFa can happily co-exist. They both have different syntaxes, but once you've converted them both to the abstract RDF model, you can use pretty simple rules to combine the data from each. The aim to strive towards should be: different syntaxes, separate parsing models, but at the end one data model. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/95D92668-5A84-422F-98FE-502E0C398D9E%40g5n.co.uk Re: RDFa and Microformats 2008-09-12T23:00:36 2008-09-12T23:00:36 2008-09-12T23:00:36 On 12 Sep 2008, at 10:46, Toby A Inkster wrote: > RDFa is "just" a representation of RDF. And microformats can > already be parsed as RDF - that's the point of GRDDL. Despite the > fact that XSLT is a horrible, horrible abomination, I think that > GRDDL, not RDFa, is probably the best hope for bringing > microformats into the "upper case Semantic Web". To clarify my point, I'm not saying... On 12 Sep 2008, at 10:46, Toby A Inkster wrote: > RDFa is "just" a representation of RDF. And microformats can > already be parsed as RDF - that's the point of GRDDL. Despite the > fact that XSLT is a horrible, horrible abomination, I think that > GRDDL, not RDFa, is probably the best hope for bringing > microformats into the "upper case Semantic Web". To clarify my point, I'm not saying that I think that Microformats +GRDDL are the best way forward for the semantic web. I think RDFa is great, and would recommend it as the first option to consider if you want to add semantics to web pages. What I mean is that for those existing pages that are already using Microformats, and indeed future pages that will be written with Microformats, I think GRDDL represents the best way to pull that data into the upper case Semantic Web - bloating RDFa with algorithms to parse all existing Microformats would be a mistake. Indeed, the guidelines on how to parse existing Microformats right now are far from comprehensive - some areas are extremely murky and grey. > this is a new model (inheritance design pattern) used in only > haudio at the moment so its experimental I'm not sure it works though? It works - I've implemented it. It is a great boon for hAudio - if you're describing an album, you don't want to have to re-list the contributors for every single track - you want them to be able to be inherited from the album. Though hAudio gives you the flexibility to be able to list track-specific contributors too, which is good. But what's good and useful for hAudio is less useful in the general case for other formats. With microformat parsing rules like this being defined specifically for each microformat, and indeed each property, microformats are able to hone themselves to be perfectly designed and beautifully compact formats for their own particular topic. But it also means that writing a universal parsing algorithm for all microformats is virtually impossible. Even if you manage to cover all the special cases in current formats, new formats may introduce other interesting (and useful in their particular case!) nuances. So you have a choice between three possibilities: 1. You choose to write your algorithm for current microformats and resign yourself to the fact that it won't cope with future microformats; 2. You write your algorithm for current microformats and update it every few months; or 3. You write your algorithm for current microformats, and then constrain the development of future formats so that they must work with the existing algorithm. Given that RDFa is trying to be fairly universal and allow virtually any data to be represented, #1 is out of the option. #2 is also out of the question, as RDFa is supposed to be a fairly stable specification. #3 would be a great shame as you'd miss out on one of the best thing about microformats - the fact that each has tonnes of useful shortcuts for publishers. If RDFa and Microformats can be brought closer together, then that's great, but we shouldn't compromise RDFa's simple, predictable processing model, nor the great flexibility of microformarts. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/995C0D35-5B77-44CF-B03A-788A34B4C20D%40g5n.co.uk Re: RDFa and Microformats 2008-09-14T09:14:35 2008-09-14T09:14:35 2008-09-14T09:14:35 On 13 Sep 2008, at 22:18, Martin McEvoy wrote: > Ben Adida wrote: >> Are you a W3C member by any chance? > No I am afraid not, too much of an expense for me, that's why I > tend to dedicate most of my time to voluntary communities, One day > when I can afford the expense :-) Ditto. It would be nice if the W3C had an "associate membership" or somesuch, more suitable and affordable for indi... On 13 Sep 2008, at 22:18, Martin McEvoy wrote: > Ben Adida wrote: >> Are you a W3C member by any chance? > No I am afraid not, too much of an expense for me, that's why I > tend to dedicate most of my time to voluntary communities, One day > when I can afford the expense :-) Ditto. It would be nice if the W3C had an "associate membership" or somesuch, more suitable and affordable for individuals, as the current membership system is very much designed for organisations. Many working groups and task forces are quite open - the RDFa task force is a good example - but it would be good if individuals could participate on a more level playing field, independently of whatever organisation that happened to be affiliated with at the time. > Yes and the goodness of GRDDL, In fact I am beginning to believe > that Microformats And RDFa are not well suited at all and the whole > idea was and Interesting but pointless discussion. This I think is > because Both Microformats and RDFa use GRDDL profiles, One or two > GRDDL applications Redland, ARC that I know of Parse hCards by > default without using a transformation link, just using the data- > view profile see: http://librdf.org/parse?language=grddl&uri=http:// > weborganics.co.uk/demo/hcard.xhtml, Yep, under GRDDL it's allowed for the parser to have some transformations that it will run, even when they are not specified on the page. This is analogous to "user style sheets" in CSS. > so what if I were to mix that with some RDFa, see: http:// > librdf.org/parse?language=grddl&uri=http://weborganics.co.uk/demo/ > hcard-RDFa.xhtml, Triples are repeating themselves but in different > contexts, thats not exactly a defining "meaning", It only brings > myself to ask Why use RDFa in my markup when Microformats are easier? Firstly in RDF, repeated triples are not usually considered significant. e.g. _:toby foaf:name "Toby Inkster" ; foaf:name "Toby Inkster" . is fine. Superfluous maybe, but a decent RDF triple store will probably just compact them into one anyway. Why use RDFa when microformats are easier? In many simple situations, yes, microformats are easier, and there is no need to use RDFa instead/as well. But while there are just a handful of microformats, representing contacts, places, events, etc, RDFa is able to represent far more. For example, hAudio may well allow you to represent a few albums. But with RDFa, you could not only mark up the albums, but also include triples to indicate that Martin McEvoy owns this album or that album, and another album is on Martin's wishlist, etc. > Thank you for confirming That small issue up for me... I never did > get to the bottom of it, Do you not think RDFa could be used to > extract Atom, RSS2 or even XSPF, I do , its fairly easy with a > little xslt in fact I believe that Its actually easier to perform > XSL transformations on RDFa because of the "extra" properties and > their very precise meanings, While RDFa is used to encode RDF in (X)(HT)ML, you have to remember that RDF is itself not a specific format, but rather a generic knowledge representation system. Theoretically, any information whatsoever can be represented that way. Once you've extracted the triples from RDFa, the information does not need to be output as RDF, but could be output as Atom, vCard, iCalendar, whatever. Indeed, this is what Cognition already does. Basically, if Cognition saw this hCard: <div class="vcard"> <a href="http://tobyinkster.co.uk" class="url fn">Toby Inkster</a> </div> it would convert it to the following RDF: _:x a vcard:Vcard ; vcard:fn "Toby Inkster" ; vcard:url <http://tobyinkster.co.uk> . Similarly if it saw this RDFa: <a typeof="foaf:Person" rel="foaf:page" href="http://tobyinkster.co.uk" property="foaf:name">Toby Inkster</a> It would produce these RDF triples: _:x a foaf:Person ; foaf:name "Toby Inkster" ; foaf:page <http://tobyinkster.co.uk> . When you ask Cognition to provide a vCard, it doesn't just convert straight from hCard - instead it goes through its triple store looking for anything which is a "foaf:Person" *or* a "vcard:Vcard" (or a pim:Male or a pim:Female, etc). And in both cases, identical vCards would be produced: BEGIN:VCARD FN:Toby Inkster URL:http://tobyinkster.co.uk END:VCARD (Actually, there would probably be some minor differences in the vCards, but the key information as above would be there.) The key when converting RDFa to vCard is simply to convert RDFa to RDF and then RDF to vCard. For another practical application of converting RDFa to an interesting format, see <http://buzzword.org.uk/2008/audio/> in which both the hAudio microformat, and RDFa are converted to the M3U playlist format. > No I do see that, Using Microformats as an example was probably a > bad idea, which seems to have caused some confusion....lets just > drop it :-) > > I will say I dont believe the RDFa Syntax should be limited to RDF > when it can be so much more, it CAN be a Generic Syntax to Describe > Semantics, not Limited to RDF... But RDF *is* a generic syntax to describe semantics. And because RDFa is an encoding of RDF in HTML, it also *is* a generic syntax to describe semantics. What semantics do you think cannot be encoded in RDF (and thus RDFa)? > That again is a rant, Mainly at the would be publishers of RDFa, Do > you really think that commercial publishers are not going to > exploit RDFa and not build walled gardens and be anti-social? This > suggested to me by an SEO I know, The idea is that every website > that he builds for his clients ARE going to exist in its OWN > namespace He believes this will Increase the Page Rank of all his > sites because the underlying "Meaning" is unique to the site.. it > goes a bit further that it basically means instead of creating one > link to a page you can deliver a hundred different links in a > hundred different contexts because the namespace that he creates > for each site map to keywords like http://somesite.com/ns/wood or > http://somesite.com/ns/mahogany If he also includes some triples somewhere which define <http://somesite.com/ns/wood> owl:sameAs <http://dbpedia.org/resource/Wood> . Then that is fine. He can happily use his own wood resource, and parsers are able to know that he means the same thing as dbpedia.org (a relatively well-known namespace) means by "Wood". If he doesn't define "wood" usefully, then that's not really a problem, but he'll probably have very little benefit, so you have to wonder why he'd use RDFa at all. This can be considered analogous to POSH. An author could mark up people in their code using: <div class="person"> <span class="name">Toby Inkster</span> </div> But they get more benefit by re-using well-known class names: <div class="vcard"> <span class="fn">Toby Inkster</span> </div> They can do it either way and things are fine. But by using the well- known, the publisher gets additional benefit. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6B807884-CDDF-4C96-8350-F4218921496C%40tobyinkster.co.uk Re: RDFa and Microformats 2008-09-15T10:49:55 2008-09-15T10:49:55 2008-09-15T10:49:55 On 15 Sep 2008, at 02:16, Martin McEvoy wrote: > Martin McEvoy wrote: >> Its just seems counter productive to me? It seems RDFa can help >> the wider community by suggesting.... >> >> <div class="vevent"> >> <h3 class="summary">Have I Got Old News For You</h3> >> <p class="location">BBC2</p> >> <p><span property="dtstart" >> content="2008-06-28T21:00:00">Saturday 28 June, >> 9</span>-<s... On 15 Sep 2008, at 02:16, Martin McEvoy wrote: > Martin McEvoy wrote: >> Its just seems counter productive to me? It seems RDFa can help >> the wider community by suggesting.... >> >> <div class="vevent"> >> <h3 class="summary">Have I Got Old News For You</h3> >> <p class="location">BBC2</p> >> <p><span property="dtstart" >> content="2008-06-28T21:00:00">Saturday 28 June, >> 9</span>-<span property="dtend" >> content="2008-06-28T21:30:00">9.30pm</p> >> <p class="description">Team captains Paul Merton and Ian Hislop >> are joined by returning guest host Jeremy Clarkson and >> panellists Danny Baker and Germaine Greer for the >> topical news quiz. <abbr title="in stereo">[S]</abbr></p> >> </div> The problem with this syntax, which Mark has already pointed out, is that you have nothing to "scope" the two property attributes. An RDFa parser will see the "dtstart" and "dtend" properties as being scoped to the whole page, and not to the event. Indeed, in the RDF/XML file you posted earlier as an interpretation of this HTML was along the lines of: <c:Vcalendar r:about=""> <c:component> <c:Vevent> <c:summary>...</c:summary> <!-- etc --> </c:Vevent> </c:component> <c:dtstart>2008-06-28T21:00:00</c:dtstart> <c:dtend>2008-06-28T21:30:00</c:dtend> </c:Vcalendar> That is, the dtstart and dtend are being interpreted as properties of the *calendar*, not of the *event*. > Ok then just thinking "way out of the box" Not so far out of the box as you think perhaps... http://microformats.org/discuss/mail/microformats-dev/2008-June/ 000561.html ;-) > I have updated http://weborganics.co.uk/demo/hcal.xhtml > to use the example above, but instead of using @property It uses > @class with @content (valid xhtml this time) > > <div class="vevent"> > <h3 class="summary">Have I Got Old News For You</h3> > <p class="location">BBC2</p> > <p><span class="dtstart" content="2008-06-28T21:00:00">Saturday 28 > June, > 9</span>-<span class="dtend" > content="2008-06-28T21:30:00">9.30pm</span></p> > <p class="description">Team captains Paul Merton and Ian Hislop > are joined by returning guest host Jeremy Clarkson and > panellists Danny Baker and Germaine Greer for the > topical news quiz. <abbr title="in stereo">[S]</abbr></p> > </div> This is a much better idea. The content attribute solves the accessibility issue with ISO datetimes, and the use of it doesn't conflict at all with RDFa's parsing rules. Personally, I haven't implemented this yet, waiting to see first if it seems like a popular approach. (I have however implemented support for <time class="dtstart" datetime="2008-06-28 21:00:00">Saturday 18 June, 9pm</time> from HTML5.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9EE05D56-7FEE-4F6D-BAA4-E1FE0810CF72%40g5n.co.uk Re: RDFa and Microformats 2008-09-15T10:55:30 2008-09-15T10:55:30 2008-09-15T10:55:30 On 15 Sep 2008, at 02:16, Martin McEvoy wrote: > Martin McEvoy wrote: >> Its just seems counter productive to me? It seems RDFa can help >> the wider community by suggesting.... >> >> <div class="vevent"> >> <h3 class="summary">Have I Got Old News For You</h3> >> <p class="location">BBC2</p> >> <p><span property="dtstart" >> content="2008-06-28T21:00:00">Saturday 28 June, >> 9</span>-<s... On 15 Sep 2008, at 02:16, Martin McEvoy wrote: > Martin McEvoy wrote: >> Its just seems counter productive to me? It seems RDFa can help >> the wider community by suggesting.... >> >> <div class="vevent"> >> <h3 class="summary">Have I Got Old News For You</h3> >> <p class="location">BBC2</p> >> <p><span property="dtstart" >> content="2008-06-28T21:00:00">Saturday 28 June, >> 9</span>-<span property="dtend" >> content="2008-06-28T21:30:00">9.30pm</p> >> <p class="description">Team captains Paul Merton and Ian Hislop >> are joined by returning guest host Jeremy Clarkson and >> panellists Danny Baker and Germaine Greer for the >> topical news quiz. <abbr title="in stereo">[S]</abbr></p> >> </div> The problem with this syntax, which Mark has already pointed out, is that you have nothing to "scope" the two property attributes. An RDFa parser will see the "dtstart" and "dtend" properties as being scoped to the whole page, and not to the event. Indeed, in the RDF/XML file you posted earlier as an interpretation of this HTML was along the lines of: <c:Vcalendar r:about=""> <c:component> <c:Vevent> <c:summary>...</c:summary> <!-- etc --> </c:Vevent> </c:component> <c:dtstart>2008-06-28T21:00:00</c:dtstart> <c:dtend>2008-06-28T21:30:00</c:dtend> </c:Vcalendar> That is, the dtstart and dtend are being interpreted as properties of the *calendar*, not of the *event*. > Ok then just thinking "way out of the box" Not so far out of the box as you think perhaps... http://microformats.org/discuss/mail/microformats-dev/2008-June/ 000561.html ;-) > I have updated http://weborganics.co.uk/demo/hcal.xhtml > to use the example above, but instead of using @property It uses > @class with @content (valid xhtml this time) > > <div class="vevent"> > <h3 class="summary">Have I Got Old News For You</h3> > <p class="location">BBC2</p> > <p><span class="dtstart" content="2008-06-28T21:00:00">Saturday 28 > June, > 9</span>-<span class="dtend" > content="2008-06-28T21:30:00">9.30pm</span></p> > <p class="description">Team captains Paul Merton and Ian Hislop > are joined by returning guest host Jeremy Clarkson and > panellists Danny Baker and Germaine Greer for the > topical news quiz. <abbr title="in stereo">[S]</abbr></p> > </div> This is a much better idea. The content attribute solves the accessibility issue with ISO datetimes, and the use of it doesn't conflict at all with RDFa's parsing rules. Personally, I haven't implemented this yet, waiting to see first if it seems like a popular approach. (I have however implemented support for <time class="dtstart" datetime="2008-06-28 21:00:00">Saturday 18 June, 9pm</time> from HTML5.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AA92749F-FA6A-45D3-BDAB-ADAFD8E8C952%40g5n.co.uk Re: RDFa and Microformats 2008-09-15T11:28:24 2008-09-15T11:28:24 2008-09-15T11:28:24 On 15 Sep 2008, at 12:06, Mark Birbeck wrote: > However, if you now add a @content value that is tied to some other > property -- in Martin's example, @class -- then we have a similiar > situation to our previous one; how does the RDFa parser know that > @content is being used in a Microformatty-way, and not an RDFa-way: > > <span > class="dtstart" content="2008-06-28T21:00:00" > proper... On 15 Sep 2008, at 12:06, Mark Birbeck wrote: > However, if you now add a @content value that is tied to some other > property -- in Martin's example, @class -- then we have a similiar > situation to our previous one; how does the RDFa parser know that > @content is being used in a Microformatty-way, and not an RDFa-way: > > <span > class="dtstart" content="2008-06-28T21:00:00" > property="foaf:name">Toby A Inkster</span> > > Your name is now a date, in the RDFa parser. This is not a problem of syntax, but just a problem of trying to do something silly. In short, the problems with the code you posted above have nothing to do with microformats. If you remove the 'class="dtstart"' - the only microformat class in the code - the problem still exists. The same problem would occur in a pure microformats or pure RDFa approach: <abbr title="2008-06-28T21:00:00" class="dtstart fn">Toby A Inkster</abbr> <span content="2008-06-28T21:00:00" property="c:dtstart foaf:name">Toby A Inkster</span> And is easily solved by adding a second element: <span class="dtstart" content="2008-06-28T21:00:00"> <span property="foaf:name">Toby A Inkster</span> </span> > Using the new attributes for something other than what they were > intended for, takes us right back to the situation we're trying to > escape from. The reason using @content to provide data values for Microformats is better than using @property plus @content, is that the use of @content alone does not create a triple in the RDFa processing model. So a <span class="dtstart"> with @content (and no RDFa-specific properties) will not create additional misleading triples in the RDFa processing model. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8122CA7C-E3F2-4015-802B-766BFDE154B9%40g5n.co.uk Re: RDFa and Microformats 2008-09-15T12:40:51 2008-09-15T12:40:51 2008-09-15T12:40:51 On 15 Sep 2008, at 12:57, Mark Birbeck wrote: > <span > class="p1" content="v1" > property="p2">v2</span> > > How does the RDFa parser know that @content was added for use in a > Microformat, rather than for use in RDFa? <span content="v1" property="p1 p2">v2</span> How does the RDFa parser know that @content was added for p1 and not p2? Answer: it doesn't; it can't; if you really... On 15 Sep 2008, at 12:57, Mark Birbeck wrote: > <span > class="p1" content="v1" > property="p2">v2</span> > > How does the RDFa parser know that @content was added for use in a > Microformat, rather than for use in RDFa? <span content="v1" property="p1 p2">v2</span> How does the RDFa parser know that @content was added for p1 and not p2? Answer: it doesn't; it can't; if you really want value v2 to be associated with property p2, then you shouldn't use that markup. Think of this way. If you have the following markup: <span property="foaf:name" content="Toby Inkster">Toby</span> then you decide to add hCard to your page: <span property="foaf:name" class="fn" content="Toby Inkster">Toby</span> why should the microformat not benefit from RDFa's more descriptive markup? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8204C4ED-E27F-4B62-8ECF-1E261109710A%40g5n.co.uk Re: RDFa and Microformats 2008-09-15T13:46:37 2008-09-15T13:46:37 2008-09-15T13:46:37 On 15 Sep 2008, at 13:59, Mark Birbeck wrote: >> <span content="v1" >> property="p1 p2">v2</span> >> >> How does the RDFa parser know that @content was added for p1 and >> not p2? >> Answer: it doesn't; it can't; > > In the sense that it cannot know the 'intent', then of course you > are right. > > But the outcome of the mark-up is clearly defined in the RDFa > processing rules,... On 15 Sep 2008, at 13:59, Mark Birbeck wrote: >> <span content="v1" >> property="p1 p2">v2</span> >> >> How does the RDFa parser know that @content was added for p1 and >> not p2? >> Answer: it doesn't; it can't; > > In the sense that it cannot know the 'intent', then of course you > are right. > > But the outcome of the mark-up is clearly defined in the RDFa > processing rules, and you will get this: > > <> p1 "v1" . > <> p2 "v1" . And with: <span class="p1" content="v1" property="p2">v2</span> the outcome of the mark-up is also clearly defined by RDFa processing rules: <> p2 "v1" . So where's the problem? > Also, as you said yourself earlier, the resource that the properties > are being attached to is different in RDFa than it is in Microformats: > > <div class="hcard"> > <span property="foaf:name" class="fn" > content="Toby Inkster">Toby</span> > </div> Here the problem is caused by the property attribute, not the content attribute. The RDFa triples created by the above markup are: <> foaf:name "Toby Inkster" . Which is clearly not what was intended. However, removing @property, or adding @about/@typeof to the <div> fix things. I'm not suggesting muddying the RDFa processing rules - merely stating that it should be safe for microformats parsers to make use of @content on elements which do not have @property; and to make use of @content on elements which *do* have @property, as long as it is used consistently with the RDFa processing model. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/17650F24-F007-45DD-9448-B8671472168D%40g5n.co.uk Re: RDFa and Microformats 2008-09-15T16:05:21 2008-09-15T16:05:21 2008-09-15T16:05:21 On 15 Sep 2008, at 16:17, Martin McEvoy wrote: > Talking of "hacks" why is this NOT a "hack" : http:// > wiki.digitalbazaar.com/en/HAudio_RDFa? it looks like a direct rip > from the Microformats wiki, That article is published by the same Manu Sporny who is editor of the hAudio spec. (At least I assume it's the same Manu Sporny. Manu Sporny has, I think, a name like mine, in that it can... On 15 Sep 2008, at 16:17, Martin McEvoy wrote: > Talking of "hacks" why is this NOT a "hack" : http:// > wiki.digitalbazaar.com/en/HAudio_RDFa? it looks like a direct rip > from the Microformats wiki, That article is published by the same Manu Sporny who is editor of the hAudio spec. (At least I assume it's the same Manu Sporny. Manu Sporny has, I think, a name like mine, in that it can be considered an "inverse functional property".) > Old News I'm afraid Microformats do have a generic parsing model > just because you cant read it on a page somewhere , again this is > Work in progress by many members of the Microformats Comunity, > Brian Suda, Ben West, Myself are some of the people who spring to > mind who are actively working this Problem. more notably Toby > Inkster with this page http://microformats.org/wiki/parsing- > brainstorming .. If you read the blurb at the top, you'll see that the page covers parsing a good deal of microformat properties, but not 100%. For example, hCard N optimisation, the "tel" and "email" properties for hCard, "item" in hAudio, lots of crazy stuff in hResume regarding intermingling hCards and hCalendar for experience and education properties. (And that last one, I don't think there's any fool-proof way of handling - the hResume spec itself is way too fuzzy.) These are all outside my parsing algorithm. Even if you ignore those issues, the parsing mechanism is still far from generic in the same way RDFa is. If you look at part 4 of the document you cited, step 5.3.1, you will see that the parser needs to "find the value of element e". To do this, it needs to choose one of five different parsing methods. To know which method, it needs to know what "type" of property it is parsing: a plain text string, a datetime, a URL, etc. This requires special knowledge of each property - e.g. the parser needs to know that "fn" should be parsed as a string, but "photo" as a URL. Also, in step 3 it needs to know which properties may contain an embedded microformat. (e.g. an hCard may be embedded in hCalendar's "attendee" property.) This contrasts markedly with RDFa which can be parsed without special knowledge of any particular terms (except for a handful of unprefixed rel values which are grandfathered in, mostly from HTML4/XHTML1 - and the special handling they get is only very slightly special). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E77019B2-A769-45C7-AD59-11376BA00BC0%40g5n.co.uk Re: XHTML+RDFa and auto discovery 2008-09-18T20:23:27 2008-09-18T20:23:27 2008-09-18T20:23:27 Sergey Chernyshev wrote: > I was thinking more about the Steven's words (in my previous thread) > regarding xhtmlvocab:alternative and rdfs:seeAlso and started to > wonder how > is data discovery going to be adopted by developers writing RDFa > client > software. Cognition <http://buzzword.org.uk/cognition/> will by default follow xhv:meta and rdfs:seeAlso links. The subject of the links m... Sergey Chernyshev wrote: > I was thinking more about the Steven's words (in my previous thread) > regarding xhtmlvocab:alternative and rdfs:seeAlso and started to > wonder how > is data discovery going to be adopted by developers writing RDFa > client > software. Cognition <http://buzzword.org.uk/cognition/> will by default follow xhv:meta and rdfs:seeAlso links. The subject of the links must be the page itself - i.e. the following link will not be followed: <div about="[_:dave]"> <a href="meta" href="more.rdf">...</a> </div> But the following will: <div about=""> <a href="meta" href="more.rdf">...</a> </div> The object of the link can be an RDF/XML file, an RDF/N3 document, or an HTML file using RDFa, eRDF, GRDDL or Microformats. You can control the depth of crawling using command-line options - by default, the depth is 1 (i.e. the initial page, and any directly linked.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/12306C1A-6FC2-4EA7-81F9-F7D8F487109D%40g5n.co.uk Re: Jena/SPARQL.org bug when processing URNs 2008-09-18T20:39:36 2008-09-18T20:39:36 2008-09-18T20:39:36 Manu Sporny wrote: > Shane McCarron spotted this bug in the SPARQL.org implementation while > running his RDFa processor against the RDFa test suite[1]. Who did? ;-) http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Aug/ 0021.html I'm guessing that Shane spotted the same problem as he's using the same URI handling library. > This seems to be a bug in the SPARQL engine - can yo... Manu Sporny wrote: > Shane McCarron spotted this bug in the SPARQL.org implementation while > running his RDFa processor against the RDFa test suite[1]. Who did? ;-) http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Aug/ 0021.html I'm guessing that Shane spotted the same problem as he's using the same URI handling library. > This seems to be a bug in the SPARQL engine - can you please verify > that > it is, or let us know why it isn't? Thanks in advance :) Ralph Swick tracked down a reference in the RDF Concepts and Abstract Syntax which says that for the purposes of RDF, two URIs are only considered equivalent if they are the same, compared character by character as Unicode strings. For Shane's benefit: I'm guessing what he's doing is passing URLs to the URI::URL Perl module to help resolve relative URIs. My workaround has been to first compare them against this regexp: /^([a-z][a-z0-9\+\.\-]*)\:/i If the URI matches that regexp, then it's already absolute, so you don't need to pass it through URI::URL. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AA182146-CB6B-400E-8A46-4B03261500D8%40g5n.co.uk Re: Jena/SPARQL.org bug when processing URNs 2008-09-18T21:34:27 2008-09-18T21:34:27 2008-09-18T21:34:27 Manu Sporny wrote: > Hmm... that's a bit strange. Anybody know the thought process behind > that decision? For example, that would mean that this: > > http://example.org/ > and this > HTTP://example.org/ > > while being canonically the same, would fail in any sort of RDF-based > comparison? I imagine that it's to make things easier to implement. Especially given that the URIs used in RDF may w... Manu Sporny wrote: > Hmm... that's a bit strange. Anybody know the thought process behind > that decision? For example, that would mean that this: > > http://example.org/ > and this > HTTP://example.org/ > > while being canonically the same, would fail in any sort of RDF-based > comparison? I imagine that it's to make things easier to implement. Especially given that the URIs used in RDF may well use URI schemes that had not even been envisaged when RDF was invented. Should all RDF processors need to know that tel:+441632790123 and tel:+44-1623-790123 are equivalent? Given the vast number of different URI schemes (see <http://en.wikipedia.org/wiki/URI_scheme>) with new schemes being standardised all the time, it would be impractical for RDF implementations to be required to recognise equivalent URIs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/34ACD959-9C76-4E1D-B6B3-43D678A82C18%40g5n.co.uk Re: White Flag! was RDFa and Microformats 2008-09-23T22:13:13 2008-09-23T22:13:13 2008-09-23T22:13:13 > I had an xslt going on this sometime back in november last year, it > was > very efficient at generating triples but alas it was just a concept > (just to see if I could), the difference between the above and > rdfa, as > far as I can see, is the above doesn't require anything new, and uses > concepts that publishers and authors can easily become familiar with? One problem is that it still ... > I had an xslt going on this sometime back in november last year, it > was > very efficient at generating triples but alas it was just a concept > (just to see if I could), the difference between the above and > rdfa, as > far as I can see, is the above doesn't require anything new, and uses > concepts that publishers and authors can easily become familiar with? One problem is that it still doesn't provide a *generic* parsing method. For example, if you have: <a class="fn n url" href="http://tobyinkster.co.uk"> <span class="given-name">Toby</span> <span class="family-name">Inkster</span> </a> (With or without prefixes - that's not the point I'm trying to get at) how does the parser know that this is parsed as: fn = "Toby Inkster" n = { "given-name": "Toby" ; "family-name": "Inkster" } url = "http://tobyinkster.co.uk/" And not: fn = { "given-name": "Toby" ; "family-name": "Inkster" } n = "http://tobyinkster.co.uk/" url = "Toby Inkster" To do so requires special knowledge of what "fn", "n" and "url" mean; knowledge that "fn" is a string, "n" is a nested structure and "url" is a URL. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/49985F20-DAAB-4D1C-BDD2-908CF137F065%40g5n.co.uk ETA on XSLT for POWDER to POWDER-S 2008-09-27T12:12:09 2008-09-27T12:12:09 2008-09-27T12:12:09 Without wanting to sound impatient, does anyone know when the official XSLT file for transforming POWDER to POWDER-S will be available? I would like to start implementing support for POWDER in Cognition <http://buzzword.org.uk/cognition/> and although supporting plain POWDER seems simpler, I'd like to support both. Rather than writing two separate functions (one for POWDER and one for P... Without wanting to sound impatient, does anyone know when the official XSLT file for transforming POWDER to POWDER-S will be available? I would like to start implementing support for POWDER in Cognition <http://buzzword.org.uk/cognition/> and although supporting plain POWDER seems simpler, I'd like to support both. Rather than writing two separate functions (one for POWDER and one for POWDER-S) I'd like to just implement POWDER-S and then transform POWDER to that. So, does anyone have any idea when it will be ready? thanks -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/71E96B10-5261-40F7-BB2C-F4D8B868DCAE%40g5n.co.uk rel=stylesheet 2008-09-27T13:50:54 2008-09-27T13:50:54 2008-09-27T13:50:54 Let's assume I'm visiting http://example.com/page1.html using a CSS and RDFa capable browser. That page contains the following XHTML element: <link about="page2.html" rel="stylesheet" href="style.css" /> Now, should the styles in style.css be applied to page1.html? (Yes, I know they *will* be in all current CSS-capable browsers, but the question is *should* they be?) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Let's assume I'm visiting http://example.com/page1.html using a CSS and RDFa capable browser. That page contains the following XHTML element: <link about="page2.html" rel="stylesheet" href="style.css" /> Now, should the styles in style.css be applied to page1.html? (Yes, I know they *will* be in all current CSS-capable browsers, but the question is *should* they be?) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/7C9F6490-F155-4F04-BDFD-61B992C80CC2%40g5n.co.uk Re: RDFa in Drupal core 2008-10-02T20:43:36 2008-10-02T20:43:36 2008-10-02T20:43:36 David Peterson wrote: > Do you see any other useful, general purpose vocabs that would make > sense to plug into such an open framework? One key strength of > Drupal is > its sense of tagging content. You should probably check out Richard Newman's Tag Ontology <http:// www.holygoat.co.uk/projects/tags/> which is a very complete and flexible system for tagging content. There are essentially ... David Peterson wrote: > Do you see any other useful, general purpose vocabs that would make > sense to plug into such an open framework? One key strength of > Drupal is > its sense of tagging content. You should probably check out Richard Newman's Tag Ontology <http:// www.holygoat.co.uk/projects/tags/> which is a very complete and flexible system for tagging content. There are essentially two ways of using it - the easy way: <#someResource> tags:taggedWithTag [ a tags:Tag ; tags:tagName "this" ] , [ a tags:Tag ; tags:tagName "that" ] . Which could be used a bit like this using RDFa: <p about="#someResource"> This resource is tagged with: <a href="http://mysite.example.com/tag/this" rel="tags:taggedWitgTag tag"> <span typeof="tags:Tag" property="tags:tagName">this</span> </a> and <a href="http://mysite.example.com/tag/that" rel="tags:taggedWitgTag tag"> <span typeof="tags:Tag" property="tags:tagName">that</span> </a> </p> There's also the re-ified way, where you have a "Tagging" which is an event by which tags are assigned to a resource. It works a bit like this: <#someResource> tags:tag [ a tags:Tagging ; tags:taggedBy [ a foaf:Person ; foaf:name "Toby Inkster" ] ; tags:taggedOn "2008-10-02"^^xsd:date ; tags:associatedTag [ a tags:Tag ; tags:tagName "this" ] , [ a tags:Tag ; tags:tagName "that" ] ] . This could be marked up with RDFa like: <div about="#someResource" rel="tags:tag" rev="tags:taggedResource"> <p typeof="tags:Tagging"> <span rel="tags:taggedBy"> <span typeof="foaf:name" property="foaf:name" >Toby Inkster</span> </span> tagged this resource as <a href="http://mysite.example.com/tag/this" rel="tags:associatedTag"> <span typeof="tags:Tag" property="tags:tagName">this</span> </a> and <a href="http://mysite.example.com/tag/that" rel="tags:associatedTag"> <span typeof="tags:Tag" property="tags:tagName">that</span> </a> </p> </div> (The indentation in those examples is quite horrible. Apple Mail has terrible line wrapping, so I had to keep lines short to avoid triggering it.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/3A03B346-12D4-4D8A-A8F8-B19A0CD1565A%40g5n.co.uk Re: ETA on XSLT for POWDER to POWDER-S 2008-10-02T21:39:46 2008-10-02T21:39:46 2008-10-02T21:39:46 On 1 Oct 2008, at 10:18, Smith, Kevin, ((R&D)) VF-Group wrote: > (Apologies for delay in answering) No problem. > I have a draft XSLT which I will revise and make available later this > week: if you were able to feedback any issues or comments that > would be > much appreciated. The Formal Semantics document seems to imply that this will be in XSLT 1.0 rather than XSLT 2.0. Is that the cas... On 1 Oct 2008, at 10:18, Smith, Kevin, ((R&D)) VF-Group wrote: > (Apologies for delay in answering) No problem. > I have a draft XSLT which I will revise and make available later this > week: if you were able to feedback any issues or comments that > would be > much appreciated. The Formal Semantics document seems to imply that this will be in XSLT 1.0 rather than XSLT 2.0. Is that the case? I'd certainly prefer the former as the XSLT engine I'm using (GNOME's libxslt) only supports 1.0. I'll certainly post feedback once I've started implementing. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/2696E355-457F-45BB-B748-D7FEC42698F9%40g5n.co.uk Re: ETA on XSLT for POWDER to POWDER-S 2008-10-03T09:40:28 2008-10-03T09:40:28 2008-10-03T09:40:28 On 3 Oct 2008, at 10:12, Smith, Kevin, ((R&D)) VF-Group wrote: > Good question - I had started in XSLT 1.0 but changed to XSLT 2.0 to > utilise the replace() function: the part I was having trouble with was > to ensure that a host, e.g. As I understand it (and I may be wrong), there are three flavours of POWDER: * POWDER, the easy-to-author XML format. * POWDER-BASE, identical to above, but ... On 3 Oct 2008, at 10:12, Smith, Kevin, ((R&D)) VF-Group wrote: > Good question - I had started in XSLT 1.0 but changed to XSLT 2.0 to > utilise the replace() function: the part I was having trouble with was > to ensure that a host, e.g. As I understand it (and I may be wrong), there are three flavours of POWDER: * POWDER, the easy-to-author XML format. * POWDER-BASE, identical to above, but with all the matching stuff compiled into regexps. * POWDER-S, the RDF version. Going from POWDER to POWDER-BASE or to POWDER-S may be difficult without the string processing ability of XSLT 2.0. But going from POWDER-BASE to POWDER-S should be more achievable with XSLT 1.0, as the regular expressions shouldn't need any changes. Personably I'd be happy enough with a POWDER-BASE to POWDER-S transformation in XSLT 1.0. I could hanndle POWDER to POWDER-BASE as a pre-transformation step. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/0689CA00-AB93-4CB7-A2B7-AD18C3F49E3F%40g5n.co.uk Re: ETA on XSLT for POWDER to POWDER-S 2008-10-03T12:19:16 2008-10-03T12:19:16 2008-10-03T12:19:16 On 3 Oct 2008, at 12:48, Phil Archer wrote: > The XSLT engine I'll use in my (Perl) POWDER Processor is > XML::LibXSLT [1] Snap. > - which, a bit of poking around, suggests only implements XSLT 1 > (I'm not 100% sure but it looks that way). XML::LibXSLT is based on GNOME's libxslt library, which is XSLT 1.0 only. Amongst the libxslt development team there seems to be a desire to add su... On 3 Oct 2008, at 12:48, Phil Archer wrote: > The XSLT engine I'll use in my (Perl) POWDER Processor is > XML::LibXSLT [1] Snap. > - which, a bit of poking around, suggests only implements XSLT 1 > (I'm not 100% sure but it looks that way). XML::LibXSLT is based on GNOME's libxslt library, which is XSLT 1.0 only. Amongst the libxslt development team there seems to be a desire to add support for XSLT 2.0, but a feeling that it will take a lot of work, so it's not on the roadmap right now. > All of which leads me to conclude that an XSLT that goes from > POWDER-BASE to POWDER-S just using XSLT 1 might actually be > preferable to one that handles POWDER to POWDER-BASE to POWDER-S if > that entails using XSLT 2. It's certainly workable and I for one > will probably find it easier to implement. Yep, that's my feeling too. For me, an XSLT 1.0 transformation that does POWDER-BASE to POWDER-S would be a lot more useful than an XSLT 2.0 transformation that runs the full gamut. Right now there are fairly few implementations of XSLT 2.0. There's Saxon, but after that not much. Oracle XML Developers' Kit includes some support, but AFAIK not full support. Qt 4.5 includes partial support too. But many of the key XSLT libraries (Xalan, libxslt, MSXML) don't yet offer anything beyond 1.0, and this seems unlikely to change in the near future. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/55068F28-3213-4888-8547-B4440DFACD9F%40g5n.co.uk Re: Southampton Pub data as linked open data 2008-10-03T22:28:07 2008-10-03T22:28:07 2008-10-03T22:28:07 Continuing the open linked pub data theme... http://buzzword.org.uk/rdf/lewes-pubs -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Continuing the open linked pub data theme... http://buzzword.org.uk/rdf/lewes-pubs -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D60D9DBC-F98A-4F77-B7CB-D64AEE5B49ED%40g5n.co.uk Re: Biological Taxonomy Vocabulary 0.1 2008-10-06T22:08:35 2008-10-06T22:08:35 2008-10-06T22:08:35 On 4 Oct 2008, at 02:41, Sw-MetaPortal-ProjectParadigm wrote: > Check out www.ubio.org and review the underlying structure. Use > this and contact the developers network to expand the biological > taxonomy vocabulary. Thanks for the information. I'll try to get in touch with them soon. As it happens, today I've pushed a few changes across from my working copy to the live vocab: http:/... On 4 Oct 2008, at 02:41, Sw-MetaPortal-ProjectParadigm wrote: > Check out www.ubio.org and review the underlying structure. Use > this and contact the developers network to expand the biological > taxonomy vocabulary. Thanks for the information. I'll try to get in touch with them soon. As it happens, today I've pushed a few changes across from my working copy to the live vocab: http://purl.org/NET/biol/ns# These changes make biol:hasTaxonomy into a sub-property of rdf:type and biol:Taxonomy a sub-class of rdfs:Class. It also adds a new term biol:morePrecise for linking from a Taxonomy to a more precise Taxonomy. Examples 3.7 and 3.8 are new, and demonstrate these new features. Lastly, having looked at ubio.org as you suggested, I've made biol:rank into a sub-property of ubio:taxonomicGroup, but having not been able to find an RDFS file for ubio, I'm not 100% sure this is correct, so it is at risk of reversal. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C5DBEED6-2CF4-4F76-A1F4-4BD3520E9681%40g5n.co.uk Re: Biological Taxonomy Vocabulary 0.1 2008-10-07T22:10:01 2008-10-07T22:10:01 2008-10-07T22:10:01 On 7 Oct 2008, at 10:03, Kjetil Kjernsmo wrote: > I'm a latecomer to this discussion, and not a biologist, so sorry > if this is > silly, but I thought Uniprot had a pretty uptodate taxonomy of > species? The Biological Taxonomy Vocabulary takes a completely different approach from UniProt, uBio, etc. Look at FOAF. The FOAF spec doesn't contain instance data - that is, the spec doesn't... On 7 Oct 2008, at 10:03, Kjetil Kjernsmo wrote: > I'm a latecomer to this discussion, and not a biologist, so sorry > if this is > silly, but I thought Uniprot had a pretty uptodate taxonomy of > species? The Biological Taxonomy Vocabulary takes a completely different approach from UniProt, uBio, etc. Look at FOAF. The FOAF spec doesn't contain instance data - that is, the spec doesn't define URIs for all the billions of people alive on Earth. Instead, it defines a few dozen terms like foaf:name, which other people can use to create instance data. Similarly, Dublin Core doesn't define URIs for millions of books, but does define a small number of properties which are useful for describing books (and films, music, etc). Existing biological ontologies have tended to focus on defining URIs for tens of thousands of different species. The Biological Taxonomy Vocabulary doesn't do that - instead it defines a smaller set of terms (less than twenty) that people can use to define species themselves. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A078A5B3-939D-4DAD-BE79-95B11A6D503C%40g5n.co.uk Re: New RDFa test case: handling xml entities 2008-10-10T14:45:30 2008-10-10T14:45:30 2008-10-10T14:45:30 Looks sensible to me. Perhaps the test case could also check numeric character references in decimal and hexadecimal. e.g. &#x40; and &#64;. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Looks sensible to me. Perhaps the test case could also check numeric character references in decimal and hexadecimal. e.g. &#x40; and &#64;. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/2FC5287B-A27C-47DA-BB76-3C70478EE17A%40tobyinkster.co.uk Re: [Playlist] XSPF -> RDF - using GRDDL 2008-10-11T16:32:05 2008-10-11T16:32:05 2008-10-11T16:32:05 I've done some work with RDF and playlists, but only tangentially related to the topic at hand. Cognition <http://buzzword.org.uk/cognition/> is able to parse hAudio <http://microformats.org/wiki/haudio> into RDF using Manu Sporny's Audio RDF vocabulary <http://purl.org/media/audio#>. It can then convert data from Audio RDF to M3U playlists. Cognition does support GRDDL (though see the ... I've done some work with RDF and playlists, but only tangentially related to the topic at hand. Cognition <http://buzzword.org.uk/cognition/> is able to parse hAudio <http://microformats.org/wiki/haudio> into RDF using Manu Sporny's Audio RDF vocabulary <http://purl.org/media/audio#>. It can then convert data from Audio RDF to M3U playlists. Cognition does support GRDDL (though see the proviso in the next paragraph), so theoretically if the XSPF GRDDL transformation provided its output as Audio RDF, Cognition could be used to convert XSPF to M3U. The proviso is that Cognition currently doesn't support all of GRDDL - it only supports rel=transformation and profileTransformation, not XML namespace transformations. This is because Cognition is really an (X)HTML parser, so doesn't support generic XML is an input - I am looking to change that in the next couple of versions though, and support non-(X)HTML input. So until Cognition supports non-(X)HTML input, and the rest of GRDDL, it won't actually be able to convert XSPF to M3U. I've got a couple of pages the demonstrate Cognition's M3U output. One uses hAudio; the other uses Audio RDF embedded in XHTML using RDFa: http://buzzword.org.uk/2008/audio/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/5E668276-FD06-4AF8-B13C-81F7A54D8B8A%40g5n.co.uk Re: [Playlist] XSPF -> RDF - using GRDDL 2008-10-11T16:33:49 2008-10-11T16:33:49 2008-10-11T16:33:49 [Apologies if you get this twice. The W3C mailing lists don't like my usual e-mail address, so I'm resending it with a different address.] I've done some work with RDF and playlists, but only tangentially related to the topic at hand. Cognition <http://buzzword.org.uk/cognition/> is able to parse hAudio <http://microformats.org/wiki/haudio> into RDF using Manu Sporny's Audio RDF vocabula... [Apologies if you get this twice. The W3C mailing lists don't like my usual e-mail address, so I'm resending it with a different address.] I've done some work with RDF and playlists, but only tangentially related to the topic at hand. Cognition <http://buzzword.org.uk/cognition/> is able to parse hAudio <http://microformats.org/wiki/haudio> into RDF using Manu Sporny's Audio RDF vocabulary <http://purl.org/media/audio#>. It can then convert data from Audio RDF to M3U playlists. Cognition does support GRDDL (though see the proviso in the next paragraph), so theoretically if the XSPF GRDDL transformation provided its output as Audio RDF, Cognition could be used to convert XSPF to M3U. The proviso is that Cognition currently doesn't support all of GRDDL - it only supports rel=transformation and profileTransformation, not XML namespace transformations. This is because Cognition is really an (X)HTML parser, so doesn't support generic XML is an input - I am looking to change that in the next couple of versions though, and support non-(X)HTML input. So until Cognition supports non-(X)HTML input, and the rest of GRDDL, it won't actually be able to convert XSPF to M3U. I've got a couple of pages the demonstrate Cognition's M3U output. One uses hAudio; the other uses Audio RDF embedded in XHTML using RDFa: http://buzzword.org.uk/2008/audio/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/DC3A8483-0756-41A4-91AA-881980814F56%40g5n.co.uk suggested new test case 2008-10-13T08:11:03 2008-10-13T08:11:03 2008-10-13T08:11:03 <div property="next">foo</div> shouldn't create a triple. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> <div property="next">foo</div> shouldn't create a triple. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/F169BCCD-39EE-4386-A439-36848B87627C%40g5n.co.uk Re: [semanticweb] Purl.org offline? 2008-10-15T23:24:48 2008-10-15T23:24:48 2008-10-15T23:24:48 > Having names for fundamental terms based on the DNS system is a > weakness. What will we do if purl.org gets taken over by a casino > site? > Will we argue that the terms keep their meaning even if the casino > site > says something else There is no law that says that if a tool wants to determine the meaning of <http://purl.org/dc/terms/title> it must perform an HTTP request for that UR... > Having names for fundamental terms based on the DNS system is a > weakness. What will we do if purl.org gets taken over by a casino > site? > Will we argue that the terms keep their meaning even if the casino > site > says something else There is no law that says that if a tool wants to determine the meaning of <http://purl.org/dc/terms/title> it must perform an HTTP request for that URI, even though that is common practice right now. It would be just as valid an approach for it to query a database, or to retrieve the meaning from a web service. http://meaningof.example/?as-of=2008&uri=http://purl.org/dc/terms/title -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B9360462-C3F7-4408-9041-37DF35BCBCA5%40g5n.co.uk Re: proposal to allow div, h1 .. h6 and section as children of list elements 2008-10-22T22:32:13 2008-10-22T22:32:13 2008-10-22T22:32:13 Bruce Lawson wrote: > <ol>… > <h2>Commencement</h2> > <li> These regulations replace the Practising Certificate > Regulations 1976 > in relation to all practising certificates, and applications for > practising certificates, for any period commencing on or after 1st > November 1995.</li> > <h2>Requests for information</h2> > <li>In addition to information supplied on any prescribed form > und... Bruce Lawson wrote: > <ol>… > <h2>Commencement</h2> > <li> These regulations replace the Practising Certificate > Regulations 1976 > in relation to all practising certificates, and applications for > practising certificates, for any period commencing on or after 1st > November 1995.</li> > <h2>Requests for information</h2> > <li>In addition to information supplied on any prescribed form > under these > regulations, solicitors must supply to the Law Society such > information as > to their practice as solicitors as the Society shall from time to time > reasonably require for the purpose of processing applications.</li> > <h2>Replacement date and conditions</h2> > <li>The replacement date for every practising certificate shall be the > 31st October following the issue of the applicant’s current practising > certificate.</li> > <li>Every practising certificate shall specify its commencement > date, its > replacement date, and any conditions imposed by the Law Society</li> > …</ol> As you noted, this could alternatively be marked up as: <div class="regulations"> <h2>Commencement</h2> <p>These regulations replace the Practising Certificate Regulations 1976 in relation to all practising certificates, and applications for practising certificates, for any period commencing on or after 1st November 1995.</p> <h2>Requests for information</h2> <p>In addition to information supplied on any prescribed form under these regulations, solicitors must supply to the Law Society such information as to their practice as solicitors as the Society shall from time to time reasonably require for the purpose of processing applications.</p> <h2>Replacement date and conditions</h2> <p>The replacement date for every practising certificate shall be the 31st October following the issue of the applicant’s current practising certificate.</p> <p>Every practising certificate shall specify its commencement date, its replacement date, and any conditions imposed by the Law Society</p> </div> div.regulations { counter-reset: regulation-paragraph; } div.regulations p:before { content: "\B6" counter(regulation-paragraph) ": "; counter-increment: regulation-paragraph; } But your objection was: > This spectacularly fails the Markup Duck Test which states that if it > looks like a duck, walks like a duck and quacks like a duck then it > is a > duck: a list of paragraphs, each beginning with a number indicating > the > order of the paragraphs is an ordered list, and needs to be marked > up as > one. As I understand it, these are referred to as "paragraphs" by those in the legal profession, so surely <p> is a better element for the job than <li>? I think most of the cases your proposal covers can be solved by adjusting the markup, especially with the <ol start> and <li value> attribute. That having been said, I do see the merit in a grouping element within lists, but not one which allows arbitrary content. Something equivalent to <tbody> within tables: the content model within the <tbody> is as if the <tbody> wasn't there. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8AB0E260-6AED-4DC8-8B0F-FAA341EB564C%40g5n.co.uk Re: life after REC: Meeting Agenda 1500 UTC Thursday October 23rd. 2008-10-23T22:46:54 2008-10-23T22:46:54 2008-10-23T22:46:54 Ivan Herman wrote: > @prefix="pref1 uri1 pref1 uri1 pref1 uri1" I personally prefer: prefix="pref1=uri1 pref2=uri2 pref3=uri3" As that allows for better future extension where certain tokens not taking the form pref=uri could be used to define other things (e.g. reserved words, or a default prefix). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Ivan Herman wrote: > @prefix="pref1 uri1 pref1 uri1 pref1 uri1" I personally prefer: prefix="pref1=uri1 pref2=uri2 pref3=uri3" As that allows for better future extension where certain tokens not taking the form pref=uri could be used to define other things (e.g. reserved words, or a default prefix). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D1644C45-4A71-4165-9271-CD3EF087233D%40g5n.co.uk XMDP to RDFS transformation for GRDDL 2008-10-26T20:32:20 2008-10-26T20:32:20 2008-10-26T20:32:20 XMDP is the usual method for defining vocabularies used in microformats. Essentially they're just <dl class="profile"> with each term defined as a <dt>, <dd> pair. An example is here: http://purl.org/uF/2008/03/ I've put together an XSLT 1.0 transformation which converts these to RDF schemas. Because XMDP is pretty much just human-readable descriptions, the schemas can't be very detaile... XMDP is the usual method for defining vocabularies used in microformats. Essentially they're just <dl class="profile"> with each term defined as a <dt>, <dd> pair. An example is here: http://purl.org/uF/2008/03/ I've put together an XSLT 1.0 transformation which converts these to RDF schemas. Because XMDP is pretty much just human-readable descriptions, the schemas can't be very detailed - they don't include ranges or domains for instance. The XSLT file is available here: http://buzzword.org.uk/2008/xmdp2rdfs.xslt And, at a versioned URI in case you need to refer to a specific version: http://buzzword.org.uk/2008/xmdp2rdfs-20081025.xslt Features: * Can cope with multiple definitions for a single term (i.e. <dt/><dd/ ><dd/>). * Definitions can reference additional information using rel="help". * <dt class="Property" /> can be used to hint that the term is a rdf:Property. * <dt class="Class" /> can be used to hint that the term is a rdfs:Class. * <title/> becomes the vocabulary's dc:title. Anyone have any ideas for improvements? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/3204DF1C-F456-4BF1-AE06-944EC16117C7%40g5n.co.uk Re: proposal to allow div, h1 .. h6 and section as children of list elements 2008-10-27T11:20:30 2008-10-27T11:20:30 2008-10-27T11:20:30 When using several <ol> elements and keeping the same numbering over them all, it would be useful to have a "continue" attribute. e.g. <ol id="firstbit"> <li>Apples</li> <li>Bananas</li> </ol> <p>A break from the list.</p> <ol continue="firstbit"> <li>Pears</li> <li>Oranges</li> </ol> The continue attribute would suggest that the second list is a logical continuation of the first list, and browsers should continue the numbering, so that "Oranges" would be numbered "4". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> When using several <ol> elements and keeping the same numbering over them all, it would be useful to have a "continue" attribute. e.g. <ol id="firstbit"> <li>Apples</li> <li>Bananas</li> </ol> <p>A break from the list.</p> <ol continue="firstbit"> <li>Pears</li> <li>Oranges</li> </ol> The continue attribute would suggest that the second list is a logical continuation of the first list, and browsers should continue the numbering, so that "Oranges" would be numbered "4". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/3DD9AF27-8C0B-464C-A7EA-41CF71965A0D%40g5n.co.uk Re: RDFa with multiple CURIEs as property.. 2008-10-31T22:36:01 2008-10-31T22:36:01 2008-10-31T22:36:01 > I think that's more of a question for one of the semweb lists, rather > than here. My guess though, is that this would not work, since it > would also imply that a literal is equivalent to a URI...which simply > cannot be, because fundamental RDF premises say they are not the same. That's what I thought when I had this discussion a while ago, but it was pointed out to me that rdfs:Literal rdfs:subClassOf rdfs:Resource - they are not disjoint. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> > I think that's more of a question for one of the semweb lists, rather > than here. My guess though, is that this would not work, since it > would also imply that a literal is equivalent to a URI...which simply > cannot be, because fundamental RDF premises say they are not the same. That's what I thought when I had this discussion a while ago, but it was pointed out to me that rdfs:Literal rdfs:subClassOf rdfs:Resource - they are not disjoint. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/35059ECD-0D39-46F4-A2B7-B9FDB06CCD36%40g5n.co.uk Re: RDFS / OWL to HTML 2008-11-04T08:51:58 2008-11-04T08:51:58 2008-11-04T08:51:58 Lee Feigenbaum wrote: > Are there any tools out there that will read in an RDF Schema and/ > or OWL > file and produce an HTML summary of the schema/ontology? Assuming that your ultimate aim is to have HTML and RDF/XML representations of the same information without having to manually maintain both, then probably the best solution would be to flip your question on its head: is there a way... Lee Feigenbaum wrote: > Are there any tools out there that will read in an RDF Schema and/ > or OWL > file and produce an HTML summary of the schema/ontology? Assuming that your ultimate aim is to have HTML and RDF/XML representations of the same information without having to manually maintain both, then probably the best solution would be to flip your question on its head: is there a way to convert an HTML representation of an ontology into RDF/XML? There are various solution, but RDFa[1] is probably your best choice. You'd mark your schema up in XHTML like: <div about="#xyzzy" typeof="rdfs:Property" id="term_xyzzy"> <h2> <dfn property="rdfs:label">xyzzy</dfn> <a href="#term_xyzzy" rel="rdfs:isDefinedBy">#</a> </h2> <p property="rdfs:comment">The xyzzy of the thing.</p> <p>Sub-property of: <a rel="rdfs:subPropertyOf" href="#term_foo" resource="#foo">foo</a>.</p> </div> Then you'd pass the XHTML+RDFa document through an RDFa implementation [2] to produce an RDF/XML version. ____ 1. http://www.w3.org/TR/rdfa-syntax/ 2. http://www.w3.org/2006/07/SWD/RDFa/implementation-report/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/27B638B3-F476-492E-9FD5-43EADDBCAD99%40g5n.co.uk Re: URIs and Unique IDs 2008-11-04T09:27:48 2008-11-04T09:27:48 2008-11-04T09:27:48 John Graybeal wrote: > Funny, I would have said this the other way around (new points back to > old, then the system services can provide the old -> new capability -- > or is this what you are saying too?). And lo, it already exists: http://www.w3.org/2006/link#obsoletes The only tiny little thing that we need is widespread usage and support for it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> John Graybeal wrote: > Funny, I would have said this the other way around (new points back to > old, then the system services can provide the old -> new capability -- > or is this what you are saying too?). And lo, it already exists: http://www.w3.org/2006/link#obsoletes The only tiny little thing that we need is widespread usage and support for it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C68C38F7-2824-45D5-8A4F-0DA3DE4CEFC8%40g5n.co.uk XHTML Sections Vocabulary 2008-11-04T18:09:42 2008-11-04T18:09:42 2008-11-04T18:09:42 Probably of little utility to most people, but I've put together a small vocab for describing sections within HTML documents. I use[1] it in conjunction with Dublin Core to describe the document structure gleaned by using the HTML 5 outline algorithm[2]. http://buzzword.org.uk/rdf/sections# Documentation for using the vocab is included at the above URI. ____ 1. http://srv.buzzword.org.uk/ 2. http://www.whatwg.org/specs/web-apps/current-work/#outlines -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Probably of little utility to most people, but I've put together a small vocab for describing sections within HTML documents. I use[1] it in conjunction with Dublin Core to describe the document structure gleaned by using the HTML 5 outline algorithm[2]. http://buzzword.org.uk/rdf/sections# Documentation for using the vocab is included at the above URI. ____ 1. http://srv.buzzword.org.uk/ 2. http://www.whatwg.org/specs/web-apps/current-work/#outlines -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/0591B96E-C5E4-4EF1-BFB7-EACFCD8EFF14%40g5n.co.uk YAUCI - Yet Another Unprefixed CURIE Idea [was Re: meeting record: 2008-11-06 RDF-in-XHTML Task Force] 2008-11-07T10:46:08 2008-11-07T10:46:08 2008-11-07T10:46:08 Ben Adida in the Meeting Record: > ... We want to make markup simpler - so when we compare Microformats > to RDFa, people don't see that RDFa is very complicated. Here's yet another possible solution. Define yet another attribute, which I'm calling "object" for now, though probably a better name can be found. It works like "typeof", but has a side-effect of setting a default CURIE prefix fo... Ben Adida in the Meeting Record: > ... We want to make markup simpler - so when we compare Microformats > to RDFa, people don't see that RDFa is very complicated. Here's yet another possible solution. Define yet another attribute, which I'm calling "object" for now, though probably a better name can be found. It works like "typeof", but has a side-effect of setting a default CURIE prefix for the element and any descendant elements. <html xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:doap="http://usefulinc.com/ns/doap#"> ... <div object="foaf:Person"> <a property="name" rel="page" href="http://tobyinkster.co.uk" >Toby Inkster</a> made <div rel="made"> <span object="doap:Project" property="name">Cognition</span> </div> </div> </html> This gives you the following result: _:b1 a foaf:Person ; foaf:name "Toby Inkster" ; foaf:page <http://tobyinkster.co.uk> ; foaf:made _:b2 . _:b2 a doap:Project ; doap:name "Cognition" . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6692E925-82EB-4B70-9766-15536457D3BE%40g5n.co.uk Re: YAUCI - Yet Another Unprefixed CURIE Idea [was Re: meeting record: 2008-11-06 RDF-in-XHTML Task Force] 2008-11-07T10:58:59 2008-11-07T10:58:59 2008-11-07T10:58:59 I wrote: > Define yet another attribute, which I'm calling "object" for now, > though probably a better name can be found. It works like "typeof", > but has a side-effect of setting a default CURIE prefix for the > element and any descendant elements. Another thought: @object could, like @about and @resource, allow full URIs to be used, so the following would be equivalent: <div object="http... I wrote: > Define yet another attribute, which I'm calling "object" for now, > though probably a better name can be found. It works like "typeof", > but has a side-effect of setting a default CURIE prefix for the > element and any descendant elements. Another thought: @object could, like @about and @resource, allow full URIs to be used, so the following would be equivalent: <div object="http://xmlns.com/foaf/0.1/Person"> <div object="[foaf:Person]"> (assuming that xmlns:foaf had been set). Of course, we'd need to spec what character to split on in these cases. Hash and slash are obviously the most common, but allowing question mark and equals sign might be good ideas too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/43FBEE6B-A055-4F26-9069-FC8B968EA966%40g5n.co.uk Re: "HTML: The Markup Language" (draft attempt an "HTML producers" spec) 2008-11-13T18:03:48 2008-11-13T18:03:48 2008-11-13T18:03:48 Michael(tm) Smith wrote: > During our face-to-face joint meeting with the W3C TAG in > Mandelieu, a large part of our discussion with the TAG[1] > concerned the idea of producing a separate normative spec for > HTML5 that defined just the syntax, structure, and semantics of > the language for "producers" of HTML content Wonderful. I argued a while back that all that all those parsing rules oug... Michael(tm) Smith wrote: > During our face-to-face joint meeting with the W3C TAG in > Mandelieu, a large part of our discussion with the TAG[1] > concerned the idea of producing a separate normative spec for > HTML5 that defined just the syntax, structure, and semantics of > the language for "producers" of HTML content Wonderful. I argued a while back that all that all those parsing rules ought to be stripped out into another specification. The HTML5 draft defines way too much to be user-friendly to the vast majority of its audience who are not browser vendors. HTML5 should define syntax rules, elements, attributes and entities. DOM5 (or perhaps DOM4 if skipping a version number was looked down upon) should be a separate document defining the DOM side of HTML5. All the SQLite storage stuff, most of chapter 4 should be split out as a "Window Object spec". A "HTML5 Browser" spec should be put together, including HTML5 parsing rules, and normatively referencing the above three specs, as well as ECMAScript, CSS 2.1/3, PNG and perhaps a few other useful specs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/58EC0EDF-17FA-4FF1-8EB5-C9519B2A0EF6%40g5n.co.uk Re: Why "Platform Core" and "HTML5" are in the same spec 2008-11-19T00:18:07 2008-11-19T00:18:07 2008-11-19T00:18:07 Ian Hickson wrote: > On Mon, 17 Nov 2008, Nikunj Mehta wrote: > > > SQL (5.10.2) and unstructured storage (5.10.1) are good examples. > The only > > reasons for keeping these parts in the HTML5 spec that I have > seen are > > that these pieces are stable and the same editor would be working on > > these sections as the Platform Core. Neither sound good enough > reasons > > to me. > > They'r... Ian Hickson wrote: > On Mon, 17 Nov 2008, Nikunj Mehta wrote: > > > SQL (5.10.2) and unstructured storage (5.10.1) are good examples. > The only > > reasons for keeping these parts in the HTML5 spec that I have > seen are > > that these pieces are stable and the same editor would be working on > > these sections as the Platform Core. Neither sound good enough > reasons > > to me. > > They're not particularily good reasons, but splitting those two > parts up > would delay progress by a year or more, and that is unacceptable IMHO. I would have thought that splitting out, say, the SQL stuff into a separate specification might allow the HTML spec to reach completion sooner as it would not be held back by a tangental area that clearly still needs a lot of work before it could be considered a fully usable specification. Splitting it out would allow people working on the SQL spec time to decide and write up exactly which subset of SQL is supported without worrying about holding up the entire project. Such decisions and documentation would surely be very important for the production of multiple interoperable implementations of a candidate recommendation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A8B6C0B6-71CA-422B-9CC9-E889575F1007%40g5n.co.uk Re: An HTML language specification 2008-11-19T00:55:05 2008-11-19T00:55:05 2008-11-19T00:55:05 Ian Hickson wrote: > On Tue, 18 Nov 2008, Mark Baker wrote: > > > Can anybody name a long deployed system whose constituent > protocols were > > specified as a monolith? I can't. > > The United States of America. > http://uscode.house.gov/ Correct me if I'm wrong, but doesn't the US constitution consist of seven separate articles, with very little overlap; plus the bill of rights, again wi... Ian Hickson wrote: > On Tue, 18 Nov 2008, Mark Baker wrote: > > > Can anybody name a long deployed system whose constituent > protocols were > > specified as a monolith? I can't. > > The United States of America. > http://uscode.house.gov/ Correct me if I'm wrong, but doesn't the US constitution consist of seven separate articles, with very little overlap; plus the bill of rights, again with little overlap with the original seven, added a few years later? And a number of smaller amendments over the years. That seems to be very much what is being proposed by splitting the current HTML5 spec: several specifications covering different areas of responsibility, with as little overlap as possible, but worked on by mostly a single team to ensure a coherent result; with the possibility for additions a few years later; and structured in a manner so that one spec may be amended without the others needing a rewrite. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/08E469D4-7413-4FBC-8100-87DF59BE4157%40g5n.co.uk HTTP-in-RDF implementation 2008-11-20T23:21:03 2008-11-20T23:21:03 2008-11-20T23:21:03 Cognition 0.1-alpha14 <http://buzzword.org.uk/cognition/> will include an implementation of the HTTP vocabulary in RDF. Previously, it represented HTTP response headers roughly like this: <rdf:Description rdf:about="http://example.com/foo" xmlns:http="urn:ietf:rfc:2616#"> <http:content-type>text/html; charset=utf-8</http:content-type> <http:server>Apache/2.1</http:s... Cognition 0.1-alpha14 <http://buzzword.org.uk/cognition/> will include an implementation of the HTTP vocabulary in RDF. Previously, it represented HTTP response headers roughly like this: <rdf:Description rdf:about="http://example.com/foo" xmlns:http="urn:ietf:rfc:2616#"> <http:content-type>text/html; charset=utf-8</http:content-type> <http:server>Apache/2.1</http:server> <!-- etc... --> </rdf:Description> Now it's been replaced with the new vocabulary. I plan to release it for download tomorrow, but you can try it online at http:// srv.buzzword.org.uk already. I realise it's past the deadline for feedback, but I have one thing I'd like to mention. Say I have: <http:Request> <http:methodName>GET</http:methodName> <http:absoluteURI>http://example.org/foo</http:absoluteURI> <http:response> <http:Response> <http:statusCodeNumber>200</http:statusCodeNumber> </http:Response> </http:response> </http:Request> And I also have some triples pertaining to the document itself: <rdf:Description rdf:about="http://example.org/foo"> <dc:title>Foo</dc:title> <dc:creator>John Citizen</dc:creator> </rdf:Description> It would be nice if there were some sort of predicate for linking from the Request resource to the Description resource, or vice versa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8F5040EB-4F17-4D8D-AC8D-3FAD7D74D7FF%40g5n.co.uk RDF/XML syntax question - parseType="Collection" plus nodeID 2008-11-21T16:14:08 2008-11-21T16:14:08 2008-11-21T16:14:08 Little question about using two features of RDF/XML in conjunction. Say I have the following RDF/XML: <rdf:Description> <ex:foo> <rdf:List rdf:nodeID="theList"> <rdf:_1><rdf:Description rdf:about="#i1" /></rdf:_1> <rdf:_2><rdf:Description rdf:about="#i2" /></rdf:_2> <rdf:_3><rdf:Description rdf:about="#i3" /></rdf:_3> </rdf:List> </ex:foo> </rdf:Description>... Little question about using two features of RDF/XML in conjunction. Say I have the following RDF/XML: <rdf:Description> <ex:foo> <rdf:List rdf:nodeID="theList"> <rdf:_1><rdf:Description rdf:about="#i1" /></rdf:_1> <rdf:_2><rdf:Description rdf:about="#i2" /></rdf:_2> <rdf:_3><rdf:Description rdf:about="#i3" /></rdf:_3> </rdf:List> </ex:foo> </rdf:Description> Now, this can be simplified, removing the rdf:List and rdf:_n stuff, using parseType="Collection": <rdf:Description> <ex:foo rdf:parseType="Collection"> <rdf:Description rdf:about="#i1" /> <rdf:Description rdf:about="#i2" /> <rdf:Description rdf:about="#i3" /> </ex:foo> </rdf:Description> But note now that the nodeID for the list no longer has an element upon which to be hung. If I want to refer to the same list again, I can't reference it as a named node. Is there a way around it? Can I use, for instance, rdf:nodeID on the <ex:foo/> element? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/5FE7D042-DEB3-4126-B273-D82632C43B3B%40g5n.co.uk Re: Splitting up the spec 2008-11-22T00:32:29 2008-11-22T00:32:29 2008-11-22T00:32:29 Ian Hickson wrote: > So where would you put the requirements currently in the "4.4.10.1 > Creating an outline" section? Personally, I don't think they belong as part of the spec at all. Don't get me wrong: it's a brilliant algorithm, and I've found it invaluable - far better than my own attempts before it was pointed out to me. But it doesn't need to be included in the spec. A separate W... Ian Hickson wrote: > So where would you put the requirements currently in the "4.4.10.1 > Creating an outline" section? Personally, I don't think they belong as part of the spec at all. Don't get me wrong: it's a brilliant algorithm, and I've found it invaluable - far better than my own attempts before it was pointed out to me. But it doesn't need to be included in the spec. A separate W3C note would suffice; or possibly as an informative appendix to the HTML5 markup spec. Here's my current thoughts on how I think the HTML5 spec should be split: 1. _HTML5 and DOM5_: Define the language syntax, the elements and their content models, the attributes, and the DOM (i.e. the "document" object in Javascript, but no other part of the document object). The parsing algorithm should be included. The outline algorithm could be an informative appendix or a separate note. Effectively chapters 1-3,8 of the current spec. 2. _Storage for Javascript_: the Storage interface, sessionStorage, localStorage, the storage event. Section 4.11.2 of the current spec, and some other parts of 4.11.1. 3. _SQL for Javascript_: database storage. This would include the scripting interface to the database, plus the minimal conforming subset of SQL. Section 4.11.2 of the current spec, and some other parts of 4.11. 4. _Server-Sent Events for Javascript_: Chapter 6 of the current spec. 5. _Offline Web Applications_: Section 4.7 of the current spec. 6. _HTML Link Vocabulary_: possibly not a spec, but a formal registry. This would start off as 4.12.3 of the current spec, but would probably expand. 7. _The HTML5 Browser_: this would normatively reference all of the above specifications, plus CSS 2.1, ECMAScript, XHR and Workers. Also a lot of the non-"document.*" Javascripty bits from the current HTML5 spec should be included: Window, History, Location, UndoManager, the draggable stuff, the contentEditable stuff, etc. Same origin; content- type sniffing. Much of chapter 4 and all of chapter 5 from the current spec. Also, included should be instructions for how user- agents should interpret any obsolete elements which they may encounter - you know, the really horrible ones that we don't want to be part of the markup spec, but browsers must still know how to deal with: <xmp>, <font>, etc. It has been mentioned by some people in this discussion that there is a lot of subtle interplay between these different parts, but actually I think that's even better justification for splitting them. It will allow us to see the ties between them because they will need to be made explicit by including normative references between the specifications. Once we can see these dependencies we can look at them one by one, and decide how they should be resolved: by keeping the normative reference, or perhaps redefining something in a different way to avoid the dependency. An example might be that server-sent events rely on the <event-source/> element. When we saw that dependency between _Server-Sent Events for Javascript_ and _HTML5 and DOM5_ we might think: why is <event-source/> needed? Perhaps an event source could be established entirely via script? > Splitting up the specs to help make progress faster, measured > either as > reaching CR faster, decoupling dependencies that might reach REC > faster, > getting specification text written faster, or, most importantly, > getting > interoperable implementations faster, is interesting. IMHO, > splitting up > the specs for no reason other than editorial preference is not Splitting up the spec can serve several useful purposes: A. It allows parts of the spec to be finalised before other parts. As I pointed out as an example before, a full and useful definition of SQL for Javascript is still a long way off. Splitting the spec would allow other important parts such as the markup language and DOM to enter the recommendation track without being held up by less complete parts. B. It makes it easier for other markup languages to incorporate components. For example, MathML, XHTML2 or SVG might like to incorporate Javascript storage, or server-sent events; OpenDocument might use the link vocab. This is a lot more practical if they are their own separate components. C. The aforementioned additional clarity regarding how the different parts are related. D. Going forward, past 2022, allowing new versions of each component spec to be worked on independently. e.g. a _SQL for Javascript 2.0_ spec (allowing, I don't know, transactions and triggers or something) could be developed without having to rethink everything else. Splitting the spec up wouldn't need to lead to the components diverging. The same working group could continue to work on the collection. People writing HTML5 browsers would still have a definitive spec to aim for: _The HTML5 Browser_. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9AA5912D-DA24-403E-9D3A-D9DE9F9A3D36%40g5n.co.uk Re: Splitting up the spec 2008-11-24T13:40:38 2008-11-24T13:40:38 2008-11-24T13:40:38 Ian Hickson wrote: > Should the Oxford English Dictionary be split into "common words" and > "uncommon words"? How is that different? Actually, it is. There is a Shorter Oxford English Dictionary (which, despite the name is still two very hefty volumes) containing all the common words, and the full Oxford English Dictionary containing pretty much all the English words which have been utter... Ian Hickson wrote: > Should the Oxford English Dictionary be split into "common words" and > "uncommon words"? How is that different? Actually, it is. There is a Shorter Oxford English Dictionary (which, despite the name is still two very hefty volumes) containing all the common words, and the full Oxford English Dictionary containing pretty much all the English words which have been uttered by anyone at any point in history. (Though the former contains a subset of the words of the latter: they are not disjoint.) A better analogy might be taking a "rulebook for using the English language" and splitting it up into separate books - the first providing just the vocabulary; the next explaining how grammar and punctuation work; another dealing with pronunciation; and another teaching essay writing. It's not a matter of separating out what's common and what's not common. It's a matter of separating out the markup language (HTML), its API (DOM) and scripting environment features (SQL, storage, history, etc). Something like Javascript-accessible SQL has nothing to do with the HTML5 markup language per se - it just so happens that many people will use them together. As proof: I don't imagine that many browsers will prevent SQL API being used by HTML4 pages or XHTML2 pages. Some may also allow SVG and MathML to use it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1D2726DE-D3C4-453E-A23B-7470F3C8296B%40g5n.co.uk Re: Splitting up the spec 2008-11-24T13:45:31 2008-11-24T13:45:31 2008-11-24T13:45:31 Jonas Sicking wrote: > IMHO all the parts about elements and attributes need to be in the > HTML spec. Content-Style-Type definitely needs to be in the HTML spec, > otherwise you have no idea how to interpret the text inside the > <style> element. I.e. you couldn't let CSS define that since you > couldn't know that it's CSS that you're trying to interpret. Actually, to be pedantic, Content-Style... Jonas Sicking wrote: > IMHO all the parts about elements and attributes need to be in the > HTML spec. Content-Style-Type definitely needs to be in the HTML spec, > otherwise you have no idea how to interpret the text inside the > <style> element. I.e. you couldn't let CSS define that since you > couldn't know that it's CSS that you're trying to interpret. Actually, to be pedantic, Content-Style-Type is needed to interpret the style *attribute*. The <style> element has a type attribute that tells you how to interpret it. Content-Style-Type is also IIRC defined to default to "text/css", so it's only needed by pages that use another stylesheet language. As few browsers support non-CSS styling languages, it is mostly redundant. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8EF594A6-34C7-41D3-B597-33D2EA6651DB%40g5n.co.uk Re: Splitting up the spec 2008-11-24T17:01:11 2008-11-24T17:01:11 2008-11-24T17:01:11 On 24 Nov 2008, at 15:15, Boris Zbarsky wrote: > Toby A Inkster wrote: > >> A better analogy might be taking a "rulebook for using the English >> language" and splitting it up into separate books > > That's an interesting thought experiment, because I think it has > some of the same issues as we face here. What is the dictionary > definition of the words 'a' and 'the' and how are they to be ... On 24 Nov 2008, at 15:15, Boris Zbarsky wrote: > Toby A Inkster wrote: > >> A better analogy might be taking a "rulebook for using the English >> language" and splitting it up into separate books > > That's an interesting thought experiment, because I think it has > some of the same issues as we face here. What is the dictionary > definition of the words 'a' and 'the' and how are they to be > defined without defining the grammar? I have never said that the parts may not normatively reference each other. In the case of 'a' and 'the', a vocabulary could define these as 'the indefinite article' and 'the definite article' respectively. The grammar could then say that when nouns are used, they are typically prefixed with the definite article when it is clear from context which instance of the noun is being referred to and the indefinite article when it is not, with an exception to the latter rule when the noun is used in its plural form. Such a definition might be not be especially helpful for people learning English as a foreign language, but that merely suggests that good English tutorials are needed too. > Heck, consider the grammatical construction "would have been > writing". Please describe to me the vocabulary sections for > "would", "have", and "been"? I'm not going to go into definitions for various words. The word with the longest definition in the OED is "set", as it has so many different senses in which it can be used. I'm sure that if you were to look up those words, the definitions of all of them would be very comprehensive, and include the sense in which they are used in your example. Again these would be candidates for normative references between the vocabulary and grammar. > I should further note that in practice when learning a language one > doesn't learn it by learning the vocabulary, then the grammar, etc. Indeed, but one learns a language from a tutorial-type book, not the specification. This goes for human languages as well as markup languages, and programming languages too. You don't learn, say, C from the EBNF syntax specification, but rather from a tutorial. > How do you explain the meaning of parts of the markup language whose > only purpose is to affect the DOM in that setup? I'm not so sure that there are any such parts. > Heck, how do you explain the meaning of parts of the markup > language whose only purpose is to affect navigation (say the > "autocomplete" attribute of <input>). Similarly to how it is already explained in WF2. That autocomplete="off" indicates that an <input> element is either of a particularly sensitive nature or is a value that is unlikely to ever be reused. It indicates that the page author believes that the <input> element cannot usefully be or should not be pre-filled by assistive technology. > I think everyone agrees that the SQL stuff needs to be split out at > some point. I challenge you to point to someone who argues against > that. The bone of contention is element definitions, element DOM > APIs (arguably an integral part of element definitions, though > apparently not to you), and things like the Window and Document > objects. I think in my last list of suggested splits I included the element and attribute definitions, DOM and document object as all being included within the HTML5 markup language specification. Originally, I listed the DOM/document part as being a separate specification, but I can see valuable arguments in both directions. Overall, I think a combined specification for markup and DOM is probably slightly preferable, but think that it should be structured so that each element is defined without reference to the DOM, and the DOM is then defined in reference to the element and its attributes. This way, user agents that do not build a DOM may still be able to implement some sort meaningful support for the element. My most recent list of suggested splits: http://lists.w3.org/Archives/Public/public-html/2008Nov/0415.html Errata: 1. The chapter numbers I used are from the latest public working draft on the W3C site; in more recent editor's drafts, many of these numbers have changed. 2. I say 'i.e. the "document" object in Javascript, but no other part of the document object' which doesn't make much sense. What I mean is 'i.e. the "document" object in Javascript, but not other part of the Javascript API'. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AD181F65-D37F-426D-9599-B8A4F0393C6A%40g5n.co.uk Re: Test Case #116: Relative URLs must be resolved in resulting triples 2008-11-24T17:19:09 2008-11-24T17:19:09 2008-11-24T17:19:09 Sergey Chernyshev wrote: > Manu, I think body of the test is not consistent with the title. Manu posted a corrected test case on Thursday. The title is "XML Entities must be supported by RDFa parser". See: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Nov/ 0040.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Sergey Chernyshev wrote: > Manu, I think body of the test is not consistent with the title. Manu posted a corrected test case on Thursday. The title is "XML Entities must be supported by RDFa parser". See: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Nov/ 0040.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/02B64433-15BA-4F94-BB76-C0D7246DCB91%40g5n.co.uk Re: HTTP-in-RDF implementation 2008-11-26T19:17:38 2008-11-26T19:17:38 2008-11-26T19:17:38 On 21 Nov 2008, at 17:37, Johannes Koch wrote: > Toby A Inkster schrieb: >> I realise it's past the deadline for feedback, but I have one >> thing I'd like to mention. Say I have: >> <http:Request> >> <http:methodName>GET</http:methodName> >> <http:absoluteURI>http://example.org/foo</http:absoluteURI> >> <http:response> >> <http:Response> >> <http:statusCo... On 21 Nov 2008, at 17:37, Johannes Koch wrote: > Toby A Inkster schrieb: >> I realise it's past the deadline for feedback, but I have one >> thing I'd like to mention. Say I have: >> <http:Request> >> <http:methodName>GET</http:methodName> >> <http:absoluteURI>http://example.org/foo</http:absoluteURI> >> <http:response> >> <http:Response> >> <http:statusCodeNumber>200</http:statusCodeNumber> >> </http:Response> >> </http:response> >> </http:Request> >> And I also have some triples pertaining to the document itself: >> <rdf:Description rdf:about="http://example.org/foo"> >> <dc:title>Foo</dc:title> >> <dc:creator>John Citizen</dc:creator> >> </rdf:Description> >> It would be nice if there were some sort of predicate for linking >> from the Request resource to the Description resource, or vice versa. > > I'd propose to add an http:body property with a cnt:Content (see > "Representing Content in RDF" <http://www.w3.org/TR/Content-in-RDF/ > >) object resource "http://example.org/foo" to the http:Response > subject. I suppose that could work, but what about if http://example.org/foo is a foaf:Person? Are we then saying that a physical person was sent down the wire? Anyway, to solve the need I had, I've created a tiny extension to the HTTP in RDF vocab: http://buzzword.org.uk/rdf/http-ext# > This gives two extra predicates: 1. http-ext:related-request - link from an rdfs:Resource to an http:Request. Indicates that the request is in some (unspecified) way related to the resource. For example, the request may have been an HTTP GET or POST request to the URI of the resource. 2. http-ext:http-equiv-headers - a link from a resource representing an (X)HTML document to a list or sequence of MessageHeaders which represent headers not actually transmitted via HTTP, but present as <meta http-equiv> elements in the (X)HTML document. These, I'm sure, are too esoteric to be included in the official vocab, but I hope that by posting this message to the list, anyone who does need predicates like these can find them and won't have to re-invent them. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/64359.81.2.120.180.1227801059.squirrel%40goddamn.co.uk Re: HTTP-in-RDF implementation 2008-11-27T15:50:59 2008-11-27T15:50:59 2008-11-27T15:50:59 Oh yes - one last comment. In the current working draft, section 1.1 Namespaces, table 2, the namespaces are defined as: http-header http://www.w3.org/2006/http-header# http-methods http://www.w3.org/2006/http-methods# http-statusCodes http://www.w3.org/2006/http-statusCodes# Yet in examples 2.3, 2.5 and 2.6, and appendix C, these URIs are used with "2008" instead of "2006". Which is correct? -Toby Oh yes - one last comment. In the current working draft, section 1.1 Namespaces, table 2, the namespaces are defined as: http-header http://www.w3.org/2006/http-header# http-methods http://www.w3.org/2006/http-methods# http-statusCodes http://www.w3.org/2006/http-statusCodes# Yet in examples 2.3, 2.5 and 2.6, and appendix C, these URIs are used with "2008" instead of "2006". Which is correct? -Toby http://tobyinkster.co.uk/message/D3185F4E-481A-4044-8D9B-9ABBDE0B0E95%40g5n.co.uk Google's SocialGraph Node Mapper 2008-11-28T19:23:08 2008-11-28T19:23:08 2008-11-28T19:23:08 Not sure if anyone else here has had much of a look at this, but it's certainly interesting. A Javascript library (with Perl, C, etc bindings, courtesy of Mozilla's libjs) that is able to interpret URIs for many, many social networking / blogging sites. Given a URI for a person's page on one of these sites it will return a URI, using the unregistered "sgn" URI scheme, for the person the... Not sure if anyone else here has had much of a look at this, but it's certainly interesting. A Javascript library (with Perl, C, etc bindings, courtesy of Mozilla's libjs) that is able to interpret URIs for many, many social networking / blogging sites. Given a URI for a person's page on one of these sites it will return a URI, using the unregistered "sgn" URI scheme, for the person themselves. Also, when that URI is fed back into the library, it can give you further URIs of interest about that person. Say, for example, you came across an hCard like this: <span class="vcard"> <a class="fn url" href="http://twitter.com/foobar" >Foo Bar</a> </span> Previously you could generate something like this: _:x1 a foaf:Person ; foaf:page <http://twitter.com/foobar> ; foaf:name "Foo Bar" . Whereas using the node mapper, you can generate: <sgn://twitter.com/?ident=foobar> a foaf:Person ; foaf:page <http://twitter.com/foobar> ; foaf:name "Foo Bar" ; plink:profile <http://twitter.com/foobar> ; plink:atom <http://twitter.com/statuses/user_timeline/foobar.atom> ; plink:rss <http://twitter.com/statuses/user_timeline/foobar.rss> . So you gain a real URI for the person (albeit using a weird unregistered URI scheme, but that's still better than a blank node) and three extra triples. I've set up a vocab that may be of use for people who want to use SGNM: http://buzzword.org.uk/rdf/personal-link-types# -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BE336D2D-A95C-42EE-AFCA-B762A6E25AD5%40g5n.co.uk Re: URIs and Unique IDs 2008-12-01T11:28:00 2008-12-01T11:28:00 2008-12-01T11:28:00 This discussions reminds me very much of Goodman's grue and bleen. It seems to me that one could define some predicates such as: ex:isBleen a rdfs:Property ; rdfs:label "is bleen" ; rdfs:comment "If this predicate is used before 1 Jan 2010, something which appears blue" , "If this predicate is used after 1 Jan 2010, something which appears green" ; rdfs:range "True or false"^rdfs:comme... This discussions reminds me very much of Goodman's grue and bleen. It seems to me that one could define some predicates such as: ex:isBleen a rdfs:Property ; rdfs:label "is bleen" ; rdfs:comment "If this predicate is used before 1 Jan 2010, something which appears blue" , "If this predicate is used after 1 Jan 2010, something which appears green" ; rdfs:range "True or false"^rdfs:comment . ex:isGrue a rdfs:Property ; rdfs:label "is grue" ; rdfs:comment "If this predicate is used before 1 Jan 2010, something which appears green" , "If this predicate is used after 1 Jan 2010, something which appears blue" ; rdfs:range "True or false"^rdfs:comment . And these can be used safely without any contradictions. Sure, on occasion we need to know the time when the predicates were used - but that only becomes an issue when we want to translate them out of the bleen/grue terminology and into the more usual world of blue/green. The obvious argument is that the predicates ex:isBlue and ex:isGreen would be more useful, because one could use them without recourse to time, but in fact, it should be noted that ex:isBlue and ex:isGreen can be safely defined as: ex:isBlue a rdfs:Property ; rdfs:label "is blue" ; rdfs:comment "If this predicate is used before 1 Jan 2010, something which appears bleen" , "If this predicate is used after 1 Jan 2010, something which appears grue" ; rdfs:range "True or false"^rdfs:comment . ex:isGreen a rdfs:Property ; rdfs:label "is green" ; rdfs:comment "If this predicate is used before 1 Jan 2010, something which appears grue" , "If this predicate is used after 1 Jan 2010, something which appears bleen" ; rdfs:range "True or false"^rdfs:comment . Few, if any, triples are universally true in an ever-changing world. foaf:names can change on marriage or by deed poll; colours of items can change easily (e.g. leaves going brown in autumn, buildings being painted, etc); the meanings of words in the English language evolve over time (e.g. the word 'web' would not be understood in the same sense as is meant by most people on this list to people a hundred years ago). To fully reason with triples, one needs to understand the temporal, geospacial, linguistic, social and personal context in which they were generated. However, without that knowledge, an albeit limited degree of reasoning is still allowed. e.g. without knowledge of time, we can still reason about bleen and grue objects - we just can't convert that knowledge into knowledge of green and blue objects. Something to mull over. More on grue and bleen: http://en.wikipedia.org/wiki/Grue_and_Bleen -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/03E5980C-3A19-4BCC-8499-F6A478D3ED9D%40g5n.co.uk Extension vocabulary for W3C's vCard Ontology 2008-12-04T23:37:26 2008-12-04T23:37:26 2008-12-04T23:37:26 For a long while I've been parsing the hCard microformat into RDF using Cognition <http://buzzword.org.uk/cognition/>. For this, I've squatted on a namespace URI of <urn:ietf:rfc:2426#>. I've spent a while tonight switching over to <http://www.w3.org/2006/vcard/ns#>, but this ontology was missing a few things I needed, so I've put together a collection of additional terms that can be use... For a long while I've been parsing the hCard microformat into RDF using Cognition <http://buzzword.org.uk/cognition/>. For this, I've squatted on a namespace URI of <urn:ietf:rfc:2426#>. I've spent a while tonight switching over to <http://www.w3.org/2006/vcard/ns#>, but this ontology was missing a few things I needed, so I've put together a collection of additional terms that can be used with it. The extension is at <http://buzzword.org.uk/rdf/vcardx#>. The first thing it enables is a collection of additional properties, taken from current drafts for vCard 4.0. The W3C ontology is based on vCard 3.0. These include: - vx:impp (instant messaging / presence protocol) - vx:kind (e.g. "individual", "group", "org") - vx:gender (as a string) - vx:birth (place of birth) - vx:death (place of death) - vx:dday (date of death) - vx:lang (language spoken/read/written) - vx:member (group -> member relationship) - vx:caluri, vx:fburl, vx:caladruri (calendars) The other main thing it does is provide an alternative structure for telephone numbers, addresses and e-mail accounts. In addition to the original method of marking these up: _:me a v:VCard ; v:fn "Alice Smith" ; v:workTel <tel:+44-7700-900123> ; v:mobileTel <tel:+44-7700-900123> . An alternative is provided: _:me a v:VCard ; v:fn "Alice Smith" ; v:tel [ a vx:Tel ; rdf:value <tel:+44-7700-900123> ; vx:usage "work" , "mobile" ] . The former method is probably cleaner, but the latter is closer to hCard's structure, so may be useful for other people converting from hCard. There are a few other bits and bobs there too, but those are the main features. Also, somewhat related: <http://purl.org/uF/hCard/terms/> Hopefully these will be of use to some people. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BFDFC0E4-BB9C-4031-95E3-D3C602043BB7%40g5n.co.uk Ontology for points in a three-dimensional space 2008-12-08T23:00:54 2008-12-08T23:00:54 2008-12-08T23:00:54 Does anyone know of such a thing? Basically I want something like: :Point a rdfs:Class ; rdfs:comment "A point in three dimentions"@en . :x a rdfs:Property ; rdfs:domain :Point ; rdfs:range xsd:decimal . :y a rdfs:Property ; rdfs:domain :Point ; rdfs:range xsd:decimal . :z a rdfs:Property ; rdfs:domain :Point ; rdfs:range xsd:decimal ; :plane a rdfs:Property ; rdfs... Does anyone know of such a thing? Basically I want something like: :Point a rdfs:Class ; rdfs:comment "A point in three dimentions"@en . :x a rdfs:Property ; rdfs:domain :Point ; rdfs:range xsd:decimal . :y a rdfs:Property ; rdfs:domain :Point ; rdfs:range xsd:decimal . :z a rdfs:Property ; rdfs:domain :Point ; rdfs:range xsd:decimal ; :plane a rdfs:Property ; rdfs:domain :Point ; rdfs:comment "The reference plane."@en . Effectively something like <http://www.w3.org/2003/01/geo/> but operating on arbitrary 3D reference planes instead of just WGS84. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/81B9F8AF-4B50-4BF8-A60C-70D7919DADB8%40g5n.co.uk Re: Ontology for points in a three-dimensional space 2008-12-08T23:41:48 2008-12-08T23:41:48 2008-12-08T23:41:48 On 8 Dec 2008, at 23:11, Story Henry wrote: > Hehe. Cool, but I don't know if you need to make a new class for > three dimensional points. All points are 0 dimensional, see > > http://blogs.sun.com/bblfish/entry/the_10_dimensions_of_reality Points are by definition 0-dimensional, but their position can be recorded in an N-dimensional space. Although I'm only interested in recording thei... On 8 Dec 2008, at 23:11, Story Henry wrote: > Hehe. Cool, but I don't know if you need to make a new class for > three dimensional points. All points are 0 dimensional, see > > http://blogs.sun.com/bblfish/entry/the_10_dimensions_of_reality Points are by definition 0-dimensional, but their position can be recorded in an N-dimensional space. Although I'm only interested in recording their position in 3 dimensions, an ontology which allows them to be recorded in N-dimensions would be fine too. > On the other hand yes, I can see that if you are using euclidian > geometry you may need specific euclidian x, y, z coordinates. Those > differ from the x, y relations of geo coordinate space, which > occurs on the surface of a sphere. The W3C geo vocab includes a "z" - altitude in metres. Essentially, the W3C geo vocab records (x,y,z) co-ordinates in one particular non- Euclidian geometry - i.e. WGS84. I am after something that does the same, but can be used in other, Euclidean and non-Euclidean geometries - the ":plane" predicate would be used to state which geometry is being used. (The plane may, for example, define where the origin is, which direction the axes lie in, the units being used for each axis, plus any other pertinent information.) Norman Gray wrote: > What's your application? > The idea is that I could do things like this: <#moonbase> foaf:based_near [ a geom:Point geom:x 56.1 ; geom:y -12.9 ; geom:z 0 ; geom:plane <#lunarPlane> ] . <#lunarPlane> a geom:ReferencePlane ; rdfs:isDefinedBy <http://adsabs.harvard.edu/abs/2002cosp...34E1305W> . Without having to create separate ontologies for each reference plane. > How general do you want your coordinate system to be (there's a > whole world of positively delicious complication waiting to be > explored there!) I really just want three numbers with an associated frame of reference which may be defined by a link or short descriptive text. Something like that should be simple and flexible enough to work for any three-or-less-dimensional geometry - even exotic things like co- ordinates on, below or above the surface of a torus. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B310238E-DE40-4751-B4F8-C35C0557CF7F%40g5n.co.uk Re: Ontology for points in a three-dimensional space 2008-12-09T07:39:12 2008-12-09T07:39:12 2008-12-09T07:39:12 On 8 Dec 2008, at 23:48, John Graybeal wrote: > It would appear the people working on SWEET have thought about it: > http://sweet.jpl.nasa.gov/2.0/spaceCoordinates.owl > I particularly notice Cartesian is pretty similar to what you've > suggested. That looks exactly like what I'm after - thanks. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 8 Dec 2008, at 23:48, John Graybeal wrote: > It would appear the people working on SWEET have thought about it: > http://sweet.jpl.nasa.gov/2.0/spaceCoordinates.owl > I particularly notice Cartesian is pretty similar to what you've > suggested. That looks exactly like what I'm after - thanks. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B4017C1C-8E42-4C88-AF21-7531D31DF712%40g5n.co.uk Re: Ontology for points in a three-dimensional space 2008-12-09T12:49:01 2008-12-09T12:49:01 2008-12-09T12:49:01 On 9 Dec 2008, at 11:51, Norman Gray wrote: > A potential problem is that SWEET is potentially a bit too upper- > level for what it sounds like you want. True. I tried writing out a few examples, but they didn't seem quite right. Doesn't help that SWEET doesn't seem to include any rdfs:labels or rdfs:comments. For the time being, I've set up this: http://buzzword.org.uk/rdf/ungeo# But ... On 9 Dec 2008, at 11:51, Norman Gray wrote: > A potential problem is that SWEET is potentially a bit too upper- > level for what it sounds like you want. True. I tried writing out a few examples, but they didn't seem quite right. Doesn't help that SWEET doesn't seem to include any rdfs:labels or rdfs:comments. For the time being, I've set up this: http://buzzword.org.uk/rdf/ungeo# But will keep reviewing alternatives. > A possible alternative is STC <http://www.ivoa.net/Documents/latest/ > STC.html>. This has a _lot_ more detail than SWEET, and is > expressly designed as a solution to the problem you describe, but > there is not as yet a great deal of software support for it. > (Also, STC is defined as an XSchema -- A subset of STC certainly seems closer. > if you're interested, I could roll you an RDFS version of it). Thanks. It's a big spec, so don't do so on my account, but if you were planning on doing it anyway, then I'd certainly be interested in the result. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C0C0342C-1514-4F1E-9A40-EADEB726AA3F%40g5n.co.uk Re: Ontology for points in a three-dimensional space 2008-12-09T15:23:15 2008-12-09T15:23:15 2008-12-09T15:23:15 On 9 Dec 2008, at 14:05, Norman Gray wrote: > In this context, x, y, z would usually (or most conventionally) be > linear coordinates with an origin at the centre of the body, such > as the earth. On the other hand, latitude and longitude would be > angular coordinates, and altitude a radial coordinate above the > earth's reference surface, also centred on the earth. Thus > coordinate... On 9 Dec 2008, at 14:05, Norman Gray wrote: > In this context, x, y, z would usually (or most conventionally) be > linear coordinates with an origin at the centre of the body, such > as the earth. On the other hand, latitude and longitude would be > angular coordinates, and altitude a radial coordinate above the > earth's reference surface, also centred on the earth. Thus > coordinate (0,0,0) would be the centre of the earth in (x,y,z) > coordinates, and the point on the equator south of Greenwich in > (long,lat,alt) coordinates. Thus they can't really be subProperties. ungeo:x, ungeo:y and ungeo:z are defined as numerical points on the x, y and z axes. There is no requirement for the axes to be linear; and definitions of the axes may include the units used. For example, my current location could be written as: <#location> a ungeo:Point ; ungeo:x -0.0009 ; ungeo:y 50.87318 ; ungeo:z "55"^^<dbpedia:Approximation> ; ungeo:system <#wgs84> . <#wgs84> a ungeo:ReferenceSystem ; rdfs:label "WGS84" ; ungeo:x-axis "Degrees West of the line running from the North pole to the South pole through the observatory at Greenwich, measured as an angle from the centre of the Earth." ; ungeo:y-axis "Degrees North of the equator, measured as an angle from the centre of the Earth." ; ungeo:z-axis "Metres above sea level." ; ungeo:body <dbpedia:Earth> . The idea is to be able to represent any numerical (x,y,z) coordinates, in any reference space - the reference space doesn't need to have three traditional perpendicular axes. It can even cope with weird spaces like <http://buzzword.org.uk/2008/torus-space>. <#p1> a ungeo:Point ; ungeo:x 0.2 ; ungeo:y 1.3 ; ungeo:z 3.6 ; ungeo:space [ rdfs:isDefinedBy </2008/torus-space> ] . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/83DD7B9C-8BFC-4712-8CAD-D5FDBECBFEAA%40g5n.co.uk XHTML Vocabulary 2008-12-09T22:24:18 2008-12-09T22:24:18 2008-12-09T22:24:18 The document here: http://www.w3.org/1999/xhtml/vocab/ seems to need: <base href="http://www.w3.org/1999/xhtml/vocab"> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> The document here: http://www.w3.org/1999/xhtml/vocab/ seems to need: <base href="http://www.w3.org/1999/xhtml/vocab"> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CD3AD078-547B-423C-91D5-D1173F2F59F5%40g5n.co.uk Re: Markup questions: html/body, datatype="", double predicates 2008-12-10T10:13:09 2008-12-10T10:13:09 2008-12-10T10:13:09 Richard Cyganiak wrote: > 2. Behaviour of datatype="" when the content includes *RDFa* markup. > Let's say I have this in my HTML: > > <p about="#me" property="bio:olb"> > I work at > <a rel="foaf:workplaceHomepage" href="http://www.deri.ie/">DERI > Galway</a>. > </p> > > This works as expected, it creates two triples, a bio:olb triple whose > value is an rdf:XMLLiteral, and a foaf:workp... Richard Cyganiak wrote: > 2. Behaviour of datatype="" when the content includes *RDFa* markup. > Let's say I have this in my HTML: > > <p about="#me" property="bio:olb"> > I work at > <a rel="foaf:workplaceHomepage" href="http://www.deri.ie/">DERI > Galway</a>. > </p> > > This works as expected, it creates two triples, a bio:olb triple whose > value is an rdf:XMLLiteral, and a foaf:workplaceHomepage triple whose > value is the DERI URL. Someone butt in and correct me if I'm wrong, which I may very well be, but actually the *opposite* behaviour should be expected. With your initial HTML sample, only one triple should be created - the XMLLiteral. The foaf:workplaceHomepage should be *ignored*! Take a look at the RDFa syntax specification and search it for the string "[recurse]" - you'll find it crops up four times in the processing sequence. The key bits are: "1. First, the local values are initialized, as follows: the [recurse] flag is set to 'true' {...}" "9. {...} Once the triple has been created, if the [datatype] of the [current object literal] is rdf:XMLLiteral, then the [recurse] flag is set to false." "11. If the [recurse] flag is 'true', all elements that are children of the [current element] are processed using the rules described here {...}" So RDFa Distiller does seem to have a bug, but a different bug from the one you thought it did. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/70FD3EA1-BA6D-43BF-BA1A-1992FFA62819%40g5n.co.uk Implementation report - new Cognition results 2008-12-10T12:34:36 2008-12-10T12:34:36 2008-12-10T12:34:36 Not sure if the implementation report is still being updated, but here's an EARL report from Cognition this afternoon: http://buzzword.org.uk/2008/cognition-rdfa-earl-20081210.rdf Of the eight tests not passed in that EARL report, tests #11, #92, #94 and #1001 look like they should be passed. That would reduce Cognition's "red squares" on the report to just four from its current fourteen. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Not sure if the implementation report is still being updated, but here's an EARL report from Cognition this afternoon: http://buzzword.org.uk/2008/cognition-rdfa-earl-20081210.rdf Of the eight tests not passed in that EARL report, tests #11, #92, #94 and #1001 look like they should be passed. That would reduce Cognition's "red squares" on the report to just four from its current fourteen. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/111CDA36-5607-4E4C-AC80-A72093CB0628%40g5n.co.uk Re: Markup questions: html/body, datatype="", double predicates 2008-12-10T13:15:08 2008-12-10T13:15:08 2008-12-10T13:15:08 Richard Cyganiak wrote: > <> foaf:maker <#me> . > <#me> foaf:homepage <> . > <> foaf:maker <> . > <> foaf:homepage <> . I get these triples with Cognition too. I'm pretty sure that it's the "correct" output, even though it's unintuitive. I think the reasoning is as follows: The <head> element is treated as if it had about="" unless it does really have an @about set. So what you have is: ... Richard Cyganiak wrote: > <> foaf:maker <#me> . > <#me> foaf:homepage <> . > <> foaf:maker <> . > <> foaf:homepage <> . I get these triples with Cognition too. I'm pretty sure that it's the "correct" output, even though it's unintuitive. I think the reasoning is as follows: The <head> element is treated as if it had about="" unless it does really have an @about set. So what you have is: <html rel="foaf:maker" rev="foaf:homepage"> <head about="">...</head> ... </html> And that results in those two strange triples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A26268F0-5FD2-46BF-B30C-7B6F22BFD7C7%40g5n.co.uk Re: units and durations 2008-12-10T14:43:58 2008-12-10T14:43:58 2008-12-10T14:43:58 Georgi Kobilarov wrote: > 1. lengths: > metre, kilometre, centimetre, km^2, etc. > dbpedia:Rhine <http://dbpedia.org/ontology/length> > "1320"^^<http://dbpedia.org/ontology/kilometre> See: http://idi.fundacionctic.org/muo/muo-vocab.html > 2. runtimes > seconds, minutes, hours, days... > dbpedia:Yellow_Submarine_(song) <http://dbpedia.org/ontology/runtime> > "2:38"^^<http://dbpedia.org/ontology... Georgi Kobilarov wrote: > 1. lengths: > metre, kilometre, centimetre, km^2, etc. > dbpedia:Rhine <http://dbpedia.org/ontology/length> > "1320"^^<http://dbpedia.org/ontology/kilometre> See: http://idi.fundacionctic.org/muo/muo-vocab.html > 2. runtimes > seconds, minutes, hours, days... > dbpedia:Yellow_Submarine_(song) <http://dbpedia.org/ontology/runtime> > "2:38"^^<http://dbpedia.org/ontology/minute> > dbpedia:The_Departed <http://dbpedia.org/ontology/runtime> > "151"^^<http://dbpedia.org/ontology/minute> > > 3. durations > dbpedia:Thirty_Years'_War <http://dbpedia.org/ontology/date> > "1618-1648"^^??? In terms of ISO 8601, "durations" are defined as abstract floating lengths of time, such as "three and a half minutes". When you fix the duration to a particular time, such as "three and a half minutes, starting now", then it is classed as an "interval". For durations, there is there is xsd:duration. e.g. dbpedia:Yellow_Submarine_(song) ont:runtime "PT2M38S"^^xsd:duration . For intervals, XSD doesn't offer a datatype, but ISO 8601 at least offers a machine readable standard syntax for them - intervals are written, slash-separated, as a start-time/end-time pair, a start-time/ duration pair, or a duration/end-time pair. Personally, I tend to represent this in RDF as: dbpedia:Thirty_Years'_War ont:date "1618/1648"^^<urn:iso:std:iso:8601#timeInterval> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/F2CA3ED3-93E4-4C9E-82DA-3E49F1D27789%40g5n.co.uk Re: Markup questions: html/body, datatype="", double predicates 2008-12-10T18:50:31 2008-12-10T18:50:31 2008-12-10T18:50:31 On 10 Dec 2008, at 17:10, Richard Cyganiak wrote: > On 10 Dec 2008, at 10:13, Toby A Inkster wrote: > >> Take a look at the RDFa syntax specification and search it for the >> string "[recurse]" - you'll find it crops up four times in the >> processing sequence. The key bits are: >> >> "1. First, the local values are initialized, as follows: the >> [recurse] flag is set to 'true' {...}" >> >>... On 10 Dec 2008, at 17:10, Richard Cyganiak wrote: > On 10 Dec 2008, at 10:13, Toby A Inkster wrote: > >> Take a look at the RDFa syntax specification and search it for the >> string "[recurse]" - you'll find it crops up four times in the >> processing sequence. The key bits are: >> >> "1. First, the local values are initialized, as follows: the >> [recurse] flag is set to 'true' {...}" >> >> "9. {...} Once the triple has been created, if the [datatype] of >> the [current object literal] is rdf:XMLLiteral, then the [recurse] >> flag is set to false." >> >> "11. If the [recurse] flag is 'true', all elements that are >> children of the [current element] are processed using the rules >> described here {...}" > > This still seems to indicated that in the case of @datatype="", > processing should continue into the subtree. > > So I still believe that the Distiller is wrong in the @datatype="" > case. It does not generate triples for RDFa embedded inside the > literal, but it should. <x property="foo" datatype=""> should generate a string literal, and recurse to generate further triples for RDFa embedded inside the literal. <x property="foo"> (with no datatype attribute) should generate either an rdf:XMLLiteral or string literal (depending on the contents of <x>). If it generated an rdf:XMLLiteral, then it should not recurse; if it generated a string literal then it has nothing to recurse to; either way it should not generate any triples for RDFa inside the literal. If RDFa Distiller is getting this wrong, it's possible that it's doing an "if (getAttribute('datatype'))" somewhere - i.e. not differentiating between an empty attribute and an absent attribute. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E1E31736-AEEF-42AB-B6FF-8A038EC0C2BD%40g5n.co.uk RDFa Example - DOAC 2008-12-11T22:39:25 2008-12-11T22:39:25 2008-12-11T22:39:25 An example CV marked up with DOAC and RDFa: http://buzzword.org.uk/2008/rdfa-cv Parsed as N3: http://srv.buzzword.org.uk/n3/buzzword.org.uk/2008/rdfa-cv And various other formats: http://srv.buzzword.org.uk/rdf-xml/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.uk/rdf-json/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.uk/trix/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.u... An example CV marked up with DOAC and RDFa: http://buzzword.org.uk/2008/rdfa-cv Parsed as N3: http://srv.buzzword.org.uk/n3/buzzword.org.uk/2008/rdfa-cv And various other formats: http://srv.buzzword.org.uk/rdf-xml/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.uk/rdf-json/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.uk/trix/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.uk/vcard/buzzword.org.uk/2008/rdfa-cv http://srv.buzzword.org.uk/jcard/buzzword.org.uk/2008/rdfa-cv Lazyweb - is there a place where demonstrations like this can go on the Wiki? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CC9E745E-4820-4E3D-A882-9F67574AB0DE%40g5n.co.uk Re: RDFa Example - DOAC 2008-12-12T09:18:53 2008-12-12T09:18:53 2008-12-12T09:18:53 On 12 Dec 2008, at 02:15, Martin McEvoy wrote: > I have been looking at Description Of A Career earlier on this > week, seeing how well it maps to hResume ;-) You may be interested then in: http://www.linkedin.com/in/steveganz http://srv.buzzword.org.uk/rdf-xml/www.linkedin.com/in/steveganz I'm looking into mapping DOAC to Europass CV, but finding it hard to get specs for the latter. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 12 Dec 2008, at 02:15, Martin McEvoy wrote: > I have been looking at Description Of A Career earlier on this > week, seeing how well it maps to hResume ;-) You may be interested then in: http://www.linkedin.com/in/steveganz http://srv.buzzword.org.uk/rdf-xml/www.linkedin.com/in/steveganz I'm looking into mapping DOAC to Europass CV, but finding it hard to get specs for the latter. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1C8BADDB-ACF0-4389-8668-671CE0764130%40g5n.co.uk Cognition 0.1-alpha14 released 2008-12-14T10:53:54 2008-12-14T10:53:54 2008-12-14T10:53:54 Cognition is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML. Cognition is written in Perl 5 and licensed under the GNU GPL (v3). 0.1-alpha14 features include: * Better HTML 5 support - previous versions wou... Cognition is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML. Cognition is written in Perl 5 and licensed under the GNU GPL (v3). 0.1-alpha14 features include: * Better HTML 5 support - previous versions would strip out HTML5 elements which did not exist in HTML4. (Though XHTML5 has always worked, as XML uses a different parser.) Supports HTML5's predefined <meta name> values. * Integrated Google SocialGraph Node Mapper - for hCard and XFN microformats, SGNM can be used to generate a URI for a _person_ instead of a URI for their homepage. (And it can then be inverted to find URIs for their other pages from the person's URI.) * Less namespace squatting - instead of squatting on <urn:ietf:rfc: 1234#>-type namespaces, Cognition now uses the W3C RDF vocabs for vCard, iCalendar and HTTP. It uses Henry Story's AtomOWL too. * Notation3 output. * Various RDFa parsing bugfixes. Some examples of Cognition's parsing: http://srv.buzzword.org.uk/n3/tantek.com/ http://srv.buzzword.org.uk/n3/twitter.com/danbri http://srv.buzzword.org.uk/n3/w3.org/ Cognition homepage (download or try online): http://buzzword.org.uk/cognition/ Cognition on Google Code (issue tracker, subversion): http://code.google.com/p/cognition-parser/ Any suggestions for improvements gratefully received. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EFFBC4D1-BDA4-4E70-B088-BB64C5616B74%40g5n.co.uk Re: Markup questions: html/body, datatype="", double predicates 2008-12-14T17:46:46 2008-12-14T17:46:46 2008-12-14T17:46:46 Ivan Herman wrote: > Ben, Mark, Michael, others: what do you think? My understanding of the syntax specification is that conforming implementations must generate both triples in your example. Another test which I think is missing from the suite is: <div property="ex:foo"> <span property="ex:bar">bar</span> </div> should generate an XMLLiteral for ex:foo, but there should be no ex:bar t... Ivan Herman wrote: > Ben, Mark, Michael, others: what do you think? My understanding of the syntax specification is that conforming implementations must generate both triples in your example. Another test which I think is missing from the suite is: <div property="ex:foo"> <span property="ex:bar">bar</span> </div> should generate an XMLLiteral for ex:foo, but there should be no ex:bar triple. Also, may I draw attention to this again: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Dec/ 0012.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/0E2C633B-5442-408F-BBAB-9AD96D049C39%40g5n.co.uk Re: Markup questions: html/body, datatype="", double predicates 2008-12-15T10:25:24 2008-12-15T10:25:24 2008-12-15T10:25:24 On 15 Dec 2008, at 10:17, Ivan Herman wrote: > But I would still want to have a formal confirmation before I > change my > code! A thorough reading of the processing sequence in the syntax specification shows that recursion should only be stopped when a property with datatype rdf:XMLLiteral is found. I quoted the exact bits in an earlier message: http://lists.w3.org/Archives/Public/public-rdfa/2008Dec/0003.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 15 Dec 2008, at 10:17, Ivan Herman wrote: > But I would still want to have a formal confirmation before I > change my > code! A thorough reading of the processing sequence in the syntax specification shows that recursion should only be stopped when a property with datatype rdf:XMLLiteral is found. I quoted the exact bits in an earlier message: http://lists.w3.org/Archives/Public/public-rdfa/2008Dec/0003.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B39EBC1E-3220-44AD-82AF-D687150C1CD9%40g5n.co.uk Fwd: Crazy jsonSLT and jsonGRDDL idea. 2008-12-15T15:46:31 2008-12-15T15:46:31 2008-12-15T15:46:31 Me, five minutes ago, on json-schema@googlegroups.com... Begin forwarded message: > From: tobyink <mail@tobyinkster.co.uk> > Date: 15 December 2008 15:41:08 GMT > To: JSON Schema <json-schema@googlegroups.com> > Subject: Crazy jsonSLT and jsonGRDDL idea. > Reply-To: json-schema@googlegroups.com > > > Hello, the following is crazy... > > jsonSLT = JSON equivalent of XSLT. Obvious syntax is to use... Me, five minutes ago, on json-schema@googlegroups.com... Begin forwarded message: > From: tobyink <mail@tobyinkster.co.uk> > Date: 15 December 2008 15:41:08 GMT > To: JSON Schema <json-schema@googlegroups.com> > Subject: Crazy jsonSLT and jsonGRDDL idea. > Reply-To: json-schema@googlegroups.com > > > Hello, the following is crazy... > > jsonSLT = JSON equivalent of XSLT. Obvious syntax is to use > ECMAScript, but to avoid tying this to client-side use it should be > ECMAScript which doesn't have to run inside a browser instance (i.e. > no references to "document" or "window". jsonSLT is an ECMAScript file > containing a function called "transform" that takes an object (not a > string, but an object) as input, does some kind of transformation on > it and returns either another object, or a [MIME-type, string] pair. > That is, while XSLT transforms XML into anything (but usually into > XML), jsonSLT transforms JSON into anything (but usually into JSON). > > jsonGRDDL = JSON equivalent of GRDDL. A JSON object includes a "$ref" > link to a JSON schema. The schema in turn contains a "$transform" link > to a jsonSLT file. The jsonSLT file takes the original JSON object as > input and returns an RDF/JSON object. > > ... but it just might work. > > I'm thinking about implementing it in Cognition <http:// > buzzword.org.uk/cognition/>. Anyone interested in helping? > > -Toby -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EBE4873F-E8A5-42F6-95A6-0DB5A14D6BF3%40tobyinkster.co.uk Draft jsonGRDDL spec - bringing JSON to the SemWeb party! 2008-12-15T21:19:49 2008-12-15T21:19:49 2008-12-15T21:19:49 Here's a sketch of an idea, porting GRDDL from XML to JSON: http://buzzword.org.uk/2008/jsonGRDDL/spec I'm about half way to a full implementation, but in the mean time the following works already: <html> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsonobject" type="text/javascript"></script> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsont-sample" type="text... Here's a sketch of an idea, porting GRDDL from XML to JSON: http://buzzword.org.uk/2008/jsonGRDDL/spec I'm about half way to a full implementation, but in the mean time the following works already: <html> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsonobject" type="text/javascript"></script> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsont-sample" type="text/javascript"></script> <script type="text/javascript"> var joe = { "name" : "Joe Bloggs" , "mbox" : "joe@example.net" }; var jane = { "name" : "Jane Doe" , "mbox" : "jane@example.net" }; var group = { "people" : [ joe , jane ] }; window.alert(JSON.transform(jane, Person)); window.alert(JSON.transform(group, People)); </script> </html> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FDD96D09-8765-40B6-8542-A8EBF93FAADC%40g5n.co.uk Draft jsonGRDDL spec - bringing JSON to the SemWeb party! 2008-12-15T21:22:50 2008-12-15T21:22:50 2008-12-15T21:22:50 Here's a sketch of an idea, porting GRDDL from XML to JSON: http://buzzword.org.uk/2008/jsonGRDDL/spec I'm about half way to a full implementation, but in the mean time the following works already: <html> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsonobject" type="text/javascript"></script> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsont-sample" type="text... Here's a sketch of an idea, porting GRDDL from XML to JSON: http://buzzword.org.uk/2008/jsonGRDDL/spec I'm about half way to a full implementation, but in the mean time the following works already: <html> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsonobject" type="text/javascript"></script> <script src="http://buzzword.org.uk/2008/jsonGRDDL/jsont-sample" type="text/javascript"></script> <script type="text/javascript"> var joe = { "name" : "Joe Bloggs" , "mbox" : "joe@example.net" }; var jane = { "name" : "Jane Doe" , "mbox" : "jane@example.net" }; var group = { "people" : [ joe , jane ] }; window.alert(JSON.transform(jane, Person)); window.alert(JSON.transform(group, People)); </script> </html> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D1606792-A26C-46DE-8B1C-AF0A124BBF31%40tobyinkster.co.uk Re: Draft jsonGRDDL spec - bringing JSON to the SemWeb party! 2008-12-16T00:57:58 2008-12-16T00:57:58 2008-12-16T00:57:58 On 15 Dec 2008, at 21:22, Toby A Inkster wrote: > Here's a sketch of an idea, porting GRDDL from XML to JSON: > > http://buzzword.org.uk/2008/jsonGRDDL/spec > > I'm about half way to a full implementation And now I'm fully there! In: http://buzzword.org.uk/2008/jsonGRDDL/example1 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example1 In: http://buzzword.org.uk/2008/jsonGRDDL/example2 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example2 JSON to Turtle! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 15 Dec 2008, at 21:22, Toby A Inkster wrote: > Here's a sketch of an idea, porting GRDDL from XML to JSON: > > http://buzzword.org.uk/2008/jsonGRDDL/spec > > I'm about half way to a full implementation And now I'm fully there! In: http://buzzword.org.uk/2008/jsonGRDDL/example1 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example1 In: http://buzzword.org.uk/2008/jsonGRDDL/example2 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example2 JSON to Turtle! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AF08705D-73A6-454B-BD4E-AED1E604D769%40g5n.co.uk Re: Draft jsonGRDDL spec - bringing JSON to the SemWeb party! 2008-12-16T00:58:44 2008-12-16T00:58:44 2008-12-16T00:58:44 On 15 Dec 2008, at 21:22, Toby A Inkster wrote: > Here's a sketch of an idea, porting GRDDL from XML to JSON: > > http://buzzword.org.uk/2008/jsonGRDDL/spec > > I'm about half way to a full implementation And now I'm fully there! In: http://buzzword.org.uk/2008/jsonGRDDL/example1 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example1 In: http://buzzword.org.uk/2008/jsonGRDDL/example2 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example2 JSON to Turtle! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 15 Dec 2008, at 21:22, Toby A Inkster wrote: > Here's a sketch of an idea, porting GRDDL from XML to JSON: > > http://buzzword.org.uk/2008/jsonGRDDL/spec > > I'm about half way to a full implementation And now I'm fully there! In: http://buzzword.org.uk/2008/jsonGRDDL/example1 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example1 In: http://buzzword.org.uk/2008/jsonGRDDL/example2 Out: http://srv.buzzword.org.uk/turtle/buzzword.org.uk/2008/jsonGRDDL/ example2 JSON to Turtle! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D90C4AA8-47DE-4F4F-B0EB-D7229983D580%40g5n.co.uk RDF-EASE: RDFa in CSS 2008-12-24T14:37:51 2008-12-24T14:37:51 2008-12-24T14:37:51 Draft specification http://buzzword.org.uk/2008/rdf-ease/spec -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Draft specification http://buzzword.org.uk/2008/rdf-ease/spec -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EE17DE61-5A57-4137-9D8D-0EFEAE847492%40g5n.co.uk Re: RDF-EASE: RDFa in CSS 2008-12-31T18:11:03 2008-12-31T18:11:03 2008-12-31T18:11:03 Replying to a few messages in one... On 31 Dec 2008, at 14:04, Ivan Herman wrote: > my superficial reading of the draft suggests me that Rease is > defined in > terms of RDFa. It is. Taking advantage of the RDFa task force's work seemed a sensible shortcut. > Ie, conceptually, an XHTML+Rease document (or even > XHTML+RDFa+Rease document) is transformed into XHTML+RDFa. Actually, a > way of... Replying to a few messages in one... On 31 Dec 2008, at 14:04, Ivan Herman wrote: > my superficial reading of the draft suggests me that Rease is > defined in > terms of RDFa. It is. Taking advantage of the RDFa task force's work seemed a sensible shortcut. > Ie, conceptually, an XHTML+Rease document (or even > XHTML+RDFa+Rease document) is transformed into XHTML+RDFa. Actually, a > way of implementing it (my RDFa implementor's mind starts working:-) > would be to add a pre-processor (like the hGRDDL idea of Ben) to an > RDFa > processor and let the trickier aspects of RDFa be solved by an > existing > processor. > > Toby, is this the idea? If not, I believe it should be:-) Very much so. The current parsing algorithm in the draft has as it's last step "The document is processed to produce triples, as described in §5. Processing Model of [RDFA]." (Though it reference's the RDFa Proposed Recommendation rather than the final RDFa Recommendation at the moment. I'll reference the final Recommendation in the next update to RDF-EASE.) The current parsing algorithm is not very efficient though, nor especially tidy. I plan on writing a replacement algorithm which will instead interleave RDF-EASE steps inside the RDFa algorithm. This would reduce the number of passes over the DOM tree. There is, by the way, a mostly working partial implementation here: http://buzzword.org.uk/2008/rdf-ease/implementation-20081224.pl This does RDF-EASE to RDFa, but doesn't go as far as producing an RDF/ XML file from the RDFa. > I have one technical comment, though. The CSS Working group has > already > published a CSS3 Namespace Module: > > http://www.w3.org/TR/css3-namespace/ > > which uses a slightly different syntax than Rease for a similar > concept. > I think it would be way better to align Rease to this. One could > expect > that CSS parsers of the future would include this namespace facility, > which might greatly facilitate the task of Rease implementers... I had originally planned to use an @rule for defining CURIE prefixes, but the Perl CSS parser (which I've used for my test implementation) chokes on it, which is one reason I chose a slightly odd method. Long term, a deficiency in one particular parser is a poor reason to influence the design of the spec, so I think an @rule should be preferred. I'm not sure about using @namespace though. There have already been some people saying that reusing XML namespaces for CURIE definitions in RDFa might have been a mistake (e.g. it's problematic for DTD- based validation; it makes porting RDFa to non-XML SGML harder), and that it may have been better to define a different method of marking up CURIE prefixes. Perhaps RDF-EASE should use '@prefix dc "http:// purl.org/dc/terms/";' ? Dan Brickley wrote: > Another thought (hmm maybe I mentioned this before) - does the idea > of an RDF-EASE-to-XSLT convertor make sense, so that EASE could > effectively serve as an authoring tool for GRDDL XSLT documents? I think you might have suggested this to me before. My XSLT skills would be nowhere near adequate for such a task - wouldn't even know where to start. But it certainly seems an interesting idea. Giovanni Tummarello wrote: > If that's the case, then RDFa suffices as that and i'd be scared to > propose yet another RDF serialization mechanism. In a way, it's not another RDF serialisation mechanism. There are really two W3C-approved solutions for embedding RDF triples in XHTML: RDFa and GRDDL. GRDDL is open-ended though. GRDDL is incredibly open- ended though, even by usual W3C standards - it allows for transformations to be written in any programming language. (It doesn't even especially recommend any particular programming languages, though it notes that XSLT, especially XSLT1, is well- supported by existing GRDDL implementations.) RDF-EASE simply defines another programming language which may be used - a very simple, non- Turing-complete one. I'm a big fan of RDFa, but I realise that a global switch to RDFa is not going to happen overnight - people will be using Microformats, and creating their own informal microformat-like patterns of classes to mark up their documents, for a long time yet. RDF-EASE just provides them with the easiest way that I can think of to map those patterns to RDF triples. Even for people who would normally write RDFa, RDF-EASE provides some big reductions in key-strokes. To mark up a simple list of names and e-mail addresses in RDFa takes a lot of work: <ul> <li typeof="foaf:Person"> <a rel="foaf:mbox" property="foaf:name" href="mailto:alice@example.net">Alice</a> </li> <li typeof="foaf:Person"> <a rel="foaf:mbox" property="foaf:name" href="mailto:bob@example.net">Bob</a> </li> <li typeof="foaf:Person"> <a rel="foaf:mbox" property="foaf:name" href="mailto:carol@example.net">Carol</a> </li> </ul> Whereas with RDF-EASE you'd get: <ul class="people"> <li><a href="mailto:alice@example.net">Alice</a></li> <li><a href="mailto:bob@example.net">Bob</a></li> <li><a href="mailto:carol@example.net">Carol</a></li> </ul> And: ul.people li { -rdf-typeof: "foaf:Person"; } ul.people li a { -rdf-property: "foaf:name"; -rdf-rel: "foaf:mbox"; } And if you decided to switch from, say, FOAF to the vCard ontology, then the HTML wouldn't need to change - just the transformation. For these reasons, people might find it beneficial to author using XHTML + RDF-EASE and publish plain old RDFa, performing the transformation server-side. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D761DFE3-46D1-412E-985F-94F3E67B1257%40g5n.co.uk RDF-EASE draft updated 2009-01-02T22:10:52 2009-01-02T22:10:52 2009-01-02T22:10:52 I'd like to thank everyone for their interest in my little idea. I've put together an update based on feedback from the group. It can be found at: http://buzzword.org.uk/2008/rdf-ease/spec-20090102 I've redefined "-rdf-datatype" which was fairly odd before, and somewhat at odds with RDFa, and indeed RDF generally, in that it allowed a literal to take multiple datatypes. It no longer doe... I'd like to thank everyone for their interest in my little idea. I've put together an update based on feedback from the group. It can be found at: http://buzzword.org.uk/2008/rdf-ease/spec-20090102 I've redefined "-rdf-datatype" which was fairly odd before, and somewhat at odds with RDFa, and indeed RDF generally, in that it allowed a literal to take multiple datatypes. It no longer does. I've changed CURIE prefix definitions to use an at-rule instead of the funny underscore syntax. e.g. @prefix foaf "http://xmlns.com/foaf/0.1/"; @prefix ex1 "http://example.com/ns1#"; I've restructured the parsing algorithm. This used to loop through the rules in the RDF-EASE file, find the DOM nodes each rule selected and then apply the RDF-EASE properties to the node. Now it loops though the DOM, finds the rules in the RDF-EASE file that apply to it, and then applies the RDF-EASE properties to the node. Seems like a minor and unimportant change, but it will ensure that each DOM node is visited only once on that crawl - and do so in a predictable order - which will make it easier to resolve one of the other items on my todo list in the next few days. Lastly, I've clarified the licensing of the document. It's under Creative Commons' BY-SA license, but I wanted to make it clear that for the purposes of licensing, implementations are not considered to be derivative works. I hope to have a web service available in the next few days where people can try out RDF-EASE. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BB963207-57E2-4517-BDDE-A41F2C55D86C%40g5n.co.uk XHTML Vocab document 2009-01-08T15:02:37 2009-01-08T15:02:37 2009-01-08T15:02:37 I've pointed this out before, but haven't had a response. If you look at <http://www.w3.org/1999/xhtml/vocab/> you will see markup along the lines of: > <dt id="chapter" about="#chapter" typeof="rdf:Property">chapter</dt> > <dd about="#chapter" property="rdfs:comment" > datatype="xsd:string"><span>chapter</span> refers to a > resource serving > as a chapter in a collction. ... I've pointed this out before, but haven't had a response. If you look at <http://www.w3.org/1999/xhtml/vocab/> you will see markup along the lines of: > <dt id="chapter" about="#chapter" typeof="rdf:Property">chapter</dt> > <dd about="#chapter" property="rdfs:comment" > datatype="xsd:string"><span>chapter</span> refers to a > resource serving > as a chapter in a collction. </dd> This creates the triples: <http://www.w3.org/1999/xhtml/vocab/#chapter> a rdf:Property ; rdfs:comment """chapter refers to a resource service as a chapter in a collction. """^^xsd:string . (Note typo in "collection", but that's not my main point.) However, because the xhv namespace is <http://www.w3.org/1999/xhtml/vocab#>, what we'd really like to see is: <http://www.w3.org/1999/xhtml/vocab#chapter> a rdf:Property ; rdfs:comment """chapter refers to a resource service as a chapter in a collction. """^^xsd:string . Note the resource's URI has had a slash removed. Two possible routes to fixing this would be: 1. change the URI of the document to <http://www.w3.org/1999/xhtml/ vocab> (no trailing slash); or 2. add a <base> element to the document. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/90FC9F4E-A6CD-4885-ABB2-53C13CC04BCF%40g5n.co.uk RDF-EASE + GRDDL implementation 2009-01-09T22:50:00 2009-01-09T22:50:00 2009-01-09T22:50:00 The RDF-EASE draft specification is here: <http://buzzword.org.uk/2008/rdf-ease/spec> Ten second sales pitch: CSS is an external file that specifies how your document should look; RDF-EASE is an external file that specifies what your document means. Essentially, RDF-EASE is an alternative to XSLT operating within the GRDDL framework. I've set up a very base XHTML file here: <http://example... The RDF-EASE draft specification is here: <http://buzzword.org.uk/2008/rdf-ease/spec> Ten second sales pitch: CSS is an external file that specifies how your document should look; RDF-EASE is an external file that specifies what your document means. Essentially, RDF-EASE is an alternative to XSLT operating within the GRDDL framework. I've set up a very base XHTML file here: <http://examples.tobyinkster.co.uk/rdfease1.html> And a transformation here: <http://examples.tobyinkster.co.uk/rdfease1.css> And here is the result: <http://srv.buzzword.org.uk/rdf-ease.cgi?uri=http:// examples.tobyinkster.co.uk/rdfease1.html> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9F64FAB5-28CC-4E27-8DBC-E4E5C04202F4%40g5n.co.uk Re: meeting record: 2009-01-08 RDF-in-XHTML TF telecon 2009-01-10T10:11:25 2009-01-10T10:11:25 2009-01-10T10:11:25 Sergey Chernyshev wrote: > the next question is which set of RDF ontologies to use > to replace specific Microformats. Take a look at: http://semanticweb.org/wiki/Microformats_in_RDF Another thing you could try is writing a page using the microformat in question, running it through <http://buzzword.org.uk/swignition/ try> and seeing what RDF is generated. For example, Tantek Celik's homepa... Sergey Chernyshev wrote: > the next question is which set of RDF ontologies to use > to replace specific Microformats. Take a look at: http://semanticweb.org/wiki/Microformats_in_RDF Another thing you could try is writing a page using the microformat in question, running it through <http://buzzword.org.uk/swignition/ try> and seeing what RDF is generated. For example, Tantek Celik's homepage uses a mixture of hCard, hCalendar, hAtom and XFN. The result in N3 <http://srv.buzzword.org.uk/n3/tantek.com/> includes the following prefixes: @prefix awol: <http://bblfish.net/work/atom-owl/2006-06-06/#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix hcterms: <http://purl.org/uF/hCard/terms/> . @prefix i: <http://www.w3.org/2002/12/cal/ical#> . @prefix ix: <http://buzzword.org.uk/rdf/icalx#> . @prefix plink: <http://buzzword.org.uk/rdf/personal-link-types#> . @prefix tag: <http://www.holygoat.co.uk/owl/redwood/0.1/tags/> . @prefix v: <http://www.w3.org/2006/vcard/ns#> . @prefix vx: <http://buzzword.org.uk/rdf/vcardx#> . @prefix xfn: <http://vocab.sindice.com/xfn#> . (Amongst others.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8970E6B1-F215-465C-B57A-EADF57F7A913%40tobyinkster.co.uk Re: The war of the worlds: HTML vs. RDF 2009-01-10T16:44:09 2009-01-10T16:44:09 2009-01-10T16:44:09 Tom Morris wrote: > You can do that already with HTML 4 and XHTML 1.x using GRDDL. GRDDL > no longer works in HTML 5 as the profile attribute has been removed. > (We get some nonsense about GRDDL still working but just not > 'requiring' profile. This is nonsense. It's a bit like saying that > you've taken the wheels off the car but it still works because you can > turn the engine on.) I think mu... Tom Morris wrote: > You can do that already with HTML 4 and XHTML 1.x using GRDDL. GRDDL > no longer works in HTML 5 as the profile attribute has been removed. > (We get some nonsense about GRDDL still working but just not > 'requiring' profile. This is nonsense. It's a bit like saying that > you've taken the wheels off the car but it still works because you can > turn the engine on.) I think much of this nonsense has arisen because GRDDL effectively uses the profile attribute for two purposes, and that has gotten people confused. By taking care of one of the purposes in HTML5, it has been assumed that GRDDL will thus work in HTML5; tick it off the list; done; taken care of. GRDDL uses the profile attribute firstly as a flag which says "this page has some GRDDL transformations linked from it". HTML5 has said that all pages may have GRDDL transformations linked from them, thus this flag is not needed in HTML5. Fair enough, you can say "this works in HTML5 without requiring a profile" and that will work. It introduces incompatibilities between how GRDDL is processed in HTML5 and how it is processed in earlier versions of (X)HTML, which is annoying (particularly as XHTML does not require a DOCTYPE, so there is no easy way of differentiating between XHTML5 and earlier versions of XHTML) but still doable. But GRDDL uses the profile attribute in another manner: a GRDDL agent is supposed to loop through all the page's profiles, perform an HTTP request for each one, and use the data it finds in them. If you say "this works in HTML5 without requiring a profile" then that is clearly nonsense. To loop through the profiles, there has to be some profiles! rel="profile" does work as a substitute here, but again it introduces inconsistencies between HTML5 and previous versions of (X) HTML. This syntax change for linking to profiles seems to be an entirely gratuitous one: if profiles are going to be allowed, then why change the syntax for them? As an analogy, there are many very good arguments both ways for dropping or retaining the <b> and <i> elements, but to suggest renaming them instead to <bold> and <italic> would be silly - even if the unabbreviated names would be clearer, the headaches caused by the syntax change would be massive. Similarly, rel="profile" does seem like a slightly nicer syntax than the profile attribute, but that small advantage comes at a cost of breaking compatibility with existing tools that use profiles. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/85614A79-E0E4-402A-8D2B-0BC46D66FCB7%40g5n.co.uk Re: The war of the worlds: HTML vs. RDF 2009-01-10T16:44:58 2009-01-10T16:44:58 2009-01-10T16:44:58 Tom Morris wrote: > You can do that already with HTML 4 and XHTML 1.x using GRDDL. GRDDL > no longer works in HTML 5 as the profile attribute has been removed. > (We get some nonsense about GRDDL still working but just not > 'requiring' profile. This is nonsense. It's a bit like saying that > you've taken the wheels off the car but it still works because you can > turn the engine on.) I think mu... Tom Morris wrote: > You can do that already with HTML 4 and XHTML 1.x using GRDDL. GRDDL > no longer works in HTML 5 as the profile attribute has been removed. > (We get some nonsense about GRDDL still working but just not > 'requiring' profile. This is nonsense. It's a bit like saying that > you've taken the wheels off the car but it still works because you can > turn the engine on.) I think much of this nonsense has arisen because GRDDL effectively uses the profile attribute for two purposes, and that has gotten people confused. By taking care of one of the purposes in HTML5, it has been assumed that GRDDL will thus work in HTML5; tick it off the list; done; taken care of. GRDDL uses the profile attribute firstly as a flag which says "this page has some GRDDL transformations linked from it". HTML5 has said that all pages may have GRDDL transformations linked from them, thus this flag is not needed in HTML5. Fair enough, you can say "this works in HTML5 without requiring a profile" and that will work. It introduces incompatibilities between how GRDDL is processed in HTML5 and how it is processed in earlier versions of (X)HTML, which is annoying (particularly as XHTML does not require a DOCTYPE, so there is no easy way of differentiating between XHTML5 and earlier versions of XHTML) but still doable. But GRDDL uses the profile attribute in another manner: a GRDDL agent is supposed to loop through all the page's profiles, perform an HTTP request for each one, and use the data it finds in them. If you say "this works in HTML5 without requiring a profile" then that is clearly nonsense. To loop through the profiles, there has to be some profiles! rel="profile" does work as a substitute here, but again it introduces inconsistencies between HTML5 and previous versions of (X) HTML. This syntax change for linking to profiles seems to be an entirely gratuitous one: if profiles are going to be allowed, then why change the syntax for them? As an analogy, there are many very good arguments both ways for dropping or retaining the <b> and <i> elements, but to suggest renaming them instead to <bold> and <italic> would be silly - even if the unabbreviated names would be clearer, the headaches caused by the syntax change would be massive. Similarly, rel="profile" does seem like a slightly nicer syntax than the profile attribute, but that small advantage comes at a cost of breaking compatibility with existing tools that use profiles. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E8C694C8-A7C8-4D38-9E1B-DD578B39BB63%40tobyinkster.co.uk Parsing RDFa in Feeds 2009-01-13T10:38:12 2009-01-13T10:38:12 2009-01-13T10:38:12 I've recently implemented support for this in Swignition <http:// buzzword.org.uk/swignition/> and thought I'd share my technique. First I use Raptor <http://librdf.org/raptor/> to parse the feed. This results in a graph (which we'll call "G") including a number of resources with rdf:type <http://purl.org/rss/1.0/item>. I loop through these resources, and for each resource (which we'll cal... I've recently implemented support for this in Swignition <http:// buzzword.org.uk/swignition/> and thought I'd share my technique. First I use Raptor <http://librdf.org/raptor/> to parse the feed. This results in a graph (which we'll call "G") including a number of resources with rdf:type <http://purl.org/rss/1.0/item>. I loop through these resources, and for each resource (which we'll call "R"): 1. If R does not have a content:encoded predicate, ignore it and go on to the next resource. Note that the full URI for content:encoded is <http://purl.org/rss/1.0/modules/content/encoded>, but some versions of Raptor erroneously use <http://web.resource.org/rss/1.0/ modules/content/encoded>, so you should check both. (I have different versions of librdf on my laptop and desktop, so come across this sort of thing all the time!) 2. Concatenate "<html>" then the content:encoded literal (hopefully there will be only one) then "</html>". Pass this through a tag soup HTML to valid XHTML conversion routine. 3. Parse the XHTML as RDFa with a base URI equal to R's URI. This results in a graph "H". 4. Merge the triples from graph H into graph G taking care not to confuse similarly-named blank nodes. (i.e. if G contains a node _:Foo and H also contains a node _:Foo, then these should not be treated as the same node in the merged graph.) In the end, all the data are belong to G. Open question: should XML namespaces used in the Feed be "inherited" as CURIE prefixes within the XHTML parsed in the step labelled "3"? I can see arguments either way. Overall, I feel that they should not. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E213BEFF-532C-4F48-B041-458BA3F73464%40g5n.co.uk Parsing RDFa in Feeds 2009-01-13T10:54:00 2009-01-13T10:54:00 2009-01-13T10:54:00 I've recently implemented support for this in Swignition <http:// buzzword.org.uk/swignition/> and thought I'd share my technique. First I use Raptor <http://librdf.org/raptor/> to parse the feed. This results in a graph (which we'll call "G") including a number of resources with rdf:type <http://purl.org/rss/1.0/item>. I loop through these resources, and for each resource (which we'll cal... I've recently implemented support for this in Swignition <http:// buzzword.org.uk/swignition/> and thought I'd share my technique. First I use Raptor <http://librdf.org/raptor/> to parse the feed. This results in a graph (which we'll call "G") including a number of resources with rdf:type <http://purl.org/rss/1.0/item>. I loop through these resources, and for each resource (which we'll call "R"): 1. If R does not have a content:encoded predicate, ignore it and go on to the next resource. Note that the full URI for content:encoded is <http://purl.org/rss/1.0/modules/content/encoded>, but some versions of Raptor erroneously use <http://web.resource.org/rss/1.0/ modules/content/encoded>, so you should check both. (I have different versions of librdf on my laptop and desktop, so come across this sort of thing all the time!) 2. Concatenate "<html>" then the content:encoded literal (hopefully there will be only one) then "</html>". Pass this through a tag soup HTML to valid XHTML conversion routine. 3. Parse the XHTML as RDFa with a base URI equal to R's URI. This results in a graph "H". 4. Merge the triples from graph H into graph G taking care not to confuse similarly-named blank nodes. (i.e. if G contains a node _:Foo and H also contains a node _:Foo, then these should not be treated as the same node in the merged graph.) In the end, all the data are belong to G. Open question: should XML namespaces used in the Feed be "inherited" as CURIE prefixes within the XHTML parsed in the step labelled "3"? I can see arguments either way. Overall, I feel that they should not. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FB5C5308-5E06-4353-84FE-F6025F216908%40g5n.co.uk New Perl RDFa Parser 2009-01-13T16:30:10 2009-01-13T16:30:10 2009-01-13T16:30:10 Someone asked on IRC today about using Swignition as an RDFa parser in a tool they were building. I suggested that SPREAD might be a better idea as it probably has fewer external dependencies, while Swignition has a lot of dependencies as it does a lot more than just parsing RDFa. However, neither of us could find any source code for SPREAD online, so I spent the best part of my lunch ho... Someone asked on IRC today about using Swignition as an RDFa parser in a tool they were building. I suggested that SPREAD might be a better idea as it probably has fewer external dependencies, while Swignition has a lot of dependencies as it does a lot more than just parsing RDFa. However, neither of us could find any source code for SPREAD online, so I spent the best part of my lunch hour forking Swignition's RDFa module so that it can run outside of the rest of the project. The result is here: http://cognition-parser.googlecode.com/svn/trunk/swignition/extras/ RDF-RDFa-Parser/lib/RDF/RDFa/Parser.pm -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EE488A53-84F2-4BCF-BF6C-128A5960B927%40g5n.co.uk Re: New Perl RDFa Parser 2009-01-13T17:08:53 2009-01-13T17:08:53 2009-01-13T17:08:53 On 13 Jan 2009, at 16:50, Dan Brickley wrote: > Does it have the same behaviours as http://buzzword.org.uk/ > swignition/rdfa ? There's a note at the bottom of that page that describes which quirks they share. > I don't entirely like having my RDF rewritten to include un- > intended references to http://thing-described-by.org/ - although I > can see value in having this as an opt-in featu... On 13 Jan 2009, at 16:50, Dan Brickley wrote: > Does it have the same behaviours as http://buzzword.org.uk/ > swignition/rdfa ? There's a note at the bottom of that page that describes which quirks they share. > I don't entirely like having my RDF rewritten to include un- > intended references to http://thing-described-by.org/ - although I > can see value in having this as an opt-in feature. > > Ah, I see > 'tdb' => 1, # Switch to 0 to turn off t-d-b.org feature. > ... can I suggest the default be for usage to require explicit opt-in? I'll consider that for 0.02. > Context - I'm looking at XML Signature for RDFa currently, and I > need RDFa parsers that emit the graph that the signed document > encodes. While thing-described-by is a cool idea, I can't find a > privacy policy for the site. I'd prefer to know whether it keeps > HTTP logs before using it in real apps. David Booth, who set it up, encourages people to build optimisations into their apps that bypass his domain entirely, so when looking for a description of http://thing-described-by.org?foo to simply request foo directly. I've CCed David - is there a privacy policy for t-d-b.org? > Back re RDFa parsing --- does the new Perl code pass all the tests? > And will it be in CPAN soon? :) It almost certainly fails some of the XML Literal ones. Other than that I would expect it to mostly work properly. It's been uploaded to PAUSE and I'm waiting for the module namespace to be approved for CPAN. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CEC2B968-32D5-42EE-8D38-74AE0ABE9227%40g5n.co.uk Re: New Perl RDFa Parser 2009-01-13T23:01:32 2009-01-13T23:01:32 2009-01-13T23:01:32 On 13 Jan 2009, at 16:50, Dan Brickley wrote: > And will it be in CPAN soon? :) http://search.cpan.org/~tobyink/RDF-RDFa-Parser-0.01/lib/RDF/RDFa/ Parser.pm -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 13 Jan 2009, at 16:50, Dan Brickley wrote: > And will it be in CPAN soon? :) http://search.cpan.org/~tobyink/RDF-RDFa-Parser-0.01/lib/RDF/RDFa/ Parser.pm -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/042D08D7-CE06-4AAC-9B4E-5BABCEDBDE72%40g5n.co.uk W3C validator 2009-01-14T09:53:24 2009-01-14T09:53:24 2009-01-14T09:53:24 What would be nice would be if the "Congratulations" message for the XHTML+RDFa doctype gave valid icon markup like this: <p xmlns:dct="http://purl.org/dc/terms/" about="" rel="dct:conformsTo" resource="http://www.w3.org/TR/rdfa-syntax/"> <a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-xhtml-rdfa-blue" alt="Valid XHTML + RDFa" /></a> </p> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> What would be nice would be if the "Congratulations" message for the XHTML+RDFa doctype gave valid icon markup like this: <p xmlns:dct="http://purl.org/dc/terms/" about="" rel="dct:conformsTo" resource="http://www.w3.org/TR/rdfa-syntax/"> <a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-xhtml-rdfa-blue" alt="Valid XHTML + RDFa" /></a> </p> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B4AC2FBC-63DD-4227-AA14-4541D9159FE3%40g5n.co.uk Re: any23: stop writes libraries in Java, portable code is needed 2009-01-15T00:22:36 2009-01-15T00:22:36 2009-01-15T00:22:36 Dmitry Ulanov wrote: > Yesterday, Richard announced a new any23 project [1]. It's a different > question why we need a new one. I have an idea (thanks for Yaroslav > Markin). > Why not to implement such converters in Ragel [2] in general form > and than > translate them into different programming languages instead of just > Java? I > don't like Java and prefer Ruby, for an example. The que... Dmitry Ulanov wrote: > Yesterday, Richard announced a new any23 project [1]. It's a different > question why we need a new one. I have an idea (thanks for Yaroslav > Markin). > Why not to implement such converters in Ragel [2] in general form > and than > translate them into different programming languages instead of just > Java? I > don't like Java and prefer Ruby, for an example. The question could be turned around and asked, why do you prefer to write in Ruby? Why don't you write in a general form which can be converted into Java and then hooked into Any23? Different people prefer different programming languages; and many people prefer several languages in different situations. You're never going to get everyone to agree to use the same programming language. My project <http://buzzword.org.uk/swignition/> is pretty similar to any23 in concept (i.e. aims at converting pretty much anything and everything to RDF) and is written in Perl. But you don't need to be a Perl programmer to use it because you can run it as a background daemon, and then your program (written in whatever language you like) can connect to it via TCP, tweak its options, pass a URI, and get back RDF/JSON (or RDF/XML, Notation 3, etc). I've only briefly skimmed its documentation today, but I imagine that Any23 has a similar facility. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/59667.81.2.120.180.1232120523.squirrel%40goddamn.co.uk subscribe 2009-01-16T15:42:03 2009-01-16T15:42:03 2009-01-16T15:42:03 subscribe subscribe http://tobyinkster.co.uk/message/63355.81.2.120.180.1232120797.squirrel%40goddamn.co.uk Re: CONFIRM s117384783 2009-01-16T15:46:37 2009-01-16T15:46:37 2009-01-16T15:46:37 > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-social-web-talk mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-social-web-talk-request@w3.org > > with the Subject string: > > CONFIRM s11... > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-social-web-talk mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-social-web-talk-request@w3.org > > with the Subject string: > > CONFIRM s117384783 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed above > will be (un)subscribed. If the address above is incorrect, please do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event that > you did not send a request to (un)subscribe, the headers of the message > may help you discover who sent the request. > > >From tai@g5n.co.uk Fri Jan 16 15:42:44 2009 >>Received: from bart.w3.org ([128.30.52.63]) >> by frink.w3.org with esmtp (Exim 4.63) >> (envelope-from <tai@g5n.co.uk>) >> id 1LNqqK-0001Ei-7w >> for public-social-web-talk-request@listhub.w3.org; Fri, 16 Jan 2009 >> 15:42:44 +0000 >>Received: from ophelia.g5n.co.uk ([81.2.120.180]) >> by bart.w3.org with esmtp (Exim 4.63) >> (envelope-from <tai@g5n.co.uk>) >> id 1LNqqB-0003Sd-OX >> for public-social-web-talk-request@w3.org; Fri, 16 Jan 2009 10:42:44 >> -0500 >>Received: by ophelia.g5n.co.uk (Postfix, from userid 82) >> id F2E8BB9804; Fri, 16 Jan 2009 15:42:02 +0000 (GMT) >>Received: from 81.2.120.180 >> (SquirrelMail authenticated user tai) >> by goddamn.co.uk with HTTP; >> Fri, 16 Jan 2009 15:42:02 -0000 (UTC) >>Message-ID: <59667.81.2.120.180.1232120522.squirrel@goddamn.co.uk> >>Date: Fri, 16 Jan 2009 15:42:02 -0000 (UTC) >>Subject: subscribe >>From: "Toby Inkster" <tai@g5n.co.uk> >>To: public-social-web-talk-request@w3.org >>User-Agent: SquirrelMail/1.4.13 >>MIME-Version: 1.0 >>Content-Type: text/plain;charset=iso-8859-1 >>X-Priority: 3 (Normal) >>Importance: Normal >>Content-Transfer-Encoding: quoted-printable >>Received-SPF: none >>X-SPF-Guess: pass >>X-W3C-Hub-Spam-Status: No, score=-0.7 >>X-W3C-Hub-Spam-Report: BAYES_20=-0.74 >>X-W3C-Scan-Sig: bart.w3.org 1LNqqB-0003Sd-OX >> a740be43933690cd59b506025cdcdcde >> >>subscribe >> > http://tobyinkster.co.uk/message/F53615E4-7236-44B7-81DF-22B0CC30F323%40g5n.co.uk Re: full URIs where a CURIE expected? 2009-01-18T23:39:43 2009-01-18T23:39:43 2009-01-18T23:39:43 Nope, not allowed. The RDFa spec says: "the mapping to use when there is no prefix is not defined, which effectively prohibits the use of CURIEs that do not contain a colon". The validator doesn't complain because the validator just checks the page against the DTD, which defines the RDFa attributes as containing plain old CDATA. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Nope, not allowed. The RDFa spec says: "the mapping to use when there is no prefix is not defined, which effectively prohibits the use of CURIEs that do not contain a colon". The validator doesn't complain because the validator just checks the page against the DTD, which defines the RDFa attributes as containing plain old CDATA. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/0C3DFAFD-DA35-4000-8EFB-009E97BBFBEF%40g5n.co.uk Re: Validator for HTML5+RDFa minus CURIEs 2009-01-20T09:34:07 2009-01-20T09:34:07 2009-01-20T09:34:07 [Manu, sorry you got two copies of this. I initially sent it with my other e-mail address which the W3C listserv doesn't like.] Manu Sporny wrote: > You can test it out on the following example that Dan Brickley put > together (and I modified, slightly): > > http://rdfa.digitalbazaar.com/demos/html5/nocuries.html For what its worth, Swignition has supported full URIs in RDFa attributes pret... [Manu, sorry you got two copies of this. I initially sent it with my other e-mail address which the W3C listserv doesn't like.] Manu Sporny wrote: > You can test it out on the following example that Dan Brickley put > together (and I modified, slightly): > > http://rdfa.digitalbazaar.com/demos/html5/nocuries.html For what its worth, Swignition has supported full URIs in RDFa attributes pretty much since I first implemented RDFa support: http://srv.buzzword.org.uk/turtle/rdfa.digitalbazaar.com/demos/html5/ nocuries.html If, say, an "http" CURIE prefix is defined, then it will be used, but if the CURIE->URI code finds that the CURIE has not been defined, then it falls back to treating it as a URI. This is not specific to "http" - I just used that as an example - similarly if "skos" is used but hasn't been defined, then "skos:Concept" will be treated as it it were an absolute URI! Manu also wrote, regarding <meta name="prefix">: > This was discussed as a possibility at one point, I don't quite > remember > what the argument was against it. Perhaps somebody else on the list > can > remember? I can't remember this exact syntax being suggested, but I suggested: <link rel="schema.foaf" href="http://xmlns.com/foaf/0.1/"> Which is what eRDF uses. One objection people had to it was that it didn't offer a method to scope a prefix declaration to just part of the page. This can be addressed by adding about="#foo" to the <link> and then id="foo" to the part of the page though. Another more important objection, which I have conceded is a good argument against it, is that it forces all prefix declarations to be in the <head> of the document. This means that people can't easily offer all-in-one chunks of RDFa for people to use on their pages. e.g. Creative Commons gives a snippet of XHTML for people to paste into their pages - with xmlns prefix declarations (or with @prefix) they could include the declarations in the same snippet of code. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/60627.81.2.120.180.1232448165.squirrel%40goddamn.co.uk Re: Validator for HTML5+RDFa minus CURIEs 2009-01-20T10:42:45 2009-01-20T10:42:45 2009-01-20T10:42:45 > Another problem with having to define prefixes upfront is that it makes > streaming production of output really hard -- if you don't know ahead of > time which namespaces you'll need you will be forced to include *all* of > them (whatever "all" means here) in the header. That is true. It's not a problem I've had with RDFa per se, but in programmatically producing Atom, where the feed's <updated... > Another problem with having to define prefixes upfront is that it makes > streaming production of output really hard -- if you don't know ahead of > time which namespaces you'll need you will be forced to include *all* of > them (whatever "all" means here) in the header. That is true. It's not a problem I've had with RDFa per se, but in programmatically producing Atom, where the feed's <updated> date is required to come before the <entry> elements are listed. But the feed <updated> date is calculated by taking the most recent of the entry <updated> dates, so after writing the entries, I need to go *back* and fix the feed <updated> date. I wouldn't suggest creating a situation where similar annoyances will occur with RDFa. This is a strong argument against requiring CURIE prefixes to be declared in the <head> - the ability to declare them close to where they are used is very useful. -Toby http://tobyinkster.co.uk/message/60923.81.2.120.180.1232792998.squirrel%40goddamn.co.uk Re: Poll: Who would join Social Web XG(s)? 1 or 2 XGs? Telecons? 2009-01-24T10:29:58 2009-01-24T10:29:58 2009-01-24T10:29:58 Harry Halpin wrote: > 1) Who would join the Social Web XG? Please add if you are a W3C member > or not, and if your organization would join W3C. Yes, if they'd have me. No. No. > 2) Would you prefer one or two XGs? One XG focused on interoperability > between exisiting work on the social web, and another focused on Best > Practices? Or should these be done as one XG? Interoperability surely is... Harry Halpin wrote: > 1) Who would join the Social Web XG? Please add if you are a W3C member > or not, and if your organization would join W3C. Yes, if they'd have me. No. No. > 2) Would you prefer one or two XGs? One XG focused on interoperability > between exisiting work on the social web, and another focused on Best > Practices? Or should these be done as one XG? Interoperability surely is a best practice! (Or am I begging the question?) One. > 3) Regardless of one or two XGs, different telecons but same listserv to > facilitate communication? Or one telecon? One everything. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/53EF6CA4-CBCB-418E-A2C3-1B789AE66B97%40g5n.co.uk Re: Poll: Who would join Social Web XG(s)? 1 or 2 XGs? Telecons? 2009-01-24T10:44:35 2009-01-24T10:44:35 2009-01-24T10:44:35 Harry Halpin wrote: > 1) Who would join the Social Web XG? Please add if you are a W3C > member > or not, and if your organization would join W3C. Yes, if they'd have me. No. No. > 2) Would you prefer one or two XGs? One XG focused on interoperability > between exisiting work on the social web, and another focused on Best > Practices? Or should these be done as one XG? Interoperability surel... Harry Halpin wrote: > 1) Who would join the Social Web XG? Please add if you are a W3C > member > or not, and if your organization would join W3C. Yes, if they'd have me. No. No. > 2) Would you prefer one or two XGs? One XG focused on interoperability > between exisiting work on the social web, and another focused on Best > Practices? Or should these be done as one XG? Interoperability surely is a best practice! (Or am I begging the question?) One. > 3) Regardless of one or two XGs, different telecons but same > listserv to > facilitate communication? Or one telecon? One everything. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D90AE3A8-78CC-4183-9864-36EDA5B6FBAF%40tobyinkster.co.uk Re: Validation issue with the xsi namespace 2009-01-24T22:51:47 2009-01-24T22:51:47 2009-01-24T22:51:47 Christoph Lange wrote: > Suppose xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance", what > would xsi:lala > expand to? Nothing reasonable, I suppose, so why do such namespace > URIs > exist? In RDFa terms, it would expand to http://www.w3.org/2001/XMLSchema- instancelala. Ugly, but that's how it's defined. See the sections in the syntax specification which deal with the definition of... Christoph Lange wrote: > Suppose xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance", what > would xsi:lala > expand to? Nothing reasonable, I suppose, so why do such namespace > URIs > exist? In RDFa terms, it would expand to http://www.w3.org/2001/XMLSchema- instancelala. Ugly, but that's how it's defined. See the sections in the syntax specification which deal with the definition of CURIEs. In RDF/XML the answer would be the same: the syntax spec says "The RDF URI reference represented by a QName is determined by appending the local name part of the QName after the namespace name (URI reference) part of the QName." You'll probably find similar answers for the other RDF serialisations that use CURIEs or QNames. In general XML terms, a namespace plus local name do not "expand" to anything - they are simply a pair. The idea of expanding them is RDF- specific. This is why there are a number of namespace URIs that do not end in a hash or slash - they are like that because they were never intended to be used as RDF vocabularies. e.g. the XHTML namespace is "http://www.w3.org/1999/xhtml". One thing I've noticed in the hash vs slash discussion is that '=' and '?' are rarely talked about as suitable final characters for namespace URIs. They seem ideal to me. e.g. xmlns:ex1="http://example.com/myterms?term=" xmlns:ex2="http://example.net/some-vocab?" -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C957261C-4AF6-4B38-A1FC-DC5171813B2C%40g5n.co.uk Re: Validation issue with the xsi namespace 2009-01-25T08:57:49 2009-01-25T08:57:49 2009-01-25T08:57:49 Christoph Lange wrote: > Hmm, I hope it's not getting to philosophical now ;-) I'm sure > it's no longer > related to Stéphane's original question, but nevertheless let me > ask: Wouldn't > it, in some cases, be reasonable to make XML namespace URIs usable as > vocabulary URIs? What URI would, e.g., the xhtml:h1 element have > if you > wanted to talk about it in RDF like … > > xhtml:h1 > ... Christoph Lange wrote: > Hmm, I hope it's not getting to philosophical now ;-) I'm sure > it's no longer > related to Stéphane's original question, but nevertheless let me > ask: Wouldn't > it, in some cases, be reasonable to make XML namespace URIs usable as > vocabulary URIs? What URI would, e.g., the xhtml:h1 element have > if you > wanted to talk about it in RDF like … > > xhtml:h1 > a :XHTMLElement ; > :content :text ; > ... . Actually I had a very similar need. The choice was between using the XHTML namespace as-is, which would result in funny looking URIs like <http://www.w3.org/1999/xhtmlh1>; tacking an extra '#' on to the XHTML namespace; or defining my own URIs for XHTML elements. In the end, I opted for the third solution: http://buzzword.org.uk/rdf/xhtml-elements# The ultimate point of it being: http://buzzword.org.uk/rdf/sections# -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/62461.81.2.120.180.1232976645.squirrel%40goddamn.co.uk Re: Discussion with Ian and Henri about HTML5+RDFa (part 2/2) 2009-01-26T13:30:45 2009-01-26T13:30:45 2009-01-26T13:30:45 San Ruby wrote: > Henri and Dan have noted that by accepting "xmlns:html='html'" and > limiting oneself to full URIs you get to the point where you have a > document which can be processed correctly by many RDF parsers. To be pedantic, it's xmlns:http="http:" (Note the colon in the attribute value.) As far as I can see, it's a reasonable compromise. RDFa parsers will probably need some updating... San Ruby wrote: > Henri and Dan have noted that by accepting "xmlns:html='html'" and > limiting oneself to full URIs you get to the point where you have a > document which can be processed correctly by many RDF parsers. To be pedantic, it's xmlns:http="http:" (Note the colon in the attribute value.) As far as I can see, it's a reasonable compromise. RDFa parsers will probably need some updating for HTML5 anyway (e.g. the proposed @prefix), so it shouldn't hurt to include this. I'd suggest not specifying it in a way that says that there is a hard-coded xmlns:http="http:" on the root element though. It should be hard-coded at an imaginary level "above" the root element, thus allowing authors to override it if need be (e.g. there is the HTTP-in-RDF vocabulary that allows for HTTP requests and responses to be described in RDF). In terms of the RDFa syntax document's processing sequence it could be implemented by making the list of URI mappings non-empty in the initial evaluation context. <http://www.w3.org/TR/rdfa-syntax/#sec_5.5.> > What other desirable and undesirable social effects would there be by > identifying a registry for well-known namespaces? When a new prefix was added to the registry, it would presumably take weeks, months or even years for it to trickle down to RDFa parsers. (Unless the registry was machine readable and RDFa parsers were obliged to query it frequently, which would create a central bottleneck of precisely the type that RDF was designed to avoid.) During the trickle-down period, authors would be wary of using the prefix, as their experience using it would be inconsistent. I don't think an evolving list of default prefixes is a good solution, though a static list of pre-defined prefixes is workable, provided authors have a mechanism such as @prefix to define their own prefixes and override the predefined ones. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/64895.81.2.120.180.1232977665.squirrel%40goddamn.co.uk Re: Validation issue with the xsi namespace 2009-01-26T13:47:45 2009-01-26T13:47:45 2009-01-26T13:47:45 > If the W3C validator returns an error when the xsi XML namespace is not > well defined, then I would expect the same for the xsd XML namespace. > However both > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsd="http://www.w3.org/2001/XMLSchema#" > validate in XHTML+RDFa. The W3C validator doesn't really understand namespaces - in general it simply ignores them - as is happening with "xm... > If the W3C validator returns an error when the xsi XML namespace is not > well defined, then I would expect the same for the xsd XML namespace. > However both > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsd="http://www.w3.org/2001/XMLSchema#" > validate in XHTML+RDFa. The W3C validator doesn't really understand namespaces - in general it simply ignores them - as is happening with "xmlns:xsd" in your example. However, in some DTDs, certain namespaces are hardcoded to certain prefixes. This is supposed to be helpful, but in real life is at best confusing and at worst a pain in the arse. "xmlns:xsi" is one such namespace. It's hard-coded in http://www.w3.org/MarkUp/DTD/xhtml-qname-1.mod, so any DTDs which reference that module (which is most XHTML DTDs) end up with this strange requirement - that if you decide to define "xmlns:xsi" in your document, then you must define it as "http://www.w3.org/2001/XMLSchema-instance". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/60713.81.2.120.180.1233060092.squirrel%40goddamn.co.uk RDFa Logo 2009-01-27T12:41:32 2009-01-27T12:41:32 2009-01-27T12:41:32 It strikes me that RDFa should have some sort of logo. Here is my idea: http://buzzword.org.uk/2009/rdfa-logo/rdfadoc.medium.png But I'm sure that other people can do better. -Toby It strikes me that RDFa should have some sort of logo. Here is my idea: http://buzzword.org.uk/2009/rdfa-logo/rdfadoc.medium.png But I'm sure that other people can do better. -Toby http://tobyinkster.co.uk/message/5D25C812-D899-4C19-B155-EE75C6AA284D%40g5n.co.uk Re: RDFa Logo 2009-01-27T23:10:17 2009-01-27T23:10:17 2009-01-27T23:10:17 On 27 Jan 2009, at 14:50, Karl Dubost wrote: > It can be worked out for different sizes. If Toby releases the > source file. :) I've included a few different sizes: http://buzzword.org.uk/2009/rdfa-logo/ I don't really have a source file though - I worked on it as a raster image - so in a sense, the large image at the URL above is the source. It should be pretty easy for someone to make ... On 27 Jan 2009, at 14:50, Karl Dubost wrote: > It can be worked out for different sizes. If Toby releases the > source file. :) I've included a few different sizes: http://buzzword.org.uk/2009/rdfa-logo/ I don't really have a source file though - I worked on it as a raster image - so in a sense, the large image at the URL above is the source. It should be pretty easy for someone to make an SVG though. The document icon is "package_wordprocessing.svg" from the gnome-icon- theme package in GNOME 2.22, available under the GPL, with the tree picture removed and replaced by the W3C SemWeb logo, which is available from the W3C site. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8EAA7ED8-8281-4B6E-ADE0-1E23EC80A845%40g5n.co.uk Re: Validation issue with the xsi namespace 2009-01-28T00:18:12 2009-01-28T00:18:12 2009-01-28T00:18:12 On 27 Jan 2009, at 17:09, Stephane Corlosquet wrote: > So far I understand that the xsd and xsi namespaces should be > defined as > follows: > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Indeed. > How about the following elements using expanded URIs, are they wrong? > <size rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">10</ >... On 27 Jan 2009, at 17:09, Stephane Corlosquet wrote: > So far I understand that the xsd and xsi namespaces should be > defined as > follows: > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Indeed. > How about the following elements using expanded URIs, are they wrong? > <size rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">10</ > size> > "System Infrastructure"^^<http://www.w3.org/2001/XMLSchema#string> These are correct. See http://www.w3.org/TR/xmlschema-2/#built-in- datatypes where it says that each datatype "foo" has a URI of <http:// www.w3.org/2001/XMLSchema#foo>. > To put the question differently, is there any situation where it makes > sense to define > xmlns:xsd="http://www.w3.org/2001/XMLSchema#" Yes, RDF. What you've got to remember is that when people are using XML schemas, they are specifically trying to use certain elements and attributes defined by the XML schema specs. Thus they have to use the XML schema namespaces. When XSD is used in RDF, people are not trying to do that. They are not trying to use the elements or attributes defined in the XML schema specs at all. They don't want to use XML schema. They just want to reference the URIs for the datatypes. The hash is needed to reference them in RDF. In RDFa, it is proper to use: <span property="dc:title" datatype="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema#">...</span> However, it is equally proper to use: <span property="dc:title" datatype="xsd:ring" xmlns:xsd="http://www.w3.org/2001/XMLSchema#st">...</span> Or: <span property="dc:title" datatype="xsd:LSchema#string" xmlns:xsd="http://www.w3.org/2001/XM">...</span> All three are considered equivalent. > Or are these 'mistakes' due to semweb bad habits? They are not mistakes in the sense of accidentally using the wrong URI. It was arguably a mistake for RDFa and RDF/XML to use XML namespaces for prefix binding in the first place though, as it causes this kind of confusion. In XML, namespace URIs are opaque identifying strings, so have to match the published string character-by- character; in RDF, they're not opaque identifiers and can point to any partial URI which the author wishes to use as a prefix. In XML, a namespace URI is the full URL of a particular resource; in RDF it is not. It helps if you stop thinking of RDF/XML as a type of XML and instead think of it as an entirely different format which just happens to make some level of sense to XML parsers. Thus while xmlns in RDF might look like it should act the same as xmlns in XML, it does not. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1233313182.10706.2.camel%40ophelia2.g5n.co.uk voiD to describe graphs 2009-01-30T10:59:42 2009-01-30T10:59:42 2009-01-30T10:59:42 My parser <http://buzzword.org.uk/swignition/> understands a variety of techniques for embedding triples in HTML (and a number of other formats), but until recently had kept them all in one big graph. I'm now beginning the work needed to make it aware of multiple graphs. So for example, the RDFa data can be kept in a different graph to the GRDDL data. It struck me that perhaps voiD might off... My parser <http://buzzword.org.uk/swignition/> understands a variety of techniques for embedding triples in HTML (and a number of other formats), but until recently had kept them all in one big graph. I'm now beginning the work needed to make it aware of multiple graphs. So for example, the RDFa data can be kept in a different graph to the GRDDL data. It struck me that perhaps voiD might offer a way of describing these graphs and their relationships with each other. Here's an example document: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> <html> <head profile="http://www.w3.org/2003/g/data-view"> <title>Example</title> <link rel="transformation" href="http://www.w3.org/2001/sw/grddl-wg/td/glean_title.xsl" /> </head> <body xmlns:dc="http://purl.org/dc/terms/"> <h1>Example</h1> <address property="dc:creator">Joe Bloggs</address> </body> </html> Now, the GRDDL transformation will generate the following triples: <http://example.com/doc> <http://purl.org/dc/elements/1.1/title> "Example" . Whereas RDFa would generate: <http://example.com/doc> <http://purl.org/dc/terms/creator> "Joe Bloggs" . That could be represented in Notation 3 using voiD like this: @prefix rdf : <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix dc : <http://purl.org/dc/terms/> . @prefix void : <http://rdfs.org/ns/void#> . @prefix scovo : <http://purl.org/NET/scovo#> . _:rdfaGraph a void:Dataset ; dc:source <http://example.com/doc> ; dc:description "Triples generated by RDFa processing." ; void:statItem [ rdf:value 1; scovo:dimension void:numberOfTriples ] ; = { <http://example.com/doc> dc:creator "Joe Bloggs" . } . _:grddlGraph1 a void:Dataset ; dc:source <http://example.com/doc> ; dc:description "Triples gleaned using transformation http://www.w3.org/2001/sw/grddl-wg/td/glean_title.xsl" ; void:statItem [ rdf:value 1; scovo:dimension void:numberOfTriples ] ; = { <http://example.com/doc> <http://purl.org/dc/elements/1.1/title> "Example" . } . _:combinedGraph a void:Dataset ; dc:source <http://example.com/doc> ; void:subset _:rdfaGraph , _:grddlGraph1 ; void:statItem [ rdf:value 2; scovo:dimension void:numberOfTriples ] ; = { <http://example.com/doc> dc:creator "Joe Bloggs" ; <http://purl.org/dc/elements/1.1/title> "Example" . } . Does this sound like a good use of voiD or an abuse? -- Toby A Inkster http://tobyinkster.co.uk/message/56F8C5F0-9B54-4301-B615-35941290F947%40g5n.co.uk Named Graphs in RDFa 2009-02-01T01:16:45 2009-02-01T01:16:45 2009-02-01T01:16:45 Hi all, This is an idea that Kjetil Kjernsmo and I have been looking at for a couple of weeks: http://buzzword.org.uk/2009/rdfa4/spec Essentially it allows you to divide the usual RDFa output into multiple named graphs. What do people think? Is this useful? Are there better ways of accomplishing it? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Hi all, This is an idea that Kjetil Kjernsmo and I have been looking at for a couple of weeks: http://buzzword.org.uk/2009/rdfa4/spec Essentially it allows you to divide the usual RDFa output into multiple named graphs. What do people think? Is this useful? Are there better ways of accomplishing it? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AEE6D65D-6F5E-4CA8-B203-748B9F59A180%40g5n.co.uk Re: Named Graphs in RDFa 2009-02-01T09:21:31 2009-02-01T09:21:31 2009-02-01T09:21:31 On 1 Feb 2009, at 07:43, Michael Hausenblas wrote: > You rightly conclude that we very likely need a new attribute but > then state > that 'this document does not define what that attribute is called'. > Hm. I > think this is too much relying on a convergent market. I can't see > how this > should scale. Kjetil had a similar concern. He is on this mailing list now though, so I won't atte... On 1 Feb 2009, at 07:43, Michael Hausenblas wrote: > You rightly conclude that we very likely need a new attribute but > then state > that 'this document does not define what that attribute is called'. > Hm. I > think this is too much relying on a convergent market. I can't see > how this > should scale. Kjetil had a similar concern. He is on this mailing list now though, so I won't attempt to speak for him. It is not that I don't think a proper attribute should be defined and standardised (see appendix C of the draft) - it is more that there are still a lot of decisions to make about it - what namespace should it be in? what should it be called? ("graph" like TriX/TriG/SPARQL? "context" like N-Quads? "formula" like Notation 3?) what should its lexical space be? In fact, even its value space is up for question - it could be a list of URIs for example. I thought that it was important to have general discussion on the idea first before making the syntax completely concrete. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/107B1E67-2A0C-4F16-A104-ACC6AE93C08B%40g5n.co.uk Re: Named Graphs in RDFa 2009-02-01T09:41:56 2009-02-01T09:41:56 2009-02-01T09:41:56 On 1 Feb 2009, at 09:17, Dan Brickley wrote: > Here's a use case, perhaps. I have been thinking about the common > case of Web site accounts where the content on a profile page is a > mix of markup whose (un-mediated) content is supplied more or less > by the end user, and content that comes in some way from the > service provide. For example, Advogato make available FOAF > profiles. Th... On 1 Feb 2009, at 09:17, Dan Brickley wrote: > Here's a use case, perhaps. I have been thinking about the common > case of Web site accounts where the content on a profile page is a > mix of markup whose (un-mediated) content is supplied more or less > by the end user, and content that comes in some way from the > service provide. For example, Advogato make available FOAF > profiles. The RDF claims about name, homepage etc come from you, > the bit about the category you are in (journeyer, master, beginner > or whatever) come from advogato. > > Toby, Kjetil, anyone, ... care to try reworking this example to use > RDFa Quads? (RDFaQ?). The basic idea would be along the lines of: <link about="_:advograph" rel="foaf:maker" resource="http:// advogato.org/#us" /> <link about="_:megraph" rel="foaf:maker" resource="http:// advogato.org/someuser#me" /> <p about="#me"> <a property="foaf:name" rel="foaf:homepage" graph="_:megraph" href="http://someuser.example.com/">Some User</span> (<span property="a:category" graph="_:advograph">master</div>) </p> Because foaf:name and foaf:homepage are on the same element, they can't be part of different graphs, but that could be worked around like: <span property="foaf:name" datatype="" graph="_:graph1"><a rel="foaf:homepage" graph="_:graph2" href="http://someuser.example.com/">Some User</span></a> > BTW one argument for getting an agreed attribute name, is that Web- > scale search engines will need a very cheap test that they can > apply before deciding to run a full RDFa+Q parser over a document. > Maybe eventually any RDFa parser will do this, but it should be > kept in mind when thinking about adoption paths... A named graphs parser should not be significantly slower than a standard RDFa parser written in the same programming language. If you take a look at section 4 of the draft, you'll see that the modifications to the standard algorithm are only minor, so don't add very much extra processing. Because of the design decisions employed, if you parse a document that does not use named graphs in a named graphs processor, you find that all the triples simply end up in the default graph. There is no need to go down one parsing route for named graph documents and another for standard documents. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1233661673.23182.9.camel%40ophelia2.g5n.co.uk Re: getting the value in rdf:datatype 2009-02-03T11:47:54 2009-02-03T11:47:54 2009-02-03T11:47:54 The Boy wrote: > I am trying to parse an owl file(rdf/xml file) using the XML parser in C# > ..Net. Firstly, this is probably not the best mailing list to ask. This is the RDFa taskforce mailing list - not RDF/XML. semantic-web@w3.org might be a better bet. Secondly, do yourself a favour and stop trying to use an XML parser to parse RDF - it won't be up to the job. Sure, it's *possible* to pars... The Boy wrote: > I am trying to parse an owl file(rdf/xml file) using the XML parser in C# > ..Net. Firstly, this is probably not the best mailing list to ask. This is the RDFa taskforce mailing list - not RDF/XML. semantic-web@w3.org might be a better bet. Secondly, do yourself a favour and stop trying to use an XML parser to parse RDF - it won't be up to the job. Sure, it's *possible* to parse RDF using an XML parser, but only in the same sense that it's *possible* to toast bread using a cigarette lighter. Here's an RDF parser for .NET. I don't know if it's any good: http://www.schemaweb.info/parser/Parser.aspx I'm sure there are many others. > how can I test that a XML node contains rdf:datatype attribute If you persist in trying to use an XML parser, then assuming you have a DOM built, use the standard DOM functions: things like getAttributeNS. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1233753749.22990.6.camel%40ophelia2.g5n.co.uk Re: New, Unified XG Proposal 2009-02-04T13:22:30 2009-02-04T13:22:30 2009-02-04T13:22:30 On Wed, 2009-02-04 at 12:25 +0000, Michael Hausenblas wrote: > One telecon for all TF? No way. Ever been on a telecon with say 30 > people. Before the last one says 'hello' the hour is over. Could the telecon just consist of one representative from each TF plus the chairs of the XG? Each TF could arrange their own internal communications themselves, according to the needs of that particular TF. That may consist of an additional mailing list, wiki pages, IRC, microblogging, conference calls, face-to-face, etc. -- Toby Inkster <tai@g5n.co.uk> On Wed, 2009-02-04 at 12:25 +0000, Michael Hausenblas wrote: > One telecon for all TF? No way. Ever been on a telecon with say 30 > people. Before the last one says 'hello' the hour is over. Could the telecon just consist of one representative from each TF plus the chairs of the XG? Each TF could arrange their own internal communications themselves, according to the needs of that particular TF. That may consist of an additional mailing list, wiki pages, IRC, microblogging, conference calls, face-to-face, etc. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/D7C2C8C7-8634-4FA4-B303-EDA450DA2BE9%40g5n.co.uk Re: New, Unified XG Proposal 2009-02-04T23:04:02 2009-02-04T23:04:02 2009-02-04T23:04:02 On 4 Feb 2009, at 13:39, Christine Perey wrote: > Toby, what area/topic or Task Force would you most likely wish to > contribute > to? Of course, there could be several! In order of interest (highest first), probably: - Interoperability Task Force - Distributed Architectures Task Force - Privacy and Trust Task Force I think that interoperability is a prerequisite for a distributed arch... On 4 Feb 2009, at 13:39, Christine Perey wrote: > Toby, what area/topic or Task Force would you most likely wish to > contribute > to? Of course, there could be several! In order of interest (highest first), probably: - Interoperability Task Force - Distributed Architectures Task Force - Privacy and Trust Task Force I think that interoperability is a prerequisite for a distributed architecture, and that privacy will be necessary for people to be able to trust such an architecture. Which brings me to the main reason I think one XG should be set up - all the areas of work are somewhat dependent on each other, and it's important for there to be one overall group to guide the work on all the areas, even if for the most part they work separately for practical reasons (e.g. avoiding massive teleconferences). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/93634D5F-D02C-46EF-B033-EC9369FC66A1%40g5n.co.uk Re: RDFa and Web Directions North 2009 2009-02-15T16:04:50 2009-02-15T16:04:50 2009-02-15T16:04:50 Sam Ruby wrote: > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/ > 018242.html Yes, this shows that there are differences between the XHTML and HTML DOM trees. I don't think anyone doubted that. The question is whether these differences make it necessary to distinguish between HTML and XHTML trees when extracting RDFa data. In fact, Henri's pages show that Attribute.na... Sam Ruby wrote: > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/ > 018242.html Yes, this shows that there are differences between the XHTML and HTML DOM trees. I don't think anyone doubted that. The question is whether these differences make it necessary to distinguish between HTML and XHTML trees when extracting RDFa data. In fact, Henri's pages show that Attribute.name and Attribute.value behave identically under the HTML and XHTML DOMs. In my experience in implementing RDFa, name and value are the only properties of Attribute nodes which are needed by implementations. (And they're only needed for step 2 of the processing sequence given in the RDFa syntax document. For the rest of the processing, plain old Element.getAttribute is sufficient, provided that your scripting environment provides a way of distinguishing between unset attributes and attributes set to the empty string - which most seem to.) There are theoretical objections to using xmlns:* attributes for RDFa in HTML. I understand them and mostly agree. It would be good to find a solution to these. But the practical problems are really minimal - once a stream of bytes has been turned into a DOM tree (and that is where the major differences between XHTML and HTML processing lie), the DOM tree can be processed as RDFa using the same algorithm for both XHTML and HTML. In fact, the RDFa concept is flexible enough to apply to any tree- like structure where the tree nodes are capable of holding attributes - think the Windows system registry, GConf, nested associative arrays in various programming languages, etc. There is probably little value [*] in implementing RDFa parsers for those media, but it is immediately clear how the RDFa processing sequence could be applied to them. ____ [*] = RDFa is primarily intended as a way of intermingling machine- readable data with human-readable data. The Windows registry, GConf and associative arrays are already machine-readable and are rarely read by humans, so there would not be much point in storing RDFa data there - RDF could be stored in a simple machine-readable format - perhaps a format similar to RDF/JSON. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FA205912-4828-46E0-8698-D514937CD1D2%40tobyinkster.co.uk Re: Named Graphs in RDFa 2009-02-16T22:43:37 2009-02-16T22:43:37 2009-02-16T22:43:37 Mark Birbeck wrote: > I'm working on using local storage to capture triples that are > retrieved from documents, whilst browsing the web, and the approach is > to store the triples in a named graph that uses the document's URI as > the name. This means that the next time I navigate to that URL, all I > have to do is to delete the named graph, then parse the document, and > insert the triples agai... Mark Birbeck wrote: > I'm working on using local storage to capture triples that are > retrieved from documents, whilst browsing the web, and the approach is > to store the triples in a named graph that uses the document's URI as > the name. This means that the next time I navigate to that URL, all I > have to do is to delete the named graph, then parse the document, and > insert the triples again; I don't have to worry that there may be > other triples floating around that are now 'incorrect'. A solution to this would be to allow an RDFa document to contain multiple named graphs, but to force the URIs for those named graphs to have URIs of the form <document URI> + "#" + <name>. This could easily be achieved by making the lexical space of the graph attribute the same as label@for. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C20C6056-3775-497E-BBC8-6CA578FFB163%40g5n.co.uk Re: Named Graphs in RDFa 2009-02-16T22:44:01 2009-02-16T22:44:01 2009-02-16T22:44:01 Mark Birbeck wrote: > I'm working on using local storage to capture triples that are > retrieved from documents, whilst browsing the web, and the approach is > to store the triples in a named graph that uses the document's URI as > the name. This means that the next time I navigate to that URL, all I > have to do is to delete the named graph, then parse the document, and > insert the triples agai... Mark Birbeck wrote: > I'm working on using local storage to capture triples that are > retrieved from documents, whilst browsing the web, and the approach is > to store the triples in a named graph that uses the document's URI as > the name. This means that the next time I navigate to that URL, all I > have to do is to delete the named graph, then parse the document, and > insert the triples again; I don't have to worry that there may be > other triples floating around that are now 'incorrect'. A solution to this would be to allow an RDFa document to contain multiple named graphs, but to force the URIs for those named graphs to have URIs of the form <document URI> + "#" + <name>. This could easily be achieved by making the lexical space of the graph attribute the same as label@for. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9D7CF343-8EE4-4BEC-8F04-34564DC86F66%40g5n.co.uk Re: Consolidation of Task-forces 2009-02-17T14:20:37 2009-02-17T14:20:37 2009-02-17T14:20:37 On 10 Feb 2009, at 20:35, Harry Halpin wrote: > The criteria for "reasonably deliver" is that these do not already > have someone who wants to work on them, i.e. volunteer to edit. I don't know what the criteria are for an editor (I'm not a W3C member, nor likely to become one in the foreseeable future) but I'm happy to co-edit any of the deliverables in the Landscape, Privacy & Trust, In... On 10 Feb 2009, at 20:35, Harry Halpin wrote: > The criteria for "reasonably deliver" is that these do not already > have someone who wants to work on them, i.e. volunteer to edit. I don't know what the criteria are for an editor (I'm not a W3C member, nor likely to become one in the foreseeable future) but I'm happy to co-edit any of the deliverables in the Landscape, Privacy & Trust, Interoperability or Distributed Architectures task forces. Many of these already have volunteers, though I note that the best practice guide for security and privacy on portable social data is still editorless, and that sounds like an area I'd like to help out. Also, I've written to Sarven Capadisli, the user experience guy at identi.ca/laconi.ca. He was unaware that this incubator group was being set up, but I would expect him to be able to make valuable contributions, especially to the user experience task force. There are some other key people I'd expect to see involved in this group but whose names have been notable in their absence from the mailing list archives. For example, does Chris Messina know that the group is being set up? Unless people know that the incubator group is being established, it will continue to have problems finding editors. Passively waiting for them to show up is not enough - we need to get in touch with people who we think might be interested and invite them to join this mailing list. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/79B1E795-319E-4A83-806D-8CE1F6480853%40g5n.co.uk User Agent conformance requirements for RDFa [was Re: RDFa and Web Directions North 2009] 2009-02-17T16:46:01 2009-02-17T16:46:01 2009-02-17T16:46:01 Ian Hickson wrote: > The RDFa community should decide whether or not browser involvement is > ever going to be desired. I have often heard conflicting statements > here > from proponents of RDF and RDFa, on the one hand that the idea is > to make > browsers more usable, and on the other that there is no cost to > browser > vendors. Both can't be true. The two are not necessarily contradict... Ian Hickson wrote: > The RDFa community should decide whether or not browser involvement is > ever going to be desired. I have often heard conflicting statements > here > from proponents of RDF and RDFa, on the one hand that the idea is > to make > browsers more usable, and on the other that there is no cost to > browser > vendors. Both can't be true. The two are not necessarily contradictory. The minimum conformance requirement would be for browsers to do nothing other than what they currently do with RDFa: that is, add the attributes to the DOM tree just like they would with any other attributes. User agents would however be free to offer features beyond the minimal requirements - examples: * when detecting RDFa that represents a person, the user agent could offer a pop-up menu allowing the user to e-mail or instant message that person, or add that person to the user's address book, or look up the person's biography on Wikipedia. * when detecting RDFa that represents a book, the agent could offer to look the book up on Amazon[1], look up the author on Wikipedia, find other books by the same author, etc. * when detecting RDFa that represents an event, the agent could offer to add it to the user's calendar, calculate the distance to travel to its location (from the user's current location, assuming that is known) and search for similar events in their area on upcoming.org if the user says the event is too far away. The possibilities are almost unlimited - it is a matter for the developers of user agents to decide which they think will benefit their users, implement them and document them. Some features (e.g. a newt tracking system) would almost certainly be too esoteric for user agents to bother with, but they can always be developed as third- party plugins, bookmarklets[2] or online services with a web interface. RDFa provides a shared data model and syntax for the development of these features. RDFa provides a level playing-field for interoperable implementations. Existing browsers already fulfil the minimum conformance requirements, so even if it can be claimed that there is a "cost" for them to do so, it is clearly a cost that has already been "paid". The "no cost" claim seems to hold up, at least as far as I can see. RDFa can be used by browser developers to make their user interface more useful and automate common tasks. This certainly will entail costs on their part, but goes beyond the minimal conformance requirements, so is optional. I imagine developers would add such features after deciding on a case- by-case basis which are most useful and most likely to attract new users to their platforms, and ultimately result in an increase in revenue stream enough to cover their implementation costs. Such a process would surely not be so different from existing decision- making processes by browser developers? Although there would be an upfront development cost, development would only be undertaken if deemed to be ultimately profitable, so the net cost would actually not be a cost but rather a profit, assuming decisions were well made. ____ 1. Note the recent "would Amazon use RDFa" discussion. Even if Amazon did not, a user agent that was able to identify mentions of books on blogs, in research papers and so on could get the book's title, author and (if provided) ISBN from RDFa and perform an Amazon API call using that information. 2. To make the development of such bookmarklets and scripts easier, some kind of RDFa API exposed via Javascript would be handy, but not essential. I imagine that scripts would test for its existence and use it if available, but otherwise load a pure Javascript RDFa toolkit. This is similar to how scripts currently use getElementsByClassName - for performance reasons they will check for a browser-native implementation, but otherwise fall back to a Javascript function. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/7B65B811-00EE-4395-AE55-DBDA74FCC8F1%40tobyinkster.co.uk W3C Validator 0.8.5 2009-02-17T17:27:01 2009-02-17T17:27:01 2009-02-17T17:27:01 Following up this message: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jan/ 0056.html I've written a patch for the validator and submitted it. It's been accepted and should be in the next release, which will presumably be 0.8.5. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Following up this message: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jan/ 0056.html I've written a patch for the validator and submitted it. It's been accepted and should be in the next release, which will presumably be 0.8.5. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/DD5A958A-622D-40B3-BD02-EB9578FEF237%40g5n.co.uk W3C Validator 0.8.5 2009-02-17T21:20:52 2009-02-17T21:20:52 2009-02-17T21:20:52 Following up this message: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jan/ 0056.html I've written a patch for the validator and submitted it. It's been accepted and should be in the next release, which will presumably be 0.8.5. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Following up this message: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jan/ 0056.html I've written a patch for the validator and submitted it. It's been accepted and should be in the next release, which will presumably be 0.8.5. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E2BC5085-6533-49B2-BC61-DB88FE4EE23D%40g5n.co.uk Re: how to mark up a photo on the web 2009-02-20T22:55:31 2009-02-20T22:55:31 2009-02-20T22:55:31 Ben Adida wrote: > Are we using the vocabularies correctly? Are there other > vocabularies we > should consider for the advanced example? I would say that the geo vocab might be being used incorrectly. You have, for example: <./maddie.jpg> geo:latitude 57.64911 ; geo:longitude 10.40744 . Given the defined domain of geo:latitude, this makes maddie.jpg a geo:SpatialThing. It says that t... Ben Adida wrote: > Are we using the vocabularies correctly? Are there other > vocabularies we > should consider for the advanced example? I would say that the geo vocab might be being used incorrectly. You have, for example: <./maddie.jpg> geo:latitude 57.64911 ; geo:longitude 10.40744 . Given the defined domain of geo:latitude, this makes maddie.jpg a geo:SpatialThing. It says that the photo itself has those co-ordinates. What you might want instead is: <./maddie.jpg> XXXX [ geo:latitude 57.64911 ; geo:longitude 10.40744 ] . Where XXXX is dcterms:subject or maybe foaf:depicts. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1236177920.26486.27.camel%40ophelia2.g5n.co.uk Feature request: IN operator 2009-03-04T14:45:20 2009-03-04T14:45:20 2009-03-04T14:45:20 Analogous to the SQL operator of the same name. PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?thing ?name WHERE { ?thing ?p ?name . FILTER (?p IN (foaf:name foaf:nick rdfs:label)) } This query can already be written as PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?thing ?name W... Analogous to the SQL operator of the same name. PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?thing ?name WHERE { ?thing ?p ?name . FILTER (?p IN (foaf:name foaf:nick rdfs:label)) } This query can already be written as PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?thing ?name WHERE { ?thing ?p ?name . FILTER (?p = foaf:name || ?p = foaf:nick || ?p = rdfs:label) } But I hope people agree that the former syntax is more legible. Formally, IN would be an infix operator taking a term as its first argument and an rdf:List as its second argument. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1236186659.26486.33.camel%40ophelia2.g5n.co.uk Re: Results of Questionnaire 2009-03-04T17:10:59 2009-03-04T17:10:59 2009-03-04T17:10:59 On Wed, 2009-03-04 at 12:44 +0000, Harry Halpin wrote: > 4) The majority of people seem to think privacy and trust work can be > done jointly with or in PLING. What of the fact that PLING's charter will expire in June though? Is its lifetime expected to be extended again? PLING Charter: http://www.w3.org/Policy/2007/ig-charter.html -- Toby Inkster <tai@g5n.co.uk> On Wed, 2009-03-04 at 12:44 +0000, Harry Halpin wrote: > 4) The majority of people seem to think privacy and trust work can be > done jointly with or in PLING. What of the fact that PLING's charter will expire in June though? Is its lifetime expected to be extended again? PLING Charter: http://www.w3.org/Policy/2007/ig-charter.html -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1236244959.17910.6.camel%40ophelia2.g5n.co.uk RE: Feature request: IN operator 2009-03-05T09:22:40 2009-03-05T09:22:40 2009-03-05T09:22:40 On Thu, 2009-03-05 at 10:10 +0100, Orri Erling wrote: > variable IN (<expression_list>) The way I suggested it would be variable1 IN variable2 Where variable2 is an rdf:List. In particular, this could be a list specified as part of the SPARQL query as in my original example: > PREFIX foaf: <http://xmlns.com/foaf/0.1/> > PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> > SELECT ?thing ?na... On Thu, 2009-03-05 at 10:10 +0100, Orri Erling wrote: > variable IN (<expression_list>) The way I suggested it would be variable1 IN variable2 Where variable2 is an rdf:List. In particular, this could be a list specified as part of the SPARQL query as in my original example: > PREFIX foaf: <http://xmlns.com/foaf/0.1/> > PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> > SELECT ?thing ?name > WHERE { > ?thing ?p ?name . > FILTER (?p IN (foaf:name foaf:nick rdfs:label)) > } The inner set of brackets there is not part of the IN operator syntax, but rather builds an rdf:List. So it can just refer to a list defined in the graph itself: SELECT ?header WHERE { ?thing a :httpHeader . FILTER (?thing IN <#responseHeaders>) } -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/93545101-7B94-4E0F-8F5B-320EA978ACB1%40g5n.co.uk RDFa on MediaWiki 2009-03-09T18:19:38 2009-03-09T18:19:38 2009-03-09T18:19:38 I've written a quick patch to enable RDFa on MediaWiki. http://buzzword.org.uk/2009/mediawiki-patches/xhtml-rdfa.patch It doesn't do anything to specifically help people add RDFa to MediaWiki, but rather prevents MediaWiki from doing things that are actively hostile to RDFa (e.g. stripping out RDFa's attributes). It doesn't change MediaWiki's doctype - you'll need to edit the skin for tha... I've written a quick patch to enable RDFa on MediaWiki. http://buzzword.org.uk/2009/mediawiki-patches/xhtml-rdfa.patch It doesn't do anything to specifically help people add RDFa to MediaWiki, but rather prevents MediaWiki from doing things that are actively hostile to RDFa (e.g. stripping out RDFa's attributes). It doesn't change MediaWiki's doctype - you'll need to edit the skin for that. Also, a couple of slightly related extensions: http://www.mediawiki.org/wiki/Extension:HTML_Profiles - allows people to add URIs to <head profile>. By default, adds http://www.w3.org/ 1999/xhtml/vocab. http://www.mediawiki.org/wiki/Extension:Link_Attributes - allows rel and rev to be set on links. Creative Commons might want to consider installing some of these on the rdfa.info wiki. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/02314DE5-218C-40C9-968C-A5793F1B1B30%40g5n.co.uk Re: RDFa and CSS 2009-03-10T18:49:40 2009-03-10T18:49:40 2009-03-10T18:49:40 Take a look at, for example: http://buzzword.org.uk/2008/rdfa-cv.html or: http://buzzword.org.uk/2009/xmltv2rdf/example-tv/screen.css One slight annoyance I've had using CSS selectors with RDFa is that you can only select based on CURIE-prefixes rather than full URIs. For example, it would be nice to be able to use p[typeof="http:// example.com/Person"] rather than p[typeof="ex:Person"]... Take a look at, for example: http://buzzword.org.uk/2008/rdfa-cv.html or: http://buzzword.org.uk/2009/xmltv2rdf/example-tv/screen.css One slight annoyance I've had using CSS selectors with RDFa is that you can only select based on CURIE-prefixes rather than full URIs. For example, it would be nice to be able to use p[typeof="http:// example.com/Person"] rather than p[typeof="ex:Person"] as the "ex" prefix is unreliable. A nice project for someone might be to write a little ECMAscript which takes the RDFa attributes and creates some additional attributes in the DOM called uri-typeof, uri-rel, etc which can be used in selectors. (That would tie styling to scripting, though for many applications that would be an acceptable compromise.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A62795CF-21DE-4713-A79F-ED6D91ABC933%40g5n.co.uk Re: RDFa and CSS 2009-03-11T08:26:13 2009-03-11T08:26:13 2009-03-11T08:26:13 On 11 Mar 2009, at 00:50, Martin McEvoy wrote: > You CAN use css like that in, Firefox, Opera, Safari and Chrome > (the standards compliance ones I guess) you just cant in *Internet > Explorer* I thought IE7 had implemented attribute selectors, no? And for IE5/6 there is: http://dean.edwards.name/IE7/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 11 Mar 2009, at 00:50, Martin McEvoy wrote: > You CAN use css like that in, Firefox, Opera, Safari and Chrome > (the standards compliance ones I guess) you just cant in *Internet > Explorer* I thought IE7 had implemented attribute selectors, no? And for IE5/6 there is: http://dean.edwards.name/IE7/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/241A0BB8-1818-44AE-B43A-FDC94D967E46%40g5n.co.uk Re: RDFa and CSS 2009-03-11T18:58:30 2009-03-11T18:58:30 2009-03-11T18:58:30 Microsoft's documentation certainly says that this selector is supported in IE7+: http://msdn.microsoft.com/en-us/library/cc351024(VS. 85).aspx#attributeselectors Though that's not to say that the implementation is bug-free. It may be, for instance, that certain characters in the attribute value (colons, slashes, etc) cause problems. While I'm responding, I'll also include a link to this little Javascript file I wrote this afternoon: http://buzzword.org.uk/2009/stylish-rdfa/test.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Microsoft's documentation certainly says that this selector is supported in IE7+: http://msdn.microsoft.com/en-us/library/cc351024(VS. 85).aspx#attributeselectors Though that's not to say that the implementation is bug-free. It may be, for instance, that certain characters in the attribute value (colons, slashes, etc) cause problems. While I'm responding, I'll also include a link to this little Javascript file I wrote this afternoon: http://buzzword.org.uk/2009/stylish-rdfa/test.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CCF50503-CA17-47AC-A249-1BE10071B253%40g5n.co.uk Re: RDFa, XHTML1.1 and @lang (via Twitter) 2009-03-13T19:33:11 2009-03-13T19:33:11 2009-03-13T19:33:11 The wording of the current RDFs syntax document is liberal enough to allow RDFa parsers to handle @lang already. (The DTD forbids the attribute to be present, but if we're going to get pedantic, the DTD doesn't allow xmlns attributes either.) In fact, depending on your reading of the document, it is arguable that handling @lang is already a requirement. Step 3 of the processing sequence... The wording of the current RDFs syntax document is liberal enough to allow RDFa parsers to handle @lang already. (The DTD forbids the attribute to be present, but if we're going to get pedantic, the DTD doesn't allow xmlns attributes either.) In fact, depending on your reading of the document, it is arguable that handling @lang is already a requirement. Step 3 of the processing sequence states: > The [current element] is also parsed for any language information, > and if present, [current language] is set accordingly; Note the phrase "*any* language information". The document then goes on to say that language information *can* be provided using xml:lang, but it doesn't say that other sources of language information cannot be explored. I don't know whether this flexibility was intentional, but it is certainly present in the syntax document. Similar language is employed where it talks about parsing the element for URI mappings. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/15633E89-E549-4E3D-96C5-0CD4DA1C13E9%40g5n.co.uk Re: embed RDFa --> embed coolness into Yahoo search results 2009-03-17T19:28:45 2009-03-17T19:28:45 2009-03-17T19:28:45 Ian Hickson wrote: > More worryingly, though, I have to say that in trying to write > these tests > I had an extremely confusing experience reading the RDFa > specification. > When can one use href="" and when can one use resource=""? In terms of semantics, the two are essentially the same. You would choose one over the other depending on whether you intended the link to be clickable (@h... Ian Hickson wrote: > More worryingly, though, I have to say that in trying to write > these tests > I had an extremely confusing experience reading the RDFa > specification. > When can one use href="" and when can one use resource=""? In terms of semantics, the two are essentially the same. You would choose one over the other depending on whether you intended the link to be clickable (@href) or not (@resource). @resource has a slightly higher priority, so when both are given on the same element, the @resource attribute "wins" - this is useful if you want to supply both a clickable link to a human-readable resource, and a non-clickable link to a machine-readable resource, which is a reasonably common pattern. e.g. I like <a about="#me" xmlns:foaf="http://xmlns.com/foaf/0.1/" rel="foaf:topic_interest" href="http://en.wikipedia.org/wiki/Cheese" resource="http://dbpedia.org/resource/Cheese">cheese</a> @resource is also allowed to contain safe CURIEs, which can be useful for abbreviating references sometimes, but is not an especially important aspect of the attribute. > Does using content="" with an absolute URL work also? No. That would represent the literal string of the URI rather than the resource identified by the string. Consider the previous example: I am interested in the concept Cheese, I am not especially interested in a string which begins "aitch tee tee pee colon..." > What are the implications of using property="" instead of rel=""? @property contains the predicate for a literal; @rel for a resource. Why two different attributes? Well, firstly it enables a fairly common pattern: <a xmlns:foaf="http://xmlns.com/foaf/0.1/" typeof="foaf:Person" rel="foaf:homepage" property="foaf:name" href="http://www.hixie.ch/">Ian Hickson</a> Which would produce three RDF triples: [] a <http://xmlns.com/foaf/0.1/Person> ; <http://xmlns.com/foaf/0.1/name> "Ian Hickson" ; <http://xmlns.com/foaf/0.1/homepage> <http://www.hixie.ch/> . Which in turn could be fed into a database or converted into a vCard to be added to an address book, etc. > When does nesting matter and when does it not matter? Nesting always matters in RDFa, though @about can be used to "reset" any nesting higher up the DOM tree. > Does it matter whan URL the assertions are made about, or will the > SearchMonkey tool simply grab all the assertions from the document > regardless of what URL they are about? What parts are necessary and > what parts are optional? Probably better answered by someone from Yahoo. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/676D30FA-F177-4EDE-8E17-CDB8BA1A46C2%40g5n.co.uk Re: Geo vocabulary - relating geo:Point values to other entoties 2009-03-18T20:18:30 2009-03-18T20:18:30 2009-03-18T20:18:30 Graham Klyne wrote: > Is there a common vocabulary term that can be used to attach a > geo:Point to an > object, e.g. to say that some place includes a given point. Candidates include: http://purl.org/dc/terms/spatial http://xmlns.com/foaf/0.1/based_near Also, if entity you are linking from is a place or area that definitely encompasses the point, you could use http://purl.org/dc/ terms/hasPart -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Graham Klyne wrote: > Is there a common vocabulary term that can be used to attach a > geo:Point to an > object, e.g. to say that some place includes a given point. Candidates include: http://purl.org/dc/terms/spatial http://xmlns.com/foaf/0.1/based_near Also, if entity you are linking from is a place or area that definitely encompasses the point, you could use http://purl.org/dc/ terms/hasPart -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/2227B031-010F-446A-AF24-750A4D1884EC%40g5n.co.uk RDFa on W3C Validator 2009-03-26T22:06:07 2009-03-26T22:06:07 2009-03-26T22:06:07 The new version of the validator is now live: http://lists.w3.org/Archives/Public/www-validator/2009Mar/0049.html This incorporates my patch for RDFa "valid" icons. Validate an XHTML +RDFa page and you'll see what I mean. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> The new version of the validator is now live: http://lists.w3.org/Archives/Public/www-validator/2009Mar/0049.html This incorporates my patch for RDFa "valid" icons. Validate an XHTML +RDFa page and you'll see what I mean. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/65105.81.2.120.180.1238150269.squirrel%40goddamn.co.uk Re: Naming - old and new SPARQL 2009-03-27T10:37:49 2009-03-27T10:37:49 2009-03-27T10:37:49 Inspired by the world of popular entertainment: * SPARQL II: Attack of the Clones * SPARQL, The Next Generation * SPARQL Reloaded * SPARQL 2, SPARQL Harder -Toby PS - #3 could actually work as a working title. Inspired by the world of popular entertainment: * SPARQL II: Attack of the Clones * SPARQL, The Next Generation * SPARQL Reloaded * SPARQL 2, SPARQL Harder -Toby PS - #3 could actually work as a working title. http://tobyinkster.co.uk/message/1238583290.14016.7.camel%40ophelia2.g5n.co.uk Re: The implied @about="": Explanation and some problems 2009-04-01T10:54:51 2009-04-01T10:54:51 2009-04-01T10:54:51 I understand why there is an implied @about, but I don't think your message addresses the question of why the implied @about is on <head> and <body>. Why is it not on <html>? > And if so, we should probably try to find out if anyone is actually > producing documents with @typeof on <body> or <head>, and if they are, > what's the effect they are trying to achieve. I used @typeof on <body> just yesterday! http://purl.org/NET/book/vocab Though this is with an explicit @about which is different to the document's base URI. -- Toby Inkster <tai@g5n.co.uk> I understand why there is an implied @about, but I don't think your message addresses the question of why the implied @about is on <head> and <body>. Why is it not on <html>? > And if so, we should probably try to find out if anyone is actually > producing documents with @typeof on <body> or <head>, and if they are, > what's the effect they are trying to achieve. I used @typeof on <body> just yesterday! http://purl.org/NET/book/vocab Though this is with an explicit @about which is different to the document's base URI. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/7F528193-9E72-4421-8D69-91506B8140B5%40g5n.co.uk So when and where do we apply to be invited experts? 2009-04-14T08:38:01 2009-04-14T08:38:01 2009-04-14T08:38:01 So when and where do we apply to be invited experts? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> So when and where do we apply to be invited experts? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/06F99C5D-4FF7-4F54-978C-8888F86F6D4D%40tobyinkster.co.uk subscribe 2009-04-14T08:41:32 2009-04-14T08:41:32 2009-04-14T08:41:32 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/546C626D-D62D-46E7-AEF0-60C3394C8641%40g5n.co.uk 2009-04-14T08:41:52 2009-04-14T08:41:52 2009-04-14T08:41:52 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/09AABAF9-3AE6-4253-8DBB-5A2D1C06E9C0%40g5n.co.uk subscribe 2009-04-14T08:42:27 2009-04-14T08:42:27 2009-04-14T08:42:27 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8F77954D-192A-4DFF-818C-07B59AF1C5B3%40g5n.co.uk CONFIRM s279664359 2009-04-14T08:47:25 2009-04-14T08:47:25 2009-04-14T08:47:25 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6D5816F2-A1C8-4F3F-9FA0-3FD40A0D6952%40tobyinkster.co.uk subscribe 2009-04-14T19:24:07 2009-04-14T19:24:07 2009-04-14T19:24:07 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A9BE1C6B-8983-4CD4-892A-1C4613216EC2%40g5n.co.uk Re: Using RDFa in rel attribute with multiple relationships 2009-04-15T19:50:10 2009-04-15T19:50:10 2009-04-15T19:50:10 On 15 Apr 2009, at 19:01, Rich Schumacher wrote: > I was wondering if there were any implications with using RDFa in a > rel attribute along with other relationships. For instance, are > there any problems with the markup below? > > <a href="http://example.com" rel="dc:source blah">Example</a> No, that's perfectly OK. > Would the fact that "blah" is not a valid rel value cause any > erro... On 15 Apr 2009, at 19:01, Rich Schumacher wrote: > I was wondering if there were any implications with using RDFa in a > rel attribute along with other relationships. For instance, are > there any problems with the markup below? > > <a href="http://example.com" rel="dc:source blah">Example</a> No, that's perfectly OK. > Would the fact that "blah" is not a valid rel value cause any > errors with RDFa parsing? RDFa parsers are supposed to ignore tokens that they don't recognise in rel, rev, property, datatype and typeof. > I only ask this because when I run the Get N3 RDFa bookmarklet it > extracts the following: > > <http://purl.org/dc/elements/1.1/source blah> <http://example.com> ; That would be a bug then. > Whereas using a valid rel attribute would result in the following: > > <http://purl.org/dc/elements/1.1/source xhtml:alternate> <http:// > exmaple.com/alternate> ; That doesn't look right either. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1802184A-DC67-4924-9935-EDE70869020F%40g5n.co.uk SKOS Implementation: Decimalised Database of Concepts 2009-04-16T21:51:10 2009-04-16T21:51:10 2009-04-16T21:51:10 The Decimalised Database of Concepts is a vocabulary inspired by Dewey Decimal Classification. It is maintained by me. It uses the following SKOS terms: ConceptScheme hasTopConcept Concept notation inScheme prefLabel altLabel exactMatch closeMatch relatedMatch broader It is publically available at http://purl.org/NET/decimalised in RDF/ XML, N-Triples and XHTML+RDFa formats. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> The Decimalised Database of Concepts is a vocabulary inspired by Dewey Decimal Classification. It is maintained by me. It uses the following SKOS terms: ConceptScheme hasTopConcept Concept notation inScheme prefLabel altLabel exactMatch closeMatch relatedMatch broader It is publically available at http://purl.org/NET/decimalised in RDF/ XML, N-Triples and XHTML+RDFa formats. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AF41205E-7290-4CE9-ABF8-7887E28FF5EB%40g5n.co.uk Re: [ANN] RDFj: Semantic objects in JSON 2009-04-22T17:57:19 2009-04-22T17:57:19 2009-04-22T17:57:19 Mark, Have you seen this? http://buzzword.org.uk/2008/jsonGRDDL/spec -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Mark, Have you seen this? http://buzzword.org.uk/2008/jsonGRDDL/spec -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B1B85FE8-D6B4-422B-98D0-55F2CA7F3A25%40g5n.co.uk subscribe 2009-04-23T13:51:56 2009-04-23T13:51:56 2009-04-23T13:51:56 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/00EDFF83-90BA-4CA1-AE21-C3A78C615797%40g5n.co.uk subscribe 2009-04-23T13:57:00 2009-04-23T13:57:00 2009-04-23T13:57:00 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1240502189.7021.4.camel%40ophelia2.g5n.co.uk Re: CONFIRM s2401021163 2009-04-23T16:05:25 2009-04-23T16:05:25 2009-04-23T16:05:25 On Thu, 2009-04-23 at 13:54 +0000, public-sweo-ig-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-sweo-ig mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-sweo-ig-request@... On Thu, 2009-04-23 at 13:54 +0000, public-sweo-ig-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-sweo-ig mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-sweo-ig-request@w3.org > > with the Subject string: > > CONFIRM s2401021163 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed above > will be (un)subscribed. If the address above is incorrect, please do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event that > you did not send a request to (un)subscribe, the headers of the message > may help you discover who sent the request. > > > >From tai@g5n.co.uk Thu Apr 23 13:54:40 2009 > >Received: from maggie.w3.org ([193.51.208.68]) > > by frink.w3.org with esmtp (Exim 4.63) > > (envelope-from <tai@g5n.co.uk>) > > id 1LwzNw-0005Uu-E5 > > for public-sweo-ig-request@listhub.w3.org; Thu, 23 Apr 2009 13:54:40 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by maggie.w3.org with esmtp (Exim 4.63) > > (envelope-from <tai@g5n.co.uk>) > > id 1LwzNn-0006up-GM > > for public-sweo-ig-request@w3.org; Thu, 23 Apr 2009 13:54:39 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 19567B9808 > > for <public-sweo-ig-request@w3.org>; Thu, 23 Apr 2009 14:53:55 +0100 (BST) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, port 10025) > > with ESMTP id Aap6J5yCH0bG for <public-sweo-ig-request@w3.org>; > > Thu, 23 Apr 2009 14:53:52 +0100 (BST) > >Received: from [192.168.0.103] (unknown [192.168.0.103]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 83EE6B9807 > > for <public-sweo-ig-request@w3.org>; Thu, 23 Apr 2009 14:53:52 +0100 (BST) > >Mime-Version: 1.0 (Apple Message framework v753.1) > >Content-Transfer-Encoding: 7bit > >Message-Id: <B1B85FE8-D6B4-422B-98D0-55F2CA7F3A25@g5n.co.uk> > >Content-Type: text/plain; charset=US-ASCII; format=flowed > >To: public-sweo-ig-request@w3.org > >From: Toby A Inkster <tai@g5n.co.uk> > >Subject: subscribe > >Date: Thu, 23 Apr 2009 14:51:56 +0100 > >X-Mailer: Apple Mail (2.753.1) > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: maggie.w3.org 1LwzNn-0006up-GM 3044dcb75f6e368d5a8f54e54032589b > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > > > > > http://tobyinkster.co.uk/message/1240502196.7021.5.camel%40ophelia2.g5n.co.uk Re: CONFIRM s32482640 2009-04-23T16:07:10 2009-04-23T16:07:10 2009-04-23T16:07:10 On Thu, 2009-04-23 at 14:01 +0000, public-lod-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-lod mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-lod-request@w3.org > > ... On Thu, 2009-04-23 at 14:01 +0000, public-lod-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-lod mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-lod-request@w3.org > > with the Subject string: > > CONFIRM s32482640 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed above > will be (un)subscribed. If the address above is incorrect, please do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event that > you did not send a request to (un)subscribe, the headers of the message > may help you discover who sent the request. > > > >From tai@g5n.co.uk Thu Apr 23 14:01:02 2009 > >Received: from bart.w3.org ([128.30.52.63]) > > by frink.w3.org with esmtp (Exim 4.63) > > (envelope-from <tai@g5n.co.uk>) > > id 1LwzU6-000057-4e > > for public-lod-request@listhub.w3.org; Thu, 23 Apr 2009 14:01:02 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by bart.w3.org with esmtp (Exim 4.63) > > (envelope-from <tai@g5n.co.uk>) > > id 1LwzSK-0005Y0-JQ > > for public-lod-request@w3.org; Thu, 23 Apr 2009 13:59:21 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 7AAADB9809 > > for <public-lod-request@w3.org>; Thu, 23 Apr 2009 14:58:40 +0100 (BST) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, port 10025) > > with ESMTP id sEtRGv3JYpXP for <public-lod-request@w3.org>; > > Thu, 23 Apr 2009 14:58:37 +0100 (BST) > >Received: from [192.168.0.103] (unknown [192.168.0.103]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 89E76B9808 > > for <public-lod-request@w3.org>; Thu, 23 Apr 2009 14:58:37 +0100 (BST) > >Mime-Version: 1.0 (Apple Message framework v753.1) > >Content-Transfer-Encoding: 7bit > >Message-Id: <00EDFF83-90BA-4CA1-AE21-C3A78C615797@g5n.co.uk> > >Content-Type: text/plain; charset=US-ASCII; format=flowed > >To: public-lod-request@w3.org > >From: Toby A Inkster <tai@g5n.co.uk> > >Subject: subscribe > >Date: Thu, 23 Apr 2009 14:57:00 +0100 > >X-Mailer: Apple Mail (2.753.1) > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: bart.w3.org 1LwzSK-0005Y0-JQ 7b20ef605c02648033eee1c9cc99a860 > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > > > > > http://tobyinkster.co.uk/message/62C39B20-9A37-4D85-8340-294EDFE69E0B%40g5n.co.uk Re: [foaf-dev] FOAF sites offline during cleanup 2009-04-27T11:50:38 2009-04-27T11:50:38 2009-04-27T11:50:38 On 27 Apr 2009, at 09:18, Ian Davis wrote: > With the lessening emphasis on RDF/XML, shouldn't we be looking at > signing the triples. I seem to recall a paper by Jeremy Carroll > that discussed this. Also, now many of us are focussed on bnode- > free linked data the problems of signing are much easier: serialise > as ntriples, sort and sign the result. The URI has already been posted, b... On 27 Apr 2009, at 09:18, Ian Davis wrote: > With the lessening emphasis on RDF/XML, shouldn't we be looking at > signing the triples. I seem to recall a paper by Jeremy Carroll > that discussed this. Also, now many of us are focussed on bnode- > free linked data the problems of signing are much easier: serialise > as ntriples, sort and sign the result. The URI has already been posted, but to summarise, Jeremy's technique is more or less the one outlined above: serialise as N-Triples, sort and sign. Graphs do not *need* to be BNode free for this to work. Some (not all) graphs containing BNodes can still be signed this way by assigning canonical names to the BNodes. Jeremy's paper outlines how this can be done. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BC6C3402-582E-445E-ADE7-5D5482FA7888%40tobyinkster.co.uk Re: RDFa tag lines 2009-04-27T21:12:26 2009-04-27T21:12:26 2009-04-27T21:12:26 <a typeof="t:Shirt" /> And on the back: xmlns:t="http://buzzword.org.uk/rdf/t#" -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> <a typeof="t:Shirt" /> And on the back: xmlns:t="http://buzzword.org.uk/rdf/t#" -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6E4272F3-02A2-462A-8397-577C143BE6D1%40g5n.co.uk subscribe 2009-04-29T17:35:03 2009-04-29T17:35:03 2009-04-29T17:35:03 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1241180554.22344.7.camel%40ophelia2.g5n.co.uk Re: Consensus on alternate prefixing mechanism 2009-05-01T12:22:34 2009-05-01T12:22:34 2009-05-01T12:22:34 On Fri, 2009-05-01 at 12:11 +0100, Martin McEvoy wrote: > maybe try using the @prefix element in the same way @xmlns is used > then?..... eg: > > <div prefix:foaf="http://xmlns.com/foaf/0.1/" > rel="foaf:page" > typeof="foaf:Document"> > > </div> Problem with this is that any elements and attibutes containing colons are assumed to be namespaced tokens by XML parsers - so the abov... On Fri, 2009-05-01 at 12:11 +0100, Martin McEvoy wrote: > maybe try using the @prefix element in the same way @xmlns is used > then?..... eg: > > <div prefix:foaf="http://xmlns.com/foaf/0.1/" > rel="foaf:page" > typeof="foaf:Document"> > > </div> Problem with this is that any elements and attibutes containing colons are assumed to be namespaced tokens by XML parsers - so the above will be taken to mean "the 'foaf' attribute from the 'prefix' namespace" and you'll get errors from parsers complaining that the 'prefix' namespace is undefined. Perhaps one of these: <div prefix.foaf="http://xmlns.com/foaf/0.1/"> <div prefix-foaf="http://xmlns.com/foaf/0.1/"> However, both of these (and 'xmlns' is also guilty of this) theoretically add an infinite number of attributes to the XHTML namespace. This makes DTD-based validation impossible (or at least, very impractical -- though the W3C validator has a workaround in that it ignores all 'xmlns:'-prefixed attributes). Using a single 'prefix' attribute solves this. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/81BCF193-802D-40EC-A25C-8F56FB07321E%40g5n.co.uk Re: Methods for referencing URIs 2009-05-02T15:10:15 2009-05-02T15:10:15 2009-05-02T15:10:15 On 2 May 2009, at 15:27, Stephane Corlosquet wrote: > For the RDFa in Drupal core effort, I'm looking for the best way to > store URIs and keep it lightweight and developer friendly. > > I see three different methods for referencing vocabulary URIs. > > 1. Full URI. very verbose and not very readable. I would suggest storing full URIs, and... > 2. CURIE. easy to read and user friendly. ...di... On 2 May 2009, at 15:27, Stephane Corlosquet wrote: > For the RDFa in Drupal core effort, I'm looking for the best way to > store URIs and keep it lightweight and developer friendly. > > I see three different methods for referencing vocabulary URIs. > > 1. Full URI. very verbose and not very readable. I would suggest storing full URIs, and... > 2. CURIE. easy to read and user friendly. ...displaying them as CURIEs if required in the user interface. > A typical use case is for representing a blog post for example: > > $object->title = 'Title of my blog post'; > $object->created = '1235130980'; > $object->user_id = 2; > $object->body = 'Lorem ipsum dolor sit amet, consectetur adipiscing > elit.'; > $object->rdf_mappings = array( > 'type' => 'sioct:Weblog', > 'title' => 'dc:title', > 'body' => 'sioc:content', > 'user_id' => 'dc:creator', > ); Using full URIs this could be: include 'prefixes.php'; # A bunch of constants /* ... */ $object->rdf_mappings = array( 'type' => SIOCT.'Weblog', 'title' => DC.'title', 'body' => SIOC. 'content', 'user_id' => DC.'creator', ); Or: include 'prefixes.php'; # A class definition /* ... */ $object->rdf_mappings = array( 'type' => RDF::sioct('Weblog'), 'title' => RDF::dc('title'), 'body' => RDF::sioc('content'), 'user_id' => RDF::dc('creator'), ); -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/668D0E60-DCA5-4041-BC0C-76032E6B88BC%40g5n.co.uk subscribe 2009-05-02T16:13:06 2009-05-02T16:13:06 2009-05-02T16:13:06 subscribe subscribe http://tobyinkster.co.uk/message/4D4E93E9-A922-47D8-A7E2-23DF5DD43734%40g5n.co.uk 2009-05-02T16:16:19 2009-05-02T16:16:19 2009-05-02T16:16:19 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EE7D7295-56C3-4B79-836F-632850044C04%40g5n.co.uk Re: CONFIRM s2880412521 2009-05-02T16:18:17 2009-05-02T16:18:17 2009-05-02T16:18:17 On 2 May 2009, at 17:13, public-xg-socialweb-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-xg-socialweb mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-xg-socialweb-reque... On 2 May 2009, at 17:13, public-xg-socialweb-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-xg-socialweb mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-xg-socialweb-request@w3.org > > with the Subject string: > > CONFIRM s2880412521 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm > string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address > listed above > will be (un)subscribed. If the address above is incorrect, please > do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event > that > you did not send a request to (un)subscribe, the headers of the > message > may help you discover who sent the request. > > >> From tai@g5n.co.uk Sat May 02 16:13:35 2009 >> Received: from maggie.w3.org ([193.51.208.68]) >> by frink.w3.org with esmtp (Exim 4.63) >> (envelope-from <tai@g5n.co.uk>) >> id 1M0HqJ-0003F8-Jd >> for public-xg-socialweb-request@listhub.w3.org; Sat, 02 May 2009 >> 16:13:35 +0000 >> Received: from ophelia.g5n.co.uk ([81.2.120.180]) >> by maggie.w3.org with esmtp (Exim 4.63) >> (envelope-from <tai@g5n.co.uk>) >> id 1M0HqA-0001WG-DN >> for public-xg-socialweb-request@w3.org; Sat, 02 May 2009 16:13:35 >> +0000 >> Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) >> by ophelia.g5n.co.uk (Postfix) with ESMTP id 9DC43B9802 >> for <public-xg-socialweb-request@w3.org>; Sat, 2 May 2009 >> 17:12:45 +0100 (BST) >> X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk >> Received: from ophelia.g5n.co.uk ([127.0.0.1]) >> by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, port >> 10025) >> with ESMTP id b7bYDlO4gMhh for <public-xg-socialweb-request@w3.org>; >> Sat, 2 May 2009 17:12:40 +0100 (BST) >> Received: from [192.168.0.103] (unknown [192.168.0.103]) >> by ophelia.g5n.co.uk (Postfix) with ESMTP id 1C2F6B9801 >> for <public-xg-socialweb-request@w3.org>; Sat, 2 May 2009 >> 17:12:39 +0100 (BST) >> Mime-Version: 1.0 (Apple Message framework v753.1) >> Content-Transfer-Encoding: 7bit >> Message-Id: <668D0E60-DCA5-4041-BC0C-76032E6B88BC@g5n.co.uk> >> Content-Type: text/plain; charset=US-ASCII; format=flowed >> To: public-xg-socialweb-request@w3.org >> From: Toby A Inkster <tai@g5n.co.uk> >> Subject: subscribe >> Date: Sat, 2 May 2009 17:13:06 +0100 >> X-Mailer: Apple Mail (2.753.1) >> Received-SPF: none >> X-SPF-Guess: pass >> X-W3C-Hub-Spam-Status: No, score=-2.6 >> X-W3C-Hub-Spam-Report: BAYES_00=-2.599 >> X-W3C-Scan-Sig: maggie.w3.org 1M0HqA-0001WG-DN >> cc8e4ab32a782eaf99df9e9951a79e4c >> >> subscribe >> >> >> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E43BA496-F1A5-4F7D-8A8A-AE18AC72C910%40g5n.co.uk Re: Consensus on alternate prefixing mechanism 2009-05-02T17:47:27 2009-05-02T17:47:27 2009-05-02T17:47:27 On 2 May 2009, at 18:16, Manu Sporny wrote: > prefix="DEFAULT_PREFIX=http://example.org/vocab/foo#" How about, instead of DEFAULT_PREFIX, an asterisk? Many people will be familiar with this as representing a 'wildcard', so it makes sense to use it to mean roughly "everything else comes from this vocabulary". Now, here's an interesting thought... CURIEs have the syntax: [ [ prefix ] ':' ]... On 2 May 2009, at 18:16, Manu Sporny wrote: > prefix="DEFAULT_PREFIX=http://example.org/vocab/foo#" How about, instead of DEFAULT_PREFIX, an asterisk? Many people will be familiar with this as representing a 'wildcard', so it makes sense to use it to mean roughly "everything else comes from this vocabulary". Now, here's an interesting thought... CURIEs have the syntax: [ [ prefix ] ':' ] reference Now, assuming that RDFa allows a default prefix to be defined (the current version does not), then CURIEs consisting of just a reference are allowed. The reference part is defined as syntactically equivalent to irelative-ref as defined by RFC 3987. In particular, irelative-refs may contain colons. Therefore if a default prefix is defined, something like 'foaf:Person' becomes a valid CURIE even without defining the 'foaf' prefix. e.g. <div prefix="*=http://example.com/" about="[me]" typeof="foaf:Person"></div> will result in the following RDF triple: <http://example.com/me> a <http://example.com/foaf:Person> which is perhaps counter-intuitive. Further, the result of this: <div prefix=" *=http://example.com/ foaf=http://xmlns.com/foaf/0.1/" about="[me]" typeof="foaf:Person"></div> actually becomes ambiguous! For this reason I recommend CURIE Syntax 1.0 be revised to recommend that any host languages which provide a default prefix or provide a mechanism for setting a default prefix, must also forbid the reference part of the CURIE to contain a colon. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9B917FD2-3035-497E-8240-2B0CDE9A6CCE%40g5n.co.uk Re: Methods for referencing URIs 2009-05-02T18:01:41 2009-05-02T18:01:41 2009-05-02T18:01:41 On 2 May 2009, at 17:56, John Graybeal wrote: > Although I am not grokking the "full URIs" example in Toby's post For anyone unfamiliar with the syntax or capitalisation conventions of PHP, a brief explanation: > include 'prefixes.php'; # A bunch of constants > /* ... */ > $object->rdf_mappings = array( > 'type' => SIOCT.'Weblog', > 'title' => DC.'title', > 'body' => SIOC. 'content'... On 2 May 2009, at 17:56, John Graybeal wrote: > Although I am not grokking the "full URIs" example in Toby's post For anyone unfamiliar with the syntax or capitalisation conventions of PHP, a brief explanation: > include 'prefixes.php'; # A bunch of constants > /* ... */ > $object->rdf_mappings = array( > 'type' => SIOCT.'Weblog', > 'title' => DC.'title', > 'body' => SIOC. 'content', > 'user_id' => DC.'creator', > ); Here I'm assuming that SIOCT, DC and SIOC have been defined as string constants in the file 'prefixes.php' -- in PHP, like many other programming language, it is convention to define constants as upper case. The dot-operator acts as a concatenation, so the array keys are assigned the full URIs as values, while the code stays reasonable. A disadvantage of this approach is that most RDF vocabularies have conventional prefixes which are short and may start with any letter of the alphabet, which may result in collisions with other constants in your program or even keywords in your programming language. (e.g. 'void' a Javascript keyword.) > include 'prefixes.php'; # A class definition > /* ... */ > $object->rdf_mappings = array( > 'type' => RDF::sioct('Weblog'), > 'title' => RDF::dc('title'), > 'body' => RDF::sioc('content'), > 'user_id' => RDF::dc('creator'), > ); Here I'm assuming that prefixes.php instead of defining constants for prefixes, defines a class (in the object-oriented programming sense of the word) called 'RDF' which has class methods (as against 'object methods' which operate on a particular copy of an object belonging to the class) named after the prefixes being used. Each method takes a string, and returns a string consisting of the full URI corresponding to that prefix and suffix. An example PHP class which fulfils this would be: class RDF { public static function dc ($suffix) { return 'http://purl.org/dc/terms/'.$suffix; } /* ... and so on ... */ } This second approach is probably my preferred one, though in retrospect, 'CURIE' might make a better name for it than 'RDF'. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CCF147D3-4C27-462A-90C3-3BED473A6642%40g5n.co.uk Re: Pre-Telecon Introductions 2009-05-05T06:26:27 2009-05-05T06:26:27 2009-05-05T06:26:27 Hello all, My name is Toby and I'm an alcoholic^H^H^H^H^H^H^H^H^H^H invited effort. I'm involved in the Microformats community, and have a general interest in web semantics - especially in bridging the gaps between the human- and machine-readable web. I've also recently joined the libre.fm development team, a project which Matt Lee has already announced on this mailing list. As the soft... Hello all, My name is Toby and I'm an alcoholic^H^H^H^H^H^H^H^H^H^H invited effort. I'm involved in the Microformats community, and have a general interest in web semantics - especially in bridging the gaps between the human- and machine-readable web. I've also recently joined the libre.fm development team, a project which Matt Lee has already announced on this mailing list. As the software developed by the project can be downloaded and installed by anyone locally, I'm interested in what this interest group's work on decentralised social networks might be able to bring to libre.fm in terms of cross-installation subscriptions and groups. I've personally always resisted joining the latest MyFriendBookSpaceClub.com-type sites, believing that if I've got my own website I should be able to use that as my online hub. The Web is The Social Network (or at least, I think it should be). I hope that this interest group goes a small way towards achieving that. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1241539594.15257.1.camel%40ophelia2.g5n.co.uk Re: RDFa in <head> 2009-05-05T16:06:34 2009-05-05T16:06:34 2009-05-05T16:06:34 On Tue, 2009-05-05 at 13:06 +0100, Stephane Corlosquet wrote: > http://drupal.deri.ie/cheese/ Oh no! It looks like my cheese club has competition! http://buzzword.org.uk/2009/cheese/paper -- Toby Inkster <tai@g5n.co.uk> On Tue, 2009-05-05 at 13:06 +0100, Stephane Corlosquet wrote: > http://drupal.deri.ie/cheese/ Oh no! It looks like my cheese club has competition! http://buzzword.org.uk/2009/cheese/paper -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/84076663-86D2-407C-8E9E-D8CF6FCC8346%40g5n.co.uk Re: Social Web Telecon: May 6 13:00 UTC 2009-05-05T16:54:12 2009-05-05T16:54:12 2009-05-05T16:54:12 On 5 May 2009, at 17:42, Uldis Bojars wrote: > There is an inconsistency in the telco start time for London > between your email (3pm) and www.timeanddate.com (2pm). 13:00 UTC is 14:00 British Summer Time, so it will be at 2pm. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 5 May 2009, at 17:42, Uldis Bojars wrote: > There is an inconsistency in the telco start time for London > between your email (3pm) and www.timeanddate.com (2pm). 13:00 UTC is 14:00 British Summer Time, so it will be at 2pm. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1241627178.1257.5.camel%40ophelia2.g5n.co.uk Re: LOD in the webpage 2009-05-06T16:26:18 2009-05-06T16:26:18 2009-05-06T16:26:18 On Tue, 2009-05-05 at 12:57 -0700, Terry Brooks wrote: > Are there examples available of making AJAX calls to a LOD repository > such as DBpedia and then displaying the results on a webpage? The edit user profile feature on http://alpha.libre.fm/ does this. If the user supplies their location, they can do an AJAX lookup for it on geonames.org and the site will save that location into their profile as a URI. Under the hood, geonames' JSON API is used, because parsing RDF/XML in Javascript in a web browser doesn't sound like my idea of a good time. -- Toby Inkster <tai@g5n.co.uk> On Tue, 2009-05-05 at 12:57 -0700, Terry Brooks wrote: > Are there examples available of making AJAX calls to a LOD repository > such as DBpedia and then displaying the results on a webpage? The edit user profile feature on http://alpha.libre.fm/ does this. If the user supplies their location, they can do an AJAX lookup for it on geonames.org and the site will save that location into their profile as a URI. Under the hood, geonames' JSON API is used, because parsing RDF/XML in Javascript in a web browser doesn't sound like my idea of a good time. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/EA4C286D-1EF1-49B9-89D4-7EB700CB8915%40g5n.co.uk planet social 2009-05-07T23:12:39 2009-05-07T23:12:39 2009-05-07T23:12:39 A number of ways for us all to communicate and collaborate were mentioned on the conference call. To help keep up with them all, I've set up "planet social": http://buzzword.org.uk/2009/social/planet/ (Apologies to Harry for stealing the logo from one of his presentations. Hope it's OK.) It currently pulls together this mailing list, the identi.ca group, the Wiki recent changes feed, an... A number of ways for us all to communicate and collaborate were mentioned on the conference call. To help keep up with them all, I've set up "planet social": http://buzzword.org.uk/2009/social/planet/ (Apologies to Harry for stealing the logo from one of his presentations. Hope it's OK.) It currently pulls together this mailing list, the identi.ca group, the Wiki recent changes feed, and the 'planet-social' tag on delicious.com. I'd also like to include relevant blogs and news sites, but only if they have a very good signal-to-noise ratio (i.e. most of their stories are relevant to this group). Suggestions welcome. Hopefully, people will find this useful. If not, then it's easy to ignore. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FD6FB9F2-C7E8-4E2B-B78A-590715C15FAB%40g5n.co.uk Re: Example RDF linking species concepts to photo gallery RDF, Suggestions or Comments Appreciated 2009-05-08T07:14:36 2009-05-08T07:14:36 2009-05-08T07:14:36 On 8 May 2009, at 01:30, Peter DeVries wrote: > With the except of the predicates speciesHasGallery, > galleryHasSpecies. In <http://dig.csail.mit.edu/breadcrumbs/node/72> Tim Berners-Lee writes: > On the other hand, also one should not encourage people having to > declare both a property and its inverse, which would simply double > the number of definitions out there, and give one more... On 8 May 2009, at 01:30, Peter DeVries wrote: > With the except of the predicates speciesHasGallery, > galleryHasSpecies. In <http://dig.csail.mit.edu/breadcrumbs/node/72> Tim Berners-Lee writes: > On the other hand, also one should not encourage people having to > declare both a property and its inverse, which would simply double > the number of definitions out there, and give one more axis of > arbitrary variation in the way information is expressed. > In other words, there isn't really a need to define both speciesHasGallery *and* galleryHasSpecies. You only need one of them. I've fallen into the trap of defining inverse properties before and when it comes to actually working with the data (e.g. performing SPARQL queries), it ends up complicating things. Also, have you seen <http://purl.org/NET/biol/ns#> ? If you make geospecies:SpeciesConcept an rdfs:subClassOf biol:Taxonomy, then geospecies:speciesHasGallery can be an rdfs:subPropertyOf biol:seeAlso. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242119672.15673.7.camel%40ophelia2.g5n.co.uk RE: last.fm events RDFizing 2009-05-12T09:14:33 2009-05-12T09:14:33 2009-05-12T09:14:33 On Tue, 2009-05-12 at 10:02 +0100, John Goodwin wrote: > All we need to do now is link the venues to resources for place in the > OS, geonames or whatever datasets. libre.fm, the Free Software replacement for last.fm, publishes linked data, including (where available) dbtunes.org/musicbrainz and geonames.org. The site seems to be down right now. :-( But when it's back up, take a look at: http://alpha.dev.libre.fm/user/tobyink -- Toby Inkster <mail@tobyinkster.co.uk> On Tue, 2009-05-12 at 10:02 +0100, John Goodwin wrote: > All we need to do now is link the venues to resources for place in the > OS, geonames or whatever datasets. libre.fm, the Free Software replacement for last.fm, publishes linked data, including (where available) dbtunes.org/musicbrainz and geonames.org. The site seems to be down right now. :-( But when it's back up, take a look at: http://alpha.dev.libre.fm/user/tobyink -- Toby Inkster <mail@tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242123644.15673.12.camel%40ophelia2.g5n.co.uk Re: OWL and LOD 2009-05-12T10:20:45 2009-05-12T10:20:45 2009-05-12T10:20:45 On Tue, 2009-05-12 at 10:49 +0100, John Goodwin wrote: > I was just curious how many OWL sceptics we have in the LOD community? > Rightly or wrongly I get the impression there are a few? If I could be sure that my SPARQL query environment would use OWL reasoning to fill in the gaps in its knowledge, then I'd be more inclined to publish OWL data. But right now there is a dearth of high-quality, widely-used OWL implementations. -- Toby Inkster <mail@tobyinkster.co.uk> On Tue, 2009-05-12 at 10:49 +0100, John Goodwin wrote: > I was just curious how many OWL sceptics we have in the LOD community? > Rightly or wrongly I get the impression there are a few? If I could be sure that my SPARQL query environment would use OWL reasoning to fill in the gaps in its knowledge, then I'd be more inclined to publish OWL data. But right now there is a dearth of high-quality, widely-used OWL implementations. -- Toby Inkster <mail@tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242125970.15673.27.camel%40ophelia2.g5n.co.uk Re: OWL and LOD 2009-05-12T10:59:30 2009-05-12T10:59:30 2009-05-12T10:59:30 On Tue, 2009-05-12 at 11:37 +0100, Steve Harris wrote: > I was thinking more of this issue: > http://lists.w3.org/Archives/Public/semantic-web/2009May/0071.html > re. slide 26. I've seen this done too, and it's quite concerning. owl:sameAs is a very blunt tool and rarely useful. Instead we should be thinking about domain-specific equivalency predicates. Take for example: 1. <http://tobyinkster... On Tue, 2009-05-12 at 11:37 +0100, Steve Harris wrote: > I was thinking more of this issue: > http://lists.w3.org/Archives/Public/semantic-web/2009May/0071.html > re. slide 26. I've seen this done too, and it's quite concerning. owl:sameAs is a very blunt tool and rarely useful. Instead we should be thinking about domain-specific equivalency predicates. Take for example: 1. <http://tobyinkster.co.uk/#i> 2. <http://www.doc.ic.ac.uk/~tai99/foaf.xml#me> Both are URLs representing me -- the first is recent and kept up to date; the second is a much older URL that 404s and I'm no longer able to update. Depending on what you're doing, it might be useful to treat these two as equivalent. If you have information on [2]'s blood type, then it's probably equally applicable to [1]. But for other purposes it's useful to treat them separately. The marital status of [1] and [2] differ, as do their interests, their e-mail addresses and various other details. This is where equivalency predicates come in. It might be useful, for example, to have a foaf:samePersonAs predicate to allow us to assert that two URLs represent the same person, but still not glue them together as tightly as owl:sameAs does, so that we can still make statements about them individually. I don't know if OWL2 could then allow us to then define which of our favourite predicates can be cross-applied between two resources which are foaf:samePersonAs each other, and which may differ. (I don't think OWL1 is capable of that.)  -- Toby Inkster <mail@tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242128413.15673.44.camel%40ophelia2.g5n.co.uk Re: last.fm events RDFizing 2009-05-12T11:40:14 2009-05-12T11:40:14 2009-05-12T11:40:14 On Tue, 2009-05-12 at 07:09 -0400, Kingsley Idehen wrote: > Since libre.fm is just another linked data space, I would encourage > cross linkage via URIs. We do! As I said, when we can figure them out, we use dbtune.org/musicbrainz URIs to represent tracks, records and artists; and we use sws.geonames.org URIs to represent places. These URIs are included in the RDFa (and thus in the other RDF se... On Tue, 2009-05-12 at 07:09 -0400, Kingsley Idehen wrote: > Since libre.fm is just another linked data space, I would encourage > cross linkage via URIs. We do! As I said, when we can figure them out, we use dbtune.org/musicbrainz URIs to represent tracks, records and artists; and we use sws.geonames.org URIs to represent places. These URIs are included in the RDFa (and thus in the other RDF serialisations which are generated from the RDFa). We also allow people to add a WebID to their profile, so that we can publish triples along the lines of: <http://tobyinkster.co.uk/#i> <http://xmlns.com/foaf/0.1/holdsAccount> <http://alpha.dev.libre.fm/user/tobyink#acct> . The profile edit page includes a wizard allowing people to figure out their WebID by providing a homepage, identi.ca account, FOAF file, etc. We're publishing using FOAF, SIOC, RSS 1.0, Music Ontology, Events Ontology and Dublin Core. The main libre.fm server is currently down, but in the mean time, feel free to peak at my local installation which is fairly representative of the type of data published on the real libre.fm. (Though my local database doesn't have as much musicbrainz data.) N-Triples of my profile on my local installation: http://nixtape.g5n.co.uk/rdf.php?fmt=nt&page=/user/tobyink I'm on #swig today if you have any suggestions for improvements. -- Toby Inkster <mail@tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242204147.15673.57.camel%40ophelia2.g5n.co.uk Re: RDFa Tutorial 2009-05-13T08:42:28 2009-05-13T08:42:28 2009-05-13T08:42:28 On Wed, 2009-05-13 at 00:13 +0200, Steven Pemberton wrote: > http://www.w3.org/MarkUp/2009/rdfa-for-html-authors Looks like a good start. A few comments: | Essentially all knowledge is gathered as assertions of the form: | | URI property value Would be nice to have a bit of punctuation in there to separate out the components. Perhaps something like: URI → property → value And then for... On Wed, 2009-05-13 at 00:13 +0200, Steven Pemberton wrote: > http://www.w3.org/MarkUp/2009/rdfa-for-html-authors Looks like a good start. A few comments: | Essentially all knowledge is gathered as assertions of the form: | | URI property value Would be nice to have a bit of punctuation in there to separate out the components. Perhaps something like: URI → property → value And then for other N-Triples-like blocks in the text, employ the same mechanism to demonstrate the triple. | Unfortunately, this says that the creator of the page about the | poem is T.S. Eliot, which is patently not true. Might be more clear as "Unfortunately, this says that T. S. Eliot created the Wikipedia page, which is patently not true." | <a about"[_:W3C]" rel="foaf:homepage" | href="http://www.w3.org/">W3C</a> Missing an equals sign. Under the "Packaging a group of relations" heading, the highlighted @typeof doesn't actually do any packaging - the existing @about already packages the properties together. You may wish to include a brief introduction to a few commonly used vocabs - e.g. FOAF, DC, iCal. Explain each one's scope and purpose and about 6 to 10 of the most important classes and properties, and give a little example of using them, and finally an example of using all three together to describe, say, a book which has been written by a person, which has a primary topic that is an event. -- Toby Inkster <mail@tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242209693.15673.87.camel%40ophelia2.g5n.co.uk Re: OWL and LOD 2009-05-13T10:14:56 2009-05-13T10:14:56 2009-05-13T10:14:56 On Wed, 2009-05-13 at 00:59 +0100, Hugh Glaser wrote: > But generating equivalency predicates for every conceivable domain is > not the way to go, I would suggest. That's not quite what I meant. Rather that OWL should provide the right tools to enable existing domain-specific vocabularies (e.g. FOAF for people, DOAP for software projects, DC for artifacts, etc) to define their own equivalency pro... On Wed, 2009-05-13 at 00:59 +0100, Hugh Glaser wrote: > But generating equivalency predicates for every conceivable domain is > not the way to go, I would suggest. That's not quite what I meant. Rather that OWL should provide the right tools to enable existing domain-specific vocabularies (e.g. FOAF for people, DOAP for software projects, DC for artifacts, etc) to define their own equivalency properties. Some vocabularies already have terms that could benefit from such tools. e.g.: * Richard Cyganiak's XFN vocabulary's "me-hyperlink" term. The two pages are equivalent in that they can both be used to indicate the same person in XFN terms. * DCMI's hasFormat/isFormatOf. The two resources are "substantially the same [...] but in another format". In both these cases, the resources being described are different, but for many purposes it's useful to consider them identical. It would be good if OWL was able to be used to express something like this: [] is owl:equivRule of dc:hasFormat ; owl:implication [ owl:propertyOnOne dc:title ; owl:propertyOnAll ex:looseTitle ; owl:validity owl:Always ] . Which allowed us to reason: { _:A dc:hasFormat _:A1 , _:A2 ; dc:title "Foo" . } => { _:A ex:looseTitle "Foo" . _:A1 ex:looseTitle "Foo" . _:A2 ex:looseTitle "Foo" . } . -Toby http://tobyinkster.co.uk/message/1242294608.15673.163.camel%40ophelia2.g5n.co.uk Re: New RDFa Profiles document (first pass) 2009-05-14T09:50:12 2009-05-14T09:50:12 2009-05-14T09:50:12 On Wed, 2009-05-13 at 00:37 -0400, Manu Sporny wrote: > http://rdfa.info/wiki/rdfa-profiles I think I've stated on this list before that I'm an RDFa Profile sceptic. Having URI-based extensibility without the pain of constantly looking up URIs is certainly appealing. (And I want to know who thought it would be a good idea to give the main RDF namespace such a long and impossible to remember URL... On Wed, 2009-05-13 at 00:37 -0400, Manu Sporny wrote: > http://rdfa.info/wiki/rdfa-profiles I think I've stated on this list before that I'm an RDFa Profile sceptic. Having URI-based extensibility without the pain of constantly looking up URIs is certainly appealing. (And I want to know who thought it would be a good idea to give the main RDF namespace such a long and impossible to remember URL!) However, I don't know if this is the best way of achieving it. By relying on prefix definitions outside the document itself, you introduce an extra level of fragility. What happens if the profile document disappears? This would make RDFa a less suitable format for archival. Some might say, that RDF is doomed already, because when I say that I'm a <http://xmlns.com/foaf/0.1/Person> I'm relying on danbri's definition of a Person, and if he goes crazy and changes it, then I'll be in trouble. But that's not quite true. Sure, danbri keeps a definition of <http://xmlns.com/foaf/0.1/Person> at the URL itself. But I can also keep a definition of what a <http://xmlns.com/foaf/0.1/Person> is somewhere else. While my definition might not be as easy to find, under the RDF model it's treated just the same as danbri's. In 50 years' time, once I've loaded by definition of <http://xmlns.com/foaf/0.1/Person> and all the other FOAF terms, and my archive document into a reasoning engine, I can start to use it. Even if nobody has a definition of exactly what a <http://xmlns.com/foaf/0.1/Person> is anymore, it's still possible to reason that all the resources on the web with that type are the same general sort of thing in some way. With RDFa Profiles, it's not as clear that this will work. If the profile document disappears, I won't know whether typeof="Person" refers to <http://xmlns.com/foaf/0.1/Person> or some other definition of a Person (Google's?). Two documents could be using typeof="Person" to refer to different classes and if the profile documents were gone, then we'd never know. Separating prefix definitions from the document also introduces other shorter-term practical problems: it requires RDFa implementations to have network access. Nowadays, most programming languages provide HTTP stuff out of the box, but there are still some scripting languages which are limited in this area. Javascript in particular is an area of concern - there are various same-origin limitations on XmlHttpRequest - as is XSLT. There is also a speed penalty incurred by fetching another document - especially another document on another server as that means that HTTP pipe-lining can't be employed. Now, let's make this message one of *constructive* criticism instead of just criticism. One of the main benefits of RDFa profiles is the ability to be able to use terms without prefixes. Another way to be able to do this would be setting a default prefix - the CURIE draft already allows for a default prefix, so it's just a matter of providing authors with a mechanism to specify it. This could involve a tiny tweak to existing syntax: <div xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dc="http://purl.org/dc/terms/"> ... <div rel="dc:creator"> <p typeof="+foaf:Person"> <a rel="homepage" href="http://tobyinkster.co.uk/" property="name">Toby Inkster</a> </p> </div> </div> Note the special @typeof syntax which would be defined to not just set the blank node's type, but also define the default prefix for all descendant elements. In my imagination, this syntax is only allowed on @typeof (not other RDFa attributes) because when you specify the type that something has, then you create expectations of the vocabulary you're going to use to describe it. This is roughly compatible with the current version of RDFa, in that the triples generated by an existing parser would be a subset of the triples generated by a plus-sign-aware parser. i.e. # Standard: <> dc:creator _:x1 . # Plus-sign-aware:  <> dc:creator _:x1 . _:x1 a foaf:Person . _:x1 foaf:homepage <http://tobyinkster.co.uk/> . _:x1 foaf:name "Toby Inkster" . Another alternative way of setting the default prefix would be to use @profile more directly. The @profile attribute is allowed on all elements and provides a list of URIs. The first URI in the list is taken to be the default prefix. (Other URIs may be present and can be used for other purposes - e.g. GRDDL.) If the URI ends in an alpha-numeric character, then a '#' sign is appended automatically. If there is a head@profile attribute, but no html@profile, then head@profile is automatically applied to the <html> element. This interpretation is compatible with the current RDFa-recommended profile of <http://www.w3.org/1999/xhtml/vocab>. -- Toby Inkster <mail@tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242299983.15673.208.camel%40ophelia2.g5n.co.uk Linked railway data for the UK 2009-05-14T11:19:43 2009-05-14T11:19:43 2009-05-14T11:19:43 I saw this on the linkeddata.org shopping list a few days ago, and thought it would be a good thing to noodle with in my spare time. So I've turned my screen scraping expertise at various railway-related websites and put together this: http://ontologi.es/rail/ It's still at a very early stage. Stations have URIs like: http://ontologi.es/rail/stations/gb/VIC (London Victoria) http://ontologi.es/... I saw this on the linkeddata.org shopping list a few days ago, and thought it would be a good thing to noodle with in my spare time. So I've turned my screen scraping expertise at various railway-related websites and put together this: http://ontologi.es/rail/ It's still at a very early stage. Stations have URIs like: http://ontologi.es/rail/stations/gb/VIC (London Victoria) http://ontologi.es/rail/stations/gb/STP (London St Pancras) http://ontologi.es/rail/stations/gb/MAN (Manchester Piccadilly) http://ontologi.es/rail/stations/gb/LIV (Liverpool Lime Street) If you know a station's three-letter Computer Reservation System code, then you should be able to work out its URI. (I don't have any plans to include data for other countries, but if anyone else is doing this, I'm happy to provide 303 redirects.) Data is published in XHTML+RDFa, but server-side scripts are on hand to translate to RDF/XML, Turtle, N-Triples and JSON if you hit those URIs with the proper HTTP Accept header magic. (Or if you can't be bothered to set the Accept header, then a simple '.ttl', '.nt', '.rdf' or '.json' at the end will do the trick.) This is still a fairly early draft. I plan on including some geonames.org links from each station to the town it serves. There are owl:sameAs links to dbpedia.org (though some of these hit redirect pages, so some work is still needed). The "facilities" area is also going to be improved. I'd be happy to receive suggestions as to what other improvements people would like. As part of the same project, I've created a rail vocabulary: http://ontologi.es/rail/vocab# Terms that people might find useful are: * rail:nearest_station The nearest station to a geo:SpatialThing. * rail:home_station The station a foaf:Agent considers to be 'home'. (This is more appropriate than rail:nearest_station for people - people are capable of motion, so their rail:nearest_station can vary with time!) -Toby http://tobyinkster.co.uk/message/1242302258.15673.222.camel%40ophelia2.g5n.co.uk dbpedia wishlist 2009-05-14T11:57:38 2009-05-14T11:57:38 2009-05-14T11:57:38 The SPARQL interface is great, but it would be nice if dbpedia provided a few shortcuts for some simple operations which shouldn't need complex requests to handle. In particular, what I'd like to see would be: 1. A page that I can post a great big list of dbpedia resource URIs to and get back an N-Triples file containing just dbprop:redirect triples for any of those URLs which is a redirect. This... The SPARQL interface is great, but it would be nice if dbpedia provided a few shortcuts for some simple operations which shouldn't need complex requests to handle. In particular, what I'd like to see would be: 1. A page that I can post a great big list of dbpedia resource URIs to and get back an N-Triples file containing just dbprop:redirect triples for any of those URLs which is a redirect. This would provide a quick and easy way of fixing my references to dbpedia. 2. A request for <http://dbpedia.org/depiction/%s> should run the following SPARQL query (or equivalent): SELECT ?depiction WHERE { <http://dbpedia.org/resource/%s> <http://xmlns.com/foaf/0.1/depiction> ?depiction } If no results are found, it should return a 404, but if a result is found, perform a 302 redirect to the depiction found. -Toby http://tobyinkster.co.uk/message/1242325156.15673.240.camel%40ophelia2.g5n.co.uk Re: HTML 4 Profile for RDFa 2009-05-14T18:19:17 2009-05-14T18:19:17 2009-05-14T18:19:17 On Thu, 2009-05-14 at 12:41 -0500, Shane McCarron wrote: > You can find the latest version at > http://www3.aptest.com/standards/rdfa-html/ For XMLLiterals which aren't well-formed would it be a good compromise to say that the literal should still be generated as normal (i.e. including tags) but just shouldn't be given an rdf:XMLLiteral datatype? e.g. <p property="rdfs:comment">Hello<br>World</p> Generates: <rdf:Description about=""> <rdfs:comment>Hello&lt;br&gt;World</rdfs:comment> </rdf:Desciption> This makes it more consistent with XHTML+RDFa. -- Toby Inkster <tai@g5n.co.uk> On Thu, 2009-05-14 at 12:41 -0500, Shane McCarron wrote: > You can find the latest version at > http://www3.aptest.com/standards/rdfa-html/ For XMLLiterals which aren't well-formed would it be a good compromise to say that the literal should still be generated as normal (i.e. including tags) but just shouldn't be given an rdf:XMLLiteral datatype? e.g. <p property="rdfs:comment">Hello<br>World</p> Generates: <rdf:Description about=""> <rdfs:comment>Hello&lt;br&gt;World</rdfs:comment> </rdf:Desciption> This makes it more consistent with XHTML+RDFa. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1242379709.18078.15.camel%40ophelia2.g5n.co.uk RE: Linked railway data for the UK 2009-05-15T09:28:30 2009-05-15T09:28:30 2009-05-15T09:28:30 On Fri, 2009-05-15 at 06:44 +0100, Michael Smethurst wrote: > http://ontologi.es/rail/stations/gb/MAN.rdf > > and wondering if there's some confusion between location and > administrative office / postal address. > > in the case of piccadilly it's a complex of buildings. the admin > office / postal address is in a high rise alongside the actual station > and only connected by a covered walkway. ... On Fri, 2009-05-15 at 06:44 +0100, Michael Smethurst wrote: > http://ontologi.es/rail/stations/gb/MAN.rdf > > and wondering if there's some confusion between location and > administrative office / postal address. > > in the case of piccadilly it's a complex of buildings. the admin > office / postal address is in a high rise alongside the actual station > and only connected by a covered walkway. hence the vcard of: > > <vcard:label xml:lang="en">9th Floor, Piccadilly Tower, Piccadilly > station. Manchester M1 2PZ</vcard:label> > > which i guess would be more suitable for helicopters than trains :-) vCard's label property is defined as "the the formatted text corresponding to delivery address of the object the vCard represents", so the RDF seems correct to me. If you wanted to have a letter delivered to the station, then that's the formatted text that you'd put on the envelope. Perhaps the HTML could be made a little clearer though, and list "Address" and "Location" as separate items of data. > but the lat, long is given as: 53.4775, -2.2313 which is also the > admin building. whereas dbpedia has lat long of 53.477001, -2.230000 > which is the actual station Six decimal places of a degree (as per dbpedia) locates an object rather more precisely than is sensible for railway stations which are typically rather big constructions (esp. Manchester Piccadilly if I recall correctly - I've not been to Manchester in almost 10 years). 0.000001 latitude is about 1 metre. 0.000001 longitude varies depending on where you are on Earth, but in the UK represents about 60 or 70 centimetres. If I've given a station's location as 53.4775, -2.2313 and some part of the station lies in the bounding box: 53.47755, -2.23125 ---------- 53.47755, -2.23135 | | | | 53.47745, -2.23125----------- 53.47745, -2.23135 then I'm happy. > not sure if there are any stations where the admin office is off site > but i guess that's not impossible and might prove problematic in the > future?1? anyway, just thought i'd point this out in case it caused > any clashing claim problems when trying to mesh up with dbpedia, > geonames etc My links to geonames were going to be to the city / town / suburb which the station serves, but actually there do seem to be a number of railway stations listed on geonames.org, so I might try linking up with them too. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/57F889C5-F5C5-453E-8BA0-5B4D5C70F953%40g5n.co.uk Re: Link rot is not dangerous (was: Re: [whatwg] Annotating structured data that HTML has nosemanticsfor) 2009-05-16T08:23:43 2009-05-16T08:23:43 2009-05-16T08:23:43 On 15 May 2009, at 17:20, Manu Sporny wrote: > The argument that link rot would cause massive damage to the semantic > web is just not true. Even if there is minor damage caused, it is > fairly > easy to recover from it, as outlined above. I was talking about this recently somewhere (can't remember where). The RDF model is different from {key:value} models in that it has a third component ... On 15 May 2009, at 17:20, Manu Sporny wrote: > The argument that link rot would cause massive damage to the semantic > web is just not true. Even if there is minor damage caused, it is > fairly > easy to recover from it, as outlined above. I was talking about this recently somewhere (can't remember where). The RDF model is different from {key:value} models in that it has a third component - a subject. This means that while a description for <http://xmlns.com/foaf/0.1/Person> (which I'll refer to as 'foaf:Person' from now on, for brevity) can be found at the URL foaf:Person, it's also possible for descriptions of foaf:Person to be found elsewhere. While the description for foaf:Person at foaf:Person is clearly much easier to find than other descriptions for foaf:Person, under the RDF model, they are all afforded equal weight. If foaf:Person disappeared tomorrow, and even if I couldn't find an alternative source for that definition, the URI would still not be useless. I'd still know, say, that Toby Inkster is a foaf:Person, and Manu Sporny is a foaf:Person and from that I'd be able to conclude that they're the same sort of thing in some way. Given enough instance data like that, I might even be able to analyse the instance data, looking at what all the instances of foaf:Person had in common and rediscover the original definition of foaf:Person. The ability to dereference an RDF class or property to discover more about it is very useful. A data format without that ability is all the poorer for not having it. But, when that dereferencing fails, all is not lost. So when in use cases, RDF fans talk about it being 'essential' to be able to follow their noses to definitions of terms, what is meant is that it's essential that a mechanism exists to enable this technique - it not essential that the definitions are always found. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/97F62F5F-5B45-4F68-B1A7-908CB27B0B5A%40tobyinkster.co.uk Re: Link rot is not dangerous (was: Re: [whatwg] Annotating structured data that HTML has nosemanticsfor) 2009-05-16T08:26:11 2009-05-16T08:26:11 2009-05-16T08:26:11 On 15 May 2009, at 17:20, Manu Sporny wrote: > The argument that link rot would cause massive damage to the semantic > web is just not true. Even if there is minor damage caused, it is > fairly > easy to recover from it, as outlined above. I was talking about this recently somewhere (can't remember where). The RDF model is different from {key:value} models in that it has a third component -... On 15 May 2009, at 17:20, Manu Sporny wrote: > The argument that link rot would cause massive damage to the semantic > web is just not true. Even if there is minor damage caused, it is > fairly > easy to recover from it, as outlined above. I was talking about this recently somewhere (can't remember where). The RDF model is different from {key:value} models in that it has a third component - a subject. This means that while a description for <http://xmlns.com/foaf/0.1/Person> (which I'll refer to as 'foaf:Person' from now on, for brevity) can be found at the URL foaf:Person, it's also possible for descriptions of foaf:Person to be found elsewhere. While the description for foaf:Person at foaf:Person is clearly much easier to find than other descriptions for foaf:Person, under the RDF model, they are all afforded equal weight. If foaf:Person disappeared tomorrow, and even if I couldn't find an alternative source for that definition, the URI would still not be useless. I'd still know, say, that Toby Inkster is a foaf:Person, and Manu Sporny is a foaf:Person and from that I'd be able to conclude that they're the same sort of thing in some way. Given enough instance data like that, I might even be able to analyse the instance data, looking at what all the instances of foaf:Person had in common and rediscover the original definition of foaf:Person. The ability to dereference an RDF class or property to discover more about it is very useful. A data format without that ability is all the poorer for not having it. But, when that dereferencing fails, all is not lost. So when in use cases, RDF fans talk about it being 'essential' to be able to follow their noses to definitions of terms, what is meant is that it's essential that a mechanism exists to enable this technique - it not essential that the definitions are always found. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A83CF7AD-57F4-4E2F-B5AE-717E65DBF781%40g5n.co.uk Triple stores with RDFS inferencing 2009-05-19T18:06:05 2009-05-19T18:06:05 2009-05-19T18:06:05 I'm looking for a triple store for a project. It needs to support the following: * SPARQL support. SPARQL Update would be nice. * RDFS inferencing. OWL is not required, but would be a bonus. e.g. SELECT * WHERE { ?resource a ex:Class . } should also return instances of subclasses of ex:Class. * Web API. Preferably supporting SPARQL Protocol. Right now it looks like the com... I'm looking for a triple store for a project. It needs to support the following: * SPARQL support. SPARQL Update would be nice. * RDFS inferencing. OWL is not required, but would be a bonus. e.g. SELECT * WHERE { ?resource a ex:Class . } should also return instances of subclasses of ex:Class. * Web API. Preferably supporting SPARQL Protocol. Right now it looks like the combination of Jena+Joseki will meet my needs the best, but I'd be interested to hear others' opinions on good tools to try. Would Virtuoso do the job? Can it do inferencing? The dataset I'm hoping to use will be in the order of tens, perhaps hundreds of thousands of triples - probably not into the millions, so performance is probably not going to be the deciding factor. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/18751FFE-0F6C-4785-BF63-91BC17FEA9D7%40tobyinkster.co.uk Re: Wiki-based vocabulary website idea 2009-05-19T23:14:33 2009-05-19T23:14:33 2009-05-19T23:14:33 On 19 May 2009, at 22:02, Sergey Chernyshev wrote: > RDFa support project was started by CC team as part of GSoC last > year, but didn't make it's way to the core yet. Don't know if you've seen this before, but here's a very quick hack to get RDFa working in MediaWiki: http://buzzword.org.uk/2009/mediawiki-patches/xhtml-rdfa.patch Also of interest perhaps: http://buzzword.org.uk/2009/med... On 19 May 2009, at 22:02, Sergey Chernyshev wrote: > RDFa support project was started by CC team as part of GSoC last > year, but didn't make it's way to the core yet. Don't know if you've seen this before, but here's a very quick hack to get RDFa working in MediaWiki: http://buzzword.org.uk/2009/mediawiki-patches/xhtml-rdfa.patch Also of interest perhaps: http://buzzword.org.uk/2009/mediawiki-patches/relAlternate- semantics.patch which adds @about to rel="alternate" links (because they're not usually an alternative for the current page!) Lastly, this extension allows setting the rel, rev and class attributes of links: http://www.mediawiki.org/wiki/Extension:Link_Attributes -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9F15AC54-FC36-4201-BDB5-5E7994138A56%40tobyinkster.co.uk Re: [whatwg] Link rot is not dangerous 2009-05-20T07:35:36 2009-05-20T07:35:36 2009-05-20T07:35:36 On 20 May 2009, at 05:23, Tab Atkins Jr. wrote: > Specifically, people can use a search engine to find information about > foaf. I know that typing "foaf" into my browser's address bar and > clicking on the first likely link is *way* faster than digging into a > document with a foaf namespace declared, finding the url, and > copy/pasting that into the location bar. FOAF is a very famous vocabu... On 20 May 2009, at 05:23, Tab Atkins Jr. wrote: > Specifically, people can use a search engine to find information about > foaf. I know that typing "foaf" into my browser's address bar and > clicking on the first likely link is *way* faster than digging into a > document with a foaf namespace declared, finding the url, and > copy/pasting that into the location bar. FOAF is a very famous vocabulary, so this happens to work quite well for FOAF. Consider Dublin Core though. Typing "dc" into Google brings up results for DC Comics, DC Shoes, Washington DC and a file sharing application called Direct Connect, all ahead of Dublin Core, which is the nineth result. Even if I spot that result, clicking through takes me to the Dublin Core Metadata Initiative's homepage, which is mostly full of conference and event information - not the definitions I'm looking for. On the other hand, typing <http://purl.org/dc/terms/issued> into my browser's address bar gives me an RDFS definition of the term immediately. Your suggestion also makes the assumption that there is a single correct answer that Google/Yahoo/whatever could give to such a query - that any given string used as a prefix will only ever be legitimately bound to one vocabulary. That is simply not the case: "dc" for example is most often used with Dublin Core Elements 1.1, but still occasionally seen as a prefix for the older 1.0 version, and increasingly being used with the new Dublin Core Terms collection. While Elements 1.0 and 1.1 are largely compatible (the latter introduces two extra terms IIRC), Dublin Core Terms has significant differences. "bio" is another string commonly bound to different vocabularies - both the biographical vocab often used in conjunction with FOAF, plus various life-science-related vocabularies. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/672D8C20-33EB-46B7-B302-E9D22FE19B90%40g5n.co.uk Re: RDF: a suitable NLP KB representation (Was: Owning URIs (Was: Yet Another LOD cloud browser)) 2009-05-20T07:47:47 2009-05-20T07:47:47 2009-05-20T07:47:47 On 20 May 2009, at 06:44, David Huynh wrote: > And look what happened to Esperanto... After one century, 2 million > speakers, or 0.025% of the world population. Given that most human languages don't have a definitive "start date", it is difficult to directly compare this with languages like French or Spanish. At the time French "started", it already had millions of speakers because Fre... On 20 May 2009, at 06:44, David Huynh wrote: > And look what happened to Esperanto... After one century, 2 million > speakers, or 0.025% of the world population. Given that most human languages don't have a definitive "start date", it is difficult to directly compare this with languages like French or Spanish. At the time French "started", it already had millions of speakers because French was defined by whatever the people of France were speaking. That said, 2 million is fairly impressive. It beats Basque, Welsh and Irish Gaelic - the last of these is an official language of the EU! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1242824086.19079.11.camel%40ophelia2.g5n.co.uk Re: DBpedia user, who are you? 2009-05-20T12:54:47 2009-05-20T12:54:47 2009-05-20T12:54:47 On Wed, 2009-05-20 at 13:04 +0200, Georgi Kobilarov wrote: > - What are you doing with it or how would you like to use it, Linked railway data project - right now, I'm just querying dbpedia to find an alternative URI for each station, so that I can provide ovterms:similarTo links from one URI for the station to another. But in the future I'd hope to also pull data about each station from dbpedi... On Wed, 2009-05-20 at 13:04 +0200, Georgi Kobilarov wrote: > - What are you doing with it or how would you like to use it, Linked railway data project - right now, I'm just querying dbpedia to find an alternative URI for each station, so that I can provide ovterms:similarTo links from one URI for the station to another. But in the future I'd hope to also pull data about each station from dbpedia. libre.fm - not using dbpedia yet, but it's being considered as a place to find album art, artist biographies, etc. > - How would you like to see it evolve? Batch queries would be nice. Imagine that I want to find a particular piece of information about multiple resources - e.g. the number of platforms a train station has, for each station in a list I've got of 1000. Right now I have two options, a single SPARQL query like: SELECT ?s ?o WHERE { ?s dbpedia:platforms ?o } which might return hundreds of results for subjects I'm not interested in; or querying each subject individually. The former is not the best use of bandwidth, especially for properties like rdfs:label where there are likely to be far more irrelevant results than relevant; and the latter can't be especially efficient in terms of dbpedia's CPU time. The other thing I'd like to see is some sort of better reasoning about redirects. I don't know quite how, but there must be something better than what we have now. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1242830356.19079.23.camel%40ophelia2.g5n.co.uk Clarity in agendas 2009-05-20T14:39:17 2009-05-20T14:39:17 2009-05-20T14:39:17 I don't wish to be overly critical, but the agenda put out before today's conference call had a couple of clarity issues. The datetime is listed as "2009-05-20T14:00-160-". Assuming that last dash is supposed to be a 0, and assuming that UTC is the intended timezone, that's a two hour meeting starting at 2 pm UTC. In fact, we had a one hour meeting starting at 1 pm UTC. I was lucky in that I chec... I don't wish to be overly critical, but the agenda put out before today's conference call had a couple of clarity issues. The datetime is listed as "2009-05-20T14:00-160-". Assuming that last dash is supposed to be a 0, and assuming that UTC is the intended timezone, that's a two hour meeting starting at 2 pm UTC. In fact, we had a one hour meeting starting at 1 pm UTC. I was lucky in that I checked in #swxg ahead of time, and in fact a good number of people seem to have turned up at the intended time, but it looks like Hao Wang doesn't possess our mind-reading skills, and there may well have been more people who missed out on this. Permatime.com is a pretty good way of removing any doubt about a datetime. e.g. http://permatime.com/UTC/2009-05-27/13:00/Next_teleconference Alternatively, Ian Davis provides nice RDF-enabled datetime URIs: http://placetime.com/interval/gregorian/2009-05-27T13:00:00Z/PT1H The other issue, more minor, is that the IRC channel was listed as #sxwg instead of #swxg - this was also on the 2009-05-13 agenda. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1242832513.19079.26.camel%40ophelia2.g5n.co.uk Re: DBpedia user, who are you? 2009-05-20T15:15:14 2009-05-20T15:15:14 2009-05-20T15:15:14 On Wed, 2009-05-20 at 14:57 +0100, Yves Raimond wrote: > 3) An interface for submitting out-going links, instead of having to > ping the dbpedia list each time Ooh!! This can be done?! Ping! http://ontologi.es/rail/links_dbpedia.ttl -- Toby Inkster <tai@g5n.co.uk> On Wed, 2009-05-20 at 14:57 +0100, Yves Raimond wrote: > 3) An interface for submitting out-going links, instead of having to > ping the dbpedia list each time Ooh!! This can be done?! Ping! http://ontologi.es/rail/links_dbpedia.ttl -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1242833758.19079.34.camel%40ophelia2.g5n.co.uk Re: RDFa Tutorial 2009-05-20T15:35:58 2009-05-20T15:35:58 2009-05-20T15:35:58 On Wed, 2009-05-20 at 14:56 +0200, Steven Pemberton wrote: > <span property="event:dtend" content="2009-04-25">24th April</span> > > maybe if I add a time, so that it at least mentions the right date. IIRC ISO 8601 has an interesting construction "T24:00" which represents the very last instant of a particular day. So you could do: <span property="event:dtend" content="2009-04-24T24:00:00" >24th April</span> xsd:dateTime does explicitly allow this notation. I can't remember whether iCalendar / the RDF iCalendar vocab allows it though. -- Toby Inkster <tai@g5n.co.uk> On Wed, 2009-05-20 at 14:56 +0200, Steven Pemberton wrote: > <span property="event:dtend" content="2009-04-25">24th April</span> > > maybe if I add a time, so that it at least mentions the right date. IIRC ISO 8601 has an interesting construction "T24:00" which represents the very last instant of a particular day. So you could do: <span property="event:dtend" content="2009-04-24T24:00:00" >24th April</span> xsd:dateTime does explicitly allow this notation. I can't remember whether iCalendar / the RDF iCalendar vocab allows it though. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1242834795.19079.50.camel%40ophelia2.g5n.co.uk Re: Using <col> to add table hierarchy 2009-05-20T15:53:16 2009-05-20T15:53:16 2009-05-20T15:53:16 On Wed, 2009-05-20 at 12:25 +0200, Steven Pemberton wrote: > http://people.csail.mit.edu/eob/2009/05/19/a-simple-extension-for-microformat-rdfa-table-support/ Microformats do actually have a similar notation for propagating information through tables. It doesn't use <col/> though - rather it uses <th id> and <td headers>. <table summary="Workshops by time and location."> <caption>Today's works... On Wed, 2009-05-20 at 12:25 +0200, Steven Pemberton wrote: > http://people.csail.mit.edu/eob/2009/05/19/a-simple-extension-for-microformat-rdfa-table-support/ Microformats do actually have a similar notation for propagating information through tables. It doesn't use <col/> though - rather it uses <th id> and <td headers>. <table summary="Workshops by time and location."> <caption>Today's workshops</caption> <thead> <tr> <th id="col1">Time</th> <th id="col2"><b class="location">Room A</b></th>  <th id="col3"><b class="location">Room B</b></th> </tr> </thead> <tbody> <tr> <th id="row1"><b class="dtstart">2009-05-20T11:00</b></th> <td id="evt1" headers="row1 col2" class="vevent"> <span class="summary">Bee keeping</span> </td>  <td id="evt2" headers="row1 col3" class="vevent"> <span class="summary">Llama hunting</span> </td> </tr>  <tr> <th id="row2"><b class="dtstart">2009-05-20T12:00</b></th> <td id="evt3" headers="row2 col2" class="vevent"> <span class="summary">Polar bear wrangling</span> </td>  <td id="evt4" headers="row2 col3" class="vevent"> <span class="summary">Mongoose studies</span> </td> </tr> </tbody> </table> It's not a widely known about pattern, and although it saves some duplication, it is still quite a verbose format. Swignition implements parsing support for it across all compound microformats; Brian Suda's x2v scripts implement it for hCalendar and perhaps for hCard; I don't know of other implementations. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1242834908.19079.52.camel%40ophelia2.g5n.co.uk Re: Tracker for actions within the XG 2009-05-20T15:55:09 2009-05-20T15:55:09 2009-05-20T15:55:09 On Wed, 2009-05-20 at 16:36 +0100, Alexandre Passant wrote: > I'm wondering if Tracker could be setup for the XG [1] ? It is! http://www.w3.org/2005/Incubator/socialweb/track/ -- Toby Inkster <tai@g5n.co.uk> On Wed, 2009-05-20 at 16:36 +0100, Alexandre Passant wrote: > I'm wondering if Tracker could be setup for the XG [1] ? It is! http://www.w3.org/2005/Incubator/socialweb/track/ -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/7FEBFB04-D0E8-4E57-93E5-BED762DAA761%40g5n.co.uk Re: Guerilla science: what can we do in 10 days? 2009-05-21T20:46:03 2009-05-21T20:46:03 2009-05-21T20:46:03 On 21 May 2009, at 20:03, joel sachs wrote: > I'm mainly hoping for pointers to biodiversity data in RDF About a month ago I started an experiment in converting the IUCN Red List to RDF. The IUCN's data licensing policies are not entirely clear, and I've not been able to get a good answer from them as to whether this is OK, so until I hear differently, this data and the URLs used shoul... On 21 May 2009, at 20:03, joel sachs wrote: > I'm mainly hoping for pointers to biodiversity data in RDF About a month ago I started an experiment in converting the IUCN Red List to RDF. The IUCN's data licensing policies are not entirely clear, and I've not been able to get a good answer from them as to whether this is OK, so until I hear differently, this data and the URLs used should be considered unstable. (If anyone here has contacts within IUCN who could clarify things, I'd love to hear from them.) Anyway, this URL represents the population of Western Gorillas: http://life.buzzword.org.uk/2009/populations/9404#population The species is: http://life.buzzword.org.uk/2009/populations/9404#taxonomy And their IUCN assessment is: http://life.buzzword.org.uk/2009/populations/9404#assessment -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BB71D72B-1F29-40C7-9DE2-3937B1F8DBA7%40g5n.co.uk Re: How to query for Country Specific Data 2009-05-25T09:35:19 2009-05-25T09:35:19 2009-05-25T09:35:19 On 24 May 2009, at 08:19, richard.hancock@3kbo.com wrote: > Depending on what you are looking for are some datasets better > starting > points than others? E.g. for finding the towns and cities is geonames > (http://sws.geonames.org/) ,CIA Factbook or some other dataset, a > better > starting point? Certainly geonames would be a better place to start for this sort of query. dbpedia is a w... On 24 May 2009, at 08:19, richard.hancock@3kbo.com wrote: > Depending on what you are looking for are some datasets better > starting > points than others? E.g. for finding the towns and cities is geonames > (http://sws.geonames.org/) ,CIA Factbook or some other dataset, a > better > starting point? Certainly geonames would be a better place to start for this sort of query. dbpedia is a wonderful resource for the linked data community, but it can be a bit patchy for certain types of knowledge - not surprising given that its primary source is Wikipedia, which is also patchy in places. (Whatsmore, page formatting of Wikipedia is on an article-by- article basis, which presumably complicates scraping. Templates probably improve matters somewhat.) Geonames probably has less data than dbpedia, and its data is strictly geographical (it won't tell you which famous people were born in a city like dbpedia might). But the data is highly normalised, so you can rely on certain types of data being present. If a city is listed, then it *will* have a name, a country, a longitude and a latitude. Unfortunately, geonames doesn't provide a SPARQL interface. Their database is downloadable though, in tab-delimited format - feature data can be downloaded on a country-by-country basis. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FF33AA11-6633-458E-B53E-27F6A476F343%40g5n.co.uk Re: Guerilla science: what can we do in 10 days? 2009-05-25T21:35:11 2009-05-25T21:35:11 2009-05-25T21:35:11 On 25 May 2009, at 14:37, joel sachs wrote: > 1. Have you considered putting the species name inside the URLs for > the pages? This would simplify human interaction with the data; > would there be a downside? While that seems like a useful idea, I wanted to use the same identifiers as IUCN do. e.g. http://www.iucnredlist.org/details/136309 http://life.buzzword.org.uk/2009/populations/1363... On 25 May 2009, at 14:37, joel sachs wrote: > 1. Have you considered putting the species name inside the URLs for > the pages? This would simplify human interaction with the data; > would there be a downside? While that seems like a useful idea, I wanted to use the same identifiers as IUCN do. e.g. http://www.iucnredlist.org/details/136309 http://life.buzzword.org.uk/2009/populations/136309 This means you can just use their search engine. Also, I have some indices which may be of use: http://life.buzzword.org.uk/2009/indices/taxon/ > 2. I notice that the URI > http://life.buzzword.org.uk/2009/terms/categories#assessment > does not yet exist. Nothing under /2009/terms/ exists yet - I don't intend to put anything there until I've figured out IUCN's licensing policy for this data, as it would be a shame to do all that work and then find I have to take it down. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1243317514.8553.10.camel%40ophelia2.g5n.co.uk Re: XMLLiteral handling in RDFa in HTML 2009-05-26T05:58:35 2009-05-26T05:58:35 2009-05-26T05:58:35 On Mon, 2009-05-25 at 20:55 -0400, Manu Sporny wrote: > So, thoughts on this issue? I don't think that a big song and dance is needed over this. The issue seems pretty simple to me. Sometimes an RDFa parser, dealing with HTML, will hit a situation where it needs to generate an XMLLiteral from non-wellformed HTML. In these situations, it seems to me that we have a choice of three potential "the pa... On Mon, 2009-05-25 at 20:55 -0400, Manu Sporny wrote: > So, thoughts on this issue? I don't think that a big song and dance is needed over this. The issue seems pretty simple to me. Sometimes an RDFa parser, dealing with HTML, will hit a situation where it needs to generate an XMLLiteral from non-wellformed HTML. In these situations, it seems to me that we have a choice of three potential "the parser MUST" actions, all of which are roughly consistent with RDFa in XHTML: 1. The parser MUST ignore this triple altogether. A simple solution, and it means that the HTML graph would be a subset of the XHTML graph. RDF vocabularies are generally defined so that if a graph G is true, then any graph H such that H is a subset of G is also true. 2. The parser MUST add the triple to the graph as normal, but MUST NOT set the literal's datatype to XMLLiteral. They could either leave the literal as an untyped literal (that happened to have a lot of angled brackets in it) or perhaps set it to some HTMLLiteral datatype of our own concoction. 3. The parser MUST coerce the HTML fragment into a well-formed (but not necessarily valid) XHTML fragment. The HTML5 draft gives us decent algorithms for doing this. There are advantages and disadvantages to each of these solutions, but none of them seem especially bad solutions. There are a number of other solutions that can be imagined, but most of them do seem like especially bad solutions. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/C918F09C-FE41-45B5-8386-65391AD3AB77%40g5n.co.uk Re: XMLLiteral handling in RDFa in HTML 2009-05-26T08:50:22 2009-05-26T08:50:22 2009-05-26T08:50:22 On 26 May 2009, at 08:14, Henri Sivonen wrote: > In a reasonable layering, the RDFa processor is layered on top of > an HTML parser, in which case the RDFa parser can't in the general > case tell if the input would have been well-formed if processed as > XML. It seems like a bad idea to define RDFa processing in terms of > the source bytes instead of defining it in terms of the output of ... On 26 May 2009, at 08:14, Henri Sivonen wrote: > In a reasonable layering, the RDFa processor is layered on top of > an HTML parser, in which case the RDFa parser can't in the general > case tell if the input would have been well-formed if processed as > XML. It seems like a bad idea to define RDFa processing in terms of > the source bytes instead of defining it in terms of the output of > the HTML parsing algorithm. Indeed. That is a good argument in favour of solution #3 from my previous message. Most current RDFa parsers do seem to sit on top of a separate (X)(HT) ML parser, just looking at a DOM tree which can be fairly reliably serialised to XML, so this solution probably has the smallest implementation cost for them. The exception is XSLT-based implementations; but, given that XSLT processors can't operate on HTML by definition, this seems to be a moot point. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CF84ADD5-BDD7-4F9E-90B7-ADA246692897%40g5n.co.uk Re: The Minimal Set of Attributes for RDFa 2009-05-31T20:25:35 2009-05-31T20:25:35 2009-05-31T20:25:35 On 29 May 2009, at 03:49, Oshani Seneviratne wrote: > I am trying to figure out an efficient way to determine whether a > given document has valid RDFa in it or not, without having to parse > the entire DOM. ARC2 has an interesting method -- the document is parsed as RDFa if any of the following are true: 1. /html@version contains "XHTML+RDFa". 2. Any tag has an xmlns:* attribute (excluding ... On 29 May 2009, at 03:49, Oshani Seneviratne wrote: > I am trying to figure out an efficient way to determine whether a > given document has valid RDFa in it or not, without having to parse > the entire DOM. ARC2 has an interesting method -- the document is parsed as RDFa if any of the following are true: 1. /html@version contains "XHTML+RDFa". 2. Any tag has an xmlns:* attribute (excluding the XHTML namespace). 3. Any tag contains one of these attributes: about, typeof, property. That said, you should be able to parse any XHTML (and any pre-HTML5 HTML) using the RDFa processing algorithm and get sensible results from it, so determining which documents "are" or "are not" RDFa is not usually necessary, except perhaps as an optimisation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9A04ED81-1CC1-40F4-B3FD-87A8FFD85C3E%40g5n.co.uk MicroTurtle - request for comments 2009-06-02T17:58:18 2009-06-02T17:58:18 2009-06-02T17:58:18 I'd appreciate feedback on this idea I've had: http://buzzword.org.uk/2009/microturtle/spec Example input: http://identi.ca/notice/4819437 Example output: http://buzzword.org.uk/2009/microturtle/implementation.cgi? acct=tobyink&notice=4819437&format=text/n3 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I'd appreciate feedback on this idea I've had: http://buzzword.org.uk/2009/microturtle/spec Example input: http://identi.ca/notice/4819437 Example output: http://buzzword.org.uk/2009/microturtle/implementation.cgi? acct=tobyink&notice=4819437&format=text/n3 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8FE2C50E-620F-4CD2-9269-D20E61226F7E%40g5n.co.uk ACTION [CONTINUES] Document developer stories on wiki. 2009-06-02T18:03:16 2009-06-02T18:03:16 2009-06-02T18:03:16 Added a section to UserStories page: http://www.w3.org/2005/Incubator/socialweb/wiki/ UserStories#Adding_new_features_to_Social_Networks The "Atomic Pattern Deliverable" bit needs filling out a bit more. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Added a section to UserStories page: http://www.w3.org/2005/Incubator/socialweb/wiki/ UserStories#Adding_new_features_to_Social_Networks The "Atomic Pattern Deliverable" bit needs filling out a bit more. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/417F5D4C-F7F2-45E2-8D72-010EECCB2D07%40g5n.co.uk "quote" predicate 2009-06-02T21:42:55 2009-06-02T21:42:55 2009-06-02T21:42:55 Is there a predicate with domain foaf:Document and range xsd:string that has a meaning "this document contains this text"? For example: <http://www.w3.org/> ex:quote "Leading the Web to Its Full Potential..." . Or will I have to define such a term myself? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Is there a predicate with domain foaf:Document and range xsd:string that has a meaning "this document contains this text"? For example: <http://www.w3.org/> ex:quote "Leading the Web to Its Full Potential..." . Or will I have to define such a term myself? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/26B9C7BD-D61A-4E4D-8A6B-DB1FED32ECD1%40tobyinkster.co.uk Re: ANN: sameas.org 2009-06-03T21:40:48 2009-06-03T21:40:48 2009-06-03T21:40:48 On 3 Jun 2009, at 20:48, Hugh Glaser wrote: > The following formats are also supported: > rdf+xml, text/n3, application/json, text/plain Starting on the HTML search result page and clicking though to the "rdf+xml", "n3", etc links, the uri query string parameter isn't %- encoded, so fragment identifiers don't get seen by the scripts which serve up the RDF/XML, N3, etc. Steps to reproduce: ... On 3 Jun 2009, at 20:48, Hugh Glaser wrote: > The following formats are also supported: > rdf+xml, text/n3, application/json, text/plain Starting on the HTML search result page and clicking though to the "rdf+xml", "n3", etc links, the uri query string parameter isn't %- encoded, so fragment identifiers don't get seen by the scripts which serve up the RDF/XML, N3, etc. Steps to reproduce: 1. Search for http://tobyinkster.co.uk/#i 2. Under the first result, click "n3". 3. Note that the resulting N3 file only talks about http:// tobyinkster.co.uk/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1244107089.12193.29.camel%40ophelia2.g5n.co.uk Re: ANN: sameas.org 2009-06-04T09:18:12 2009-06-04T09:18:12 2009-06-04T09:18:12 On Thu, 2009-06-04 at 00:54 +0100, Richard Cyganiak wrote: > The general RDF graph has the shape > <U1> owl:sameAs <U1>, <U2>, <U3>, <U4> . Oh yes, another thing: saying the above, with OWL reasoning in place is equivalent to saying: <U1> owl:sameAs <U1>, <U1>, <U1>, <U1> . in a way. For this reason, you might want to consider adding in support for my URI ontology, in which case you'd serve... On Thu, 2009-06-04 at 00:54 +0100, Richard Cyganiak wrote: > The general RDF graph has the shape > <U1> owl:sameAs <U1>, <U2>, <U3>, <U4> . Oh yes, another thing: saying the above, with OWL reasoning in place is equivalent to saying: <U1> owl:sameAs <U1>, <U1>, <U1>, <U1> . in a way. For this reason, you might want to consider adding in support for my URI ontology, in which case you'd serve something like this: @prefix owl : <http://www.w3.org/2002/07/owl#> . @prefix uri : <http://purl.org/NET/uri#> . <U1> owl:sameAs <U1> , <U2> , <U3> ; uri:identifier [ a uri:UniformResourceIdentifier ; rdf:value "U1" ] , [ a uri:UniformResourceIdentifier ; rdf:value "U2" ] , [ a uri:UniformResourceIdentifier ; rdf:value "U3" ] . You could even use it to indicate the source of your information. e.g. <U1> uri:identifier [ a uri:UniformResourceIdentifier ; rdf:value "U2" ; ex:accordingTo <http://..../> , <http://..../> ; ex:discoveredByUs "2009-04-05" ] . Harry Halpin's IRW ontology may also be of use, but I've not entirely been able to figure out how it works. It's here: <http://www.ontologydesignpatterns.org/ont/web/irw.owl> -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/DF4F88F2-935D-4A9E-89E6-C020129712E8%40g5n.co.uk Re: [foaf-dev] Parsing RDF from namespace documents - anyone reading RDF from inside XHTML? (foaf ns) 2009-06-06T05:53:11 2009-06-06T05:53:11 2009-06-06T05:53:11 On 6 Jun 2009, at 01:07, Danny Ayers wrote: > I would very much like to see the continuation of there being a HTML > version and an RDF/XML version of the spec available through conneg. > Standards and all that. What troubles me a little is that if the HTML > version uses RDFa, it's going to be hard to keep versions in sync, all > complete. Surely with there being two versions already (HTML and... On 6 Jun 2009, at 01:07, Danny Ayers wrote: > I would very much like to see the continuation of there being a HTML > version and an RDF/XML version of the spec available through conneg. > Standards and all that. What troubles me a little is that if the HTML > version uses RDFa, it's going to be hard to keep versions in sync, all > complete. Surely with there being two versions already (HTML and RDF/XML), there is still opportunity for them to become out of sync. I don't see how adding RDFa to the HTML version makes that any worse. The syncing problem is greatly reduced by using a script to generate one version from the other (whichever way around you choose to do it), which is indeed what is done for the FOAF spec. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8DF3C482-6980-4D76-B0F2-A14B26624D71%40g5n.co.uk Re: parsing purl.org/media/video 2009-06-08T08:46:08 2009-06-08T08:46:08 2009-06-08T08:46:08 On 7 Jun 2009, at 21:28, Manu Sporny wrote: > I have been meaning to have a conversation with the PURL team about > how > they do URL re-writing for top-level directories. They're in the process of switching the software they use to power the purl.org service. (Which seems to be taking a ridiculously long time to do.) It'd probably be more productive for you to speak to the people at pu... <html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div><div>On 7 Jun 2009, at 21:28, Manu Sporny wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I have been meaning to have a conversation with the PURL team about how</div> <div>they do URL re-writing for top-level directories.&nbsp;</div> </blockquote></div><div><br></div><div>They're in the process of switching the software they use to power the purl.org service. (Which seems to be taking a ridiculously long time to do.)&nbsp;It'd probably be more productive for you to speak to the people at purlz.org, who are developing the new software, than those at purl.org.</div><div><br></div><div>One of the enhancements that the new software will bring is the ability to select an HTTP response code for PURLs. (Currently they're hard-coded as 302.) Though right now purlz.org's software only allows this for normal redirects, though adding this feature for partial redirects is on the bug tracker too. (For people not familiar with purl.org terminology, a partial redirect is essentially string head matching - i.e. not just "/foo/bar/", but all URLs that *start* "/foo/bar/".)</div><div><br></div><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>--&nbsp;</div><div>Toby A Inkster</div><div>&lt;<a href="mailto:mail@tobyinkster.co.uk">mailto:mail@tobyinkster.co.uk</a>&gt;</div><div>&lt;<a href="http://tobyinkster.co.uk">http://tobyinkster.co.uk</a>&gt;</div><div><br class="webkit-block-placeholder"></div></span><br class="Apple-interchange-newline"> </div><br></body></html> On 7 Jun 2009, at 21:28, Manu Sporny wrote: > I have been meaning to have a conversation with the PURL team about > how > they do URL re-writing for top-level directories. They're in the process of switching the software they use to power the purl.org service. (Which seems to be taking a ridiculously long time to do.) It'd probably be more productive for you to speak to the people at purlz.org, who are developing the new software, than those at purl.org. One of the enhancements that the new software will bring is the ability to select an HTTP response code for PURLs. (Currently they're hard-coded as 302.) Though right now purlz.org's software only allows this for normal redirects, though adding this feature for partial redirects is on the bug tracker too. (For people not familiar with purl.org terminology, a partial redirect is essentially string head matching - i.e. not just "/foo/bar/", but all URLs that *start* "/foo/ bar/".) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://www.w3.org/mid/4A2D25E7.10907@digitalbazaar.com Effective Community Behavior 2009-06-08T14:54:43 2009-06-08T14:54:43 2009-06-08T14:54:43 The list has been quiet for the past week, so this may be a good time to send this out, as it's not directed at anybody or any conversation that we've been having. The PURL/SIMILE websites provide a very good set of general guidelines for communicating via a mailing list/IRC. Both RDFa mailing lists have had a good track record of being kind and courteous places to learn and ask questions. Most ... The list has been quiet for the past week, so this may be a good time to send this out, as it's not directed at anybody or any conversation that we've been having. The PURL/SIMILE websites provide a very good set of general guidelines for communicating via a mailing list/IRC. Both RDFa mailing lists have had a good track record of being kind and courteous places to learn and ask questions. Most conflicts have been handled by community members in a well-mannered, non-combative approach (thank you all for being nice on both mailing lists!). This page is by no means meant to be definitive - but may be helpful for those joining an online community and communicating via a mailing list for the first time: http://rdfa.info/wiki/effective-community-behavior It is linked off of the "Participate" page on the wiki: http://rdfa.info/wiki/participate#Contribute -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Admitting That Javascript was a Mistake http://blog.digitalbazaar.com/2009/05/31/admitting-that-javascript-was-a-mistake/ http://tobyinkster.co.uk/message/5975A417-912F-4B07-BFA2-6FDC75CCD1AD%40g5n.co.uk Re: Linking back to sameas.org? 2009-06-08T19:59:31 2009-06-08T19:59:31 2009-06-08T19:59:31 On 8 Jun 2009, at 12:22, Bernard Vatant wrote: > http://sameas.org/html?uri=http://www.lingvoj.org/lang/fr provides > 16 equivalent URIs (including the original one). > At http://www.lingvoj.org/lang/fr I've gathered painfully only 10 > of those :-) > But now that sameas.org is alive, why should I care maintaining > those sameAs links locally? I imagine that sameas.org found many of those ... On 8 Jun 2009, at 12:22, Bernard Vatant wrote: > http://sameas.org/html?uri=http://www.lingvoj.org/lang/fr provides > 16 equivalent URIs (including the original one). > At http://www.lingvoj.org/lang/fr I've gathered painfully only 10 > of those :-) > But now that sameas.org is alive, why should I care maintaining > those sameAs links locally? I imagine that sameas.org found many of those links at lingvoj.org. > Using rdfs:seeAlso is as usual good but not precise enough. Maybe > sameas.org could provide a minimal vocabulary to describe its URI, > such as some http://sameas.org#hub property > http://www.lingvoj.org/lang/fr sameas:hub http://sameas.org/ > html?uri=http://www.lingvoj.org/lang/fr Perhaps better: <http://www.lingvoj.org/lang/fr> rdfs:seeAlso <http://sameas.org/html?uri=http://www.lingvoj.org/lang/fr> . <http://sameas.org/html?uri=http://www.lingvoj.org/lang/fr> rdf:type sameas:Hub . As this will work in existing tools that understand rdfs:seeAlso. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1244535388.350.4.camel%40ophelia2.g5n.co.uk Re: ANN: sameas.org 2009-06-09T08:16:29 2009-06-09T08:16:29 2009-06-09T08:16:29 On Wed, 2009-06-03 at 20:48 +0100, Hugh Glaser wrote: > We are pleased to offer http://sameas.org/ as a service to provide you > with help finding URIs. I wonder if in <http://example.com/foo> I wrote: <#me> foaf:based_near _:lewes . _:lewes owl:sameAs <http://dbpedia.org/resource/Lewes> . Would sameas.org then be able to produce the following: <http://dbpedia.org/resource/Lewes> ... On Wed, 2009-06-03 at 20:48 +0100, Hugh Glaser wrote: > We are pleased to offer http://sameas.org/ as a service to provide you > with help finding URIs. I wonder if in <http://example.com/foo> I wrote: <#me> foaf:based_near _:lewes . _:lewes owl:sameAs <http://dbpedia.org/resource/Lewes> . Would sameas.org then be able to produce the following: <http://dbpedia.org/resource/Lewes> owl:sameAs [ rdfs:seeAlso <http://example.com/foo> ] . i.e. the resource is the same as some blank node. I'm guessing that the answer is no, but it would be quite cool to be able to cope with blank nodes. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/EFEFFAA0-4C4A-4A3E-B7B5-2823921E0775%40g5n.co.uk Re: What is a social network? 2009-06-09T18:41:58 2009-06-09T18:41:58 2009-06-09T18:41:58 On 9 Jun 2009, at 14:53, Christine Perey wrote: > I suggest that we take a stab at a W3C Social Web XG 'accepted' > definition of scope. A very good discussion topic. Here's my stab at an answer... A social network is any website or collection of websites that: 1. Allows agents (who will generally be people, but could be organisations, etc) to acquire accounts or use accounts they already ... On 9 Jun 2009, at 14:53, Christine Perey wrote: > I suggest that we take a stab at a W3C Social Web XG 'accepted' > definition of scope. A very good discussion topic. Here's my stab at an answer... A social network is any website or collection of websites that: 1. Allows agents (who will generally be people, but could be organisations, etc) to acquire accounts or use accounts they already have (e.g. OpenID, FOAF+SSL); 2. Allows them to express information about themselves in a profile which is accessible to at least some other members of the social network; 3. Sources at least some of its content from its users. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1244628824.350.36.camel%40ophelia2.g5n.co.uk RE: Purpose of List [was Re: ACTION: Top Social Networking services] 2009-06-10T10:13:44 2009-06-10T10:13:44 2009-06-10T10:13:44 On Wed, 2009-06-10 at 11:07 +0200, Christine Perey wrote: > 1. What new insights will the fact that a service has (or has not) > implemented A1 or A2 provide? I'm not Harry, but allow me to provide my answer to this question. A service that provides FOAF, OpenID, etc scores points in terms of interoperability/distributed architecture. In terms of open source software, it's not a question of wh... On Wed, 2009-06-10 at 11:07 +0200, Christine Perey wrote: > 1. What new insights will the fact that a service has (or has not) > implemented A1 or A2 provide? I'm not Harry, but allow me to provide my answer to this question. A service that provides FOAF, OpenID, etc scores points in terms of interoperability/distributed architecture. In terms of open source software, it's not a question of whether the site is hosted on Apache or whatever, but what's important rather is the free availability of the actual site code. For example, identi.ca is powered by the GPLed laconi.ca software. That means that if I decided I no longer liked identi.ca's privacy policies, I could set up my own server running the same software and hopefully transfer my microblog over to my own server. Big win for interop and data portability. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/A92360CD-86F6-4129-B893-BFEC00497D1A%40g5n.co.uk Re: Mixing @id and @about on the same element 2009-06-11T22:04:51 2009-06-11T22:04:51 2009-06-11T22:04:51 On 11 Jun 2009, at 14:50, Manu Sporny wrote: > We need to determine if creating markup like this is an acceptable > practice: > <p id="foo" about="#foo">Some text</p> Just today I included the following in a document: <div about="#project" typeof="doap:Project"> ... <div rel=":help"> <div id="help" about="#help"> <h3 property="dc:title">Help</h3> ... </div> <... On 11 Jun 2009, at 14:50, Manu Sporny wrote: > We need to determine if creating markup like this is an acceptable > practice: > <p id="foo" about="#foo">Some text</p> Just today I included the following in a document: <div about="#project" typeof="doap:Project"> ... <div rel=":help"> <div id="help" about="#help"> <h3 property="dc:title">Help</h3> ... </div> </div> </div> Which generates these three triples: <#project> a doap:Project ; xhv:help <#help> . <#help> dc:title "Help" . All of which seems logical to me. The issue included in the TF minutes is not really including @id and @about on the same element - there's nothing wrong with that, but rather trying to use the same fragment identifier (hence the same URI) to refer to two separate things. (In the SKOS case, they use the same URI to identify both a document fragment and an rdf:Property.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1244796253.7422.12.camel%40ophelia2.g5n.co.uk Re: Common Tag - semantic tagging convention 2009-06-12T08:44:14 2009-06-12T08:44:14 2009-06-12T08:44:14 On Fri, 2009-06-12 at 01:33 +0200, Andraz Tori wrote: > also to note is that there exist proper mappings to other efforts at > tagging ontologies: > http://commontag.org/mappings The question is though, will Search Monkey, Sindice, et al make use of these mappings, and offer support for other tagging vocabs? Another, unrelated, point: it's probably a bad idea for the specification to recommend u... On Fri, 2009-06-12 at 01:33 +0200, Andraz Tori wrote: > also to note is that there exist proper mappings to other efforts at > tagging ontologies: > http://commontag.org/mappings The question is though, will Search Monkey, Sindice, et al make use of these mappings, and offer support for other tagging vocabs? Another, unrelated, point: it's probably a bad idea for the specification to recommend using the "/>" syntax with the <span> element. Yes, it's syntactically legal, but it breaks XHTML 1.0 Appendix C guidelines, and will cause headaches for authors who aren't sending their pages as application/xhtml+xml. Oh, one more... it would be nice if the spec had an example of using ctag:label and ctag:taggingDate on the same tag. Sure *I* know how, but I'm pretty sure that most of the people the spec is targeted at will get the answer seriously wrong if they had to guess using the existing examples as a guideline. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1244803651.29842.14.camel%40ophelia2.g5n.co.uk Re: Common Tag - semantic tagging convention 2009-06-12T10:47:32 2009-06-12T10:47:32 2009-06-12T10:47:32 On Fri, 2009-06-12 at 12:15 +0200, Peter Mika wrote: > Indeed, you cannot do this merging: a ctag:Tag refers to the tagging > event. So the concepts they refer to (ctag:means) might be the same, the > Tags are not. Then http://commontag.org/mapping is wrong. It states: ctag:Tag rdfs:subClassOf tag:Tag . ctag:tagged rdfs:subClassOf tag:taggedWithTag . Whereas if ctag:Tag represents the taggi... On Fri, 2009-06-12 at 12:15 +0200, Peter Mika wrote: > Indeed, you cannot do this merging: a ctag:Tag refers to the tagging > event. So the concepts they refer to (ctag:means) might be the same, the > Tags are not. Then http://commontag.org/mapping is wrong. It states: ctag:Tag rdfs:subClassOf tag:Tag . ctag:tagged rdfs:subClassOf tag:taggedWithTag . Whereas if ctag:Tag represents the tagging event, it should state: ctag:Tag rdfs:subClassOf tag:Tagging . ctag:tagged rdfs:subClassOf tag:tag . That also has implications for ctag's mappings to MOAT, SCOT, SKOS and SIOC though. And it invalidates the ctag:means mapping to MOAT. In essence it seems ctag:Tag is a sort of hybrid between tag:Tagging and tag:Tag. There's nothing wrong with that per se, but it does mean that your mappings to Richard Newman's tag ontology are probably never going to work especially well. And this includes MOAT and SCOT which are built on Richard's ontology. (And SIOC and SKOS use ideas which are fairly compatible with Richard's ontology too - indeed, tag:Tag is a subclass of skos:Concept.) -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1244805413.29842.26.camel%40ophelia2.g5n.co.uk Re: Common Tag - semantic tagging convention 2009-06-12T11:16:53 2009-06-12T11:16:53 2009-06-12T11:16:53 On Fri, 2009-06-12 at 11:47 +0100, Toby Inkster wrote: > In essence it seems ctag:Tag is a sort of hybrid between tag:Tagging > and tag:Tag. There's nothing wrong with that per se, but it does mean > that your mappings to Richard Newman's tag ontology are probably never > going to work especially well. Lest I be accused of nonconstructive criticism, a route to improving the vocab would be to prop... On Fri, 2009-06-12 at 11:47 +0100, Toby Inkster wrote: > In essence it seems ctag:Tag is a sort of hybrid between tag:Tagging > and tag:Tag. There's nothing wrong with that per se, but it does mean > that your mappings to Richard Newman's tag ontology are probably never > going to work especially well. Lest I be accused of nonconstructive criticism, a route to improving the vocab would be to properly align CommonTag with existing ontologies by dropping ctag:taggedDate altogether. Of all the terms defined by CommonTag, ctag:taggedDate is probably the one with least value to most publishers, so this change would not only help align CommonTag with other ontologies, but also serve to simplify and streamline the spec. The description of tagging *events* could then be considered an "advanced" use case, not directly supported by CommonTag. But given that CommonTag would then be compatible with Richard Newman's ontology, and MOAT, SCOT, etc, advanced users could go outside CommonTag to add this extra meaning to their tags. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1244819111.29842.28.camel%40ophelia2.g5n.co.uk Re: Common Tag - semantic tagging convention 2009-06-12T15:05:13 2009-06-12T15:05:13 2009-06-12T15:05:13 On Fri, 2009-06-12 at 10:31 -0400, Valeska Oleary wrote: > It’s hard to comment without understanding the use cases and > scenarios, but high level speaking I’m inclined to think date is a > valuable piece of information to most publishers. I imagine the date of publication of an article, plus dates of modification and other document lifecycle dates are valuable to most publishers. The date an article has had a particular tag added though is probably of secondary importance. -- Toby Inkster <tai@g5n.co.uk> On Fri, 2009-06-12 at 10:31 -0400, Valeska Oleary wrote: > It’s hard to comment without understanding the use cases and > scenarios, but high level speaking I’m inclined to think date is a > valuable piece of information to most publishers. I imagine the date of publication of an article, plus dates of modification and other document lifecycle dates are valuable to most publishers. The date an article has had a particular tag added though is probably of secondary importance. -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/092CB2A1-7879-414D-A9AA-E8C7F883FC89%40g5n.co.uk Re: gimmee some data! 2009-06-14T23:18:34 2009-06-14T23:18:34 2009-06-14T23:18:34 On 14 Jun 2009, at 10:23, Danny Ayers wrote: > It's Ian Davis' birthday tomorrow, and for it he wants some linked > data. Happy Birthday Ian! ISO 3166-1 and -2 codes, e.g.: Warwickshire http://ontologi.es/place/GB-WAR I still need to add some 303 redirects in there. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 14 Jun 2009, at 10:23, Danny Ayers wrote: > It's Ian Davis' birthday tomorrow, and for it he wants some linked > data. Happy Birthday Ian! ISO 3166-1 and -2 codes, e.g.: Warwickshire http://ontologi.es/place/GB-WAR I still need to add some 303 redirects in there. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245057270.21773.4.camel%40ophelia2.g5n.co.uk Re: gimmee some data! 2009-06-15T09:14:30 2009-06-15T09:14:30 2009-06-15T09:14:30 On Mon, 2009-06-15 at 01:03 +0100, Hugh Glaser wrote: > On 15/06/2009 00:18, "Toby A Inkster" <tai@g5n.co.uk> wrote: > > > I still need to add some 303 redirects in there. > > Better hurry up, people might find it... > http://sameas.org/html?uri=http://ontologi.es/place/GB-WAR It was late, so I was cutting corners, but it's tidied up now, plus an index with voiD description has been added at http://ontologi.es/place/ Aside: <http://unlocode.rkbexplorer.com/id/GBAFT> should have label "Alfriston" (with an "l") - perhaps an error in the source data? -Toby On Mon, 2009-06-15 at 01:03 +0100, Hugh Glaser wrote: > On 15/06/2009 00:18, "Toby A Inkster" <tai@g5n.co.uk> wrote: > > > I still need to add some 303 redirects in there. > > Better hurry up, people might find it... > http://sameas.org/html?uri=http://ontologi.es/place/GB-WAR It was late, so I was cutting corners, but it's tidied up now, plus an index with voiD description has been added at http://ontologi.es/place/ Aside: <http://unlocode.rkbexplorer.com/id/GBAFT> should have label "Alfriston" (with an "l") - perhaps an error in the source data? -Toby http://tobyinkster.co.uk/message/1245059030.21773.7.camel%40ophelia2.g5n.co.uk Re: gimmee some data! 2009-06-15T09:43:51 2009-06-15T09:43:51 2009-06-15T09:43:51 On Mon, 2009-06-15 at 10:38 +0100, Ian Davis wrote: > I noticed a slight encoding error on http://ontologi.es/place/ > I think you have unescaped ampersands in there. Thanks, fixed. Had remembered to escape '<', '>' and '"' (which are never going to appear in place names really) but not ampersand! -Toby On Mon, 2009-06-15 at 10:38 +0100, Ian Davis wrote: > I noticed a slight encoding error on http://ontologi.es/place/ > I think you have unescaped ampersands in there. Thanks, fixed. Had remembered to escape '<', '>' and '"' (which are never going to appear in place names really) but not ampersand! -Toby http://tobyinkster.co.uk/message/1245140674.28450.7.camel%40ophelia2.g5n.co.uk Re: gimmee some data! 2009-06-16T08:24:35 2009-06-16T08:24:35 2009-06-16T08:24:35 On Mon, 2009-06-15 at 22:44 -0400, Ross Singer wrote: > http://dilettantes.code4lib.org/LODThing/isbns/088103696X Interesting. A while back I set up this service, which is essentially a wrapper around Amazon's API: http://purl.org/NET/book/isbn/088103696X#book We should probably sort some kind of cross-links out. owl:sameAs assuming that the ontologies we're using are compatible enough; ov:similarTo otherwise. PS: your "related manifestations" links are broken (need "/LODThing" prepended to href attributes). -- Toby Inkster <tai@g5n.co.uk> On Mon, 2009-06-15 at 22:44 -0400, Ross Singer wrote: > http://dilettantes.code4lib.org/LODThing/isbns/088103696X Interesting. A while back I set up this service, which is essentially a wrapper around Amazon's API: http://purl.org/NET/book/isbn/088103696X#book We should probably sort some kind of cross-links out. owl:sameAs assuming that the ontologies we're using are compatible enough; ov:similarTo otherwise. PS: your "related manifestations" links are broken (need "/LODThing" prepended to href attributes). -- Toby Inkster <tai@g5n.co.uk> http://tobyinkster.co.uk/message/1245153286.2667.16.camel%40ophelia2.g5n.co.uk Re: gimmee some data! 2009-06-16T11:54:48 2009-06-16T11:54:48 2009-06-16T11:54:48 On Tue, 2009-06-16 at 07:30 -0400, Ross Singer wrote: > On Tue, Jun 16, 2009 at 4:24 AM, Toby Inkster<tai@g5n.co.uk> wrote: > Definitely. Since it's not an absolute that the coverage of ISBNs are > 1:1 (in either direction, but definitely from yours to here) -- how to > determine what actually exists? In my opinion, that's a non-issue. A 404 does not mean that the book does not exist, just that ... On Tue, 2009-06-16 at 07:30 -0400, Ross Singer wrote: > On Tue, Jun 16, 2009 at 4:24 AM, Toby Inkster<tai@g5n.co.uk> wrote: > Definitely. Since it's not an absolute that the coverage of ISBNs are > 1:1 (in either direction, but definitely from yours to here) -- how to > determine what actually exists? In my opinion, that's a non-issue. A 404 does not mean that the book does not exist, just that the web server has no information about it. So the meaning of, say: http://dilettantes.code4lib.org/LODThing/isbns/0062515862 is well-defined, even if no data is returned, and I can safely say that http://purl.org/NET/book/isbn/0062515862#book is owl:sameAs it. (Though in fact, there should never be a book with that ISBN as the checksum doesn't work out.) However it would help if you used different URIs for the bibo:Book instances and the RDFa documents which describe them. q.v. httpRange-14. That way, you could distinguish between the pages and the book they describe - e.g. to say that the book exists but the page does not. It would also allow some basic statements like <http://dilettantes.code4lib.org/LODThing/isbns/0062515861> foaf:maker [ foaf:name "Ross Singer" ] . <http://dilettantes.code4lib.org/LODThing/isbns/0062515861#book> foaf:maker [ foaf:name "Tim Berners-Lee" ] . > It seems to me if we're talking about the same ISBN, owl:sameAs is > accurate, but I don't have strong enough opinions to back that up in > an argument. We are both using FRBR - you directly, and me via a subclass - and thought we might be doing our modelling at different levels in FRBR's hierarchy. But it seems we're both treating an ISBN as representing an frbr:Manifestation, so it should be safe to do. I'll add the owl:sameAs stuff on my side at lunch time. -Toby http://tobyinkster.co.uk/message/F0C43CD2-FC60-4DE6-BA0F-1B77195CCEF3%40g5n.co.uk Re: gimmee some data! 2009-06-16T22:33:15 2009-06-16T22:33:15 2009-06-16T22:33:15 On 16 Jun 2009, at 12:54, Toby Inkster wrote: > I'll add the owl:sameAs stuff on my side at lunch time. I've added some owl:sameAs links to DBpedia as well now: e.g. <http://purl.org/NET/book/isbn/9780061474095#book> My mapping between ISBN numbers and DBpedia resources is here: <http://ontologi.es/book/dbpedia-data/isbn.ttl> It's generated from the DBpedia Ontology ABox data, with ISBNs ... On 16 Jun 2009, at 12:54, Toby Inkster wrote: > I'll add the owl:sameAs stuff on my side at lunch time. I've added some owl:sameAs links to DBpedia as well now: e.g. <http://purl.org/NET/book/isbn/9780061474095#book> My mapping between ISBN numbers and DBpedia resources is here: <http://ontologi.es/book/dbpedia-data/isbn.ttl> It's generated from the DBpedia Ontology ABox data, with ISBNs cleaned up and canonicalised. You may notice that each triple in the mapping file is exactly 128 characters (as is the prologue of the file) and triples are sorted by ISBN in alphabetical order. This allows it to be searched very quickly using a binary search algorithm - a little geeky perhaps, but I didn't want to slow my ISBN lookup script down by having to grep through the entire file (or even parse the entire file as Turtle) for each script execution. It also looks pretty. Ian and Hugh may be interested in using isbn.ttl to map between books on DBpedia and ISBN-based URIs for sameas.org. <> rdfs:seeAlso <http://esw.w3.org/topic/BookVocabularies> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245229802.2667.48.camel%40ophelia2.g5n.co.uk Re: gimmee some data! 2009-06-17T09:10:03 2009-06-17T09:10:03 2009-06-17T09:10:03 On Tue, 2009-06-16 at 22:31 -0400, Ross Singer wrote: > http://dilettantes.code4lib.org/LODThing/isbns/0002157926#book You probably want to remove the "resource" RDFa attribute from the Wikipedia references. That's because: <http://dilettantes.code4lib.org/LODThing/isbns/0002157926#book> dcterms:isReferencedBy <http://dbpedia.org/resource/Maggie_Siggins> . doesn't seem right. That book i... On Tue, 2009-06-16 at 22:31 -0400, Ross Singer wrote: > http://dilettantes.code4lib.org/LODThing/isbns/0002157926#book You probably want to remove the "resource" RDFa attribute from the Wikipedia references. That's because: <http://dilettantes.code4lib.org/LODThing/isbns/0002157926#book> dcterms:isReferencedBy <http://dbpedia.org/resource/Maggie_Siggins> . doesn't seem right. That book is not referenced by the person Maggie Siggins, but rather it's referenced by a Wikipedia article. You want the triple to be: <http://dilettantes.code4lib.org/LODThing/isbns/0002157926#book> dcterms:isReferencedBy <http://en.wikipedia.org/wiki/Maggie_Siggins> . (Same deal with the RDF/XML.) Looking forward to seeing the book covers. I wonder what other sources of book data we can link in? -Toby http://tobyinkster.co.uk/message/1245240773.2667.83.camel%40ophelia2.g5n.co.uk Re: gimmee some data! 2009-06-17T12:12:54 2009-06-17T12:12:54 2009-06-17T12:12:54 On Wed, 2009-06-17 at 07:26 -0400, Ross Singer wrote: > The way to access the cover images is: > While http://covers.librarything.com/devkey/{devkey}/medium/isbn/0760759715 > (or some variant of {devkey}) is a URI, I can't help but think that > people would be a little underwhelmed to find that in a foaf:Image > along with disclaimers, licenses and instructions of use. > > Dunno, any advice? A large number of sites seem to use Amazon.com's images, and indeed, I use those too (e.g. <http://purl.org/NET/book/isbn/9781575863269>). Though they are not "open data" in any sense. -Toby On Wed, 2009-06-17 at 07:26 -0400, Ross Singer wrote: > The way to access the cover images is: > While http://covers.librarything.com/devkey/{devkey}/medium/isbn/0760759715 > (or some variant of {devkey}) is a URI, I can't help but think that > people would be a little underwhelmed to find that in a foaf:Image > along with disclaimers, licenses and instructions of use. > > Dunno, any advice? A large number of sites seem to use Amazon.com's images, and indeed, I use those too (e.g. <http://purl.org/NET/book/isbn/9781575863269>). Though they are not "open data" in any sense. -Toby http://tobyinkster.co.uk/message/0148E992-9D1F-4D4A-BF20-0E77610B7BBE%40g5n.co.uk URIs for great circle arcs 2009-06-21T09:45:46 2009-06-21T09:45:46 2009-06-21T09:45:46 Great circle arcs are the shortest surface paths between two points on a spherical body. I've minted some URIs (and am serving up RDF/ XML) for great circle arcs on the surface of the Earth. Amongst other things, the RDF/XML returned will tell you the distance between the points, the compass bearing and the midpoint. For example, the arc between London and Tokyo is represented as: <http:/... Great circle arcs are the shortest surface paths between two points on a spherical body. I've minted some URIs (and am serving up RDF/ XML) for great circle arcs on the surface of the Earth. Amongst other things, the RDF/XML returned will tell you the distance between the points, the compass bearing and the midpoint. For example, the arc between London and Tokyo is represented as: <http://ontologi.es/place/arc/51.507778;-0.128056/35.683333;139.766667> which is a geo:SpatialThing. There is also: <http://ontologi.es/place/arc/ 51.507778;-0.128056/35.683333;139.766667#points> which is an rdfs:Container representing the (infinite) set of all points between the two endpoints of the line. An additional feature is the ability to link to URIs representing the endpoints. e.g.: <http://ontologi.es/place/arc/ 51.507778;-0.128056/35.683333;139.766667?uri1=http://dbpedia.org/ resource/London&uri2=http://dbpedia.org/resource/Tokyo> The document you get returned still has a primaryTopic of <http://ontologi.es/place/arc/51.507778;-0.128056/35.683333;139.766667> (i.e. it doesn't alter the linked data URI) but now contains explicit dbpedia references for the end points. Those URIs don't have to be from dbpedia - they could be anything - they're not used in calculations of distances, etc - just included in the output. Possible uses: flight and travel linked data. Any ideas for improvements? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FBCAE6A1-287F-4FE2-842E-4AB4154B335A%40g5n.co.uk Re: URIs for great circle arcs 2009-06-22T16:03:16 2009-06-22T16:03:16 2009-06-22T16:03:16 On 22 Jun 2009, at 08:52, Peter Coetzee wrote: > First off - the whole "infinite set of points" Container is a tough > one to swallow, without nasty URI-hacking to suggest a resolution > for how many points you want to see, etc. Essentially I was debating two ways of representing an arc: 1. A subclass of geo:SpatialThing - a single discrete "place" which is very long but infinitely thin; ... On 22 Jun 2009, at 08:52, Peter Coetzee wrote: > First off - the whole "infinite set of points" Container is a tough > one to swallow, without nasty URI-hacking to suggest a resolution > for how many points you want to see, etc. Essentially I was debating two ways of representing an arc: 1. A subclass of geo:SpatialThing - a single discrete "place" which is very long but infinitely thin; or 2. A subclass of rdfs:Container - essentially an infinitely big collection of infinitely small points. Both are useful ways of thinking of an arc with advantages and disadvantages. In the end I decided to define, and a one-to-one mapping between then (the arc:points property). I've since come up with a third way I could have done it: 3. A subclass of rdfs:Class - such that all geo:Point resources along the arc have the arc as an rdf:type. Though this third way offers no way of conferring directionality onto the arc. Directionality is important. If the arc from A to B is the owl:sameAs the arc from B to A, then you can't give a definitive answer to the question of what bearing it has. > I wonder if there's a neat Linked-Data way of doing this, to make > it browseable. For example, how about describing those points in > terms of the arcs that connect them (caveat: I know little-to- > nothing about geodesic arcs!) So, what I'm imagining is that you > can describe the arc from A to B via C in terms of the arc from A > to C and the arc from C to B, recursively. In this way you can > build up a greater resolution of points on the arc without having > to URI-hack your way to the solution. Would this even work in this > domain? I've added this. The arc vocab now has a property "part" connecting two directed lines and defined so that any point on the object line must lie on the subject line. The data served up now includes "part" links from the requested arc to two smaller arcs, joining the ends of the requested arc to its midpoint. > More generally, I'm intrigued by the notion of the slight mix of > services you're offering here. On the one hand is a really-quite- > cool "linked data great circle arc" service. On the other, there's > the ability for the user of the service to essentially perform a > mesh-up (or is this a mash-up? I get confused ;)) of this data with > any other service. Are these safe to mix? Is it desirable to let > the user "puppet" my mouth to say anything they wish? I'm using "geo:" URIs to describe points because they're very easy to construct, for any point on the earth's surface, at any desired precision. (In fact, geo allows for altitude to be provided, but that significantly complicates the mathematics, so I don't use this feature.) Sadly, they're not easily dereferencable, so I thought it would be useful to provide a way for people to paste in their own more linked-dataish URIs. Yes, this results in possible trust issues. In the RDF/XML document I assert that I am the document's foaf:maker. Fools who decide to trust my data blindly could be lulled into believing that Tokyo's in the middle of the Surrey countryside, a mere 20 miles or so from London. Perhaps I should list myself as the mere dc:publisher of the information, but (even when people paste in their own URLs), I do consider myself the primary creator of the information. What I really want to indicate though is whether or not I believe the information that I am, myself, providing. <> foaf:maker ?x ; ex:isBelievedBy ?x . versus: <> foaf:maker ?x . We really need a good vocabulary for describing the trust agents have for documents, and trust levels between agents themselves. I've talked about that in #swig before, and have suggested it as a possible VoCamp Bristol 2009 project. There is some good work at <http://trust.mindswap.org/trustOnt.shtml> and <http://daml.umbc.edu/ontologies/webofbelief/1.4/wob.owl> but I don't think either of them is quite right. The former seems to confuse trust and agreement too much, and only talks about trust between agents, whereas the latter is overcomplicated, and only talks about agents trusting RDF graphs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245757828.15599.21.camel%40ophelia2.g5n.co.uk Re: Common Tag - semantic tagging convention 2009-06-23T11:50:28 2009-06-23T11:50:28 2009-06-23T11:50:28 On Tue, 2009-06-23 at 12:37 +0100, Pierre-Antoine Champin wrote: > So the design of Common Tag implies that Tag resources should not be > "reused" across different tagging actions, which IMHO makes them quite > different from Newman's Tags (and close to Tagging, in fact). I reached a similar conclusion. As the commontag mailing list doesn't have public archives yet, here's a quote from a recent ... On Tue, 2009-06-23 at 12:37 +0100, Pierre-Antoine Champin wrote: > So the design of Common Tag implies that Tag resources should not be > "reused" across different tagging actions, which IMHO makes them quite > different from Newman's Tags (and close to Tagging, in fact). I reached a similar conclusion. As the commontag mailing list doesn't have public archives yet, here's a quote from a recent message I posted there: > On Thu, 2009-06-18 at 08:43 -0700, Alexandre Passant wrote: > > > A Tag in common tag is a tag a seen in Newman's ontology. > > Technically that's true, but in practise I think the two concepts of a > Tag will probably be used quite differently. > > Assuming you give a Tag a URI, then in Richard Newman's ontology (and > SKOS from which his inherits), the Tag is reusable. It's possible to > say that: > > <http://example.com/docs/1> > tags:taggedWithTag > <http://example.com/tags/u2#concept> . > > <http://example.com/docs/2> > tags:taggedWithTag > <http://example.com/tags/u2#concept> . > > But with Common Tag you can't do that without implying that the tag > dates are the same, and (if you use subclasses of ctag:Tag) the > tagging method (author, reader, robot) was the same. > > A ctag:Tag is essentially a blend between a tags:Tag and a > tags:Tagging. There's nothing wrong with that per se, but it may make > mapping between the two schemas more challenging. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245758720.15599.32.camel%40ophelia2.g5n.co.uk Re: RDFa vs RDF/XML and content negotiation 2009-06-23T12:05:20 2009-06-23T12:05:20 2009-06-23T12:05:20 On Tue, 2009-06-23 at 13:09 +0200, bill.roberts@planet.nl wrote: > For any non-trivial amount of data, then we will need a templating > engine of some sort for either approach. For my railway data <http://ontologi.es/rail/> I publish static XHTML +RDFa files (all but two of which are generated by script) and use a combination of Apache .htaccess files and small PHP scripts to dynamically generate... On Tue, 2009-06-23 at 13:09 +0200, bill.roberts@planet.nl wrote: > For any non-trivial amount of data, then we will need a templating > engine of some sort for either approach. For my railway data <http://ontologi.es/rail/> I publish static XHTML +RDFa files (all but two of which are generated by script) and use a combination of Apache .htaccess files and small PHP scripts to dynamically generate other formats (JSON, RDF/XML, N-Triples, Turtle) on request. e.g.: http://ontologi.es/rail/stations/gb/VIC (conneg'd 303 redirect) http://ontologi.es/rail/stations/gb/VIC.xhtml (static XHTML) http://ontologi.es/rail/stations/gb/VIC.ttl (dynamic Turtle) http://ontologi.es/rail/stations/gb/VIC.json?callback=foo (JS) This approach seems to have worked pretty well for a reasonably large data set (nearly 7000 XHTML+RDFa pages) and I'd certainly consider using it again. I'll try to clean up the scripts, etc involved and share them for others who wish to use this technique. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245758983.15599.33.camel%40ophelia2.g5n.co.uk Re: RDFa vs RDF/XML and content negotiation 2009-06-23T12:09:44 2009-06-23T12:09:44 2009-06-23T12:09:44 On Tue, 2009-06-23 at 13:09 +0200, bill.roberts@planet.nl wrote: > For any non-trivial amount of data, then we will need a templating > engine of some sort for either approach. For my railway data <http://ontologi.es/rail/> I publish static XHTML +RDFa files (all but two of which are generated by script) and use a combination of Apache .htaccess files and small PHP scripts to dynamically generat... On Tue, 2009-06-23 at 13:09 +0200, bill.roberts@planet.nl wrote: > For any non-trivial amount of data, then we will need a templating > engine of some sort for either approach. For my railway data <http://ontologi.es/rail/> I publish static XHTML +RDFa files (all but two of which are generated by script) and use a combination of Apache .htaccess files and small PHP scripts to dynamically generate other formats (JSON, RDF/XML, N-Triples, Turtle) on request. e.g.: http://ontologi.es/rail/stations/gb/VIC (conneg'd 303 redirect) http://ontologi.es/rail/stations/gb/VIC.xhtml (static XHTML) http://ontologi.es/rail/stations/gb/VIC.ttl (dynamic Turtle) http://ontologi.es/rail/stations/gb/VIC.json?callback=foo (JS) This approach seems to have worked pretty well for a reasonably large data set (nearly 7000 XHTML+RDFa pages) and I'd certainly consider using it again. I'll try to clean up the scripts, etc involved and share them for others who wish to use this technique. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245760223.15599.39.camel%40ophelia2.g5n.co.uk Re: RDFa vs RDF/XML and content negotiation 2009-06-23T12:30:23 2009-06-23T12:30:23 2009-06-23T12:30:23 On Tue, 2009-06-23 at 13:09 +0100, Toby Inkster wrote: > For my railway data <http://ontologi.es/rail/> I publish static XHTML > +RDFa files (all but two of which are generated by script) and use a > combination of Apache .htaccess files and small PHP scripts to > dynamically generate other formats (JSON, RDF/XML, N-Triples, Turtle) > on request. Just to clarify, when I say "dynamically generate"... On Tue, 2009-06-23 at 13:09 +0100, Toby Inkster wrote: > For my railway data <http://ontologi.es/rail/> I publish static XHTML > +RDFa files (all but two of which are generated by script) and use a > combination of Apache .htaccess files and small PHP scripts to > dynamically generate other formats (JSON, RDF/XML, N-Triples, Turtle) > on request. Just to clarify, when I say "dynamically generate" I mean by parsing the XHTML+RDFa off disk and into memory and then dumping it out in the requested format. So essentially, I'm just publishing XHTML+RDFa and leaving the web server to generate other formats from it when needed. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245845190.21999.2.camel%40ophelia2.g5n.co.uk regrets & interesting link 2009-06-24T12:06:31 2009-06-24T12:06:31 2009-06-24T12:06:31 Not able to make today's call, but here's an interesting article from the New Scientist about analysis of e-mail data (not the contents, just time period and sender and recipient identities) to predict major events: http://www.newscientist.com/article/mg20227135.900-email-patterns-can-predict-impending-doom.html I wonder if/how this could be applies to social networks? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Not able to make today's call, but here's an interesting article from the New Scientist about analysis of e-mail data (not the contents, just time period and sender and recipient identities) to predict major events: http://www.newscientist.com/article/mg20227135.900-email-patterns-can-predict-impending-doom.html I wonder if/how this could be applies to social networks? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1245930802.10113.10.camel%40ophelia2.g5n.co.uk Re: Visualization of domain and range 2009-06-25T11:53:22 2009-06-25T11:53:22 2009-06-25T11:53:22 On Thu, 2009-06-25 at 13:49 +0200, Bernhard Schandl wrote: > > Something like this might be a nice visualisation: > > > > http://buzzword.org.uk/2009/domain-range-illustration.png > > It would be even better to flip it so that the ontology level is on > top of the instance level, so to be in line with MOF. You're right, it's much clearer this way: http://buzzword.org.uk/2009/domain-range-illustration-flipped.png ;-) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2009-06-25 at 13:49 +0200, Bernhard Schandl wrote: > > Something like this might be a nice visualisation: > > > > http://buzzword.org.uk/2009/domain-range-illustration.png > > It would be even better to flip it so that the ontology level is on > top of the instance level, so to be in line with MOF. You're right, it's much clearer this way: http://buzzword.org.uk/2009/domain-range-illustration-flipped.png ;-) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/473F27EC-B63D-46BB-A8B4-E9789ED930D8%40g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-06-26T08:03:10 2009-06-26T08:03:10 2009-06-26T08:03:10 On 25 Jun 2009, at 21:18, Pat Hayes wrote: > If [RDF] requires people to tinker with files with names starting > with a dot [...] then the entire SWeb architecture is fundamentally > broken. RDF doesn't. Apache does. Many hosts do have front ends for configuring Apache, allowing redirects to be set up and content-types configured by filling in simple web forms. But there are such a vari... On 25 Jun 2009, at 21:18, Pat Hayes wrote: > If [RDF] requires people to tinker with files with names starting > with a dot [...] then the entire SWeb architecture is fundamentally > broken. RDF doesn't. Apache does. Many hosts do have front ends for configuring Apache, allowing redirects to be set up and content-types configured by filling in simple web forms. But there are such a variety of these tools with different capabilities and different interfaces that it would be difficult to produce advice suitable for them all, so instead ".htaccess" recipes are provided instead. That said, there are a couple of steps that Martin could remove from his recipe and still be promoting reasonably good practice: Step 5a - this rewrites <http://example.org/semanticweb> to <http:// example.org/semanticweb.rdf>. Other than aesthetics, there's no real reason to do this. Yes, I've read timbl's old Cool URIs document, and understand about not wanting to include hints of file format in a URI. But realistically, this file is going to always include some RDF - perhaps in a non-RDF/XML serialisation, but I don't see anything inappropriate about serving other RDF serialisations using a ".rdf" URL, provided the correct MIME type is used. Step 5b - the default Apache mime.types file knows about application/ rdf+xml, so this should be unnecessary. Perhaps instead have a GoodRelations "validator" which checks that the content type is correct, and only suggests this when it is found to be otherwise. Steps 3 and 4 could be amalgamated into a single "validate your RDF file" step using the aforementioned validator. The validator would be written so that, upon a successful validation, it offers single-click options to ping semweb search engines, and Yahoo (via a RDF/XML- >DataRSS converter). With those adjustments, the recipe would just be: 1. Upload your RDF file. 2. Add a rel="meta" link to it. 3. Validate using our helpful tool. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1246006276.20411.14.camel%40ophelia2.g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-06-26T08:51:17 2009-06-26T08:51:17 2009-06-26T08:51:17 On Fri, 2009-06-26 at 09:35 +0200, Dan Brickley wrote: > Does every major RDF toolkit have an integrated RDFa parser already? No - and even for those that do, it's often rather flaky. Seseme/Rio doesn't have one in its stable release, though I believe one is in development for 3.0. Redland/Raptor often (for me at least) seems to crash on RDFa. It also complains a lot when named entities are us... On Fri, 2009-06-26 at 09:35 +0200, Dan Brickley wrote: > Does every major RDF toolkit have an integrated RDFa parser already? No - and even for those that do, it's often rather flaky. Seseme/Rio doesn't have one in its stable release, though I believe one is in development for 3.0. Redland/Raptor often (for me at least) seems to crash on RDFa. It also complains a lot when named entities are used (e.g. &nbsp;) even though the XHTML+RDFa 1.0 DTD does allow them. Jena (just testing on sparql.org) doesn't seem to handle RDFa at all. Not really "toolkits" per se, but cwm and the current release of Tabulator don't seem to have RDFa support. (Though I think support for the latter is being worked on.) For application developers who are specifically trying to support RDFa, none of this is a major problem - it's pretty easy to include a little content-type detection and pass the XHTML through an RDFa->XML converter prior to the rest of your code getting its hands on it - but this does require specific handling, which must be an obstacle to adoption. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/16729969-EE51-4608-85B5-D108637C9988%40g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-06-27T18:50:56 2009-06-27T18:50:56 2009-06-27T18:50:56 On 27 Jun 2009, at 11:25, Melvin Carvalho wrote: > What happens if you put them in one big <span> tree and use the > @content attribute? view-source:http://ontologi.es/rail/routes/gb/VTB1.xhtml -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 27 Jun 2009, at 11:25, Melvin Carvalho wrote: > What happens if you put them in one big <span> tree and use the > @content attribute? view-source:http://ontologi.es/rail/routes/gb/VTB1.xhtml -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1246280726.1981.21.camel%40ophelia2.g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-06-29T13:05:28 2009-06-29T13:05:28 2009-06-29T13:05:28 On Mon, 2009-06-29 at 13:30 +0100, Mark Birbeck wrote: > If we go back a step, RDFa was carefully designed so that it could > carry any combination of the RDF concepts in an HTML document. In the > end we dropped reification and lists, because it didn't seem that the > RDF community itself was clear on the future of those, but they are > both easily added back if the issues were to be resolved. R... On Mon, 2009-06-29 at 13:30 +0100, Mark Birbeck wrote: > If we go back a step, RDFa was carefully designed so that it could > carry any combination of the RDF concepts in an HTML document. In the > end we dropped reification and lists, because it didn't seem that the > RDF community itself was clear on the future of those, but they are > both easily added back if the issues were to be resolved. RDF reification and lists do *work* in RDFa, they're just a bit of a pain to mark up. e.g. here's a reification: <div xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:db="http://dbpedia.org/resource/" typeof="rdf:Statement"> <span property="dc:creator">Mark Birkbeck</span> says that <span rel="rdf:subject" resource="[db:Sky]">the sky</span> <span rel="rdf:predicate" resource="http://dbpedia.org/property/color" >is</span>  <span rel="rdf:object" resource="[db:Blue]">blue</span>. </div> And an example of a list can be found here: http://ontologi.es/rail/routes/gb/VTB1.xhtml -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1246284680.1981.25.camel%40ophelia2.g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-06-29T14:11:21 2009-06-29T14:11:21 2009-06-29T14:11:21 On Mon, 2009-06-29 at 09:46 -0400, Yihong Ding wrote: > I envision an innovation of semantic data display combining the > strengthes of Microformat and RDFa/RDF. But it is surely not easy. It's not easy, it's EASE. ;-) http://buzzword.org.uk/2008/rdf-ease/spec Note to myself: chapter 1 needs fleshing out with some examples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2009-06-29 at 09:46 -0400, Yihong Ding wrote: > I envision an innovation of semantic data display combining the > strengthes of Microformat and RDFa/RDF. But it is surely not easy. It's not easy, it's EASE. ;-) http://buzzword.org.uk/2008/rdf-ease/spec Note to myself: chapter 1 needs fleshing out with some examples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1246372710.1981.82.camel%40ophelia2.g5n.co.uk XHTML + RDFa + @role 2009-06-30T14:38:31 2009-06-30T14:38:31 2009-06-30T14:38:31 Can someone publish a DTD for this (and maybe including the rest of ARIA)? I've done similar for HTML4, but personally find XHTML's DTDs confusing. http://buzzword.org.uk/2008/html4plus-example.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Can someone publish a DTD for this (and maybe including the rest of ARIA)? I've done similar for HTML4, but personally find XHTML's DTDs confusing. http://buzzword.org.uk/2008/html4plus-example.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1246464382.26752.17.camel%40ophelia2.g5n.co.uk Re: tutorial on Music and the Web of Data 2009-07-01T16:06:23 2009-07-01T16:06:23 2009-07-01T16:06:23 On Wed, 2009-07-01 at 14:46 +0100, Kurt J wrote: > We've launched a website which will contain all tutorial materials > [2]. If you have any suggestions for materials to include you can > comment on that site or on this thread. Take a look at libre.fm, an open source project to create a site similar to last.fm. It publishes listening data, artist, album and track data, and user profiles in RDFa... On Wed, 2009-07-01 at 14:46 +0100, Kurt J wrote: > We've launched a website which will contain all tutorial materials > [2]. If you have any suggestions for materials to include you can > comment on that site or on this thread. Take a look at libre.fm, an open source project to create a site similar to last.fm. It publishes listening data, artist, album and track data, and user profiles in RDFa. Where possible we link to dbtune.org URIs for artists, tracks and albums; to geonames.org for locations; and to peoples' external WebIDs. e.g. my profile at: http://alpha.libre.fm/user/tobyink -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/EE05532D-2C12-4F6A-BC51-5236CDEEADDD%40g5n.co.uk Re: HTML+RDFa Issues (update) 2009-07-02T08:01:09 2009-07-02T08:01:09 2009-07-02T08:01:09 On 2 Jul 2009, at 05:00, Manu Sporny wrote: > As Shane has mentioned previously, we should immediately update the > XHTML+RDFa errata document to say that all prefixes specified by > xmlns: > should be lower-case. In other words, authors SHOULD NOT use mixed > case > for prefixes. I think even that's too strong a prohibition! How about: authors SHOULD NOT define two CURIE prefixes which differ only by case. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 2 Jul 2009, at 05:00, Manu Sporny wrote: > As Shane has mentioned previously, we should immediately update the > XHTML+RDFa errata document to say that all prefixes specified by > xmlns: > should be lower-case. In other words, authors SHOULD NOT use mixed > case > for prefixes. I think even that's too strong a prohibition! How about: authors SHOULD NOT define two CURIE prefixes which differ only by case. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1246628167.26752.48.camel%40ophelia2.g5n.co.uk Re: Social Network Usage Stats by Country 2009-07-03T13:36:08 2009-07-03T13:36:08 2009-07-03T13:36:08 On Thu, 2009-07-02 at 21:06 +0200, Melvin Carvalho wrote: > Ranked by Average Hours per Visitor* I think there's a missing "per" in there. Average hours per visitor per day? Per week? Per month? Over the course of a lifetime? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2009-07-02 at 21:06 +0200, Melvin Carvalho wrote: > Ranked by Average Hours per Visitor* I think there's a missing "per" in there. Average hours per visitor per day? Per week? Per month? Over the course of a lifetime? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20C5F74E-C8B3-44B9-A956-71872B4D3C2B%40g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-07-05T12:54:32 2009-07-05T12:54:32 2009-07-05T12:54:32 On 5 Jul 2009, at 01:52, Pierre-Antoine Champin wrote: > I guess a PHP version would not even require that .htaccess, but > sorry, I'm not fluent in PHP ;) The situation with PHP should be much the same, though I suppose web hosts might be more likely to set index.php in the DirectoryIndex as a default. Anyway, I've done a quick port of your code to PHP. (I stripped out your connection... On 5 Jul 2009, at 01:52, Pierre-Antoine Champin wrote: > I guess a PHP version would not even require that .htaccess, but > sorry, I'm not fluent in PHP ;) The situation with PHP should be much the same, though I suppose web hosts might be more likely to set index.php in the DirectoryIndex as a default. Anyway, I've done a quick port of your code to PHP. (I stripped out your connection negotiation code and replaced it with my own, as I figured out it would be faster to paste in the ConNeg class I'm familiar with rather than do line-by-line porting of the Python to PHP.) Here it is, same license - LGPL 3. We should start a repository somewhere of useful code for serving linked data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C1D17292-58FF-4D2C-BFA4-F4F5E0ABF924%40g5n.co.uk Re: Explicit RDF property for "literal has datatype D"? 2009-07-06T14:53:56 2009-07-06T14:53:56 2009-07-06T14:53:56 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6 Jul 2009, at 14:34, Christoph LANGE wrote: > p a rdf:Property ; > rdfs:domain rdfs:Literal ; > rdfs:range rdfs:Datatype . In terms of RDF, this can't be done. Well, the property could be defined using RDFS, but it could never legally be used. The definition would imply that "p" is used like so: "2008-01-01" p xsd:date . However, RDF... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6 Jul 2009, at 14:34, Christoph LANGE wrote: > p a rdf:Property ; > rdfs:domain rdfs:Literal ; > rdfs:range rdfs:Datatype . In terms of RDF, this can't be done. Well, the property could be defined using RDFS, but it could never legally be used. The definition would imply that "p" is used like so: "2008-01-01" p xsd:date . However, RDF doesn't allow a literal to be used as the subject of a triple. Hence there is no property defined like the "p" you describe. There are supersets of RDF (such as Notation 3) which relax this restriction and would allow a property "p" like you describe to be used. - -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpSEAQACgkQzr+BKGoqfTnHfQCfV50trF0sL9InwG08FgvQfbDQ mBQAnA3dot8UHlT5bmvLtUycwQhAwYSB =cB/I -----END PGP SIGNATURE----- http://tobyinkster.co.uk/message/3720B290-EE5C-40EC-9B0E-673A04E95E05%40tobyinkster.co.uk Re: Explicit RDF property for "literal has datatype D"? 2009-07-06T15:24:52 2009-07-06T15:24:52 2009-07-06T15:24:52 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6 Jul 2009, at 15:53, Toby A Inkster wrote: > In terms of RDF, this can't be done. Well, the property could be > defined using RDFS, but it could never legally be used. The > definition would imply that "p" is used like so: > > "2008-01-01" p xsd:date . Forgot to mention... (somewhat perversely) the inverse is fine and dandy! ex:isDataty... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6 Jul 2009, at 15:53, Toby A Inkster wrote: > In terms of RDF, this can't be done. Well, the property could be > defined using RDFS, but it could never legally be used. The > definition would imply that "p" is used like so: > > "2008-01-01" p xsd:date . Forgot to mention... (somewhat perversely) the inverse is fine and dandy! ex:isDatatypeOf rdfs:domain rdfs:Datatype ; rdfs:range rdfs:Literal . xsd:date ex:isDatatypeOf "2008-01-01" , "2008-01-02" . If it's OK to say one, why isn't it OK to say the other? Silly RDF. - -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpSF0QACgkQzr+BKGoqfTmVQwCeItza5JyfINyCQcLJ2JOVXXAR 2RgAn2wsykWNR9hzeSyTWoHhcBrR4QQg =jOTI -----END PGP SIGNATURE----- http://tobyinkster.co.uk/message/1247075431.17905.10.camel%40ophelia2.g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-07-08T17:50:37 2009-07-08T17:50:37 2009-07-08T17:50:37 On Wed, 2009-07-08 at 15:13 +0100, Mark Birbeck wrote: > The original point of this thread seemed to me to be saying that if > .htaccess is the key to the semantic web, then it's never going to > happen. It simply isn't the key to the semantic web though. .htaccess is a simple way to configure Apache to do interesting things. It happens to give you a lot of power in deciding how requests for URL... On Wed, 2009-07-08 at 15:13 +0100, Mark Birbeck wrote: > The original point of this thread seemed to me to be saying that if > .htaccess is the key to the semantic web, then it's never going to > happen. It simply isn't the key to the semantic web though. .htaccess is a simple way to configure Apache to do interesting things. It happens to give you a lot of power in deciding how requests for URLs should be translated into responses of data. If you have hosting which allows you such advanced control over your settings, and you can create nicer URLs, then by all means do so - and not just for RDF, but for all your URLs. It's a Good Thing to do, and in my opinion, worth switching hosts to achieve. But all that isn't necessary to publish linked data. If you own example.com, you can upload foaf.rdf and give yourself a URI like: <http://example.com/foaf.rdf#alice> (Or foaf.ttl, foaf.xhtml, whatever.) No, that's not as elegant as <http://example.com/alice> with a connection negotiated 303 redirect to representations in various formats, but it does work, and it won't break anything. Let's not blow this all out of proportion. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D68ED2C7-03C2-4453-B7D6-37F23CB9C87C%40g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-07-08T23:38:19 2009-07-08T23:38:19 2009-07-08T23:38:19 On 8 Jul 2009, at 19:58, Seth Russell wrote: > Is it not true that everything past the hash (#alice) is not > transmitted back to the server when a browser clicks on a > hyperlink ? If that is true, then the server would not be able to > serve anything different if a browser clicked upon http:// > example.com/foaf.rdf or if they clicked upon http://example.com/ > foaf.rdf#alice . Indee... On 8 Jul 2009, at 19:58, Seth Russell wrote: > Is it not true that everything past the hash (#alice) is not > transmitted back to the server when a browser clicks on a > hyperlink ? If that is true, then the server would not be able to > serve anything different if a browser clicked upon http:// > example.com/foaf.rdf or if they clicked upon http://example.com/ > foaf.rdf#alice . Indeed - the server doesn't see the fragment. > If that is true, and it probably isn't, then is not the Semantic > Web crippled from using that techniqe to distinguish between > resources and at the same time hyper linking between those > different resources? Not at all. Is the web of documents crippled because the server can't distinguish between requests for http://example.com/document.html and http:// example.com/document.html#part2 ? Of course it isn't - the server doesn't need to distinguish between them - it serves up the same web page either way and lets the user agent distinguish. Hash URIs are very valuable in linked data, precisely *because* they can't be directly requested from a server - they allow us to bypass the whole HTTP 303 issue. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BBEE642B-AA70-4F08-8C45-905736D50277%40g5n.co.uk Re: .htaccess a major bottleneck to Semantic Web adoption / Was: Re: RDFa vs RDF/XML and content negotiation 2009-07-09T07:08:49 2009-07-09T07:08:49 2009-07-09T07:08:49 On 9 Jul 2009, at 07:44, Juan Sequeda wrote: > On Jul 9, 2009, at 2:25 AM, Hugh Glaser <hg@ecs.soton.ac.uk> wrote: >> Mind you, it does mean that you should make sure that you don't >> put too many >> LD URIs in one document. >> If dbpedia decided to represent all the RDF in one document, and >> then use >> hash URIs, it would be somewhat problematic. > > Could you explain why??? The very pr... On 9 Jul 2009, at 07:44, Juan Sequeda wrote: > On Jul 9, 2009, at 2:25 AM, Hugh Glaser <hg@ecs.soton.ac.uk> wrote: >> Mind you, it does mean that you should make sure that you don't >> put too many >> LD URIs in one document. >> If dbpedia decided to represent all the RDF in one document, and >> then use >> hash URIs, it would be somewhat problematic. > > Could you explain why??? The very practical problem of file sizes. Your hash URIs can of course be distributed across a collection of files. e.g. http://example.com/~alice/foaf.rdf#me http://example.com/~bob/foaf.rdf#me http://example.com/~carol/foaf.rdf#me -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8E6695F7-CED9-4BB8-86D8-480A9083FC02%40g5n.co.uk Re: RDFa vs RDF/XML and content negotiation 2009-07-09T07:22:15 2009-07-09T07:22:15 2009-07-09T07:22:15 On 9 Jul 2009, at 05:10, Sergey Chernyshev wrote: > I think that if your goal is to publish it to public, publish in > all formats, including CSV or vcard as long as there is at least > one tool that will potentially consume this information. I used to ascribe to this philosophy. I offered feeds of my blog in: RSS 0.91 RSS 1.0 (RDF) RSS 2.0 RSS 2.0 with HTML summaries Atom 1.0 Atom 1... On 9 Jul 2009, at 05:10, Sergey Chernyshev wrote: > I think that if your goal is to publish it to public, publish in > all formats, including CSV or vcard as long as there is at least > one tool that will potentially consume this information. I used to ascribe to this philosophy. I offered feeds of my blog in: RSS 0.91 RSS 1.0 (RDF) RSS 2.0 RSS 2.0 with HTML summaries Atom 1.0 Atom 1.0 with HTML summaries iCalendar JSON PHP Serialised Object format CSV But I found that offering all those options tended to confuse rather than help people, so I don't do that any more. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247158545.6412.18.camel%40ophelia2.g5n.co.uk Re: HTML+RDFa Issues (update) 2009-07-09T16:55:46 2009-07-09T16:55:46 2009-07-09T16:55:46 On Thu, 2009-07-09 at 16:58 +0200, Julian Reschke wrote: > If I had a solution that is compatible both with RDFa and full-URIs in > @rel, I would already have proposed it. That's why I've been > complaining for so long: I think the use of CURIEs instead of > safe-CURIEs in @rel is a big problem. (It's ok in new attributes, but > problematic in @rel/rev). Safe CURIEs are important in @about/@resou... On Thu, 2009-07-09 at 16:58 +0200, Julian Reschke wrote: > If I had a solution that is compatible both with RDFa and full-URIs in > @rel, I would already have proposed it. That's why I've been > complaining for so long: I think the use of CURIEs instead of > safe-CURIEs in @rel is a big problem. (It's ok in new attributes, but > problematic in @rel/rev). Safe CURIEs are important in @about/@resource because those attributes are primarily intended for URIs. The @rel attribute was not previously used for URIs, so no disambiguation mechanism was needed. Yes, @rel in *Atom* is a URI, but no previous recommendations for HTML or XHTML have recommended URIs in @rel, and the current HTML5 draft doesn't either. Nor am I aware of any widely non-W3C specifications that use URIs in @rel. Google's rel=canonical and rel=nofollow are simple tokens. Pingback uses a simple token, and so do microformats. So I'm not sure where these pre-existing uses of URIs in @rel are supposed to be found. If you're concerned by compatibility between HTML's @rel and Atom's @rel, then don't be. They're completely incompatible. Atom's is not a token separated list at all. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247159028.6412.26.camel%40ophelia2.g5n.co.uk Re: adding reification ids 2009-07-09T17:03:48 2009-07-09T17:03:48 2009-07-09T17:03:48 On Thu, 2009-07-09 at 18:46 +0200, Simon Reinhardt wrote: > You might want to take a look at > http://buzzword.org.uk/2009/rdfa4/spec - it doesn't use reification > but named graphs instead which I'd prefer anyway. Reification can effectively be achieved by putting each triple into a separate graph. I'd be interested in hearing if anyone has any other feedback on RDFa Quads, as I'm considering i... On Thu, 2009-07-09 at 18:46 +0200, Simon Reinhardt wrote: > You might want to take a look at > http://buzzword.org.uk/2009/rdfa4/spec - it doesn't use reification > but named graphs instead which I'd prefer anyway. Reification can effectively be achieved by putting each triple into a separate graph. I'd be interested in hearing if anyone has any other feedback on RDFa Quads, as I'm considering issuing an updated draft. My main planned updates are: - define the attribute to be called "graph" in the normal XHTML namespace. - specify the lexical space of graph as being like xhtml:id. This is the less flexible option, but has the advantage that it's easy to identify all the graphs from a particular document. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/46284786-E778-4B62-AE75-5F21E9C8A9A9%40g5n.co.uk Re: XHTML + RDFa + @role 2009-07-09T21:17:37 2009-07-09T21:17:37 2009-07-09T21:17:37 On 30 Jun 2009, at 15:38, Toby Inkster wrote: > Can someone publish a DTD for this (and maybe including the rest of > ARIA)? OK, I've gone ahead and done it myself: http://demiblog.org/dtd/xhtml-rdfa-role-1.dtd To use it, your DOCTYPE should look like this: <!DOCTYPE html PUBLIC "+//IDN demiblog.org//DTD XHTML+RDFa+Role 1.0//EN" "http://demiblog.org/dtd/xhtml-rdfa-role-1.dtd"> Your <html> element should have attribute version="XHTML+RDFa+Role 1.0". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 30 Jun 2009, at 15:38, Toby Inkster wrote: > Can someone publish a DTD for this (and maybe including the rest of > ARIA)? OK, I've gone ahead and done it myself: http://demiblog.org/dtd/xhtml-rdfa-role-1.dtd To use it, your DOCTYPE should look like this: <!DOCTYPE html PUBLIC "+//IDN demiblog.org//DTD XHTML+RDFa+Role 1.0//EN" "http://demiblog.org/dtd/xhtml-rdfa-role-1.dtd"> Your <html> element should have attribute version="XHTML+RDFa+Role 1.0". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/99EA22B1-984A-4853-AA6B-FCCAD82D5B55%40g5n.co.uk Re: XHTML + RDFa + @role 2009-07-10T07:07:59 2009-07-10T07:07:59 2009-07-10T07:07:59 On 9 Jul 2009, at 22:36, Laurens Holst wrote: > The version attribute is deprecated in HTML4.01, never used, and no > longer present in HTML5… I also see no language in the XHTML 1.1 > specification defining the content format of this attribute or > requiring its use (although it does seem to be in the DTD, which I > find strange as it wasn’t in XHTML 1.0’s), and I know of no > implemen... On 9 Jul 2009, at 22:36, Laurens Holst wrote: > The version attribute is deprecated in HTML4.01, never used, and no > longer present in HTML5… I also see no language in the XHTML 1.1 > specification defining the content format of this attribute or > requiring its use (although it does seem to be in the DTD, which I > find strange as it wasn’t in XHTML 1.0’s), and I know of no > implementations using such an attribute. So it seems a bit useless > to add it. Let’s keep HTML free of versioning. Wasn't my idea - the version attribute is already in XHTML+RDFa 1.0 (and setting it is a "SHOULD" in the conformance requirements). I've stuck to much the same requirements, just changing the DTD and the value for the version attribute. As far as implementations that use it, my own semantic web tool Swignition has a "strict mode" where it refuses to parse a document as RDFa without the version requirement. So there's at least one implementation that does use it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247219612.18243.10.camel%40ophelia2.g5n.co.uk Re: Dons flame resistant (3 hours) interface about Linked Data URIs 2009-07-10T09:53:33 2009-07-10T09:53:33 2009-07-10T09:53:33 On Fri, 2009-07-10 at 10:12 +0100, Richard Light wrote: > so the final decision is: which of these URLs > should be the one which represents the subject of discourse? And the > answer has to be: Neither. If I use the URL of my machine readable data to identity myself (myself being the subject of discourse) then it immediately creates ambiguities. What would it mean for the file to have a dc:... On Fri, 2009-07-10 at 10:12 +0100, Richard Light wrote: > so the final decision is: which of these URLs > should be the one which represents the subject of discourse? And the > answer has to be: Neither. If I use the URL of my machine readable data to identity myself (myself being the subject of discourse) then it immediately creates ambiguities. What would it mean for the file to have a dc:created property? Would the value of that property be my date of birth, or would it be the date I first uploaded my data? The classic example is that if I use the same URL to represent myself and my web page, then how can I state that I am the creator of my web page without also asserting that I'm my own father. The URL of the file and the URL of the subject of discourse must differ so that we can make unambiguous statements about each, and make statements about the relationship between the two. An incredibly easy way to do this is to just add a fragment to the URL of the subject of discourse. Examples include: <http://tobyinkster.co.uk/> represents my web page <http://tobyinkster.co.uk/#i> represents me <http://id.loc.gov/authorities/sh85082139> is a web page <http://id.loc.gov/authorities/sh85082139#concept> is the abstract concept of Mathematics. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247220028.18243.17.camel%40ophelia2.g5n.co.uk Re: Dons flame resistant (3 hours) interface about Linked Data URIs 2009-07-10T10:00:28 2009-07-10T10:00:28 2009-07-10T10:00:28 On Fri, 2009-07-10 at 10:40 +0100, Steve Harris wrote: > Personally I think that RDF/XML doesn't help, it's too hard to write > by hand. MicroTurtle, the sloppy RDF format: <http://buzzword.org.uk/2009/microturtle/spec> I really need to document my implementation's error recovery too. It copes pretty well with accidentally missed commas, semi-colons and full-stops. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2009-07-10 at 10:40 +0100, Steve Harris wrote: > Personally I think that RDF/XML doesn't help, it's too hard to write > by hand. MicroTurtle, the sloppy RDF format: <http://buzzword.org.uk/2009/microturtle/spec> I really need to document my implementation's error recovery too. It copes pretty well with accidentally missed commas, semi-colons and full-stops. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9548A4DD-8C6D-4F22-A045-02581BDAEAE0%40g5n.co.uk Re: Proposal for allowing URIs in CURIE-only attributes 2009-07-12T17:50:42 2009-07-12T17:50:42 2009-07-12T17:50:42 On 10 Jul 2009, at 13:23, Mark Birbeck wrote: > (c) but since ordinary CURIEs may still be used, we should > differentiate > by saying that anything appearing before a colon, that is not a > mapped prefix, is a protocol. Wouldn't this break existing pre-RDFa uses of CURIE-like tokens? Uses of "dc:blah" with no explicit prefix mapping are not uncommon. (Admittedly more in meta@na... On 10 Jul 2009, at 13:23, Mark Birbeck wrote: > (c) but since ordinary CURIEs may still be used, we should > differentiate > by saying that anything appearing before a colon, that is not a > mapped prefix, is a protocol. Wouldn't this break existing pre-RDFa uses of CURIE-like tokens? Uses of "dc:blah" with no explicit prefix mapping are not uncommon. (Admittedly more in meta@name than @rel.) I'd say they're almost certainly more common than the full-URIs-in-rel that this solution is designed to work around. eRDF pages will often also contain rel values with colons in. eRDF does map prefixes to URIs, but not via xmlns:foo, instead using an RFC2731-style <link> element. In both of those cases, you'll end up with incorrect triples that use bogus URL schemes. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C8F4DD6B-5D38-44AC-8C4E-CB8319062785%40g5n.co.uk Re: FYI: Blog post about Web of Identities 2009-07-13T19:16:49 2009-07-13T19:16:49 2009-07-13T19:16:49 On 13 Jul 2009, at 18:31, Kaliya wrote: > The think I am confused about when you propose this is that your > browser becomes a "beacon" giving away your identifier to who ever > asks. Maybe I am not understanding how this [FOAF+SSL] works but > when Kingsley explained it to me at the Sem Web conference this is > what I "got" Your browser should pop up a dialogue box asking which certi... On 13 Jul 2009, at 18:31, Kaliya wrote: > The think I am confused about when you propose this is that your > browser becomes a "beacon" giving away your identifier to who ever > asks. Maybe I am not understanding how this [FOAF+SSL] works but > when Kingsley explained it to me at the Sem Web conference this is > what I "got" Your browser should pop up a dialogue box asking which certificate you wish to use when you visit a website. If you hit "cancel" then the web site may decide to give you anonymous access, or may decline to give you access - it's their choice. However, in some browsers -- particularly if you have exactly one certificate installed -- you will not be shown that dialogue box. This does raise some anonymity issues, but I tend to see that as a browser issue -- the problem has existed for years before FOAF+SSL arrived on the scene. If people care about this issue and complain, then browser developers will fix it and improve client side SSL certificate selection UIs. Ultimately though, the identifiers used by FOAF+SSL are just opaque URLs. The file at the other end of them can include as much or as little information about you as you wish to provide. Name? Optional. E-mail address? Optional. Shoe size? Yes, if you really want - it's up to you! And you can choose to use different identities for different sites, though of course the main motivations for most people in using federated identity systems like FOAF+SSL and OpenID are to consolidate their identity on the web, and avoid setting up different profiles for every service they with to use. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/334FCCF9-D3A9-47BC-BD25-103746E251EE%40g5n.co.uk Re: FYI: Blog post about Web of Identities 2009-07-13T21:33:54 2009-07-13T21:33:54 2009-07-13T21:33:54 On 13 Jul 2009, at 20:18, Kaliya wrote: > Where are the main places where this vision is articulated on the web? FOAF+SSL on the ESW Wiki: http://esw.w3.org/topic/foaf+ssl Mailing List: http://lists.foaf-project.org/mailman/listinfo/foaf-protocols Also of interest: http://esw.w3.org/topic/foaf+ssl/UseCases http://esw.w3.org/topic/foaf+ssl/FAQ http://blogs.sun.com/bblfish/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 13 Jul 2009, at 20:18, Kaliya wrote: > Where are the main places where this vision is articulated on the web? FOAF+SSL on the ESW Wiki: http://esw.w3.org/topic/foaf+ssl Mailing List: http://lists.foaf-project.org/mailman/listinfo/foaf-protocols Also of interest: http://esw.w3.org/topic/foaf+ssl/UseCases http://esw.w3.org/topic/foaf+ssl/FAQ http://blogs.sun.com/bblfish/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247654135.11252.18.camel%40ophelia2.g5n.co.uk Re: Agenda: Social Web XG Meeting July 15th 2009-07-15T10:35:35 2009-07-15T10:35:35 2009-07-15T10:35:35 On Tue, 2009-07-14 at 17:44 +0100, Harry Halpin wrote: > + [CONTINUES] ACTION: tinkster to document danbri's > microblogging provenance question as a user story. Not sure if it was minuted but I did mention that I'd finished this in last week's call. The user story is here: http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#Tracking_Sources Currently my only ongoing action is ACTIO... On Tue, 2009-07-14 at 17:44 +0100, Harry Halpin wrote: > + [CONTINUES] ACTION: tinkster to document danbri's > microblogging provenance question as a user story. Not sure if it was minuted but I did mention that I'd finished this in last week's call. The user story is here: http://www.w3.org/2005/Incubator/socialweb/wiki/UserStories#Tracking_Sources Currently my only ongoing action is ACTION-56: http://www.w3.org/2005/Incubator/socialweb/track/actions/56 Which I have not started yet, but will do this evening hopefully. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247734252.23734.7.camel%40ophelia2.g5n.co.uk Re: xmlns in HTML5 (was: Telecon Agenda- Thursday 1500 UTC) 2009-07-16T08:50:57 2009-07-16T08:50:57 2009-07-16T08:50:57 On Thu, 2009-07-16 at 00:40 -0400, Manu Sporny wrote: > I think we will inevitably hit upon the xmlns: discussion for non-XML > languages, namely HTML5. After doing some digging, I was unable to > find a place in the HTML5 spec that says that xmlns:-based namespace > declarations cannot be used in HTML5 (vs. XHTML5). For some reason, the Gell-Mann Totalitarian Principle sprung into my mind when I... On Thu, 2009-07-16 at 00:40 -0400, Manu Sporny wrote: > I think we will inevitably hit upon the xmlns: discussion for non-XML > languages, namely HTML5. After doing some digging, I was unable to > find a place in the HTML5 spec that says that xmlns:-based namespace > declarations cannot be used in HTML5 (vs. XHTML5). For some reason, the Gell-Mann Totalitarian Principle sprung into my mind when I read this. "Everything which is not forbidden, is compulsory." But the HTML specs, recklessly defying quantum physics, do not follow that principle. Instead... "Everything which is not defined, is forbidden." For the same reason, xmlns:foo attributes aren't allowed in HTML4 either. Ian Hickson wrote: > Authors must not use elements, attributes, and attribute values that > are not permitted by this specification or other applicable > specifications. > -- http://www.whatwg.org/specs/web-apps/current-work/#semantics-0 Which "other specifications" are "applicable"? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247736721.23734.15.camel%40ophelia2.g5n.co.uk Re: xmlns in HTML5 (was: Telecon Agenda- Thursday 1500 UTC) 2009-07-16T09:32:02 2009-07-16T09:32:02 2009-07-16T09:32:02 On Thu, 2009-07-16 at 09:20 +0000, Ian Hickson wrote: > On Thu, 16 Jul 2009, Toby Inkster wrote: > > Ian Hickson wrote: > > > > > Authors must not use elements, attributes, and attribute values that > > > are not permitted by this specification or other applicable > > > specifications. > > > -- http://www.whatwg.org/specs/web-apps/current-work/#semantics-0 > > > > Which "other specifications" a... On Thu, 2009-07-16 at 09:20 +0000, Ian Hickson wrote: > On Thu, 16 Jul 2009, Toby Inkster wrote: > > Ian Hickson wrote: > > > > > Authors must not use elements, attributes, and attribute values that > > > are not permitted by this specification or other applicable > > > specifications. > > > -- http://www.whatwg.org/specs/web-apps/current-work/#semantics-0 > > > > Which "other specifications" are "applicable"? > > Pretty much any that claim to be and that the people affected agree > are applicable. So assuming that people deem the HTML 4.01 Recommendation to be "applicable", the much debated @summary, @longdesc and @profile may all be used in HTML5? A document using @summary is conformant if and only if the person assessing the document's conformance deems HTML 4.01 to be applicable? The observer influences the outcome of the experiment? Perhaps HTML5 is very quantum physics after all... -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1247764468.23734.77.camel%40ophelia2.g5n.co.uk Re: an alternative for microformat-like simplicity 2009-07-16T17:14:29 2009-07-16T17:14:29 2009-07-16T17:14:29 On Thu, 2009-07-16 at 10:03 -0700, Ben Adida wrote: > Vocabulary Definition at http://ben.adida.net/vocab, using RDFa: > > <div about="#name" typeof="rdf:Property"> > <h4 property="rdfs:label">name</h4>, > which corresponds to > <a rel="owl:sameAs" > href="http://xmlns.com/foaf/0.1/name"> > foaf:name > </a>. > </div> I'm pretty sure that OWL people would advise yo... On Thu, 2009-07-16 at 10:03 -0700, Ben Adida wrote: > Vocabulary Definition at http://ben.adida.net/vocab, using RDFa: > > <div about="#name" typeof="rdf:Property"> > <h4 property="rdfs:label">name</h4>, > which corresponds to > <a rel="owl:sameAs" > href="http://xmlns.com/foaf/0.1/name"> > foaf:name > </a>. > </div> I'm pretty sure that OWL people would advise you to use either rdfs:subPropertyOf or the stronger owl:equivalentProperty rather than owl:sameAs. This would be for two reasons: 1. OWL-DL purity: apart from in OWL Full, owl:sameAs can only be used for instances (things) and not for properties and classes. 2. owl:sameAs asserts that everything that is true about one thing is true about the other. I'm not sure that the rdfs:isDefinedBy property of foaf:name necessarily applies to yourvocab:name. You don't want something as strong as owl:sameAs here. > - what does rel="license" resolve to when @prefix is set? I think the > reserved keywords should trump all, but it's worth a debate. > > - what does rel="foobar" resolve to? I think if you've declared > @prefix, then it is no longer ignored and there should be a foobar > property within that vocabulary, but if there isn't then it's just a > dead triple, very little harm in that. "me too" to both. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/3A388B37-9D14-4A78-A6E7-8B854074A133%40g5n.co.uk Re: an alternative for microformat-like simplicity 2009-07-16T18:21:29 2009-07-16T18:21:29 2009-07-16T18:21:29 On Thu, 2009-07-16 at 10:03 -0700, Ben Adida wrote: > Vocabulary Definition at http://ben.adida.net/vocab, using RDFa: > > <div about="#name" typeof="rdf:Property"> > <h4 property="rdfs:label">name</h4>, > which corresponds to > <a rel="owl:sameAs" > href="http://xmlns.com/foaf/0.1/name"> > foaf:name > </a>. > </div> I'm pretty sure that OWL people would advise you... On Thu, 2009-07-16 at 10:03 -0700, Ben Adida wrote: > Vocabulary Definition at http://ben.adida.net/vocab, using RDFa: > > <div about="#name" typeof="rdf:Property"> > <h4 property="rdfs:label">name</h4>, > which corresponds to > <a rel="owl:sameAs" > href="http://xmlns.com/foaf/0.1/name"> > foaf:name > </a>. > </div> I'm pretty sure that OWL people would advise you to use either rdfs:subPropertyOf or the stronger owl:equivalentProperty rather than owl:sameAs. This would be for two reasons: 1. OWL-DL purity: apart from in OWL Full, owl:sameAs can only be used for instances (things) and not for properties and classes. 2. owl:sameAs asserts that everything that is true about one thing is true about the other. I'm not sure that the rdfs:isDefinedBy property of foaf:name necessarily applies to yourvocab:name. You don't want something as strong as owl:sameAs here. > - what does rel="license" resolve to when @prefix is set? I think > the > reserved keywords should trump all, but it's worth a debate. > > - what does rel="foobar" resolve to? I think if you've declared > @prefix, then it is no longer ignored and there should be a foobar > property within that vocabulary, but if there isn't then it's just a > dead triple, very little harm in that. "me too" to both. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E1528ED3-9836-40AF-8CAE-CD390687F70A%40g5n.co.uk Re: xmlns in HTML5 (was: Telecon Agenda- Thursday 1500 UTC) 2009-07-17T11:49:05 2009-07-17T11:49:05 2009-07-17T11:49:05 On 17 Jul 2009, at 12:34, Ian Hickson wrote: > It is literally not possible to send XHTML5 as text/html, because > as soon > as you label it as text/html, you are stating "it is HTML". As soon as Steven labels it as text/html, he is stating that it is HTML. But that doesn't mean that it is HTML. If I state that I'm President Elect of the Galactic Federation, that doesn't make it true. (I... On 17 Jul 2009, at 12:34, Ian Hickson wrote: > It is literally not possible to send XHTML5 as text/html, because > as soon > as you label it as text/html, you are stating "it is HTML". As soon as Steven labels it as text/html, he is stating that it is HTML. But that doesn't mean that it is HTML. If I state that I'm President Elect of the Galactic Federation, that doesn't make it true. (I'm only the Acting President.) It's certainly fine for browsers to process Steven's document using their normal rules for processing HTML, because that is what he has claimed that it is - it's not their fault if he's lied. Hopefully he has anticipated that they will do that, and checked that the document's rendering and functionality will not be hindered by this. Using a Content-Type header to determine what is HTML and what is XHTML for processing purposes is fragile -- not all situations where a processor will be dealing with (X)HTML necessarily involve HTTP -- but ultimately a good pragmatic decision. However, the determination of how something will be processed by user-agents does not necessarily effect its intrinsic nature. My website is XHTML, but it will be served as text/html if your browser seems to prefer it that way. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8C2C7779-DBCC-4FE7-9DE8-421B65EDC245%40g5n.co.uk Re: xmlns in HTML5 (was: Telecon Agenda- Thursday 1500 UTC) 2009-07-17T12:00:45 2009-07-17T12:00:45 2009-07-17T12:00:45 On 17 Jul 2009, at 12:49, Toby A Inkster wrote: > My website is XHTML, but it will be served as text/html if your > browser seems to prefer it that way. Further, if I serve it as text/plain so that people can see the source code and learn from its wonderousness, then are they viewing HTML source code or XHTML source code? Perhaps they are seeing both. Like wave-particle duality. The quantum physics nature of HTML5 crops up again. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 17 Jul 2009, at 12:49, Toby A Inkster wrote: > My website is XHTML, but it will be served as text/html if your > browser seems to prefer it that way. Further, if I serve it as text/plain so that people can see the source code and learn from its wonderousness, then are they viewing HTML source code or XHTML source code? Perhaps they are seeing both. Like wave-particle duality. The quantum physics nature of HTML5 crops up again. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/FE7AADEC-CD0B-4564-B500-D19EA08FCB31%40g5n.co.uk Re: an alternative for microformat-like simplicity 2009-07-17T20:45:33 2009-07-17T20:45:33 2009-07-17T20:45:33 On 17 Jul 2009, at 20:05, Ben Adida wrote: > Ok, I definitely want this to be done in the *right* OWL way, but with > the least amount of complexity possible. For example, I'd like this to > be usable with the simplest variant of OWL. The simplest version of OWL that the OWL spec defines is "OWL Lite", and rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass and owl:equivalentProperty a... On 17 Jul 2009, at 20:05, Ben Adida wrote: > Ok, I definitely want this to be done in the *right* OWL way, but with > the least amount of complexity possible. For example, I'd like this to > be usable with the simplest variant of OWL. The simplest version of OWL that the OWL spec defines is "OWL Lite", and rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass and owl:equivalentProperty all work there. Of course, if you just use rdfs:subClassOf and rdfs:subPropertyOf, you don't need any OWL at all - RDFS reasoning is sufficient. <#Ben> myvocab:name "Ben" . myvocab:name rdfs:subPropertyOf foaf:name . is enough information to reason that the following is true: <#Ben> foaf:name "Ben" . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E15714D1-53FB-437D-A47F-0EE7A7D724D7%40g5n.co.uk Re: When to use object property vs datatype property 2009-07-19T08:15:53 2009-07-19T08:15:53 2009-07-19T08:15:53 On 19 Jul 2009, at 07:40, Kevin Jenkins wrote: > It’s my understanding that object properties link individuals via a > property and that datatype properties link individuals to data > (such as form input). [...] I have many properties in my ontology > such as has-company-name, has-software-product, is-employee-of etc > … my guess is these must be datatype properties because somewhere > ... On 19 Jul 2009, at 07:40, Kevin Jenkins wrote: > It’s my understanding that object properties link individuals via a > property and that datatype properties link individuals to data > (such as form input). [...] I have many properties in my ontology > such as has-company-name, has-software-product, is-employee-of etc > … my guess is these must be datatype properties because somewhere > (I guess a web form) somebody has to name the company, choose the > software product category from a list, indicate who the employer is > etc. That's not correct. An object property is a property that takes a resource (an object) as its value. A datatype property is a property that takes a literal (string, number, date/time, boolean, etc) as its value. e.g. <#kj> rdf:type foaf:Person ; foaf:name "Kevin Jenkins" ; foaf:mbox <mailto:kj@iteegosearch.com> ; foaf:mbox_sha1sum "d610935545bb79ad673d5a5e7bd45a11f9b12128" ; foaf:knows <#alice> . In the above, foaf:mbox and foaf:knows are object properties, while foaf:name and foaf:mbox_sha1sum are datatype properties. (rdf:type is also logically an object property, though I think OWL treats it as a special case.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1248083694.32230.2.camel%40ophelia2.g5n.co.uk Re: temporary URLs on Second Life 2009-07-20T09:54:55 2009-07-20T09:54:55 2009-07-20T09:54:55 On Mon, 2009-07-20 at 11:10 +0200, Dan Brickley wrote: > Well, we can't have it both ways. > Either we want everything of interest to have HTTP URIs. > Or we want all HTTP URIs to de-reference usefully forever. Of course, but there's a difference between URLs getting broken because resources have been removed/relocated/restructured, and a policy of deliberately issuing URLs on a temporary basis. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2009-07-20 at 11:10 +0200, Dan Brickley wrote: > Well, we can't have it both ways. > Either we want everything of interest to have HTTP URIs. > Or we want all HTTP URIs to de-reference usefully forever. Of course, but there's a difference between URLs getting broken because resources have been removed/relocated/restructured, and a policy of deliberately issuing URLs on a temporary basis. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1248185431.32230.35.camel%40ophelia2.g5n.co.uk Re: an alternative for microformat-like simplicity 2009-07-21T14:10:31 2009-07-21T14:10:31 2009-07-21T14:10:31 On Tue, 2009-07-21 at 13:51 +0100, Martin McEvoy wrote: > Well I don't know about that... suppose you used the google vocab for > your terms... Indeed. I see Ben's proposal as most useful when combined with well known vocabularies. e.g. <div prefix="http://xmlns.com/foaf/0.1/" typeof="Person"> <h1 property="name">Toby Inkster</h1> <p> <b>Plan:</b> <i property="plan">worl... On Tue, 2009-07-21 at 13:51 +0100, Martin McEvoy wrote: > Well I don't know about that... suppose you used the google vocab for > your terms... Indeed. I see Ben's proposal as most useful when combined with well known vocabularies. e.g. <div prefix="http://xmlns.com/foaf/0.1/" typeof="Person"> <h1 property="name">Toby Inkster</h1> <p> <b>Plan:</b> <i property="plan">world domination</i> </p> </div> And if you need to mix in a few terms from other vocabs to indicate data which FOAF doesn't currently support, you can always fall back to using normal CURIEs. As well as FOAF, there are other vocabs that spring to mind: Dublin Core, RSS 1.0, DOAP, etc. These tend to provide pretty complete vocabularies for describing their respective problem domains, so are good candidates for the "just set a single default prefix" approach. I'd suggest that @prefix is maybe not the best name for the attribute -- too focused on the mechanics of CURIE mapping. @vocab maybe? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1248197028.32230.46.camel%40ophelia2.g5n.co.uk Re: Merging Databases 2009-07-21T17:23:48 2009-07-21T17:23:48 2009-07-21T17:23:48 On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote: > > I would say: Never assert sameAs. It's just too big a hammer. > > Instead use a wider palette of relationships to connect entities > > to other ones. > > which ones would you recommend? skos:exactMatch = asserts that the two resources represent the same concept, but does not assert that all triples containing the first resource ar... On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote: > > I would say: Never assert sameAs. It's just too big a hammer. > > Instead use a wider palette of relationships to connect entities > > to other ones. > > which ones would you recommend? skos:exactMatch = asserts that the two resources represent the same concept, but does not assert that all triples containing the first resource are necessarily true when the second resource is substituted in. skos:closeMatch = same as exact match, but slightly woolier. owl:equivalentProperty = if {X equivalentProperty Y} and {A X B} then {A Y B}. In other words, the properties can be used completely interchangeably. But perhaps there are other important differences between X and Y, such as their rdfs:label or rdfs:isDefinedBy. owl:equivalentClass = if {X equivalentClass Y} then all Xs are Ys and vice versa. Same dealy with owl:equivalentProperty really. ovterms:similarTo = a general, all-purpose wimps' predicate. I use this extensively. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/4254106E-A10B-4369-8E25-923DB385A268%40g5n.co.uk Re: PHP code only allowed in XHTML 5? 2009-07-22T08:33:06 2009-07-22T08:33:06 2009-07-22T08:33:06 On 22 Jul 2009, at 02:07, Leif Halvard Silli wrote: > Suppose one wants to validate a page that embeds PHP, but that one > wants to do so /prior/ to the execution of the PHP script: > > <?php Print "Hello, World!"; ?> > > Validator.nu will then tell you that the page is _invalid_ as a > HTML5 page. But that it is valid as a XHTML5 page ... Also, > checking the HTML 5 draft, you will ... On 22 Jul 2009, at 02:07, Leif Halvard Silli wrote: > Suppose one wants to validate a page that embeds PHP, but that one > wants to do so /prior/ to the execution of the PHP script: > > <?php Print "Hello, World!"; ?> > > Validator.nu will then tell you that the page is _invalid_ as a > HTML5 page. But that it is valid as a XHTML5 page ... Also, > checking the HTML 5 draft, you will find nothing about the <?> syntax. <p class="<?php echo 'foo';?>"> Invalid in both XHTML and HTML, but perfectly legal PHP. PHP's start and end markers are not real XML processing instructions. They just look a bit like them. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1249670068.29751.46.camel%40ophelia2.g5n.co.uk Re: Why bound prefixes are an anti-pattern in language design 2009-08-07T18:34:29 2009-08-07T18:34:29 2009-08-07T18:34:29 On Fri, 2009-08-07 at 04:34 +0000, Ian Hickson wrote: > Having said that, programming is far more complicated than writing > markup should be, so even if that was exactly the same, I wouldn't > like it as a precedent. I certainly wouldn't consider the use of RDFa to be as complicated as programming. It's far simpler to sprinkle a bit of RDFa into a web page indicating where semantically-enabled ... On Fri, 2009-08-07 at 04:34 +0000, Ian Hickson wrote: > Having said that, programming is far more complicated than writing > markup should be, so even if that was exactly the same, I wouldn't > like it as a precedent. I certainly wouldn't consider the use of RDFa to be as complicated as programming. It's far simpler to sprinkle a bit of RDFa into a web page indicating where semantically-enabled tools can find bits of data on the page, than it is to write a program (in, say, Javascript) that is capable of extracting such data. It is true that there are some techniques (e.g. microformats) which are simpler still, RDFa has other advantages (such as unambiguity and consistency) which, in my mind, are worth sacrificing a little ease of use for. On the other hand, the current HTML5 draft *does* define a number of features that *do* seem to require programmer-level knowledge to use: - the <canvas> element - the <datagrid> element - the Window object - Drag and drop Et cetera. If programmer-level complexity should exclude a solution from HTML5, then all these should be excluded ahead of RDFa. However, <canvas> is an *optional* element. It is not *wrong* for people to create web pages that do not use it. Thus the complexity is only exposed to people who opt into using it. RDFa is in the same boat - nobody is suggesting that people *must* use it. Its complexity is only exposed to people who want to include structured data in their pages. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/A020A74B-D92C-48B5-9688-983F152B026C%40g5n.co.uk New Scientist articles 2009-08-08T18:11:38 2009-08-08T18:11:38 2009-08-08T18:11:38 I was catching up on a few back-issues of New Scientist this morning and noticed a write-up of Sören Preibusch and Joseph Bonneau's research. The article can be found on their website here: http://www.newscientist.com/article/mg20327193.300 There's also a more in depth article (which I've not found in the dead tree edition yet) here: http://www.newscientist.com/article/dn17542 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I was catching up on a few back-issues of New Scientist this morning and noticed a write-up of Sören Preibusch and Joseph Bonneau's research. The article can be found on their website here: http://www.newscientist.com/article/mg20327193.300 There's also a more in depth article (which I've not found in the dead tree edition yet) here: http://www.newscientist.com/article/dn17542 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8207D1D8-CC17-4BDE-ADCA-E7A620A1FB34%40g5n.co.uk Re: The cite and pubdate attributes 2009-08-10T12:23:44 2009-08-10T12:23:44 2009-08-10T12:23:44 On 10 Aug 2009, at 12:48, Lachlan Hunt wrote: > The cite and pubdate attributes now defined for the article and > section elements don't seem to be very well designed. It's not > entirely clear what problem they are meant to solve, or use cases > they are addressing. They also violate the usual visible metadata > pattern and duplicate much of the functionality of other features > th... On 10 Aug 2009, at 12:48, Lachlan Hunt wrote: > The cite and pubdate attributes now defined for the article and > section elements don't seem to be very well designed. It's not > entirely clear what problem they are meant to solve, or use cases > they are addressing. They also violate the usual visible metadata > pattern and duplicate much of the functionality of other features > that are already in the spec. Certainly both can be replaced with a little RDFa fairly easily. <section id="foo" xmlns:dc="http://purl.org/dc/terms/" about="#foo"> <h1 property="dc:title">Foo</h1> <p> This section was first published at <time property="dc:issued">2009-01-01 12:00:00</time> and is based on <a rel="dc:source" href="http://example.com/data">this data</a>. </p> </section> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/0F393814-1308-4F76-B0C9-2508993C1B88%40g5n.co.uk Re: HTML5-warnings - request to publish as next heartbeat WD 2009-08-10T15:44:21 2009-08-10T15:44:21 2009-08-10T15:44:21 On 9 Aug 2009, at 14:32, Manu Sporny wrote: > 2. Two other independent voices to support the publishing of this > draft. > Without those voices, this proposal cannot be considered for > publishing. I think you already have those two other voices. FWIW, I agree that warnings about controversial passages of the draft - areas "at risk" - should be included in a published draft. They may... On 9 Aug 2009, at 14:32, Manu Sporny wrote: > 2. Two other independent voices to support the publishing of this > draft. > Without those voices, this proposal cannot be considered for > publishing. I think you already have those two other voices. FWIW, I agree that warnings about controversial passages of the draft - areas "at risk" - should be included in a published draft. They may turn out to be very valuable for early adopters of HTML5. For people whom development time comes at a premium, it may be important to avoid areas of HTML5 which are very likely to change before final publication. Conversely, those who have a lot of development time on their hands could even be encouraged to experiment in the more "at risk" parts of HTML5, so that they can feedback their experience to this group. I've not spent enough time reading Manu's edition of the HTML5 draft to decide whether the particular parts he's highlighted are the best parts to mark "at risk" (and perhaps even getting consensus on this list of parts to highlight could be daunting) but I certainly agree that in principle such parts should be noted. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/5EEC7E19-390D-4856-B124-27EC7F97DD30%40g5n.co.uk Re: The "real" reason why xmlns should "not" be used 2009-08-12T07:58:20 2009-08-12T07:58:20 2009-08-12T07:58:20 On 12 Aug 2009, at 05:24, Martin McEvoy wrote: > <div xmlns:dc="http://purl.org/dc/elements/1.1/"> > <h2 property="dc:title">The trouble with Bob</h2> > <h3 property="dc:creator">Alice</h3> > ... > </div> > > The above example is invalid because it declares the div having a > prefix of dc: example: > > <dc:div xmlns:dc="http://purl.org/dc/elements/1.1/"> > <h2 property="dc:title">The tr... On 12 Aug 2009, at 05:24, Martin McEvoy wrote: > <div xmlns:dc="http://purl.org/dc/elements/1.1/"> > <h2 property="dc:title">The trouble with Bob</h2> > <h3 property="dc:creator">Alice</h3> > ... > </div> > > The above example is invalid because it declares the div having a > prefix of dc: example: > > <dc:div xmlns:dc="http://purl.org/dc/elements/1.1/"> > <h2 property="dc:title">The trouble with Bob</h2> > <h3 property="dc:creator">Alice</h3> > ... > </dc:div> No Martin, that's not how the default namespace (which <div> is in) works. xmlns="..." sets the default namespace, so would have an effect on the meaning of <div>. xmlns:dc="..." sets an explicitly prefixed namespace, so has no effect on the meaning of the <div> element. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250067894.32500.15.camel%40ophelia2.g5n.co.uk Re: Is a Perfect Storm Forming For Distributed Social Networking? 2009-08-12T09:04:54 2009-08-12T09:04:54 2009-08-12T09:04:54 On Wed, 2009-08-12 at 09:46 +0100, Dave Raggett wrote: > * Retaining HTTP based identifiers for resources whilst > using P2P protocols for dereferencing them [...] Much of this list consists of things which the OpenMicroBlogging spec handles pretty well. This is why I'm looking forward to SWXG's talk from Evan Prodromou, whenever that happens. Longer term, I hope SWXG leads to a W3C effor... On Wed, 2009-08-12 at 09:46 +0100, Dave Raggett wrote: > * Retaining HTTP based identifiers for resources whilst > using P2P protocols for dereferencing them [...] Much of this list consists of things which the OpenMicroBlogging spec handles pretty well. This is why I'm looking forward to SWXG's talk from Evan Prodromou, whenever that happens. Longer term, I hope SWXG leads to a W3C effort (a Working Group perhaps) to develop a decentralised social networking protocol - hopefully going beyond just 140 character messages though, and instead allowing content in a wide variety of media types - perhaps using OMB as a jumping off point, and certainly using it as input to the process, along with efforts like Atompub and Linked Data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250077710.32500.45.camel%40ophelia2.g5n.co.uk Re: The "real" reason why xmlns should "not" be used 2009-08-12T11:48:32 2009-08-12T11:48:32 2009-08-12T11:48:32 On Wed, 2009-08-12 at 12:40 +0100, Martin McEvoy wrote: > I am misunderstanding the meaning of this > http://www.validome.org/xml/validate/?lang=en&viewSourceCode=1&url=http://weborganics.co.uk > /test/xhtml-test.xhtml ? Probably. I don't see how that link is even relevant to the topic at hand. It's the validation of an XHTML document against a DTD. The document fails validation because it uses ... On Wed, 2009-08-12 at 12:40 +0100, Martin McEvoy wrote: > I am misunderstanding the meaning of this > http://www.validome.org/xml/validate/?lang=en&viewSourceCode=1&url=http://weborganics.co.uk > /test/xhtml-test.xhtml ? Probably. I don't see how that link is even relevant to the topic at hand. It's the validation of an XHTML document against a DTD. The document fails validation because it uses both an element and an attribute neither of which are defined in the DTD. You would get exactly the same errors if you replaced "xmlns:dc" with "foo-bar" and "dc:div" with "bar-div". The result fails to tell us anything interesting about XML namespaces. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250079205.32500.61.camel%40ophelia2.g5n.co.uk Re: Is a Perfect Storm Forming For Distributed Social Networking? 2009-08-12T12:13:25 2009-08-12T12:13:25 2009-08-12T12:13:25 On Wed, 2009-08-12 at 11:29 +0100, Dave Raggett wrote: > Would you mind expanding on that? I've skimmed the OpenMicroBlogging > spec [1] and it seems to only deal with a means to allow users of > one microblogging service to publish notices to users of another > service, given the other users' permission, and relying upon OAuth. > I don't see how it supports load balancing, for instance. Esse... On Wed, 2009-08-12 at 11:29 +0100, Dave Raggett wrote: > Would you mind expanding on that? I've skimmed the OpenMicroBlogging > spec [1] and it seems to only deal with a means to allow users of > one microblogging service to publish notices to users of another > service, given the other users' permission, and relying upon OAuth. > I don't see how it supports load balancing, for instance. Essentially OMB helps with load balancing gives you distributed profiles - if peoples' profiles are on different servers, then load on one profile doesn't have to effect load on others. Messages end up distributed to more than one server. CiaranG subscribes to my microblog, so my notices can be found in his stream should my own server temporarily disappear <http://micro.ciarang.com/ciarang/all>. The laconica/OMB architecture certainly seems to represent a big improvement over centralised social networks. While individual profiles are not hosted in a P2P manner - each is tied to a particular server - the network as a whole is. > Retaining HTTP based identifiers for resources whilst > using P2P protocols for dereferencing them In the example of my notices on CiaranG's microblog, his installation of laconica knows the full absolute HTTP URI of each of my notices, a full copy of the notice text, and certain data about me, the author of them, so could certainly be used to dereference the URI, maybe not providing the exact same byte-for-byte representation of the resource, but providing something "close enough" (e.g. maybe a different HTML template). > Supporting a mix of social web features, including > traditional SNS, blogs, wikis and messaging (tweets) There is nothing in the OMB draft spec that inherently limits it to messages of 140 characters or less - this is an arbitrary restriction which could easily be lifted. That would allow longer articles, wiki diffs and potentially even full videos to be distributed in a similar manner. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250087356.32500.87.camel%40ophelia2.g5n.co.uk Re: The "real" reason why xmlns should "not" be used 2009-08-12T14:29:16 2009-08-12T14:29:16 2009-08-12T14:29:16 On Wed, 2009-08-12 at 14:10 +0100, Martin McEvoy wrote: > If I remove all the namespace declarations from the example I gave you > there is no problems parsing the document as XML > > http://www.validome.org/xml/validate/?lang=en&viewSourceCode=1&url=http://weborganics.co.uk/test/xhtml-test2.xhtml Yes that document is valid whereas your first one was not, but my point is that the namespace decl... On Wed, 2009-08-12 at 14:10 +0100, Martin McEvoy wrote: > If I remove all the namespace declarations from the example I gave you > there is no problems parsing the document as XML > > http://www.validome.org/xml/validate/?lang=en&viewSourceCode=1&url=http://weborganics.co.uk/test/xhtml-test2.xhtml Yes that document is valid whereas your first one was not, but my point is that the namespace declarations are not the real reason your first document was invalid. The following document, which contains no Dublin Core namespace declaration is equally invalid: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>xhtml test</title> </head> <body> <h1>XHTML test</h1> <div foo-dc="http://purl.org/dc/elements/1.1/"> <h2 property="dc:title">The trouble with Bob</h2> <h3 property="dc:creator">Alice</h3> </div> <bar-div foo-dc="http://purl.org/dc/elements/1.1/"> <h2 property="dc:title">The trouble with Bob</h2> <h3 property="dc:creator">Alice</h3> </bar-div> </body> </html> You see? While the DC namespace declarations in your original example may have triggered the errors you originally saw; the same errors can be triggered without namespace declarations. The errors in your example were entirely caused by the fact that <dc:div> and xmlns:dc are undefined in the RDFa DTD. The former is not a problem as RDFa doesn't use dc:div. The latter is a theoretical problem (see my message entitled "Possible RDFa errata") but rather than being a major issue with RDFa, it highlights the limitation of DTDs as a technology for validating documents that make use of some of the more interesting features XML has to offer, like namespaces - this is presumably one of the reasons that the HTML5 effort has abandoned using DTDs for validation. But none of this has anything to do with your original assertion, which was that the following are equivalent in meaning: <div xmlns:dc="http://purl.org/dc/elements/1.1/"> and: <dc:div xmlns:dc="http://purl.org/dc/elements/1.1/"> In fact, the former example is equivalent to: <xh:div xmlns:xh="http://www.w3.org/1999/xhtml" xmlns:dc="http://purl.org/dc/elements/1.1/"> As can be understood by a thorough reading of the XML namespace document. RDFa does not do anything special that pulls XHTML elements out of the XHTML namespace and puts them into Dublin Core or any other XML namespace. All the elements and attributes defined or used by XHTML+RDFa 1.0 are in the http://www.w3.org/1999/xhtml namespace (with the exception of xml:lang and the xmlns:* attributes themselves). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250087359.32500.89.camel%40ophelia2.g5n.co.uk Possible RDFa errata - 4.1 Document Conformance 2009-08-12T14:29:19 2009-08-12T14:29:19 2009-08-12T14:29:19 4.1 Document Conformance http://www.w3.org/TR/rdfa-syntax/#docconf | A strictly conforming XHTML+RDFa document is a document that requires | only the facilities described as mandatory in this specification. Such | a document satisfies the following criteria: | | 1. The document MUST conform to the constraints expressed in the | schemas in Appendix A - XHTML+RDFa Document Type Definition. However... 4.1 Document Conformance http://www.w3.org/TR/rdfa-syntax/#docconf | A strictly conforming XHTML+RDFa document is a document that requires | only the facilities described as mandatory in this specification. Such | a document satisfies the following criteria: | | 1. The document MUST conform to the constraints expressed in the | schemas in Appendix A - XHTML+RDFa Document Type Definition. However, the DTD given doesn't allow for xmlns:* attributes which are beyond the ability of DTDs to deal with. I propose one of two solutions: 1. Preferred - change the conformance requirement to: "With the exception of xmlns:* attributes, the document MUST conform to the constraints expressed in the schemas in Appendix A - XHTML+RDFa Document Type Definition." The W3C XHTML validator already does this when checking document conformance. 2. Less preferred - drop this criterion and make Appendix A informative. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250088479.32500.92.camel%40ophelia2.g5n.co.uk Re: The "real" reason why xmlns should "not" be used 2009-08-12T14:48:00 2009-08-12T14:48:00 2009-08-12T14:48:00 On Wed, 2009-08-12 at 15:29 +0100, Toby Inkster wrote: > The latter is a theoretical problem (see my message entitled "Possible > RDFa errata") ... on public-rdfa. It wasn't my intention to post these to different lists! http://www.w3.org/mid/1250087359.32500.89.camel@ophelia2.g5n.co.uk -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2009-08-12 at 15:29 +0100, Toby Inkster wrote: > The latter is a theoretical problem (see my message entitled "Possible > RDFa errata") ... on public-rdfa. It wasn't my intention to post these to different lists! http://www.w3.org/mid/1250087359.32500.89.camel@ophelia2.g5n.co.uk -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250091919.32500.98.camel%40ophelia2.g5n.co.uk Re: The "real" reason why xmlns should "not" be used 2009-08-12T15:45:20 2009-08-12T15:45:20 2009-08-12T15:45:20 On Wed, 2009-08-12 at 16:05 +0100, Martin McEvoy wrote: > the error is Attribute "xmlns:dc" must be declared for element type > "div". ie: > > <dc:div xmlns:dc="http://purl.org/dc/elements/1.1/"> > ... > > </dc:div> No, that's not true at all. <div xmlns:dc="http://purl.org/dc/elements/1.1/"> doesn't place <div> into the DC namespace - <div> remains in the expected XHTML namespace. This... On Wed, 2009-08-12 at 16:05 +0100, Martin McEvoy wrote: > the error is Attribute "xmlns:dc" must be declared for element type > "div". ie: > > <dc:div xmlns:dc="http://purl.org/dc/elements/1.1/"> > ... > > </dc:div> No, that's not true at all. <div xmlns:dc="http://purl.org/dc/elements/1.1/"> doesn't place <div> into the DC namespace - <div> remains in the expected XHTML namespace. This is a perfectly legal and proper use of namespaces - it just won't validate properly in DTD-based validators because DTDs can't deal with namespaces (except in a very limited manner). This will be my last message on this matter. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250179188.4698.32.camel%40ophelia2.g5n.co.uk Re: <canvas> and the 2D context API (was RE: Begin discussions for pushing Last Call into 2010) 2009-08-13T15:59:50 2009-08-13T15:59:50 2009-08-13T15:59:50 On Wed, 2009-08-12 at 18:29 -0700, Maciej Stachowiak wrote: > But HTML5 would likely have a normative reference to a Canvas API > spec, so there is a limit. Per W3C rules, you can't normatively > reference a document that's more than one maturity level apart. The solution then seems to be to only include an informative reference. An example of the current draft with just an informative reference to the canvas API might be: http://buzzword.org.uk/2009/html5/the-canvas-element-20090813.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2009-08-12 at 18:29 -0700, Maciej Stachowiak wrote: > But HTML5 would likely have a normative reference to a Canvas API > spec, so there is a limit. Per W3C rules, you can't normatively > reference a document that's more than one maturity level apart. The solution then seems to be to only include an informative reference. An example of the current draft with just an informative reference to the canvas API might be: http://buzzword.org.uk/2009/html5/the-canvas-element-20090813.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B6758BBE-913F-4547-9ECF-ADC747718B5B%40g5n.co.uk Re: who would be interested in working with a Canvas object/2D API separate group 2009-08-13T17:51:39 2009-08-13T17:51:39 2009-08-13T17:51:39 On 13 Aug 2009, at 18:22, Shelley Powers wrote: > except for the issue of whether the change could be informative or > normative, because of the use of ImageData with PostMessage A third option would be for it to be tentatively normative, with a fallback option to an informative reference should it be thought later on that the speed of progress on the 2D API was slowing down progress on HTML5. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 13 Aug 2009, at 18:22, Shelley Powers wrote: > except for the issue of whether the change could be informative or > normative, because of the use of ImageData with PostMessage A third option would be for it to be tentatively normative, with a fallback option to an informative reference should it be thought later on that the speed of progress on the 2D API was slowing down progress on HTML5. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250238254.4698.47.camel%40ophelia2.g5n.co.uk Re: ANN: RDF2RDFa: Turning RDF/XML into Snippets for Copy-and-Paste 2009-08-14T08:24:14 2009-08-14T08:24:14 2009-08-14T08:24:14 On Thu, 2009-08-13 at 23:50 +0200, Martin Hepp (UniBW) wrote: > The tool is available at > http://www.ebusiness-unibw.org/tools/rdf2rdfa/ A few bits of feedback: 1. The contents of the @content attributes don't seem to be properly HTML-escaped. This is especially problematic for literals that contain quote marks. 2. Using the "/>" closing notation for <span> and <div> elements *will not work* i... On Thu, 2009-08-13 at 23:50 +0200, Martin Hepp (UniBW) wrote: > The tool is available at > http://www.ebusiness-unibw.org/tools/rdf2rdfa/ A few bits of feedback: 1. The contents of the @content attributes don't seem to be properly HTML-escaped. This is especially problematic for literals that contain quote marks. 2. Using the "/>" closing notation for <span> and <div> elements *will not work* in real-world browsers unless a page is served with an X(HT)ML MIME type. Use full end tags: <span ...></span>. 3. The generated code seems to nest <div> elements inside <span> elements. This is invalid both in HTML and XHTML. 4. When using the "Convert from URI" form, the tool sends an HTTP Accept header of: "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2". Given that the tool only accepts RDF/XML, this should probably be something like: "application/rdf+xml, application/xml;q=0.1, text/xml;q=0.1". Right now it fails on URIs that are connection negotiated. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250243245.4698.62.camel%40ophelia2.g5n.co.uk Re: ProductDB 2009-08-14T09:47:26 2009-08-14T09:47:26 2009-08-14T09:47:26 On Fri, 2009-08-14 at 10:15 +0100, Ian Davis wrote: > I'm pleased to announce the first release of ProductDB: > http://productdb.org/ Nice. This, I think, would be very useful in conjunction with a few terms to link products to people and organisations. Firstly: where are products available? <http://productdb.org/nokia-n95> :availableFrom <#someShop> . (GoodRelations probably has a term that ... On Fri, 2009-08-14 at 10:15 +0100, Ian Davis wrote: > I'm pleased to announce the first release of ProductDB: > http://productdb.org/ Nice. This, I think, would be very useful in conjunction with a few terms to link products to people and organisations. Firstly: where are products available? <http://productdb.org/nokia-n95> :availableFrom <#someShop> . (GoodRelations probably has a term that can be used here.) Secondly: what do I have? <#me> :hasOneOf <http://productdb.org/nokia-6230i> . Or maybe: <#me> :has [ :isOneOf <http://productdb.org/nokia-6230i> ] . Which is less simple, but allows me to state additional information about the particular phone I have. Thirdly: what do I want? <#me> :wantsOneOf <http://productdb.org/nokia-6230i> . The "firstly" and "thirdly" data combine nicely to allow FOAF files to include "Wishlists" similar to the Wishlist feature on Amazon.com and similar sites. Does anyone know of any vocabs that provide terms like these? If not, shall I add to the VoCampBristol2009 todo list? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/218E6A11-D5C4-4DE7-A833-33406552066E%40g5n.co.uk Re: ProductDB 2009-08-14T14:04:14 2009-08-14T14:04:14 2009-08-14T14:04:14 On 14 Aug 2009, at 14:55, Kingsley Idehen wrote: > FOAF (ground zero for profiles), SIOC (ground zero for data spaces > i.e., data containers and items), and GR (ground zero for products/ > services vendors and buyers) are the 3 critical stools of the Web > of Linked Data! > > On top of the above slap in some SUMO, Yago, WordNet, OpenCyc, and > UMBEL, and what do you have? Exactly what th... On 14 Aug 2009, at 14:55, Kingsley Idehen wrote: > FOAF (ground zero for profiles), SIOC (ground zero for data spaces > i.e., data containers and items), and GR (ground zero for products/ > services vendors and buyers) are the 3 critical stools of the Web > of Linked Data! > > On top of the above slap in some SUMO, Yago, WordNet, OpenCyc, and > UMBEL, and what do you have? Exactly what the cynics claimed wasn't > achievable :-) Pretty useful to add DC Terms to that list - after all, neither FOAF nor SIOC contain a property that allows you to specify the title or date of a foaf:Document or sioc:Item. (Though I suppose it's possible foaf:name could be used for the title.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250263986.4698.104.camel%40ophelia2.g5n.co.uk Re: ProductDB 2009-08-14T15:33:06 2009-08-14T15:33:06 2009-08-14T15:33:06 On Fri, 2009-08-14 at 15:17 +0200, Martin Hepp (UniBW) wrote: > Note that the GoodRelations "seeks" patterns allows using the full > amount of details and the same vocabulary for specifying wish lists > you can say that you are interested in TV sets with at least 11 inches > of screen size etc. So it is not only a simple wish list, but allows > using all features of GoodRelations for the buy side... On Fri, 2009-08-14 at 15:17 +0200, Martin Hepp (UniBW) wrote: > Note that the GoodRelations "seeks" patterns allows using the full > amount of details and the same vocabulary for specifying wish lists > you can say that you are interested in TV sets with at least 11 inches > of screen size etc. So it is not only a simple wish list, but allows > using all features of GoodRelations for the buy side - with the simple > difference of using gr:seeks instead of gr:offers between the > gr:BusinessEntity and the gr:Offering. Aha. I'm not surprised that GoodRelations provides such a relation - it's fairly comprehensive. I'm be a little concerned over it's complexity for common FOAF-like use cases though. There's quite a lot of indirection to get from the foaf:Person to the product they want - in GoodRelations, a person would seek an Offering, which includes a TypeAndQuantityNode which has a type of good which is the end product. So: <#me> gr:seeks [ gr:includesObject [ gr:typeOfGood <#product> ] ] . Really I'd just want something like: <#me> ex:seeks <#product> . Yes, that's not quite as expressive - I can't say how much I'd be willing to pay for it, or how many I want, or in what timeframe I want to buy it, but it's enough for a simple wishlist. ex:seeks could of course be defined in terms of gr:seeks, so that mapping could be done in both directions, but I do think that a simpler term is needed. Then a wishlist becomes as easy as: <> a sioctypes:WishList ; foaf:maker <#me> . <#me> ex:seeks <#product1> , <#product2> , <#product3> . Ian's barter vocab is closer to this, though I think it could be improved by specifying domains and ranges for the terms and generally defining them a little less loosely. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250268056.4698.126.camel%40ophelia2.g5n.co.uk Re: ProductDB 2009-08-14T16:40:57 2009-08-14T16:40:57 2009-08-14T16:40:57 On Fri, 2009-08-14 at 18:12 +0200, Simon Reinhardt wrote: > barter:wants owl:propertyChainAxiom (gr:seeks gr:includesObject > gr:typeOfGood) . owl:propertyChainAxiom = awesome. I really need to take a closer look at OWL2. Without knowing about owl:propertyChainAxiom, I would have suggested N3: { ?person gr:seeks ?off . ?off gr:includesObject ?obj . ?obj gr:typeOfGood ?product . } => { ?person barter:wants ?product . } ; <= { ?person barter:wants ?product . } . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2009-08-14 at 18:12 +0200, Simon Reinhardt wrote: > barter:wants owl:propertyChainAxiom (gr:seeks gr:includesObject > gr:typeOfGood) . owl:propertyChainAxiom = awesome. I really need to take a closer look at OWL2. Without knowing about owl:propertyChainAxiom, I would have suggested N3: { ?person gr:seeks ?off . ?off gr:includesObject ?obj . ?obj gr:typeOfGood ?product . } => { ?person barter:wants ?product . } ; <= { ?person barter:wants ?product . } . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E149931B-239E-4915-B1A4-844C83048852%40g5n.co.uk HTML5 already includes RDFa 2009-08-17T22:05:09 2009-08-17T22:05:09 2009-08-17T22:05:09 In a roundabout way. It allows SVG to be directly used in HTML files: http://dev.w3.org/html5/spec/the-canvas-element.html#svg ... references SVG Tiny 1.2 http://dev.w3.org/html5/spec/references.html#refsSVG ... which in turn includes all of the RDFa attributes. http://www.w3.org/TR/SVGTiny12/metadata.html#MetadataAttributes -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> In a roundabout way. It allows SVG to be directly used in HTML files: http://dev.w3.org/html5/spec/the-canvas-element.html#svg ... references SVG Tiny 1.2 http://dev.w3.org/html5/spec/references.html#refsSVG ... which in turn includes all of the RDFa attributes. http://www.w3.org/TR/SVGTiny12/metadata.html#MetadataAttributes -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250681978.14859.5.camel%40ophelia2.g5n.co.uk Re: data.gov now live with RDFa 2009-08-19T11:39:39 2009-08-19T11:39:39 2009-08-19T11:39:39 On Wed, 2009-08-19 at 06:50 -0400, rick wrote: > http://www.data.gov/ > The page has two triples. Ten by my count. The namespace for Dublin Core is wrong though. It's currently pointed at <http://dublincore.org/documents/2008/01/14/dcmi-terms/> which is a documentation file. The namespace should be one of: http://purl.org/dc/terms/ http://purl.org/dc/elements/1.1/ http://purl.org/dc/eleme... On Wed, 2009-08-19 at 06:50 -0400, rick wrote: > http://www.data.gov/ > The page has two triples. Ten by my count. The namespace for Dublin Core is wrong though. It's currently pointed at <http://dublincore.org/documents/2008/01/14/dcmi-terms/> which is a documentation file. The namespace should be one of: http://purl.org/dc/terms/ http://purl.org/dc/elements/1.1/ http://purl.org/dc/elements/1.0/ Looking at how Dublin Core is being used on the page -- in particular, literals for dc:creator and dc:publisher -- I'd suggest using the older <http://purl.org/dc/elements/1.1/> namespace URI. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250764369.7016.17.camel%40ophelia2.g5n.co.uk Re: Top three levels of Dewey Decimal Classification published as linked data 2009-08-20T10:32:50 2009-08-20T10:32:50 2009-08-20T10:32:50 On Wed, 2009-08-19 at 14:27 -0400, Panzer,Michael wrote: > I would like to announce the availability of the DDC Summaries as a > linked data service that uses SKOS and other vocabularies for > representation [1]. Please take a look if you like. Comments, > suggestions, and advice are really appreciated! Hurrah! I was looking for linked data URIs for the Dewey Decimal Classification a few months ... On Wed, 2009-08-19 at 14:27 -0400, Panzer,Michael wrote: > I would like to announce the availability of the DDC Summaries as a > linked data service that uses SKOS and other vocabularies for > representation [1]. Please take a look if you like. Comments, > suggestions, and advice are really appreciated! Hurrah! I was looking for linked data URIs for the Dewey Decimal Classification a few months ago, and while I eventually found <info:ddc/22/eng//641>, these aren't very "linked data" as they're not dereferencable via HTTP. So I set up my own, in the format: <http://purl.org/NET/decimalised#c470> The data is available in RDF/XML and N-Triples with a subset in XHTML +RDFa, all content negotiated. I've called my data the "Decimalised Database of Concepts" to reflect the fact that the information shouldn't be treated as necessarily exactly the same as official Dewey Decimal Classification concepts. It includes SKOS "relatedMatch" mappings to DBpedia and "closeMatch" mappings to LCSH and LCCO in many cases. In light of your announcement yesterday, I've added "exactMatch" mappings to dewey.info's URIs too. I don't know if this information or the mappings are any use to you. It's available under CC-BY-SA, which is not especially compatible with the CC-BY-NC-ND license used by dewey.info, but given that the vast majority of my data comes from Wikipedia, I don't really have the choice of publishing it under a different license. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250847329.24397.0.camel%40ophelia2.g5n.co.uk http://www.w3.org/1999/xhtml/vocab#itsRules 2009-08-21T09:35:29 2009-08-21T09:35:29 2009-08-21T09:35:29 The textual content of this <dt> element is wrong. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> The textual content of this <dt> element is wrong. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250856874.24397.13.camel%40ophelia2.g5n.co.uk Media types for RDF. 2009-08-21T12:14:34 2009-08-21T12:14:34 2009-08-21T12:14:34 The question of proper, official media types for various serialisations of RDF came up on #swig (IRC) again today. What needs to be done to progress the registration of "text/n3" and "text/turtle" which was discussed back in 2007/2008? http://www.w3.org/2008/01/rdf-media-types Right now the situation's a mess. The media types used by publishers, and supported by consumers, are of such a varie... The question of proper, official media types for various serialisations of RDF came up on #swig (IRC) again today. What needs to be done to progress the registration of "text/n3" and "text/turtle" which was discussed back in 2007/2008? http://www.w3.org/2008/01/rdf-media-types Right now the situation's a mess. The media types used by publishers, and supported by consumers, are of such a variety that content negotiation between them ends up as a lucky dip. I am surprised at the lack of momentum for getting these standardised. Once the registration is official, we should also submit a patch to the Apache httpd project to get common file suffixes for RDF serialisations into the Apache default configuration files. Currently ".rdf" is there for RDF/XML. It would be handy to add: AddType application/rdf+xml .owl AddType text/n3 .n3 AddType text/turtle .ttl AddType text/plain .nt # Or maybe use text/turtle here too? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250864948.24397.28.camel%40ophelia2.g5n.co.uk Fingerpoint - a proposed alternative to Webfinger 2009-08-21T14:29:09 2009-08-21T14:29:09 2009-08-21T14:29:09 Fingerpoint is an alternative draft specification offering much the same facilities as Webfinger. The current draft spec can be found at: http://buzzword.org.uk/2009/fingerpoint/spec I think it offers the following advantages over Webfinger: 1. Minimal reinvention. Fingerpoint reuses FOAF for descriptions of people, and reuses the W3C SPARQL Query Language for searching for their information. I... Fingerpoint is an alternative draft specification offering much the same facilities as Webfinger. The current draft spec can be found at: http://buzzword.org.uk/2009/fingerpoint/spec I think it offers the following advantages over Webfinger: 1. Minimal reinvention. Fingerpoint reuses FOAF for descriptions of people, and reuses the W3C SPARQL Query Language for searching for their information. It uses Mark Nottingham's Web Linking draft for discovery. 2. Integration with the world of Linked Data. 3. It's very easy to set up a small-scale Fingerpoint service - no programming knowledge needed! A basic command-line client for Fingerpoint can be found at: http://buzzword.org.uk/2009/fingerpoint/FingerpointClient.pl To run it you type: FingerpointClient.pl account@example.com To show how easy it is to set up a fingerpoint service, I've set one up here: http://fingerpoint.tobyinkster.co.uk/ Note that no fancy .htaccess tricks are required, no PHP, no programming at all. It can be implemented easily on a cheap host that just serves up static files. (Though there are scalability advantages if you can run your own SPARQL endpoint.) To try it out, install the FingerpointClient.pl client and try fingering the following identifiers: me@fingerpoint.tobyinkster.co.uk somebody@fingerpoint.tobyinkster.co.uk mail@tobyinkster.co.uk -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1250865085.24397.30.camel%40ophelia2.g5n.co.uk Fingerpoint - a proposed alternative to Webfinger 2009-08-21T14:31:25 2009-08-21T14:31:25 2009-08-21T14:31:25 Fingerpoint is an alternative draft specification offering much the same facilities as Webfinger. The current draft spec can be found at: http://buzzword.org.uk/2009/fingerpoint/spec I think it offers the following advantages over Webfinger: 1. Minimal reinvention. Fingerpoint reuses FOAF for descriptions of people, and reuses the W3C SPARQL Query Language for searching for their information. I... Fingerpoint is an alternative draft specification offering much the same facilities as Webfinger. The current draft spec can be found at: http://buzzword.org.uk/2009/fingerpoint/spec I think it offers the following advantages over Webfinger: 1. Minimal reinvention. Fingerpoint reuses FOAF for descriptions of people, and reuses the W3C SPARQL Query Language for searching for their information. It uses Mark Nottingham's Web Linking draft for discovery. 2. Integration with the world of Linked Data. 3. It's very easy to set up a small-scale Fingerpoint service - no programming knowledge needed! A basic command-line client for Fingerpoint can be found at: http://buzzword.org.uk/2009/fingerpoint/FingerpointClient.pl To run it you type: FingerpointClient.pl account@example.com To show how easy it is to set up a fingerpoint service, I've set one up here: http://fingerpoint.tobyinkster.co.uk/ Note that no fancy .htaccess tricks are required, no PHP, no programming at all. It can be implemented easily on a cheap host that just serves up static files. (Though there are scalability advantages if you can run your own SPARQL endpoint.) To try it out, install the FingerpointClient.pl client and try fingering the following identifiers: me@fingerpoint.tobyinkster.co.uk somebody@fingerpoint.tobyinkster.co.uk mail@tobyinkster.co.uk -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/007EDE3D-F566-43A9-9CD0-73CC86B48402%40g5n.co.uk Re: Please Specify Behavior for @rel="next | prev" 2009-08-23T15:36:05 2009-08-23T15:36:05 2009-08-23T15:36:05 On 23 Aug 2009, at 14:00, Karl Dubost wrote: > * Opera implements it in View > Toolbars > Navigation > (still available in 10. just tested it.) Pretty sure that Opera's "fast forward" feature uses rel=next too. That said, I agree with Maciej that the specification should not mandate browser behaviour in this area. I would hope that instead most browser vendors would independently decide that such features are helpful. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> <html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 23 Aug 2009, at 14:00, Karl Dubost wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">* Opera implements it in View &gt; Toolbars &gt; Navigation</font></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><span class="Apple-converted-space">&nbsp; </span>(still available in 10. just tested it.)</font></p> </blockquote></div><br><div>Pretty sure that Opera's "fast forward" feature uses rel=next too.</div><div><br></div><div>That said, I agree with&nbsp;Maciej that the specification should not mandate browser behaviour in this area. I would hope that instead most browser vendors would independently decide that such features are helpful.</div><br><div> <div>--&nbsp;</div><div>Toby A Inkster</div><div>&lt;<a href="mailto:mail@tobyinkster.co.uk">mailto:mail@tobyinkster.co.uk</a>&gt;</div><div>&lt;<a href="http://tobyinkster.co.uk">http://tobyinkster.co.uk</a>&gt;</div><div><br></div></div></body></html> On 23 Aug 2009, at 14:00, Karl Dubost wrote: > * Opera implements it in View > Toolbars > Navigation > (still available in 10. just tested it.) Pretty sure that Opera's "fast forward" feature uses rel=next too. That said, I agree with Maciej that the specification should not mandate browser behaviour in this area. I would hope that instead most browser vendors would independently decide that such features are helpful. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6742AF7A-8F3A-4C9F-8462-62C3FF7EA012%40g5n.co.uk HTML 4.02 2009-08-23T17:44:09 2009-08-23T17:44:09 2009-08-23T17:44:09 The HTML 4.02 specification is here: http://doctype.be/402.html It's 13 lines long, including the heading. Features: * RDFa * ARIA * Ruby * a few other nice bits from other (X)HTML specs * DTD validation (though doesn't cope with xmlns:*) Any valid HTML 4.01 Strict document can become an HTML 4.02 document by just changing the doctype. What do people think? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> <html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div>The HTML 4.02 specification is here:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://doctype.be/402.html">http://doctype.be/402.html</a></div><div><br></div><div>It's 13 lines long, including the heading.</div><div><br></div><div>Features:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* RDFa<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* ARIA<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* Ruby<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* a few other nice bits from other (X)HTML specs<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* DTD validation (though doesn't cope with xmlns:*)<br></div><div><br></div><div>Any valid HTML 4.01 Strict document can become an HTML 4.02 document by just changing the doctype.</div><div><br></div><div>What do people think?</div><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>--&nbsp;</div><div>Toby A Inkster</div><div>&lt;<a href="mailto:mail@tobyinkster.co.uk">mailto:mail@tobyinkster.co.uk</a>&gt;</div><div>&lt;<a href="http://tobyinkster.co.uk">http://tobyinkster.co.uk</a>&gt;</div><div><br class="webkit-block-placeholder"></div></span><br class="Apple-interchange-newline"> </div><br></body></html> The HTML 4.02 specification is here: http://doctype.be/402.html It's 13 lines long, including the heading. Features: * RDFa * ARIA * Ruby * a few other nice bits from other (X)HTML specs * DTD validation (though doesn't cope with xmlns:*) Any valid HTML 4.01 Strict document can become an HTML 4.02 document by just changing the doctype. What do people think? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/33FD699C-D951-47F0-AFD6-2A916B4445E4%40g5n.co.uk Re: HTML 4.02 2009-08-23T22:42:56 2009-08-23T22:42:56 2009-08-23T22:42:56 I'm not answering all questions, but here are some answers: On 23 Aug 2009, at 20:04, Tab Atkins Jr. wrote: > To be fair, that's only because you've left out some things that would > be necessary to actually have an unambiguous, coherent spec. Certainly it could do with beefing up a bit, but I have neither the time nor the inclination. However, if you consider the links to be normative refer... I'm not answering all questions, but here are some answers: On 23 Aug 2009, at 20:04, Tab Atkins Jr. wrote: > To be fair, that's only because you've left out some things that would > be necessary to actually have an unambiguous, coherent spec. Certainly it could do with beefing up a bit, but I have neither the time nor the inclination. However, if you consider the links to be normative references, it's actually quite usable as a spec. > What problems are being solved by these nice bits? What criteria did > you have for what to include and exclude? Criteria: I included stuff I liked and did not include stuff I did not like. I did originally plan to run a survey on what should go in and what should stay out, and although I finished writing the survey, never got around to writing it. Yes, this is a somewhat autocratic method for writing a specification, but I'm not proposing that the W3C publish HTML 4.02 as a Recommendation tomorrow. Personally, I like it, and am already using it in some places. It already "just works", so I'm perfectly happy for it to be ignored if there is no interest in developing it further - it more or less fulfils my need as it is. > So can it be DTD validated or not? If not, is there any real benefit > from having it be DTD-validatable only sometimes? If not, is there > any benefit in having the DTD at all? A subset of HTML 4.02 documents can be validated against the DTD. If the validator is tweaked to ignore xmlns:* attributes, then all HTML 4.02 documents can. This tweak is already present in the W3C validator, but only enabled for XHTML documents. Line 3132 is where the magic happens: http://dev.w3.org/cvsweb/validator/httpd/cgi-bin/check?rev=1.680 That said, the xmlns:* issue is, I consider, the biggest open issue with it. The @prefix attribute is a hint at a possible solution - it has been proposed that RDFa (which is the main use case for xmlns:* attributes) could use this attribute as an alternative for CURIE prefix definitions. At least two implementations already support this. Laura Carlson wrote: > Karl Dubost previously mentioned doing an html 4.2 or 4.5: Kornel Lesinski wrote: > Douglas Crockfor has called for HTML 4.2 that's "stable and reliable" Indeed. For a long time I've thought HTML5 needs to scale back its efforts. A lot of the stuff that's going on as part of the HTML5 effort is great stuff, and no doubt very useful, but it's not necessarily stuff that should end up in the specification for a markup language. > That however depends on definition of "works". Should it be > "doesn't break badly" or "browser implements it [partially | > fully]"? e.g. does <section> "work" in IE6? Does Ruby "work" in Opera? Varying definitions of "work". Nothing breaks too much. <section> is not included in HTML 4.02. Ruby is included, and using <rp> elements can be made to degrade very gracefully in browsers that don't support it. > I'm not sure whether subset you've chosen is the best (and probably > exact subset is going to be hard to agree on...) > Why add target, but not <ol start>? <ol start> should probably be in there actually. I'll maybe add that tomorrow. > There are other features that work today and could be included, > e.g. <input autocomplete>, <meta charset> and APIs like innerHTML. <input autocomplete="off"> works today, so could theoretically be included. But I don't like it, so it doesn't meet my primary inclusion criteria (which is that stuff I don't like isn't included). <meta charset> doesn't seem to solve an actual problem. DOM APIs I do not consider to be part of the markup language. Robert J Burns wrote: > Ian Hickson and the WhatWG have shown they have no interest in the > needs of authors and users but only the needs of the anointed > browser vendors I somewhat agree with this sentiment. For every browser vendor reading the HTML5 spec, there's going to be a thousand page authors. I've been saying for a couple of years or more that HTML5 is far too skewed towards what implementers need. An HTML specification should define what the elements and attributes are called, what they mean, where they are allowed to be used, and precious little else. If necessary, an implementation guide could be produced separately and informatively referenced. A final thought before I go to bed. Why should people use HTML 4.02? Because it's more or less the same as good old HTML 4.01 Strict that you're used to, but with better accessibility (ARIA), better metadata facilities (RDFa, plus the <time> element which solves a big Microformat accessibility problem), better internationalisation (Ruby) and a doctype tag you can probably remember without having to look up. -Toby http://tobyinkster.co.uk/message/1251107833.3069.6.camel%40ophelia2.g5n.co.uk Re: RDFa usage for SKOS applications 2009-08-24T09:57:14 2009-08-24T09:57:14 2009-08-24T09:57:14 On Mon, 2009-08-24 at 11:43 +0200, Ivan Herman wrote: > One area where RDFa is increasingly used is when major subject > hierarchies are encoded into SKOS I use RDFa and SKOS for: http://purl.org/NET/decimalised.html The RDFa deliberately contains less data than the accompanying RDF/XML file though, in order to keep the file size down. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2009-08-24 at 11:43 +0200, Ivan Herman wrote: > One area where RDFa is increasingly used is when major subject > hierarchies are encoded into SKOS I use RDFa and SKOS for: http://purl.org/NET/decimalised.html The RDFa deliberately contains less data than the accompanying RDF/XML file though, in order to keep the file size down. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251196810.3069.43.camel%40ophelia2.g5n.co.uk SPARQL Query Problem - perhaps solvable in 1.1? 2009-08-25T10:40:10 2009-08-25T10:40:10 2009-08-25T10:40:10 OK, I've hit up against a problem which at first reading, sounds simple enough, but I'm pretty sure is unsolvable in SPARQL 1.0. I'll outline this problem below. Any suggestions as to how it can be solved in SPARQL 1.0 would be gratefully received. But if you're as convinced as I am that it's unsolvable, I also have a suggested feature for SPARQL 1.1 that should solve it. So the problem. I'm coll... OK, I've hit up against a problem which at first reading, sounds simple enough, but I'm pretty sure is unsolvable in SPARQL 1.0. I'll outline this problem below. Any suggestions as to how it can be solved in SPARQL 1.0 would be gratefully received. But if you're as convinced as I am that it's unsolvable, I also have a suggested feature for SPARQL 1.1 that should solve it. So the problem. I'm collecting a bunch of RSS feeds into a triple store and trying to create a single list of articles from them. I need to be able to filter the list by date range and order it by date. The people behind the RSS 1.0 spec (in their infinite wisdom) decided that a date property would not be needed, so RSS feeds will typically contain a mixed bag of different properties that could describe the publication date of the items. I'm focusing on the following four: <http://purl.org/dc/terms/created> <http://purl.org/dc/terms/issued> <http://purl.org/dc/terms/date> <http://purl.org/dc/elements/1.1/date> When an RSS item has a dcterms:created date, then I essentially want to treat that as authoritative and ignore everything else. If there is no dcterms:created, then I'd fall back to dcterms:issued, treating that as authoritative and ignoring the other two terms, and so on. Filtering for a date range - say, all the items published in 2008 - is pretty tricky, but is achievable. My solution is to bind each date to a different variable (dcterms:created is ?date1, dcterms:issued is ?date2, etc) in OPTIONAL clauses and then do a filter like this: FILTER ( (bound(?date1) && inRange(?date1)) || (!bound(?date1) && bound(?date2) && inRange(?date2))  || (!bound(?date1) && !bound(?date2) && bound(?date3) && inRange(?date3)) || (!bound(?date1) && !bound(?date2) && !bound(?date3) && bound(?date4) && inRange(?date4)) ) where "inRange" in the above pseudo-code actually represents some xsd:dateTime type casts and greater-than and less-than comparisons. This is ugly, yes, but it works. A lot of the complicatedness comes from the fact that the date property found first in my order of priorities needs to be treated as completely authoritative. So that, for example, if an item has dcterms:created only in 2007, then when filtering for items in 2008, that item will not be found, even if it has dcterms:issued, dcterms:date and dc:date properties all with values in 2008! Anyway, as I said, this is ugly, but it works. However, results are of course returned in no particular order. Right now, I pull these results into my application and sort them into date order there. But I'd like the SPARQL query engine to take care of the sorting itself - in particular, that way I'd be able to get the query engine to apply any LIMIT and OFFSET I wanted, saving a lot of communications overhead between the query engine and the application in the case where, say, there are 500 matching items but I only want the first 10 ordered by date. Michael Hausenblas on #swig suggested a solution which at first glance looks like it might work, and looks really easy: ORDER BY (?date1 || ?date2 || ?date3 || ?date4) However, this doesn't work, as the || operator seems to always return an xsd:boolean - not (as is the case in many other programming languages) the first non-false literal value that was passed to it. I'm fairly convinced that ordering my results is not possible without breaking my filter. If you need some test data to play with, I've put some here: http://buzzword.org.uk/2009/sparql-test-data-1.ttl The expected results should be :inRange4, :inRange3, :inRange2 and :inRange1 - in that order. A very simple solution, which would solve the ordering problem (and also greatly simplify the filter) would be for SPARQL to borrow the COALESCE function from SQL. For those not familiar with COALESCE, it takes a variable number of arguments, and returns the first of those arguments which is not null. (In the SPARQL case, it would be the first which is bound.) That would make my filter as simple as: FILTER (inRange(COALESCE(?date1,?date2,?date3,?date4))) And my sorting as easy as: ORDER BY (COALESCE(?date1,?date2,?date3,?date4)) Failing that, even an if-then-else tertiary operator would be useful: ORDER BY ( if bound(?date1) then ?date1 else ( if bound(?date2) ... ) ) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251205246.3069.77.camel%40ophelia2.g5n.co.uk Re: SPARQL Query Problem - perhaps solvable in 1.1? 2009-08-25T13:00:49 2009-08-25T13:00:49 2009-08-25T13:00:49 On Tue, 2009-08-25 at 08:45 -0400, Lee Feigenbaum wrote: > If I understand you correctly, the pattern you're looking for is that > you have a prioritized list of predicates that you want to use for a > particular value, in this case date. The "canonical" way to do this in > SPARQL (or, at least, what I've always done and seen done) is to use a > series of OPTIONAL clauses that all bind to the... On Tue, 2009-08-25 at 08:45 -0400, Lee Feigenbaum wrote: > If I understand you correctly, the pattern you're looking for is that > you have a prioritized list of predicates that you want to use for a > particular value, in this case date. The "canonical" way to do this in > SPARQL (or, at least, what I've always done and seen done) is to use a > series of OPTIONAL clauses that all bind to the same variable: > > SELECT ?date { > ?item a ex:Item . > OPTIONAL { ?item dct:created ?date } > OPTIONAL { ?item dct:issued ?date } > OPTIONAL { ?item dct:date ?date } > OPTIONAL { ?item dc:date ?date } > } ORDER BY ?date Wow! That actually seems to work! How did I not spot this? It means I lose out on knowing which of the predicates worked, so I can't perfectly reconstruct the original triples in my application. But that, I think I can live with. Nevertheless I think a COALESCE function would still be a useful addition to SPARQL 1.1. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/08EC5D64-6224-4A04-AA51-F25889DCEE2F%40g5n.co.uk Re: HTML 4.02 2009-08-25T23:39:21 2009-08-25T23:39:21 2009-08-25T23:39:21 On 24 Aug 2009, at 22:20, Robert J Burns wrote: > To avoid the same autocratic problems the WG already suffers under, > it would be nice to say a bit why you don't like autocomplete. If > it is your own personal spec, the autocratic method is fine, but if > you want a community of authors to adopt it, you should at least > meet that community half way. As I said, I created it as a spec t... On 24 Aug 2009, at 22:20, Robert J Burns wrote: > To avoid the same autocratic problems the WG already suffers under, > it would be nice to say a bit why you don't like autocomplete. If > it is your own personal spec, the autocratic method is fine, but if > you want a community of authors to adopt it, you should at least > meet that community half way. As I said, I created it as a spec that I'd want to use. If other people want to use it, that's great, but if I'm the only one, then that's OK too. As to why I don't like the autocomplete attribute - its sole purpose is to disable a very user-friendly feature. If banks and the like want to use autocomplete="off" then that's their choice, but that doesn't mean it has to validate. > One question about the doctype declaration. Is it a standards mode > invoking declaration? If browsers see a doctype that they've never heard of, they tend to default to standards mode. I guess they think "you're doing something complicated, so I'll assume you know what you're doing!" The HTML 4.02 doctype tag triggers standards mode everywhere I've checked. Tab Atkins Jr wrote: > For example, does any major browser implement <script implements>? If > so, how do you use it? I'm really not sure. I don't think any do. Lack of support hasn't caused me any problems *yet*. It may be possible to implement support for @implements using Javascript itself. > Similar, is <access> or @inputmode implemented anywhere? @inputmode is mostly intended for mobile browsers, so it's not surprising that support is not found in any desktop browsers. It's supported in the Blackberry browser I'm told. Plus the Opera core engine supports it, though this support is switched off in the desktop version of Opera. I don't think <access> is implemented anywhere, but it is certainly a good candidate to implement in Javascript and run as a user script (e.g. Greasemonkey for Mozilla) or embed on a page. > If you're including <time>, are you including all the things that are > referred to in its section in the HTML5 spec? The HTML 4.02 DTD includes a <time> element which has the same content model as any normal phrase element such as <span>. The only difference is that it includes a @datetime attribute. > Without any sort of even vaguely objective criteria, though, how are > we supposed to know if these solve any relevant problems? I don't see why a vaguely objective criteria for having ruled things in or out of HTML 4.02 is a prerequisite for analysing whether HTML 4.02 solves a given document markup problem. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251285920.3378.47.camel%40ophelia2.g5n.co.uk [ACTION-56 CLOSED] User Story: Business Advantages of Open Protocols 2009-08-26T11:25:20 2009-08-26T11:25:20 2009-08-26T11:25:20 I have an action to write up this user story. With this e-mail, I consider is closed. I'm posting this to the mailing list instead of adding to Wiki because I know Henry is in the middle of overhauling the stories on the Wiki. = User Story: Business Advantages of Open Protocols = == Goal == Isaac wants to get as many people to join Social Network X as possible. == Summary == Isaac has recentl... I have an action to write up this user story. With this e-mail, I consider is closed. I'm posting this to the mailing list instead of adding to Wiki because I know Henry is in the middle of overhauling the stories on the Wiki. = User Story: Business Advantages of Open Protocols = == Goal == Isaac wants to get as many people to join Social Network X as possible. == Summary == Isaac has recently started a new social networking site (Social Network X) where people review hamster cages socially. At a barbecue he meets a few friends of friends who have heard of his site and thought it an interesting idea, but not use the site. Alice explains that she is tired of typing in the same details (name, e-mail, age, location, etc) every time she wants to use a new social site, then waiting for a confirmation e-mail to click on. She had tried to join Social Network X a few days ago, but only got as far as filling in two fields before her hamster started screaming and she needed to urgently care for it. She never ended up completing the sign-up process. Bob explains that he did manage to sign up and tried adding his friend Alice to his list of trusted cage reviewers (i.e. "buddies list"), but couldn't find her. He also wanted to find out which of his hundreds of friends from Social Network B were also signed up for Social Network X, but didn't want to search for each one manually. Carol says she considered signing up to his site, but wanted to make sure she'd be able to get her data back out again, so that she could mirror her own reviews on her personal blog. Isaac realises that by implementing open protocols for importing and exporting data, he can reduce these barriers to entry and sign up more people to his site, hence sell more advertising to hamster cage manufacturers. == Actors == * Alice, a user of Social Network A * Bob, a user of Social Network B * Carol * Isaac, the owner of Social Network X == Preconditions == * Alice and Bob are friends * The three social networks have no prior knowledge. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CA975176-7A08-4280-B100-C056E677BA42%40g5n.co.uk Re: SPARQL performance for ORDER BY on large datasets 2009-08-27T08:01:51 2009-08-27T08:01:51 2009-08-27T08:01:51 On 26 Aug 2009, at 23:11, Seaborne, Andy wrote: > Talking of data validity - in the data, all the timezones, > regardless of time of year, are -04:00, which is a strangeness. According to Wikipedia there are 22 places (i.e. countries or parts of countries) that use UTC-4 all year round (i.e. don't observe daylight saving). These include Barbados, Aruba and Bolivia and parts of Brazil and... On 26 Aug 2009, at 23:11, Seaborne, Andy wrote: > Talking of data validity - in the data, all the timezones, > regardless of time of year, are -04:00, which is a strangeness. According to Wikipedia there are 22 places (i.e. countries or parts of countries) that use UTC-4 all year round (i.e. don't observe daylight saving). These include Barbados, Aruba and Bolivia and parts of Brazil and Canada. Given that the data comes from the Library of Congress, one would expect it to be formatted to a timezone used in part of the USA, so I humbly offer Puerto Rico and the US Virgin Islands which also use UTC-4 all year round. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251373249.3378.76.camel%40ophelia2.g5n.co.uk Using Google's Rich Snippets testing tool to test their RDFa support 2009-08-27T11:40:50 2009-08-27T11:40:50 2009-08-27T11:40:50 http://www.google.com/webmasters/tools/richsnippets?url=http%3A%2F%2Ftobyinkster.co.uk%2F 1. It seems to complain about various rel and property attributes being "found outside typeof". This suggests that they don't have a proper way of determining the subject of a triple. 2. Although they only advertise support for their own vocabulary, they seem to pick up all properties associated with any re... http://www.google.com/webmasters/tools/richsnippets?url=http%3A%2F%2Ftobyinkster.co.uk%2F 1. It seems to complain about various rel and property attributes being "found outside typeof". This suggests that they don't have a proper way of determining the subject of a triple. 2. Although they only advertise support for their own vocabulary, they seem to pick up all properties associated with any resource which has a typeof attribute. 3. They seem to ignore the "content" attribute. Dear Google, please, please parse RDFa using the algorithm published in the RDFa syntax specification. A suitably talented coder can probably implement it in an afternoon. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8495F95E-393C-4706-943B-E6738F10A5B6%40g5n.co.uk Re: Undeclared prefix in @datatype -- what happens? 2009-08-27T18:09:42 2009-08-27T18:09:42 2009-08-27T18:09:42 On 27 Aug 2009, at 16:43, Richard Cyganiak wrote: > Of course I could just read the spec, but I imagine that some kind > soul on this list who is already familiar with the spec can find > out the answer much faster than me ... The spec doesn't specify this. If there were a definitive answer, it would be step #9 in the processing sequence. My vote, if this were to be written up as an erra... On 27 Aug 2009, at 16:43, Richard Cyganiak wrote: > Of course I could just read the spec, but I imagine that some kind > soul on this list who is already familiar with the spec can find > out the answer much faster than me ... The spec doesn't specify this. If there were a definitive answer, it would be step #9 in the processing sequence. My vote, if this were to be written up as an errata, would be to specify that if @datatype is non-empty but does not contain a valid CURIE, to treat it as datatype="" - i.e. the value of the attribute is ignored but the presence of the attribute is not ignored. This would be consistent with non-CURIE rel, rev, typeof, etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/19917CAE-FB5C-4882-B03E-8BEA5DDDF752%40g5n.co.uk Re: Undeclared prefix in @datatype -- what happens? 2009-08-27T20:19:18 2009-08-27T20:19:18 2009-08-27T20:19:18 On 27 Aug 2009, at 21:05, Shane McCarron wrote: > When @datatype is made up of only illegal values, my belief is that > it should be treated as empty. It should only ever contain one value. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 27 Aug 2009, at 21:05, Shane McCarron wrote: > When @datatype is made up of only illegal values, my belief is that > it should be treated as empty. It should only ever contain one value. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251456202.2394.63.camel%40ophelia2.g5n.co.uk Re: Proposal: <content> element 2009-08-28T10:43:23 2009-08-28T10:43:23 2009-08-28T10:43:23 On Fri, 2009-08-28 at 10:19 +0100, Steven Faulkner wrote: > 3. while currently role="contentinfo" does not have an authoring > restriction like role="banner", i believe this is an oversight, and it > should have. I disagree. My homepage (link in sig) uses role="contentinfo" for three distinct elements. 1. A list of tags for the primary content of the page. 2. A table of metadata (e.g. author, cr... On Fri, 2009-08-28 at 10:19 +0100, Steven Faulkner wrote: > 3. while currently role="contentinfo" does not have an authoring > restriction like role="banner", i believe this is an oversight, and it > should have. I disagree. My homepage (link in sig) uses role="contentinfo" for three distinct elements. 1. A list of tags for the primary content of the page. 2. A table of metadata (e.g. author, created date, modified date) for the primary content of the page. 3. A footer containing a link to the CMS software that serves the page. I think each of these matches the ARIA definition of "metadata that applies to the parent document". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251457061.2394.75.camel%40ophelia2.g5n.co.uk Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 2009-08-28T10:57:41 2009-08-28T10:57:41 2009-08-28T10:57:41 On Fri, 2009-08-28 at 11:03 +0200, Julian Reschke wrote: > Well, in that case HTML5 is unsuitable as the *only* specification > referenced by the text/html media type registration. Perhaps the media type registration could use something like the following: """ The following is a non-exhaustive list of specifications and recommendations for various versions of the HTML and XHTML language which c... On Fri, 2009-08-28 at 11:03 +0200, Julian Reschke wrote: > Well, in that case HTML5 is unsuitable as the *only* specification > referenced by the text/html media type registration. Perhaps the media type registration could use something like the following: """ The following is a non-exhaustive list of specifications and recommendations for various versions of the HTML and XHTML language which carry the media type "text/html": HTML 2.0 <http://www.ietf.org/rfc/rfc1866.txt> HTML 3.2 <http://www.w3.org/TR/REC-html32> HTML 4.0 <http://www.w3.org/TR/1998/REC-html40-19980424/> HTML 4.01 <http://www.w3.org/TR/html401> XHTML 1.0* <http://www.w3.org/TR/xhtml1> XHTML 1.1* <http://www.w3.org/TR/xhtml11> HTML 5 <http://www.w3.org/TR/html5> [ * a subset of XHTML documents is suitable as "text/html". The primary media type for these documents is "application/xhtml+xml". ] Publishers MAY serve a document conforming to any of the above specifications as "text/html". In the absence of version indicators, consumers SHOULD assume that the document is authored to the HTML5 specification. Even in the presence of version indicators to the contrary, consumers MAY treat the document as if it were authored to the HTML5 specification. """ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251457971.2394.80.camel%40ophelia2.g5n.co.uk Re: Proposal: <content> element 2009-08-28T11:12:51 2009-08-28T11:12:51 2009-08-28T11:12:51 On Fri, 2009-08-28 at 11:58 +0100, Steven Faulkner wrote: > would you mark each of these items as a <footer>? If I were using HTML5, I would consider the last of the three suitable for <footer>. For the other two, any of HTML5's predefined sectioning/header/footer elements would probably be a bit of a stretch semantically, hence <div role="contentinfo">. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2009-08-28 at 11:58 +0100, Steven Faulkner wrote: > would you mark each of these items as a <footer>? If I were using HTML5, I would consider the last of the three suitable for <footer>. For the other two, any of HTML5's predefined sectioning/header/footer elements would probably be a bit of a stretch semantically, hence <div role="contentinfo">. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251460355.2394.84.camel%40ophelia2.g5n.co.uk FriendFeed's sale to Facebook [was Re: Is a Perfect Storm Forming For Distributed Social Networking?] 2009-08-28T11:52:38 2009-08-28T11:52:38 2009-08-28T11:52:38 On Wed, 2009-08-12 at 10:12 +0200, Melvin Carvalho wrote: > FriendFeed's sale to Facebook FriendFeed have apparently now disabled their FOAF output. <http://identi.ca/notice/9001608> :-( -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2009-08-12 at 10:12 +0200, Melvin Carvalho wrote: > FriendFeed's sale to Facebook FriendFeed have apparently now disabled their FOAF output. <http://identi.ca/notice/9001608> :-( -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/45AF29AC-8ACE-47B3-B191-490B3E9FD560%40g5n.co.uk Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 2009-08-31T11:26:32 2009-08-31T11:26:32 2009-08-31T11:26:32 On 31 Aug 2009, at 11:45, Henri Sivonen wrote: > It seems to me that there's a difference of underlying premises here. > Premise 1: HTML5 obsoletes HTML 2.0, 3.2 and 4.01 and XHTML 1.x. > New authoring must use the latest level of the language. > Premise 2: HTML 2.0, 3.2, 4.01 and 5 and XHTML 1.x are all > Recommended. It is appropriate to author new pages using older > levels of the langua... On 31 Aug 2009, at 11:45, Henri Sivonen wrote: > It seems to me that there's a difference of underlying premises here. > Premise 1: HTML5 obsoletes HTML 2.0, 3.2 and 4.01 and XHTML 1.x. > New authoring must use the latest level of the language. > Premise 2: HTML 2.0, 3.2, 4.01 and 5 and XHTML 1.x are all > Recommended. It is appropriate to author new pages using older > levels of the language. I think my suggested media type registration text is a reasonable compromise between these. It notes the existence of various different versions of HTML, but gives user agents the freedom to treat them all as HTML5 if they wish: http://www.w3.org/mid/1251457061.2394.75.camel@ophelia2.g5n.co.uk -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1251783766.8710.5.camel%40ophelia2.g5n.co.uk RE: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 2009-09-01T05:42:48 2009-09-01T05:42:48 2009-09-01T05:42:48 On Sun, 2009-08-23 at 18:26 -0700, Larry Masinter wrote: > In addition, [XHTML1] > defines a profile of use of XHTML which is compatible with HTML > 4.01 and which may also be labeled as text/html. To be spectacularly picky, both RFC 2854 and XHTML 1.0 talk about a profile of *XHTML* which can be labelled as text/html. They don't talk about a profile of *XHTML 1.0*. There is nothing in either tha... On Sun, 2009-08-23 at 18:26 -0700, Larry Masinter wrote: > In addition, [XHTML1] > defines a profile of use of XHTML which is compatible with HTML > 4.01 and which may also be labeled as text/html. To be spectacularly picky, both RFC 2854 and XHTML 1.0 talk about a profile of *XHTML* which can be labelled as text/html. They don't talk about a profile of *XHTML 1.0*. There is nothing in either that *explicitly* states that Appendix C guidelines cannot be applied to other versions of XHTML. Neither does XHTML 1.1 contradict this anywhere. The XHTML Media Types note <http://www.w3.org/TR/xhtml-media-types> has explicit guidelines for serving any XHTML-family markup language as text/html, though of course, this is only a note. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/6439D145-8C08-4EB3-B5EB-4F0767C88E11%40g5n.co.uk Re: ANN: BestBuy.com starts publishing full catalog as RDF/XML using GoodRelations - 27 million triples 2009-09-01T08:48:14 2009-09-01T08:48:14 2009-09-01T08:48:14 On 1 Sep 2009, at 08:23, Martin Hepp (UniBW) wrote: > All individual item URIs, e.g. > > http://products.semweb.bestbuy.com/products/8182593/semanticweb.rdf > > should be dereferenceable and return a RDF/XML representation with > the proper media type. But the RDF obtained by dereferencing that URI includes: xml:base="http://products.semweb.bestbuy.com/semanticweb.rdf" which means that the... On 1 Sep 2009, at 08:23, Martin Hepp (UniBW) wrote: > All individual item URIs, e.g. > > http://products.semweb.bestbuy.com/products/8182593/semanticweb.rdf > > should be dereferenceable and return a RDF/XML representation with > the proper media type. But the RDF obtained by dereferencing that URI includes: xml:base="http://products.semweb.bestbuy.com/semanticweb.rdf" which means that the actual product URI ends up as: http://products.semweb.bestbuy.com/semanticweb.rdf#Offering_8182593 When fetching that, you get a 404. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AA53F24B-D369-4894-AAFD-85EC7016A7A0%40g5n.co.uk Re: up up up, was: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard 2009-09-01T09:22:16 2009-09-01T09:22:16 2009-09-01T09:22:16 On 30 Aug 2009, at 13:24, Julian Reschke wrote: > The main disadvantage is that a recipient that only looks for "up" > and which tries to build a tree of resources, treating "up up up" > as "up" will create a broken tree. How does "up up up" fit in with hierarchies where nodes may have multiple ancestries? e.g. the "Winston Churchill" article in a theoretical encyclopaedic work might be... On 30 Aug 2009, at 13:24, Julian Reschke wrote: > The main disadvantage is that a recipient that only looks for "up" > and which tries to build a tree of resources, treating "up up up" > as "up" will create a broken tree. How does "up up up" fit in with hierarchies where nodes may have multiple ancestries? e.g. the "Winston Churchill" article in a theoretical encyclopaedic work might be reachable by drilling down in any of the following ways: Home -> People -> British -> Prime Ministers -> 20th Century -> Winston Churchill Home -> People -> Families -> Spencer-Churchill Family -> Winston Churchill Home -> Events -> Wars -> World War II -> Key Players -> Winston Churchill The first tree implies that the relationship from Winston Churchill's page to the home page is rel="up up up up" and the second tree implies that it's rel="up up up". The last tree also implies rel="up up up up". The rel attribute allows multiple relationships to be space- separated, so I can imagine someone adding links to Winston Churchill's page like this: <link rel="up up up home up up up up contents up up up up" href="/" /> RDFa provides a solution to mapping out the full tree of "ups" unambiguously: <link rel="home contents" href="/" /> <link rel="up" href="/People_GB_PM_20C" /> <link about="/People_GB_PM_20C" rel="up" href="/People_GB_PM" /> <link about="/People_GB_PM" rel="up" href="/People_GB" /> <link about="/People_GB" rel="up" href="/People" /> <link about="/People" rel="up" href="/" /> <link rel="up" href="/Family_SpencerChurchill" /> <link about="/Family_SpencerChurchill" rel="up" href="/Families" /> <link about="/Families" rel="up" href="/People" /> <link rel="up" href="/WW2_KeyPlayers" /> <link about="/WW2_KeyPlayers" rel="up" href="/WW2" /> <link about="/WW2" rel="up" href="/Wars" /> <link about="/Wars" rel="up" href="/Events" /> <link about="/Events" rel="up" href="/" /> Or, for a more visible, breadcrumb-like solution: <div class="breadcrumbs"> <a rel="home contents" href="/">Home</a> &lt; <a about="/" rev="up" href="/People">People</a> &lt; <a about="/People" rev="up" href="/People_GB">British</a> &lt; <a about="/People_GB" rev="up" href="/People_GB_PM">Prime Ministers</a> &lt; <!-- etc --> </div> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/985E64CB-FFAF-47A6-992D-665F4A84A881%40g5n.co.uk Re: up up up, was: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard 2009-09-01T10:08:48 2009-09-01T10:08:48 2009-09-01T10:08:48 On 1 Sep 2009, at 10:22, Toby Inkster wrote: > RDFa provides a solution to mapping out the full tree of "ups" > unambiguously I was answering this thread in the context of the HTML working group, but as it also concerns the Web Linking draft I'll note that this solution also works for the HTTP Link header as it provides an "anchor" parameter which almost exactly matches the semantics of RDFa's "about" attribute. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 1 Sep 2009, at 10:22, Toby Inkster wrote: > RDFa provides a solution to mapping out the full tree of "ups" > unambiguously I was answering this thread in the context of the HTML working group, but as it also concerns the Web Linking draft I'll note that this solution also works for the HTTP Link header as it provides an "anchor" parameter which almost exactly matches the semantics of RDFa's "about" attribute. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/7E251C01-3303-4A4E-B59F-716E01BBF8C3%40g5n.co.uk Re: <keygen> element (was RE: Implementor feedback on new elements in HTML5) 2009-09-01T16:44:23 2009-09-01T16:44:23 2009-09-01T16:44:23 On 1 Sep 2009, at 16:13, Adrian Bateman wrote: > It's hard to find examples of <keygen> being actively used today. <keygen> is being used by FOAF+SSL key providers. Actively. Today. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 1 Sep 2009, at 16:13, Adrian Bateman wrote: > It's hard to find examples of <keygen> being actively used today. <keygen> is being used by FOAF+SSL key providers. Actively. Today. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BFA259F7-C2E0-4B10-B555-05AFE45AA641%40g5n.co.uk Project idea: cviki (or some better name than that) 2009-09-02T05:34:01 2009-09-02T05:34:01 2009-09-02T05:34:01 I think this is a great idea for a project, but I don't have time to do it myself... 1. Set up a wiki (pref MediaWiki) for people to publish their CVs/ Resumés. This might need slightly different access restrictions than normal MediaWiki installations to prevent people from negatively editing others' CVs. 2. The site would provide a bunch of MediaWiki "templates" which would expose the ... I think this is a great idea for a project, but I don't have time to do it myself... 1. Set up a wiki (pref MediaWiki) for people to publish their CVs/ Resumés. This might need slightly different access restrictions than normal MediaWiki installations to prevent people from negatively editing others' CVs. 2. The site would provide a bunch of MediaWiki "templates" which would expose the CV data as XHTML+RDFa using the FOAF and DOAC vocabs primarily. 3. The site would provide a conformance checking tool for CV authors, using RDFS and OWL reasoning, and perhaps in-built knowledge of FOAF and DOAC, to look at individual CVs and check them for contradictions. (e.g. range/domain conflicts.) 4. The site would provide a "dictionary" of skills, each with a URI, for more standardised markup of a person's skillset. 5. A bot would monitor the "recent changes" RSS feed (is this valid RSS 1.0 - i.e. RDF? If not, it could maybe be fixed.) finding CVs which had recently been changed. Each of these would be parsed as RDFa and entered into a big, communal triple store (using the URL of the CV page as a graph name for easy maintenance). 6. A SPARQL endpoint would be exposed for the big triple store. 7. People could write various human-friendly forms as a wrapper for the SPARQL endpoint. The cviki community would vote on the best of these, and the winner would be placed on the Wiki front page. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/DBC825D4-7CE9-4508-AA39-368651DB6E15%40g5n.co.uk Re: <meter> and <progress> (was RE: Implementor feedback on new elements in HTML5) 2009-09-02T05:40:19 2009-09-02T05:40:19 2009-09-02T05:40:19 On 2 Sep 2009, at 06:31, Jonas Sicking wrote: > The problem with temperatures is that they're generally unbounded. Well, they have a lower bound, but not one that's especially useful for weather reports. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 2 Sep 2009, at 06:31, Jonas Sicking wrote: > The problem with temperatures is that they're generally unbounded. Well, they have a lower bound, but not one that's especially useful for weather reports. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BFBBCCBA-397A-4AF7-B6DC-F2D5393D8609%40g5n.co.uk Re: Vocabularies for file data, content events, errors 2009-09-02T10:14:56 2009-09-02T10:14:56 2009-09-02T10:14:56 On 2 Sep 2009, at 10:37, Niklas Lindström wrote: > * simple file data properties, describing: > - checksum+algorithm (and/or direct properties for md5, sha1/-2 > etc.), > - filename/slug (unless dct:identifier is suitable enough?). foaf:sha1 exists, but that might not be much use if you if you want to... > * content-related events, such as "the act of reading from a > dataset/collection... On 2 Sep 2009, at 10:37, Niklas Lindström wrote: > * simple file data properties, describing: > - checksum+algorithm (and/or direct properties for md5, sha1/-2 > etc.), > - filename/slug (unless dct:identifier is suitable enough?). foaf:sha1 exists, but that might not be much use if you if you want to... > * content-related events, such as "the act of reading from a > dataset/collection (e.g. a feed)", "create", "update" and specifically > "delete" (or "deletion") ... track changes to the document's hash over time. > Currently we use AtomOwl to represent versioned entries That's probably a pretty good start. If you add in an events ontology (and I'd recommend starting with Yves Raimond's one and building on top of it) then you should be able to define a EntryChange class as a subclass of Yves' ev:Event class with accompanying previousVersion (subproperty of ev:factor) and subsequentVersion (subproperty of ev:product). Building on Yves' ontology for tracking document changes is more or less what I've done here: http://ontologi.es/status -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/23CC91BD-04CB-41BA-A503-453444A9AB19%40g5n.co.uk Re: tweaking meter [was: Re: <meter> and <progress> (was RE: Implementor feedback on new elements in HTML5)] 2009-09-02T15:31:10 2009-09-02T15:31:10 2009-09-02T15:31:10 On 2 Sep 2009, at 15:38, Jim Jewett wrote: > I think meter should be an appropriate element for things like > "number of posts" or "member for X months". > > Under the current definition, these wouldn't be appropriate, > as there is no *hard* maximum, but I think it would be reasonable > to change the element to accommodate them. Depending on how you define "hard maximum" each of these examples ... On 2 Sep 2009, at 15:38, Jim Jewett wrote: > I think meter should be an appropriate element for things like > "number of posts" or "member for X months". > > Under the current definition, these wouldn't be appropriate, > as there is no *hard* maximum, but I think it would be reasonable > to change the element to accommodate them. Depending on how you define "hard maximum" each of these examples have a hard maximum: - the total number of posts ever made to the site - the length of time since the group was founded -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/75C723CB-CDC1-42B1-B258-B11330FEDAD2%40g5n.co.uk Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 2009-09-03T10:19:09 2009-09-03T10:19:09 2009-09-03T10:19:09 On 3 Sep 2009, at 09:50, Ian Hickson wrote: > HTML4 defined it as taking a single URI. The DTD defines it as %URI; (which is just an alias for CDATA though). The recommendation text states "this attribute specifies the location of one or more meta data profiles, separated by white space." -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 3 Sep 2009, at 09:50, Ian Hickson wrote: > HTML4 defined it as taking a single URI. The DTD defines it as %URI; (which is just an alias for CDATA though). The recommendation text states "this attribute specifies the location of one or more meta data profiles, separated by white space." -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AEDA7707-4136-4878-AD7D-4943CDCE383B%40g5n.co.uk Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03 2009-09-03T11:41:18 2009-09-03T11:41:18 2009-09-03T11:41:18 On 3 Sep 2009, at 11:32, Anne van Kesteren wrote: > On Thu, 03 Sep 2009 12:19:09 +0200, Toby Inkster <tai@g5n.co.uk> > wrote: >> On 3 Sep 2009, at 09:50, Ian Hickson wrote: >>> HTML4 defined it as taking a single URI. >> >> The DTD defines it as %URI; (which is just an alias for CDATA >> though). The recommendation text states "this attribute specifies >> the location of one or more meta dat... On 3 Sep 2009, at 11:32, Anne van Kesteren wrote: > On Thu, 03 Sep 2009 12:19:09 +0200, Toby Inkster <tai@g5n.co.uk> > wrote: >> On 3 Sep 2009, at 09:50, Ian Hickson wrote: >>> HTML4 defined it as taking a single URI. >> >> The DTD defines it as %URI; (which is just an alias for CDATA >> though). The recommendation text states "this attribute specifies >> the location of one or more meta data profiles, separated by white >> space." > > Wow, bonus points for selectively quoting. The rest of the paragraph is not relevant to a discussion of the syntax of the profile attribute - the rest of the paragraph is concerned with the semantics of the URLs. As Julian pointed out, there is an apparent inconsistency between the DTD and the prose of the recommendation, but it seems pretty obvious that a whitespace delimited list of URIs is intended - if documentary evidence is required, take a look at XHTML 1.1 where the inconsistency is resolved, in favour of a list of URIs. If you want to talk about the semantics, it's certainly true that HTML 4 only assigns meaning to the first URI; however it is left open for other specifications to assign meaning to subsequent URIs in the list. GRDDL and XMDP are two specifications which assign meaning to all the URIs in the list. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/2B971039-143B-4A5D-A12B-FEF881183C6D%40g5n.co.uk Re: Proposed Wording Change - Processing step 9 2009-09-03T16:48:55 2009-09-03T16:48:55 2009-09-03T16:48:55 On 3 Sep 2009, at 17:15, Shane McCarron wrote: > I propose that we change step 9 so that the *default* behavior is > that a "plain literal" is generated, as opposed to the default > behavior today that an "XML Literal" is generated. While I agree that this is better default behaviour, it is a big change from the current specification. Are you proposing this as an errata, or for a future ... On 3 Sep 2009, at 17:15, Shane McCarron wrote: > I propose that we change step 9 so that the *default* behavior is > that a "plain literal" is generated, as opposed to the default > behavior today that an "XML Literal" is generated. While I agree that this is better default behaviour, it is a big change from the current specification. Are you proposing this as an errata, or for a future version of RDFa? If the former, I think it's too big a change. If the latter, it sounds like a good idea, but it would need to be decided if processors would be expected to apply the old rule for RDFa 1.0 and the new rule for RDFa 1.1? If so, what would be the definitive way of determining which to use? Using the XHTML @version attribute and defaulting to 1.1 when it's not present makes sense for XHTML+RDFa 1.0, but perhaps not so much for other host languages such as SVG and ODF. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D50EE6FC-7E89-4C74-9256-905EF56E9F91%40g5n.co.uk Re: [ontolog-forum] Event Ontology 2009-09-04T23:40:54 2009-09-04T23:40:54 2009-09-04T23:40:54 On 4 Sep 2009, at 21:30, Dan Brickley wrote: > Given two event descriptions, in rdf, owl or similar... how would > you determine whether these documents described one event or two > different events? If you think about the obvious properties an event has - e.g. time and location - it appears there are no single one or combination of them could act as a natural inverse functional property... On 4 Sep 2009, at 21:30, Dan Brickley wrote: > Given two event descriptions, in rdf, owl or similar... how would > you determine whether these documents described one event or two > different events? If you think about the obvious properties an event has - e.g. time and location - it appears there are no single one or combination of them could act as a natural inverse functional property. Nevertheless, for certain subsets of the class of events, IFPs can be found: * For things like concerts, a property :ticket with rdfs:domain :Event and rdfs:range :Ticket is an IFP. * For events representing, say, checkins to a subversion repository, each checkin is given a unique, sequential identifier which, when combined with the address of the repository acts as an identifier. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/903B2BF3-4D69-428E-BBCD-36FB0912CFF9%40g5n.co.uk Re: rdf:Lists in RDFa? 2009-09-05T12:17:57 2009-09-05T12:17:57 2009-09-05T12:17:57 On 5 Sep 2009, at 07:49, Roberto García wrote: > I've been able to find some references to this issue but it is not > clear for me if at last it is possible to use some sort of construct > that makes this easier than modelling all the triples for the list > with rdf:first, rdf:rest, rdf:nil,... Yes, rdf:Lists are truly horrible in RDFa. In fairness to RDFa, they're just a very complex structu... On 5 Sep 2009, at 07:49, Roberto García wrote: > I've been able to find some references to this issue but it is not > clear for me if at last it is possible to use some sort of construct > that makes this easier than modelling all the triples for the list > with rdf:first, rdf:rest, rdf:nil,... Yes, rdf:Lists are truly horrible in RDFa. In fairness to RDFa, they're just a very complex structure and are horrible in a lot of RDF serialisations - N-Triples, TriX, RDF/JSON, etc. The only serialisations where they seem reasonable are those that provide syntactic sugar to handle them - e.g. Turtle and RDF/XML. Here's how I've marked up lists in RDFa: http://ontologi.es/rail/routes/gb/VTB1.xhtml -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/571B7C8E-84C3-49F9-95BD-CD6EB8311AC2%40g5n.co.uk Re: xhtml markup such as <strong> and <em> in RDFa values 2009-09-05T12:21:03 2009-09-05T12:21:03 2009-09-05T12:21:03 On 5 Sep 2009, at 11:40, Benjamin Melançon wrote: > Is there any chance that datatype="" is the default? It's not the default, but there is a proposal for it to become the default in RDFa 1.1: http://www.w3.org/mid/4A9FEBA0.6000300@aptest.com -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 5 Sep 2009, at 11:40, Benjamin Melançon wrote: > Is there any chance that datatype="" is the default? It's not the default, but there is a proposal for it to become the default in RDFa 1.1: http://www.w3.org/mid/4A9FEBA0.6000300@aptest.com -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/951D6FD0-23C9-4D54-B10C-5E80691ABADC%40g5n.co.uk Re: FPWD Review Request: HTML+RDFa 2009-09-05T12:37:44 2009-09-05T12:37:44 2009-09-05T12:37:44 On 5 Sep 2009, at 13:00, Philip Taylor wrote: > In most cases the CURIE syntax restriction is sufficient - you > can't have rel="0:test" (it will just be ignored) so it doesn't > really matter how xmlns:0="..." was processed. But you can write > rel=":test", so it matters how xmlns:="..." interacts with that. Actually rel=":test" in XHTML+RDFa (and presumably in Manu's HTML draft) is de... On 5 Sep 2009, at 13:00, Philip Taylor wrote: > In most cases the CURIE syntax restriction is sufficient - you > can't have rel="0:test" (it will just be ignored) so it doesn't > really matter how xmlns:0="..." was processed. But you can write > rel=":test", so it matters how xmlns:="..." interacts with that. Actually rel=":test" in XHTML+RDFa (and presumably in Manu's HTML draft) is defined to always map exactly to: http://www.w3.org/1999/xhtml/vocab#test and not be dependent on CURIE prefix mapping at all. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/B197583F-CA52-4E32-96D0-E4BBF32FB68F%40g5n.co.uk Feature request for RDFa 1.1 [Fwd: rdf:Lists in RDFa?] 2009-09-05T15:40:17 2009-09-05T15:40:17 2009-09-05T15:40:17 Justification: > Yes, rdf:Lists are truly horrible in RDFa. In fairness to RDFa, > they're just a very complex structure and are horrible in a lot of > RDF serialisations - N-Triples, TriX, RDF/JSON, etc. The only > serialisations where they seem reasonable are those that provide > syntactic sugar to handle them - e.g. Turtle and RDF/XML. The following language in a future spec would ma... Justification: > Yes, rdf:Lists are truly horrible in RDFa. In fairness to RDFa, > they're just a very complex structure and are horrible in a lot of > RDF serialisations - N-Triples, TriX, RDF/JSON, etc. The only > serialisations where they seem reasonable are those that provide > syntactic sugar to handle them - e.g. Turtle and RDF/XML. The following language in a future spec would make marking up lists in RDFa much easier: """ RDFa 1.1 processors MUST handle the property rdfs:member specially. If the subject of a triple with predicate rdfs:member is known to be an rdf:List, then the processor MUST add appropriate rdf:first, rdf:rest, and rdf:nil triples to assemble the list. If the subject of a triple with predicate rdfs:member is known to be a rdf:Bag, rdf:Alt or rdf:Seq, then the processor MUST add appropriate rdf:_1, rdf:_2, etc triples. "Known to be" = RDFa processors MUST recognise the explicit container types rdf:List, rdf:Bag, rdf:Alt and rdf:Seq. RDFa processors MAY implement RDFS, OWL or other reasoning to determine that other resources may be containers. """ There are of course other ways this could be handled - via an additional attribute for instance, or by triggering particular behaviours based on <ol>/<ul> elements. (Though the latter has the disadvantage of not translating to non-(X)HTML languages very easily.) I'm not wedded to the solution above, but I'd like to see better rdf:List support in RDFa 1.1. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AC06748D-48D3-4FA6-9A63-1A08292149B8%40g5n.co.uk Re: What about music-related URIs??? 2009-09-07T09:13:54 2009-09-07T09:13:54 2009-09-07T09:13:54 On 6 Sep 2009, at 17:06, Dan Brickley wrote: > ps. i am just running MusicBrainz Picard tagger over all my mp3s > (includes all the CDs I ever bought...). ... Is there a tool / > workflow people here can recommend to turn all that into RDF locally? > does picard keep a db somewhere, or all metadata is just within the > files? I wrote a tool to do this for myself a while ago. Last night I clean... On 6 Sep 2009, at 17:06, Dan Brickley wrote: > ps. i am just running MusicBrainz Picard tagger over all my mp3s > (includes all the CDs I ever bought...). ... Is there a tool / > workflow people here can recommend to turn all that into RDF locally? > does picard keep a db somewhere, or all metadata is just within the > files? I wrote a tool to do this for myself a while ago. Last night I cleaned it up and added it to my source repository, but forgot to reply here. http://goddamn.co.uk/viewvc/misc/ogg2rdf/ogg2rdf.pl It only works on Oggs right now, but it probably wouldn't be much work to add MP3 support as well. Usage is: ogg2rdf.pl somefile.ogg anotherfile.ogg /some/dir/ /another/dir/ anotherfile.ogg And it prints out RDF/XML to STDOUT. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/2D11F400-3498-4BB3-AA9D-A0E35FA3BF02%40g5n.co.uk Re: Feature request for RDFa 1.1 [Fwd: rdf:Lists in RDFa?] 2009-09-07T10:16:45 2009-09-07T10:16:45 2009-09-07T10:16:45 On 7 Sep 2009, at 10:00, Ivan Herman wrote: > This approach is not optimal either, because it is really bound to the > specifics of HTML. Maybe @role could help out here. <ul> and <ol> trigger the rdf:List behaviour, but if you want to use a different HTML element (e.g. <div>), or are using a markup language other than HTML, then you can force rdf:List behaviour via @role. <list xmlns:xhv="http://www.w3.org/1999/xhtml/vocab#" about="#mylist" role="xhv:list"> ... </list> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 7 Sep 2009, at 10:00, Ivan Herman wrote: > This approach is not optimal either, because it is really bound to the > specifics of HTML. Maybe @role could help out here. <ul> and <ol> trigger the rdf:List behaviour, but if you want to use a different HTML element (e.g. <div>), or are using a markup language other than HTML, then you can force rdf:List behaviour via @role. <list xmlns:xhv="http://www.w3.org/1999/xhtml/vocab#" about="#mylist" role="xhv:list"> ... </list> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1F1B0BBE-11FF-4AC3-B41E-DB1909375B24%40g5n.co.uk Re: regrets for September 9, 2009 2009-09-07T12:09:47 2009-09-07T12:09:47 2009-09-07T12:09:47 Regrets from me too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Regrets from me too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/BD7F6F48-6CBF-43CA-B732-6E49D49FBC1F%40g5n.co.uk Re: SPARQL: restricting DESCRIBE queries 2009-09-07T15:19:06 2009-09-07T15:19:06 2009-09-07T15:19:06 On 7 Sep 2009, at 15:36, Bernhard Schandl wrote: > DESCRIBE ?concept WHERE { ?concept rdfs:label "Berlin"@en . } LIMIT 2 > > returns some ~4500 triples because it includes the description of > dbpedia:Berlin. > > Any suggestions how I could limit the number of triples returned by > such a query? Fake it with CONSTRUCT? CONSTRUCT { ?concept ?p ?o . } WHERE { ?concept rdfs:label "Berlin"@en ; ?p ?o . } LIMIT 2 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 7 Sep 2009, at 15:36, Bernhard Schandl wrote: > DESCRIBE ?concept WHERE { ?concept rdfs:label "Berlin"@en . } LIMIT 2 > > returns some ~4500 triples because it includes the description of > dbpedia:Berlin. > > Any suggestions how I could limit the number of triples returned by > such a query? Fake it with CONSTRUCT? CONSTRUCT { ?concept ?p ?o . } WHERE { ?concept rdfs:label "Berlin"@en ; ?p ?o . } LIMIT 2 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/D29E0F3E-7897-422E-9715-7D98236C0D8C%40g5n.co.uk Re: Asserting subclasses of open ranges or domains 2009-09-08T09:59:22 2009-09-08T09:59:22 2009-09-08T09:59:22 On 8 Sep 2009, at 10:03, Bernard Vatant wrote: > - Are such constructions valid in RDFS and/or OWL? > - Are they useful? I think they're valid, but I don't think they're especially useful. Given: dcterms:subject rdfs:range _:b . skos:Concept rdfs:subClassOf _:b . foaf:Person rdfs:subClassOf _:b . <doc> dcterms:subject <#thing> . what useful conclusions can a reasoner come to? It can't co... On 8 Sep 2009, at 10:03, Bernard Vatant wrote: > - Are such constructions valid in RDFS and/or OWL? > - Are they useful? I think they're valid, but I don't think they're especially useful. Given: dcterms:subject rdfs:range _:b . skos:Concept rdfs:subClassOf _:b . foaf:Person rdfs:subClassOf _:b . <doc> dcterms:subject <#thing> . what useful conclusions can a reasoner come to? It can't conclude that <#thing> is a foaf:Person; it can't conclude that <#thing> is a skos:Concept; in fact, <#thing> might be neither of those - it could be anything. A related OWL construct is: ex:subject rdfs:range _:b . _b: owl:unionOf ( skos:Concept foaf:Person ) . Where the reasoner could at least conclude that if <doc> ex:subject <#thing> then <#thing> must be either a skos:Concept or a foaf:Person or both. This is more useful for reasoning with, because combined with a few other inferences it could narrow down <#thing>'s class. OK, given that your original example is not much use to automated reasoners, could it at least be helpful to humans reading the schema? Yes, perhaps, but it's likely they'd be served better by text written in natural language - a rdfs:comment, skos:note, etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E30AA213-4663-4AEC-B7DD-2D4C8C42B2E6%40g5n.co.uk Re: [Bug 7509] Consider <dl type="dialog"> instead of <dialog> 2009-09-09T21:40:39 2009-09-09T21:40:39 2009-09-09T21:40:39 I like this idea. The <dl> element has been used (and some would say abused) for quite a few different purposes. HTML5 creates a <dialog> element to split off one of those purposes, but I'd argue that marking up dialogues is not the only - probably not even the most important - use of <dl> that should be split off. In particular, I think key-value lists are an important case. e.g. <dl> ... I like this idea. The <dl> element has been used (and some would say abused) for quite a few different purposes. HTML5 creates a <dialog> element to split off one of those purposes, but I'd argue that marking up dialogues is not the only - probably not even the most important - use of <dl> that should be split off. In particular, I think key-value lists are an important case. e.g. <dl> <dt>Name:</dt> <dd>Toby Inkster</dd> <dt>Date of birth:</dt> <dd>1980-06-01</dd> </dl> This is quite different to a definition list. "Toby Inkster" isn't the definition of "Name"; if anything it's the other way around: "Name" is the definition of "Toby Inkster". <dl> lists like this seem to be pretty common. Specialising it using an attribute seems preferable to creating a different element for each usage. I'd suggest not using @type though because its syntax would conflict with the attribute of the same name on <a>, <link>, <script>, <object>, etc. Possibly @role could be re-used. (@role isn't just an ARIA attribute, it's intended to be used in other ways too.) e.g. <dl role="property-list"> <dt>Name:</dt> <dd>Toby Inkster</dd> <dt>Date of birth:</dt> <dd>1980-06-01</dd> </dl> A role of "glossary" or something would be the default if no contradictory roles (like "dialog", "timeline" or "property-list") were found. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/AF54D5AC-8D81-4FFB-B09C-8238512CC075%40g5n.co.uk Re: [Bug 7508] <dialog> needs a way to add non-speech related information 2009-09-09T21:45:56 2009-09-09T21:45:56 2009-09-09T21:45:56 In the case of, say, a block of stage directions inserted between two lines of dialogue, I'd suggest the following markup: </dialog><aside>...</aside><dialog> The directions are not part of what is being spoken, so I think this would be the correct way of handling them. It might be nice to have a "follows-from" attribute containing an IDREF allowing a <dialog> element (and indeed all th... In the case of, say, a block of stage directions inserted between two lines of dialogue, I'd suggest the following markup: </dialog><aside>...</aside><dialog> The directions are not part of what is being spoken, so I think this would be the correct way of handling them. It might be nice to have a "follows-from" attribute containing an IDREF allowing a <dialog> element (and indeed all the list elements) to be explicitly marked as following on from a previous one. Its semantics would be to specify that logically the two elements constitute the same list / piece of dialogue, but it has been interrupted to allow some other text to appear. The case of e.g. timestamps appearing by a speaker's name is different though. They're not an interruption from the dialogue, but additional metadata about it. To cover this, I'd suggest that the HTML5 draft be modified to, instead of saying that <dt> indicates the speaker of the following <dd>, say that it contains brief metadata about the following <dd>. This metadata could include, but is not limited to, the name of the speaker, the date or time it was spoken, and the manner it was spoken in. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/7F41A57E-9EB6-4A19-851E-4AC3A7B9E4C1%40g5n.co.uk Re: ARIA's role="" attribute (was Re: [Bug 7509] Consider <dl type="dialog"> instead of <dialog>) 2009-09-10T08:30:53 2009-09-10T08:30:53 2009-09-10T08:30:53 On 9 Sep 2009, at 23:06, Edward O'Connor wrote: > You may be confusing ARIA's role="" attribute with the XHTML Role > Attribute Module. They share a name, and a namespace, so in my book, they're the same attribute. It's true that WAI-ARIA no longer normatively references the XHTML Role Attribute Module. I'm not entirely sure why this is, but it may be because it's expected that XHTML Role... On 9 Sep 2009, at 23:06, Edward O'Connor wrote: > You may be confusing ARIA's role="" attribute with the XHTML Role > Attribute Module. They share a name, and a namespace, so in my book, they're the same attribute. It's true that WAI-ARIA no longer normatively references the XHTML Role Attribute Module. I'm not entirely sure why this is, but it may be because it's expected that XHTML Role will only end up as a Note, and ARIA is aiming at being published as a Recommendation. (I don't think a Recommendation can normatively reference a Note.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/E6B8BF4F-9644-43A2-81B4-0EDA9313BCC4%40g5n.co.uk Re: [Bug 7509] Consider <dl type="dialog"> instead of <dialog> 2009-09-10T08:38:47 2009-09-10T08:38:47 2009-09-10T08:38:47 On 10 Sep 2009, at 02:50, Leif Halvard Silli wrote: > Toby Inkster On 09-09-09 23.40: > >> Specialising it using an attribute seems preferable to creating a >> different element for each usage. I'd suggest not using @type >> though because its syntax would conflict with the attribute of >> the same name on <a>, <link>, <script>, <object>, etc. > > It fits with how @type is used for the <... On 10 Sep 2009, at 02:50, Leif Halvard Silli wrote: > Toby Inkster On 09-09-09 23.40: > >> Specialising it using an attribute seems preferable to creating a >> different element for each usage. I'd suggest not using @type >> though because its syntax would conflict with the attribute of >> the same name on <a>, <link>, <script>, <object>, etc. > > It fits with how @type is used for the <input> element. And with > HTML 4's <ol type="A"> and <ul type="square">. True - I'd forgotten about those. The @type attributes of <ol> and <ul> have been removed from HTML5 though. input@type is a big inconsistency with other uses of @type, but it's too late to do anything about that. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/96829EB6-CA61-4E67-B4E9-561FC3D6C92D%40g5n.co.uk Re: Change back the semantics of <cite> 2009-09-13T18:02:41 2009-09-13T18:02:41 2009-09-13T18:02:41 On 11 Sep 2009, at 16:45, Smylers wrote: > But what does it actually achieve? In what way does a user benefit > from > a document having all the people mentioned marked up as such? It's not a question of having all the people *mentioned* marked up, but all the people *cited* marked up. A citation is more than a mere mention - it's an indication that the person or thing cited provides su... On 11 Sep 2009, at 16:45, Smylers wrote: > But what does it actually achieve? In what way does a user benefit > from > a document having all the people mentioned marked up as such? It's not a question of having all the people *mentioned* marked up, but all the people *cited* marked up. A citation is more than a mere mention - it's an indication that the person or thing cited provides supporting evidence for the words on the page. How does a user of the page benefit? I can imagine a bit of Javascript that, say, highlights nearby <cite> elements when the mouse is hovered over a <blockquote> or <q> element. Perhaps the <cite> element immediately before and immediately after, plus any <cite> elements actually within the <blockquote>, as there's currently no way of knowing exactly which is the relevant one, though RDFa maybe could help: <p xmlns:foaf="http://xmlns.com/foaf/0.1/"> [... blah, blah, blah, blah, blah, blah, blah ...] After all, as <cite about="#ws" property="foaf:name">Shakespeare</cite> said, <q cite="#ws">a rose by any other name would smell as sweet</q>. </p> If HTML 2 and HTML 4 differ on the definition of <cite>, it seems more sensible to go with either the wider definition (as that will encompass the narrower one) or the more recent definition, as these will be compatible with more existing content. The HTML 4 definition is both the wider definition and the more recent one, so seems the way to go. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/C966C546-5EE0-4496-ADC9-4C43BFEE9FDB%40g5n.co.uk Re: <details> 2009-09-14T13:12:51 2009-09-14T13:12:51 2009-09-14T13:12:51 On 14 Sep 2009, at 12:38, Anne van Kesteren wrote: > One thing I'm afraid of is that if people start using <details> > before implementations are ready is that implementations can no > longer provide the functionality of <details> natively. From that > perspective I'm sort of happy authors cannot use it yet. I take it you mean that if people start implementing the show/hide functionality... <html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div><div>On 14 Sep 2009, at 12:38, Anne van Kesteren wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>One thing I'm afraid of is that if people start using &lt;details&gt; before implementations are ready is that implementations can no longer provide the functionality of &lt;details&gt; natively. From that perspective I'm sort of happy authors cannot use it yet.</div> </blockquote><br></div><div>I take it you mean that if people start implementing the show/hide functionality of &lt;details&gt; in Javascript, this would interfere with native show/hide functionality?</div><div><br></div><div>This would be a reason to add &lt;script implements&gt; to HTML5. The HTML5 documentation would define a URI that represents the functionality of the &lt;details&gt; element, say:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://www.w3.org/1999/xhtml/element#details">http://www.w3.org/1999/xhtml/element#details</a><br></div><div><br></div><div>Then authors who wished to implement show/hide in Javascript so that they can use it straight away would just put:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>&lt;script implements="<a href="http://www.w3.org/1999/xhtml/element#details">http://www.w3.org/1999/xhtml/element#details</a>"&gt;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>&nbsp;&nbsp;// script to implement &lt;details&gt; goes here.<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>&lt;/script&gt;<br></div><div><br></div><div>When new browser versions are released which have native functionality for &lt;details&gt;, they'd see the URI in the implements attribute, know that they already implement support for that feature, and thus ignore that entire &lt;script&gt; element.</div><div><br></div><div>The implements attribute appears in the most recent XHTML 2 and XML Events 2 drafts. It's a really nice hook for future-proofing websites, and pretty easy for user agents to implement; I think HTML5 is all the poorer for not having adopted it yet.&nbsp;</div><div><br></div><div>Certainly there are ways it could be improved. For example, it would be nice if the implements attribute could be allowed to take relative URIs which are always evaluated relative to "<a href="http://www.w3.org/1999/xhtml/">http://www.w3.org/1999/xhtml/</a>". That would allow for the previous example to be written as:</div><div><br></div><div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>&lt;script implements="element#details"&gt;</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>&nbsp;&nbsp;// script to implement &lt;details&gt; goes here.<br></div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>&lt;/script&gt;</div><div><br></div><div>Other use cases would include websites providing Javascript that rewrites &lt;audio&gt; and &lt;video&gt; to, for example, Flash-based players in browsers with no native support for those elements - the implements attribute would provide a way of avoiding sniffing to guess which user-agents need the rewriting. Also, scripts that implement &lt;canvas&gt; in Internet Explorer, etc, etc.</div></div><br><div> <span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; "><div>--&nbsp;</div><div>Toby A Inkster</div><div>&lt;<a href="mailto:mail@tobyinkster.co.uk">mailto:mail@tobyinkster.co.uk</a>&gt;</div><div>&lt;<a href="http://tobyinkster.co.uk">http://tobyinkster.co.uk</a>&gt;</div><div><br class="webkit-block-placeholder"></div></span><br class="Apple-interchange-newline"> </div><br></body></html> On 14 Sep 2009, at 12:38, Anne van Kesteren wrote: > One thing I'm afraid of is that if people start using <details> > before implementations are ready is that implementations can no > longer provide the functionality of <details> natively. From that > perspective I'm sort of happy authors cannot use it yet. I take it you mean that if people start implementing the show/hide functionality of <details> in Javascript, this would interfere with native show/hide functionality? This would be a reason to add <script implements> to HTML5. The HTML5 documentation would define a URI that represents the functionality of the <details> element, say: http://www.w3.org/1999/xhtml/element#details Then authors who wished to implement show/hide in Javascript so that they can use it straight away would just put: <script implements="http://www.w3.org/1999/xhtml/element#details"> // script to implement <details> goes here. </script> When new browser versions are released which have native functionality for <details>, they'd see the URI in the implements attribute, know that they already implement support for that feature, and thus ignore that entire <script> element. The implements attribute appears in the most recent XHTML 2 and XML Events 2 drafts. It's a really nice hook for future-proofing websites, and pretty easy for user agents to implement; I think HTML5 is all the poorer for not having adopted it yet. Certainly there are ways it could be improved. For example, it would be nice if the implements attribute could be allowed to take relative URIs which are always evaluated relative to "http://www.w3.org/1999/ xhtml/". That would allow for the previous example to be written as: <script implements="element#details"> // script to implement <details> goes here. </script> Other use cases would include websites providing Javascript that rewrites <audio> and <video> to, for example, Flash-based players in browsers with no native support for those elements - the implements attribute would provide a way of avoiding sniffing to guess which user-agents need the rewriting. Also, scripts that implement <canvas> in Internet Explorer, etc, etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/F750245D-D635-4F26-B560-2BEB98388A08%40g5n.co.uk Re: Privacy, security and social media management 2009-09-14T13:33:46 2009-09-14T13:33:46 2009-09-14T13:33:46 On 14 Sep 2009, at 13:06, Christine Perey wrote: > I would be interested in hearing what people think of the Global > Lockbox proposal. Ah yes, I remember reading about this a while back. I think it's a good idea, but very centralised. I'd like to be able to host my own lockbox on my own server. Oh, but I do have to ask "WTF?" about the 3441 pixel high image on their front page!! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 14 Sep 2009, at 13:06, Christine Perey wrote: > I would be interested in hearing what people think of the Global > Lockbox proposal. Ah yes, I remember reading about this a while back. I think it's a good idea, but very centralised. I'd like to be able to host my own lockbox on my own server. Oh, but I do have to ask "WTF?" about the 3441 pixel high image on their front page!! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253009247.7391.73.camel%40ophelia2.g5n.co.uk Re: Making human-friendly linked data pages more human-friendly (was: dbpedia not very visible, nor fun) 2009-09-15T10:07:28 2009-09-15T10:07:28 2009-09-15T10:07:28 On Tue, 2009-09-15 at 11:08 +0200, Matthias Samwald wrote: > This could be improved by changes in the layout, and possibly a > manually curated ordering of properties. For example, > http://d.opencalais.com/er/company/ralg-tr1r/f8a13a13-8dbc-3d7e-82b6-1d7968476cae.html > definitely looks more inviting than the typical DBpedia page (albeit > still a bit sterile). This is kind of what I aim for wit... On Tue, 2009-09-15 at 11:08 +0200, Matthias Samwald wrote: > This could be improved by changes in the layout, and possibly a > manually curated ordering of properties. For example, > http://d.opencalais.com/er/company/ralg-tr1r/f8a13a13-8dbc-3d7e-82b6-1d7968476cae.html > definitely looks more inviting than the typical DBpedia page (albeit > still a bit sterile). This is kind of what I aim for with demiblog. For example, these triples: http://tobyinkster.co.uk/article/projects/?format=text/turtle get output as this (X)HTML: http://tobyinkster.co.uk/article/projects/?format=text/html It figures out the best way to lay out a page based on its rdf:type. e.g. a type of foaf:Document or rss:item would trigger the "document" layout, so it places the text of the document into a wide column and other metadata into a narrower column. Documents can be tagged, and that's something a visitor might be interested in, so the tags associated with the document are removed from the generic metadata area and placed in a "tags for this item" panel. On the other hand, if the thing being described with not a foaf:Document but perhaps a skos:Concept, or a foaf:Person then a different layout would be triggered. Connection negotiation also works on a per-rdf:type basis. For example, an Atom representation is available for foaf:Document resources, whereas a vCard representation is available for foaf:Person resources. A lot of work is still needed - the pages still look too generic - the per-rdf:type layouts are not tweaked enough yet. But the project is still young (about 3 months old), and only has one developer (me) working on it (part time). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253014257.7391.93.camel%40ophelia2.g5n.co.uk Re: <details> 2009-09-15T11:30:58 2009-09-15T11:30:58 2009-09-15T11:30:58 On Tue, 2009-09-15 at 11:09 +0000, Ian Hickson wrote: > Search for "unreliable" in: > http://lists.w3.org/Archives/Public/public-html/2009Jul/0685.html hasFeature was unreliable because the features were too broad. Asking for a boolean answer to hasFeature('StyleSheets') is clearly not going to give you a useful answer. Asking for a boolean answer to implements("elements#details") is a differ... On Tue, 2009-09-15 at 11:09 +0000, Ian Hickson wrote: > Search for "unreliable" in: > http://lists.w3.org/Archives/Public/public-html/2009Jul/0685.html hasFeature was unreliable because the features were too broad. Asking for a boolean answer to hasFeature('StyleSheets') is clearly not going to give you a useful answer. Asking for a boolean answer to implements("elements#details") is a different matter though. To claim that it's the same thing is a false comparison. Do you really expect that any browsers will be released with *partial implementations* of the <details> element? Implementations may be buggy, but they're pretty likely to be complete. And even in the case where a browser does implement partial support for <details> - say, it exposes the element's DOM, but don't offer a way of expanding and contracting the element - then how does the suggested alternative: if (typeof document.createElement('details').open == 'undefined') { // script that implements <details> here } improve matters? The meat of the script will not be executed. Using <script implements> provides us with a neat, consistent and readable syntax. People seeing the code above would naturally ask themselves what is being opened. <script implements> is simple and declarative. People seeing <script implements="element#details"> can say: oh, OK, this script implements the element <details>. Given the amount of script out there on the web at large that does feature detection, <script implements> would be paving a cowpath, replacing an ad-hoc approach to development with a consistent, standardised one. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253016486.7391.104.camel%40ophelia2.g5n.co.uk Re: <details> 2009-09-15T12:08:06 2009-09-15T12:08:06 2009-09-15T12:08:06 On Tue, 2009-09-15 at 13:55 +0200, Lachlan Hunt wrote: > Your proposal and suggestion for how to use it seem to be conflicting. > You seem to be proposing that if the attribute evaluates to true. > i.e. <script implements="elements#details"> is supposed to check if > the details element is implemented, and then executes the script if it > evaluates to true. No, what I've always said is that <scr... On Tue, 2009-09-15 at 13:55 +0200, Lachlan Hunt wrote: > Your proposal and suggestion for how to use it seem to be conflicting. > You seem to be proposing that if the attribute evaluates to true. > i.e. <script implements="elements#details"> is supposed to check if > the details element is implemented, and then executes the script if it > evaluates to true. No, what I've always said is that <script implements="elements#details"> is simple, declarative markup indicating that this <script> element provides an implementation of the <details> element. The usual behaviour of a browser with native support for <details> would be to *not* execute the script. If the script was externally referenced with <script> it need not even download it, saving precious bytes. An alternative behaviour would be to disable its native support for <details> and execute the script. I don't imagine that many browsers would take this approach. However it may be useful to do this with more complicated elements like <video>, where it might be advantageous to disable a partial, native implementation, in favour of a fuller, scripted implementation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253090278.7391.121.camel%40ophelia2.g5n.co.uk Re: Testing Google's Rich Snippets RDFa support 2009-09-16T08:37:59 2009-09-16T08:37:59 2009-09-16T08:37:59 On Tue, 2009-09-15 at 17:09 +0100, Philip Taylor wrote: > Othar wrote: > > > We surely have errors in our parsing (thanks for finding several: > > we'll look into these on Monday). But we will also deviate from the > > standard in some cases to be forgiving of webmaster errors. For > > example, we expect that some webmasters will forget the xmlns > > attribute entirely. > > "we will [...] devia... On Tue, 2009-09-15 at 17:09 +0100, Philip Taylor wrote: > Othar wrote: > > > We surely have errors in our parsing (thanks for finding several: > > we'll look into these on Monday). But we will also deviate from the > > standard in some cases to be forgiving of webmaster errors. For > > example, we expect that some webmasters will forget the xmlns > > attribute entirely. > > "we will [...] deviate from the standard" makes me believe that the > above problems are an unavoidable consequence of Google's intentions, > rather than just unintentional transient fixable bugs, and therefore are > a serious concern (which is why I'm writing about it like this rather > than just listing bugs). I think it's reasonable to build in a degree of laxity into an RDFa parser. Postel's Law applies. But Google's current parsing algorithm doesn't just forgive webmasters who make mistakes, but has the presumably unintended consequence of punishing webmasters who publish conforming but unexpected-by-Google RDFa. The best way to forgive webmasters who forget to declare the 'v' CURIE prefix would be to pre-populate the "list of URI mappings" which is described as initially empty in <http://www.w3.org/TR/rdfa-syntax/#sec_5.5.>. Instead, Google appears to ignore CURIE prefix mappings altogether. I'd previously sent to Kavi Goel at Google a few test cases which *ought* to be to *exactly* identical results by an RDFa processor, but Google currently seems to handle differently to each other. I'll put them on public record now: <div xmlns:v="http://rdf.data-vocabulary.org/" about="#joe" typeof="v:Person"> <span property="v:name">Joe Bloggs</span> <span property="v:nickname">Joey</span> </div> <div xmlns:v="http://rdf.data-vocabulary.org/"> <span about="#joe" typeof="v:Person" property="v:name">Joe Bloggs</span> <span about="#joe" property="v:nickname">Joey</span> </div> <div xmlns:v="http://rdf.data-vocabulary.org/"> <span about="#joe" property="v:name">Joe Bloggs</span> <span about="#joe" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" rel="rdf:type" resource="[v:Person]" property="v:nickname">Joey</span> </div> <div xmlns:v="http://rdf.data-vocabulary.org/" about="#joe" typeof="v:Person"> <span xmlns:v="http://rdf.data-vocabulary.org/n" property="v:ame">Joe Bloggs</span> <span xmlns:v="http://rdf.data-vocabulary.org/n" property="v:ickname">Joey</span> </div> <div xmlns:v="http://rdf.data-vocabulary.org/" about="#joe" typeof="v:Person" property="v:nickname" content="Joey"> <span property="v:name">Joe Bloggs</span> <span>Joey</span> </div> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/623681E2-4844-4E4A-88BD-9160063E46B8%40g5n.co.uk Re: Testing Google's Rich Snippets RDFa support 2009-09-16T17:24:15 2009-09-16T17:24:15 2009-09-16T17:24:15 On 16 Sep 2009, at 18:19, Philip Taylor wrote: > Are you suggesting that Google should intentionally violate the > RDFa specification? Or are you suggesting the RDFa specification > should be relaxed to allow implementers freedom in handling invalid > documents? I think it must be one or the other, as long as Google > is claiming to implement RDFa. Neither. I am claiming that implementer... On 16 Sep 2009, at 18:19, Philip Taylor wrote: > Are you suggesting that Google should intentionally violate the > RDFa specification? Or are you suggesting the RDFa specification > should be relaxed to allow implementers freedom in handling invalid > documents? I think it must be one or the other, as long as Google > is claiming to implement RDFa. Neither. I am claiming that implementers will often want to implement a superset of RDFa. e.g. they'll want to parse RDFa plus some other HTML semantics (like <blockquote@cite>, <title>, etc). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253181747.20274.16.camel%40ophelia2.g5n.co.uk subscribe 2009-09-17T10:02:28 2009-09-17T10:02:28 2009-09-17T10:02:28 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253181775.20274.18.camel%40ophelia2.g5n.co.uk subscribe 2009-09-17T10:02:55 2009-09-17T10:02:55 2009-09-17T10:02:55 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253181886.20274.20.camel%40ophelia2.g5n.co.uk Re: CONFIRM s618810553 2009-09-17T10:04:46 2009-09-17T10:04:46 2009-09-17T10:04:46 On Thu, 2009-09-17 at 10:03 +0000, public-rdb2rdf-comments-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdb2rdf-comments mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > publi... On Thu, 2009-09-17 at 10:03 +0000, public-rdb2rdf-comments-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdb2rdf-comments mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-rdb2rdf-comments-request@w3.org > > with the Subject string: > > CONFIRM s618810553 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed above > will be (un)subscribed. If the address above is incorrect, please do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event that > you did not send a request to (un)subscribe, the headers of the message > may help you discover who sent the request. > > > >From tai@g5n.co.uk Thu Sep 17 10:03:14 2009 > >Received: from bart.w3.org ([128.30.52.63]) > > by frink.w3.org with esmtp (Exim 4.63) > > (envelope-from <tai@g5n.co.uk>) > > id 1MoDpa-0002jm-DG > > for public-rdb2rdf-comments-request@listhub.w3.org; Thu, 17 Sep 2009 10:03:14 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by bart.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1MoDpR-0006gS-I6 > > for public-rdb2rdf-comments-request@w3.org; Thu, 17 Sep 2009 10:03:14 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 33121B9802 > > for <public-rdb2rdf-comments-request@w3.org>; Thu, 17 Sep 2009 11:02:34 +0100 (BST) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, port 10025) > > with ESMTP id R+7Dub+sqrnH > > for <public-rdb2rdf-comments-request@w3.org>; > > Thu, 17 Sep 2009 11:02:28 +0100 (BST) > >Received: from [127.0.0.1] (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 4A50DB9801 > > for <public-rdb2rdf-comments-request@w3.org>; Thu, 17 Sep 2009 11:02:28 +0100 (BST) > >Subject: subscribe > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-rdb2rdf-comments-request@w3.org > >Content-Type: text/plain > >Date: Thu, 17 Sep 2009 11:02:27 +0100 > >Message-Id: <1253181747.20274.16.camel@ophelia2.g5n.co.uk> > >Mime-Version: 1.0 > >X-Mailer: Evolution 2.22.3.1-1.1mdv2008.1 > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: bart.w3.org 1MoDpR-0006gS-I6 63d1fe528cb4da87defb316d6b55ae59 > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253181896.20274.21.camel%40ophelia2.g5n.co.uk Re: CONFIRM s2296910602 2009-09-17T10:04:57 2009-09-17T10:04:57 2009-09-17T10:04:57 On Thu, 2009-09-17 at 10:03 +0000, public-rdb2rdf-wg-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdb2rdf-wg mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-rdb2rdf-wg... On Thu, 2009-09-17 at 10:03 +0000, public-rdb2rdf-wg-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdb2rdf-wg mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-rdb2rdf-wg-request@w3.org > > with the Subject string: > > CONFIRM s2296910602 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed above > will be (un)subscribed. If the address above is incorrect, please do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event that > you did not send a request to (un)subscribe, the headers of the message > may help you discover who sent the request. > > > >From tai@g5n.co.uk Thu Sep 17 10:03:38 2009 > >Received: from bart.w3.org ([128.30.52.63]) > > by frink.w3.org with esmtp (Exim 4.63) > > (envelope-from <tai@g5n.co.uk>) > > id 1MoDpy-0002kZ-7V > > for public-rdb2rdf-wg-request@listhub.w3.org; Thu, 17 Sep 2009 10:03:38 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by bart.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1MoDpo-0006st-TM > > for public-rdb2rdf-wg-request@w3.org; Thu, 17 Sep 2009 10:03:38 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 1138FB9803 > > for <public-rdb2rdf-wg-request@w3.org>; Thu, 17 Sep 2009 11:02:58 +0100 (BST) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, port 10025) > > with ESMTP id SrW22ZniffYr for <public-rdb2rdf-wg-request@w3.org>; > > Thu, 17 Sep 2009 11:02:55 +0100 (BST) > >Received: from [127.0.0.1] (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 6CF44B9801 > > for <public-rdb2rdf-wg-request@w3.org>; Thu, 17 Sep 2009 11:02:55 +0100 (BST) > >Subject: subscribe > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-rdb2rdf-wg-request@w3.org > >Content-Type: text/plain > >Date: Thu, 17 Sep 2009 11:02:55 +0100 > >Message-Id: <1253181775.20274.18.camel@ophelia2.g5n.co.uk> > >Mime-Version: 1.0 > >X-Mailer: Evolution 2.22.3.1-1.1mdv2008.1 > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: bart.w3.org 1MoDpo-0006st-TM 8e515053920a8800a9ce267453ad70b7 > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253182993.20274.33.camel%40ophelia2.g5n.co.uk Re: vCard RDF merge.... 2009-09-17T10:23:16 2009-09-17T10:23:16 2009-09-17T10:23:16 On Thu, 2009-09-17 at 10:36 +0200, Martin Hepp (UniBW) wrote: > I don't know whether I am in the Linked Data scene ;-), but I am > convinced that bNodes can be useful. As far as I'm concerned a bNode is just a resource that nobody's bothered to give a URI... yet. I don't think that the vCard vocab should be *insisting* that these are bNodes rather than URIs. e.g. the following should be essentia... On Thu, 2009-09-17 at 10:36 +0200, Martin Hepp (UniBW) wrote: > I don't know whether I am in the Linked Data scene ;-), but I am > convinced that bNodes can be useful. As far as I'm concerned a bNode is just a resource that nobody's bothered to give a URI... yet. I don't think that the vCard vocab should be *insisting* that these are bNodes rather than URIs. e.g. the following should be essentially the same as far as vCard vocab consumers are concerned: <#me> v:tel [ a v:Home ; rdf:value "123456789" ] . and: <#me> v:tel <#homePhone> . <#homePhone> a v:Home ; rdf:value "123456789" . Indeed, it annoys me that [...] in SPARQL doesn't match nodes which have URIs. It's unintuitive. I'm CCing public-rdf-dawg-comments. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253196299.20274.43.camel%40ophelia2.g5n.co.uk RE: vCard RDF merge.... 2009-09-17T14:05:01 2009-09-17T14:05:01 2009-09-17T14:05:01 On Thu, 2009-09-17 at 11:28 +0000, Seaborne, Andy wrote: > Blank nodes in a SPARQL query are variables and, as such, should match > nodes in the graph being matched with URIs or literal or blank nodes > in the data. Drat! You are right, of course. And that's a good thing really. Perhaps it was a bad experience in one particular implementation that made me think that [...] wouldn't match URI node... On Thu, 2009-09-17 at 11:28 +0000, Seaborne, Andy wrote: > Blank nodes in a SPARQL query are variables and, as such, should match > nodes in the graph being matched with URIs or literal or blank nodes > in the data. Drat! You are right, of course. And that's a good thing really. Perhaps it was a bad experience in one particular implementation that made me think that [...] wouldn't match URI nodes. Or more likely some other error in my query caused it to fail and I ended up blaming the square brackets! But certainly ARQ seems to get things right. PS: Andy, you may be interested in running 'SELECT * WHERE { <http://demiblog.org/vocab/oauth#> rdfs:label ?label }' at <http://demiblog.org/_sparql> and requesting the result in text/turtle. It uses your result-set vocab. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253196664.20274.46.camel%40ophelia2.g5n.co.uk Re: Syntaxes of the mapping language 2009-09-17T14:11:05 2009-09-17T14:11:05 2009-09-17T14:11:05 On Thu, 2009-09-17 at 14:06 +0200, Simon Reinhardt wrote: > "The mapping language SHOULD have a human-readable syntax as well as > XML and RDF representations of the syntax for purposes of discovery > and machine generation." > > In my opinion this is way too many representations (given that RDF > itself has dozens of syntaxes already) which will be a huge burden on > the implementors. If the RD... On Thu, 2009-09-17 at 14:06 +0200, Simon Reinhardt wrote: > "The mapping language SHOULD have a human-readable syntax as well as > XML and RDF representations of the syntax for purposes of discovery > and machine generation." > > In my opinion this is way too many representations (given that RDF > itself has dozens of syntaxes already) which will be a huge burden on > the implementors. If the RDF syntax were the only normative one, a simplified XML syntax could perhaps be published as a Note with accompanying GRDDL transform. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253198658.20274.50.camel%40ophelia2.g5n.co.uk Re: HTML+RDFa (3.1 Document Conformance) 2009-09-17T14:44:19 2009-09-17T14:44:19 2009-09-17T14:44:19 On Wed, 2009-09-16 at 23:27 +0100, Mark Birbeck wrote: > So the exact same notation could be used in markup to indicate what > functionality a platform must support, in order to process the current > document. For example: > > @version="HTML RDFa" > > means 'this document will work on a DOM that supports any version of > HTML, and any version of RDFa'. > > @version="HTML RDFa 1.1" > > mean... On Wed, 2009-09-16 at 23:27 +0100, Mark Birbeck wrote: > So the exact same notation could be used in markup to indicate what > functionality a platform must support, in order to process the current > document. For example: > > @version="HTML RDFa" > > means 'this document will work on a DOM that supports any version of > HTML, and any version of RDFa'. > > @version="HTML RDFa 1.1" > > means 'this document will work on a DOM that supports any version of > HTML, but it must support _at least_ version 1.1 of RDFa'. @version="XHTML+RDFa 1.0" can be interpreted according to the above scheme if we allow for URL encoding. (ie. the plus sign is '%20') However, for many situations, it's enough to have a user agent that only supports RDFa (and not specifically XHTML), or only supports XHTML (and ignores the RDFa) to process an XHTML+RDFa 1.0 document. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253199637.20274.62.camel%40ophelia2.g5n.co.uk Re: FYI: RDFa extension to Semantic Media Wiki... 2009-09-17T15:00:37 2009-09-17T15:00:37 2009-09-17T15:00:37 On Thu, 2009-09-17 at 08:52 +0200, Ivan Herman wrote: > I did not know this existed! > http://www.mediawiki.org/wiki/Extension:RDFa Looks good. Think I might have mentioned them before, but I've written a few mediawiki patches and extensions to support RDFa: http://www.mediawiki.org/wiki/Extension:HTML_Profiles ... allows pages to use Wiki markup to declare a metadata profile. Needs a little ho... On Thu, 2009-09-17 at 08:52 +0200, Ivan Herman wrote: > I did not know this existed! > http://www.mediawiki.org/wiki/Extension:RDFa Looks good. Think I might have mentioned them before, but I've written a few mediawiki patches and extensions to support RDFa: http://www.mediawiki.org/wiki/Extension:HTML_Profiles ... allows pages to use Wiki markup to declare a metadata profile. Needs a little hook added to the skin to output <head profile> attribute. Includes RDFa profile by default. http://www.mediawiki.org/wiki/Extension:Link_Attributes http://buzzword.org.uk/2009/mediawiki-patches/LinkAttributes-hack.patch ... allows setting rel and rev values on links. http://buzzword.org.uk/2009/mediawiki-patches/relAlternate-semantics.patch ... adds @about to <link rel="alternate"> feed links to make it clear that they're not alternative versions of the current page. http://buzzword.org.uk/2009/mediawiki-patches/xhtml-rdfa.patch ... adds RDFa attributes, plus xmlns:* to Mediawiki's "whitelist" of allowed attributes. Also removes a bunch of <a name> elements - that's because those broke validation against the RDFa DTD. http://buzzword.org.uk/2009/mediawiki-patches/Sidebar-illegal-chars-fix.patch ... another validation fix. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CBC28491-26DE-4102-A281-FDE5C04EBE1B%40g5n.co.uk Re: Quick Update re. DBpedia RDFa pages 2009-09-18T20:46:01 2009-09-18T20:46:01 2009-09-18T20:46:01 On 18 Sep 2009, at 14:26, Kingsley Idehen wrote: > We've enhanced the initial release of DBpedia's HTML+RDFa pages. All the literals are @en. Would be nice to have a few xml:lang attributes where appropriate. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 18 Sep 2009, at 14:26, Kingsley Idehen wrote: > We've enhanced the initial release of DBpedia's HTML+RDFa pages. All the literals are @en. Would be nice to have a few xml:lang attributes where appropriate. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/61A13130-53E1-4FD3-993E-E0321F5E3F4B%40g5n.co.uk Re: My first RDFa Web example (products) 2009-09-18T20:57:19 2009-09-18T20:57:19 2009-09-18T20:57:19 On 18 Sep 2009, at 16:19, Manu Sporny wrote: > PS: RDFa community - both of these issues could have been easily > avoided > if we had a conformance checker. Anybody want to volunteer to write > one? Michael Hausenblas made a start at one: http://ld2sd.deri.org/vrdfa/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 18 Sep 2009, at 16:19, Manu Sporny wrote: > PS: RDFa community - both of these issues could have been easily > avoided > if we had a conformance checker. Anybody want to volunteer to write > one? Michael Hausenblas made a start at one: http://ld2sd.deri.org/vrdfa/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/469D9A39-F93A-4240-B254-8B376137249F%40g5n.co.uk Re: Request to publish HTML+RDFa (draft 3) as FPWD 2009-09-22T21:09:43 2009-09-22T21:09:43 2009-09-22T21:09:43 On 22 Sep 2009, at 21:50, Jonas Sicking wrote: > On Tue, Sep 22, 2009 at 1:43 PM, Jonas Sicking <jonas@sicking.cc> > wrote: > > >Sure, but if you have a DOM, what do you do? One solution is > certainly >> to say that "If you have a DOM, there is no way to extract RDFa >> data". >> This is certainly a possibility, but it does mean that it's >> impossible >> to > > ... to build a RDFa imple... On 22 Sep 2009, at 21:50, Jonas Sicking wrote: > On Tue, Sep 22, 2009 at 1:43 PM, Jonas Sicking <jonas@sicking.cc> > wrote: > > >Sure, but if you have a DOM, what do you do? One solution is > certainly >> to say that "If you have a DOM, there is no way to extract RDFa >> data". >> This is certainly a possibility, but it does mean that it's >> impossible >> to > > ... to build a RDFa implementation in javascript, as javascript is > handed a DOM. I don't know if javascript implementations of RDFa is > something that's considered important. I know of at least three Javascript implementations of RDFa parsers that each use the DOM: * The Operator add-on for Firefox * Jeni Tennison's rdfQuery library, based on jQuery * Ben Adida's implementation <http://www.w3.org/2006/07/SWD/RDFa/impl/js/20080817/> If, as you say, RDFa implementations "can't" use the DOM, it appears this is more of a "theoretical can't" rather than a "practical can't". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/869019E0-B126-43F6-AFAB-1126D09A6999%40g5n.co.uk Re: Request to publish HTML+RDFa (draft 3) as FPWD 2009-09-22T21:35:06 2009-09-22T21:35:06 2009-09-22T21:35:06 On 22 Sep 2009, at 22:14, Jonas Sicking wrote: > I think I found the code that extracts prefix mappings, and it appears > that it uses method 3. So my question is, why is this more correct > than any of the other 4 methods i proposed? I think you'll probably find that they all use "none of the above". None of the five methods you outlined match the method suggested (though not required - an... On 22 Sep 2009, at 22:14, Jonas Sicking wrote: > I think I found the code that extracts prefix mappings, and it appears > that it uses method 3. So my question is, why is this more correct > than any of the other 4 methods i proposed? I think you'll probably find that they all use "none of the above". None of the five methods you outlined match the method suggested (though not required - any other technique that produced the same end result is allowed) by the RDFa Syntax recommendation. The method suggested would be to check the current element for attributes whose first six characters match "xmlns:". No walking ancestor elements is needed if you follow the algorithm suggested by the recommendation. Exactly how to find these attributes which match those six characters is left up to the developer of the implementation - the developer will choose whichever method is most appropriate for the environment the implementation is expected to be run on. In terms of the DOM, I've found looping through the Node.attributes collection and checking the name property of each to be an effective method. That's the method I've used in Javascript and in Perl (libxml). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253706861.24136.10.camel%40ophelia2.g5n.co.uk Re: Request to publish HTML+RDFa (draft 3) as FPWD 2009-09-23T11:54:22 2009-09-23T11:54:22 2009-09-23T11:54:22 On Wed, 2009-09-23 at 09:52 +0100, Philip Taylor wrote: > So I believe these attributes (rel, rev, content, href, src) should > only be permitted on the elements that HTML5 currently permits them > on. Certainly it would be wise to consider the appearance of @href and @src on elements HTML5 does not currently permit them on to be non-conforming. They're allowed anywhere in XHTML+RDFa for essenti... On Wed, 2009-09-23 at 09:52 +0100, Philip Taylor wrote: > So I believe these attributes (rel, rev, content, href, src) should > only be permitted on the elements that HTML5 currently permits them > on. Certainly it would be wise to consider the appearance of @href and @src on elements HTML5 does not currently permit them on to be non-conforming. They're allowed anywhere in XHTML+RDFa for essentially two reasons: - RDFa was written with XHTML 2.0 compatibility in mind. In XHTML 2.0 it was planned that any element could be a link, and any could embed external images. Hence the attributes were allowed anywhere. - RDFa is also written to avoid mentioning specific HTML elements as much as possible. This is because it is intended to be usable with non-HTML markup languages, like SVG, ODF, DocBook, etc. The XHTML+RDFa processing algorithm only defines any special behaviour for <head> and <body>. However, disallowing @rel, @rev and @content from appearing on arbitrary elements would break current content which relies on the fact that they can, and break very useful RDFa authoring patterns. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253718897.24136.19.camel%40ophelia2.g5n.co.uk Re: Request to publish HTML+RDFa (draft 3) as FPWD 2009-09-23T15:14:58 2009-09-23T15:14:58 2009-09-23T15:14:58 On Wed, 2009-09-23 at 13:58 +0100, Philip Taylor wrote: > (I think restricting href is still > worthwhile, to prevent future confusion for HTML authors who don't > care about RDFa at all and expect href to make links and should get > validator errors when it doesn't.) As do I - in terms of the triples generated, @href and @src can always be directly replaced with @resource and @about, so there is... On Wed, 2009-09-23 at 13:58 +0100, Philip Taylor wrote: > (I think restricting href is still > worthwhile, to prevent future confusion for HTML authors who don't > care about RDFa at all and expect href to make links and should get > validator errors when it doesn't.) As do I - in terms of the triples generated, @href and @src can always be directly replaced with @resource and @about, so there is no reason to permit them on any element that HTML5 does not already permit them on. I don't see why the XHTML+RDFa 1.0 DTD permits them - I imagine it must have been an XHTML2 influence. RDFa processors should still allow those non-conforming uses to generate triples as per usual, but validators should report errors when they're seen. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253719733.24136.30.camel%40ophelia2.g5n.co.uk probable erratum - RDFA-SYNTAX 3.10. A description of RDFa in RDF terms 2009-09-23T15:28:53 2009-09-23T15:28:53 2009-09-23T15:28:53 The final paragraph of this section reads: > a subject [URI reference] is generally indicated using @about {...} > Objects which are [URI reference]s are represented using @href, > @resource or @src But @src is treated more like @about than it is like @href/@resource. Of course any of these four can in fact act as either a subject or an object - perhaps that point needs to be made as well. For... The final paragraph of this section reads: > a subject [URI reference] is generally indicated using @about {...} > Objects which are [URI reference]s are represented using @href, > @resource or @src But @src is treated more like @about than it is like @href/@resource. Of course any of these four can in fact act as either a subject or an object - perhaps that point needs to be made as well. For example, here @about acts as the object and @resource sets the subject: <div resource="[:Foo]"> <p rel=":example"> <span about="[:Bar]">bar</span> </p> </div> creating the triple: @prefix : <http://www.w3.org/1999/xhtml/vocab#> . :Foo :example :Bar . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1253780436.24136.34.camel%40ophelia2.g5n.co.uk Re: RDFa processing spec - clarification 2009-09-24T08:20:36 2009-09-24T08:20:36 2009-09-24T08:20:36 On Wed, 2009-09-23 at 21:11 +0200, Hondros, Constantine wrote: > I don't get what "the rule for @about" is that the text refers to ... > but I am guessing that the idea is to treat the empty @about as a > relative URI and resolve it against the value of BASE. So that in > effect BASE gets used as the subject of the triple if the current > element is <head> or <body> and there is no @about present... On Wed, 2009-09-23 at 21:11 +0200, Hondros, Constantine wrote: > I don't get what "the rule for @about" is that the text refers to ... > but I am guessing that the idea is to treat the empty @about as a > relative URI and resolve it against the value of BASE. So that in > effect BASE gets used as the subject of the triple if the current > element is <head> or <body> and there is no @about present. It means that when you hit the <head> or <body> elements, if they don't have an @about attribute, then pretend they include: about="" which is taken to be a relative URL, relative to the base URL of the document. In most cases (i.e. when <base href> is not specified) this will be the URL of the document itself. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/DABF5249-2177-40E5-80B6-FAFF229FA70A%40g5n.co.uk Re: how to consume linked data 2009-09-25T21:35:43 2009-09-25T21:35:43 2009-09-25T21:35:43 On 25 Sep 2009, at 07:41, Graham Klyne wrote: > Interesting... I'm doing work at the moment with CIDOC-CRM (http:// > cidoc.ics.forth.gr/) and its expression in OWL (http:// > www8.informatik.uni-erlangen.de/IMMD8/Services/cidoc-crm/ > versions.html). Have you seen Simon Reinhardt's recent OWL2 version? http://bloody-byte.net/rdf/cidoc-crm/index.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 25 Sep 2009, at 07:41, Graham Klyne wrote: > Interesting... I'm doing work at the moment with CIDOC-CRM (http:// > cidoc.ics.forth.gr/) and its expression in OWL (http:// > www8.informatik.uni-erlangen.de/IMMD8/Services/cidoc-crm/ > versions.html). Have you seen Simon Reinhardt's recent OWL2 version? http://bloody-byte.net/rdf/cidoc-crm/index.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20586.77.89.160.242.1254133930.squirrel%40goddamn.co.uk Re: tweet2rdf vocabulary convergence 2009-09-28T10:32:10 2009-09-28T10:32:10 2009-09-28T10:32:10 > There are multiple tools and services that convert twitter profiles > and contacts to RDF (e.g semantictweet[1] or knowee), I think they all > mostly re-use stuff from FOAF and don't really need new terms. A good place to start would be StatusNet. This is the open source software that powers identi.ca, and dozens of smaller microblogging sites. It has a slightly different feature set to Twitter... > There are multiple tools and services that convert twitter profiles > and contacts to RDF (e.g semantictweet[1] or knowee), I think they all > mostly re-use stuff from FOAF and don't really need new terms. A good place to start would be StatusNet. This is the open source software that powers identi.ca, and dozens of smaller microblogging sites. It has a slightly different feature set to Twitter, but is probably close enough. Importantly, it outputs RDF. Not everything is available in RDF (yet), but a lot of data is, including subscription data, hashtags, in-reply-to info, etc. Here is, for example, my FOAF file on identi.ca: http://identi.ca/tobyink/foaf And here's my RSS 1.0 file: http://identi.ca/tobyink/rss (There are currently problems with the <enclosure> elements in the RSS 1.0 feeds. There's a patch for this working its way into StatusNet's repository.) Some development code which may be of interest: http://gitorious.org/~tobyink/statusnet/statusnot/commit/d62b8ec987d7eaa331741e960d2c9c036a2d4df5 http://gitorious.org/~tobyink/statusnet/statusnot/commit/f77f3e7de2c7975116c3a996fde3df86d9839687 -Toby http://tobyinkster.co.uk/message/22064.77.89.160.242.1254140528.squirrel%40goddamn.co.uk Re: tweet2rdf vocabulary convergence 2009-09-28T12:22:08 2009-09-28T12:22:08 2009-09-28T12:22:08 > Anyone aware of other statusnet terms apart from postIcon? I've written a StatusNet patch which uses a statusnet:recipient property to link from a notice to an account that is the recipient of the notice. Definition (if there were a definition published) would be roughly: statusnet:recipient a rdf:Property ; rdfs:label "recipient" ; rdfs:domain sioc:Item ; rdfs:range sioc:User . This ... > Anyone aware of other statusnet terms apart from postIcon? I've written a StatusNet patch which uses a statusnet:recipient property to link from a notice to an account that is the recipient of the notice. Definition (if there were a definition published) would be roughly: statusnet:recipient a rdf:Property ; rdfs:label "recipient" ; rdfs:domain sioc:Item ; rdfs:range sioc:User . This patch hasn't yet been accepted into the main StatusNet code base, but I'm hopeful. Most people seem to agree this is potentially useful information to include in the RSS 1.0 feed, but it does add an additional database query to each notice included in the feed (and StatusNet includes 48 notices per feed by default). As feeds are typically re-requested frequently, this potentially adds a lot of extra work. Though the patch works nicely on my own system, I've requested a performance review from a larger installation of the StatusNet software. Other than that, postIcon is the only term currently used in the statusnet vocab. -Toby http://tobyinkster.co.uk/message/28057.77.89.160.242.1254154291.squirrel%40goddamn.co.uk Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1) 2009-09-28T16:11:31 2009-09-28T16:11:31 2009-09-28T16:11:31 > This has not yet triggered the end of the world, so presumably RDFa in > practice works fine without @version. It is not surprising that RDFa *currently* works in practice without the @version attribute, because *currently* only one version of RDFa is defined. -Toby > This has not yet triggered the end of the world, so presumably RDFa in > practice works fine without @version. It is not surprising that RDFa *currently* works in practice without the @version attribute, because *currently* only one version of RDFa is defined. -Toby http://tobyinkster.co.uk/message/1254177729.32171.30.camel%40ophelia2.g5n.co.uk Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1) 2009-09-28T22:42:09 2009-09-28T22:42:09 2009-09-28T22:42:09 On Mon, 2009-09-28 at 14:56 -0700, Maciej Stachowiak wrote: > Sounds to me like @version should be dropped as a mandatory document > conformance requirement, at least for HTML+RDFa, and probably for the > next version of XHTML+RDFa. It's already a SHOULD in both, not a MUST. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2009-09-28 at 14:56 -0700, Maciej Stachowiak wrote: > Sounds to me like @version should be dropped as a mandatory document > conformance requirement, at least for HTML+RDFa, and probably for the > next version of XHTML+RDFa. It's already a SHOULD in both, not a MUST. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1254209610.32171.32.camel%40ophelia2.g5n.co.uk Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1) 2009-09-29T07:33:31 2009-09-29T07:33:31 2009-09-29T07:33:31 On Mon, 2009-09-28 at 17:32 -0700, Jonas Sicking wrote: > I would personally recommend that RDFa follow the strategy that HTML > uses To only provide version identifiers for the first four versions? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2009-09-28 at 17:32 -0700, Jonas Sicking wrote: > I would personally recommend that RDFa follow the strategy that HTML > uses To only provide version identifiers for the first four versions? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1254228200.32171.38.camel%40ophelia2.g5n.co.uk Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1) 2009-09-29T12:43:21 2009-09-29T12:43:21 2009-09-29T12:43:21 On Tue, 2009-09-29 at 10:37 +0300, Henri Sivonen wrote: > On Sep 29, 2009, at 04:47, Mark Birbeck wrote: > > > My recollection of the TF's discussion around @version is that it was > > a way to allow RDFa consumers to decide whether they wanted to parse a > > page or not. > > It seems that you failed to allow it. A quick search through http://www.w3.org/TR/rdfa-syntax/ > for the string "versi... On Tue, 2009-09-29 at 10:37 +0300, Henri Sivonen wrote: > On Sep 29, 2009, at 04:47, Mark Birbeck wrote: > > > My recollection of the TF's discussion around @version is that it was > > a way to allow RDFa consumers to decide whether they wanted to parse a > > page or not. > > It seems that you failed to allow it. A quick search through http://www.w3.org/TR/rdfa-syntax/ > for the string "version" suggests that http://www.w3.org/TR/rdfa-syntax/ > doesn't define any processing for @version. Therefore, there's > nothing in the RDFa in XHTML spec that allows an RDFa processor to > halt processing depending on @version and fail to extract the triples > encoded in the document. But there's also nothing in the syntax document that requires it to *start* processing. So an RDFa processor can simply opt to not begin processing, depending on whatever factors it wants. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1254471733.2119.29.camel%40ophelia2.g5n.co.uk Re: Linked (genealogy) data 2009-10-02T08:22:14 2009-10-02T08:22:14 2009-10-02T08:22:14 On Thu, 2009-10-01 at 21:51 +0100, John Goodwin wrote: > I've been working on my family tree as linked data in my spare time. I've been looking at doing something similar but haven't gotten around to it yet. I have quite a bit on paper, but very little typed up. My plan was to enter everything into GRAMPS (a Linux genealogy tool), export as XML and then convert that to FOAF with a little scripti... On Thu, 2009-10-01 at 21:51 +0100, John Goodwin wrote: > I've been working on my family tree as linked data in my spare time. I've been looking at doing something similar but haven't gotten around to it yet. I have quite a bit on paper, but very little typed up. My plan was to enter everything into GRAMPS (a Linux genealogy tool), export as XML and then convert that to FOAF with a little scripting. A few comments on your implementation: * Individuals don't seem to link back families (i.e. "is foaf:member of"). * All your foaf:primaryTopic links seem to have accompanying foaf:topic links. This is probably unnecessary in the RDF itself, and certainly unnecessary in the HTML. OK, that didn't end up as "a few". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1254563965.3525.23.camel%40ophelia2.g5n.co.uk Re: ISSUE-41/ACTION-97 decentralized-extensibility 2009-10-03T09:59:30 2009-10-03T09:59:30 2009-10-03T09:59:30 On Fri, 2009-10-02 at 16:51 -0700, Maciej Stachowiak wrote: > Representatives of browser implementors other than Microsoft > have expressed reluctance to support a mechanism similar to XML > namespaces in text/html syntax for philosophical and technical > reasons. In particular, there are concerns about the usability of > prefix-based indirection for authors, and about the wisdom of allowi... On Fri, 2009-10-02 at 16:51 -0700, Maciej Stachowiak wrote: > Representatives of browser implementors other than Microsoft > have expressed reluctance to support a mechanism similar to XML > namespaces in text/html syntax for philosophical and technical > reasons. In particular, there are concerns about the usability of > prefix-based indirection for authors, and about the wisdom of allowing > unilateral extensions to the language in such a way that content using > them is still conforming. Perhaps the HTML5 specification could define the parsing of xmlns:* attributes, and element and attribute names containing colons, and represent them in the DOM in a namespaces-in-XML-like way, but declare their use to be non-conforming. There is precedent for the HTML5 spec to define non-trivial parsing and DOM representation requirements on non-conforming parts of the language: <frameset> and <applet> for instance [1][2]. Then people can write "other applicable specifications" [3] which use namespaces if they want to, safe in the knowledge that in user agents which don't implement the applicable specification, it will at least be parsed into the DOM properly. People using these other applicable specifications would not be writing conforming HTML5, but might be writing conforming, say, "HTML5+BeeKeepingML" or whatever. ____ 1. http://dev.w3.org/html5/spec/obsolete.html#frameset 2. http://dev.w3.org/html5/spec/obsolete.html#the-applet-element 3. http://dev.w3.org/html5/spec/infrastructure.html#other-applicable-specifications -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/8C089D56-51EA-4056-B585-9BAED24E15B1%40g5n.co.uk Re: Microdata vocabulary specifications 2009-10-05T07:12:19 2009-10-05T07:12:19 2009-10-05T07:12:19 On 4 Oct 2009, at 12:44, Ian Hickson wrote: > Incidentaly, a side-effect of this is that the HTML-to-Atom conversion > algorithm can no longer output valid Atom. It used to rely on the > vCard > vocabulary to get the value of <author>, but this is no longer > possible > since there's no reference to the vocabulary specs. An empty <atom:author> could be provided by the algorithm, though th... On 4 Oct 2009, at 12:44, Ian Hickson wrote: > Incidentaly, a side-effect of this is that the HTML-to-Atom conversion > algorithm can no longer output valid Atom. It used to rely on the > vCard > vocabulary to get the value of <author>, but this is no longer > possible > since there's no reference to the vocabulary specs. An empty <atom:author> could be provided by the algorithm, though this by itself is not useful. <link rel="author" could be used to add an <atom:url> or <atom:email> to the <atom:author>. That said, the weak semantics of rel="author" become a slight problem here. If there are multiple rel="author" links, does that indicate multiple authors, or multiple links for the same author, or even several authors each with several links? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1254746146.9495.26.camel%40ophelia2.g5n.co.uk Re: ISSUE-41/ACTION-97 decentralized-extensibility 2009-10-05T12:35:48 2009-10-05T12:35:48 2009-10-05T12:35:48 On Mon, 2009-10-05 at 15:09 +0300, Henri Sivonen wrote: > I think a stronger argument for why RDFa (or Microdata for that > matter) is inappropriate for this use case is that the RDF graph > represented by RDFa doesn't have data model-level correspondence to > particular elements in the DOM even though syntactically the graph and > the DOM are overlaid. RDF does have a model-level correspo... On Mon, 2009-10-05 at 15:09 +0300, Henri Sivonen wrote: > I think a stronger argument for why RDFa (or Microdata for that > matter) is inappropriate for this use case is that the RDF graph > represented by RDFa doesn't have data model-level correspondence to > particular elements in the DOM even though syntactically the graph and > the DOM are overlaid. RDF does have a model-level correspondence to particular elements in the DOM - it's just one that needs to be "triggered" explicitly rather than implicitly. To make RDF statements about an element, you give the element an 'id' attribute. This assigns a URI to that element, which you can use in triples. For example: <div xmlns:foaf="http://xmlns.com/foaf/0.1/" typeof="foaf:Person"> <h1 property="foaf:name">Bob</h1> <p>Bob's interests are...</p> <ul rel="foaf:interest"> <li><a href="#foo">Foo</a></li> <li><a href="#bar">Bar</a></li> </ul> </div> <div id="foo" about="#foo"> <h2 xmlns:core="http://purl.org/dc/terms/" property="core:title">Foo</h2> <p>... foo ...</p> </div> <div id="bar" about="#bar"> <h2 xmlns:core="http://purl.org/dc/terms/" property="core:title">Bar</h2> <p>... bar ...</p> </div> However, while this shows that the RDF graph can correspond to DOM elements when it wants to, I don't think RDFa is the answer to the problem of more generalised decentralised extensibility. To solve this more general problem, I do think that adopting XML's namespacing for elements and attributes into the HTML serialisation would be a good solution. Not only would it give us a flexible decentralised extensibility mechanism, but also it would reduce unnecessary differences between the XHTML and HTML serialisations, which is surely a big win. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CA2051D5-D50D-43AC-87A0-8BBFFF0D5817%40g5n.co.uk Fwd: [uf-discuss] Ident Engine 2009-10-07T21:47:00 2009-10-07T21:47:00 2009-10-07T21:47:00 Interesting... Begin forwarded message: > From: "Glenn Jones" <glenn.jones@madgex.com> > Date: 6 October 2009 13:06:59 BDT > To: <microformats-discuss@microformats.org> > Subject: [uf-discuss] Ident Engine > Reply-To: Microformats Discuss <microformats-discuss@microformats.org> > > Hi All > > I have built a little JavaScript library that combines Social Graph > data > and parsing of open data ... Interesting... Begin forwarded message: > From: "Glenn Jones" <glenn.jones@madgex.com> > Date: 6 October 2009 13:06:59 BDT > To: <microformats-discuss@microformats.org> > Subject: [uf-discuss] Ident Engine > Reply-To: Microformats Discuss <microformats-discuss@microformats.org> > > Hi All > > I have built a little JavaScript library that combines Social Graph > data > and parsing of open data sources such as microformats. > > http://identengine.com/ > http://www.alistapart.com/articles/discovering-magic/ > > Earlier this year Chris Messina made the passing comment that the > techniques I demoed involved too much hoop jumping to be of practical > use. I built this library to see if I could lower the barrier of > entry. > A List Apart published an article I have written on the libraries > architecture. > > The library makes extensive use of both the Google's Social Graph API > and Yahoo's YQL. It all under a MIT license > > Try out the demo's > > Glenn Jones > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss http://tobyinkster.co.uk/message/3AB7B69E-6BF1-4088-ACAC-29515F39BD57%40g5n.co.uk Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1) 2009-10-10T21:10:51 2009-10-10T21:10:51 2009-10-10T21:10:51 On 10 Oct 2009, at 12:04, Maciej Stachowiak wrote: > HTML 4.01 allowed a version attribute on <html>, but did not define > the syntax and made it deprecated. It is only allowed in the loose > DTD, not strict. > HTML 3.2 had a version attribute, did not specify it at all in > prose, and the DTD made it fixed to the value "-//W3C//DTD HTML 3.2 > Final//EN". > HTML 3.0 had a version attribut... On 10 Oct 2009, at 12:04, Maciej Stachowiak wrote: > HTML 4.01 allowed a version attribute on <html>, but did not define > the syntax and made it deprecated. It is only allowed in the loose > DTD, not strict. > HTML 3.2 had a version attribute, did not specify it at all in > prose, and the DTD made it fixed to the value "-//W3C//DTD HTML 3.2 > Final//EN". > HTML 3.0 had a version attribute, and in prose and the DTD made it > fixed to the value "-//W3O//DTD W3 HTML 3.0//EN". HTML 2.0 also had it, fixed as one of these, depending on which DTD you referenced: "-//IETF//DTD HTML 2.0//EN" "-//IETF//DTD HTML 2.0 Strict//EN" "-//IETF//DTD HTML 2.0 Level 1//EN" "-//IETF//DTD HTML 2.0 Strict Level 1//EN" -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/375E2B1D-AAC3-4F32-92E7-02890BE9C9E6%40g5n.co.uk Re: Drupal user profiles in RDFa 2009-10-12T11:42:50 2009-10-12T11:42:50 2009-10-12T11:42:50 On 11 Oct 2009, at 16:09, Stephane Corlosquet wrote: > We have 2 options to add RDFa to this link which both return the > same RDF data: > > <a href="/user/1" rel="sioc:has_creator foaf:maker" title="View > user profile." class="username"><span resource="/user/1" > typeof="sioc:User" property="foaf:name">Henry</span></a> > > or > > <span rel="sioc:has_creator foaf:maker"><a href="/d7sprint/... On 11 Oct 2009, at 16:09, Stephane Corlosquet wrote: > We have 2 options to add RDFa to this link which both return the > same RDF data: > > <a href="/user/1" rel="sioc:has_creator foaf:maker" title="View > user profile." class="username"><span resource="/user/1" > typeof="sioc:User" property="foaf:name">Henry</span></a> > > or > > <span rel="sioc:has_creator foaf:maker"><a href="/d7sprint/user/1" > typeof="sioc:User" property="foaf:name" title="View user profile." > class="username">Henry</a></span></span> foaf:maker is probably not what you want. foaf:maker's range is foaf:Agent, whereas a sioc:User is not a foaf:Agent, it's an account that a foaf:Agent holds. > Question for the RDFa ninjas reading this: is there a way to embed > all this information without adding a span tag either inside or > outside the a existing a tag. <a href="/user/1" title="View user profile." about="/user/1" typeof="sioc:User" rev="sioc:has_creator" resource="" property="foaf:name">Henry</a> > 2.1 Use a markup similar to the one above, but the cons is that > the user profile URI will not be dereferencable (and hereby > breaking one of the Linked Data principles). It will return a 403 > Access denied. > > <span rel="sioc:has_creator foaf:maker" class="username"><span > resource="/user/1" typeof="sioc:User" property="foaf:name">Henry</ > span></span> I think this is the right thing to do. > 3. In the case of a non registered user leaving a comment, Drupal > offers to leave her name, homepage and email address (though the > email address is not displayed for privacy reasons). The default > markup is: > > <a href="http://openspring.net/" rel="nofollow" > class="username">Stephane Corlosquet (not verified)</a> > > We don't have a user profile URI here, but a homepage which is > usually linked to a foaf:Person. Here we have multiple options > again to describe the author of a comment. I'm not sure we should > directly link a page to a foaf:Person, should we?. Do we have to > generate a foaf:OnlineAccount /sioc:User URI here based on the > homepage by adding #user to it? use a bnode? opinions? Assuming that you're still wanting to avoid that <span> element, the following would be reasonably consistent with the markup for people who have accounts: <a href="http://openspring.net/" about="_:bnode_001" typeof="sioc:User" rev="sioc:has_creator" resource="" property="foaf:name" content="Stephane Corlosquet" >Stephane Corlosquet (not verified)</a> This does *not* use the address <http://openspring.net/> in any triples though. It's ignored. If we include that <span>, then we can use the openspring.net address: <span rel="sioc:has_creator"> <a typeof="sioc:User" rel="foaf:page" href="http://openspring.net/" property="foaf:name" content="Stephane Corlosquet" >Stephane Corlosquet (not verified)</a> </span> (Note that I've used foaf:page instead of foaf:homepage because the latter is a very strong assertion, being an IFP. Stick with foaf:page for user-submitted content, otherwise OWL inference on your data will start to throw up some very strange conclusions.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/CE0B2CEA-0B30-4692-A464-1842B0B57D01%40g5n.co.uk Re: Drupal user profiles in RDFa 2009-10-12T11:51:51 2009-10-12T11:51:51 2009-10-12T11:51:51 On 12 Oct 2009, at 12:42, Toby Inkster wrote: >> 2.1 Use a markup similar to the one above, but the cons is that >> the user profile URI will not be dereferencable (and hereby >> breaking one of the Linked Data principles). It will return a 403 >> Access denied. >> >> <span rel="sioc:has_creator foaf:maker" class="username"><span >> resource="/user/1" typeof="sioc:User" property="foaf:n... On 12 Oct 2009, at 12:42, Toby Inkster wrote: >> 2.1 Use a markup similar to the one above, but the cons is that >> the user profile URI will not be dereferencable (and hereby >> breaking one of the Linked Data principles). It will return a 403 >> Access denied. >> >> <span rel="sioc:has_creator foaf:maker" class="username"><span >> resource="/user/1" typeof="sioc:User" property="foaf:name">Henry</ >> span></span> > > I think this is the right thing to do. You want @about here though. @about is for setting subjects, @resource is for setting objects. (It's possible to use them the other way around, but not a good idea usually.) My point though, was that, yes, I think it's fine to use URIs here which currently resolve to 403. That's an accurate representation of the situation (that the data exists but access is denied). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/39B1BB5D-FF8B-41D4-A3BE-0D00ABECAA41%40tobyinkster.co.uk Re: ANN: alternative to cURL for debugging URIs 2009-10-12T14:36:35 2009-10-12T14:36:35 2009-10-12T14:36:35 On 12 Oct 2009, at 15:02, Olaf Hartig wrote: > http://linkeddata.informatik.hu-berlin.de/uridbg/ I like. For debugging SPARQL it might be nice to have a GET/POST selector and a textarea to paste POSTed data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On 12 Oct 2009, at 15:02, Olaf Hartig wrote: > http://linkeddata.informatik.hu-berlin.de/uridbg/ I like. For debugging SPARQL it might be nice to have a GET/POST selector and a textarea to paste POSTed data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1255885173.21900.9.camel%40ophelia2.g5n.co.uk Re: SocialWeb anti-pattern wiki? today's annoyance: name too long/short/weird to fit 2009-10-18T16:59:39 2009-10-18T16:59:39 2009-10-18T16:59:39 On Sun, 2009-10-18 at 12:32 +0200, Dan Brickley wrote: > Greenpeace's site just refused to let me sign up, because my first > name - Dan - is too short. See screenshot at > http://www.flickr.com/photos/danbri/4022025450/ ... That's one of the stupidest forms I've seen in a long while. My first name is 4 letters long (and despite what some assume, not a shortened form of Tobias in my case). My wife (Anna) would have problems too. I wonder if their executive director has ever tried using their website? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 2009-10-18 at 12:32 +0200, Dan Brickley wrote: > Greenpeace's site just refused to let me sign up, because my first > name - Dan - is too short. See screenshot at > http://www.flickr.com/photos/danbri/4022025450/ ... That's one of the stupidest forms I've seen in a long while. My first name is 4 letters long (and despite what some assume, not a shortened form of Tobias in my case). My wife (Anna) would have problems too. I wonder if their executive director has ever tried using their website? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256077200.7123.18.camel%40ophelia2.g5n.co.uk subscribe 2009-10-20T22:20:01 2009-10-20T22:20:01 2009-10-20T22:20:01 subscribe -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> subscribe -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256081314.7123.42.camel%40ophelia2.g5n.co.uk Re: CONFIRM s3196931709 2009-10-20T23:28:35 2009-10-20T23:28:35 2009-10-20T23:28:35 On Tue, 2009-10-20 at 22:20 +0000, public-egov-ig-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-egov-ig mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-egov-ig-request@... On Tue, 2009-10-20 at 22:20 +0000, public-egov-ig-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-egov-ig mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-egov-ig-request@w3.org > > with the Subject string: > > CONFIRM s3196931709 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed above > will be (un)subscribed. If the address above is incorrect, please do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event that > you did not send a request to (un)subscribe, the headers of the message > may help you discover who sent the request. > > > >From tai@g5n.co.uk Tue Oct 20 22:20:43 2009 > >Received: from maggie.w3.org ([193.51.208.68]) > > by frink.w3.org with esmtp (Exim 4.63) > > (envelope-from <tai@g5n.co.uk>) > > id 1N0N4N-0008F0-Nn > > for public-egov-ig-request@listhub.w3.org; Tue, 20 Oct 2009 22:20:43 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by maggie.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1N0N4K-0004kh-H0 > > for public-egov-ig-request@w3.org; Tue, 20 Oct 2009 22:20:43 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 72147115BC1 > > for <public-egov-ig-request@w3.org>; Tue, 20 Oct 2009 23:20:09 +0100 (BST) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, port 10025) > > with ESMTP id mCmjkORIyDzC for <public-egov-ig-request@w3.org>; > > Tue, 20 Oct 2009 23:20:02 +0100 (BST) > >Received: from [127.0.0.1] (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id CCBD7115BBF > > for <public-egov-ig-request@w3.org>; Tue, 20 Oct 2009 23:20:01 +0100 (BST) > >Subject: subscribe > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-egov-ig-request@w3.org > >Content-Type: text/plain > >Date: Tue, 20 Oct 2009 23:20:00 +0100 > >Message-Id: <1256077200.7123.18.camel@ophelia2.g5n.co.uk> > >Mime-Version: 1.0 > >X-Mailer: Evolution 2.22.3.1-1.1mdv2008.1 > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: maggie.w3.org 1N0N4K-0004kh-H0 8cb670fc4a3f6b148317fda884be0207 > > > >subscribe > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256113569.7123.50.camel%40ophelia2.g5n.co.uk Re: ISSUE-76: Need feedback on splitting Microdata into separate specification 2009-10-21T08:26:09 2009-10-21T08:26:09 2009-10-21T08:26:09 On Tue, 2009-10-20 at 19:07 -0700, Maciej Stachowiak wrote: > I also agree with Sam that Microdata is in the same boat, by virtue of > being published as a Working Draft. Has the HTML WG really made the same commitment to Microdata? Microdata was a *feature* of HTML in the recent HTML5 WD, but was not published as a WD in its own right. If publishing a WD commits us to retaining every feature of... On Tue, 2009-10-20 at 19:07 -0700, Maciej Stachowiak wrote: > I also agree with Sam that Microdata is in the same boat, by virtue of > being published as a Working Draft. Has the HTML WG really made the same commitment to Microdata? Microdata was a *feature* of HTML in the recent HTML5 WD, but was not published as a WD in its own right. If publishing a WD commits us to retaining every feature of it, then I guess <dialog> will be making a comeback? Splitting out Microdata as a separate WD would actually secure its place in the HTML5 WG's work, committing us to taking it to Rec or Note status (eventually). Until that happens (and based on my, admittedly limited understanding of the W3C process) the HTML WG has made no commitment to keep Microdata. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256114908.7123.63.camel%40ophelia2.g5n.co.uk Re: RDFa API for browsers 2009-10-21T08:48:29 2009-10-21T08:48:29 2009-10-21T08:48:29 On Tue, 2009-10-20 at 23:57 -0400, Manu Sporny wrote: > The conversation started when I pointed out that we might want to > start focusing on an RDFa API for Javascript running in browsers since > Mozilla seems to be open to implementing the Microdata API[3]. Just some ideas... // Query the union of all data found on the page: var r = document.meta().query('SELECT ?foo WHERE ...'); // Just qu... On Tue, 2009-10-20 at 23:57 -0400, Manu Sporny wrote: > The conversation started when I pointed out that we might want to > start focusing on an RDFa API for Javascript running in browsers since > Mozilla seems to be open to implementing the Microdata API[3]. Just some ideas... // Query the union of all data found on the page: var r = document.meta().query('SELECT ?foo WHERE ...'); // Just query the data found in RDFa: var r = document.meta('rdfa').query('SELECT ?foo WHERE ...'); for (var i in r) { // r[i].foo typeof 'RDFNode'. if (r[i].foo.type == 'literal') window.alert(r[i].foo.datatype); } // Get the RDFa data as a RDF/JSON-like object: var data = document.meta('rdfa').data; // Get the RDFa data as an array of triples: var triples = document.meta('rdfa').triples; for (var i in triples) { // each triple has subject, object, predicate and graph properties var g = triples[i].graph; // named graph URI var s = triples[i].subject; // RDFNode.token returns a Turtle-like token // (i.e. URIs in <>, literals in "", bnodes start _:). if (s.type != 'bnode') window.alert(s.token); } // Can also grab data from Microdata and GRDDL if the browser // supports those. var data = document.meta('grddl').data; var r = document.meta('items').query('SELECT ?foo WHERE ...'); -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256117909.7123.67.camel%40ophelia2.g5n.co.uk ACTION [DONE]: tinkster to summarize Evan's talk 2009-10-21T09:38:30 2009-10-21T09:38:30 2009-10-21T09:38:30 Summary of Evan Prodromou's talk with the W3C Social Web Incubator Group ======================================================================== [2009-10-07] Evan Prodromou is the developer of the OpenMicroBlogging specification (OMB), currently at version 0.1, with version 0.2 on the way. He is also the lead developer of StatusNet (formerly known as laconica), which is the highest profile impl... Summary of Evan Prodromou's talk with the W3C Social Web Incubator Group ======================================================================== [2009-10-07] Evan Prodromou is the developer of the OpenMicroBlogging specification (OMB), currently at version 0.1, with version 0.2 on the way. He is also the lead developer of StatusNet (formerly known as laconica), which is the highest profile implementation of OMB. identi.ca is the biggest installation of the StatusNet software, which is operated by Evan's company, StatusNet Inc. He was also involved with MediaWiki (contributed the popular OpenID plugin) and WikiTravel (open content travel guide wiki). With the launch of Twitter in 2007, there was an explosion of interest in Microblogging, which is defined as the exchange of small (usually 140 character limit) text messages with your social network. Evan didn't see anyone else doing it, so he started an open source immplementation. StatusNet includes various features thought to be important to an open social web: - OpenID - FOAF - Atom / RSS StatusNet is designed to be run on commodity servers - i.e. "LAMP stack". Federation is an important feature. People with their accounts on one server can subscribe to accounts on other servers. Initially Evan looked at OpenID attribute exchange to accomplish this, but it didn't work out. Instead, it's an OAuth extension. There are four key players in the OMB remote subscription process: the publisher, the subscriber, the publisher's server and the subscriber's server. The process: 1. The subscriber provides the HTTP URL of their profile to the publisher's server 2. The publisher's server looks up the URL using OAuth discovery (XRD Simple). 3. The subscriber does the OAuth dance to authorise the publisher's server to push messages through to the subscriber's server. 4. The subscriber's server notifies the publisher's server that the subscription has been authorised and passes back the subscriber's details (name, avatar, etc). 5. Thereafter, the publisher's server will use an API on the subscriber's server to push new notices, and publisher's profile updates through to the subscriber's server. Over the wire, notices are defined to be plain text, even though OMB installations tend to ascribe particular semantics to certain patterns such as #hashtags and @replies. Important considerations for OMB version 0.2: - No system for unsolicited notices. If Alice isn't subscribed to Bob, there's no way that Bob can get a message to her. - Although StatusNet installations internally track threaded conversations, this information isn't sent over OMB, so threads between multiple installations don't work properly. - Replace deprecated use of XRD Simple with LRDD. - Push notices as Atom entries instead of plain text: * include full HTML versions of messages between installations, making #hashtags and @replies more reliable. * allows use of Atom threading extension. - Some sort of security issue that Toby doesn't quite understand. - Possibly some sort of activitystrea.ms work. Further along the lines, server-to-server communication via XMPP might be a possibility. Google Wave might also be something to look at. Subscribers having to provide their profile URLs has usability consequences. Can this be done in a better way? Evan is keeping an eye on WebFinger. Relationship to SMOB (Semantic Microblogging) <http://smob.sioc-project.org/>: SMOB does a really great job of publishing info, but doesn't have any server-to-server interaction defined. There is certainly potential for working together. OMB in SMOB would be very welcome. FOAF and Semantic Web tech may be useful for various features going forward. Answering the question "who *should* I be subscribed to?" There are plans to make geolocation part of the OMB/StatusNet platform. Each profile will have a location associated with it (it already does, but only as a plain text string), and each notice will too, indicating the location the publisher sent it from. [Toby adds: Possibly also a way of tagging notices with locations would be usefule. e.g. I'm not in London right now, but this notice is tagged London because it's about that place.] Will use geonames/Where on Earth/OpenStreetMap. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256121787.7123.88.camel%40ophelia2.g5n.co.uk Re: RDFa API for browsers 2009-10-21T10:43:08 2009-10-21T10:43:08 2009-10-21T10:43:08 On Wed, 2009-10-21 at 11:12 +0100, Mark Birbeck wrote: > This is interesting...why would you prefer to keep the triples from > different formats separate? > > I'm not saying you shouldn't. :) It might speed up practical implementations. If you only use RDFa on your page, then calling: document.meta('RDFa').whatever(); means that the browser doesn't need to waste its time checking all the pag... On Wed, 2009-10-21 at 11:12 +0100, Mark Birbeck wrote: > This is interesting...why would you prefer to keep the triples from > different formats separate? > > I'm not saying you shouldn't. :) It might speed up practical implementations. If you only use RDFa on your page, then calling: document.meta('RDFa').whatever(); means that the browser doesn't need to waste its time checking all the page's profile URIs (if any are given) for GRDDL profileTransformations, and namespace declarations (which will almost certainly be given on any page that uses RDFa) for GRDDL namespaceTransformations. Also, if different browsers support different serialisations (e.g. RDFa, GRDDL, Microdata, eRDF, etc), testing whether document.meta('RDFa') is empty might be a useful tool. > It's just that I've always worked on the assumption that everyone > would want all the metadata to be bundled into one common, queryable > location. I imagine that most people would, yes. That's why I showed meta() with no parameters to return the union graph. > > for (var i in r) > > { > > // r[i].foo typeof 'RDFNode'. > > if (r[i].foo.type == 'literal') > > window.alert(r[i].foo.datatype); > > } > > My preference here is for the default mode to be JSON objects. If you > look at it from the point of view of a JS programmer, then a query is > essentially a request to construct an array of JSON objects, that are > based on a certain template. > > For example, a query for "?name" is really a request to create an > array of objects, each with the single property "name": > > [ > { > name: "Toby Inkster" > }, > { > name: "Manu Sporny" > } > ] This is essentially the same as what I'm suggesting, but they'd get back: [ { "name": { "value" : "Toby Inkster" , "type" : "literal" , "lang" : "en" } } , {  "name": { "value" : "Manu Sporny" , "type" : "literal" , "lang" : "en" } } ] This is pretty similar to the SPARQL Results JSON serialisation <http://www.w3.org/TR/rdf-sparql-json-res/> and RDF/JSON <http://n2.talis.com/wiki/RDF_JSON_Specification>, both of which are pretty widely implemented and supported. The main difference would be that these objects like {  "value" : "Manu Sporny" , "type" : "literal" , "lang" : "en" } would also have some object methods defined, such as ".token()" which outputs a Turtle-compatible token. > There's no need for our JavaScript authors to be testing types, etc. > -- they should get back an immediately usable set of objects. > > I know people are going to say "what about the difference between URIs > and literals?", "what about data types?"...and so on. If people care about whether things are URIs or literals, and what datatype has been used, and the language, then they can look at .type, .datatype and .lang. If they don't care, they can just look at .value and ignore the rest. > For example: > > [ > { > name: "Toby Inkster", > foo: 17 > }, > { > name: "Manu Sporny", > bar: 93.25, > action: function () { > ... > } > } > ] > > As you can see, the principle is always to make the object feel > 'natural' to a JS programmer, and in a sense to conceal its RDF > origins. I can see the value in "flattening" the structure, so that { "value" : "foo" , "type" : "blah" } just becomes a simple string "foo", but the problem is that it's impossible to go the other way - to get back to the unflattened structure reliably. If the outer array was replaced by an iterator object that could act like an array but have methods, then your flattened structure could be returned using: var r = document.meta.query('...').simple(); I wonder how much of this could be prototyped in a Javascript library before browser pick it up? (And to allow scripts using document.meta to function in older browsers.) Probably quite a lot. GRDDL might be difficult because of cross-site requests. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256137716.7123.89.camel%40ophelia2.g5n.co.uk Re: ARIA roles added to the a element should be conforming in HTML5. 2009-10-21T15:08:42 2009-10-21T15:08:42 2009-10-21T15:08:42 On Wed, 2009-10-21 at 15:23 +0200, Thomas Broyer wrote: > Oh, and, how about flagging <a href="javascript:..."> as an error? (or > at least a warning), as it's hardly a "link" It arguably is in the (very occasional) case of so-called bookmarklets. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2009-10-21 at 15:23 +0200, Thomas Broyer wrote: > Oh, and, how about flagging <a href="javascript:..."> as an error? (or > at least a warning), as it's hardly a "link" It arguably is in the (very occasional) case of so-called bookmarklets. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256166818.7123.151.camel%40ophelia2.g5n.co.uk [Fwd: [Social-discuss] A missive - thoughts on a distributed social network] 2009-10-21T23:13:40 2009-10-21T23:13:40 2009-10-21T23:13:40 Just posted this to the GNU Social mailing list. I use a different e-mail address to subscribe to W3C mailing lists (W3C listserv doesn't like my usual address), so I couldn't CC it here, hence forwarding it instead. -Toby -------- Forwarded Message -------- > From: Toby Inkster <mail@tobyinkster.co.uk> > To: social-discuss@nongnu.org > Subject: [Social-discuss] A missive - thoughts on a distri... Just posted this to the GNU Social mailing list. I use a different e-mail address to subscribe to W3C mailing lists (W3C listserv doesn't like my usual address), so I couldn't CC it here, hence forwarding it instead. -Toby -------- Forwarded Message -------- > From: Toby Inkster <mail@tobyinkster.co.uk> > To: social-discuss@nongnu.org > Subject: [Social-discuss] A missive - thoughts on a distributed social > network > Date: Thu, 22 Oct 2009 00:00:30 +0100 > > Darling everybody, > > I promised Matt that I'd pop my head in and provide my thoughts on > distributed a social network. I think it's a great idea, but alas I > don't think I have any time to contribute to it in any practical way, so > my thoughts are all you're likely to get. > > When I first started using the Internet it was via AOL. Our family used > that for a year or so before moving to a real ISP. That experience > taught me that walled garden social networks are not a Good Thing. > Consequently, you'll find me on very few of them. I don't have a > Facebook account; I don't have a Myspace account; I think I have a > del.icio.us account, but have not really used it. Because I don't have > much experience using "social network sites", I think perhaps I might > bring a different perspective to this discussion, based on different > preconceptions of how a social network should behave. > > I'd also like to state that my interests lie not so much in building > social networks, but making our existing network more social. > > Moving swiftly on, here are my thoughts on how *I'd* approach building > something like daisycha.in, if I were in charge, and if I had the time. > > Firstly, federation is a must. I should be able to run my own account on > my own server, and connect up with other people running software on > their own servers, or shared servers. > > Another feature is extensibility. This is entangled up with an idea that > Dan Brickley's been going on about a bit recently - the idea that geeks > shouldn't decide how everyone describes themselves. For instance, say > that in our federated network, two servers need to exchange profile > information about their users: there will be fields like "name", > "avatar", "email" being passed about. The protocol designers shouldn't > decide which fields are allowed and which are optional. The end users > should, or at the very least, the people running the servers should. > What fields are important to you and me might not be important to other > people. > > Privacy and security are important, and related. I should be able to > share data with my social network, reasonably confident that it won't be > leaked outside my circle - at least, not without a conscious decision > from one of my friends to deliberately pass it on. (Clearly, this last > possibility is always going to be a privacy hole - there isn't a > sensible technical fix for it.) > > Anyway, those are fairly abstract ideas, but important to state. Now for > more practical matters. What should this distributed social network > actually do? > > Firstly, I'd want to publish profile-type information about me. Some > profile information I want to be public, so people can find it (perhaps > through Google). Other profile information I want to only be available > to my friends, or maybe just to a subset of them. > > Secondly, I want to publish items of content. These might be short, > microblog-like bits of text; they might be photos, videos or audio > clips; they might be links to things I've found on the Web. Again, some > of these I might elect to make public, and others I'd want to keep > private. > > I want to, of course, be able to view my friends' profiles, and be kept > informed of the items of content that they publish, in some sort of > aggregated view, so that I don't need to go and visit each of their > pages individually. > > Lastly, I'd need a way to manage these friends and contacts. A way of > blocking access from some people; a way of establishing a relationship > with others. > > So what would a web application that let me do this actually look like? > Here's my suggestion. It would consist of two loosely-related parts: > > 1. A publication tool; > 2. A feed aggregator. > > Each of these would be functionally fairly independent, though for > usability's sake, they would probably provide a fairly integrated user > experience. A third part of the platform which would need to have ties > to both is an API for adding and approving friendships. > > Using the publication tool I'd publish my profile data and content > items. The publication tool would allow me to configure access control > to different bits of data. This wouldn't have to be tricky ACL-type > stuff: a mere "this is public"/"only my friends" drop down would cover > the majority of use cases. > > Crucially the publication tool would be outputting the data using FOAF > and RSS 1.0, embedded in RDFa. Using RDF gives us our extensibility - > RDF is a framework built to represent data of all kinds. There's a whole > host of off-the-shelf libraries, parsers, databases, query engines and > so on that it opens up. Specifically for daisycha.in I'd recommend ARC2, > a PHP+MySQL RDF toolkit. > > The output XHTML+RDFa files would be simply published to a location on > the public Web, albeit with the non-public ones using HTTP > authentication. This would be Googleable and could indeed not only act > as your social networking profile but as your personal web site as well. > > The aggregator would visit the XHTML+RDFa-enabled profiles of all your > friends, parse their information and present it in a unified view for > your consumption. As these people have confirmed your friendship, your > aggregator will have access to their private profile data and content > items too. > > Those parts are actually pretty easy. We're left with two gaps: > > 1. Managing friendships; > 2. Push updates of new content. > > To manage friendship, OpenMicroBlogging's method might be a possibility, > but it's not really intended for symmetrical relationships. Here's > another possibility... > > Assuming Alice and Bob want to become friends; their profiles are hosted > on separate sites. Alice finds Bob's profile through Google and copies > and pastes hist profile's URL into her friendship manager. This > publishes a friendship "claim" to her profile (i.e. her profile says > that Alice claims to be Bob's friend). Alice's friendship manager then > pings Bob's server. Bob's server receives a ping from Alice's server and > fetches Alice's profile. It notes the friendship claim and puts that in > a queue of claims to verify for Bob. Next time Bob logs in, he sees the > claim and approves it. Bob's server pings Alice's to let it know the > friendship was approved. Alice's server lists Bob as Alice's friend. It > returns a success message to Bob's server. Bob's server gets the success > message and adds Alice as Bob's friend. > > For aggregating your friends' content, clearly a push model would be > more efficient than polling. Something like PubSubHubBub might work > here. > > The great thing about all this is that, even without any special > software at all, you can join in the social network. If you only want to > publish public profile and content data, then you can make do by > publishing static XHTML+RDFa files. It's only once you get into the more > complex area of making friends that you need to have any server-side > scripting involved. > > Anyway, that's how I'd do it, if it were me. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256225134.7123.199.camel%40ophelia2.g5n.co.uk New Scientist, 17 October 2009-10-22T15:25:35 2009-10-22T15:25:35 2009-10-22T15:25:35 These two articles in last weekend's New Scientist might be of interest to people here... Virtual workforce found in Kenyan refugee camp http://www.newscientist.com/article/mg20427305.700-refugees-set-to-tap-demand-for-virtual-workforce.html > Later this month, cellphone users in Kenya will be able to sign up to > txteagle, another remote-working service that distributes translation > and image ... These two articles in last weekend's New Scientist might be of interest to people here... Virtual workforce found in Kenyan refugee camp http://www.newscientist.com/article/mg20427305.700-refugees-set-to-tap-demand-for-virtual-workforce.html > Later this month, cellphone users in Kenya will be able to sign up to > txteagle, another remote-working service that distributes translation > and image tasks by cellphone. Nathan Eagle, a cellphone technology > researcher at the Santa Fe Institute in New Mexico and the developer > of txteagle, estimates that 15 million Kenyans will be interested in > taking part. The pocket spy: Will your smartphone rat you out? http://www.newscientist.com/article/mg20427301.100-the-pocket-spy-will-your-smartphone-rat-you-out.html > So just how secure is the data we store on our phones? If we are > starting to use them as combined diaries and wallets, what happens if > we lose them or they are stolen? And what if we simply trade in our > phones for recycling? > > According to the UK government's Design and Technology Alliance > Against Crime (DTAAC), 80 per cent of us carry information on our > handsets that could be used to commit fraud - and about 16 per cent of > us keep our bank details on our phones. I thought my Nokia N96 would > hold few surprises, though, since I had only been using it for a few > weeks when I submitted it to DiskLabs. Yet their analysts proved me > wrong. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256294020.7123.219.camel%40ophelia2.g5n.co.uk Re: [foaf-dev] RDF/RDFa now part of Drupal core 2009-10-23T10:33:41 2009-10-23T10:33:41 2009-10-23T10:33:41 On Thu, 2009-10-22 at 14:02 -0400, Stephane Corlosquet wrote: > A blog post with comments http://drupalrdf.openspring.net/node/3 """ <http://drupalrdf.openspring.net/node/3> a sioct:Weblog . """ Should be sioct:BlogPost I think. > Forum page http://drupalrdf.openspring.net/node/4 """ <http://drupalrdf.openspring.net/node/4> a sioct:ForumTopic, sioct:Post . """ SIOC defines neither of those ty... On Thu, 2009-10-22 at 14:02 -0400, Stephane Corlosquet wrote: > A blog post with comments http://drupalrdf.openspring.net/node/3 """ <http://drupalrdf.openspring.net/node/3> a sioct:Weblog . """ Should be sioct:BlogPost I think. > Forum page http://drupalrdf.openspring.net/node/4 """ <http://drupalrdf.openspring.net/node/4> a sioct:ForumTopic, sioct:Post . """ SIOC defines neither of those types. You probably want sioct:BoardPost and/or sioc:Post. """ <http://drupalrdf.openspring.net/forum/4> a sioct:Container . """ Also not defined. sioc:Container is what you want, though you could go more specific with sioc:Forum or sioct:MessageBoard. > Static page http://drupalrdf.openspring.net/about Looks good. Comments that apply to all the pages: 1. Would be nice to include http://www.w3.org/1999/xhtml/vocab in the <head profile> as recommended by XHTML+RDFa spec. 2. This: <meta property="dc:title" content="About" about="/about" /> <title>About | RDFa in Drupal testing site</title> could be combined into one element: <title about="/about" property="dc:title" content="About" >About | RDFa in Drupal testing site</title> 3. And in the above, the @about attribute is not really needed, as RDFa's default subject URI is the page itself. <title property="dc:title" content="About" >About | RDFa in Drupal testing site</title> Though I don't claim to know much about Drupal's internal architecture. Perhaps there is an important reason to be explicit about the subject URI (e.g. the content can be served up at multiple locations). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256300845.7123.234.camel%40ophelia2.g5n.co.uk Re: ISSUE-41/ACTION-97 decentralized-extensibility 2009-10-23T12:27:25 2009-10-23T12:27:25 2009-10-23T12:27:25 On Fri, 2009-10-23 at 12:54 +0200, Leif Halvard Silli wrote: > Profiles defines semantics for existing HTML features. I think the new > data-* attribute will be incorporated into profiles. Hmmm... this is a good point. User agents could be allowed to assign explicit semantics to certain data-* attributes when an author has opted in via a known profile URI. This gives us distributed extensibilit... On Fri, 2009-10-23 at 12:54 +0200, Leif Halvard Silli wrote: > Profiles defines semantics for existing HTML features. I think the new > data-* attribute will be incorporated into profiles. Hmmm... this is a good point. User agents could be allowed to assign explicit semantics to certain data-* attributes when an author has opted in via a known profile URI. This gives us distributed extensibility for attributes, but not for elements. (However, @class can be used as a way to perform the equivalent of distributed extensibility for elements.) So, for example, instead of: <geo:Point xmlns:geo="http://example.com/geo/namespace" geo:lat="50.878000" geo:long="0.005000" /> People could use: <head profile="http://example.com/geo/profile"> [...] <span class="point" data-lat="50.878000" data-long="0.005000" ></span> The presence of the profile URI would license geospatially-aware HTML user agents to do magical things with the class and data-* attributes. Without the profile URI, user agents must respect the fact that class and data-* have only locally defined meaning. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256311057.7123.292.camel%40ophelia2.g5n.co.uk Re: Requesting the RDF MIME type of an image 2009-10-23T15:17:37 2009-10-23T15:17:37 2009-10-23T15:17:37 On Fri, 2009-10-23 at 15:02 +0100, Mischa Tuffield wrote: > Which you can perform content negotiation on, so that if you : > request "Accept:application/rdf+xml" you would get back RDF > and if you request html you would get back an HTML doc, perhaps an > html page with the image, and a human readable representation of all > of the metadata. > and if you request image/jpeg (or whatever the c... On Fri, 2009-10-23 at 15:02 +0100, Mischa Tuffield wrote: > Which you can perform content negotiation on, so that if you : > request "Accept:application/rdf+xml" you would get back RDF > and if you request html you would get back an HTML doc, perhaps an > html page with the image, and a human readable representation of all > of the metadata. > and if you request image/jpeg (or whatever the correct MIME type is > for a .jpg file) you would get back the Image itself. > This would allow you to change the file format of your picture if ever > need be (i.e. from .jpg to .png for example), keeping the URI of the > image constant and neutral to file format. I don't think this is a sensible way to use content negotiation. An RDF file and an image are probably not representations of the same resource; so they should not share a URI. (With the possible edge-case of an image which is the visualisation of an RDF graph.) Perhaps: GET /images/example HTTP/1.1 Accept: image/png, image/jpeg, image/*;q=0.5 should return the JPEG, but: GET /images/example HTTP/1.1 Accept: application/rdf+xml should return a 303 See Other to a different URL (e.g. </data/images/example> or </images/example;about>) which would provide an RDF description of the image. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256315751.7123.315.camel%40ophelia2.g5n.co.uk Re: [foaf-dev] RDF support for anonymous users in Drupal 2009-10-23T16:35:52 2009-10-23T16:35:52 2009-10-23T16:35:52 On Fri, 2009-10-23 at 11:48 -0400, Stephane Corlosquet wrote: > To keep things simple, I'm very tempted to reuse the sioc:User mapping > we already have for the regular registered user. Is it ok not to use a > foaf:Agent or foaf:Person in this case, and link a sioc:User to a > homepage with foaf:page? sioc:has_creator links to a sioc:User by definition, not to a foaf:Agent or foaf:Person. By the... On Fri, 2009-10-23 at 11:48 -0400, Stephane Corlosquet wrote: > To keep things simple, I'm very tempted to reuse the sioc:User mapping > we already have for the regular registered user. Is it ok not to use a > foaf:Agent or foaf:Person in this case, and link a sioc:User to a > homepage with foaf:page? sioc:has_creator links to a sioc:User by definition, not to a foaf:Agent or foaf:Person. By the way, on http://drupalrdf.openspring.net/node/3 the sioc:reply_of links aren't getting picked up. They're "masked" by the property="content:encoded" of the parent <div> element. A slightly annoying feature of RDFa is that any property which results in an rdf:XMLLiteral causes any RDF on descendant elements to be ignored. Possible solution... Drop this: <span rel="sioc:reply_of" resource="/node/3" /> Change this (lines wrapped for readability): <h3 property="dc:title" datatype=""> <a href="/comment/1#comment-1">a first comment to the blog post</a> </h3> To this: <h3 property="dc:title" datatype=""> <a about="/node/3" rel="sioc:has_reply" rev="sioc:reply_of" href="/comment/1#comment-1"> a first comment to the blog post </a> </h3> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256323393.7123.325.camel%40ophelia2.g5n.co.uk Re: Empty span/div tags in RDFa pages 2009-10-23T18:43:14 2009-10-23T18:43:14 2009-10-23T18:43:14 On Fri, 2009-10-23 at 14:12 -0400, Stephane Corlosquet wrote: > There are only 10 EMPTY tags in HTML 1.0, and neither div nor span is > part of these. I looked in XHTML 1.1 and didn't find anything. The > RDFa DTD [2] does not declare new EMPTY tags either. Can someone point > me to some specs or a DTD which explains why the empty tag notation is > allowed in RDFa? If you read the XHTML 1.0 spec... On Fri, 2009-10-23 at 14:12 -0400, Stephane Corlosquet wrote: > There are only 10 EMPTY tags in HTML 1.0, and neither div nor span is > part of these. I looked in XHTML 1.1 and didn't find anything. The > RDFa DTD [2] does not declare new EMPTY tags either. Can someone point > me to some specs or a DTD which explains why the empty tag notation is > allowed in RDFa? If you read the XHTML 1.0 spec, you'll find that <div/> is perfectly valid. Appendix C discourages it in favour of <div></div>, but Appendix C is informative, not normative. XHTML 1.1 was written as more of a "pure XML application" with backwards-compatibility with non-X HTML less in mind, so takes the they-parse-exactly-the-same-under-XML-rules approach. RDFa is built on XHTML 1.1 rather than XHTML 1.0, thus inherits the "who cares whether you use <div></div> or <div/>?" philosophy - in theory. In practice, if you're serving RDFa using the text/html Content-Type, you'll want to pay attention to the Appendix C guidelines of XHTML 1.0, and avoid writing <div/>. This is true for any XHTML-family language, not just RDFa - in theory <div/> and <div></div> are identical, but in practise, served as text/html, they're parsed very differently. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256538170.7123.328.camel%40ophelia2.g5n.co.uk RE: A suggestion from the public 2009-10-26T06:22:51 2009-10-26T06:22:51 2009-10-26T06:22:51 On Mon, 2009-10-26 at 02:05 -0400, Justin James wrote: > The overall sentiment that I hear is that people want that style of > HTML to not be merely "defined" an "obsolete" or "non-conforming", but > to be considered "valid HTML". If it's currently valid HTML 3.2 or valid HTML 4.01, then it will continue to be valid HTML 3.2 or valid HTML 4.01. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2009-10-26 at 02:05 -0400, Justin James wrote: > The overall sentiment that I hear is that people want that style of > HTML to not be merely "defined" an "obsolete" or "non-conforming", but > to be considered "valid HTML". If it's currently valid HTML 3.2 or valid HTML 4.01, then it will continue to be valid HTML 3.2 or valid HTML 4.01. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/47672.77.89.160.244.1256576427.squirrel%40goddamn.co.uk Feedback on "Publishing Open Government Data" WD 2009-10-26T17:00:27 2009-10-26T17:00:27 2009-10-26T17:00:27 Expose Interfaces <http://www.w3.org/TR/2009/WD-gov-data-20090908/#concepts.expose>: > If you really want to help people discover and explore the data > you are publishing, there are some useful W3C standards which can > help. It is possible to make data human-readable by using XSLT > for XML- and RDF-based formats. It is probably not useful to mention RDF-based formats here. It seems unlikely ... Expose Interfaces <http://www.w3.org/TR/2009/WD-gov-data-20090908/#concepts.expose>: > If you really want to help people discover and explore the data > you are publishing, there are some useful W3C standards which can > help. It is possible to make data human-readable by using XSLT > for XML- and RDF-based formats. It is probably not useful to mention RDF-based formats here. It seems unlikely that XSLT would be very useful for making N-Triples or Turtle more human-readable. XSLT is only useful for transforming XML-based formats; yes, some RDF serialisations are XML-based, but those are already covered by saying that XSLT can be used on XML-based formats. -Toby http://tobyinkster.co.uk/message/1256599085.25705.12.camel%40ophelia2.g5n.co.uk Re: Empty span/div tags in RDFa pages 2009-10-26T23:18:05 2009-10-26T23:18:05 2009-10-26T23:18:05 On Mon, 2009-10-26 at 18:40 +0100, Julian Reschke wrote: > Which of course is caused by the fact that you simply can't serve > XHTML as text/html. The media type is authoritative, so recipients > will treat it as HTML. I think this is something that is often overstated. RFC 2854 notes that "different versions [of HTML] are distinguishable by the DOCTYPE declaration contained within them", so -- ... On Mon, 2009-10-26 at 18:40 +0100, Julian Reschke wrote: > Which of course is caused by the fact that you simply can't serve > XHTML as text/html. The media type is authoritative, so recipients > will treat it as HTML. I think this is something that is often overstated. RFC 2854 notes that "different versions [of HTML] are distinguishable by the DOCTYPE declaration contained within them", so -- assuming that XHTML is a "version" of HTML, whatever that means -- it is not incorrect behaviour to detect an XHTML DOCTYPE and perform version-specific parsing on the content. I realise that many popular user agents (especially desktop browsers) do not do this, but that doesn't make it wrong to do so. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256599450.25705.16.camel%40ophelia2.g5n.co.uk Re: Requesting the RDF MIME type of an image 2009-10-26T23:24:13 2009-10-26T23:24:13 2009-10-26T23:24:13 On Mon, 2009-10-26 at 23:06 +0100, Raphaël Troncy wrote: > We had a conversation with Tim Berners Lee during this workshop that > pretty much agrees with what Toby just wrote below ... while I was > arguing than nobody has formally defined what is the 'sameness' of two > representations of a resource. The accessibility community has defined > the notion of "equivalent" when the two representatio... On Mon, 2009-10-26 at 23:06 +0100, Raphaël Troncy wrote: > We had a conversation with Tim Berners Lee during this workshop that > pretty much agrees with what Toby just wrote below ... while I was > arguing than nobody has formally defined what is the 'sameness' of two > representations of a resource. The accessibility community has defined > the notion of "equivalent" when the two representations both fulfill > the same function or purpose upon presentation to the user, and in an > accessibility context, it is fine to say that a text is another > representation of an audio resource ... My personal answer is that two responses are "the same enough" if you, as a publisher, would be happy to publish them under the same URI without any explicit way of referring to them individually. If you, as the publisher, would be satisfied never being sure which representation a consumer will get, then they're OK to share a URI. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256637528.25705.30.camel%40ophelia2.g5n.co.uk RE: A suggestion from the public 2009-10-27T09:58:49 2009-10-27T09:58:49 2009-10-27T09:58:49 On Tue, 2009-10-27 at 00:00 -0400, Justin James wrote: > I really think that answer completely ignores the fundamental issue > that these folks have. To make it clear, they are extremely angry that > the *current* HTML efforts ignore this kind of work. They want a way > to do things in a valid, conforming, and "approved" fashion in a > current standard, that does not require all sorts of hoops to... On Tue, 2009-10-27 at 00:00 -0400, Justin James wrote: > I really think that answer completely ignores the fundamental issue > that these folks have. To make it clear, they are extremely angry that > the *current* HTML efforts ignore this kind of work. They want a way > to do things in a valid, conforming, and "approved" fashion in a > current standard, that does not require all sorts of hoops to jump > through. Then this is perhaps an issue they should have raise while it was still being decided in the mid-1990s. Presentational HTML was deprecated by the HTML 4.0 recommendation, finalised over 11.5 years ago. HTML 3.2, HTML 4.0 Transitional, HTML 4.01 Transitional and XHTML 1.0 Transitional all include support for presentational elements and attributes, and will continue to work as expected for the foreseeable future. If these people of whom you speak want to continue to follow their current practices, and are not interested in changing their style of markup, why would they want to learn a whole new version of HTML (HTML5) anyway? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256661661.25705.49.camel%40ophelia2.g5n.co.uk Re: Empty span/div tags in RDFa pages 2009-10-27T16:41:02 2009-10-27T16:41:02 2009-10-27T16:41:02 On Tue, 2009-10-27 at 15:11 +0100, Julian Reschke wrote: > I don't think this is a "fix", in that RFC 2854 never said you can > deliver XHTML as text/html and expect it to be treated as XHTML. Nor does RFC 2854 place any particular limits on how documents served as text/html may be treated. Parsing some such documents with an XML parser is not forbidden. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 2009-10-27 at 15:11 +0100, Julian Reschke wrote: > I don't think this is a "fix", in that RFC 2854 never said you can > deliver XHTML as text/html and expect it to be treated as XHTML. Nor does RFC 2854 place any particular limits on how documents served as text/html may be treated. Parsing some such documents with an XML parser is not forbidden. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256811608.25705.61.camel%40ophelia2.g5n.co.uk Re: Newbie LOD Questions :) 2009-10-29T10:20:09 2009-10-29T10:20:09 2009-10-29T10:20:09 On Wed, 2009-10-28 at 23:48 +0000, Nathan wrote: > - which are the preferred ontologies to use when trying to be very > specific about a subject (rather than dc.subject dc.creator etc which > are essentially free text based not URI identifier based) It's worth mentioning that RDFa makes it pretty trivial (compared to other RDF serialisations) to mark up multiple triples which differ only in the... On Wed, 2009-10-28 at 23:48 +0000, Nathan wrote: > - which are the preferred ontologies to use when trying to be very > specific about a subject (rather than dc.subject dc.creator etc which > are essentially free text based not URI identifier based) It's worth mentioning that RDFa makes it pretty trivial (compared to other RDF serialisations) to mark up multiple triples which differ only in their predicate. e.g. <p xmlns:dc="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/"> By <a about="" rel="foaf:maker dc:creator :author" rev="foaf:made :made" href="#i" >me</a>. </p> which creates the following five triples: @prefix dc: <http://purl.org/dc/terms/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix xhv: <http://www.w3.org/1999/xhtml/vocab#> . <> foaf:maker <#i> . <> dc:creator <#i> . <> xhv:author <#i> . <#i> foaf:made <> . <#i> xhv:made <> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1256820300.25705.68.camel%40ophelia2.g5n.co.uk Re: Carrying all of a resource's metadata as RDFa? 2009-10-29T12:45:01 2009-10-29T12:45:01 2009-10-29T12:45:01 On Thu, 2009-10-29 at 12:01 +0100, Hondros, Constantine wrote: > It would seem logical to put this sort of metadata in the <head> of a > document, but since that only allows a flat structure it seems to be > impossible with RDFa. No, it's not impossible: <head xmlns:xyz="http://example.com/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <link about="_:a" typeof="xyz:Period" ... On Thu, 2009-10-29 at 12:01 +0100, Hondros, Constantine wrote: > It would seem logical to put this sort of metadata in the <head> of a > document, but since that only allows a flat structure it seems to be > impossible with RDFa. No, it's not impossible: <head xmlns:xyz="http://example.com/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <link about="_:a" typeof="xyz:Period" rev="xyz:applicablePeriod" resource="" /> <meta about="_:a" property="xyz:startDate" content="blah" datatype="rdf:XMLLiteral" />  <meta about="_:a" property="xyz:endDate" content="blah" datatype="rdf:XMLLiteral" /> </head> Though I'm not sure why you'd want those dates to be XMLLiterals. xsd:date seems like a more appropriate datatype. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1257086777.25705.84.camel%40ophelia2.g5n.co.uk Re: XHTML character entity support 2009-11-01T14:46:18 2009-11-01T14:46:18 2009-11-01T14:46:18 On Fri, 2009-10-30 at 16:10 -0700, Alexey Proskuryakov wrote: > As noted in > <http://www.whatwg.org/specs/web-apps/current-work/#writing-xhtml-documents > >, there is no guarantee that authors can use character entity > references such as &nbsp; in XHTML, because XML parsers are not > required to process external DTD subsets. A bigger issue is that even user-agents which *do* process exter... On Fri, 2009-10-30 at 16:10 -0700, Alexey Proskuryakov wrote: > As noted in > <http://www.whatwg.org/specs/web-apps/current-work/#writing-xhtml-documents > >, there is no guarantee that authors can use character entity > references such as &nbsp; in XHTML, because XML parsers are not > required to process external DTD subsets. A bigger issue is that even user-agents which *do* process external DTD subsets are not necessarily going to support named entities; simply because XHTML5 documents do not link to a suitable DTD defining the named entities. > This works in at least Firefox, Safari and Opera In Safari? That's news to me. Last time I tried looking at an XHTML+RDFa 1.0 document served with an XML media type, named entities did not work. (The XHTML+RDFa 1.0 DTD defines the same set of entities used in XHTML 1.1.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1257155570.25705.114.camel%40ophelia2.g5n.co.uk Re: RDF 2 Wishlist 2009-11-02T09:52:51 2009-11-02T09:52:51 2009-11-02T09:52:51 On Sun, 2009-11-01 at 12:51 -0500, Sandro Hawke wrote: > So, what should W3C standardize next in the area of RDF, if anything? I was actually talking about something similar on IRC the other day. Here's my wishlist: A superset of the RDF model should be defined. I'm calling this "RDF 2.0", but other names might be possible. This model would be something like the SPARQL model. a) Tt would remove... On Sun, 2009-11-01 at 12:51 -0500, Sandro Hawke wrote: > So, what should W3C standardize next in the area of RDF, if anything? I was actually talking about something similar on IRC the other day. Here's my wishlist: A superset of the RDF model should be defined. I'm calling this "RDF 2.0", but other names might be possible. This model would be something like the SPARQL model. a) Tt would remove the restriction on subjects being literals. b) It would have named graphs. It would clarify the relationship between named graph URIs and document URIs. Should the document itself, and the graph gleaned by processing a document share a URI? Probably not, but in practise, this is what many people do. It makes it hard to represent different graphs gleaned from the same document (e.g. parsing an XHTML file with RDFa and with GRDDL). c) URI aliases: an owl:sameAs-like feature as part of the data model. A blank node is treated the same as a URI - it just has one less URI alias. Thus blank nodes are allowed as predicates. d) Clearer support for reification. I should be able to write a reified triple and then have tools understand its unreified meaning too - and perhaps only do so depending on some criteria. e.g. treat [ a rdf:Statement; foaf:maker <#bob> ] as an unreified triple only if I trust <#bob>. (a) is somewhat incompatible with RDF1, but could be projected back to RDF1 via inverses. In RDF 2.0: "W3C" ex:abbreviates <http://dbpedia.org/resource/W3C> . In RDF 1: <http://dbpedia.org/resource/W3C> i:be245f99 "W3C" . i:be245f99 rdf2compat:inverseOf ex:abbreviates . (b) is also incompatible with RDF1 as it is defined, but is fairly compatible with RDF1 as it's used in the wild. Tonnes of people already use named graphs. For those that need to backport RDF 2.0 data that uses named graphs to an RDF1 tool with no support for named graphs, either the graph can be dropped (if the person doesn't care about it) or the data could be reified. The URI alias feature (c) can be backported to RDF1 by adding rdf2compat:sameAs triples into the graph. The blank node predicate feature can be backported by assigning an arbitrary temporary URI to the blank node in question. (d) is pretty compatible with the RDF1 data model, and is just an area where tools could add better features. The rdf2compat vocabulary would define a bunch of terms for backporting RDF 2.0 data to RDF1. Such as: rdf2compat:inverseOf rdfs:subPropertyOf owl:inverseOf . rdf2compat:sameAs rdfs:subPropertyOf owl:sameAs . rdf2compat:sourceGraph rdfs:domain rdf:Statement . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1257163247.25705.148.camel%40ophelia2.g5n.co.uk Re: XHTML character entity support 2009-11-02T12:00:49 2009-11-02T12:00:49 2009-11-02T12:00:49 On Sun, 2009-11-01 at 18:33 -0500, Aryeh Gregor wrote: > Slightly off-topic for this thread, but: a remarkable number of web > developers want their markup to validate. There is absolutely no > technically sound reason for anyone to have switched from HTML4 to > XHTML1 Transitional served as text/html -- they're functionally > identical. But most major web apps do use some form of XHTML1. It se... On Sun, 2009-11-01 at 18:33 -0500, Aryeh Gregor wrote: > Slightly off-topic for this thread, but: a remarkable number of web > developers want their markup to validate. There is absolutely no > technically sound reason for anyone to have switched from HTML4 to > XHTML1 Transitional served as text/html -- they're functionally > identical. But most major web apps do use some form of XHTML1. It seems to me that large scale development, particularly of modular software, benefits from using XHTML over HTML. Firstly, many projects will want to enforce a "house style" on generated output. Rules like "always quote attribute values", "always use lower case tag names and attributes", "always close non-empty elements, even if they have optional end tags" can be enforced more easily by choosing an XHTML validation target, than by validating against HTML 4 and then adding extra restrictions. Secondly, modules can be written more cleanly if it can be checked that they explicitly close each tag that they open. If a module leaves a <p> tag open at the end of its output, then a second module that only outputs inline text will find itself as run-on content in the same paragraph. Lastly, using XHTML is useful if one module needs to modify the output of another module. It means that the modifying module can use off-the-shelf XML manipulation tools (XSLT, XML parsers, etc). While the HTML5 effort has done great work in standardising HTML parsing, the HTML manipulation tools available are not as widespread, mature or consistent yet. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1257341103.15652.29.camel%40ophelia2.g5n.co.uk Re: Subjects & Tagging - Help? 2009-11-04T13:25:04 2009-11-04T13:25:04 2009-11-04T13:25:04 On Tue, 2009-11-03 at 18:16 +0000, Nathan wrote: > Hoping for a little bit of guidance here on tagging & assigning > subjects to content etc - I can't quite grasp how to describe what an > item of content is about # TIMTOWTDI # Here's a few abbreviations for starters... @prefix dct: <http://purl.org/dc/terms/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdfs: <http://www.w3.org/2000... On Tue, 2009-11-03 at 18:16 +0000, Nathan wrote: > Hoping for a little bit of guidance here on tagging & assigning > subjects to content etc - I can't quite grasp how to describe what an > item of content is about # TIMTOWTDI # Here's a few abbreviations for starters... @prefix dct: <http://purl.org/dc/terms/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix tags: <http://www.holygoat.co.uk/owl/redwood/0.1/tags/> . # Tags I model as being instances of both skos:Concept and tags:Tag. # The latter is a subclass of the former anyway, but my store doesn't # do inferencing. </tag/linux/#concept> a skos:Concept, tags:Tag ; skos:prefLabel "linux"@en ; tags:name "linux"@en ; rdfs:label "linux"@en . # I associate a page with each tag, for linked data goodness. </tag/linux/#concept> foaf:isPrimaryTopicOf </tag/linux/> . </tag/linux/> foaf:primaryTopic </tag/linux/#concept> . # I link from tags to the real-world things they describe. </tag/linux/#concept> moat:localMeaning <http://dbpedia.org/resource/Linux> . # Finally, I link from pages to tags. </article/linux-rocks/> dc:subject </tag/linux/#concept> ; tags:taggedWithTag </tag/linux/#concept> . </article/linux-sucks/> dc:subject </tag/linux/#concept> ; tags:taggedWithTag </tag/linux/#concept> . # When outputting article tags in RDFa, I use: # # <a rel="dc:subject tags:taggedWithTag tag" # href="/tag/linux/#concept">linux</a> # # ... which is rel=tag-compatible. # TIMTOWTDI -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1257352434.15652.41.camel%40ophelia2.g5n.co.uk Re: Subjects & Tagging - Help? 2009-11-04T16:33:56 2009-11-04T16:33:56 2009-11-04T16:33:56 On Wed, 2009-11-04 at 14:26 +0000, Nathan wrote: > Primary question in this scenario is why dc:subject through to local tag > then tag associated with moat:localMeaning rather than dc:subject > straight through to dbpedia resource? ... > > .. as from the dc docs I gathered that "This term (dc:subject) is > intended to be used with non-literal values as defined in the DCMI > Abstract Model (htt... On Wed, 2009-11-04 at 14:26 +0000, Nathan wrote: > Primary question in this scenario is why dc:subject through to local tag > then tag associated with moat:localMeaning rather than dc:subject > straight through to dbpedia resource? ... > > .. as from the dc docs I gathered that "This term (dc:subject) is > intended to be used with non-literal values as defined in the DCMI > Abstract Model (http://dublincore.org/documents/abstract-model/). As of > December 2007, the DCMI Usage Board is seeking a way to express this > intention with a formal range declaration." For me it wasn't an question of what to link to when using dc:subject; but rather which predicate to use when linking from a foaf:Document to a skos:Concept. dc:subject seemed the ideal solution. Can dc:subject be used to link straight from a document to a dbpedia resource? Maybe. The definition is sufficiently woolly. Personally if I were linking directly between them I'd use foaf:topic/foaf:page. > Also, noted that you opted for a different doc type "XHTML+RDFa > 1.0+Role" in demiblog (assumed you're the core dev) any specific notes > on why you're using a customised DTD rather than XHTML+RDFa or HTML5? I use the role attribute which is not defined by the XHTML+RDFa DTD. http://www.w3.org/TR/xhtml-role/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1257707058.6339.7.camel%40ophelia2.g5n.co.uk Re: Meeting minutes, 2009-11-05 2009-11-08T19:04:19 2009-11-08T19:04:19 2009-11-08T19:04:19 On Thu, 2009-11-05 at 19:42 +0100, Ivan Herman wrote: > ... There is MediaRSS - which is RDFa being used in a non-XHTML > dialect. DataRSS, surely? DataRSS is RDFa in Atom. Regarding an RSS 1.1 Core specification, it looks to me like there are currently three "branches" of RDFa syntax: 1. XHTML+RDFa - the original, and a W3C Rec. DataRSS uses the same branch of RDFa - it's essentially jus... On Thu, 2009-11-05 at 19:42 +0100, Ivan Herman wrote: > ... There is MediaRSS - which is RDFa being used in a non-XHTML > dialect. DataRSS, surely? DataRSS is RDFa in Atom. Regarding an RSS 1.1 Core specification, it looks to me like there are currently three "branches" of RDFa syntax: 1. XHTML+RDFa - the original, and a W3C Rec. DataRSS uses the same branch of RDFa - it's essentially just got different tag names. 2. HTML+RDFa - small refinements on XHTML+RDFa necessary to get it to work on an HTML DOM. 3. SVG 1.2 Tiny - this differs significantly from the other two in that it may also legitimately include RDF/XML chunks. RDF 1.1 Core needs to unite not only the first two, but also the third branch - XML-based varieties of RDFa which can legitimately include RDF/XML chunks. (It should specify whether triples from all of them form a single graph or should/may be separated into separate graphs. It might even be useful if: <x property="foo:bar" datatype="rdfa:reified"> <rdf:RDF>...</rdf:RDF> </x> resulted in something like the following N3: <> foo:bar { ... } . Just some things to think about... -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1257931418.8736.6.camel%40ophelia2.g5n.co.uk Re: list-expansion in RDFa 2009-11-11T09:23:40 2009-11-11T09:23:40 2009-11-11T09:23:40 On Tue, 2009-11-10 at 20:59 -0500, Gregg Kellogg wrote: > I notice that RDFa does not define rdf:li list expansion as in > RDF/XML. In RDF/XML, according to > http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-list-elements, > rdf:li is expanded to rdf:_1, rdf:_2 and so forth during expansion. Indeed it does not. A method for RDF grouping constructs - and in particular rdf:List structures, w... On Tue, 2009-11-10 at 20:59 -0500, Gregg Kellogg wrote: > I notice that RDFa does not define rdf:li list expansion as in > RDF/XML. In RDF/XML, according to > http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-list-elements, > rdf:li is expanded to rdf:_1, rdf:_2 and so forth during expansion. Indeed it does not. A method for RDF grouping constructs - and in particular rdf:List structures, which are annoying to represent in RDFa - would be very welcome in a future version of RDFa. But as RDFa is currently defined, rdf:li does not expand to rdf:_1, rdf:_2, etc. So a test case requiring parsers to do so would not be a good idea. That having been said, expanding rdf:li to rdf:_1, rdf:_2, etc seems a useful feature for a parser to have, albeit one that should be implemented as an option, switched off by default until such a time as this feature is standardised. I'm quite tempted to implement it in my Perl RDFa parser. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258227387.10171.13.camel%40ophelia2.g5n.co.uk Re: PROPOSAL: Errata text regarding defining a prefix of '_' 2009-11-14T19:36:30 2009-11-14T19:36:30 2009-11-14T19:36:30 On Sat, 2009-11-14 at 12:06 -0600, Shane McCarron wrote: > My question is this: How do you ensure that your implicit, > automatically created bnode names never collide with a documents > explicit, auto-vivified bnode names? And should we have some sort of > a test case to ensure this happens? It's not especially difficult. Here's one technique a parser could follow: When an explicitly name... On Sat, 2009-11-14 at 12:06 -0600, Shane McCarron wrote: > My question is this: How do you ensure that your implicit, > automatically created bnode names never collide with a documents > explicit, auto-vivified bnode names? And should we have some sort of > a test case to ensure this happens? It's not especially difficult. Here's one technique a parser could follow: When an explicitly named bnode is found, check if its name starts '_:bn'. If not, use it verbatim. But if so, replace the '_:bn' with '_:bnbn'. When a name is needed for an implicit bnode, give it one starting '_:bn' followed by numbers. You should find that this can never produce a collision. Of course if means that in some cases, explicitly named blank nodes in the input RDFa have different names in the output graph. But that's OK - RDF doesn't assign any meanings to the names of blank nodes. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258310663.10171.30.camel%40ophelia2.g5n.co.uk Re: PROPOSAL: Errata text regarding defining a prefix of '_' 2009-11-15T18:44:26 2009-11-15T18:44:26 2009-11-15T18:44:26 On Sat, 2009-11-14 at 16:28 -0600, Shane McCarron wrote: > I agree that the technique described will work. I am surprised that > you think it ok okay to change the bnode in the emitted triples. While > you might not think it has a meaning, others may... The RDF Semantics[1] recommendation says this about identifiers for blank nodes: > While node identifiers such as '_:xxx' serve to identify blan... On Sat, 2009-11-14 at 16:28 -0600, Shane McCarron wrote: > I agree that the technique described will work. I am surprised that > you think it ok okay to change the bnode in the emitted triples. While > you might not think it has a meaning, others may... The RDF Semantics[1] recommendation says this about identifiers for blank nodes: > While node identifiers such as '_:xxx' serve to identify blank nodes > in the surface syntax, these expressions are not considered to be the > label of the graph node they identify; they are not names, and do not > occur in the actual graph. i.e. node identifiers are syntactic sugar. They're a very useful bit of syntactic sugar in fact, because without them it would be pretty much impossible to serialise a graph containing cyclical references between blank nodes. But they're not a part of the RDF graph itself - so, assuming that all an RDFa processor is required to output is an RDF graph, it cannot be a requirement for RDF processors to retain blank node identifiers. That said, retaining blank node identifiers when possible is a good thing - it helps the readability of any resultant serialisation, in much the same way as retaining CURIE prefixes of the input RDFa does. The method I outlined does retain blank node identifiers in the vast majority of cases, and can be guaranteed not to produce collisions, yet it's still possible to implement as part of a one-pass algorithm. ____ 1. http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258378498.19975.14.camel%40ophelia2.g5n.co.uk Re: URIs in @rel and @property... 2009-11-16T13:35:00 2009-11-16T13:35:00 2009-11-16T13:35:00 Here's an idea, and it may be a terrible one. That's for you lot to decide. In RDFa 1.1, all RDFa-specific attributes (i.e. not @href and @src) may take either SafeCURIEs or Safe URIs. SafeCURIEs take the form: [prefix:suffix] SafeURIs take the form: {absoluteOrRelativeURI} (Angled brackets are theoretically nicer than curly braces because they fit better with how URIs are often given in th... Here's an idea, and it may be a terrible one. That's for you lot to decide. In RDFa 1.1, all RDFa-specific attributes (i.e. not @href and @src) may take either SafeCURIEs or Safe URIs. SafeCURIEs take the form: [prefix:suffix] SafeURIs take the form: {absoluteOrRelativeURI} (Angled brackets are theoretically nicer than curly braces because they fit better with how URIs are often given in the wild - but they'd need escaping when serialised, so they're probably not as nice in practise. More on this later...) In the case of tokens which are neither a SafeCURIE nor a SafeURI, a disambiguation method is applied: 1. If the attrbute is @about or @resource, the token is a URI; 2. If the attribute is @rel or @rev and on the list of known keywords, it's a keyword. 3. If the token begins '_:' then it's a bnode. 4. If the prefix of the token has been declared, or it's the empty prefix, it's a CURIE. 5. Otherwise it's a URI. (... More on the curly braces: actually you'll see that in most cases, people will be able to rely on the disambiguation method rather than use curly braces. So maybe instead with *should* use angled brackets <> which look ugly when serialised - precisely to discourage people from using them, and encourage them instead to rely on the disambiguation algorithm.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258386571.19975.36.camel%40ophelia2.g5n.co.uk Re: differentFrom? 2009-11-16T15:49:32 2009-11-16T15:49:32 2009-11-16T15:49:32 On Sat, 2009-11-14 at 22:52 +0000, Richard Light wrote: > But owl:disjointWith does rather better (scoring 19979). owl:disjointWith serves a rather different purpose though. The following classes are owl:differentFrom each other: ex:AcademyAwardWinner ex:GrammyAwardWinner ex:NobelPrizeWinner But the classes are not disjoint -- dbpedia:Al_Gore is in the intersection of the three classes. (Indeed, I imagine he is the only person in the intersection.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 2009-11-14 at 22:52 +0000, Richard Light wrote: > But owl:disjointWith does rather better (scoring 19979). owl:disjointWith serves a rather different purpose though. The following classes are owl:differentFrom each other: ex:AcademyAwardWinner ex:GrammyAwardWinner ex:NobelPrizeWinner But the classes are not disjoint -- dbpedia:Al_Gore is in the intersection of the three classes. (Indeed, I imagine he is the only person in the intersection.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258453802.16532.22.camel%40ophelia2.g5n.co.uk Re: Data linking to Geonames 2009-11-17T10:30:04 2009-11-17T10:30:04 2009-11-17T10:30:04 On Mon, 2009-11-16 at 17:31 +0100, Bernard Vatant wrote: > I would like to get updated estimation about the size of the linked > data using geonames URIs (outside Geonames publication itself, of > course). libre.fm profiles include a "location" field. After filling in this field in the edit profile form, users can use an AJAX widget to search Geonames for that location, and link their profile to... On Mon, 2009-11-16 at 17:31 +0100, Bernard Vatant wrote: > I would like to get updated estimation about the size of the linked > data using geonames URIs (outside Geonames publication itself, of > course). libre.fm profiles include a "location" field. After filling in this field in the edit profile form, users can use an AJAX widget to search Geonames for that location, and link their profile to it. If they do this, then the link is included in the (FOAF) RDFa on their profile page. For example: http://alpha.libre.fm/user/tobyink StatusNet (the software behind popular microblogging site identi.ca) is introducing geocoding in version 0.9.x. This is planned to be based around geonames identifiers (and probably one or two other services will be used too). Each profile will have a location associated with it, and each notice too. This will almost certainly be exposed in the FOAF/RSS/SIOC outputs provided by the software. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258462429.13013.9.camel%40ophelia2.g5n.co.uk Re: XML problems with percent encoding 2009-11-17T12:53:51 2009-11-17T12:53:51 2009-11-17T12:53:51 On Tue, 2009-11-17 at 10:13 +0000, Damian Steer wrote: > RDF/XML remains the only recommended rdf serialisation, but it can't > serialise every rdf graph. > > Not a happy situation. Actually XHTML+RDFa is a W3C Recommendation, with the same (de jure) status as RDF/XML. It's capable of representing almost every RDF graph. (With the exception of literals containing certain Unicode control charact... On Tue, 2009-11-17 at 10:13 +0000, Damian Steer wrote: > RDF/XML remains the only recommended rdf serialisation, but it can't > serialise every rdf graph. > > Not a happy situation. Actually XHTML+RDFa is a W3C Recommendation, with the same (de jure) status as RDF/XML. It's capable of representing almost every RDF graph. (With the exception of literals containing certain Unicode control characters which are completely illegal in XML.) XHTML+RDFa uses CURIEs rather than QNames. CURIEs are a superset of QNames and allow a much wider set of characters to be used. For example, <http://ko.dbpedia.org/property/%EA%B4%91%EC%9E%90> can be serialised as: <div xmlns:dbp-ko="http://dbpedia.org/property/" property="dbp-ko:%EA%B4%91%EC%9E%90"> As it happens, some properties containing lots of percent-encoding can be represented fine in RDF/XML. e.g. <http://ko.dbpedia.org/property/%EA %B4%91%EC%9E%8F> which can be: <foo:F xmlns:foo="http://ko.dbpedia.org/property/%EA%B4%91%EC%9E%8"> The problems arise when neither hex digit of the last character is in the range A-F. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258470473.13013.134.camel%40ophelia2.g5n.co.uk Thoughts on @profile 2009-11-17T15:07:54 2009-11-17T15:07:54 2009-11-17T15:07:54 Ian asked me to send in my thoughts on the profile attribute. I'm the primary developer of Swignition <http://buzzword.org.uk/swignition/> a tool that aims to parse both the so-called "lower-case semantic web" and "upper-case Semantic Web". It includes various modules for parsing microformats and other widely used "plain old semantic HTML" patterns, plus RDFa, eRDF, GRDDL, etc, pulls it into a bi... Ian asked me to send in my thoughts on the profile attribute. I'm the primary developer of Swignition <http://buzzword.org.uk/swignition/> a tool that aims to parse both the so-called "lower-case semantic web" and "upper-case Semantic Web". It includes various modules for parsing microformats and other widely used "plain old semantic HTML" patterns, plus RDFa, eRDF, GRDDL, etc, pulls it into a big pot and uses that to output useful stuff. e.g. outputting vCards which combine data gleaned from hCard and RDFa; or iCalendar events which contain a mixture of data from hCalendar and RDF/XML. Swignition's currently on a bit of a development hiatus while I work on other projects, but has not been completely abandoned. Anyway, Swignition uses the @profile attribute for a number of purposes. Firstly, microformats use class names and link types which may already exist in the wild in some cases. While they're mostly chosen to be fairly unique, collisions do happen. For example, class="vcard" is occasionally seen on links to VCF files. In fact, I've even seen this used on pages which had a genuine hCard on them too. Including an explicit link to a well-known URL for a microformat profile provides a disambiguation mechanism. It allows a page to indicate that when it says class="vcard" it's using the hCard microformat. In practise, not very many people include the hCard profile in the wild, so relying on this mechanism to detect hCard usage is not especially useful, however, Swignition provides a "strict mode", which when enabled does require the hCard profile to be used. This strict mode does produce fewer spurious results on pages where accidental collisions occur, so it's useful to have as a toggle. Secondly, some microformats patterns have well-documented accessibility issues. For the last few years the microformats community has been working at addressing these issues, but work has not been fast. Numerous different patterns for markup have been proposed, including, for example: <span class="dtstart data:20091117">11 Nov 2009</span> <span class="dtstart"> <span class="value-title" title="20091117">&nbsp;</span> 11 Nov 2009 </span> <span class="dtstart usetitle" title="20091117"> 11 Nov 2009 </span> <span class="dtstart" title="data:20091117"> 11 Nov 2009 </span> I've implemented support for some of these unofficial suggestions, but with these experimental and not widely used techniques it's been especially beneficial to have the profile attribute to use as a flag for toggling behaviour. In these cases I've found it most useful to disable support for the patterns by default and (even when not in strict mode) *require* authors to use a well-known profile URI to switch on the behaviour. Similarly it supports extensions to certain microformats when particular profile URIs are found. For example, it supports rel="evil-twin" if a profile URI of <http://xen.adactio.com/> is found. Swignition supports GRDDL. If a page uses GRDDL, the parser will download profiles linked to and inspect them for transformations which can be run on the page to yield more data. Transformations can be written in either XSLT1 or RDF-EASE (and I did have plans to allow Javascript transformations, but libjs doesn't include any DOM support when run outside the browser). So Swignition uses @profile in a variety of ways. As it happens, being forward-looking, it also supports rel="profile" on A and LINK elements, and HTTP Link headers with rel="profile" too. Overall I'd recommend keeping @profile for its use in GRDDL, and as a general purpose flag that user agents can use to trigger particular processing behaviours. While Swignition does support rel="profile", I'd recommend against introducing this as a new standard way of indicating profiles, as is seems a gratuitously different syntax, not backwards compatible with existing agents. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258473309.16718.4.camel%40ophelia2.g5n.co.uk Re: RDF Update Feeds 2009-11-17T15:55:10 2009-11-17T15:55:10 2009-11-17T15:55:10 On Tue, 2009-11-17 at 16:45 +0100, Georgi Kobilarov wrote: > How do we deal with RDF diffs? Talis' changeset vocab is a good start: http://n2.talis.com/wiki/Changesets It has enough level of details for changes to be rewound, replayed, etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 2009-11-17 at 16:45 +0100, Georgi Kobilarov wrote: > How do we deal with RDF diffs? Talis' changeset vocab is a good start: http://n2.talis.com/wiki/Changesets It has enough level of details for changes to be rewound, replayed, etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258571851.16718.227.camel%40ophelia2.g5n.co.uk Re: XML problems with percent encoding 2009-11-18T19:17:34 2009-11-18T19:17:34 2009-11-18T19:17:34 On Wed, 2009-11-18 at 15:17 +0100, Sebastian Hellmann wrote: > So basically XHTML+RDFa is incompatible with RDF/XML in this respect. > Let's say the original data is kept in XHTML+RDFa. If it is spread in > the Web of Data from host to host and somebody tries to serialize it > in RDF/XML his parser/serializer is bound to fail. That is true. But this is a problem with RDF/XML rather than XHTML+RD... On Wed, 2009-11-18 at 15:17 +0100, Sebastian Hellmann wrote: > So basically XHTML+RDFa is incompatible with RDF/XML in this respect. > Let's say the original data is kept in XHTML+RDFa. If it is spread in > the Web of Data from host to host and somebody tries to serialize it > in RDF/XML his parser/serializer is bound to fail. That is true. But this is a problem with RDF/XML rather than XHTML+RDFa. Neither of these formats is capable of representing all RDF graphs, though the latter is closer than the former. RDF/XML falls down because some URIs cannot be encoded into QNames. But both are restricted by the fact that certain characters are not allowed in XML. Turtle and N-Triples should be able to cope with any RDF graph that you want to serialise. Each of these are pretty widely supported and both are kinda almost W3C Recommendations. (A very Turtle-like syntax forms the basis of the SPARQL Query Language, which is a Rec; N-Triples is described in the RDF Test Cases Rec.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258625113.16718.251.camel%40ophelia2.g5n.co.uk Re: Web Browser Preferences and Internationalisation/Accessibility 2009-11-19T10:05:15 2009-11-19T10:05:15 2009-11-19T10:05:15 On Wed, 2009-11-18 at 19:10 -0800, Maciej Stachowiak wrote: > Is there a need to expose any setting to the Web page other than the > language preference for Web content? In Safari, it's unlikely we'll > ever have three separate language preferences, but even if we did, I > can't see why Web content would care about the OS language or the > browser language if they are different from the la... On Wed, 2009-11-18 at 19:10 -0800, Maciej Stachowiak wrote: > Is there a need to expose any setting to the Web page other than the > language preference for Web content? In Safari, it's unlikely we'll > ever have three separate language preferences, but even if we did, I > can't see why Web content would care about the OS language or the > browser language if they are different from the language to be used in > Web pages. I can only think of one realistic use case where the web page might want to know OS and Browser UI languages rather than web page language preferences, and that's when providing help on using their system. For example: <p>To open a command prompt in Windows 95, click the <kbd id="start">Start</kbd> menu, select "Run" and type <kbd>command</kbd> then Enter.</p> <script type="text/javascript"> var start = document.getElementById('start'); if (navigator.systemLanguage=='fr') start.innerHTML='Démarrage'; else if (navigator.systemLanguage=='es') start.innerHTML='Inicio'; else if (navigator.systemLanguage=='it') start.innerHTML='Avvio'; </script> It seems to me that the most useful information that scripts could be provided would be the user's preferences for web page languages - i.e. the same information used to construct the Accept-Language HTTP header. This should probably be as an array. I'm not sure if it's best for it to be an array of strings, or an array of objects. The former is simpler, but the latter would allow them to provide some useful methods like lang.matches() which could allow "en-gb" to match "en", but not match "en-us" (similar to SPARQL's langMatches function). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1258652190.32665.9.camel%40ophelia2.g5n.co.uk Re: Web Browser Preferences and Internationalisation/Accessibility 2009-11-19T17:36:34 2009-11-19T17:36:34 2009-11-19T17:36:34 On Thu, 2009-11-19 at 07:59 -0600, Shelley Powers wrote: > Even the reference to the navigator object is browser specific, not > DOM specific. Though objects like window and navigator are considered > "DOM Level 0", they're really not DOM, as we know the Document Object > Model from previous and current implementations. They're part of the > BOM, or Browser Object Model. Most particularly, discuss... On Thu, 2009-11-19 at 07:59 -0600, Shelley Powers wrote: > Even the reference to the navigator object is browser specific, not > DOM specific. Though objects like window and navigator are considered > "DOM Level 0", they're really not DOM, as we know the Document Object > Model from previous and current implementations. They're part of the > BOM, or Browser Object Model. Most particularly, discussions related > to the BOM and JavaScript are not related to HTML. I completely agree that it's an issue for HTML5 to include specifications for window and navigator objects. I've been advocating splitting them out for at least a year. Yes, they're useful specifications to have, but they're NOT HTML. They could be split out into a separate specification or specifications, and HTML5 would probably not even need to reference them. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259141582.708.51.camel%40ophelia2.g5n.co.uk Another possible compromise re namespaces in HTML 2009-11-25T09:33:04 2009-11-25T09:33:04 2009-11-25T09:33:04 How about this - I think it allows people wanting to use namespaced content in HTML a great deal of flexibility, yet without making things too complicated for parsers. 1. In the HTML serialisation, xmlns:* attributes may be used to declare any namespaces. The default xmlns attribute cannot be bound to anything other than the HTML namespace. 2. The namespace URIs which HTML supports "out of the b... How about this - I think it allows people wanting to use namespaced content in HTML a great deal of flexibility, yet without making things too complicated for parsers. 1. In the HTML serialisation, xmlns:* attributes may be used to declare any namespaces. The default xmlns attribute cannot be bound to anything other than the HTML namespace. 2. The namespace URIs which HTML supports "out of the box" (e.g. SVG, XML, HTML itself) do not have to be declared, and may not be declared using any prefix other than their standard prefix as specified by the HTML syntax spec. Those standard prefixes cannot be used with other namespace URIs. There is precedent for such a rule - in XML, the prefix 'xml' and namespace URI 'http://www.w3.org/XML/1998/namespace' may only be bound to each other. Such non-conformant namespace declarations would be ignored. 3. Namespaced attributes (foo:bar="baz") are conformant, but validators *may* issue warnings about them. 4. Within so-called foreign content (e.g. SVG), namespaced elements are conformant, but validators *may* issue warnings about them. Elsewhere, namespaced elements are non-conformant. Namespaced elements are parsed the same way any other unknown elements are. 5. People wishing to use namespaced elements outside foreign content are instead advised to use CURIE values within @role. It may be useful for browsers to expose the contents of @role as an array in the DOM with CURIE prefixes already expanded out. 6. Namespace-aware DOM functions (getAttributeNS, etc) should work. I can't imagine there's very much existing content in the wild that would break under these rules. The aforementioned example of Creative Commons licenses within SVG would work and be considered conformant; the Google Jotspot example would work but be considered non-conformant. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259145246.708.82.camel%40ophelia2.g5n.co.uk Delete: The Virtue of Forgetting in the Digital Age 2009-11-25T10:34:08 2009-11-25T10:34:08 2009-11-25T10:34:08 I'm about half-way through this book by Viktor Mayer-Schonberger. It covers how, with the invention of language, writing, printing, and now digital storage, it has become progressively cheaper and easier to store information rather than not. For example, if you assume it takes 3 seconds to decide whether to keep or delete a photograph, and you assume your time is worth an average wage, then going... I'm about half-way through this book by Viktor Mayer-Schonberger. It covers how, with the invention of language, writing, printing, and now digital storage, it has become progressively cheaper and easier to store information rather than not. For example, if you assume it takes 3 seconds to decide whether to keep or delete a photograph, and you assume your time is worth an average wage, then going through your digital camera and deciding which photos to keep is now more expensive than the hard disk space required to simply keep them all. The default behaviour was once to forget, as remembering took effort. In the last decade or so though, this has been changing towards a default policy of remembering. Mayer-Schonberger discusses the implications (some positive, many negative) this is having on society, and possible solutions. It's a really good read, very jargon-free, and I highly recommend it to SWXG members as it has a lot of relevance to what we're doing. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259227081.708.97.camel%40ophelia2.g5n.co.uk Re: RDF Update Feeds + URI time travel on HTTP-level 2009-11-26T09:18:03 2009-11-26T09:18:03 2009-11-26T09:18:03 On Thu, 2009-11-26 at 00:04 +0000, Richard Cyganiak wrote: > If you choose such a rather broad definition for agent-driven > negotiation, then you surely must count the practice of sending > different responses based on client IP or User-Agent header, both of > which are common on the Web, as examples for server-driven conneg. And even different responses based on the client's "Cookie" header. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2009-11-26 at 00:04 +0000, Richard Cyganiak wrote: > If you choose such a rather broad definition for agent-driven > negotiation, then you surely must count the practice of sending > different responses based on client IP or User-Agent header, both of > which are common on the Web, as examples for server-driven conneg. And even different responses based on the client's "Cookie" header. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259234758.708.112.camel%40ophelia2.g5n.co.uk Re: Default and empty CURIE prefixes in a non-XHTML host language 2009-11-26T11:25:59 2009-11-26T11:25:59 2009-11-26T11:25:59 On Thu, 2009-11-26 at 01:17 +0100, Christoph LANGE wrote: > I suppose both is possible, because the RDFa recommendation says that > for CURIE processing mappings for (1) and (2) have to be provided [by > way of the specification of the host language]. I think I will do > that, but not particularly endorse its usage, as general-purpose RDFa > processors would not understand it. Hmmm... this is a ... On Thu, 2009-11-26 at 01:17 +0100, Christoph LANGE wrote: > I suppose both is possible, because the RDFa recommendation says that > for CURIE processing mappings for (1) and (2) have to be provided [by > way of the specification of the host language]. I think I will do > that, but not particularly endorse its usage, as general-purpose RDFa > processors would not understand it. Hmmm... this is a good point. I've tried to make my Perl RDFa parser as generic as possible, and allow XHTML-specific features (like treating <head> and <body> specially; understanding <base href>; etc) to be switched off. But I don't currently provide a way to change the default CURIE prefix from <http://www.w3.org/1999/xhtml/vocab#>. Nor do I provide a way to define additional keywords. If I were to add such a feature, what do you think would be more useful - allow additional keywords in @rel/@rev; or allow them to be used in any attribute? > Now I'm just wondering why this is done in such a strange way for RDFa > in XHTML. Why are the bare words that _are_ allowed in @rel and @rev > attributes not specified as prefixless CURIEs (mapping to the > http://www.w3.org/1999/xhtml/vocab# namespace) but as special reserved > words? Is this for historical reasons? Indeed - it's for hysterical raisins. @rel and @rev are not new attributes defined by RDFa, but have existed since HTML 2.0 was published 14 years ago. These keywords have been "grandfathered in" to RDFa and require slightly different handling to real CURIEs - for instance, they should be handled case-insensitively, as previous versions of HTML and XHTML have defined @rel and @rev as case-insensitive. > And why is there, in addition, a default > namespace http://www.w3.org/1999/xhtml/vocab# for use with the empty > prefix? That makes @rel="next" redundantly equal to @rel=":next". It does seem a little redundant, yes, but there doesn't seem to be a better vocabulary to point the empty prefix at. > There is additionally a separate CURIE spec at > http://www.w3.org/TR/curie/. > Which one is more reliable, RDFa or CURIE? The CURIE spec is a spin-off of the RDFa spec, intended to allow CURIEs to be easily used by other specifications, like the XHTML role attribute. The XHTML+RDFa recommendation does not normativly reference it, so when there are differences between them, the behaviour described by the XHTML+RDFa recommendation is what RDFa processors should follow. With the imminent closure of the XHTML2 working group it seems unlikely that the CURIE spec will ever become a W3C Recommendation, unless it's taken over by another working group. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259249123.708.128.camel%40ophelia2.g5n.co.uk Re: Proposal for 'URIs everywhere' 2009-11-26T15:25:24 2009-11-26T15:25:24 2009-11-26T15:25:24 On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote: > Anyway, below you'll find a series of minor changes that I feel would > need to be made to various parts of the syntax document, in order to > support URIs and CURIEs in all RDFa-related attributes (except @src > and @href). The following describes the behaviour of the unreleased RDF::RDFa::Parser 0.21 package for Perl. (Latest released ver... On Wed, 2009-11-25 at 22:06 +0000, Mark Birbeck wrote: > Anyway, below you'll find a series of minor changes that I feel would > need to be made to various parts of the syntax document, in order to > support URIs and CURIEs in all RDFa-related attributes (except @src > and @href). The following describes the behaviour of the unreleased RDF::RDFa::Parser 0.21 package for Perl. (Latest released version is 0.20.) If the parser is instantiated with the option "full_uris" set to true, then, it uses the following behaviour for these attributes: @about/@resource: Safe CURIE, falling back to URIs. @src/@href: URIs only. @rel/@rev: Keywords, falling back to safe CURIEs, CURIEs then URIs. @property/@typeof/@datatype: Safe CURIEs, CURIEs then URIs. I think this is more or less the same as your proposal, except that unsafe CURIEs are disallowed in @about/@resource. By default, i.e. when "full_uris" is not true, it uses: @about/@resource: Safe CURIE, falling back to URIs. @src/@href: URIs only. @rel/@rev: Keywords, falling back to safe CURIEs, then CURIEs. @property/@typeof/@datatype: Safe CURIEs, falling back to CURIEs. And as of 0.21 it's now passing all 107 approved tests in the XHTML+RDFa test suite. (Yay!) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259518982.2511.471.camel%40ophelia2.g5n.co.uk Re: Non-XHTML host languages for RDFa 2009-11-29T18:23:04 2009-11-29T18:23:04 2009-11-29T18:23:04 On Sat, 2009-11-28 at 11:55 +0100, Christoph LANGE wrote: > Do we want to have such an overview? I've started a Wiki page outlining known RDFa host languages, plus significant parsing differences between those and XHTML+RDFa. http://rdfa.info/wiki/RDFa_Host_Languages -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 2009-11-28 at 11:55 +0100, Christoph LANGE wrote: > Do we want to have such an overview? I've started a Wiki page outlining known RDFa host languages, plus significant parsing differences between those and XHTML+RDFa. http://rdfa.info/wiki/RDFa_Host_Languages -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259520904.2511.472.camel%40ophelia2.g5n.co.uk Re: Non-XHTML host languages for RDFa 2009-11-29T18:55:04 2009-11-29T18:55:04 2009-11-29T18:55:04 On Sat, 2009-11-28 at 11:55 +0100, Christoph LANGE wrote: > Do we want to have such an overview? I've started a Wiki page outlining known RDFa host languages, plus significant parsing differences between those and XHTML+RDFa. http://rdfa.info/wiki/RDFa_Host_Languages -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 2009-11-28 at 11:55 +0100, Christoph LANGE wrote: > Do we want to have such an overview? I've started a Wiki page outlining known RDFa host languages, plus significant parsing differences between those and XHTML+RDFa. http://rdfa.info/wiki/RDFa_Host_Languages -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259574385.2511.500.camel%40ophelia2.g5n.co.uk SPARQL 1.1 Aggregates 2009-11-30T09:46:27 2009-11-30T09:46:27 2009-11-30T09:46:27 I see that the built-in set of aggregates for SPARQL 1.1 has not yet been decided. The current list is quite numerically oriented. Here are some I'd like to see: CONCAT - concatenates values, with an optional second parameter to provide a joiner character. Result is a plain literal with no language. XML_CONCAT - Concatenates values into an XMLLiteral using an SPARQL-Results-like structu... I see that the built-in set of aggregates for SPARQL 1.1 has not yet been decided. The current list is quite numerically oriented. Here are some I'd like to see: CONCAT - concatenates values, with an optional second parameter to provide a joiner character. Result is a plain literal with no language. XML_CONCAT - Concatenates values into an XMLLiteral using an SPARQL-Results-like structure. LONGEST/SHORTEST - returns the longest or shortest result (in terms of character count). Optional second parameter specifies a language. MODE/MEDIAN - while AVG returns the mean result, these two would return other kinds of average. With named graphs, the same triple can occur multiple times, so MODE makes sense. Optional second parameter specifies a language. In the case where I've indicated that the second parameter specifies a language, the aggregate function would work like this: 1. Do any values in the list match the specified language? (Using same definition of "match" as langMatches.) If so, then discard any results which don't match. 2. Run the aggregate as normal. So for example, on the following graph: <http://example.com/cat> rdfs:label "cat"@en, "chat"@fr, "feline"@en, "felis"@la. This SPARQL query: SELECT ?resource (SHORTEST(?label,"fr") AS ?mylabel) WHERE { ?resource rdfs:label ?label . } Would return: resource | mylabel -------------------------+----------- <http://example.com/cat> | "chat"@fr Because the non-French values would be discarded, with the shortest remaining label being selected. However, this: SELECT ?resource (SHORTEST(?label,"de") AS ?mylabel) WHERE { ?resource rdfs:label ?label . } Would return resource | mylabel -------------------------+----------- <http://example.com/cat> | "cat"@en There was no German label in the data, so the discarding step never happens - thus the shortest of any language is selected. I think in terms of presenting views of graph data, having these aggregate language preferences (and they're preferences, not filters, as the second example illustrates) would be very useful - especially for "label" and "description" kinds of fields. While I'm giving examples, I'll provide some for CONCAT and XML_CONCAT: SELECT ?resource (CONCAT(?label, ";") AS ?concat) (XML_CONCAT(?label) AS ?xmlconcat) WHERE { ?resource rdfs:label ?label . } ORDER BY ?label ?concat would be "cat;chat;feline;felis" (the ORDER BY clause having been used by the aggregate function). ?xmlconcat would be: """<literal xml:lang="en">cat</literal> <literal xml:lang="fr">chat</literal> <literal xml:lang="en">feline</literal> <literal xml:lang="la">felis</literal>"""^^rdf:XMLLiteral Perhaps the data type could be more specialised - instead of rdf:XMLLiteral, it could be, say, sparql:XMLResultsLiteral, which SPARQL libraries could recognise and automagically parse for you. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259576725.2511.519.camel%40ophelia2.g5n.co.uk Re: Non-XHTML host languages for RDFa 2009-11-30T10:25:26 2009-11-30T10:25:26 2009-11-30T10:25:26 On Mon, 2009-11-30 at 10:45 +0100, Ivan Herman wrote: > Thanks Toby. These are important information if we work on non-HTML > RDFa in the next incarnation of the RDFa group... > > As a comment on your question on SVG 1.2: > > [[[ > Should the predefined XHTML+RDFa keywords (e.g. "next", "prev") be > supported in SVG? > ]]] > > my answer is: I do not think so. And, actually... SVG1.2 Tiny is a >... On Mon, 2009-11-30 at 10:45 +0100, Ivan Herman wrote: > Thanks Toby. These are important information if we work on non-HTML > RDFa in the next incarnation of the RDFa group... > > As a comment on your question on SVG 1.2: > > [[[ > Should the predefined XHTML+RDFa keywords (e.g. "next", "prev") be > supported in SVG? > ]]] > > my answer is: I do not think so. And, actually... SVG1.2 Tiny is a > Recommendation, so I do not believe that question is relevant until > (and if...) the SVG group wants to update SVG1.2 Tiny. Ie, my feeling > is that, in the note, we should make it clear that keywords should not > be recognised in SVG... I've done a little more digging into this question. The SVG Tiny 1.2 Rec says: RDFa enforces the further requirement that each value string must be a CURIE Essentially they say "we don't enforce any requirements on the tokens in this attribute, but RDFa needs them to be CURIEs". However, that's factually incorrect. There are essentially two questions which emerge: 1. Is rel="next" OK to use in SVG. (I suspect the answer is yes.) 2. What should an RDFa processor do with it? (This is unclear.) I suspect that the definitive answer should come from the SVG group. > I was surprised not to see reference to the same issue for DataRSS. I > must admit I never looked at that spec. Do they accept the xhtml > keywords? DataRSS has pretty similar language over their definition of @rel, saying that it must contain CURIEs. However, unlike SVG Tiny 1.2, they include a normative reference to the XHTML+RDFa spec. So this seems to me to be a situation like: 1. Is rel="next" OK to use in DataRSS. (No.) 2. What should an RDFa processor do with it? (Process as per XHTML +RDFa.) Another interesting question about DataRSS is, given the following (example from the "Understanding DataRSS" page of the SearchMonkey Guide): <atom:entry> <atom:id>http://the.url/in/question</atom:id> ... <y:adjunct version="1.0" name="com.yahoo.test"> <y:meta property="tagspace:tags">tag 1 tag2 tag3 tag4</meta> <y:item rel="dc:subject" resource="http://photosite.com/img.jpg"> <y:type typeof="media:Photo"> <y:meta property="dc:creator">The Nameless One</meta> </y:type> </y:item> </y:adjunct> </atom:entry> What is the subject URI of the "tagspace:tags" triple? Should it be taken from the <atom:id> element? In version 0.3x of RDF::RDFa::Parser I may well include special support for Atom, in which if an <atom:entry> element is encountered, a new subject URI is set to the address given in <atom:id>, or a new bnode if no <atom:id> child exists. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259622188.2511.535.camel%40ophelia2.g5n.co.uk Re: NEW RDFa Test Suite (XHTML1.1, HTML4 and HTML5) 2009-11-30T23:03:10 2009-11-30T23:03:10 2009-11-30T23:03:10 On Sun, 2009-09-20 at 19:00 -0400, Manu Sporny wrote: > I spent some time this weekend re-writing the RDFa test harness so > that it would let us test XHTML1.1, HTML4 and HTML5 using a unified > set of tests. I've been testing RDF::RDFa::Parser against this test suite. (It was already passing the ones on the W3C website.) I have a query: HTML4 and HTML5 include test case 0113, which includes th... On Sun, 2009-09-20 at 19:00 -0400, Manu Sporny wrote: > I spent some time this weekend re-writing the RDFa test harness so > that it would let us test XHTML1.1, HTML4 and HTML5 using a unified > set of tests. I've been testing RDF::RDFa::Parser against this test suite. (It was already passing the ones on the W3C website.) I have a query: HTML4 and HTML5 include test case 0113, which includes the following: <body> <span about="#a" property="dc:title"></span> <span about="#b" property="dc:title" /> </body> And claims that the literals generated from each <span> should be identical. However, in HTML 4, "/>" does not represent a self-closing tag. Strictly speaking, if you want to follow the formal SGML SHORTTAG rules, I believe it's equivalent to this: <body> <span about="#a" property="dc:title"></span> <span about="#b" property="dc:title" >&gt; </body> Though that's invalid because the second <span> element is never closed. So, strictly following HTML4, the best literal a parser could come up with would be ">\n ". Using HTML5 parsing, it would be "\n ". Either way, I don't think this test should be included in the HTML test cases. If it is to be included, "" should not be the literal expected from the second <span>. Right now I'm passing all XHTML1 tests, and all but three of the HTML tests (failing the same three in both HTML4 and HTML5). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259658971.17105.4.camel%40ophelia2.g5n.co.uk Re: Non-XHTML host languages for RDFa 2009-12-01T09:16:13 2009-12-01T09:16:13 2009-12-01T09:16:13 On Tue, 2009-12-01 at 08:48 +0000, Mark Birbeck wrote: > Right...but as I say, a JavaScript parser running in a browser would > not be able to retrieve those RDFa documents, if they were in a > different domain to the main document. > > So even if we do support that, I think we need to do it in a way that > also supports a JSON solution. XHR requests are domain-restricted. This is the case whet... On Tue, 2009-12-01 at 08:48 +0000, Mark Birbeck wrote: > Right...but as I say, a JavaScript parser running in a browser would > not be able to retrieve those RDFa documents, if they were in a > different domain to the main document. > > So even if we do support that, I think we need to do it in a way that > also supports a JSON solution. XHR requests are domain-restricted. This is the case whether the profiles are in XML, XHTML or plain text. JSON doesn't change that. So called "JSON-P" (which is actually Javascript, not JSON) provides a workaround, but also opens a gaping security hole as it allows the server you're reading from to inject arbitrary Javascript code into your document. If your document contains any private data (e.g. you're using RDFa on pages containing your company's internal data on a page that's behind a corporate firewall) then a malevolent JSON-P profile could be used to steal that data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259659308.17105.8.camel%40ophelia2.g5n.co.uk Re: Default value for @about depending on language [Re: Non-XHTML host languages for RDFa] 2009-12-01T09:21:49 2009-12-01T09:21:49 2009-12-01T09:21:49 On Tue, 2009-12-01 at 01:09 +0100, Christoph LANGE wrote: > In OMDoc, however, the situation is different. There, RDFa metadata > are attached to elements, and the metadata are always metadata of > these elements, and it it recommended to give elements an @xml:id. > Therefore, we have in most cases the situation > > <element xml:id="i" about="#i"> > <meta property="onto:foo" content="bar"/> > ... On Tue, 2009-12-01 at 01:09 +0100, Christoph LANGE wrote: > In OMDoc, however, the situation is different. There, RDFa metadata > are attached to elements, and the metadata are always metadata of > these elements, and it it recommended to give elements an @xml:id. > Therefore, we have in most cases the situation > > <element xml:id="i" about="#i"> > <meta property="onto:foo" content="bar"/> > ... > </element> You could always lose the @about attribute and mention in your documentation that "OMDoc uses RDFa with the following modifications...". To be helpful you could provide an XSLT file to transform <element xml:id="foo"> to <element xml:id="foo" about="#foo">, which would ease the burden on people wishing to apply generic RDFa processors to OMDoc documents. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259661260.17105.27.camel%40ophelia2.g5n.co.uk Re: DOCTYPE versioning change proposal (ISSUE-4) 2009-12-01T09:54:21 2009-12-01T09:54:21 2009-12-01T09:54:21 On Tue, 2009-12-01 at 00:00 -0800, Larry Masinter wrote: > When this specification becomes a W3C Recommendation, a DOCTYPE with > a correct html version string will be: > <!DOCTYPE html PUBLIC “-//W3C//HTML 5.0//EN”> I know that HTML is moving away from its SGML legacy, but it still seems incongruous to use a public identifier string which does not conform to FPI syntax[1][2]. A possible DOC... On Tue, 2009-12-01 at 00:00 -0800, Larry Masinter wrote: > When this specification becomes a W3C Recommendation, a DOCTYPE with > a correct html version string will be: > <!DOCTYPE html PUBLIC “-//W3C//HTML 5.0//EN”> I know that HTML is moving away from its SGML legacy, but it still seems incongruous to use a public identifier string which does not conform to FPI syntax[1][2]. A possible DOCTYPE that could be used which does comply with FPI syntax is: <!DOCTYPE html PUBLIC "-//W3C//NONSGML HTML 5.0//EN"> Personally I think the "EN" at the end is unhelpful. It refers to the fact that the normative specification for HTML is in English - but I've seen people who change this part of the DOCTYPE to match the language the document is written in[3] - which is wrong. Given that FPIs don't need a language indicator at all, the above can be reduced to: <!DOCTYPE html PUBLIC "-//W3C//NONSGML HTML 5.0//"> ____ 1. http://en.wikipedia.org/wiki/Formal_Public_Identifier#Syntax 2. http://xml.coverpages.org/tauber-fpi.html 3. http://devfiles.myopera.com/articles/570/doctype-ci-url.htm (many examples) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259680432.17105.69.camel%40ophelia2.g5n.co.uk Re: NEW RDFa Test Suite (XHTML1.1, HTML4 and HTML5) 2009-12-01T15:13:54 2009-12-01T15:13:54 2009-12-01T15:13:54 On Mon, 2009-11-30 at 23:03 +0000, Toby Inkster wrote: > Right now I'm passing all XHTML1 tests, and all but three of the HTML > tests (failing the same three in both HTML4 and HTML5). Last night I spent ages puzzling over why I was failing test 0121 in HTML4 and HTML5, but not XHTML1, and today it's come to me out of nowhere. <p about="http://example.org/"> <span about="[]" property="dc:titl... On Mon, 2009-11-30 at 23:03 +0000, Toby Inkster wrote: > Right now I'm passing all XHTML1 tests, and all but three of the HTML > tests (failing the same three in both HTML4 and HTML5). Last night I spent ages puzzling over why I was failing test 0121 in HTML4 and HTML5, but not XHTML1, and today it's come to me out of nowhere. <p about="http://example.org/"> <span about="[]" property="dc:title">Test Case 0121</span> checks to make sure RDFa processors resolve the empty CURIE correctly. <p resource="[]"> <span property="dc:contributor">Shane McCarron</span> contributed to this test. </p> </p> In HTML, paragraphs cannot be nested. (In XHTML1 this is invalid too, but well-formed.) Thus, in parsing, the opening of the second paragraph automatically closes the first paragraph. Thus the above parses as if it were: <p about="http://example.org/"> <span about="[]" property="dc:title">Test Case 0121</span> checks to make sure RDFa processors resolve the empty CURIE correctly. </p> <p resource="[]"> <span property="dc:contributor">Shane McCarron</span> contributed to this test. </p> So the subject of the second triple is the implicit about="" on the <body> element. So, as far as HTML parsing is concerned, my parser is right and the test case's SPARQL result is wrong. Suggestion: replace the second <p> element with <b> or something. My suggestion to drop test case 0113 from the HTML test suites still stands too. As I believe these two test cases in the HTML test suites are erroneous, I won't be changing my parser to "pass" them. Other than that, RDF::RDFa::Parser is now passing all the HTML4, HTML5 and XHTML1 tests. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259687828.17105.78.camel%40ophelia2.g5n.co.uk Re: Non-XHTML host languages for RDFa 2009-12-01T17:17:10 2009-12-01T17:17:10 2009-12-01T17:17:10 For flexible integration with non-XHTML host languages, the next version of RDF::RDFa::Parser has the following optional features: 1. Allows lists of keywords to be configured on a per-attribute basis for @rel, @rev, @property, @datatype, @typeof, @about, @resource and @graph. 2. Allows CURIE prefixes to be treated case-insensitively (good for HTML). 3. Allows the empty CURIE prefix to be chang... For flexible integration with non-XHTML host languages, the next version of RDF::RDFa::Parser has the following optional features: 1. Allows lists of keywords to be configured on a per-attribute basis for @rel, @rev, @property, @datatype, @typeof, @about, @resource and @graph. 2. Allows CURIE prefixes to be treated case-insensitively (good for HTML). 3. Allows the empty CURIE prefix to be changed. 4. Supports colon-less CURIE prefixes (e.g. xmlns:foafname="http://xmlns.com/foaf/0.1/name" property="foafname"). RDF::RDFa::Parser is not an end-user tool, but a library for Perl. These options are switched on by the programmer using the library, not by the document itself. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259745646.17105.334.camel%40ophelia2.g5n.co.uk Re: Non-XHTML host languages for RDFa 2009-12-02T09:20:50 2009-12-02T09:20:50 2009-12-02T09:20:50 On Tue, 2009-12-01 at 23:57 +0100, Christoph LANGE wrote: > 2009-12-01 18:17 Toby Inkster <tai@g5n.co.uk>: > > 1. Allows lists of keywords to be configured on a per-attribute basis > > for @rel, @rev, @property, @datatype, @typeof, @about, @resource and > > @graph. > > aha, that sounds like an interesting approach, to enable that per > attribute. Not sure whether it should really be different for... On Tue, 2009-12-01 at 23:57 +0100, Christoph LANGE wrote: > 2009-12-01 18:17 Toby Inkster <tai@g5n.co.uk>: > > 1. Allows lists of keywords to be configured on a per-attribute basis > > for @rel, @rev, @property, @datatype, @typeof, @about, @resource and > > @graph. > > aha, that sounds like an interesting approach, to enable that per > attribute. Not sure whether it should really be different for, e.g. > @rel and @rev, and whether one would want keywords on @about and > @resource, but, well, why not? Let's see how people use it. I imagine that people would define @rel and @rev the same. As it's a structure that uses pointers (a hashref in Perl), it's pretty easy to set @rev's keywords list to be a pointer to @rel's. But they can be used separately if need be. > (What is @graph BTW?) RDF::RDFa::Parser has experimental support for quad-based RDFa parsing as per <http://buzzword.org.uk/2009/rdfa4/spec>. (Support is disabled by default.) > > 4. Supports colon-less CURIE prefixes (e.g. > > xmlns:foafname="http://xmlns.com/foaf/0.1/name" > property="foafname"). > > I have always thought that a name_space_ is something that contains a > lot of localnames. So this is indeed a creative (ab)use of > "namespaces" that only contain a single entity. I wouldn't say it is > illegal, though, it's definitely an interesting and elegant hack. It's legal in RDFa to do this: xmlns:foafname="http://xmlns.com/foaf/0.1/name" property="foafname:" Enabling the colon-less option just allows that last colon to be omitted. This idea comes from Mark Birbeck's article here: <http://webbackplane.com/mark-birbeck/blog/2009/04/30/tokenising-the-semantic-web> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259831564.17105.357.camel%40ophelia2.g5n.co.uk Re: Restricted Metadata Inheritance by Named Graphs? 2009-12-03T09:12:46 2009-12-03T09:12:46 2009-12-03T09:12:46 On Thu, 2009-12-03 at 00:21 +0100, Christoph LANGE wrote: > { ?resource :inheritsMetadata ?otherResource . > ?otherResource ?property ?value . } > => > { ?resource ?property ?value. } Possibly a slightly less naïve approach would be to define :inheritsMetadata more fully so that the definition of the property includes a list of what types of metadata it applies to. For example: :inheritsDu... On Thu, 2009-12-03 at 00:21 +0100, Christoph LANGE wrote: > { ?resource :inheritsMetadata ?otherResource . > ?otherResource ?property ?value . } > => > { ?resource ?property ?value. } Possibly a slightly less naïve approach would be to define :inheritsMetadata more fully so that the definition of the property includes a list of what types of metadata it applies to. For example: :inheritsDublinCoreMetadata a rdf:Property , :InheritanceProperty ; :inheritableMetadata dc:title, dc:description , dc:type . With the following rule: { ?a ?ip ?b . ?ip a :InheritanceProperty ; :inheritableMetadata ?prop . ?b ?prop ?val . } => { ?a ?prop ?val . } . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259832062.17105.359.camel%40ophelia2.g5n.co.uk Re: ESW Wiki (was Re: ISSUE-76: Need feedback on splitting Microdata into separate specification) 2009-12-03T09:21:03 2009-12-03T09:21:03 2009-12-03T09:21:03 On Wed, 2009-12-02 at 15:31 -0600, Laura Carlson wrote: > It has been said that the ESW Wiki is no longer supported. The ESW Wiki is used pretty heavily by the Semantic Web Interest Group. I don't think it's going to disappear any time soon. (There is some desire to switch it to MediaWiki but nobody's volunteered to do the conversion.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2009-12-02 at 15:31 -0600, Laura Carlson wrote: > It has been said that the ESW Wiki is no longer supported. The ESW Wiki is used pretty heavily by the Semantic Web Interest Group. I don't think it's going to disappear any time soon. (There is some desire to switch it to MediaWiki but nobody's volunteered to do the conversion.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259845562.17105.367.camel%40ophelia2.g5n.co.uk Re: working online RDFa parsers? 2009-12-03T13:06:13 2009-12-03T13:06:13 2009-12-03T13:06:13 On Wed, 2009-12-02 at 16:03 +0100, Dan Brickley wrote: > So what tools are you all using? And what can be done to improve the > state of tooling for casual users / learners? As of roughly now: http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= This uses the latest development code of my RDF::RDFa::Parser module, with Auto Config switched on (see RDF::RDFa::Parser 0.22 documentation for an e... On Wed, 2009-12-02 at 16:03 +0100, Dan Brickley wrote: > So what tools are you all using? And what can be done to improve the > state of tooling for casual users / learners? As of roughly now: http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= This uses the latest development code of my RDF::RDFa::Parser module, with Auto Config switched on (see RDF::RDFa::Parser 0.22 documentation for an explanation of Auto Config -- once it's released!). It's equipped with both an HTML parser and an XML parser, and will choose which one to use based on HTTP media type. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1259940673.17105.395.camel%40ophelia2.g5n.co.uk Re: Relationships between individual resources using POWDER 2009-12-04T15:31:15 2009-12-04T15:31:15 2009-12-04T15:31:15 On Thu, 2009-12-03 at 16:33 -0200, Alexandre Gaigalas wrote: > VADER: Vocabulary for Associating Descriptions of Resources > > Properties: > > vader:association - Describes an association between resources by URI > patterns > (all the following properties have rdfs:domain vader:association) > vader:host - A pattern for hosts > vader:minPathDeepness - Minimum of path levels associated > vader:max... On Thu, 2009-12-03 at 16:33 -0200, Alexandre Gaigalas wrote: > VADER: Vocabulary for Associating Descriptions of Resources > > Properties: > > vader:association - Describes an association between resources by URI > patterns > (all the following properties have rdfs:domain vader:association) > vader:host - A pattern for hosts > vader:minPathDeepness - Minimum of path levels associated > vader:maxPathDeepness - Maximum of path levels associated > vader:pathPrefix - Adds a prefix to the path association > vader:pathSuffix - Adds a suffix to the path association Interesting idea. I wonder if it might be made simpler by copying POWDER's regular expression capability? <vader:association> <vader:from>http://twitter.com/([^/]+)</vader:from> <vader:to>http://semantictweet.com/$1</vader:to> <vader:associationType rdf:resource="http://www.w3.org/2000/01/rdf-schema#seeAlso" /> </vader:association> Also, it's convention to capitalise the first letter of classes in RDF, so vader:association might be better as vader:Association. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260141775.22275.4.camel%40ophelia2.g5n.co.uk Re: ISSUE-76: Need feedback on splitting Microdata into separate specification 2009-12-06T23:22:57 2009-12-06T23:22:57 2009-12-06T23:22:57 On Sun, 2009-12-06 at 17:12 -0500, Aryeh Gregor wrote: > Microdata is not conceivably reusable outside of HTML, so modularity > is useless here. Why is it not conceivably reusable outside of HTML? RDFa was originally conceived to work inside XHTML, but SVG 1.2 Tiny now includes its attributes, as does the most recent version of OpenDocument, and Yahoo's DataRSS format (based on Atom). If Microdata is especially useful, then it's certainly possible to conceive of it similarly being used within other standards. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 2009-12-06 at 17:12 -0500, Aryeh Gregor wrote: > Microdata is not conceivably reusable outside of HTML, so modularity > is useless here. Why is it not conceivably reusable outside of HTML? RDFa was originally conceived to work inside XHTML, but SVG 1.2 Tiny now includes its attributes, as does the most recent version of OpenDocument, and Yahoo's DataRSS format (based on Atom). If Microdata is especially useful, then it's certainly possible to conceive of it similarly being used within other standards. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260168028.22275.19.camel%40ophelia2.g5n.co.uk Re: attaching multiple licenses 2009-12-07T06:40:30 2009-12-07T06:40:30 2009-12-07T06:40:30 On Sun, 2009-12-06 at 19:40 +0100, Georgi Kobilarov wrote: > Say I publish one URI for an artist: > http://example.org/resource/Madonna > > I aggregate information from multiple sources about that artist, and > those sources have different licenses. One triple comes from a source > under GNU FDL, another triple from a source under Public Domain, and a > owl:sameas link which I want to publish und... On Sun, 2009-12-06 at 19:40 +0100, Georgi Kobilarov wrote: > Say I publish one URI for an artist: > http://example.org/resource/Madonna > > I aggregate information from multiple sources about that artist, and > those sources have different licenses. One triple comes from a source > under GNU FDL, another triple from a source under Public Domain, and a > owl:sameas link which I want to publish under Creative Commons > License. Two methods spring to mind. The first is reification. It's probably not an excellent solution though - consumers would need to be specially aware of the fact that you're using reification, and that they should dereify your data. Something like: [ a rdf:Statement ; rdf:subject <http://example.org/resource/Madonna> ; rdf:predicate <http://xmlns.com/foaf/0.1/name> ; rdf:object "Madonna Veronica Louise Chicone" ; ex:statementLicence </public-domain-declaration> ] . A better solution might be to publish your data in a format that can make use of multiple graphs. e.g. in N3: { <http://example.org/resource/Madonna> <http://xmlns.com/foaf/0.1/name> "Madonna Veronica Louise Chicone" } ex:graphLicence </public-domain-declaration> . Unfortunately, most of the data formats with native support for named graphs do not have very good support in consuming software. But you can fake named graphs in formats like RDF/XML, Turtle, etc by simply splitting your data into multiple documents. So, in one file, you'd have: <http://example.org/resource/Madonna> <http://xmlns.com/foaf/0.1/name> "Madonna Veronica Louise Chicone" . <> ex:graphLicence </public-domain-declaration> . And in other files, you'd publish your other statements under different licenses. You'd use rdfs:seeAlso links between the files to enable autodiscovery. Of course, because of the nature of public domain data, you could duplicate that data in your other two files, so that any tool fetching, say just the GNU FDL data would get the public domain data too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/82f4afd6e59966ac2099b4fe9238816d.squirrel%40goddamn.co.uk Re: working online RDFa parsers? 2009-12-07T10:54:19 2009-12-07T10:54:19 2009-12-07T10:54:19 > I do not know why pyRdfa does not show up on the google list. But the > package is certainly downloadable and usable from inside an RDFLib (ie, > Python) applications. Searching for either PyRDFa or "RDFa Distiller" finds it on Google, but you do need to know the magic words. It would be nice if we had a decent RDFa parsing service come up as #1 when searching for "RDFa Parser" though. -Toby > I do not know why pyRdfa does not show up on the google list. But the > package is certainly downloadable and usable from inside an RDFLib (ie, > Python) applications. Searching for either PyRDFa or "RDFa Distiller" finds it on Google, but you do need to know the magic words. It would be nice if we had a decent RDFa parsing service come up as #1 when searching for "RDFa Parser" though. -Toby http://tobyinkster.co.uk/message/f00f21edeb191c5b51f85c2ac8655793.squirrel%40goddamn.co.uk Re: working online RDFa parsers? 2009-12-07T11:11:51 2009-12-07T11:11:51 2009-12-07T11:11:51 > As of roughly now: > > http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= > > This uses the latest development code of my RDF::RDFa::Parser module, > with Auto Config switched on (see RDF::RDFa::Parser 0.22 documentation > for an explanation of Auto Config -- once it's released!). It's equipped > with both an HTML parser and an XML parser, and will choose which one to > use based on HTTP medi... > As of roughly now: > > http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= > > This uses the latest development code of my RDF::RDFa::Parser module, > with Auto Config switched on (see RDF::RDFa::Parser 0.22 documentation > for an explanation of Auto Config -- once it's released!). It's equipped > with both an HTML parser and an XML parser, and will choose which one to > use based on HTTP media type. Here's an explanation of my Auto Config feature: it enables pages to opt-in to certain experimental features of RDF::RDFa::Parser. For example, they can switch on support for @lang (instead of, or as well as @xml:lang), or support for full URIs in attributes where CURIEs are expected. The syntax for doing this is deliberately RDF::RDFa::Parser-specific. It uses an HTTP-Query-String-like syntax in a <meta> element: <meta name="http://search.cpan.org/dist/RDF-RDFa-Parser/#auto_config" content="xhtml_lang=1&amp;xml_lang=0" /> <meta name="http://search.cpan.org/dist/RDF-RDFa-Parser/#auto_config" content="full_uris=1" /> This might be useful for RDFa TF members experimenting with, say, full URIs in RDFa. -Toby http://tobyinkster.co.uk/message/1260223195.1713.12.camel%40ophelia2.g5n.co.uk Re: ISSUE-76: Need feedback on splitting Microdata into separate specification 2009-12-07T21:59:57 2009-12-07T21:59:57 2009-12-07T21:59:57 On Mon, 2009-12-07 at 18:23 +0000, Ian Hickson wrote: > It's actually even worse than those two, because the microdata > processing model makes certain assumptions about the vocabulary. For > SVG to reuse itemscope=""/itemprop=""/etc, the processing model would > have to be rewritten to define how it works in SVG, and SVG would have > to be extended to provide parallels for <time itemprop datetime... On Mon, 2009-12-07 at 18:23 +0000, Ian Hickson wrote: > It's actually even worse than those two, because the microdata > processing model makes certain assumptions about the vocabulary. For > SVG to reuse itemscope=""/itemprop=""/etc, the processing model would > have to be rewritten to define how it works in SVG, and SVG would have > to be extended to provide parallels for <time itemprop datetime>, > <meta itemprop content>, <link itemprop href>, etc. I've been playing around with trying to implement Microdata and I don't think this is as big an issue as you're making out. Certainly it would be something the editor of a split-out Microdata spec would have to consider, if supporting non-HTML host languages was an aim, but it's not a big difficulty. It would be quite easy to say, for the value of a property element: - if the element has an itemscope attribute, use the item; - otherwise, if it has a content attribute, use that; - otherwise, if it has an href attribute, use that; - otherwise, if it has a src attribute, use that; - otherwise, if it has a datetime attribute, use that; - otherwise, use the text content. That's not *entirely* consistent with the current draft, but it is mostly in keeping with the spirit of it. For most conformant content, it will produce the same end result (exceptions being <object itemprop>, <ins itemprop datetime> and <del itemprop datetime> SVG 1.2 Tiny already has a content attribute, usable on any SVG element, and an href element too (albeit in the XLink namespace). For host markup languages which don't already have these attributes, a host-neutral Microdata spec could provide them in addition to providing the item* attributes. This issue is certainly not insurmountable. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260265550.1713.45.camel%40ophelia2.g5n.co.uk Re: RDFa without using xmlns: 2009-12-08T09:45:51 2009-12-08T09:45:51 2009-12-08T09:45:51 Replying to several messages in one... On Mon, 2009-12-07 at 23:07 +0000, Martin McEvoy wrote: > sorry about the quotes on everything php json decoding wont work with > out them. PHP's JSON implementation is perfectly correct to reject input where strings have not been quoted. RFC 4627 specifies that all strings in JSON *must* be quoted: string = quotation-mark *char quotation-mark ... Replying to several messages in one... On Mon, 2009-12-07 at 23:07 +0000, Martin McEvoy wrote: > sorry about the quotes on everything php json decoding wont work with > out them. PHP's JSON implementation is perfectly correct to reject input where strings have not been quoted. RFC 4627 specifies that all strings in JSON *must* be quoted: string = quotation-mark *char quotation-mark (quotation-mark is a double-quote). Mark Birbeck wrote: > First, the problem with using link/@rel value to point to a set of > prefix mappings is that you won't find them until you start > parsing...and by then it's too late. I disagree. I think it's an elegant way of linking to the mappings without defining much new stuff. (No new elements or attributes.) It is no more a problem for sequential programming than processing <base href> is, and RDFa processors already need to do that. Diving into the DOM to pick up prefix mappings before processing the root element for RDFa should be no more of a problem than diving in to pick up the base URI is. > One possible solution would be to use another attribute. Myself I'd > like to see us use @profile, and if the receiving server were to use > content-negotiation, then the prefix mappings could come back in any > form. I think using @profile would be a waste of bandwidth. It's already used for GRDDL and XMDP profiles. An RDFa processor would probably end up downloading a bunch of files that it doesn't have anything useful it can do with. > http://code.google.com/p/backplanejs/wiki/Rdfj I'd recommend removing references to "JSON" from this page. The format described does not seem to be serialisable to JSON (as defined by RFC 4627, or by json.org), though probably a subset of RDFj could. For example, Javascript functions may be used as literals in RDFj, but cannot be represented in JSON. Martin McEvoy wrote: > Another way I tried was setting a header tag to something like > "X-Dataset: http://...dataset.json" > It worked as a way to deliver the json to the parser before parsing > which was easy enough for parsers to Implement... but I think it may > be a little beyond what is actually practical... This would be useless to processors which can't see the HTTP envelope. And if a web page were saved to disk, it would lose its headers, and thus its semantics. Whatsmore, some publishers struggle with web server configuration, so requiring them to send particular headers can be a big ask. No, HTTP headers are not a good way of doing this. That said, if they were to be used, I'd recommend using the existing Link header (currently going through the later stages of the RFC process), rather than minting an X-Header: Link: </files/my_ds.json>; rel="http://weborganics.co.uk/ns/dataset" (rel types in Link headers are URIs) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260271700.1713.55.camel%40ophelia2.g5n.co.uk Re: RDFa without using xmlns: 2009-12-08T11:28:22 2009-12-08T11:28:22 2009-12-08T11:28:22 On Tue, 2009-12-08 at 11:15 +0000, Martin McEvoy wrote: > Mark mentioned that the page needs to be updated to use quotes ;) I was thinking more of this example: { /* bnode */ "a": "<http://www.w3.org/2004/09/fresnel#Format>", "http://www.w3.org/2004/09/fresnel#group": "<http://ubiquity-rdfa.googlecode.com/svn/trunk/_samples/formats/debug.html>", "http://ubiquity-rdfa.googlecode.com... On Tue, 2009-12-08 at 11:15 +0000, Martin McEvoy wrote: > Mark mentioned that the page needs to be updated to use quotes ;) I was thinking more of this example: { /* bnode */ "a": "<http://www.w3.org/2004/09/fresnel#Format>", "http://www.w3.org/2004/09/fresnel#group": "<http://ubiquity-rdfa.googlecode.com/svn/trunk/_samples/formats/debug.html>", "http://ubiquity-rdfa.googlecode.com/action": function(obj) { . . . return; } } Including Javascript functions is a non-trivial extension of JSON, enough to make the data unparsable by virtually any JSON library, and (even if parsed OK) useless outside of environments that can evaluate Javascript. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260275285.1713.56.camel%40ophelia2.g5n.co.uk Re: SWXG Scratchpad wave 2009-12-08T12:28:05 2009-12-08T12:28:05 2009-12-08T12:28:05 On Tue, 2009-12-08 at 12:27 +0100, Melvin Carvalho wrote: > I have 5 wave invites left. > Please message me with your preferred email address, if you would > like one. And I have... eight it seems. Same offer. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 2009-12-08 at 12:27 +0100, Melvin Carvalho wrote: > I have 5 wave invites left. > Please message me with your preferred email address, if you would > like one. And I have... eight it seems. Same offer. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260290845.1713.79.camel%40ophelia2.g5n.co.uk Re: attaching multiple licenses 2009-12-08T16:47:28 2009-12-08T16:47:28 2009-12-08T16:47:28 On Mon, 2009-12-07 at 11:05 +0000, Tom Heath wrote: > IIRC then Tim disagreed with this at some point, arguing that two > documents that describe the same resource and are reached by content > negotiation and a 303 from the same URI should contain the same > information to the greatest possible extent. Even where we discount > aspects like navigation and ads in HTML documents I don't agree with > ... On Mon, 2009-12-07 at 11:05 +0000, Tom Heath wrote: > IIRC then Tim disagreed with this at some point, arguing that two > documents that describe the same resource and are reached by content > negotiation and a 303 from the same URI should contain the same > information to the greatest possible extent. Even where we discount > aspects like navigation and ads in HTML documents I don't agree with > this; HTML and RDF documents have different audiences and therefore > the requirements on them are different. I agree that two representations of a resource should provide substantially the same data (within the limits of the media types of each resource), but if you're offering two separate resources at separate URIs, then I don't see why they need contain similar data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260291175.1713.84.camel%40ophelia2.g5n.co.uk Re: quick advice on content negotiation 2009-12-08T16:52:55 2009-12-08T16:52:55 2009-12-08T16:52:55 On Tue, 2009-12-08 at 16:43 +0000, Nathan wrote: > I've implemented content negotiation as follows: > where we have a URI resource http://example.org/user/23 > when that URI is requested then content negotiation using the Accept > header kicks in, if any of the RDF formats are specified and data > exists then serialized RDF in the requested format is returned; > > if one of the HTML types is requ... On Tue, 2009-12-08 at 16:43 +0000, Nathan wrote: > I've implemented content negotiation as follows: > where we have a URI resource http://example.org/user/23 > when that URI is requested then content negotiation using the Accept > header kicks in, if any of the RDF formats are specified and data > exists then serialized RDF in the requested format is returned; > > if one of the HTML types is requested then an HTML document > (essentially the "page" is returned. > > in addition adding the extension .n3 / .rdf to the uri causes content > RDF to be returned instead. > > passable and usable? An important question not answered in your message is: what is the URI <http://example.org/user/23> supposed to identify? If it identifies a particular person, then this behavious semantically problematic. Why? Because a web server should never respond "200 OK" to a request for a URI identifying a person, unless it intends to physically chop the person up and pass him/her down the wire to the receiving user agent. If the URI <http://example.org/user/23> is supposed to identify, say, a person's profile, and you have a different URI to represent the person themselves (e.g. <http://example.org/user/23#me>) then the connection negotiation setup you describe is fine. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260291373.1713.87.camel%40ophelia2.g5n.co.uk Re: RDFa without using xmlns: 2009-12-08T16:56:14 2009-12-08T16:56:14 2009-12-08T16:56:14 On Tue, 2009-12-08 at 14:59 +0000, Martin McEvoy wrote: > The json example you provided above seems to be invalid json, > (unquoted strings, not key => value pairs ) so I am a little at a loss > at what you are attempting to do, so I will guess here is how I would > represent your example in json and you tell me what I am missing.... That's rather my point. The example I posted (which was a quote... On Tue, 2009-12-08 at 14:59 +0000, Martin McEvoy wrote: > The json example you provided above seems to be invalid json, > (unquoted strings, not key => value pairs ) so I am a little at a loss > at what you are attempting to do, so I will guess here is how I would > represent your example in json and you tell me what I am missing.... That's rather my point. The example I posted (which was a quote from the RDFj wiki page on Google Code) *cannot* be represented in JSON because JSON doesn't have a data type equivalent to Javascript's first-class function objects. Thus RDFj is not JSON - it's Javascript. (Or rather, it uses a format that's a subset of Javascript but a superset of JSON.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260364269.1713.166.camel%40ophelia2.g5n.co.uk Re: attaching multiple licenses 2009-12-09T13:11:10 2009-12-09T13:11:10 2009-12-09T13:11:10 On Wed, 2009-12-09 at 07:15 -0500, Kingsley Idehen wrote: > Yes, I still stand by my case for HTTP URIs as implicit vehicles of > Attribution. <http://dbpedia.org/resource/Arthur_Brown_(musician)> <http://dbpedia.org/ontology/Person/homeTown> <http://dbpedia.org/resource/Lewes> . The above triple is true, though it doesn't make sense to attribute it to dbpedia.org, as DBpedia doesn't seem to know about it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2009-12-09 at 07:15 -0500, Kingsley Idehen wrote: > Yes, I still stand by my case for HTTP URIs as implicit vehicles of > Attribution. <http://dbpedia.org/resource/Arthur_Brown_(musician)> <http://dbpedia.org/ontology/Person/homeTown> <http://dbpedia.org/resource/Lewes> . The above triple is true, though it doesn't make sense to attribute it to dbpedia.org, as DBpedia doesn't seem to know about it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260399601.25743.9.camel%40ophelia2.g5n.co.uk Re: Telecon Agenda - 19 November 2009, 1600 UTC 2009-12-09T23:00:04 2009-12-09T23:00:04 2009-12-09T23:00:04 On Wed, 2009-12-09 at 17:44 -0500, Manu Sporny wrote: > we need to do some HTML+RDFa housekeeping I'd appreciate it if you could take a look at the two HTML test case issues I raised recently: http://www.w3.org/mid/1259680432.17105.69.camel@ophelia2.g5n.co.uk Test cases 0121 and 0113 are invalid HTML (in both HTML 4.x and HTML5) and passing them requires an implementation to deviate from the HTML5 parsing algorithm. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2009-12-09 at 17:44 -0500, Manu Sporny wrote: > we need to do some HTML+RDFa housekeeping I'd appreciate it if you could take a look at the two HTML test case issues I raised recently: http://www.w3.org/mid/1259680432.17105.69.camel@ophelia2.g5n.co.uk Test cases 0121 and 0113 are invalid HTML (in both HTML 4.x and HTML5) and passing them requires an implementation to deviate from the HTML5 parsing algorithm. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260549831.32395.51.camel%40ophelia2.g5n.co.uk Possible test case candidate? 2009-12-11T16:43:52 2009-12-11T16:43:52 2009-12-11T16:43:52 What triple should this generate? <div xmlns:blank="_:" about="[blank:foobar]" rel="next" resource="[blank:foobaz]" ></div> Here are a few candidates as N-Triples: # Just treat the CURIE prefix like any other, even though "_" is not # a registered URI scheme (and syntactically cannot be). <_:foobar> <http://www.w3.org/1999/xhtml/vocab#next> <_:foobaz> . # This is wha... What triple should this generate? <div xmlns:blank="_:" about="[blank:foobar]" rel="next" resource="[blank:foobaz]" ></div> Here are a few candidates as N-Triples: # Just treat the CURIE prefix like any other, even though "_" is not # a registered URI scheme (and syntactically cannot be). <_:foobar> <http://www.w3.org/1999/xhtml/vocab#next> <_:foobaz> . # This is what my parser currently does because it passes resources # about as plain strings, so the fact that they're not really bnodes # gets lost. _:foobar <http://www.w3.org/1999/xhtml/vocab#next> _:foobaz . # If "blank" is completely ignored as a CURIE prefix, then perhaps # @about and @resource are treated as relative URIs? <%5Bblank:foobar%5D> <http://www.w3.org/1999/xhtml/vocab#next> <%5Bblank:foobar%5D> . # Or maybe as references to the current document? <> <http://www.w3.org/1999/xhtml/vocab#next> <> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260576929.32395.64.camel%40ophelia2.g5n.co.uk RE: ISSUE-76: If we fixed namespaces, does RDFa still have problems? 2009-12-12T00:15:31 2009-12-12T00:15:31 2009-12-12T00:15:31 On Fri, 2009-12-11 at 20:14 +0000, Ennals, Robert wrote: > Yeah. You are right. But typing about="_:bnode" seems pretty awkward > for end users, especially given that, in the microdata usage models, > this is something we expect to see almost everywhere. Microdata's > "itemscope" seems much more friendly. I *think* typeof="" should quickly and easily accomplish the feat of creating a blank node ... On Fri, 2009-12-11 at 20:14 +0000, Ennals, Robert wrote: > Yeah. You are right. But typing about="_:bnode" seems pretty awkward > for end users, especially given that, in the microdata usage models, > this is something we expect to see almost everywhere. Microdata's > "itemscope" seems much more friendly. I *think* typeof="" should quickly and easily accomplish the feat of creating a blank node without giving it a name or type, or using chaining, but the current RDFa spec is a little unclear in that regard. Hopefully RDFa 1.1 will clarify this particular case, as I do think it's a useful pattern. > In Microdata, a common idiom is to write something like the following: > > <div itemscope> > <span itemprop="name">Rob</span> > <div itemprop="knows" itemscope> > <span itemprop="name">Manu</span> > <span itemprop="special-power">RDFa wizardry</span> > </div> > </div> > > This declares two blank nodes, one for me and one for you, and > declares that you are my friend. > > In RDFa I believe I would have to write: > > <div about="_:bnode" vocab="whatever"> > <span property="name">Rob</span> > <div rel="knows"> -- This node isn't needed in Microdata > <div about="_:bnode2"> > <span property="name">Manu</span> > <span property="special-power">RDFa wizardry</span> > </div> > </div> In RDFa you could write: <div about="_:bnode" vocab="whatever"> <span property="name">Rob</span> <div rel="knows"> <span property="name">Manu</span> <span property="special-power">RDFa wizardry</span> </div> </div> No extra node. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260743281.32395.112.camel%40ophelia2.g5n.co.uk Re: Creating JSON from RDF 2009-12-13T22:28:03 2009-12-13T22:28:03 2009-12-13T22:28:03 On Sat, 2009-12-12 at 21:42 +0000, Jeni Tennison wrote: > To put this in context, what I think we should aim for is a pure > publishing format that is optimised for approachability for normal > developers, *not* an interchange format. RDF/JSON [1] and the SPARQL > results JSON format [2] aren't entirely satisfactory as far as I'm > concerned because of the way the objects of statements are... On Sat, 2009-12-12 at 21:42 +0000, Jeni Tennison wrote: > To put this in context, what I think we should aim for is a pure > publishing format that is optimised for approachability for normal > developers, *not* an interchange format. RDF/JSON [1] and the SPARQL > results JSON format [2] aren't entirely satisfactory as far as I'm > concerned because of the way the objects of statements are represented > as JSON objects rather than as simple values. jsonGRDDL <http://buzzword.org.uk/2008/jsonGRDDL/spec> provides a method of mapping from more human-friendly JSON formats to RDF/JSON. (Much like GRDDL does mapping XML to RDF/XML.) Essentially you want the inverse. It seems to me that for a format to be very human-friendly, it helps for it to be fairly domain-specific. For example, if you know you're modelling people, then it makes sense to have the "sex" property as a single value, but telephone number, e-mail address, and perhaps even name might be arrays. With a deep enough OWL ontology (so that it can be figured out which properties are singular and plural), I suppose you could get software to do a reasonably good job creating these human-friendly formats from RDF data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260829903.32395.135.camel%40ophelia2.g5n.co.uk RE: ISSUE-76: If we fixed namespaces, does RDFa still have problems? 2009-12-14T22:31:46 2009-12-14T22:31:46 2009-12-14T22:31:46 On Mon, 2009-12-14 at 18:46 +0000, Ennals, Robert wrote: > Then the value of @property is just “x-apple:whatever”. A tool that > wanted to understand a page semantically could either risk the danger > of name clashes and assume that “x-apple” means what it thinks it > does, or it could check for the presence of an xmlns declaration > saying what “x-apple” means. Given that the name "Apple" was re... On Mon, 2009-12-14 at 18:46 +0000, Ennals, Robert wrote: > Then the value of @property is just “x-apple:whatever”. A tool that > wanted to understand a page semantically could either risk the danger > of name clashes and assume that “x-apple” means what it thinks it > does, or it could check for the presence of an xmlns declaration > saying what “x-apple” means. Given that the name "Apple" was recently subject to an enormous lawsuit between Apple Records and Apple Computers, surely this shows precisely why this couldn't work? A registration authority is needed to ensure uniqueness of name. RDF uses URIs, and thus piggybacks on top of a registration authority which has proved itself to be pretty good: the DNS. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260869122.32395.154.camel%40ophelia2.g5n.co.uk RE: ISSUE-76: If we fixed namespaces, does RDFa still have problems? 2009-12-15T09:25:25 2009-12-15T09:25:25 2009-12-15T09:25:25 On Tue, 2009-12-15 at 04:15 +0100, Leif Halvard Silli wrote: > I think, to make RDFa "native" to HTML and simple to use, then a > vocabulary for the HTML namespace could be useful. > > It should be simpler to use this vocabulary than other vocabularies. > Either because it could be used without any prefix at all. XHTML+RDFa 1.0 already has this. The default prefix is: http://www.w3.org/199... On Tue, 2009-12-15 at 04:15 +0100, Leif Halvard Silli wrote: > I think, to make RDFa "native" to HTML and simple to use, then a > vocabulary for the HTML namespace could be useful. > > It should be simpler to use this vocabulary than other vocabularies. > Either because it could be used without any prefix at all. XHTML+RDFa 1.0 already has this. The default prefix is: http://www.w3.org/1999/xhtml/vocab# And it contains a bunch of terms useful for describing (X)HTML documents. It has terms like "chapter", "appendix", "contents", "index", "glossary", "copyright" and "license". CURIEs in the default prefix are written with an empty first part, e.g. the second CURIE in this attribute: rel="dc:license :license cc:license" Within @rel and @rev in fact, terms from the current XHTML vocabulary are treated as case-insensitive keywords, so the leading colon isn't needed either. I'd certainly like to see the XHTML vocabulary expand to cover other terms useful for describing typical XHTML documents. Authorship, dates, topic/keyword, title and description properties seem natural additions. The vocab itself can be added to without needing any changes to RDFa, though the new terms would not be recognised as case-insensitive keywords by RDFa 1.0 processors. > These HTML namespace vocabularies would then also be possible to use > not only in HTML documents, but also in other mark-up languages. The SVG Tiny 1.2 Rec (which includes RDFa) unfortunately has little to say on whether the default prefix and keywords apply to SVG. In my parser, I decided that these should work the same as XHTML. Hopefully, clearer guidance to using RDFa in non-XHTML host languages will be one of the things an RDFa WG will deliver. When SVG or MathML are used *within* XHTML, I certainly think it's a good idea to apply the XHTML rules throughout. Switching rules for document fragments does not seem desirable. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260897357.32395.188.camel%40ophelia2.g5n.co.uk Re: ISSUE-76: If we fixed namespaces, does RDFa still have problems? 2009-12-15T17:16:00 2009-12-15T17:16:00 2009-12-15T17:16:00 On Tue, 2009-12-15 at 17:20 +0200, Henri Sivonen wrote: > On Dec 14, 2009, at 03:29, Manu Sporny wrote: > > > Microdata: > > > > <div itemscope> > > <p>My name is <span itemprop="name">Aryeh Gregor</span>.</p> > > </div> > > > > RDFa: > > > > <div about="#me" vocab="myvocab.html"> > > <p>My name is <span property="name">Aryeh Gregor</span>.</p> > > </div> > > > > or > > > > <div about="#me" ... On Tue, 2009-12-15 at 17:20 +0200, Henri Sivonen wrote: > On Dec 14, 2009, at 03:29, Manu Sporny wrote: > > > Microdata: > > > > <div itemscope> > > <p>My name is <span itemprop="name">Aryeh Gregor</span>.</p> > > </div> > > > > RDFa: > > > > <div about="#me" vocab="myvocab.html"> > > <p>My name is <span property="name">Aryeh Gregor</span>.</p> > > </div> > > > > or > > > > <div about="#me" xmlns:myvoc="http://ficticious.url/vocab#"> > > <p>My name is <span property="myvoc:name">Aryeh Gregor</span>.</p> > > </div> > > Are these RDFa examples complete without an id="me" somewhere? That > is, is baseuri#me supposed to be an imaginary URL that doesn't > dereference to a node but is just talked about or is it supposed to > point to a node? This is a question that's important, but orthogonal to RDFa (it applies equally to, say, Microdata's itemid attribute). I'm personally of the opinion that a URI should identify precisely one thing, so for the given examples, in an ideal world, there would *not* be an id="me" attribute anywhere in the document. If there were such an attribute, it would introduce confusion as to what the URI <baseuri#me> represents - does it represent a section of a document, or does it represent a person called Aryeh Gregor? There are of course valid situations when you'd want to provide paired id and about attributes. One example is when you're providing metadata about a specific element or part of the document: <section id="foo" xmlns:dc="http://purl.org/dc/terms/"> <p>...blah...</p> <div about="#foo" property="dc:modified" content="2009-12-15">Last changed today.</div> </section> > * Generating more than one triple per element is confusing. It can be, but in my experience writing RDFa, I think it's better than the alternative of forcing authors to create additional elements to carry extra data. I often find myself wishing I could squeeze extra triples into existing elements. > * Conflict with existing rel token processing (due to not requiring > Safe-CURIE there). In practise, I can't remember having seen this cause an issue in the wild. > * Namespaces are a complication for implementors. Not sure if you're referring to consumers or producers. Or perhaps both? There are certainly several annoyances when parsing RDFa. Namespaces are one of them. But most of the annoyances come from the underlying host language - processing language attributes is annoying (mostly because you have to make sure to ignore invalid attributes); resolving relative URIs is something I could do without; XML canonicalisation is also quite irritating. As an RDFa author though, many of the hoops that RDFa processors have to jump through are the little tricks that save me time. I don't want to have to spell out all URIs in full, so CURIEs and relative URIs provide me with a good shortcut. I certainly don't want to specify an xml:lang attribute on every single element, so I'm happy I can just add one to the root element and rely on that being inherited by all its descendants. As an author of RDFa documents, the one things that does get on my nerves is that the use of CURIEs isn't optional. When handwriting RDFa, splitting URIs into prefix and suffix isn't a problem, but when machine generating it, it's an annoyance. Depending on how you're generating your RDFa, it might not be a problem - if you're writing, say, a CMS which uses a fixed set of property and class URIs, it won't cause any pain. But if you're trying to serialise arbitrary RDF data to RDFa, it's an extra step that you'd rather not go through. I'm pleased that allowing full URIs in currently CURIE-only attributes is planned for the next version of RDFa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1260966197.32395.234.camel%40ophelia2.g5n.co.uk Re: ISSUE-27: rel-ownership - Chairs Solicit Proposals 2009-12-16T12:23:18 2009-12-16T12:23:18 2009-12-16T12:23:18 > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html Your new explanation on @rev in HTML4 states: > some hold that rev reverses > the direction of the link, while others that it reverses the > semantics of the relation itself The HTML 4.01 Recommendation defines @rel as: "the relationship f... > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html Your new explanation on @rev in HTML4 states: > some hold that rev reverses > the direction of the link, while others that it reverses the > semantics of the relation itself The HTML 4.01 Recommendation defines @rel as: "the relationship from the current document to the anchor specified by the href attribute" <http://www.w3.org/TR/html4/struct/links.html#adef-rel> And @rev as: "a reverse link from the anchor specified by the href attribute to the current document" <http://www.w3.org/TR/html4/struct/links.html#adef-rev> Further it illustrates this with an example (linked to from the @rev definition) showing them both in use, stating that the following code in Document A: <LINK href="docB" rel="foo"> has "exactly the same meaning" as the following code in Document B: <LINK href="docA" rev="foo"> The earlier 4.0 Recommendation has word-for-word identical definitions and examples. 3.2 is similar <http://www.w3.org/TR/REC-html32#link>. I don't doubt that some people are confused by @rev. (If you look hard enough, you can find people confused about almost anything.) But given that all the relevant recommendations are quite clear in stating that @rev reverses the *direction* of the link, it seems disingenuous to present them as two equally valid interpretations of the definition of @rev. I'd suggest changing the wording to something like: while rev is defined to reverse the direction of the link, some have implemented it as if it reversed the semantics of the link type Though, that having been said, although I've seen a handful of examples where people have mistakenly used @rev instead of @rel, either through ignorance or the slip of a finger, I can't remember seeing any which *rely* on the mistaken interpretation of it reversing the semantics of the link type. For example, I've never seen a page which used, say, rel="author" to link to the author and rev="author" to link to people who did not contribute to the document. PS: in case you're not aware of it, I've implemented a parser for HTTP Link headers in Perl, and am in general a big fan of them. http://search.cpan.org/~tobyink/HTTP-Link-Parser/lib/HTTP/Link/Parser.pm -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1261869106.18012.14.camel%40ophelia2.g5n.co.uk Re: Orderly (& JSON Schema language(s)) 2009-12-26T23:11:50 2009-12-26T23:11:50 2009-12-26T23:11:50 On Wed, 2009-12-23 at 17:19 +0100, Dan Brickley wrote: > Just found http://orderly-json.org/ Orderly's still a bit of a work in progress, though there's already implementations springing up. It arose out of discussions on the JSON Schema mailing list <json-schema@googlegroups.com>. Indeed I think some of the syntactic features of Orderly are based on my suggestions (e.g. trailing '?' to indicate... On Wed, 2009-12-23 at 17:19 +0100, Dan Brickley wrote: > Just found http://orderly-json.org/ Orderly's still a bit of a work in progress, though there's already implementations springing up. It arose out of discussions on the JSON Schema mailing list <json-schema@googlegroups.com>. Indeed I think some of the syntactic features of Orderly are based on my suggestions (e.g. trailing '?' to indicate optional properties; use of '{min,max}' to indicate ranges -- mostly ideas I nicked from regular expressions). Orderly can be thought of as the equivalent of Relax NG Compact Syntax for the JSON world. (Much like JSONSchema can be thought of as the equivalent of XML Schema or Relax NG's XML syntax.) Generally I think there is some interesting work to be done in "porting" ideas from the XML world to JSON and vice versa. (Though with XML being a more mature technology, there is more of the former than the latter to be done.) Which brings me to... > There's an online demo and code on github. Seems like it could be a > good system to explore some GRDDL-ish extensions that map idiomatic > JSON into RDF? This is precisely what I was trying to do with jsonGRDDL (which I bang on about from time to time): http://buzzword.org.uk/2008/jsonGRDDL/spec The idea is to port the GRDDL idea as closely as possible from XML to JSON, but to do it sympathetically - i.e. to not try to shoehorn XML technologies like XSLT in. The idea is that you should be able to use "human-friendly" JSON structures like: { "name" : "Toby Inkster" , "homepage" : "http://tobyinkster.co.uk/" } And be able to uplift the data into a more semantically rich model (i.e. RDF). I have a working implementation, which for a while was offered online as a web service, though it's down at the moment. I have plans to port my implementation to Gregory William's RDF::Trine Perl framework. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1262173234.2190.28.camel%40ophelia2.g5n.co.uk Re: ISSUE-27: rel-ownership - Chairs Solicit Proposals 2009-12-30T11:40:35 2009-12-30T11:40:35 2009-12-30T11:40:35 On Wed, 2009-12-30 at 10:02 +1100, Mark Nottingham wrote: > Thanks for the implementation ref; I have a very simple one in Python > at <http://gist.github.com/210535>. Any interest in working on a test > suite? I have a few tests as part of HTTP::Link::Parser: http://cpansearch.perl.org/src/TOBYINK/HTTP-Link-Parser-0.04/t/HTTP-Link-Parser.t CPAN, the Perl packaging system, runs them as part of ... On Wed, 2009-12-30 at 10:02 +1100, Mark Nottingham wrote: > Thanks for the implementation ref; I have a very simple one in Python > at <http://gist.github.com/210535>. Any interest in working on a test > suite? I have a few tests as part of HTTP::Link::Parser: http://cpansearch.perl.org/src/TOBYINK/HTTP-Link-Parser-0.04/t/HTTP-Link-Parser.t CPAN, the Perl packaging system, runs them as part of the installation process. The test script creates a fake HTTP::Response object adds a Base header to it and six Link headers, then parses it with HTTP::Link::Parser. It then checks that the parser has picked up various relationships and properties from the response headers. The tests include absolute URIs and registered tokens in the relationships; use of spaces in rel; and the anchor, rel, rev, hreflang, type, title and title* parameters. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1262198690.2190.38.camel%40ophelia2.g5n.co.uk Re: Mixed XHTML+MathML+SVG+RDFa markup 2009-12-30T18:44:50 2009-12-30T18:44:50 2009-12-30T18:44:50 On Sun, 2009-12-27 at 22:54 +0200, Shlomi Fish wrote: > How can I do a mixed XHTML+MathML+SVG+RDFa markup? I have some > MathML code at, for example: > > http://www.shlomifish.org/MathVentures/bugs-in-square-mathml.xhtml > > And I'd like to licence it under a Creative Commons licence? If you want to license the entire page, then it's as simple as: <a rel="license" href="http://example.c... On Sun, 2009-12-27 at 22:54 +0200, Shlomi Fish wrote: > How can I do a mixed XHTML+MathML+SVG+RDFa markup? I have some > MathML code at, for example: > > http://www.shlomifish.org/MathVentures/bugs-in-square-mathml.xhtml > > And I'd like to licence it under a Creative Commons licence? If you want to license the entire page, then it's as simple as: <a rel="license" href="http://example.com/link/to/license">link text</a> If there's a specific part of it that you want to license, then you can wrap it in, say: <div id="bit-i-want-to-license"> ... </div> And then apply the license like this: <a about="#bit-i-want-to-license" rel="license" href="http://example.com/link/to/license">link text</a> If there are some external files like the Perl script you wish to license, then you could use: <a about="gen-bugs-in-square-svg.pl" rel="license" href="http://example.com/link/to/license">link text</a> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1262220687.2190.51.camel%40ophelia2.g5n.co.uk Re: Mixed XHTML+MathML+SVG+RDFa markup 2009-12-31T00:51:29 2009-12-31T00:51:29 2009-12-31T00:51:29 On Thu, 2009-12-31 at 00:42 +0200, Shlomi Fish wrote: > XHTML, MathML, SVG, RDFa, etc. and still validate. I'm looking for a > good DTD definition. Ah, I see. As far as I know, nobody has bothered to create one. Someone would need to take: http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ And add in the RDFa module. (Adding the Role attribute module too might be nice.) That said, DTD validation ... On Thu, 2009-12-31 at 00:42 +0200, Shlomi Fish wrote: > XHTML, MathML, SVG, RDFa, etc. and still validate. I'm looking for a > good DTD definition. Ah, I see. As far as I know, nobody has bothered to create one. Someone would need to take: http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ And add in the RDFa module. (Adding the Role attribute module too might be nice.) That said, DTD validation doesn't really work with RDFa, or indeed any namespaced XML, because DTDs are namespace-unaware. (The W3C validator hides a few namespace-related error messages, so you might not notice how poorly DTD-based validation works for namespaced documents.) A Relax NG schema might be of better practical use for authors wishing to check XHTML+MathML+SVG+RDFa documents. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1262762650.2855.582.camel%40ophelia2.g5n.co.uk Re: [Bug 8611] Consider adding a full schema to H:TML 2010-01-06T07:24:14 2010-01-06T07:24:14 2010-01-06T07:24:14 On Tue, 2010-01-05 at 20:00 -0800, Joe D Williams wrote: > Ok, so that is a rule for XHTML but does not describe or explain the > text/html usage where the atttribute may appear in html as a string > not followed by = but having the special rule that says if only the > attribute name string is present and followed by separator then that > is ok and the default value is the empty string which m... On Tue, 2010-01-05 at 20:00 -0800, Joe D Williams wrote: > Ok, so that is a rule for XHTML but does not describe or explain the > text/html usage where the atttribute may appear in html as a string > not followed by = but having the special rule that says if only the > attribute name string is present and followed by separator then that > is ok and the default value is the empty string which means a default > functionality that you can go read in the spec what it does. In this > case it is the =value part of the attribute that is optional in the > user code (or is the name= part optional?) . Clearly an XML schema would only be directly applicable to HTML5 that is also XML (i.e. XHTML5), but even with this limitation, it still seems like a valuable exercise. HTML5's text/html syntax has a canonical mapping to the DOM, and -- excepting a few edge cases[1] -- the DOM can be serialised to XHTML[2], so via this indirect route text/html would also be checkable against an XML schema. ____ 1. And some of the edge cases could be worked around. e.g. DOMs that contain unserializable Comment nodes could just have those nodes removed prior to serialisation, as they're not going to cause any problems checking against an XML schema. 2. http://www.w3.org/TR/html5/the-xhtml-syntax.html#serializing-xhtml-fragments -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1262773831.2855.591.camel%40ophelia2.g5n.co.uk Re: Semantics of rdf:Statement 2010-01-06T10:30:33 2010-01-06T10:30:33 2010-01-06T10:30:33 On Tue, 2010-01-05 at 00:54 -0600, Pat Hayes wrote: > On Jan 4, 2010, at 5:11 PM, darood wrote: > > > • “sister of” - Symmetric > > No. Mary sisterOf John, but not John sisterOf Mary. Depending on your definition of "sister of" with regards to step-sisters, half-sisters, sisters-in-law, etc, the relation may be transitive though. { :Mary :sisterOf :John . :Anne :sisterOf :Mary . } => {... On Tue, 2010-01-05 at 00:54 -0600, Pat Hayes wrote: > On Jan 4, 2010, at 5:11 PM, darood wrote: > > > • “sister of” - Symmetric > > No. Mary sisterOf John, but not John sisterOf Mary. Depending on your definition of "sister of" with regards to step-sisters, half-sisters, sisters-in-law, etc, the relation may be transitive though. { :Mary :sisterOf :John . :Anne :sisterOf :Mary . } => { :Anne :sisterOf :John . } . Amongst an all-female population, sisterOf becomes a symmetric relationship too. A slightly broader transitive "sisterOf-or-sameAs" relationship (that is, a definition which effectively counts each woman herself amongst her own sisters), in an all-female population is an equivalence relationship. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1262961641.2855.612.camel%40ophelia2.g5n.co.uk Re: Call for Toics and Invited Talks for 2010! 2010-01-08T14:40:46 2010-01-08T14:40:46 2010-01-08T14:40:46 On Fri, 2010-01-08 at 13:12 +0000, Harry Halpin wrote: > 7) OpenMicroblogging and Twitter - We can invite someone from Twitter > and really sit down and compare OMB to Twitter's APIs. This is comparing apples with oranged. The OpenMicroblogging protocol and Twitter API serve two different uses: OMB deals with server-to-server propagation of messages and profile updates; the Twitter API is for cl... On Fri, 2010-01-08 at 13:12 +0000, Harry Halpin wrote: > 7) OpenMicroblogging and Twitter - We can invite someone from Twitter > and really sit down and compare OMB to Twitter's APIs. This is comparing apples with oranged. The OpenMicroblogging protocol and Twitter API serve two different uses: OMB deals with server-to-server propagation of messages and profile updates; the Twitter API is for client-to-server communication (e.g. allowing desktop microblogging clients to push messages to a user's notice stream). StatusNet, which is the highest profile implementation of OMB, also implements a Twitter-compatible API (a large overlap with Twitter's API, but some minor differences to account for slightly different functionality of the platforms) for client-to-server communication. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263254957.22239.18.camel%40ophelia2.g5n.co.uk Re: CfC: Publish HTML5 Microdata as First Public Working Draft and a new HTML5 Working Draft 2010-01-12T00:09:21 2010-01-12T00:09:21 2010-01-12T00:09:21 On Thu, 2010-01-07 at 22:12 -0800, Maciej Stachowiak wrote: > Silence will be taken to mean there is no objection, but positive > responses are encouraged. If there are no objections by Thursday, > January 24, this resolution will carry. I have very mixed feelings about this one. I've been trying to come up with a clear response for a few days, but my position seems to waver between objectin... On Thu, 2010-01-07 at 22:12 -0800, Maciej Stachowiak wrote: > Silence will be taken to mean there is no objection, but positive > responses are encouraged. If there are no objections by Thursday, > January 24, this resolution will carry. I have very mixed feelings about this one. I've been trying to come up with a clear response for a few days, but my position seems to waver between objecting and offering my services to co-edit such a draft, and everywhere in between. On one hand, I don't think Microdata (as-is) is very good. On the other hand, with a bit more work, I do think it has the potential to become a useful format. In an ideal world, I'd like to see RDFa take some ideas from Microdata (I'm not going to go into specifics in this message) and the need for the latter to evaporate. In which case putting Microdata on the Recommendation track at this stage might lead to author confusion further down the line if the W3C endorses two competing standards for embedding data in (X)HTML. My suggestion is that Microdata should be allowed to evolve as an editors' draft until we can see the direction RDFa 1.1 is headed. There doesn't seem to be any pressing need to publish Microdata as a WD right now; there seems to be no harm in delaying. I'd also suggest that Microdata be worked on not in isolation by the HTML Working Group, but by a joint task force formally involving, say, the Semantic Web Interest Group, and with a liason to the RDFa Working Group, assuming such a group will exist. So as I said, I do want to support progression with Microdata, and hope that I can contribute positively to its development, but I'm not sure the time is right to publish as a FPWD. This is not however a formal objection. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263324223.22239.49.camel%40ophelia2.g5n.co.uk Re: RDFa Vocabularies 2010-01-12T19:23:47 2010-01-12T19:23:47 2010-01-12T19:23:47 On Mon, 2010-01-11 at 23:01 -0500, Manu Sporny wrote: > http://rdfa.digitalbazaar.com/specs/rdfa-vocab-20100111.html I'd like to outline an alternative solution. This is mostly based on ideas I've seen on this list - Mark and Ben's ideas mainly IIRC, though I could be misattributing them. 1. Introduce a new scoped attribute @default-prefix. Actually you'd probably want a shorter name, but I'll ... On Mon, 2010-01-11 at 23:01 -0500, Manu Sporny wrote: > http://rdfa.digitalbazaar.com/specs/rdfa-vocab-20100111.html I'd like to outline an alternative solution. This is mostly based on ideas I've seen on this list - Mark and Ben's ideas mainly IIRC, though I could be misattributing them. 1. Introduce a new scoped attribute @default-prefix. Actually you'd probably want a shorter name, but I'll stick with this now as it's pretty clear what it does. This would set the default prefix for CURIEs that contain no colon. (The keywords found in @rel and @rev are not CURIEs, so it does not affect those.) So for example: <address about="" default-prefix="http://xmlns.com/foaf/0.1/" rev="made"> <a typeof="Person" rel="homepage" href="http://tobyinkster.co.uk/" property="name">Toby Inkster</a> </address> 2. Permit but do not require RDFa processors to perform a limited subset of OWL reasoning on the document, taking into account data from the document obtained by dereferencing the default-prefix. Assuming that <doc> is the document graph and <dp> is the default prefix graph, the suggested reasoning to be carried out can be summed up in SPARQL as: CONSTRUCT { ?subject ?property ?object . } WHERE { GRAPH <dp> { ?localalias owl:equivalentProperty ?property . } GRAPH <doc> { ?subject ?localalias ?object . } } CONSTRUCT { ?subject a ?class . } WHERE { GRAPH <dp> { ?localalias owl:equivalentClass ?class . } GRAPH <doc> { ?subject a ?localalias . } } This covers the use case of people wanting to use vocabs that combine terms from multiple established vocabularies. They'd simply create their own mix-and-match vocab using a couple of fairly basic OWL terms to note equivalences to established ones, and then set that vocab as the default prefix (perhaps on the root <html> element). By making the reasoning optional, triples (albeit perhaps less useful ones) can still be obtained from the document in the case when default-prefix is not dereferencable (be that because the processor is running inside a sandboxed environment, or it's running offline, or the domain name used in the default prefix has lapsed) or cannot be parsed. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263365037.9072.6.camel%40ophelia2.g5n.co.uk Re: text/sandboxed-html 2010-01-13T06:44:01 2010-01-13T06:44:01 2010-01-13T06:44:01 On Wed, 2010-01-13 at 10:18 +0800, sird@rckc.at wrote: > why not putting the sandboxed URL inside the sandbox attribute? > anyway, it's just a suggestion, the new mime type is a great idea, now > sandbox makes sense! > > <iframe sandbox="http://thesite.com/thesandboxed.html" > sandboxsomething="no-scripts no-frames"> Using a new attribute rather than src seems like a sensible idea to me. Legacy ... On Wed, 2010-01-13 at 10:18 +0800, sird@rckc.at wrote: > why not putting the sandboxed URL inside the sandbox attribute? > anyway, it's just a suggestion, the new mime type is a great idea, now > sandbox makes sense! > > <iframe sandbox="http://thesite.com/thesandboxed.html" > sandboxsomething="no-scripts no-frames"> Using a new attribute rather than src seems like a sensible idea to me. Legacy user agents won't load anything from: <iframe sandbox="http://example.com/sandboxed.html"></iframe> And won't pop up annoying dialogue boxes. It seems to eliminate the need for an additional media type registration; and it makes things simpler for those HTML publishers who are not au fait with configuring their web servers. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/9fee1c5b5eb40c32d85a401270c219c8.squirrel%40goddamn.co.uk Re: @lang and @xml:lang in XHTML+RDFa 1.1 2010-01-13T14:19:18 2010-01-13T14:19:18 2010-01-13T14:19:18 > <html lang="ja" xml:lang="ja"> > ... > <p xmlns:dc="http://purl.org/dc/terms/"> > Updated: <span property="dc:modified">2010-01-13</span>... > </p> > > which generates weird triple: > > <> dc:modified "2010-01-13"@ja . It is a weird triple, but the XHTML itself is at fault -- the RDF generated suffers as a consequence. Note that the word "Updated", which is an English, but not as far as I know... > <html lang="ja" xml:lang="ja"> > ... > <p xmlns:dc="http://purl.org/dc/terms/"> > Updated: <span property="dc:modified">2010-01-13</span>... > </p> > > which generates weird triple: > > <> dc:modified "2010-01-13"@ja . It is a weird triple, but the XHTML itself is at fault -- the RDF generated suffers as a consequence. Note that the word "Updated", which is an English, but not as far as I know, a Japanese word, is tagged as being in Japanese too and will be interpreted as such by all implementations of the xml:lang attribute -- not just RDFa processors. This is an annoyance of language tagging in XHTML generally, and I don't think it's RDFa's job to fix it. RDFa should simply use XHTML's built-in mechanism for declaring languages (mo matter how annoying it may be to use correctly) rather that trying to invent its own rules. One minor tweak that *might* aleviate some of the pain in authoring documents that include multiples languages and/or a mixture of linguistic and non-linguistic content would be to ask RDFa processors to implement special handling for a few ISO-639-2 codes. Here's my suggestions: 1. "mul" is the code for "multiple languages". This would generate a literal tagged with language @mul as you'd expect, however it would be treated as the same as xml:lang="" in terms of inheroting the language to descendent elements. Example: <div xml:lang="mul" property="ex:test1" content="Foo"> <span property="ex:test2">Bar</span> <span property="ex:test3" xml:lang="en">Baz</span> </div> would generate: <> ex:test1 "Foo"@mul . <> ex:test2 "Bar" . <> ex:test3 "Baz"@en . This would allow authors to markup the fact that an area of the page contains multiple languages, and that RDFa processors should not try to interpret the language of descendent elements without further prompts. 2. "zxx" is the code for non-linguistic content. Processors could recognise xml:lang="zxx" as being equivalent to xml:lang="". -Toby http://tobyinkster.co.uk/message/1263479403.29455.2.camel%40ophelia2.g5n.co.uk Re: Requirements for a possible "RDF 2.0" 2010-01-14T14:30:05 2010-01-14T14:30:05 2010-01-14T14:30:05 On Wed, 2010-01-13 at 11:00 -0500, Chris Welty wrote: > I suppose we don't really need to discuss whether we should > investigate an "RDF 2.0", but rather what kinds of requirements > various RDF users have that they would like to be considered (I'd like > this thread to be less "+1" and "-1" messages, and more "I'd like to > see RDF support x...") Adopt SPARQL's data model for all future Semant... On Wed, 2010-01-13 at 11:00 -0500, Chris Welty wrote: > I suppose we don't really need to discuss whether we should > investigate an "RDF 2.0", but rather what kinds of requirements > various RDF users have that they would like to be considered (I'd like > this thread to be less "+1" and "-1" messages, and more "I'd like to > see RDF support x...") Adopt SPARQL's data model for all future Semantic Web standards -- for all SW protocols and serialisations. The major differences between SPARQL's data model and RDF are: * Explicit support for named graphs * Literal subjects * Blank node predicates (Though it might be a good idea to phase out blank nodes.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263494788.29455.4.camel%40ophelia2.g5n.co.uk Re: Updated RDFa Syntax 1.1 draft uploaded 2010-01-14T18:46:29 2010-01-14T18:46:29 2010-01-14T18:46:29 On Thu, 2010-01-14 at 09:44 -0600, Shane McCarron wrote: > This specification also adds the |lang| attribute to the I18N > attribute > collection as defined in [XHTMLMOD > <http://www.w3.org/MarkUp/2010/ED-rdfa-syntax-20100113/references.html#ref_xhtml_modularization>]. > The |lang| attribute is defined in [HTML4 > <http://www.w3.org/MarkUp/2010/ED-rdfa-syntax-20100113/references.html#ref_html... On Thu, 2010-01-14 at 09:44 -0600, Shane McCarron wrote: > This specification also adds the |lang| attribute to the I18N > attribute > collection as defined in [XHTMLMOD > <http://www.w3.org/MarkUp/2010/ED-rdfa-syntax-20100113/references.html#ref_xhtml_modularization>]. > The |lang| attribute is defined in [HTML4 > <http://www.w3.org/MarkUp/2010/ED-rdfa-syntax-20100113/references.html#ref_html4>]. > When this attribute and the |xml:lang| attribute are specified on the > same element, the |xml:lang| attribute takes precedence. When both > |lang| and |xml:lang| are specified on the same element, they SHOULD > have the same value. That's more or less the same as HTML5's lang/xml:lang handling except that IIRC HTML5 stipulates that attributes with invalid language codes must be treated as if they were absent. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263511821.18556.5.camel%40ophelia2.g5n.co.uk Decentralised extensibility idea (ISSUE-41) 2010-01-14T23:30:23 2010-01-14T23:30:23 2010-01-14T23:30:23 This is a sketch of a proposal for decentralised extensibility (DE) in HTML5. If there is interest in it, I'll be happy to write it up as a change proposal, but I'd like to see what people think first. ---- So, what's the point of DE? Essentially different people are publishing HTML documents about different things. Some people might really want a <car/> element in HTML: <car engine-size="1.8L... This is a sketch of a proposal for decentralised extensibility (DE) in HTML5. If there is interest in it, I'll be happy to write it up as a change proposal, but I'd like to see what people think first. ---- So, what's the point of DE? Essentially different people are publishing HTML documents about different things. Some people might really want a <car/> element in HTML: <car engine-size="1.8L" colour="blue">Toyota</car> (I don't drive, so this example picks up pretty much everything I know about cars - they have engines, colours and manufacturers. But if anyone wants to buy me one for writing this proposal, I'll have a silver Morgan Aero 8 thanks.) This might be really useful for them, being able to style the <car/> element differently, and perhaps have a script apply a special behaviour on mouseover. The trouble is that this is too esoteric to add to HTML. If we added that then we'd have to add <cake/> and any other (excuse the pun) half-baked idea people had. DE allows third-parties to create specifications (which I'll assign the jargon term "otherspecs") based on HTML5 introducing specialised elements and attributes. So far the discussion on DE has mostly revolved on porting XML's DE mechanism to HTML. This idea however creates a new, more HTML-ish DE mechanism based on stuff that mostly already exists. Firstly, how does my proposal allow otherspecs to create their own special elements? One of the weaknesses with the XML namespace approach applied to HTML is that if a user-agent comes across: <foo:bar foo:baz="..." /> in a document, if it doesn't have specific knowledge of the otherspec, it will have no idea how to handle it. In the case of browsers, which are a major class of user agents, they will have no idea how to display it by default (e.g. is it inline or block?). My solution forces otherspecs to subclass existing HTML elements instead. They do this using the existing class attribute. So, for example, one might have: <span class="Car">Mazda</span> The class attribute has traditionally been used mostly by authors for their own purposes. That doesn't need to conflict with this solution, as I will later indicate a mechanism for documents to specify which otherspec(s) they are making use of. So, how should one add custom attributes to otherspecs. We repurpose the data-* attributes: <span class="Car" data-engine-size="1.8L" data-colour="blue">Mazda</span> Currently the data-* attributes are reserved entirely for the author's private use. In this proposal, the definition of those attributes would be changed to allow otherspecs to assign particular meaning to data-* attributes, but only in the case where document authors have explicitly indicated which otherspec(s) they're making use of. This proposal also allows otherspecs to mint their own meta names and link rel types. Lastly, the mechanism for documents to indicate which otherspecs they're using: <head profile="http://example.com/CarML/html5"> The profile attribute would be allowed on any HTML element and would apply to all descendant elements. As a special case, a profile on <head/> would apply to the whole document. So, my original XML-style <car/> element could be written as: <span profile="http://example.com/CarML/html5" class="Car" data-engine-size="1.8L" data-colour="blue">Mazda</span> So in summary, we should be able to achieve DE by reintroducing @profile, as a scoped attribute allowed on any element, and giving the profile mechanism "jurisdiction" to assign non-local meaning to class names, link relationships, meta names and data-* attributes. I'm not proposing this method to replace the current extensibility method of becoming an "applicable specification", but as an additional extensibility point with perhaps a lower barrier to entry. An optional extra would be a DOM method getElementsByClassNameWithProfile(classname, profileuri) which return a collection of elements matching the provided class, but only if they were within the scope of a particular profile URI. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263512232.18556.10.camel%40ophelia2.g5n.co.uk Re: hidden versus discoverable meta-data 2010-01-14T23:37:13 2010-01-14T23:37:13 2010-01-14T23:37:13 On Thu, 2010-01-14 at 20:06 +0000, Tantek Celik wrote: > Even TimBL is now advocating RDFa now, not RDF Perhaps being pernickety, but that's like saying that somebody is advocating using PNGs instead of pictures. PNGs are pictures; and RDFa is RDF. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2010-01-14 at 20:06 +0000, Tantek Celik wrote: > Even TimBL is now advocating RDFa now, not RDF Perhaps being pernickety, but that's like saying that somebody is advocating using PNGs instead of pictures. PNGs are pictures; and RDFa is RDF. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263513733.18556.15.camel%40ophelia2.g5n.co.uk Re: Avoid setting href as new subject when no rel/rev is present 2010-01-15T00:02:16 2010-01-15T00:02:16 2010-01-15T00:02:16 On Thu, 2010-01-14 at 13:21 -0500, Stephane Corlosquet wrote: > I just wanted to check and make sure there is not problem in using the > empty rel hack, or whether there is a better way of working around > this? Yes - it's an odd case. I find it an unintuitive behaviour, though I can imagine plenty of arguments in its favour. Other workarounds: 1. Include an explicit @about on the <a> tag. 2. ... On Thu, 2010-01-14 at 13:21 -0500, Stephane Corlosquet wrote: > I just wanted to check and make sure there is not problem in using the > empty rel hack, or whether there is a better way of working around > this? Yes - it's an odd case. I find it an unintuitive behaviour, though I can imagine plenty of arguments in its favour. Other workarounds: 1. Include an explicit @about on the <a> tag. 2. Put something useful into rel, such as sioc:has_discussion. 3. Move the @content and @property to the containing <li> element. Is there an RDFa test suite case covering this construct? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263558119.18556.48.camel%40ophelia2.g5n.co.uk Re: Requirements for a possible "RDF 2.0" 2010-01-15T12:22:01 2010-01-15T12:22:01 2010-01-15T12:22:01 On Fri, 2010-01-15 at 11:57 +0100, Danny Ayers wrote: > Aside from a little tidiness, what would we actually gain through > going the whole hog on what can go in which position in the triple? > > blank node predicate - what does that tell you that an rdfs:seeAlso > wouldn't? <#school> [ rdfs:subPropertyOf ex:teacher ; rdfs:label "maths teacher" ; ex:relatedTopic dbpedia:Mathematic... On Fri, 2010-01-15 at 11:57 +0100, Danny Ayers wrote: > Aside from a little tidiness, what would we actually gain through > going the whole hog on what can go in which position in the triple? > > blank node predicate - what does that tell you that an rdfs:seeAlso > wouldn't? <#school> [ rdfs:subPropertyOf ex:teacher ; rdfs:label "maths teacher" ; ex:relatedTopic dbpedia:Mathematics ] <#joe> . <#band> [ rdfs:subPropertyOf foaf:member ; ex:relatedInstrument <#bongo> ] <#jim> . These structures are of course already permissible in RDF, but only if you're willing to commit to giving the property a URI. > literal subject - aside from quotations: > > "I can't really see how it would be useful" <x:saidBy> <#me> . If the above was the only use case, then it would not be especially useful - you'd simply create a x:didSay predicate that worked in the reverse direction. With blank node predicates that's even easier: <#me> [ owl:inverseOf x:saidBy ] "I can't really see how it would be useful" . But that's not the only use case. Consider relationships between two literals: "Toby Inkster" foaf:sha1 "4296ab2b2243bdb1e3cd1952158d2ce5464ea10c" . I can imagine wanting to do things like: SELECT ?person ?hash WHERE { ?person ex:password ?pwd . ?pwd foaf:sha1 ?hash . FILTER (?hash = "672059bd1419f8b90633fc2d02529be0de2fa614") } Both blank node predicates and literal subjects are already allowed by N3 and are theoretically allowed by SPARQL (though I don't know of any implementations that choose to support them). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263572023.18556.228.camel%40ophelia2.g5n.co.uk Re: Decentralised extensibility idea (ISSUE-41) 2010-01-15T16:13:44 2010-01-15T16:13:44 2010-01-15T16:13:44 Several replies in one... ---- Leif Halvard Silli wrote: > So how would you indicate where the rel value comes from? Like > this: <link profile="URI" rel="value" href="somewhere" > You can't indicate where the rel value comes from -- nor where classes and data-* attributes come from. Consider the HTML+RDFa and Microdata specifications. These are extensions to HTML. If a parser understands, sa... Several replies in one... ---- Leif Halvard Silli wrote: > So how would you indicate where the rel value comes from? Like > this: <link profile="URI" rel="value" href="somewhere" > You can't indicate where the rel value comes from -- nor where classes and data-* attributes come from. Consider the HTML+RDFa and Microdata specifications. These are extensions to HTML. If a parser understands, say, Microdata, then when it comes across @itemprop it knows that the Microdata specification defines that attribute. If the parser does not understand Microdata, it doesn't know where that attribute comes from, so will not do anything in particular with it. In general, the solution is not designed to provide "backtracing" - finding out which otherspec something came from, but instead just allows user agents that support an otherspec to know which pages (or parts of pages) use the otherspec. > Indeed a special case. But how would <html profile="URI"> and <head > profile="URI"> differ? Remember, also, that HTML5, unlike HTML4, allows > @class and @id even on <html>, <head> and <title> - even on <meta>. It is perhaps an annoyance for people who want to apply a profile just to <head>. > But thanks to HTML5's freedom w.r.t. where @id/@class might appear, > then a perhaps more - as you said - "HTML-ish" (not to say > "Twitter-ish") option would be this: > > <head > > <link id=CarML rel=profile href=http://example.com/CarML/html5 > > </head> > <span profile="#CarML" class="Car">Mazda</span> I don't think adding an extra level of indirection would be especially helpful. If it's supposed to prevent repetition, then perhaps my original message wasn't clear enough. <html profile="http://example.com/CarML/html5"> would automatically license class="Car" and associated data-* attributes to have their CarML meaning everywhere in the document. So repetition of the profile is rarely needed. > Note that if a <link> points to a DE profile, then it will not have any > descendant elements - so linking to it like this, seems fitting. :-) > Also note that @profile - at least <head@profile> - can link to several > URIs, so <link@rel="profile"> seems better than @profile for that > reason, for this idea. It's certainly my intention that @profile would continue to contain a space-separated list. > And so, to apply two DE profiles simultaneously, then perhaps this: ? > > <head > > <link id=CarML rel=profile href=http://example.com/CarML/html5 > > <link id=MyML rel=profile href="http://example.com/MyML/html5 > > </head> > <span profile="#CarML #MyML" class="Car" >Mazda</span> > > I think - when necessary - to separate "Car" from CarML and "Car" from > MyML, there should be some prefix option. I don't know, but perhaps > simply like this: ? > > <div class="Japanese" profile="#CarML" > > <div class="Favorite" profile="#MyML" > > <span class="Car#CarmML" data-colour="blue#MyML" >Mazda</span> > </div></div> > > Or do you see another option? There are three situations you could be in when attempting to mix otherspecs: 1. One otherspec defines class="Car" and the second otherspec doesn't define any meaning for class="Car" at all. In this case, user agents implementing the first otherspec will understand it and user agents implementing the second will ignore it. No problem. 2. Both otherspecs define class="Car" in such a way that (for your own use case at least) they are equivalent. In which case: <html profile="http://example.com/CarML/html5 http://example.com/MyML/html5"> ... <span class="Car">Mazda</span> ... </html> Should just work in both otherspecs. No problem. 3. Both otherspecs define class="Car", but with conflicting interpretations. In this case, it is impossible to apply both otherspecs to the same HTML node. This does cause a problem: scoping the profile attribute can usually help here, but at other times, you'll just have to drop compliance with one of the otherspecs. ---- Philip Jägenstedt wrote: > Overloading the class attribute (like microformats) isn't a very > good idea, it *will* clash with existing markup. The proposal is in fact a superset of the mechanisms microformats already use. I agree that microformats do clash with existing class names. This is a problem. The profile mechanism aims at avoiding clashes. Officially speaking, microformats use profiles, but in the wild, they don't. This is because the profile attribute in HTML 4.x is problematic: there is confusion as to whether it takes a single URI or multiple URIs; and it being stuck in the <head> can make it difficult to use in CMSes and various other tools. By freeing the profile attribute from the head and allowing it to be specified closer to where the markup is actually used, it becomes more copy-and-pastable. > I don't think this is a very good idea, as data-* are always hidden > and not suitable for marking up content that is visible in the page. You are mistaking my proposal for a method of embedding data into a document. The proposal is not intended for embedding the kind of data that Microdata or RDFa embed; rather it's a general purpose extension point that other standards ("otherspecs") could use. Which other standards? It could be used as an alternative to namespaces, as the recommended way method of embedding things like SVG or MathML into HTML, were it not for the fact that using namespaces for this is quite solidly established. As far as I know, neither Microdata nor RDFa has positioned itself as a way of doing this. Here are some use cases, where currently XML-style namespaces, or proprietary extensions to HTML might be used, that might instead be solved using my proposal: * a WYSIWYG editor wishes to use a special attribute to note that certain parts of a document should be skipped by the spell check function. Rather than adding a proprietary attribute or using namespaces, they'd just add something like data-spellcheck="skip" to those elements, with a profile attribute allowing that particular data-* attribute to have a globally-defined meaning. * A phone company introduces a revolutionary new multi-head browser, designed for use on dual-screen phones. Pages are generally viewed on the primary screen, but the documents can specify certain sections which are intended for the second screen. Rather than introduce a proprietary element, they suggest a class+profile combination to indicate which element(s) go on the second screen. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263750726.18556.236.camel%40ophelia2.g5n.co.uk Re: Decentralised extensibility idea (ISSUE-41) 2010-01-17T17:52:09 2010-01-17T17:52:09 2010-01-17T17:52:09 On Sun, 2010-01-17 at 09:39 -0800, Tab Atkins Jr. wrote: > I'm making a stronger point than that, though. Even in the presence > of just a single extension, you are unable to extract the data unless > you specifically know the extension being used. You require vocab > knowledge just to disambiguate it from HTML itself. Indeed. Extraction of data by generic agents is not intended to be a use ca... On Sun, 2010-01-17 at 09:39 -0800, Tab Atkins Jr. wrote: > I'm making a stronger point than that, though. Even in the presence > of just a single extension, you are unable to extract the data unless > you specifically know the extension being used. You require vocab > knowledge just to disambiguate it from HTML itself. Indeed. Extraction of data by generic agents is not intended to be a use case the proposal satisfies. If you consider this to be a problem, note that this problem also applies to the existing method of extensibility suggested by the HTML5 draft (i.e. extensibility by becoming an "applicable specification"). The advantage that my DE proposal has over "applicable specification extensibility" are: scoped URI-based opt-in; and well-established fallback parsing, behaviour and rendering. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263757649.18556.263.camel%40ophelia2.g5n.co.uk Re: The harm that can come if the W3C supports publication of competing specs 2010-01-17T19:47:34 2010-01-17T19:47:34 2010-01-17T19:47:34 On Sun, 2010-01-17 at 13:25 +0100, Philip Jägenstedt wrote: > I agree that browsers will be minority consumers of microdata, but also > feel that by having a model that is possible to write good DOM APIs for > which are possible (desirable rather) to implement in browsers, the > metadata becomes much more useful (likely to be used) by others than the > traditional semantic web community. S... On Sun, 2010-01-17 at 13:25 +0100, Philip Jägenstedt wrote: > I agree that browsers will be minority consumers of microdata, but also > feel that by having a model that is possible to write good DOM APIs for > which are possible (desirable rather) to implement in browsers, the > metadata becomes much more useful (likely to be used) by others than the > traditional semantic web community. Since the RDF model is a graph, it is > hard to see how it could be represented using HTMLCollection-like > interfaces (you would need a query language for it to be useful) or mapped > to JavaScript (you can construct the objects with some effort, but can't > serialize them as JSON if the graph has loops). The RDF/JSON spec <http://n2.talis.com/wiki/RDF_JSON_Specification> (non-W3C, draft, but quite stable) provides a serialisation of RDF as JSON. It is capable of serialising arbitrary RDF graphs with (as far as I'm aware) no exceptions. It's not an especially pretty format -- intended for ease of serialisation and parsing rather than human readability -- but it shows that RDF can be serialised to JSON completely. It's also worth noting rdfquery <http://code.google.com/p/rdfquery>, an extension to jQuery which provides an in-browser Javascript API for RDFa data -- albeit one that's implemented by a script rather than internally by the browser itself. So RDFa APIs are certainly feasible, and I believe the people planning the RDFa Working Group plan on standardising such an API. > > The mediawiki thread cited by Shelley notes that there is some ambiguity > > in the semantics of the microdata presentation, but that's relatively > > easily fixed, I think (just ensure the unqualified properties are mapped > > implicitly to a full URI, which in turn is described by an RDF schema or > > OWL). > > If itemtype is not used, then the data has no semantics outside of the > page, and using it is as unsafe as e.g. scraping HTML tables. The RDF > extraction algorithm doesn't include untyped items, as it shouldn't. I > wouldn't really call this ambiguity, but possibly the spec could be more > explicit about this. In the extreme one could even require itemtype to be > used, but I think that would harm useful site-private use of microdata. IIRC, the following has a mapping to RDF: <div item> <span itemprop="http://purl.org/dc/terms/title">Foo</span> </div> > I would agree, RDF is a well established model and there's nothing much > wrong with it. Presently, the only RDF concept I'm aware of that can't be > expressed using microdata is XML Schema Datatypes (XSD). I would argue > that the datatypes should defined in the vocabulary and not by the author, > so I consider this restriction quite sensible. Cyclical references amongst blank nodes cannot be represented in Microdata. In Turtle an example might be: @prefix foaf: <http://xmlns.com/foaf/0.1/> . _:bob foaf:knows _:jon . _:jon foaf:knows _:bob . In RDFa it can be expressed quite simply: <p xmlns:knows="http://xmlns.com/foaf/0.1/knows" about="_:jon" rel="knows:" rev="knows:" resource="_:bob"> Jon and Bob know each other. </p> To express the same semantics in Microdata would require assigning a URI to at least one of the people. Certainly it's possible for a script to assign a URI on the fly, but committing to maintaining the meaning of that URI long-term is harder, which is why blank nodes are so frequently used in RDF. I believe, this could be addressed by allowing @itemid to contain a blank node name, and providing a way for @itemprop to specify a blank node as its value. > This only seems to matter > if you're trying to embed RDF data verbatim which you have no control > over, in which case I would argue that you shouldn't bother with either > microdata or RDFa and simply link to an external N3/Turtle representation. > However, if a use case other than "express arbitrary RDF" requires XSD, it > certainly wouldn't be too late to add it to microdata as itemproptype or > something. (I would be interested in hearing about such use cases.) Sorting is a use case for datatypes, albeit not an especially important one. Sorting as strings, "100" comes before "99"; as numbers, 99 before 100. Sorting as strings, "2010-01-17T19:46:00+0000" comes before "2010-01-17T19:46:01+0100"; sorting as datetimes, they're the other way around. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263856740.18556.286.camel%40ophelia2.g5n.co.uk DataRSS parser [Fwd: ANN: RDF::RDFa::Parser 0.30 and XML::Atom::OWL 0.01] 2010-01-18T23:19:01 2010-01-18T23:19:01 2010-01-18T23:19:01 The RDF::RDFa::Parser Perl RDFa parser now supports DataRSS (i.e. RDFa in Atom). -------- Forwarded Message -------- From: Toby Inkster <mail@tobyinkster.co.uk> To: dev@lists.perlrdf.org Subject: ANN: RDF::RDFa::Parser 0.30 and XML::Atom::OWL 0.01 Date: Mon, 18 Jan 2010 23:06:06 +0000 There are three major improvements in RDF::RDFa::Parser 0.30: 1. It installs the XHTML+RDFa DTD and associated ... The RDF::RDFa::Parser Perl RDFa parser now supports DataRSS (i.e. RDFa in Atom). -------- Forwarded Message -------- From: Toby Inkster <mail@tobyinkster.co.uk> To: dev@lists.perlrdf.org Subject: ANN: RDF::RDFa::Parser 0.30 and XML::Atom::OWL 0.01 Date: Mon, 18 Jan 2010 23:06:06 +0000 There are three major improvements in RDF::RDFa::Parser 0.30: 1. It installs the XHTML+RDFa DTD and associated modules on your filesystem (probably in a directory named something like "/usr/lib/perl5/site_perl/5.10.1/auto/share/dist/RDF-RDFa-Parser/"). This allows libxml to parse XHTML+RDFa files much more quickly. 2. It has a better callback system. In particular, Gregory Williams will be interested in the callback event called "ontriple". Hooking a function onto that allows it to be passed an RDF::Trine::Statement object as soon as it's parsed. Something similar was previously possible, but the callback function would only be passed strings - not a fully-ready statement. 3. It supports RDFa found in Atom feeds. It does some special magic to allow <feed> and <entry> elements to automatically set a new subject for triples. XML::Atom::OWL is a brand new module that parses Atom feeds into RDF::Trine models using Henry Story's AtomOWL vocabulary. RDF::RDFa::Parser (if called with the 'atom_parser' option enabled) will delegate Atom parsing to XML::Atom::OWL, allowing you to create a combined graph of Atom+RDFa documents. Atom+RDFa has been marketed by Yahoo under the name "DataRSS" and is potentially a very nice format. Lastly, RDF::RDFa::Parser::Redland 0.30 has been released, catching it up with changes in the underlying RDF::RDFa::Parser. All have been uploaded and should appear on CPAN mirrors soon. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263927850.18556.623.camel%40ophelia2.g5n.co.uk Re: RDF, XML, XSLT: Grit 2010-01-19T19:04:13 2010-01-19T19:04:13 2010-01-19T19:04:13 On Mon, 2010-01-18 at 23:32 +0100, Christoph LANGE wrote: > … of that kind: I have successfully done some XSLT processing with > RXR (http://wiki.oasis-open.org/office/RXR, > http://www.dajobe.org/papers/xmleurope2004/). I found it very nice > for XSLT processing, as there is exactly one way for writing down > things. You may be interested in the RXR output plugin I wrote for ARC2 a few months ago: http://goddamn.co.uk/viewvc/demiblog-new/arc-patching/plugins/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2010-01-18 at 23:32 +0100, Christoph LANGE wrote: > … of that kind: I have successfully done some XSLT processing with > RXR (http://wiki.oasis-open.org/office/RXR, > http://www.dajobe.org/papers/xmleurope2004/). I found it very nice > for XSLT processing, as there is exactly one way for writing down > things. You may be interested in the RXR output plugin I wrote for ARC2 a few months ago: http://goddamn.co.uk/viewvc/demiblog-new/arc-patching/plugins/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1263969442.18556.1304.camel%40ophelia2.g5n.co.uk Re: Requirements for a possible "RDF 2.0" 2010-01-20T06:37:24 2010-01-20T06:37:24 2010-01-20T06:37:24 On Fri, 2010-01-15 at 22:06 +0000, Steve Harris wrote: > There is a cost to opening up what can go where in triples. My SPARQL > engines (and I expect those of others) use this as a source of > optimisations. E.g. if some variable appears in the predicate slot, > then you know it can only bind to a URI, and you can limit your search > space. I seem to remember that in Virtuoso TP1, the follo... On Fri, 2010-01-15 at 22:06 +0000, Steve Harris wrote: > There is a cost to opening up what can go where in triples. My SPARQL > engines (and I expect those of others) use this as a source of > optimisations. E.g. if some variable appears in the predicate slot, > then you know it can only bind to a URI, and you can limit your search > space. I seem to remember that in Virtuoso TP1, the following query: SELECT * WHERE { ?s ?p ?o . OPTIONAL { ?o ?q ?v . } } "optimised" things by making the assumption that ?o was not a literal. :-( -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/346f6d1726c3ba6f6b5639ce48d03792.squirrel%40goddamn.co.uk Re: Telecon Agenda - 28th January 2010, 1600 UTC 2010-01-27T17:12:21 2010-01-27T17:12:21 2010-01-27T17:12:21 > * Mapping Microdata terms to RDFa processing rules Copied and pasted from my scratchpad (as I was/am looking at producing an HTML+Microdata to XHTML+RDFa convertion tool)... """ <a itemprop="foo" href="bar"> to <a rel="foo" href="bar"> <img itemprop="foo" src="bar"> to <img rel="foo" src="bar" about="subject" resource="bar"> <span itemprop="foo">Bar</span> to <span property="foo" datatyp... > * Mapping Microdata terms to RDFa processing rules Copied and pasted from my scratchpad (as I was/am looking at producing an HTML+Microdata to XHTML+RDFa convertion tool)... """ <a itemprop="foo" href="bar"> to <a rel="foo" href="bar"> <img itemprop="foo" src="bar"> to <img rel="foo" src="bar" about="subject" resource="bar"> <span itemprop="foo">Bar</span> to <span property="foo" datatype="">Bar</span> <div itemscope="" itemid="foo" itemtype="bar"> to <div about="foo" typeof="bar"> <div itemscope="" itemtype="bar"> to <div typeof="bar"> <div itemscope="" itemid="foo"> to <div about="foo"> <div itemscope=""> to <div about="_:auto01"> <div itemprop="foo" itemscope=""> to <div rel="foo" resource="_:auto02"> <div itemprop="foo" itemscope="" itemtype="bar"> to <div rel="foo" resource="_:auto02"><span rel="rdf:type" resource="bar"></span> <div itemprop="foo" itemscope="" itemid="baz"> to <div rel="foo" resource="baz"> <div itemprop="foo" itemscope="" itemtype="bar" itemid="baz"> to <div rel="foo" resource="baz"><span rel="rdf:type" resource="bar"></span> @itemref will require thought. """ -Toby http://tobyinkster.co.uk/message/1d2e550365bc3389ab92e90a8194f0a3.squirrel%40goddamn.co.uk Re: Telecon Agenda - 28th January 2010, 1600 UTC 2010-01-27T17:13:03 2010-01-27T17:13:03 2010-01-27T17:13:03 > * Mapping Microdata terms to RDFa processing rules Copied and pasted from my scratchpad (as I was/am looking at producing an HTML+Microdata to XHTML+RDFa convertion tool)... """ <a itemprop="foo" href="bar"> to <a rel="foo" href="bar"> <img itemprop="foo" src="bar"> to <img rel="foo" src="bar" about="subject" resource="bar"> <span itemprop="foo">Bar</span> to <span property="foo" datatyp... > * Mapping Microdata terms to RDFa processing rules Copied and pasted from my scratchpad (as I was/am looking at producing an HTML+Microdata to XHTML+RDFa convertion tool)... """ <a itemprop="foo" href="bar"> to <a rel="foo" href="bar"> <img itemprop="foo" src="bar"> to <img rel="foo" src="bar" about="subject" resource="bar"> <span itemprop="foo">Bar</span> to <span property="foo" datatype="">Bar</span> <div itemscope="" itemid="foo" itemtype="bar"> to <div about="foo" typeof="bar"> <div itemscope="" itemtype="bar"> to <div typeof="bar"> <div itemscope="" itemid="foo"> to <div about="foo"> <div itemscope=""> to <div about="_:auto01"> <div itemprop="foo" itemscope=""> to <div rel="foo" resource="_:auto02"> <div itemprop="foo" itemscope="" itemtype="bar"> to <div rel="foo" resource="_:auto02"><span rel="rdf:type" resource="bar"></span> <div itemprop="foo" itemscope="" itemid="baz"> to <div rel="foo" resource="baz"> <div itemprop="foo" itemscope="" itemtype="bar" itemid="baz"> to <div rel="foo" resource="baz"><span rel="rdf:type" resource="bar"></span> @itemref will require thought. """ -Toby http://tobyinkster.co.uk/message/1264785881.14352.18.camel%40ophelia2.g5n.co.uk Re: Telecon Agenda - 28th January 2010, 1600 UTC 2010-01-29T17:24:45 2010-01-29T17:24:45 2010-01-29T17:24:45 On Wed, 2010-01-27 at 17:13 +0000, Toby Inkster wrote: > Copied and pasted from my scratchpad (as I was/am looking at producing > an HTML+Microdata to XHTML+RDFa convertion tool)... This code manages to do a pretty complete mapping from Microdata to RDFa without changing the page layout (it needs to add additional empty <span> elements occasionally): http://goddamn.co.uk/viewvc/perlmods/HTML-HT... On Wed, 2010-01-27 at 17:13 +0000, Toby Inkster wrote: > Copied and pasted from my scratchpad (as I was/am looking at producing > an HTML+Microdata to XHTML+RDFa convertion tool)... This code manages to do a pretty complete mapping from Microdata to RDFa without changing the page layout (it needs to add additional empty <span> elements occasionally): http://goddamn.co.uk/viewvc/perlmods/HTML-HTML5-Microdata-ToRDFa/lib/HTML/HTML5/Microdata/ToRDFa.pm Limitations: - If the input page uses a mixture of Microdata and RDFa, the output will probably be broken. - It only looks at mapping Microdata's item* attributes. The Microdata spec also (or at least used to also - not looked recently) provides mappings for some other HTML attributes and elements to RDF (e.g. <meta name>; <blockquote cite>; <title>; etc), but this code ignores all that. - Where itemprop, itemscope and itemtype are all on the same element, it needs to add an extra <span> element to the output to avoid losing the rdf:type. - RDFa doesn't have a construct similar to itemref. When the converter finds an itemref it does some special magic to figure out what triples would have been generated by following the itemref attribute's references; and adds them in as extra <span> elements too. It is probably not rock solid, but seems to get the majority of cases right. I'm sure there are ways to trick it though. I've not seen any microdata "in the wild" that it fails on. Though, to be fair, I've not seen any microdata in the wild that it succeeds on either. ;-) Right now it's completely lacking in documentation, but once I've typed some docs up, I'll upload it to CPAN. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265105092.14352.59.camel%40ophelia2.g5n.co.uk Re: RDFa DOM API Editors Draft 2010-02-02T10:04:59 2010-02-02T10:04:59 2010-02-02T10:04:59 On Mon, 2010-02-01 at 00:15 -0500, Manu Sporny wrote: > http://dev.w3.org/rdfa/specs/rdfa-dom-api.html I know this is just very early thoughts, but here's a few comments: | interface Triple Doesn't contain a mechanism to differentiate between these triples: <foo> ex:test <bar> . <foo> ex:test "bar" . Perhaps a boolean attribute "is_literal"? I'm assuming that the "_:" convention would be... On Mon, 2010-02-01 at 00:15 -0500, Manu Sporny wrote: > http://dev.w3.org/rdfa/specs/rdfa-dom-api.html I know this is just very early thoughts, but here's a few comments: | interface Triple Doesn't contain a mechanism to differentiate between these triples: <foo> ex:test <bar> . <foo> ex:test "bar" . Perhaps a boolean attribute "is_literal"? I'm assuming that the "_:" convention would be used to identify blank nodes, but it is not clear whether an implementation of this API would be required to keep blank node identifiers exactly how they are given in the source RDFa or not. (RDF assigns no meaning to blank node identifiers -- they're not part of the data; just part of the serialisation. It seems unwise to rely on them being preserved by the parser.) Of course, not all blank nodes have identifiers in the source (some will be assigned during parsing due to chaining rules, etc). | children of type array of Triple, readonly | A list of triples that contain the same subject as this triple. Not sure why this attribute is called "children". If a familial relation is wanted, "siblings" seems more appropriate to me, as there's no obvious hierarchy between triples. Better would just be to have a document.getTriplesBySubject(s) method: // Instead of this_triple.children... document.getTriplesBySubject( this_triple.subject ); Even better, document.getTriplesByPattern(s, p, o): var triples = document.getTriplesByPattern( null, 'http://xmlns.com/foaf/0.1/name', 'Toby Inkster'); | getTriplesByType | To perform a match, a direct string comparison is performed. If the | string comparison fails, the given type is checked against a subject's | type starting at the last character in each string and moving | backwards. This seems odd. I can see why it might be useful to return a list of foaf:Persons when document.getTriplesByType('Person') is called; but I can see less justification in allowing document.getTriplesByType('rson') to work. Perhaps use word boundaries rather than character by character scanning? Also, what triples would be returned? Say the document contains only three triples: <> foaf:primaryTopic <#me> . <#me> a foaf:Person . <#me> foaf:name "Toby Inkster" . All of the triples contain the resource <#me> (in either subject or object position), and <#me> is a Person, so would they all be returned? Or would just the triples with <#me> as the subject be returned? Or just the single triple "<#me> a foaf:Person"? If the last of these is correct, then returning triples seems superfluous, as you already know what the predicate will be, and have a pretty good idea what the object will be. So getResourcesByType(t), returning not triples, but a list of URIs and blank node identifiers would be just as useful. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265137630.14352.69.camel%40ophelia2.g5n.co.uk Re: Hash URIs and RDFa documents 2010-02-02T19:07:14 2010-02-02T19:07:14 2010-02-02T19:07:14 On Tue, 2010-02-02 at 10:13 +0000, Mark Birbeck wrote: > I disagree with the point made in the email you refer to, from > Richard. > > Only one triple is generated in your sample, so nowhere do we have an > indication that #me is both a person and an HTML element in a > document. The graph generated from the example by an RDFa processor would not contain an indication that #me is an HTML elemen... On Tue, 2010-02-02 at 10:13 +0000, Mark Birbeck wrote: > I disagree with the point made in the email you refer to, from > Richard. > > Only one triple is generated in your sample, so nowhere do we have an > indication that #me is both a person and an HTML element in a > document. The graph generated from the example by an RDFa processor would not contain an indication that #me is an HTML element, no. However another graph, say, from a document outline generator, may contain something like: <#me> a xhtml:Div ; xhtml:textContent "yada yada" . It would be a perfectly sensible couple of triples to generate from the given example. Merging the RDFa and document outline graphs would result in a contradiction. (At least, it's a contradiction if we assume that people and HTML elements are disjoint classes.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/c214ad833704499c5c6cb565ccee7e1f.squirrel%40goddamn.co.uk Re: mapping from Turtle grammar to RDF graph 2010-02-03T15:44:43 2010-02-03T15:44:43 2010-02-03T15:44:43 > It also might be worth starting to consider whether to align the terminals > (qnames) more with sparql first. Or perhaps align both with CURIEs <http://www.w3.org/TR/curie/> ? -Toby > It also might be worth starting to consider whether to align the terminals > (qnames) more with sparql first. Or perhaps align both with CURIEs <http://www.w3.org/TR/curie/> ? -Toby http://tobyinkster.co.uk/message/1265483620.25221.15.camel%40ophelia2.g5n.co.uk Re: swap-scala's RDFa parser deployed on google app engine 2010-02-06T19:13:43 2010-02-06T19:13:43 2010-02-06T19:13:43 On Sat, 2010-02-06 at 11:21 +0000, Michael Hausenblas wrote: > Thanks a lot DanC! Awesome. I'll update the IR soon together with > Damian's java-rdfa parser, which is still on my todo list. Any other > implementation I might have missed out? I'd appreciate it if you dropped Swignition and replaced it with RDF::RDFa::Parser. The latter is passing the full test suite (or at least it does when run ... On Sat, 2010-02-06 at 11:21 +0000, Michael Hausenblas wrote: > Thanks a lot DanC! Awesome. I'll update the IR soon together with > Damian's java-rdfa parser, which is still on my todo list. Any other > implementation I might have missed out? I'd appreciate it if you dropped Swignition and replaced it with RDF::RDFa::Parser. The latter is passing the full test suite (or at least it does when run locally on my computer). I have a web service here though it can be a little slow: http://srv.buzzword.org.uk/rdfa-to-xml.cgi?uri= For those who are interested, Swignition (formerly known as Cognition) is more or less dead. However, its carrion will provide food for various spin-offs that I'm releasing (of which RDF::RDFa::Parser is the first). Swignition was too monolithic - the spin-offs will be smaller, more modular parsers and serialisers/writers. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265568505.25221.37.camel%40ophelia2.g5n.co.uk subscribe 2010-02-07T18:48:27 2010-02-07T18:48:27 2010-02-07T18:48:27 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265621178.3219.0.camel%40ophelia2.g5n.co.uk Re: CONFIRM s2280828832 2010-02-08T09:26:21 2010-02-08T09:26:21 2010-02-08T09:26:21 On Sun, 2010-02-07 at 18:49 +0000, public-rdfa-wg-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdfa-wg mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-rdfa-wg-request@... On Sun, 2010-02-07 at 18:49 +0000, public-rdfa-wg-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdfa-wg mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-rdfa-wg-request@w3.org > > with the Subject string: > > CONFIRM s2280828832 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm string > has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed above > will be (un)subscribed. If the address above is incorrect, please do not > send the confirmation message listed above. Instead, send a new > (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event that > you did not send a request to (un)subscribe, the headers of the message > may help you discover who sent the request. > > > >From tai@g5n.co.uk Sun Feb 07 18:49:11 2010 > >Received: from bart.w3.org ([128.30.52.63]) > > by frink.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1NeCBz-0007Ub-Hj > > for public-rdfa-wg-request@listhub.w3.org; Sun, 07 Feb 2010 18:49:11 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by bart.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1NeCBu-0005A0-Ui > > for public-rdfa-wg-request@w3.org; Sun, 07 Feb 2010 18:49:11 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 7FD6EB9802 > > for <public-rdfa-wg-request@w3.org>; Sun, 7 Feb 2010 18:48:35 +0000 (GMT) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, port 10025) > > with ESMTP id kz+BJHio4kQK for <public-rdfa-wg-request@w3.org>; > > Sun, 7 Feb 2010 18:48:27 +0000 (GMT) > >Received: from [127.0.0.1] (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 3F921B9801 > > for <public-rdfa-wg-request@w3.org>; Sun, 7 Feb 2010 18:48:27 +0000 (GMT) > >Subject: subscribe > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-rdfa-wg-request@w3.org > >Content-Type: text/plain; charset="UTF-8" > >Date: Sun, 07 Feb 2010 18:48:25 +0000 > >Message-ID: <1265568505.25221.37.camel@ophelia2.g5n.co.uk> > >Mime-Version: 1.0 > >X-Mailer: Evolution 2.28.1-1mdv2010.0 > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: bart.w3.org 1NeCBu-0005A0-Ui de6a78d5f92d1a2f5285c2053068f569 > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265706314.27114.5.camel%40ophelia2.g5n.co.uk Re: where are Uppercase reserved words specified? (Test #134) 2010-02-09T09:05:18 2010-02-09T09:05:18 2010-02-09T09:05:18 On Mon, 2010-02-08 at 20:00 -0600, Dan Connolly wrote: > Nothing about uppercase reserved words in sight. Specref, please? It's mentioned in the errata - final point in the list of clarifications. http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/ rel="NEXT" is mapped to <http://www.w3.org/1999/xhtml/vocab#next> but rel=":NEXT" is mapped to <http://www.w3.org/1999/xhtml/vocab#NEXT... On Mon, 2010-02-08 at 20:00 -0600, Dan Connolly wrote: > Nothing about uppercase reserved words in sight. Specref, please? It's mentioned in the errata - final point in the list of clarifications. http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/ rel="NEXT" is mapped to <http://www.w3.org/1999/xhtml/vocab#next> but rel=":NEXT" is mapped to <http://www.w3.org/1999/xhtml/vocab#NEXT>. The former is a reserved word (thus case-insensitive), the latter is a CURIE using the default prefix (thus case-sensitive). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265706869.27114.9.camel%40ophelia2.g5n.co.uk Re: Does RDFa processing recurse into content:encoded? 2010-02-09T09:14:32 2010-02-09T09:14:32 2010-02-09T09:14:32 On Mon, 2010-02-08 at 15:16 -0500, Stephane Corlosquet wrote: > This is correct and was brought in a previous thread. In fact we've > added this content:encoded mapping knowingly. However, despite the > fact this is not part of the RDFa specs, some parsers could ignore > this restriction and try to parse the content of this rdf:XMLLiteral. > I don't think there is any problem with that? expect con... On Mon, 2010-02-08 at 15:16 -0500, Stephane Corlosquet wrote: > This is correct and was brought in a previous thread. In fact we've > added this content:encoded mapping knowingly. However, despite the > fact this is not part of the RDFa specs, some parsers could ignore > this restriction and try to parse the content of this rdf:XMLLiteral. > I don't think there is any problem with that? expect convincing RDFa > parsers developers :D As an RDFa parser developer, I don't expect to add such a feature. It's a violation of the RDFa syntax specification, and if I were to change how I parsed XMLLiterals, it would cause me to fail the RDFa test suite. (I assume it would - if not, then there's a test that needs adding!) Drupal could add datatype="" to the element with property="content:encoded". This would allow parsers to recurse within it, however at the expense of creating a plain literal rather than an XMLLiteral. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265965462.7956.7.camel%40ophelia2.g5n.co.uk Re: CfC: Publish HTML5, RDFa heartbeats and Microdata, 2D Context and H:TML as FPWDs 2010-02-12T09:04:24 2010-02-12T09:04:24 2010-02-12T09:04:24 On Thu, 2010-02-11 at 20:52 -0600, Tab Atkins Jr. wrote: > For my own curiosity, I'd like to know how RDFa 1.1 is coming along. > Anyone have news? The RDFa WG (which has RDFa 1.1 as a deliverable) is newly formed (10 days ago) and hasn't had its first telecon yet. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2010-02-11 at 20:52 -0600, Tab Atkins Jr. wrote: > For my own curiosity, I'd like to know how RDFa 1.1 is coming along. > Anyone have news? The RDFa WG (which has RDFa 1.1 as a deliverable) is newly formed (10 days ago) and hasn't had its first telecon yet. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1265966156.7956.15.camel%40ophelia2.g5n.co.uk Re: Representing vCard Objects in RDF (W3C Member Submission) 2010-02-12T09:15:57 2010-02-12T09:15:57 2010-02-12T09:15:57 On Thu, 2010-02-11 at 09:48 +0000, Michael Hausenblas wrote: > http://open.vocab.org/terms/businessCard A while back, when I was RDFifying some hCards, I put together this: http://purl.org/uF/hCard/terms/ The schema needs a little work - I put it together before I knew many of the intricacies of RDFS and OWL. For example, I use "rdfs:range foaf:Person, v:VCard" when I mean "rdfs:range [owl:uni... On Thu, 2010-02-11 at 09:48 +0000, Michael Hausenblas wrote: > http://open.vocab.org/terms/businessCard A while back, when I was RDFifying some hCards, I put together this: http://purl.org/uF/hCard/terms/ The schema needs a little work - I put it together before I knew many of the intricacies of RDFS and OWL. For example, I use "rdfs:range foaf:Person, v:VCard" when I mean "rdfs:range [owl:unionOf (foaf:Person v:VCard)]". I'll try to update the schema in the near future. The property URIs themselves should be stable though. I'll make ov:businessCard into an owl:equivalentProperty of hcterms:hasCard. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1266388909.18442.0.camel%40ophelia2.g5n.co.uk Re: Updated DOCTYPE versioning change proposal (ISSUE-4) 2010-02-17T06:41:51 2010-02-17T06:41:51 2010-02-17T06:41:51 On Tue, 2010-02-16 at 19:41 -0800, Maciej Stachowiak wrote: > Also: should documents that request version-specific validation be > considered conforming HTML5 documents? Yes, iff the validation version they request corresponds to a published HTML5 recommendation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 2010-02-16 at 19:41 -0800, Maciej Stachowiak wrote: > Also: should documents that request version-specific validation be > considered conforming HTML5 documents? Yes, iff the validation version they request corresponds to a published HTML5 recommendation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1266521379.6234.12.camel%40ophelia2.g5n.co.uk RDF::RDFa::Parser 1.00 released today 2010-02-18T19:29:41 2010-02-18T19:29:41 2010-02-18T19:29:41 I've finally released version 1.00 of my Perl RDFa parser. It has a few interesting features that make it stand out from some other RDFa parsers: * Optional support for various features proposed for RDFa 1.1, including allowing URIs in currently CURIE-only attributes; and allowing SafeCURIEs in currently CURIE-only attributes. * Support for named graphs. <http://buzzword.org.uk/2009/rdfa4/spec> ... I've finally released version 1.00 of my Perl RDFa parser. It has a few interesting features that make it stand out from some other RDFa parsers: * Optional support for various features proposed for RDFa 1.1, including allowing URIs in currently CURIE-only attributes; and allowing SafeCURIEs in currently CURIE-only attributes. * Support for named graphs. <http://buzzword.org.uk/2009/rdfa4/spec> * The ability for the consumer of the page (not the author) to define additional keywords (like the @rel/@rev keywords) on an attribute-by-attribute basis, for all RDFa attributes: even @about and @resource. Predefined bundles of keywords corresponding to various X/HTML specifications, the Atom link registry, etc, are provided. * Special support for various host languages. For example, in SGML-style HTML, CURIE prefixes are treated case-insensitively by default, and @lang is used to set element languages; in Atom, <feed> and <entry> have an implicit @about (like <head> and <body> do in X/HTML); in SVG, embedded portions of RDF/XML are added to the graph; etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1266571179.6234.21.camel%40ophelia2.g5n.co.uk Re: RDF::RDFa::Parser 1.00 released today 2010-02-19T09:19:41 2010-02-19T09:19:41 2010-02-19T09:19:41 On Fri, 2010-02-19 at 09:23 +0100, Ivan Herman wrote: > I was wondering: would you mind adding this tool to the SWSWiki > toolset[1]? There is an extra page for contributors[2] and, of course, > cut-and-paste is your friend, so you can take the example of > pyRdfa...[3]. It would be good to have your tool appear on the RDFa > page there...[4] It's already on the Wiki, though doesn't seem to show up in category listings... http://www.w3.org/2001/sw/wiki/RDF-RDFa-Parser -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2010-02-19 at 09:23 +0100, Ivan Herman wrote: > I was wondering: would you mind adding this tool to the SWSWiki > toolset[1]? There is an extra page for contributors[2] and, of course, > cut-and-paste is your friend, so you can take the example of > pyRdfa...[3]. It would be good to have your tool appear on the RDFa > page there...[4] It's already on the Wiki, though doesn't seem to show up in category listings... http://www.w3.org/2001/sw/wiki/RDF-RDFa-Parser -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1266625190.6234.23.camel%40ophelia2.g5n.co.uk Re: list-expansion in RDFa 2010-02-20T00:19:52 2010-02-20T00:19:52 2010-02-20T00:19:52 On Fri, 2010-02-19 at 15:12 -0500, Gregg Kellogg wrote: > However, the inability to reasonably serialize RDF lists in RDFa is a > shortcoming. Serialising rdf:Lists in RDFa is ugly, ugly, ugly. That said, rdf:Lists have few uses outside OWL ontologies. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2010-02-19 at 15:12 -0500, Gregg Kellogg wrote: > However, the inability to reasonably serialize RDF lists in RDFa is a > shortcoming. Serialising rdf:Lists in RDFa is ugly, ugly, ugly. That said, rdf:Lists have few uses outside OWL ontologies. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1266626783.6234.30.camel%40ophelia2.g5n.co.uk Re: no change proposal for ISSUE-55, but a new plan for @profile 2010-02-20T00:46:25 2010-02-20T00:46:25 2010-02-20T00:46:25 On Fri, 2010-02-19 at 21:36 +0100, Julian Reschke wrote: > At present there are three supporters of this approach: Tantek, Manu > and myself. +1. FWIW, this idea seems (so far) fairly similar to an approach I mooted about a month ago as a solution for distributed extensibility in HTML. > http://microformats.org/wiki/html5-profile > > We hope that a FPWD-ready specification should be compl... On Fri, 2010-02-19 at 21:36 +0100, Julian Reschke wrote: > At present there are three supporters of this approach: Tantek, Manu > and myself. +1. FWIW, this idea seems (so far) fairly similar to an approach I mooted about a month ago as a solution for distributed extensibility in HTML. > http://microformats.org/wiki/html5-profile > > We hope that a FPWD-ready specification should be complete at the end > of March, but will only propose a FPWD at that time if we feel that > the work is ready. @profile essentially assigns additional meaning to particular parts of HTML which would otherwise have no common semantics. (Their meaning would otherwise be private to the document.) It is commonly used to assign meanings to @class, @rel and @rev tokens. It would be useful for the specification to clarify which parts of HTML @profile may be used to establish semantics for, and which are beyond the scope of profiles. I'd humbly suggest that its scope cover at least: @class @rel / @rev <meta name> @data-* -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1266880157.23845.18.camel%40ophelia2.g5n.co.uk Re: Fwd: Markup of SKOS in HTML 2010-02-22T23:09:21 2010-02-22T23:09:21 2010-02-22T23:09:21 <ol class="menu" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/" about="http://ukwildlife.co.uk/concepts#wildlife" typeof="skos:Concept" rel="skos:narrower"> <!-- The above means that http://ukwildlife.co.uk/concepts#wildlife is a Concept, and the child elements (the <li> elements) are related to it by being narrower concepts. --> ... <ol class="menu" xmlns:skos="http://www.w3.org/2004/02/skos/core#" xmlns:foaf="http://xmlns.com/foaf/0.1/" about="http://ukwildlife.co.uk/concepts#wildlife" typeof="skos:Concept" rel="skos:narrower"> <!-- The above means that http://ukwildlife.co.uk/concepts#wildlife is a Concept, and the child elements (the <li> elements) are related to it by being narrower concepts. --> <li typeof="skos:Concept"> <!-- Above introduces another Concept, but one without a URI. Giving the concept a URI (in an 'about' attribute) is generally a good idea because it allows other people to link to it. --> <a rel="foaf:page" href="/galleries/mammals/" property="skos:prefLabel" >Mammals</a> <!-- Above says that the concept has a page, with address /galleries/mammals/, and has a preferred label "Mammals". These attributes apply to the concept defined by the <li> element, not to the concept defined by the <ol> element, thanks to RDFa's nesting rules. --> </li> <li typeof="skos:Concept"> <a rel="foaf:page" href="/galleries/birds-ornithology/" property="skos:prefLabel">Birds</a> <!-- The above is similar to the mammals concept. --> <span rel="skos:related"> <span typeof="skos:Concept" property="skos:prefLabel">Ornithology</span> </span> <!-- This says that the Birds concept is related to another concept that has a preferred label "Ornithology". Previously you were using something like this: <span property="skos:related">Ornithology</span> This is wrong though, because the RDFa property attribute is used to mark literal properties (strings essentially), whereas the skos:related property is intended to be used to related between two concepts, not one concept and a literal. So rel is used instead, the target being a concept that has a preferred label. --> </li> <!-- The other concepts in your example were mostly similar. --> </ol> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/94473157cd258970ccb4dc5659f95f12.squirrel%40goddamn.co.uk Re: Question about qnames vs curies 2010-02-24T10:16:56 2010-02-24T10:16:56 2010-02-24T10:16:56 > How is the real and pratical difference of Qname and CURIE ? > I read this: > http://www.xml.com/pub/a/2007/04/04/introducing-rdfa-part-two.html?page=1 > And i conclude that only advantage is allow numeric names, like > "[ime:2224445]" CURIEs allow a lot of characters that cannot be used in QNames. For example: <div xmlns:google="http://www.google" xmlns:ex="http://example.com/"> <sp... > How is the real and pratical difference of Qname and CURIE ? > I read this: > http://www.xml.com/pub/a/2007/04/04/introducing-rdfa-part-two.html?page=1 > And i conclude that only advantage is allow numeric names, like > "[ime:2224445]" CURIEs allow a lot of characters that cannot be used in QNames. For example: <div xmlns:google="http://www.google" xmlns:ex="http://example.com/"> <span about="[google:.com/search?q=Foo]"> <span property="ex:ns#searchTerm">Foo</span> </span> </div> Produces the following triple: <http://www.google.com/search?q=Foo> <http://example.com/ns#searchTerm> "Foo" . The characters '/', '?', '=' and '#' could not be used in QNames, and I don't think the "localname" component of a QName can begin with a leading '.' either. -Toby http://tobyinkster.co.uk/message/85570d4cc765abecbed9e1af7a6e3844.squirrel%40goddamn.co.uk Re: RDFa DOM API: Adding RDF triples to the DOM 2010-02-24T13:22:35 2010-02-24T13:22:35 2010-02-24T13:22:35 > I doubt the wisdom of having a addTriple in an RDFa DOM API. Yes, it doesn't seem to be a great idea to me. It's a lot of work for little reward. An addTriple method is of course a great idea for the triple store API which is within the charter of the WG. -Toby > I doubt the wisdom of having a addTriple in an RDFa DOM API. Yes, it doesn't seem to be a great idea to me. It's a lot of work for little reward. An addTriple method is of course a great idea for the triple store API which is within the charter of the WG. -Toby http://tobyinkster.co.uk/message/ee326b6423dcbbaca224e84eea226f5b.squirrel%40goddamn.co.uk Re: New HTTP Link Header and Site Meta Specs 2010-02-24T15:54:57 2010-02-24T15:54:57 2010-02-24T15:54:57 > The first could enable the expression of RDF triples in HTTP via the > Link: header. > > Semantics in HTTP Link Header > http://tools.ietf.org/html/draft-nottingham-http-link-header-07 Can? It does (at least for a subset of RDF). My HTTP::Link::Parser perl module parses HTTP Link headers into an RDF model that can, for example, be queried with SPARQL. http://search.cpan.org/dist/HTTP-Link-Par... > The first could enable the expression of RDF triples in HTTP via the > Link: header. > > Semantics in HTTP Link Header > http://tools.ietf.org/html/draft-nottingham-http-link-header-07 Can? It does (at least for a subset of RDF). My HTTP::Link::Parser perl module parses HTTP Link headers into an RDF model that can, for example, be queried with SPARQL. http://search.cpan.org/dist/HTTP-Link-Parser/ > The .well-known proposal, while it has mixed reviews, attempts to > migrate well-known URLs such as /robots.txt and /favicon.ico to a > .well-known directory on the server. I've been looking at .well-known as a mechanism for discovering a host's main SPARQL Protocol endpoint. -Toby http://tobyinkster.co.uk/message/f111e45cf82fcc67d2eaf8e59b6327a8.squirrel%40goddamn.co.uk Re: Colors 2010-02-24T17:11:50 2010-02-24T17:11:50 2010-02-24T17:11:50 > Does anyone know of URIs which identify colors? Umbel has the general > notion of Color, but I want the actual colors, like, you know, red, > white, blue and yellow. I can make up my own, but would rather use > some already out there, if they exist. http://ontologi.es/colour/FF0000 = red http://ontologi.es/colour/FFFFFF = white http://ontologi.es/colour/0000FF = blue http://ontologi.es/colour/FFFF00 = yellow Though those identify particular shades of each colour. -Toby > Does anyone know of URIs which identify colors? Umbel has the general > notion of Color, but I want the actual colors, like, you know, red, > white, blue and yellow. I can make up my own, but would rather use > some already out there, if they exist. http://ontologi.es/colour/FF0000 = red http://ontologi.es/colour/FFFFFF = white http://ontologi.es/colour/0000FF = blue http://ontologi.es/colour/FFFF00 = yellow Though those identify particular shades of each colour. -Toby http://tobyinkster.co.uk/message/2fc2667a36226ddf9a060ede8a0eb557.squirrel%40goddamn.co.uk Possible PyRDFa bug 2010-02-24T17:15:25 2010-02-24T17:15:25 2010-02-24T17:15:25 If given a URL: http://example.com/foo Which redirects to: http://example.com/foo.html PyRDFa parses the document as if the base URI is still <http://example.com/foo>. -Toby If given a URL: http://example.com/foo Which redirects to: http://example.com/foo.html PyRDFa parses the document as if the base URI is still <http://example.com/foo>. -Toby http://tobyinkster.co.uk/message/1267141451.32438.19.camel%40ophelia2.g5n.co.uk Re: Error in RDFa generated by validator.w3.org 2010-02-25T23:44:13 2010-02-25T23:44:13 2010-02-25T23:44:13 On Thu, 2010-02-25 at 11:16 -0800, Nathan R. Yergler wrote: > This was reported last year, with the promise to be corrected in the > next release (http://www.w3.org/Bugs/Public/show_bug.cgi?id=7025). Do > we know how to give this a nudge? It was me who contributed the original code that added RDFa to the validator output, and made this mistake. I later contributed a fix, which was checked into t... On Thu, 2010-02-25 at 11:16 -0800, Nathan R. Yergler wrote: > This was reported last year, with the promise to be corrected in the > next release (http://www.w3.org/Bugs/Public/show_bug.cgi?id=7025). Do > we know how to give this a nudge? It was me who contributed the original code that added RDFa to the validator output, and made this mistake. I later contributed a fix, which was checked into the validator's CVS repository, but there hasn't been a release since then. Oliver Theroux was the validator's main developer and arranged releases and such, but IIRC he's no longer employed by the W3C. I don't know who, if anyone, is now responsible for validator releases. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1267177565.32438.56.camel%40ophelia2.g5n.co.uk Re: precedence of xml:lang and lang? 2010-02-26T09:46:11 2010-02-26T09:46:11 2010-02-26T09:46:11 On Fri, 2010-02-26 at 08:43 +0100, Ivan Herman wrote: > I tried to look at the (X)HTML5 document, I did find a reference to > xml:lang in 7.03[3], but I did not find any reference to the question > of relative precedence. I must admit I am not very familiar with the > HTML5 document structure, so I may have missed it. The relevant section of the latest HTML5 working draft (25/08/09) is 3.2.3.3. ... On Fri, 2010-02-26 at 08:43 +0100, Ivan Herman wrote: > I tried to look at the (X)HTML5 document, I did find a reference to > xml:lang in 7.03[3], but I did not find any reference to the question > of relative precedence. I must admit I am not very familiar with the > HTML5 document structure, so I may have missed it. The relevant section of the latest HTML5 working draft (25/08/09) is 3.2.3.3. In DOM terms, there are three attributes of relevance in HTML5 (and here I'm excluding the Content-Language HTTP header and <meta http-equiv> equivalent of it, which as I understand it, are still being debated). Written in Clark notation, they're: 1. {http://www.w3.org/XML/1998/namespace}lang 2. {}lang 3. {}xml:lang Note that #1 and #3 are each the result of parsing an attribute called 'xml:lang'. Parsing under XML rules yields #1, and under HTML rules yields #3. In terms of declaring the language of an element, #1 has precedence (just like it does in XHTML 1) over #2. #3 is ignored. However, for HTML documents (i.e. those sent as text/html), no attributes will ever be parsed as #1. (I believe #1 attributes can still be created via client-side scripts.) While the precedence rules are the same in HTML and XHTML, because HTML parsing has the effect of never generating #1 attributes and generating #3 instead, effectively 'xml:lang' is always ignored. This is somewhat annoying, given that it can result in different behaviour in HTML and XML processing modes. That said, for HTML documents, it is a conformance error to set an 'xml:lang' attribute without also providing a 'lang' attribute which is a case-sensitive match. So at least this problem should be picked up by validators. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1267405337.15017.30.camel%40ophelia2.g5n.co.uk RE: ISSUE-4 (html-versioning) (vs. ISSUE-30 longdesc) 2010-03-01T01:02:24 2010-03-01T01:02:24 2010-03-01T01:02:24 On Sun, 2010-02-28 at 11:38 -0800, Larry Masinter wrote: > If someone wants to write a different change proposal which > introduces a HTML version parameter somewhere else, I would > likely be willing to support that as well. For what it's worth, the following HTML and XHTML Recs/RFCs all include an attribute called 'version' on the root element which may be used to indicate HTML version: HTML... On Sun, 2010-02-28 at 11:38 -0800, Larry Masinter wrote: > If someone wants to write a different change proposal which > introduces a HTML version parameter somewhere else, I would > likely be willing to support that as well. For what it's worth, the following HTML and XHTML Recs/RFCs all include an attribute called 'version' on the root element which may be used to indicate HTML version: HTML 2.0 HTML 3.2 HTML 4.01 (Transitional DTD **) XHTML 1.1 XHTML+RDFa 1.0 ** = yes, HTML 4.01 deprecates it, so you might think it's justifiable for HTML5 to remove it altogether, but you've got to look at the reason that HTML 4.01 deprecates it: "it is redundant with version information provided by the document type declaration". If version information is no longer provided by the DTD in HTML5, then it is no longer redundant. Similar facilities are available in some/all(?) versions of SVG, in RSS 2, in XSLT, in OPML and probably other common XML formats that I'm forgetting. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1267485953.15017.73.camel%40ophelia2.g5n.co.uk Re: ISSUE-18 (ODF integration): Determine how ODF will integrate RDFa 1.1 [RDFa 1.1 Core] 2010-03-01T23:25:55 2010-03-01T23:25:55 2010-03-01T23:25:55 Prompted by a thread on semantic-web@w3.org I was recently taking a look at RDFa in ODF. Here are a few of my findings... On Mon, 2010-03-01 at 02:30 +0000, RDFa Working Group Issue Tracker wrote: > * Are all RDFa properties included in ODF? Assuming by "properties" you mean "attributes", the answer is no. Only about, property, datatype and content are. This effectively means that all triples ... Prompted by a thread on semantic-web@w3.org I was recently taking a look at RDFa in ODF. Here are a few of my findings... On Mon, 2010-03-01 at 02:30 +0000, RDFa Working Group Issue Tracker wrote: > * Are all RDFa properties included in ODF? Assuming by "properties" you mean "attributes", the answer is no. Only about, property, datatype and content are. This effectively means that all triples have literal objects. An interesting question this throws up is what a parser should do if it encounters one of the RDFa attributes which ODF does not define. Clearly it's an ODF conformance error, but should the parser treat it according to the RDFa syntax specification, or ignore its presence > * Are all HTML reserved keywords such as rel="next" defined in ODF? No rel and rev attributes, so they presumably don't need to be defined. > * Should there be an RDFa versioning mechanism in ODF? > * Is follow-your-nose via @profile expected to work in ODF? > * Are malformed ODF documents expected to be processed? Here are a couple of other aspects that should be considered... 1. ODF places the RDFa attributes in the XHTML namespace (http://www.w3.org/1999/xhtml), whereas all other RDFa host languages (XHTML, SVG, HTML, DataRSS) put them in the null namespace.. 2. ODF specifies interesting behaviour for generating the literal object value of the <text:bookmark-start/> element. As I understand it, the literal value of the following should be "Bar\nBaz": <text:p>Foo<text:bookmark-start text:name="x" xhtml:about="" xhtml:property="ex:example"/>Bar</text:p> <text:p>Baz<text:bookmark-end text:name="x"/>Quux</text:p> That is, it pulls text content until a corresponding (same text:name) <text:bookmark-end/> is found. Note that in my example above, the bookmark start and end are in different paragraph elements. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/40598bd40ce888d4bb89775aad9255ae.squirrel%40goddamn.co.uk Introduction 2010-03-03T10:08:56 2010-03-03T10:08:56 2010-03-03T10:08:56 Hello, I'm the Working Group's newest invited expert. I work part time for a charity in the UK and take on occasional freelance work, though my interests in the Semantic Web are mostly a hobby. A couple of years ago I started development of a Perl parser for microformats and other semantic HTML formats (e.g. eRDF, DC-HTML, etc). Development of the parser, Swignition, is now mostly stopped, thou... Hello, I'm the Working Group's newest invited expert. I work part time for a charity in the UK and take on occasional freelance work, though my interests in the Semantic Web are mostly a hobby. A couple of years ago I started development of a Perl parser for microformats and other semantic HTML formats (e.g. eRDF, DC-HTML, etc). Development of the parser, Swignition, is now mostly stopped, though I'm cannibalising it to split out some of the more interesting components. RDFa was one of the formats I implemented, and it quickly became my favourite. The RDFa parser was the first thing to be split out from Swignition, and is available on CPAN under the name RDF::RDFa::Parser. It already implements (as options that can be selectively enabled) many of the features that are on the agenda for this working group, including support for the 'lang' attribute, support for non-XHTML host languages, support for full URIs in CURIE attributes, and various ways of handling prefix-less CURIEs. Another project I'm working on (on and off) is my RDF-based CMS, demiblog. It keeps all its data in a triple store and serves it up using machine-generated RDFa. My work items of interest for the RDFa WG are: 1. Keeping RDFa 1.1 compatible with RDFa 1.0. I'm defining "compatible" thusly: any document authored as RDFa 1.0 should produce the same graph when parsed with an RDFa 1.1 parser; and any document authored as RDFa 1.1 should produce the same graph, or a proper subgraph when parsed with a legacy RDFa 1.0 parser. 2. Try to ensure that RDFa external vocabs, or whatever they end up being called, don't end up making RDFa documents more fragile; don't break too badly when the vocab document disappears; don't introduce centralised points of failure. 3. Trying to reduce divergence in how RDFa is adopted by different host languages. RDFa Core 1.1 should specify which features of RDFa host languages may alter, and which they should not. 4. It would be nice (if people think it's within the group's scope) to look at publishing something like Named Graphs in RDFa <http://buzzword.org.uk/2009/rdfa4/spec> as a Working Group Note. -Toby http://tobyinkster.co.uk/message/cd5b0896ea779558664768c96b9f6f28.squirrel%40goddamn.co.uk unsubscribe 2010-03-03T17:24:28 2010-03-03T17:24:28 2010-03-03T17:24:28 http://tobyinkster.co.uk/message/1267731469.30377.38.camel%40ophelia2.g5n.co.uk Javascript Security for Dummies 2010-03-04T19:37:52 2010-03-04T19:37:52 2010-03-04T19:37:52 Apologies for cutting out of the telecon a few minutes early. As I left I volunteered to write a quick summary of how Javascript/JSON/JSONP/CORS relate to each other and the various security issues involved. Let's start with the basics: Javascript (more properly known as ECMAScript these days) is a scripting language with various implementations, the best known being the ones that are embedded in... Apologies for cutting out of the telecon a few minutes early. As I left I volunteered to write a quick summary of how Javascript/JSON/JSONP/CORS relate to each other and the various security issues involved. Let's start with the basics: Javascript (more properly known as ECMAScript these days) is a scripting language with various implementations, the best known being the ones that are embedded in most modern, graphical browsers. Javascript, as implemented in browsers, runs in a sandbox to prevent maliciously crafted web pages from doing any damage to the visitor's machine. A good number of years ago, Microsoft implemented a proprietary extension to Javascript which allowed scripts to perform HTTP requests and make use of the responses. Mozilla implemented some fairly similar functionality, and eventually other browsers followed (using the Mozilla syntax). This feature is called XmlHttpRequest or XHR - it's a bit of a misnomer as it's not restricted to retrieving XML. For security reasons, XHR requests are only allowed to be performed to URLs on the same domain as the script itself was loaded from. This is a good thing because you don't want http://evil.example/badpage.html to be able to perform an XHR to <http://bank.example/account-statement.html> especially given that the XHR would be sent with all the applicable cookies in the browser's cookie jar. (Aside: technically it's not cross-domain requests that are disallowed, but cross-origin requests. An origin is a slightly wooly concept: foo.example.com and bar.example.com are considered to be the same origin, foo.co.uk and bar.co.uk are different origins, despite the fact that from a DNS viewpoint, they're both third-level domain names. This is all being standardised currently.) Douglas Crockford "discovered" JSON. He maintains that he didn't invent it, just realise that Javascript contained a useful bit of syntax that could be standardised on. JSON is a restricted subset of Javascript's notation for objects and arrays. (JSON = Javascript Object Notation.) JSON is a data format that allows strings, numbers, booleans, arrays and associative arrays to be represented. In many ways it can be considered a competitor to XML. It's also pretty similar to YAML (though the oft-quoted statement that it's a subset of YAML is an urban myth). Here's how a person might be represented in JSON: { "name" : "Toby Inkster" , "homepage" : "http://tobyinkster.co.uk/" , "mbox" : "mailto:mail@tobyinkster.co.uk" } Getting back to XHR, often people want to be able to request data from other origins, circumventing the same-origin policy enforced by browsers. With a little bit of extra syntax, JSON can be useful for this. This extra syntax is called JSONP. (JSONP = JSON plus Payload.) The way that JSONP works is that instead of supplying a JSON response, the server responding with the data sends a Javascript response, like this (usually the name of the callback function is configurable as a query string): callback_function({ "name" : "Toby Inkster" , "homepage" : "http://tobyinkster.co.uk/" , "mbox" : "mailto:mail@tobyinkster.co.uk" }); How does this circumvent XHR's same-origin policy? Answer: it doesn't. But it eliminates the need to use XHR at all. The page requesting the data doesn't need to perform an XHR request, it just defines a function called callback_function to deal with the data, then it loads the JSONP file using a standard HTML <script src> element. The browser downloads and executes the script, and calls the function with the data as a parameter. However, this opens up a big security hole. Suppose that the server supplying a JSONP response is compromised, or its owner just decides to turn to the dark side. The server can send arbitrary Javascript (i.e. not JSONP) and the browser will execute it unquestioningly. This Javascript could be used to steal cookies, passwords and other privileged information from the page it was included in. Not nice. CORS is another way around the same-origin policy, but this time it's not a hack. It's a set of HTTP headers that a URL can respond with to indicate that it's safe to be retrieved in cross-origin requests. So if, say, http://bank.example/homepage.html contains no private data and is perfectly safe for other sites to have access to, then it could set a CORS header to allow http://evil.example/badpage.html to try its worst. http://bank.example/account-statement.html wouldn't send the CORS header so would be protected by the default same-origin policy. So how does this apply to RDFa vocabularies/profiles? If vocabularies are hosted on a separate server to the pages making use of them, then Javascript implementations of RDFa would need to make a cross-origin request to read them. (Actually they could make a same-origin request to a proxying script, but that's not an especially elegant solution.) If we want such Javascript implementations of RDFa to be possible, this allows two solutions: 1. Serve up the vocabulary document as JSONP; or 2. Serve it up as something else plus CORS headers. #1 is problematic because as I said, JSONP is not nice, safe JSON, despite the similar names. JSONP is Javascript. #2 is problematic because CORS is a very new feature. Many of the newest browsers support it (including IE8), but if you want your script to work in downlevel browsers, this is not your solution. In my next message I'll outline how my RDFa vocab proposal (which is slightly different to Manu's) makes this a moot point by saying that retrieval of the vocab document is optional - a SHOULD requirement rather than a MUST - and provides a fallback in the case, e.g. of browsers which don't implement CORS. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1267780357.30377.45.camel%40ophelia2.g5n.co.uk Re: Javascript Security for Dummies 2010-03-05T09:12:40 2010-03-05T09:12:40 2010-03-05T09:12:40 On Fri, 2010-03-05 at 09:20 +0100, Ivan Herman wrote: > I do have a technical question, though, for further clarification. You > say that, if a data is defined through JSONP, what this means is that > the HTML file that starts up the whole process should have an > additional <script...> element to get that. Typically when loading JSONP, the document would not include an actual <script> element t... On Fri, 2010-03-05 at 09:20 +0100, Ivan Herman wrote: > I do have a technical question, though, for further clarification. You > say that, if a data is defined through JSONP, what this means is that > the HTML file that starts up the whole process should have an > additional <script...> element to get that. Typically when loading JSONP, the document would not include an actual <script> element that loads it. Rather the JSONP would be loaded by another script. e.g.: <script type="text/javascript"> function load_data (u, cb) { document.write("<script src=\""+u+"?callback="+cb+"\"></script>"); } function handle_data (d) { blah blah; } blah blah blah; blah blah; { load_data(foo, handle_data); load_data(bar, handle_data); } </script> So the RDFa author would not add JSONP script tags to their document. They'd add an RDFa API script to their document, which would in turn load JSONP files using document.write() or similar. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1267809082.30377.92.camel%40ophelia2.g5n.co.uk Re: attempting to merge the 'vocab' and 'profile' documents 2010-03-05T17:11:25 2010-03-05T17:11:25 2010-03-05T17:11:25 On Fri, 2010-03-05 at 17:17 +0100, Ivan Herman wrote: > I am more concerned by the, shall we say, 'political' issues that this > might raise: HTML5 WG decides to remove an attribute and then the RDFa > WG decides to reintroduce it... that would be a recipe for flame wars *cough* @rev *cough*. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2010-03-05 at 17:17 +0100, Ivan Herman wrote: > I am more concerned by the, shall we say, 'political' issues that this > might raise: HTML5 WG decides to remove an attribute and then the RDFa > WG decides to reintroduce it... that would be a recipe for flame wars *cough* @rev *cough*. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/dc1fc1acf4c1a6d19bd6a9ab9e561254.squirrel%40goddamn.co.uk Re: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments) 2010-03-10T13:32:09 2010-03-10T13:32:09 2010-03-10T13:32:09 > - UAs appear to treat those consistently (with the exception of Opera, > but Yngwe already signaled that he's willing to adapt), *but* Hmmm... Opera's behaviour seems nicer. It's a shame to lose that, but pragmatically one vendor changing their behaviour is going to be simpler than all of the others doing so. -Toby > - UAs appear to treat those consistently (with the exception of Opera, > but Yngwe already signaled that he's willing to adapt), *but* Hmmm... Opera's behaviour seems nicer. It's a shame to lose that, but pragmatically one vendor changing their behaviour is going to be simpler than all of the others doing so. -Toby http://tobyinkster.co.uk/message/8a0c27f4bc97cd4e46453fe6f2f6103c.squirrel%40goddamn.co.uk [Fwd: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments)] 2010-03-10T13:34:32 2010-03-10T13:34:32 2010-03-10T13:34:32 I wonder if the semantics of the proposed solution to ticket 43 below have implications for httpRange-14? ---------------------------- Original Message ---------------------------- Subject: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments) From: "Julian Reschke" <julian.reschke@gmx.de> Date: Wed, March 10, 2010 1:06 ... I wonder if the semantics of the proposed solution to ticket 43 below have implications for httpRange-14? ---------------------------- Original Message ---------------------------- Subject: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments) From: "Julian Reschke" <julian.reschke@gmx.de> Date: Wed, March 10, 2010 1:06 pm To: "HTTP Working Group" <ietf-http-wg@w3.org> "public-html@w3.org" <public-html@w3.org> -------------------------------------------------------------------------- Hi, the HTTPbis WG has two open tickets with respect to the syntax and semantics of the Location header (not to be confused with Content-Location!): a) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment combination / precedence during redirects" This is about how to handle the case when both the original URI and the value of the Location header contain a fragment identifier. b) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location header payload handling" This is about allowing relative references (in addition to full URIs), and also about treating broken values (*). Some time ago I created a few tests, see <http://greenbytes.de/tech/tc2231/redirects.html>. What I found was that - UAs appear to treat those consistently (with the exception of Opera, but Yngwe already signaled that he's willing to adapt), *but* - the behavior I found unfortunately doesn't make sense (treating the cases for absolute URIs and relative references differently). Specifically, I would expect UAs to let the fragment ID found in the Location header (when present) override the original URI's. But we found this to be only the case for absolute URIs. At this point, and with no further feedback from browser vendors about whether they'd consider changing the behavior for relative references, we changed the spec to clarify that the fragment recombination behavior is undefined (previously, the spec didn't say anything about this). The new text for "Location" is: -- snip -- 9.4. Location The "Location" response-header field is used to identify a newly created resource, or to redirect the recipient to a different location for completion of the request. For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5). Location = "Location" ":" OWS Location-v Location-v = URI-reference Examples are: Location: http://www.example.org/pub/WWW/People.html#tim Location: /index.html There are circumstances in which a fragment identifier in a Location URI would not be appropriate: o With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource. o With 305 Use Proxy. Note: This specification does not define precedence rules for the case where the original URI, as navigated to be the user agent, and the Location header field value both contain fragment identifiers. Note: The Content-Location header field (Section 5.7 of [Part3]) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response. It is therefore possible for a response to contain header fields for both Location and Content-Location. -- snip -- (see also <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#header.location>). Of course it would be nice if we *could* recommend a specific behavior that makes sense, so I would be very grateful to get feedback from UA implementers about whether they'd consider treating relative references and absolute URIs consistently. Best regards, Julian (*) We'll look at *that* issue separately. On 10.03.2010 13:19, Julian Reschke wrote: > On 09.03.2010 17:54, Julian Reschke wrote: >> ... >> OK, here's a proposal >> (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/43/i43.diff>): >> >> >> >> - allow relative references >> >> - state that we do not specify fragment recombination >> >> - stay silent on invalid URI-references (I think we should discuss this >> as an orthogonal issue). >> >> The changed text for the Location header would be: >> ... > > Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/785>. > > I'll send a separate summary, and cc' the W3C HTML WG, trying (yet > again) to get feedback from browser vendors about whether they're > willing to go further than that. > > Best regards, Julian > http://tobyinkster.co.uk/message/1268263032.27087.73.camel%40ophelia2.g5n.co.uk Re: attempting to merge the 'vocab' and 'profile' documents 2010-03-10T23:17:13 2010-03-10T23:17:13 2010-03-10T23:17:13 On Wed, 2010-03-10 at 19:05 +0000, Mark Birbeck wrote: > Note also that this idea of 'tokens' brings our predefined keywords > into harmony with prefix-mappings; using the new 'optional colon' > rule, we can see that the predefined token 'next' is no different to > the following longhand: > > <div xmlns:next="http://www.w3.org/1999/xhtml/vocab#next"> > <a rel="next" href="blah">go to next d... On Wed, 2010-03-10 at 19:05 +0000, Mark Birbeck wrote: > Note also that this idea of 'tokens' brings our predefined keywords > into harmony with prefix-mappings; using the new 'optional colon' > rule, we can see that the predefined token 'next' is no different to > the following longhand: > > <div xmlns:next="http://www.w3.org/1999/xhtml/vocab#next"> > <a rel="next" href="blah">go to next document</a> > </div> It is still slightly different, in that the predefined keywords are case-correcting (i.e. detected case-insensitively, but automatically mapped to the correct case) and only apply in particular attributes. I do however see the appeal in defining tokens as an extension of the existing prefix mechanism. RDF::RDFa::Parser actually implements this already as an option, disabled by default. If anyone wants to play with it, you can add the following to your document to opt-in: <meta name="http://search.cpan.org/dist/RDF-RDFa-Parser/#auto_config" content="prefix_bare=1" /> And then parse it using either of these endpoints: http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= http://srv.buzzword.org.uk/rdfa-to-xml.cgi?uri= -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268263492.27087.81.camel%40ophelia2.g5n.co.uk RDF TripleStores API 2010-03-10T23:24:57 2010-03-10T23:24:57 2010-03-10T23:24:57 This working group has this document as an optional deliverable. As I understand it, the aim is roughly to document the current landscape of APIs for triple stores, and if it's found lacking, suggest possible directions the W3C could advance it -- e.g. by standardising a useful API. It's somewhat unfortunate that the schedule of work for the group places it chronologically after the RDFa DOM API... This working group has this document as an optional deliverable. As I understand it, the aim is roughly to document the current landscape of APIs for triple stores, and if it's found lacking, suggest possible directions the W3C could advance it -- e.g. by standardising a useful API. It's somewhat unfortunate that the schedule of work for the group places it chronologically after the RDFa DOM API, given that surveying the landscape of triple store APIs could help inform work on the DOM API. Anyway, I've kickstarted an informal survey of RDF APIs on the Wiki <http://www.w3.org/2010/02/rdfa/wiki/RDF-API>. If you've got the time, it would be nice if you could add a summary of the API of your favourite RDF toolkit (Redland, Jena, Seseme, ARC, rdfQuery, etc - take your pick!) - just the basic CRUD-style operations. Then we can compare and contrast - see how they differ, and in what ways they're similar. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268300941.27087.111.camel%40ophelia2.g5n.co.uk Re: RDFa for Turtles 2: HTML embedding 2010-03-11T09:49:02 2010-03-11T09:49:02 2010-03-11T09:49:02 On Wed, 2010-03-10 at 22:50 +0100, Danny Ayers wrote: > On 10 March 2010 18:19, Paul Houle <ontology2@gmail.com> wrote: > > > <head xmlns="http://www.w3.org/1999/xhtml" > xmlns:dcterms="http://purl.org/dc/terms/"> > > <meta rel="dcterms:creator" content="Ataru Morobishi"> > > </head> > > ... > > > This does bend the XHTML/RDFa standard and also HTML a little (those > namespace declarations ... On Wed, 2010-03-10 at 22:50 +0100, Danny Ayers wrote: > On 10 March 2010 18:19, Paul Houle <ontology2@gmail.com> wrote: > > > <head xmlns="http://www.w3.org/1999/xhtml" > xmlns:dcterms="http://purl.org/dc/terms/"> > > <meta rel="dcterms:creator" content="Ataru Morobishi"> > > </head> > > ... > > > This does bend the XHTML/RDFa standard and also HTML a little (those > namespace declarations aren't technically valid) > > Sorry, but what's not valid about that? In XHTML 1.x, @rel is not an allowed attribute for <meta>, and @xmlns:dcterms is not an allowed attribute for <head> (though the W3C validator glosses over the latter invalidity). Also the <meta> element isn't closed. In HTML 4.x, the two attributes above are still disallowed, as is @xmlns on <head>. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268301526.27087.121.camel%40ophelia2.g5n.co.uk Re: RDFa for Turtles 2010-03-11T09:58:47 2010-03-11T09:58:47 2010-03-11T09:58:47 On Wed, 2010-03-10 at 12:03 -0500, Paul Houle wrote: > <meta rel="{predicate}" content="{object}" /> > <meta rel="{predicate}" content="{object}" datatype="{type_of_object}" /> You want to use @property, not @rel. Also, don't forget @xml:lang! > Am I missing anything? To bullet-proof it, you may want to explicitly set @about on *all* the <link> and <meta> elements, plus @xml:lang on all <m... On Wed, 2010-03-10 at 12:03 -0500, Paul Houle wrote: > <meta rel="{predicate}" content="{object}" /> > <meta rel="{predicate}" content="{object}" datatype="{type_of_object}" /> You want to use @property, not @rel. Also, don't forget @xml:lang! > Am I missing anything? To bullet-proof it, you may want to explicitly set @about on *all* the <link> and <meta> elements, plus @xml:lang on all <meta> elements, to avoid chaining, and avoid inheriting language tags from <head> or <html>. > Requirement: Ability to embed RDFa in a document that is not, > globally, a valid XHTML document Why not just use the HTML+RDFa draft being worked on by the HTML WG in conjunction with the RDFa WG? It specifies how RDFa can be used in so-called "tag soup" HTML. I know of at least three tools that implement HTML+RDFa at least experimentally: * RDF::RDFa::Parser - my own Perl RDFa parser. * PyRDFa - the code that powers the W3C's "RDFa distiller" service. * Damien Steer's Java RDFa parser which I can't remember the name of. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268301895.27087.127.camel%40ophelia2.g5n.co.uk Re: Conneg representation equivalence 2010-03-11T10:04:55 2010-03-11T10:04:55 2010-03-11T10:04:55 On Thu, 2010-03-11 at 02:24 +0000, Nathan wrote: > If I have multiple representations of a resource which I consider > equal, let's say one of each of the following: RDF+XML, RDF+N3, SVG > > Then should all three representations be considered equivalent? They certainly *could* all represent the same thing. Whether they *do* represent the same thing is a judgement call. > Is it correct that all ... On Thu, 2010-03-11 at 02:24 +0000, Nathan wrote: > If I have multiple representations of a resource which I consider > equal, let's say one of each of the following: RDF+XML, RDF+N3, SVG > > Then should all three representations be considered equivalent? They certainly *could* all represent the same thing. Whether they *do* represent the same thing is a judgement call. > Is it correct that all representations must have consistent fragment > identifiers in order to be considered equivalent? A fragment identifier should not identify different things in different representations. (Though it may be unrepresented in some or all of the representations.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268334340.15904.6.camel%40ophelia2.g5n.co.uk Re: ISSUE-1: Format of the profile document 2010-03-11T19:05:43 2010-03-11T19:05:43 2010-03-11T19:05:43 On Thu, 2010-03-11 at 12:22 -0500, Manu Sporny wrote: > It was discussed today that we could allow that as an option for > implementers, but the only profile document format that would be > required by the specification would be a document expressed in RDFa. > > This still means that one could use XHTML+RDFa, HTML+RDFa, SVG+RDFa or > even perhaps ODF+RDFa. A key point to make is that although RD... On Thu, 2010-03-11 at 12:22 -0500, Manu Sporny wrote: > It was discussed today that we could allow that as an option for > implementers, but the only profile document format that would be > required by the specification would be a document expressed in RDFa. > > This still means that one could use XHTML+RDFa, HTML+RDFa, SVG+RDFa or > even perhaps ODF+RDFa. A key point to make is that although RDFa would be the only format that parsers would be required to implement support for, they would also be free to support other formats. Profile publishers would not be mandated to publish the profile in RDFa, but any that care about interoperability would. They could choose to publish the profile in multiple formats using content negotiation. A parser that supports the required RDFa profile format, but also an alternative JSON profile format might issue an HTTP Accept header like this: Accept: application/json;q=1.0, application/xhtml+xml;q=0.1, text/html;q=0.1 Using the 'q' value to advertise that it would prefer the JSON profile, as it would probably the lighter weight and quicker to parse. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268336838.15904.44.camel%40ophelia2.g5n.co.uk Re: ISSUE-1: What happens when you can't dereference a profile document? 2010-03-11T19:47:19 2010-03-11T19:47:19 2010-03-11T19:47:19 On Thu, 2010-03-11 at 12:37 -0500, Manu Sporny wrote: > Both Ben and Toby have been concerned about what happens when you > cannot dereference an RDFa Profile document. Both of them have > expressed that he would like to see a placeholder triple that is > generated when a profile document cannot be dereferenced. RDFa > toolchains can then dereference the profile document at a later time > and re-w... On Thu, 2010-03-11 at 12:37 -0500, Manu Sporny wrote: > Both Ben and Toby have been concerned about what happens when you > cannot dereference an RDFa Profile document. Both of them have > expressed that he would like to see a placeholder triple that is > generated when a profile document cannot be dereferenced. RDFa > toolchains can then dereference the profile document at a later time > and re-write the triple when the profile document becomes available. Frankly it's not just the case of what happens if the profile document is temporarily down, but we also have to consider what happens if the profile document is *permanently* down. Let's assume that this: <b profile="http://example.com/vocab" typeof="Person" property="name">Joe Bloggs</b> Is supposed to expand to: @prefix foaf: <http://xmlns.com/foaf/0.1/> . [] a foaf:Person ; foaf:name "Joe Bloggs" . But the example.com vocabulary disappears *permanently*. Now say we allow it to continue to generate triples, using fallback URIs, e.g. @prefix vocab1: <http://example.com/vocab#> . [] a vocab1:Person ; vocab1:name "Joe Bloggs" . Now, tools that know about FOAF won't know what these triples mean, so you might wonder what's the value in them. But when we start to combine them with triples found on other pages, the value starts to appear. Say another page contains: <b profile="http://example.com/vocab" typeof="Person" property="name">Alice Gibbs</b> Then our theoretical consumer knows that Joe Bloggs and Alice Gibbs are the same kind of thing, in some way. A third page might contain: <div xmlns:foaf="http://xmlns.com/foaf/0.1/" profile="http://example.com/vocab" typeof="Person"> <span property="name">Bob Jenkins</span> (<span property="foaf:gender">male</span>) </div> Now, not only does it know that Bob Jenkins is the same type of thing that Alice Gibbs and Joe Bloggs are; it also knows that Bob Jenkins is a foaf:Agent (this can be reasoned from FOAF's definition of the foaf:gender property). It can't be sure that Alice Gibbs and Joe Bloggs are foaf:Agents, but it can be sure that this vocab1:Person class isn't disjoint with foaf:Agent. (i.e. they're at least overlapping classes.) That is, making the parser generate fallback triples allows the consumer the option of building up a picture of the profile terms from other sources, regardless of whether the profile eventually becomes available again. A big question that needs to be answered before we can determine whether this is feasible is: how many profiles can be active at once? e.g. given: <div profile="a"> <div profile="b"> <span typeof="Foo" property="bar" resource="[baz]" /> </div> </div> Let's assume that profile 'a' defines 'Foo' and 'bar'; and profile 'b' defines 'bar' and 'baz'. For 'baz', I don't imagine there is any contention. Profile b's definition wins. For 'bar' there are three possible outcomes: - it resolves to profile b's definition only, as the nearest ancestor profile; - it resolves to profile a's definition only, because it "got there first"; or - it generates two triples, using both definitions. But what about 'Foo': - it's treated as typeof="" because the nearest ancestor profile does not define it; or - the parser figures out that b does not define Foo, so checks the next ancestor profile for a definition. If we make the decision that there's only ever one profile active, then when parsing the <span/>, profile 'a' will be ignored, so we get 'Foo' undefined, with 'bar' and 'baz' defined by profile 'b'. If there's only every one profile active, then generating these fallback triples becomes a very easy option, because we know exactly which profile was *supposed* to define them. > Toby has an alternate mechanism that uses @default-prefix and requires > RDFa processors to understand a subset of OWL. @default-prefix was just a temporary name for the attribute while we were deciding. @profile is fine. The subset of OWL required is not much more complicated to implement than the current suggested vocabulary for profiles. It's merely a way of saying that this term from the profile: <http://example.com/vocab#Person> is equivalent to this one: <http://xmlns.com/foaf/0.1/Person> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268386255.15904.54.camel%40ophelia2.g5n.co.uk Re: ISSUE-1: Status of RDFa Profiles 2010-03-12T09:30:56 2010-03-12T09:30:56 2010-03-12T09:30:56 On Thu, 2010-03-11 at 15:39 -0800, Ben Adida wrote: > I'm still worried about inheriting prefixes from @profile, so I'm not > sure we have consensus just yet. The other problem is that it introduces a conflict with full URIs in attributes. e.g. <div profile="http://example.com/vocab"> <span property="foo:bar">foo bar</span> </div> If example.com is down, the parser has no way of determin... On Thu, 2010-03-11 at 15:39 -0800, Ben Adida wrote: > I'm still worried about inheriting prefixes from @profile, so I'm not > sure we have consensus just yet. The other problem is that it introduces a conflict with full URIs in attributes. e.g. <div profile="http://example.com/vocab"> <span property="foo:bar">foo bar</span> </div> If example.com is down, the parser has no way of determining whether "foo" is a CURIE prefix defined by the profile, or a URI scheme. Using safe CURIEs, in the case where "foo" was intended as a CURIE prefix, there is a non-ambiguous form: <div profile="http://example.com/vocab"> <span property="[foo:bar]">foo bar</span> </div> However, advising authors to use safe CURIEs whenever a prefix was defined in a profile seems like it's going to cause confusion. And, if "foo" really was intended as a URI scheme, there's no "safe URI" syntax, so when the profile document is unavailable, it's impossible to unambiguously know what was intended. I think there are three ways out of this: 1. We don't allow profiles to define prefixes; 2. We abandon full URIs in CURIE attributes; or 3. We define a safe URI syntax and insist that safe CURIEs and safe URIs are used anywhere a profile is in scope. I really don't like #3, and I'd rather drop profiles' ability to define prefixes than drop full URIs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268386617.15904.60.camel%40ophelia2.g5n.co.uk Re: Does RDFa processing recurse into content:encoded? 2010-03-12T09:36:59 2010-03-12T09:36:59 2010-03-12T09:36:59 On Thu, 2010-03-11 at 16:30 -0500, Stephane Corlosquet wrote: > I gave a quick glance at the open issues [1] but I could not find any > on this topic, or this handled as part of another issue? As I see it there are two related questions: 1. Given a node that has no datatype attribute and non-textnode content, such as: <span property="ex:foobar">Albert <b>Einstein</b></span> Should RDFa 1.1 ge... On Thu, 2010-03-11 at 16:30 -0500, Stephane Corlosquet wrote: > I gave a quick glance at the open issues [1] but I could not find any > on this topic, or this handled as part of another issue? As I see it there are two related questions: 1. Given a node that has no datatype attribute and non-textnode content, such as: <span property="ex:foobar">Albert <b>Einstein</b></span> Should RDFa 1.1 generate an XMLLiteral (like RDFa 1.0 does), or generate a plain literal (like most people seem to prefer)? 2. When an XMLLiteral is generated, in RDFa 1.0 descendant elements are skipped for parsing. In RDFa 1.1, should we require descendant elements to be parsed, should we keep the RDFa 1.0 behaviour, or should we provide a mechanism for page authors to decide? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268392888.27851.13.camel%40ophelia2.g5n.co.uk Re: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments) 2010-03-12T11:21:30 2010-03-12T11:21:30 2010-03-12T11:21:30 On Thu, 2010-03-11 at 16:35 +0100, Julian Reschke wrote: > The other good news is that Firefox, IE and Chrome handle them the > same way, and that happens to be what makes most sense (IMHO) It makes sense from the "let's do the least work to harmonise this" point of view, but I don't think it makes a lot of sense from an end user point of view. Let's say that a long document is published as a s... On Thu, 2010-03-11 at 16:35 +0100, Julian Reschke wrote: > The other good news is that Firefox, IE and Chrome handle them the > same way, and that happens to be what makes most sense (IMHO) It makes sense from the "let's do the least work to harmonise this" point of view, but I don't think it makes a lot of sense from an end user point of view. Let's say that a long document is published as a series of pages: section1.html (containing #subsection1.1, #subsection1.2, etc) section2.html (containing #subsection2.1, #subsection2.2, etc) ... etc Later, it is realised that the document is not long enough to justify the split, so they're merged into a single page: all.html (containing #section1, #subsection1.1, etc) To prevent links from being broken a set of 302 Found redirects are established: section1.html -> all.html#section1 section2.html -> all.html#section2 ... etc Now, imagine a user clicks on a link to <section1.html#subsection1.2>. Their browser requests <section1.html> and receives a 302 redirect to <all.html#section1>. Which part of the page does it make more sense to scroll the user down to? #section1 or #subsection1.2? I would argue the latter. The server could have redirected the browser to the latter fragment itself, if only it had known the fragment part of the user's original request (though of course it can't, as the fragment isn't sent over the wire in the request). The Firefox/IE/Chrome behaviour I would say perhaps makes sense in the case of 303 See Other. A 303 response indicates that the resource in the Location header is a separate resource; a 302 response indicates that the resource in the Location header is the same resource that was requested, just in a different place. So with 302 responses, there should be an expectation that fragment identifiers in the originally requested resource match any fragment identifiers in the resource from the Location header. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268593112.27851.16.camel%40ophelia2.g5n.co.uk Re: Notes on "RDFa For Turtles" 2010-03-14T18:58:32 2010-03-14T18:58:32 2010-03-14T18:58:32 On Fri, 2010-03-12 at 10:21 -0500, Paul Houle wrote: > I think the differential use of href and resource here maximizes > backwards and forwards compatibility. It is non-conformant to use > legacy link/@rel elements if @about is not set in the <html> element. > Also, > > <link about=”{any_subject}” rel=”{reserved_value}” href=”{object}”> > <link about=”{any_subject}” rel=”{reserved_value}” href=... On Fri, 2010-03-12 at 10:21 -0500, Paul Houle wrote: > I think the differential use of href and resource here maximizes > backwards and forwards compatibility. It is non-conformant to use > legacy link/@rel elements if @about is not set in the <html> element. > Also, > > <link about=”{any_subject}” rel=”{reserved_value}” href=”{object}”> > <link about=”{any_subject}” rel=”{reserved_value}” href=”{object}”> > > Is disallowed because legacy clients could misinterpret it. If we > want to assert predicates such as “alternate”, “cite” about documents > that are not the present document, we need to add a namespace > declaration like > > xmlns:xhv=”http://www.w3.org/1999/xhtml/vocab#” > > and then write the predicate as a CURIE: > > <link about=”{any_subject}” rel=”xhv:{reserved_value}” > resource=”{object}”> In understand this concern, but there's no need to use xhtml:xhv. Legacy clients can be worked around using: <link about="{subject}" rel=":license" resource="{object}" /> Note the leading colon for the rel token. RDFa processors automatically interpret any CURIE with a leading colon as being prefixed <http://www.w3.org/1999/xhtml/vocab#>. It's a trick I often use if I think legacy clients will misunderstand something. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268593494.27851.21.camel%40ophelia2.g5n.co.uk Re: SPARQL: sorting resources by label? 2010-03-14T19:04:55 2010-03-14T19:04:55 2010-03-14T19:04:55 On Sat, 2010-03-13 at 04:16 +0100, Axel Rauschmayer wrote: > > OPTIONAL { > > ?subj ?labelPred ?label . > > FILTER ( > > (?labelPred = > > <http://www.w3.org/2000/01/rdf-schema#label>) # (1) > > ) > > FILTER( isLiteral(?label) ) > > } I use something like: OPTIONAL { ?subject ?labelprop ?label . GRAPH <http://buzzword... On Sat, 2010-03-13 at 04:16 +0100, Axel Rauschmayer wrote: > > OPTIONAL { > > ?subj ?labelPred ?label . > > FILTER ( > > (?labelPred = > > <http://www.w3.org/2000/01/rdf-schema#label>) # (1) > > ) > > FILTER( isLiteral(?label) ) > > } I use something like: OPTIONAL { ?subject ?labelprop ?label . GRAPH <http://buzzword.org.uk/2009/label-properties> { ?labelprop a <http://buzzword.org.uk/2009/label-properties#LabelProperty> . } FILTER( isLiteral(?label) ) } Having first loaded http://buzzword.org.uk/2009/label-properties into the store. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268597916.27851.49.camel%40ophelia2.g5n.co.uk Re: SPARQL: sorting resources by label? 2010-03-14T20:18:36 2010-03-14T20:18:36 2010-03-14T20:18:36 On Sun, 2010-03-14 at 21:01 +0100, Danny Ayers wrote: > On 14 March 2010 20:04, Toby Inkster <tai@g5n.co.uk> wrote: > > > I use something like: > > > > OPTIONAL { > > ?subject ?labelprop ?label . > > GRAPH <http://buzzword.org.uk/2009/label-properties> { > > ?labelprop a > <http://buzzword.org.uk/2009/label-properties#LabelProperty> . > > } > > ... On Sun, 2010-03-14 at 21:01 +0100, Danny Ayers wrote: > On 14 March 2010 20:04, Toby Inkster <tai@g5n.co.uk> wrote: > > > I use something like: > > > > OPTIONAL { > > ?subject ?labelprop ?label . > > GRAPH <http://buzzword.org.uk/2009/label-properties> { > > ?labelprop a > <http://buzzword.org.uk/2009/label-properties#LabelProperty> . > > } > > FILTER( isLiteral(?label) ) > > } > > > > Having first loaded > http://buzzword.org.uk/2009/label-properties into > > the store. > > I like your idea of wrapping all the label properties up, but don't > you need to run subproperty inference before the query will work? Assuming that the label property being used is listed at http://buzzword.org.uk/2009/label-properties, then it works without any inferencing. If the label property being used is a rdfs:subPropertyOf or owl:equivalentProperty of one of the listed properties, then, yes, inferencing is needed of course. But frankly, anybody using a labelling property that's not listed there deserves everything they get! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268767076.32423.38.camel%40ophelia2.g5n.co.uk Re: Another way other than @profile, @vocab or @map 2010-03-16T19:17:58 2010-03-16T19:17:58 2010-03-16T19:17:58 On Tue, 2010-03-16 at 14:38 +0000, Martin McEvoy wrote: > With all the above in mind, RDFa could I think re-use an attribute > name that already exists in htm5, microdata to be more precise > "itemtype"[1]. RDFa could be used pretty much like microdata eg: > > <div itemtype="http://www.w3.org/2006/vcard/ns#" about="#BusinessEntity" > typeof="VCard"> > <div property="fn">L'Amourita Pizza</div> >... On Tue, 2010-03-16 at 14:38 +0000, Martin McEvoy wrote: > With all the above in mind, RDFa could I think re-use an attribute > name that already exists in htm5, microdata to be more precise > "itemtype"[1]. RDFa could be used pretty much like microdata eg: > > <div itemtype="http://www.w3.org/2006/vcard/ns#" about="#BusinessEntity" > typeof="VCard"> > <div property="fn">L'Amourita Pizza</div> > <div rel="adr"> > <div typeof="Address"> > <span property="street-address">2040 Any Street</span>, > <span property="locality">Springfield</span>, > <span property="postal-code">98102</span>. > Tel: <span property="tel">206-555-7242</span>. > <span rel="url" resource="http://pizza.example.com/"></span> > </div> > </div> > </div> I like the general idea, but how about reusing typeof instead: <div typeof="http://www.w3.org/2006/vcard/ns#VCard" about="#BusinessEntity"> <div property="fn">L'Amourita Pizza</div> <div rel="adr"> <div typeof="Address"> <span property="street-address">2040 Any Street</span>, <span property="locality">Springfield</span>, <span property="postal-code">98102</span>. </div> </div> Tel: <span property="tel">206-555-7242</span>. <span rel="url" resource="http://pizza.example.com/"></span> </div> This should be pretty easy to make workable: whenever typeof contains a full URI (CURIE versus URI can be determined by checking whether xmlns:http has been declared yet), then it sets the default prefix (by trimming back to the last non-QName character - in the example above '#') for unprefixed tokens. In the case where typeof contains multiple tokens (space-separated), then the first one wins. This may well be more author-friendly than external profiles; plus it's going to make parsing a bit faster, not needing to dereference external files. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1268783656.32423.315.camel%40ophelia2.g5n.co.uk Re: Telecon Agenda - 18th March 2010, 1500 UTC 2010-03-16T23:54:18 2010-03-16T23:54:18 2010-03-16T23:54:18 On Tue, 2010-03-16 at 09:46 -0400, Manu Sporny wrote: > WARNING: The annoyingly complicated world-wide ritual known as > Daylight Saving Time is in effect in the USA. Not world-wide. There are plenty of places that don't do daylight savings - most places in the tropics don't. (In Australia, some states observe it and others do not!) I wish there were more places that ignored this silly ritual - i... On Tue, 2010-03-16 at 09:46 -0400, Manu Sporny wrote: > WARNING: The annoyingly complicated world-wide ritual known as > Daylight Saving Time is in effect in the USA. Not world-wide. There are plenty of places that don't do daylight savings - most places in the tropics don't. (In Australia, some states observe it and others do not!) I wish there were more places that ignored this silly ritual - if people want to get up an hour earlier in the summer, I'm OK with that - just don't pretend it's 7am when it's really 6. > Telecon times are at the same time in the USA - 9am EST. In the UK and > other countries that have not "sprung forward" yet, the telecon will > be one hour earlier for the next two weeks. Anyhow, as I mentioned on last week's call, I won't be able to make the 18th or 25th for this reason. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269006442.29519.262.camel%40ophelia2.g5n.co.uk Re: Another way other than @profile, @vocab or @map 2010-03-19T13:47:26 2010-03-19T13:47:26 2010-03-19T13:47:26 On Fri, 2010-03-19 at 12:21 +0000, Martin McEvoy wrote: > @profile in this way is behaving just the same as html4 profiles.. > > "As a globally unique name. User agents may be able to recognize the > name (without actually retrieving the profile) and perform some > activity based on known conventions for that profile" > > http://www.w3.org/TR/html401/struct/global.html#profiles > > In the case... On Fri, 2010-03-19 at 12:21 +0000, Martin McEvoy wrote: > @profile in this way is behaving just the same as html4 profiles.. > > "As a globally unique name. User agents may be able to recognize the > name (without actually retrieving the profile) and perform some > activity based on known conventions for that profile" > > http://www.w3.org/TR/html401/struct/global.html#profiles > > In the case of RDFa the "known conventions" would be setting the > default namespace for the document. Not quite the same. "name" in the quote above can be translated as "URI". So when it says: "user agents may be able to recognize the name" it means that user agents should only be doing this for URIs that they recognise. Unless I'm misunderstanding your suggestion, RDFa processors would be applying the profile as a default prefix whether or not they recognised the URI. I don't have anything against this general technique - but I don't think it's consistent with the HTML4/XHTML1.x definition of @profile, so a different attribute would need to be used. A lot of the debate here has been on the syntax and model for profile documents. Personally I don't think we've had enough debate on whether profile documents are needed at all - Martin's suggestion here is not to define a profile (in the sense that we've been talking about them) at all, but to just set the default CURIE prefix. What exactly are the use cases that show this to be insufficient? Personally, I don't think I've seen any yet. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269124995.8745.26.camel%40ophelia2.g5n.co.uk Re: Another way other than @profile, @vocab or @map 2010-03-20T22:43:18 2010-03-20T22:43:18 2010-03-20T22:43:18 On Fri, 2010-03-19 at 22:05 -0400, Manu Sporny wrote: > Mark's UK consultation work is one use case that demonstrates[1] that > mixing vocabularies to create RDFa Profiles/Argots are helpful. [...] > > Digital Bazaar (my company) would like to mix the Music Ontology with > the Good Relations Ontology in a way that bloggers could express music > for purchase without having to invent a new vocabula... On Fri, 2010-03-19 at 22:05 -0400, Manu Sporny wrote: > Mark's UK consultation work is one use case that demonstrates[1] that > mixing vocabularies to create RDFa Profiles/Argots are helpful. [...] > > Digital Bazaar (my company) would like to mix the Music Ontology with > the Good Relations Ontology in a way that bloggers could express music > for purchase without having to invent a new vocabulary, and making it > as easy to use (correctly) as a Microformat[3]. These are laudable goals, but in my mind not enough to justify the RDFa profiles approach. There's more than one way to do this. Let's take a simple case of mixing two well known RDF vocabularies: FOAF and Dublin Core. We wish to note that a foaf:Document has a dc:title. In RDFa 1.0, this might be: <html xmlns="http://www.w3.org/1999/xhtml" xmlns:dc="http://purl.org/dc/terms/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xml:lang="en"> <head typeof="foaf:Document"> <title property="dc:title">Foo</title> </head> ... </html> So, how could we allow these terms from different vocabularies to be used in RDFa 1.1 without as much fuss? Firstly, we define a mechanism for setting a default prefix - I'll use the attribute @vocab in this example: <html xmlns="http://www.w3.org/1999/xhtml" vocab="http://example.com/my-vocab#" xml:lang="en"> <head typeof="Document"> <title property="title">Foo</title> </head> </html> So what have we achieved? We end up with these two triples: <> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.com/my-vocab#Document> . <> <http://example.com/my-vocab#title> "Foo"@en . Not quite what we wanted, but still... suppose the vocab document at <http://example.com/my-vocab> contains the following triples: <http://example.com/my-vocab#Document> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://xmlns.com/foaf/0.1/Document> . <http://example.com/my-vocab#title> <http://www.w3.org/2000/01/rdf-schema#subPropertyOf> <http://purl.org/dc/terms/title> . Then by strapping an RDFS processor on to our RDFa pipeline, we can add the following two triples to our RDFa output: <> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Document> . <> <http://purl.org/dc/terms/title> "Foo"@en . Which were the triples we wanted. Yes, I realise RDFS reasoning is not necessarily a simple thing to implement, but given a choice between: 1. default prefixes: perform very RDFa1.0-like parsing, then, if you want to, perform (perhaps only limited) RDFS reasoning later on in the toolchain. 2. profiles: add recursive HTTP fetching, parsing and RDF querying to the RDFa parser itself. I'm still not convinced that #2 is really the simplest option. I'm not saying that I can't be convinced, just that I'm not convinced so far. Bundling multiples ontologies/vocabularies is a great idea, but @profile is not the only way to do it, and not necessarily the best way to do it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269285400.8745.42.camel%40ophelia2.g5n.co.uk Re: Another way other than @profile, @vocab or @map 2010-03-22T19:16:42 2010-03-22T19:16:42 2010-03-22T19:16:42 On Mon, 2010-03-22 at 06:38 -0400, Ivan Herman wrote: > - regardless of the difficulty of implementation, I myself regard > RDFa, from the SW point of view, as yet another standard serialization > of RDF. But, with an RDFS processing in the picture, that is not true > any more. This is a major step to take... It's not really my intention to suggest that RDFS inferencing should be built into RDFa ... On Mon, 2010-03-22 at 06:38 -0400, Ivan Herman wrote: > - regardless of the difficulty of implementation, I myself regard > RDFa, from the SW point of view, as yet another standard serialization > of RDF. But, with an RDFS processing in the picture, that is not true > any more. This is a major step to take... It's not really my intention to suggest that RDFS inferencing should be built into RDFa parsers. Rather a RDFa parser would produce a graph containing the uninferenced triples, which could then be handed over to an inferencer by the consumer (and this is the important bit...) if the consumer wants to. RDFa would remain a standard serialisation of RDF. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269471171.1205.10.camel%40ophelia2.g5n.co.uk Re: @vocab 2010-03-24T22:52:56 2010-03-24T22:52:56 2010-03-24T22:52:56 On Wed, 2010-03-24 at 13:07 -0400, Sebastian Heath wrote: > I am concerned about how any rdfa tokenizing mechanism will overlap > with the mechanism for defining new @rel values in HTML5. To be sure, > this is one of the weirder parts of the standard. Anybody can stick > anything http://wiki.whatwg.org/wiki/RelExtensions and it's a > candidate for being an official @rel value. How are parsers goi... On Wed, 2010-03-24 at 13:07 -0400, Sebastian Heath wrote: > I am concerned about how any rdfa tokenizing mechanism will overlap > with the mechanism for defining new @rel values in HTML5. To be sure, > this is one of the weirder parts of the standard. Anybody can stick > anything http://wiki.whatwg.org/wiki/RelExtensions and it's a > candidate for being an official @rel value. How are parsers going to > keep up with that? Let alone distinguish between those values and > default values. In January the HTMLWG reached a rough consensus to change this. Assuming that Mark Nottingham's link relation registry[1] gets off the ground, it seems fairly likely that HTML5 will switch to that. An IETF registry would probably be less of a moving target than a wiki, but all the same... it would move. ____ 1. http://tools.ietf.org/html/draft-nottingham-http-link-header-08#section-6.2 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269472450.1205.30.camel%40ophelia2.g5n.co.uk Re: Chat with Ivan on RDFa 1.1 Authoring features 2010-03-24T23:14:20 2010-03-24T23:14:20 2010-03-24T23:14:20 On Wed, 2010-03-24 at 16:47 -0400, Ivan Herman wrote: > What I said, to be more precise: if our goal is (and I think it is) to > simplify RDFa and bring it closer to HTML(5) authors, then we should > keep away from RDFS. We would shoot ourselves in the foot in the sense > that it would make RDFa more complex conceptually, something we do not > want to do... (sorry Toby:-) As I've said, I'm not s... On Wed, 2010-03-24 at 16:47 -0400, Ivan Herman wrote: > What I said, to be more precise: if our goal is (and I think it is) to > simplify RDFa and bring it closer to HTML(5) authors, then we should > keep away from RDFS. We would shoot ourselves in the foot in the sense > that it would make RDFa more complex conceptually, something we do not > want to do... (sorry Toby:-) As I've said, I'm not suggesting that RDFa includes RDFS/OWL. (I had previously suggested this though.) My suggestion is that RDFa does not need to contain a profile feature - all it needs to do is provide a way of setting a default prefix. This would enable Google, say, to recommend publishing data like this: <p vocab="http://rdf.data-vocabulary.org/#" typeof="Person"> <a property="name" rel="url" href="/">Toby Inkster</a> </p> i.e. as they currently do, but without prefixes. The default prefix (indeed, non-default prefixes too) *may* be dereferenced to find an RDF schema, which might result in the consumer being able to infer additional triples. But that's a consideration orthogonal to RDFa 1.1. (After all, RDFS and OWL reasoning like that can already be conducted on existing RDFa 1.0 documents if the consumer chooses to do so.) No, this suggestion is not as powerful as RDFa profiles, but the use of profiles introduces fragility into RDFa documents, and I'm not convinced that the use cases suggested so far justify taking the risk with them. Whatsmore, I think that my suggestion leaves us room for adding profiles in a future version of RDFa without changing the syntax. (You'd just tell RDFa parsers to start performing profile processing on the URIs given in @vocab.) Jumping straight to profiles doesn't allow us a natural path back from them if they turn out to be a mistake. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269511873.1205.43.camel%40ophelia2.g5n.co.uk Re: Chat with Ivan on RDFa 1.1 Authoring features 2010-03-25T10:11:16 2010-03-25T10:11:16 2010-03-25T10:11:16 On Thu, 2010-03-25 at 00:53 +0100, Melvin Carvalho wrote: > Quick question: does the @vocab proposal allow multiple occurrences > with more and less specific meaning? The analogy I'm thinking of is > @style in CSS... Think more like @lang in HTML. Language-tagged elements can be nested inside each other fine, but for any given piece of text, there is only ever at most one language in scope. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2010-03-25 at 00:53 +0100, Melvin Carvalho wrote: > Quick question: does the @vocab proposal allow multiple occurrences > with more and less specific meaning? The analogy I'm thinking of is > @style in CSS... Think more like @lang in HTML. Language-tagged elements can be nested inside each other fine, but for any given piece of text, there is only ever at most one language in scope. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269595982.16154.13.camel%40ophelia2.g5n.co.uk Re: New version of @profile and @vocab 2010-03-26T09:33:06 2010-03-26T09:33:06 2010-03-26T09:33:06 On Thu, 2010-03-25 at 15:55 -0400, Ivan Herman wrote: > Having read the minutes of the 2010-03-25, I have committed a new > version of the document: > > http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100326/ A few editorial issues: * In section 2 there is a property which seems to be inconsistently referred to as 'uri' and 'URI'. In the accompanying Turtle file, it's 'URI'. I'd suggest ... On Thu, 2010-03-25 at 15:55 -0400, Ivan Herman wrote: > Having read the minutes of the 2010-03-25, I have committed a new > version of the document: > > http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100326/ A few editorial issues: * In section 2 there is a property which seems to be inconsistently referred to as 'uri' and 'URI'. In the accompanying Turtle file, it's 'URI'. I'd suggest using 'uri' consistently, as RDF vocabularies tend to use lower case for properties. * In the Turtle file you use owl:functionalProperty which should have a capital 'F'. * In the Turtle file and the document, you assert that the domain of 'keyword' is 'PrefixMapping' - it should be 'KeywordMapping'. * In the Turtle file and the document, you use rdfs:PrefixMapping instead of rdfa:PrefixMapping. And some non-editorial ones: * Nothing is said about whether keyword and prefix mappings are case-sensitive or not. RDFa 1.0 keywords are case-insensitive. * If rdfa:uri is an owl:FunctionalProperty it rules out this: [ a rdfa:KeywordMapping ; rdfa:keyword "name" ; rdfa:uri foaf:name ; rdfa:uri rdfs:label ] . I think it would be very nice for keywords to be expandable to multiple terms. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269610902.16154.36.camel%40ophelia2.g5n.co.uk Re: New version of @profile and @vocab 2010-03-26T13:41:44 2010-03-26T13:41:44 2010-03-26T13:41:44 On Fri, 2010-03-26 at 05:51 -0400, Ivan Herman wrote: > That I do not understand. Do you mean that the same keyword would > automatically generate several URI-s, ie, would generate several > triples? This is certainly not the way I envisaged that... Precisely. It's not the way I'd envisaged it either, but if we do end up with @profile as an RDFa 1.1 feature, it doesn't seem too difficult to im... On Fri, 2010-03-26 at 05:51 -0400, Ivan Herman wrote: > That I do not understand. Do you mean that the same keyword would > automatically generate several URI-s, ie, would generate several > triples? This is certainly not the way I envisaged that... Precisely. It's not the way I'd envisaged it either, but if we do end up with @profile as an RDFa 1.1 feature, it doesn't seem too difficult to implement keywords so that they can expand to multiple URIs. I can even imagine something like: @prefix iana: <http://www.iana.org/assignments/relation/> . @prefix rdfa: <http://www.w3.org/ns/rdfa#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xhv: <http://www.w3.org/1999/xhtml/vocab#> . [ a rdfa:KeywordMapping ; rdfa:keyword "nextdoc" ; rdfa:uri xhv:next, iana:next, rdfs:seeAlso ; rdfa:reverse_uri xhv:prev , iana:prev , rdfs:seeAlso ] . So that this: <a about="doc1" rel="nextdoc" href="doc2">next</a> Would generate: @prefix iana: <http://www.iana.org/assignments/relation/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xhv: <http://www.w3.org/1999/xhtml/vocab#> . <doc1> iana:next <doc2> ; xhv:next <doc2> ; rdfs:seeAlso <doc2> . <doc2> iana:prev <doc1> ; xhv:prev <doc1> ; rdfs:seeAlso <doc1> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269648663.16154.52.camel%40ophelia2.g5n.co.uk Re: A rose by any other name is just as thorny... 2010-03-27T00:11:04 2010-03-27T00:11:04 2010-03-27T00:11:04 On Fri, 2010-03-26 at 17:32 -0400, Ivan Herman wrote: > - there _is_ a default @vocab, conceptually set on the <html> element, > which is set to the value of "http://www.w3.org/1999/xhtml/vocab#". This would result in rel="next" and rel="NEXT" generating different predicates. In RDFa 1.0 they generate the same predicate. Quick question: what about CURIEs of the form ":foo" which are currently e... On Fri, 2010-03-26 at 17:32 -0400, Ivan Herman wrote: > - there _is_ a default @vocab, conceptually set on the <html> element, > which is set to the value of "http://www.w3.org/1999/xhtml/vocab#". This would result in rel="next" and rel="NEXT" generating different predicates. In RDFa 1.0 they generate the same predicate. Quick question: what about CURIEs of the form ":foo" which are currently expanded using the prefix <http://www.w3.org/1999/xhtml/vocab#>? Are those also effected by @vocab, or do they remain grounded in the XHTML vocabulary? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269685901.27948.1.camel%40ophelia2.g5n.co.uk Re: A rose by any other name is just as thorny... 2010-03-27T10:31:45 2010-03-27T10:31:45 2010-03-27T10:31:45 On Fri, 2010-03-26 at 23:27 -0500, Shane McCarron wrote: > Toby Inkster wrote: > > On Fri, 2010-03-26 at 17:32 -0400, Ivan Herman wrote: > > > > > - there _is_ a default @vocab, conceptually set on the <html> element, > > > which is set to the value of "http://www.w3.org/1999/xhtml/vocab#". > > > > This would result in rel="next" and rel="NEXT" generating different > > predicates. In RDFa 1.... On Fri, 2010-03-26 at 23:27 -0500, Shane McCarron wrote: > Toby Inkster wrote: > > On Fri, 2010-03-26 at 17:32 -0400, Ivan Herman wrote: > > > > > - there _is_ a default @vocab, conceptually set on the <html> element, > > > which is set to the value of "http://www.w3.org/1999/xhtml/vocab#". > > > > This would result in rel="next" and rel="NEXT" generating different > > predicates. In RDFa 1.0 they generate the same predicate. > > > Why? Surely we can just declare that keywords are always > case-insensitive... or, more likely, always mapped to lower-case. But @vocab isn't used for loading keywords (that's @profile) - it's used for setting the default prefix. If CURIEs in the default prefix are always mapped to lower-case, then things like <div vocab="http://xmlns.com/foaf/0.1/" typeof="Person"> won't work. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269767600.14672.2.camel%40ophelia2.g5n.co.uk Re: A rose by any other name is just as thorny... 2010-03-28T09:13:22 2010-03-28T09:13:22 2010-03-28T09:13:22 On Sat, 2010-03-27 at 21:29 -0400, Manu Sporny wrote: > We may want to say that rel/rev are always mapped to lower-case since > they are legacy attributes. Everything else is case-sensitive. Assuming we're just talking about rel/rev values that do not contain a colon, I could support that. It does break e.g. <a vocab="http://xmlns.com/foaf/0.1/" rel="primaryTopic" ...> and <a vocab="http://www.w3.org/2000/01/rdf-schema#" rel="seeAlso" ...> though. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 2010-03-27 at 21:29 -0400, Manu Sporny wrote: > We may want to say that rel/rev are always mapped to lower-case since > they are legacy attributes. Everything else is case-sensitive. Assuming we're just talking about rel/rev values that do not contain a colon, I could support that. It does break e.g. <a vocab="http://xmlns.com/foaf/0.1/" rel="primaryTopic" ...> and <a vocab="http://www.w3.org/2000/01/rdf-schema#" rel="seeAlso" ...> though. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269870120.3257.12.camel%40ophelia2.g5n.co.uk Re: RDFa Core and RDF/XML 2010-03-29T13:42:01 2010-03-29T13:42:01 2010-03-29T13:42:01 On Mon, 2010-03-29 at 13:04 +0200, Ivan Herman wrote: > Let us suppose I have a general XML application, using namespaces. I > use RDFa 1.1 in there, that can be used to generate RDF triples. > However, because that is a namespace aware XML application, it is > perfectly feasible that the user includes an RDF/XML portion into the > XML file, too. The question is: are the triples described by that ... On Mon, 2010-03-29 at 13:04 +0200, Ivan Herman wrote: > Let us suppose I have a general XML application, using namespaces. I > use RDFa 1.1 in there, that can be used to generate RDF triples. > However, because that is a namespace aware XML application, it is > perfectly feasible that the user includes an RDF/XML portion into the > XML file, too. The question is: are the triples described by that > RDF/XML part of what the RDFa processor produces or not? Ie, should > the RDFa processor take that RDF/XML portion, parse it and add those > triples to the generated Graph? My RDFa parser has three options that it can take when it sees RDF/XML in a document: * It can plough straight through it, and if any RDFa is found within it (say in an XML literal), then these will be parsed in the same way that they would be anywhere in the document. * It can skip over the element, ignoring its contents. * It can parse the RDF/XML (or rather it calls another Perl module to do the job). Although @xml:base is ignored for resolving relative URIs in RDFa, my parser does look at this attribute so that it can pass the base URI on to the RDF/XML parser. (There's also an option to allow <base href> to be used as a fallback base URI for the RDF/XML.) It also passes the @xml:lang attribute on. By default, RDFa triples and RDF/XML triples are added to the same graph, though there is a multi-graph mode where each RDF/XML chunk is added to a different graph. As you can tell from the above description, the parser has a number of different options that the consumer can fiddle with. For convenience, a few default sets of options are provided. The default set of options for XHTML takes the first route with RDF/XML, ploughing straight through it. The default for SVG parses the RDF/XML, as do the defaults for Atom and generic XML. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1269885632.3257.19.camel%40ophelia2.g5n.co.uk Re: A rose by any other name is just as thorny... 2010-03-29T18:00:34 2010-03-29T18:00:34 2010-03-29T18:00:34 On Mon, 2010-03-29 at 09:13 -0500, Shane McCarron wrote: > Actually, I disagree. The current discussion was around ensuring this > is backward compatible for existing documents. If I reference a new > 'default vocabulary' then I have switched contexts. Clearly I am not > writing an RDFa 1.0 document, I am working in the context of RDFa 1.1. > New rules apply. Backward compatibility has to be... On Mon, 2010-03-29 at 09:13 -0500, Shane McCarron wrote: > Actually, I disagree. The current discussion was around ensuring this > is backward compatible for existing documents. If I reference a new > 'default vocabulary' then I have switched contexts. Clearly I am not > writing an RDFa 1.0 document, I am working in the context of RDFa 1.1. > New rules apply. Backward compatibility has to be our first priority. > But as soon as a document switches contexts, I think the author has > chosen to by in an RDFa 1.1 world where 'CURIES with no prefix' are > interpreted as 'terms' in some other vocabulary. There are two types of compatibility at stake here: 1. Do RDFa 1.0 documents work in RDFa 1.1 processors? 2. Do RDFa 1.1 documents work in RDFa 1.0 processors? Clearly this issue doesn't affect compatibility #1 as no RDFa 1.0 conformant document will contain the @vocab attribute necessary to switch default prefix. However, it does affect compatibility #2. Of course we can't expect RDFa 1.0 processors to fully understand RDFa 1.1 - that would mean that the revision of RDFa would have to essentially be a no-op. But we can design RDFa 1.1 such that any new features will be entirely ignored by an RDFa 1.0 processor - that is, the RDFa 1.0 processor sees a subset of the default graph produced by an RDFa 1.1 processor. Allowing the RDFa 1.0 keywords to be redefined by @vocab or @profile does affect compatibility between RDFa 1.0 and RDFa 1.1. I'm not saying that it mustn't be done, but merely that we should be careful in doing so. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/907f01719e3e423f348d985d31f37bbe.squirrel%40goddamn.co.uk Re: swig telecons? 2010-03-31T09:53:24 2010-03-31T09:53:24 2010-03-31T09:53:24 > If we started having regular Semantic Web Interest Group telecons, would > you attend? What would you expect/hope to get out of it? Personally, I don't think telecons are the most productive way to collaborate. Too much time is spent on administrivia and deciding whose turn it is to speak next. What I'd rather see is scheduled IRC chats on #swig (which is already a fairly active channel). A ... > If we started having regular Semantic Web Interest Group telecons, would > you attend? What would you expect/hope to get out of it? Personally, I don't think telecons are the most productive way to collaborate. Too much time is spent on administrivia and deciding whose turn it is to speak next. What I'd rather see is scheduled IRC chats on #swig (which is already a fairly active channel). A topic could be circulated on this mailing list a week in advance, then we'd turn up on IRC at the scheduled start time. There would be no scheduled finish time - the discussion would continue until either the problem was solved, or everyone was sufficiently bored with the topic at hand. Chat topics should be a nice mix of the theoretical and practical. It would be nice to have outcomes like "OK, my company will release our library that does this funky thing as open source" or "OK, I'll get one of my students to work on plugging RDFa output into this web app". -Toby http://tobyinkster.co.uk/message/1270113210.11889.2.camel%40ophelia2.g5n.co.uk Re: Complexity of RDFa 2010-04-01T09:13:32 2010-04-01T09:13:32 2010-04-01T09:13:32 On Thu, 2010-04-01 at 10:07 +0100, Mark Birbeck wrote: > I've Googled around to see if people already use this technique, but > although I can't find anything, I'd be really surprised if someone, > somewhere, hadn't tried it. Martin Hepp and I had a discussion about this technique on one of the W3C mailing lists a little while ago. This wiki page emerged from the discussion: http://esw.w3.org/N3inHTML -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2010-04-01 at 10:07 +0100, Mark Birbeck wrote: > I've Googled around to see if people already use this technique, but > although I can't find anything, I'd be really surprised if someone, > somewhere, hadn't tried it. Martin Hepp and I had a discussion about this technique on one of the W3C mailing lists a little while ago. This wiki page emerged from the discussion: http://esw.w3.org/N3inHTML -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1270113863.11889.13.camel%40ophelia2.g5n.co.uk RE: Complexity of RDFa 2010-04-01T09:24:23 2010-04-01T09:24:23 2010-04-01T09:24:23 On Thu, 2010-04-01 at 10:46 +0200, Hondros, Constantine wrote: > <> a cw:LawFragment; > cw:infoClass cw:LegislationRegulation; > ltr:referenceInformation _:b0 . > _:b0 a ltr:ReferenceInformation; officialPublication > <http://some.uri>; ltr:applicablePeriod _:b1 . > _b:1 a ltr:ApplicablePeriod ; cw:startDate > "2009-04-24T00:00:00+01:00"^^xsd:date... On Thu, 2010-04-01 at 10:46 +0200, Hondros, Constantine wrote: > <> a cw:LawFragment; > cw:infoClass cw:LegislationRegulation; > ltr:referenceInformation _:b0 . > _:b0 a ltr:ReferenceInformation; officialPublication > <http://some.uri>; ltr:applicablePeriod _:b1 . > _b:1 a ltr:ApplicablePeriod ; cw:startDate > "2009-04-24T00:00:00+01:00"^^xsd:dateTime ; cw:endDate > "2010-04-24T00:00:00+01:00"^^xsd:dateTime . > > I see real complexity trying to represent this inline with RDFa. For > example, the date literals will certainly be in the body of the > document, so should I create a typed blank node in situ, and reference > it from the more general metadata in the top of the document? <body typeof="cw:LawFragment" xmlns:cw="http://example.com/cw#" xmlns:ltr="http://example.com/ltr#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <h1> <span rel="cw:infoClass" resource="[cw:LegislationRegulation]">Legislation Regulation:</span> number 123 </h1> <p rel="ltr:referenceInformation"> Official publication: <a rel="ltr:officialPublication" href="http://example.com/some.uri">http://example.com/some.uri</a> <br rel="rdf:type" resource="[ltr:ReferenceInformation]" /> <span rel="lrt:applicablePeriod">( <span rel="rdf:type" resource="[ltr:ApplicablePeriod]" property="cw:startDate" datatype="xsd:dateTime" content="2009-04-24T00:00:00+01:00">24/04/09</span> until <span property="cw:startDate" datatype="xsd:dateTime" content="2010-04-24T00:00:00+01:00">24/04/10</span> )</span> </p> </body> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1270143834.11889.20.camel%40ophelia2.g5n.co.uk Re: RDFa DOM API commited to CVS 2010-04-01T17:43:56 2010-04-01T17:43:56 2010-04-01T17:43:56 On Thu, 2010-04-01 at 15:31 +0200, Benjamin Adrian wrote: > Should the API provide some CONSTANTS for popular URI references > (e.g., from Dublin Core, FOAF ) ? I think that if RDFa 1.1 predefines some prefixes, then the API should provide constants for those, but otherwise no. Possible exception would be the XHTML vocab. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2010-04-01 at 15:31 +0200, Benjamin Adrian wrote: > Should the API provide some CONSTANTS for popular URI references > (e.g., from Dublin Core, FOAF ) ? I think that if RDFa 1.1 predefines some prefixes, then the API should provide constants for those, but otherwise no. Possible exception would be the XHTML vocab. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1270144852.11889.36.camel%40ophelia2.g5n.co.uk Subclassing literals in RDFa API 2010-04-01T18:00:55 2010-04-01T18:00:55 2010-04-01T18:00:55 I'm a big fan of adding optional bits to specs. I'm an implementer, so I like optional bits because optional bits tend to be the bits where implementers can have some fun. So what I'm proposing is an optional bit. Where the RDFa API would normally return an object of type RDFLiteral, it should be allowed to return an object of some other type that implements the RDFLiteral interface. If we imagi... I'm a big fan of adding optional bits to specs. I'm an implementer, so I like optional bits because optional bits tend to be the bits where implementers can have some fun. So what I'm proposing is an optional bit. Where the RDFa API would normally return an object of type RDFLiteral, it should be allowed to return an object of some other type that implements the RDFLiteral interface. If we imagine an RDFa API implementation in a language that supports multiple inheritance, a literal with datatype xsd:dateTime might be returned as an object that's a subclass of RDFLiteral, and also a subclass of the programming language's native datetime object. Or in a language which doesn't do multiple inheritance, it the same literal might be represented as a subclass of RDFLiteral with an extra attribute called "datetime" that contains a copy of the datetime in the programming language's native datetime object. I can imagine implementations wanting to provide such subclasses for types xsd:dateTime (and other XSD date- and time-related datatypes), rdf:XMLLiteral and xsd:anyURI, though I'm not suggesting this option be restricted only to those - if an implementation wants to be able to do something special with xsd:unsignedByte, then why not let it? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1270193538.11889.51.camel%40ophelia2.g5n.co.uk Re: New Issue: Allowing extension of RDFa Core 2010-04-02T07:32:21 2010-04-02T07:32:21 2010-04-02T07:32:21 On Thu, 2010-04-01 at 18:41 -0500, Shane McCarron wrote: > Obviously, it would make some sense for @role to be able to generate > triples that could be used to help find specific roles in resources. > I doubt that spinbutton is particularly interesting, but 'definition', > 'contentinfo', and 'main' are probably low hanging fruit for a > semantic web inference engine ( <http://example.com/somedocu... On Thu, 2010-04-01 at 18:41 -0500, Shane McCarron wrote: > Obviously, it would make some sense for @role to be able to generate > triples that could be used to help find specific roles in resources. > I doubt that spinbutton is particularly interesting, but 'definition', > 'contentinfo', and 'main' are probably low hanging fruit for a > semantic web inference engine ( <http://example.com/somedocument.html> > <xhv:main> <http://example.com/somedocument.html#fragmentID> ). > [...] > So, that's the question. Does it make sense to try to introduce this > type of hook? If we had one, would we also need a way of indicating > (perhaps in a Host Language RDFa Profile document) what attributes > hooked in where? Sort of an 'instruction to the RDFa Processor'? I think it does make sense. It would allow, say, HTML+RDFa to allow @data to set a subject URI like @src does. (@data of course being an attribute on the <object> element.) Or HTML+RDFa to treat @datetime to provide a literal object on <time> elements. However, unless the hooks are very convoluted, I don't think they would solve the @role use case. @role would probably want the subject and object of the triple to be calculated differently. For example: <div role="main" id="foo">...</div> Ought to generate a triple along the lines of: <> xhv:main <#foo> . i.e. forcing the subject to be the document's base URI regardless of the current RDFa subject (e.g. @about on a parent element), and using @id to set the object resource, even though @id is entirely ignored by current processing rules. A host language that included RDFa and the Role Attribute Module (e.g. XHTML 1.2) would probably want to specify a method for extracting @role triples separately from RDFa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1270309526.1532.10.camel%40ophelia2.g5n.co.uk Re: @href and @src in RDFa 1.1 Core (Re: Editor's Drafts Updated) 2010-04-03T15:45:27 2010-04-03T15:45:27 2010-04-03T15:45:27 On Sat, 2010-04-03 at 10:23 -0500, Shane McCarron wrote: > Well - on this point I guess I could agree. Actually, I have always > thought the rules were wrong. I would prefer that we remove them > altogether, instead saying that @about defaults to "" at the start of > processing and inherits down. I can't remember why we didn't do that > in the first place - it makes no sense to me. About th... On Sat, 2010-04-03 at 10:23 -0500, Shane McCarron wrote: > Well - on this point I guess I could agree. Actually, I have always > thought the rules were wrong. I would prefer that we remove them > altogether, instead saying that @about defaults to "" at the start of > processing and inherits down. I can't remember why we didn't do that > in the first place - it makes no sense to me. About the only good thing about the current <head>/<body> rule is that you can do this: <body typeof="foaf:Document"> and it doesn't create a bnode. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/ca639a33375ab0de6c9628254f2ff3ec.squirrel%40goddamn.co.uk [Fwd: CPAN as linked data] 2010-04-07T14:20:25 2010-04-07T14:20:25 2010-04-07T14:20:25 ---------------------------- Original Message ---------------------------- Subject: CPAN as linked data From: "Toby Inkster" <mail@tobyinkster.co.uk> Date: Wed, April 7, 2010 3:18 pm To: dev@lists.perlrdf.org -------------------------------------------------------------------------- This lunch time I threw together a quick Linked Data wrapper around CPAN::SQLite. Example author: ht... ---------------------------- Original Message ---------------------------- Subject: CPAN as linked data From: "Toby Inkster" <mail@tobyinkster.co.uk> Date: Wed, April 7, 2010 3:18 pm To: dev@lists.perlrdf.org -------------------------------------------------------------------------- This lunch time I threw together a quick Linked Data wrapper around CPAN::SQLite. Example author: http://purl.org/NET/cpan-uri/person/gwilliams Example distribution: http://purl.org/NET/cpan-uri/dist/RDF-Trine/project Example version: http://purl.org/NET/cpan-uri/dist/RDF-Trine/v_0-118 If you visit the page of a version that cannot be found on CPAN, then the wrapper naively assumes that it does/will/did exist, so serves up a page anyway: http://purl.org/NET/cpan-uri/dist/RDF-Trine/v_9-999 If module authors use Module::Install::DOAPChangeSets and include a Changes.ttl file in their distribution, then the project data will automatically pick up data from Changes.ttl: http://purl.org/NET/cpan-uri/dist/RDF-TrineShortcuts/project The Changes.ttl files for RDF-TrineShortcuts v0.06 and for Module-Install-DOAPChangeSets v0.04 itself are considered good examples of how to write Changes.ttl files. -Toby http://tobyinkster.co.uk/message/10d179c250dc088bc3f18a3203f28838.squirrel%40goddamn.co.uk Re: mailing-lists in semantic-land 2010-04-07T15:21:08 2010-04-07T15:21:08 2010-04-07T15:21:08 > Or are we simply talking about publishing mailing lists as RDF/Linked > Data? I use this: http://goddamn.co.uk/viewvc/misc/mbox2rdf/mbox2rdf.pl -Toby > Or are we simply talking about publishing mailing lists as RDF/Linked > Data? I use this: http://goddamn.co.uk/viewvc/misc/mbox2rdf/mbox2rdf.pl -Toby http://tobyinkster.co.uk/message/1270750230.29423.220.camel%40ophelia2.g5n.co.uk Re: ISSUE-21: It will be hard to tell where a prefix comes from 2010-04-08T18:10:32 2010-04-08T18:10:32 2010-04-08T18:10:32 On Thu, 2010-04-08 at 14:15 +0000, RDFa Working Group Issue Tracker wrote: > ISSUE-21: It will be hard to tell where a prefix comes from > > http://www.w3.org/2010/02/rdfa/track/issues/21 Further, for: <div profile="http://example.com/p" typeof="foaf:Person"> <h1 property="foaf:name">Joe Bloggs</h1> <p property="http://example.com/foo">Bar</p> </div> If the profile defines "foaf" to point ... On Thu, 2010-04-08 at 14:15 +0000, RDFa Working Group Issue Tracker wrote: > ISSUE-21: It will be hard to tell where a prefix comes from > > http://www.w3.org/2010/02/rdfa/track/issues/21 Further, for: <div profile="http://example.com/p" typeof="foaf:Person"> <h1 property="foaf:name">Joe Bloggs</h1> <p property="http://example.com/foo">Bar</p> </div> If the profile defines "foaf" to point to the usual prefix, then it should result in the following triples: _:x a <http://xmlns.com/foaf/0.1/Person> . _:x <http://xmlns.com/foaf/0.1/name> "Joe Bloggs" . _:x <http://example.com/foo> "Bar" . However, if the profile document returns a 404, then it results in: _:x a <foaf:Person> . _:x <foaf:name> "Joe Bloggs" . _:x <http://example.com/foo> "Bar" . i.e. the prefix "foaf:" is treated as a URI scheme, not a CURIE prefix. Using profiles to define plain terms (not prefixes): <div profile="http://example.com/p" typeof="Person"> <h1 property="name">Joe Bloggs</h1> <p property="http://example.com/foo">Bar</p> </div> If the profile document is unavailable, this generation of weird triples doesn't happen - the typeof=Person and property=name triples simply disappear and you end up with a simple subset of the intended graph: _:x <http://example.com/foo> "Bar" . So the wider issue is that if a profile document disappears it's impossible to even distinguish between a non-safe CURIE and a full URI. So allowing CURIE prefixes to be defined by profiles threatens our ability to permit full URIs in the previously CURIE-only attributes. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1270751666.29423.221.camel%40ophelia2.g5n.co.uk Re: Fwd: I-D Action:draft-nottingham-http-link-header-09.txt 2010-04-08T18:34:30 2010-04-08T18:34:30 2010-04-08T18:34:30 On Sat, 2010-04-03 at 10:10 -0700, Mark Nottingham wrote: > http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-09.txt I can't believe I've only just noticed this, but: registered link types are no longer URIs?! That sucks! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 2010-04-03 at 10:10 -0700, Mark Nottingham wrote: > http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-09.txt I can't believe I've only just noticed this, but: registered link types are no longer URIs?! That sucks! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1270805772.29423.232.camel%40ophelia2.g5n.co.uk suggested test for test suite: prefix redefinition 2010-04-09T09:36:14 2010-04-09T09:36:14 2010-04-09T09:36:14 <div about="#foo" xmlns:ex="http://example.com/right#"> <span xmlns:ex="http://example.com/wrong#"></span> <span property="ex:bar">baz</span> </div> Ought to generate this triple: <#foo> <http://example.com/right#bar> "baz" . The current release of RDF::RDFa::Parser generates: <#foo> <http://example.com/wrong#bar> "baz" . This is because I'm passing around the list of URI mappings by ... <div about="#foo" xmlns:ex="http://example.com/right#"> <span xmlns:ex="http://example.com/wrong#"></span> <span property="ex:bar">baz</span> </div> Ought to generate this triple: <#foo> <http://example.com/right#bar> "baz" . The current release of RDF::RDFa::Parser generates: <#foo> <http://example.com/wrong#bar> "baz" . This is because I'm passing around the list of URI mappings by reference rather than by value. It would be useful if this test could be added to the test suite, as currently none of the approved test cases cover the situation. I have a fix written for RDF::RDFa::Parser which I'll release later today. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/7a7784bb86a18ae65df1acebf9996154.squirrel%40goddamn.co.uk safe curies with undefined prefixes in @about/@resource 2010-04-12T07:29:19 2010-04-12T07:29:19 2010-04-12T07:29:19 Consider: <div profile="http://example.com/profile" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <p about="#bob"> <span property="foaf:name">Bob</span> <span about="[fred:me]" property="foaf:name">Fred</span> </p> </div> Assuming that the profile document defines the prefix "fred", then the names "Fred" and "Bob" are taken to be different resources. If prefix "fred" bein... Consider: <div profile="http://example.com/profile" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <p about="#bob"> <span property="foaf:name">Bob</span> <span about="[fred:me]" property="foaf:name">Fred</span> </p> </div> Assuming that the profile document defines the prefix "fred", then the names "Fred" and "Bob" are taken to be different resources. If prefix "fred" being undefined leads to the about="[fred:me]" attribute being completely ignored, then a processor will assume that the names "Bob" and "Fred" both apply to the same resource. It seems to me that a more useful way of processing it would be to take about="[fred:me]", when "fred" is undefined, to introduce a new blank node. That way, like the correct behaviour when "fred" is defined, the names apply to two different resources; it's just that we don't know the URI for one of them. -Toby http://tobyinkster.co.uk/message/679c61a27eb7823c64e11543c9c413ec.squirrel%40goddamn.co.uk Re: safe curies with undefined prefixes in @about/@resource 2010-04-12T09:17:26 2010-04-12T09:17:26 2010-04-12T09:17:26 > I appreciate that, and it might, technically, be a good idea to treat it > that way. However... doesn't that break backward compatibility? In RDFa > 1.0 that safe CURIE would definitely be ignored... It does break backwards compatibility with RDFa 1.0, yes. But if you consider my example, an RDFa 1.1 processor would alreay generate radically different triples to an RDFa 1.0 processor... >> <d... > I appreciate that, and it might, technically, be a good idea to treat it > that way. However... doesn't that break backward compatibility? In RDFa > 1.0 that safe CURIE would definitely be ignored... It does break backwards compatibility with RDFa 1.0, yes. But if you consider my example, an RDFa 1.1 processor would alreay generate radically different triples to an RDFa 1.0 processor... >> <div profile="http://example.com/profile" >> xmlns:foaf="http://xmlns.com/foaf/0.1/"> >> <p about="#bob"> >> <span property="foaf:name">Bob</span> >> <span about="[fred:me]" property="foaf:name">Fred</span> >> </p> >> </div> Assuming that "fred" is defined by the profile, even if the profile can be resolved, then an RDFa 1.1 processor would generate: @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix fred: <something> . <#bob> foaf:name "Bob" . fred:me foaf:name "Fred" . While an RDFa 1.0 processor would generate: @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix fred: <something> . <#bob> foaf:name "Bob" , "Fred" . This is another reason why I think allowing profiles to define prefixes is not such a good idea. We'll only get close to backwards compatibility if we restrict profiles to defining terms (but not prefixes) for @typeof/@property/@rel/@rev/@datatype. -Toby http://tobyinkster.co.uk/message/20100415141540.375f6c21%40miranda.g5n.co.uk Re: Telecon Agenda - 15th April 2010, 1400 UTC 2010-04-15T13:15:40 2010-04-15T13:15:40 2010-04-15T13:15:40 I'm afraid I'll have to send my regrets today. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I'm afraid I'll have to send my regrets today. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100415143937.59930240%40miranda.g5n.co.uk Re: Telecon Agenda - 15th April 2010, 1400 UTC 2010-04-15T13:39:37 2010-04-15T13:39:37 2010-04-15T13:39:37 I'm afraid I'll have to send my regrets today. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I'm afraid I'll have to send my regrets today. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1271411637.15832.42.camel%40ophelia2.g5n.co.uk Re: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals 2010-04-16T09:54:06 2010-04-16T09:54:06 2010-04-16T09:54:06 Hmmm... a lot of the talk around this issue begs the question of what the nature of sameness is. Two Atom <entry> elements need the same identifier if they're the same entry, but under what circumstances are they the same entry? I am not the same person I was 10 years ago. This is true in a physical sense - most of my body cells are less than 10 years old - and in a less physical sense too - the ... Hmmm... a lot of the talk around this issue begs the question of what the nature of sameness is. Two Atom <entry> elements need the same identifier if they're the same entry, but under what circumstances are they the same entry? I am not the same person I was 10 years ago. This is true in a physical sense - most of my body cells are less than 10 years old - and in a less physical sense too - the person I was 10 years ago is not necessarily a person with whom I share the same beliefs, hopes and fears. So in what sense am I the same person? Certainly there's a continuity of existence between Y2K me and Y2.01K me; a continuity of consciousness. If I'm the same person today as I was yesterday, and the same person yesterday that I was the day before, then I can trace that sameness back as far as I like until my conception. This is a useful technique for evaluating sameness that can be applied to real-world objects, but applying it to virtual, digital resources does not always work out the way we'd like. Take an example from popular programmer's companion "diff". Say I have the following code: if (x) { foo; } And one day I change this to: if (x) { foo; } if (y) { bar; } A diff tool, when asked to pick out which lines have been added to my code, might select: } if (y) { bar; Logically, we consider it to have selected the "wrong" closing brace. It has decided that the closing brace at the end of the full block has remained the same; whereas we'd think that the closing brace after "foo;" has remained the same. Under what circumstances is one HTML page the same as another HTML page? Consider a popular company goes bankrupt; their brand still has value though, and a small competitor buys the right to use that brand (name and logo), and the popular company's domain name from the administrator. The new owner of the domain name sets up a new website reusing the old company's domain name. They set up an "aboutus.html" page which, perhaps by pure chance, or perhaps in an effort to capture traffic from the old site, uses exactly the same URL as the old company's "aboutus.html" page. These two pages have different authors, perhaps different titles, certainly different subjects (they refer to legally separate companies), etc. Is it right to generate the same Atom identifiers for both? Are they the same entries in an Atom sense? Atom says that an <entry> must always retain the same identifier; it must never change. But it doesn't say when two bits of content represent the same <entry>. So what's a practical solution? One way out of the quagmire would be to generate not Atom 1.0, but RDF using the RSS 1.0 vocabulary. (I say "RDF using the RSS 1.0 vocabulary" to differentiate between that and "RSS 1.0" which, in addition to using the RSS 1.0 vocabulary, also uses a limited subset of RDF/XML syntax and has certain other restrictions in order to seem backwards-compatible-ish with earlier versions of RSS. Converters from HTML5 would want to, when possible, aim to comply with those limitations and restrictions in order to increase compatibility with real world feed readers, but not slavishly adhere to them.) With RDF and the open world assumption, it's always possible to leave stuff out. For example, a bloodType property might be defined with a rule stating that every Person has a bloodType. However, even if every people *has* a bloodType, it doesn't mean that we know what their bloodType is, or care to share it with the world. It's permissible to provide information about the Person without providing their bloodType. That's the open world assumption - we never have all the information. So generating RDF using the RSS 1.0 vocabulary, we'd convert each HTML5 <article> element into an rss:item and then tack on any information that we could find about it (title, author, date, etc) and not concern ourselves too much about any particular bits of information which would be impossible to find. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1271435786.15832.112.camel%40ophelia2.g5n.co.uk A couple of XMLLiteral-related questions. 2010-04-16T16:36:29 2010-04-16T16:36:29 2010-04-16T16:36:29 I think the RDFa 1.0 spec is silent on these; it would be nice if RDFa 1.1 could give some unambiguous answers. Firstly, given: <p property="ex:foo"><!--hello--><b>world</b></p> Should the literal be: '<!--hello--><b xmlns="http://www.w3.org/1999/xhtml">world</b>' Or should it be: '<b xmlns="http://www.w3.org/1999/xhtml">world</b>' That is, do we include comments in the canonicalisation ... I think the RDFa 1.0 spec is silent on these; it would be nice if RDFa 1.1 could give some unambiguous answers. Firstly, given: <p property="ex:foo"><!--hello--><b>world</b></p> Should the literal be: '<!--hello--><b xmlns="http://www.w3.org/1999/xhtml">world</b>' Or should it be: '<b xmlns="http://www.w3.org/1999/xhtml">world</b>' That is, do we include comments in the canonicalisation XMLLiteral? In RDF/XML they are included, but that's a serialisation-specific decision; we could decide to specify it the other way. Secondly, given: <p property="ex:foo"><!--hello-->world</p> Is the presence of the comment enough to trigger the generation of an XMLLiteral, or should a plain literal be generated instead? For what it's worth, the current behaviour of my parser is to include comments in XMLLiterals, but for the presence of a comment to not trigger generating an XMLLiteral. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100416190722.186d65a1%40miranda.g5n.co.uk Re: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals 2010-04-16T18:07:22 2010-04-16T18:07:22 2010-04-16T18:07:22 On Fri, 16 Apr 2010 10:28:00 -0700 "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > It is easy to imagine further tools coming to depend on such an id > being dereferenceable, and not reacting appropriately when paired > with a tool that cannot produce dereferenceable URLs for such > articles. This will cause interop problems. This case is already covered by RFC4287: | Though the IRI might us... On Fri, 16 Apr 2010 10:28:00 -0700 "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > It is easy to imagine further tools coming to depend on such an id > being dereferenceable, and not reacting appropriately when paired > with a tool that cannot produce dereferenceable URLs for such > articles. This will cause interop problems. This case is already covered by RFC4287: | Though the IRI might use a dereferencable scheme, Atom | Processors MUST NOT assume it can be dereferenced. Any tool that uses the output of the HTML5 to Atom conversion algorithm is by definition an Atom processor, so bound by RFC4287. I don't see why HTML5 needs to place any additional restrictions on the dereferencability of atom:id elements. > I believe that there currently is no such appropriate algorithm for > defining such a dereferenceable URL, and so it is best to simply say > that the URL must be undereferenceable. Assuming that the HTML5 to Atom conversion tool is running as a web service, it's actually pretty simple to generate a dereferencable URL. Assuming that http://example.com/input-document is the input document, and the conversion tool is running at http://atom.example.net, then: 1. atom.example.net generates a unique undereferencable identifier - perhaps a hash of some kind - for each entry. Say one of those is "ABC123ABC123". 2. It stores the following tuple in a database running on the atom.example.net server: ("ABC123ABC123", "http://example.com/input-document") 3. It uses the following URL as an atom:id when outputting the Atom document: <http://atom.example.net/entry-id/ABC123ABC123> 4. http://atom.example.net/entry-id is a script that takes an identifier, looks it up in the database, and performs a 303 redirect to the destination address. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100416192030.75642c99%40miranda.g5n.co.uk Re: profile files for test purposes 2010-04-16T18:20:30 2010-04-16T18:20:30 2010-04-16T18:20:30 On Fri, 16 Apr 2010 18:51:33 +0200 Ivan Herman <ivan@w3.org> wrote: > http://www.w3.org/2007/08/pyRdfa/profiles/w3c-prefixes.{html,ttl,rdf} > lists the standard prefixes rdf, rdfs, owl, etc Uses rdfa:term where it should use rdfa:prefix, no? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 16 Apr 2010 18:51:33 +0200 Ivan Herman <ivan@w3.org> wrote: > http://www.w3.org/2007/08/pyRdfa/profiles/w3c-prefixes.{html,ttl,rdf} > lists the standard prefixes rdf, rdfs, owl, etc Uses rdfa:term where it should use rdfa:prefix, no? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100418221952.61349a30%40miranda.g5n.co.uk Re: Hacking RDF with Perl hackathon cancelled 2010-04-18T21:19:52 2010-04-18T21:19:52 2010-04-18T21:19:52 On Sun, 18 Apr 2010 21:48:39 +0200 Dan Brickley <danbri@danbri.org> wrote: > What are the main opensource pure Perl tools available? RDF::Trine and RDF::Query tend to be the framework we're gravitating towards. For XML parsing, RDF::Trine has an XML::LibXML dependency, but other than that it's fairly pure Perl. > How compliant > are they? How much of SPARQL (in memory, in SQL, in other things;... On Sun, 18 Apr 2010 21:48:39 +0200 Dan Brickley <danbri@danbri.org> wrote: > What are the main opensource pure Perl tools available? RDF::Trine and RDF::Query tend to be the framework we're gravitating towards. For XML parsing, RDF::Trine has an XML::LibXML dependency, but other than that it's fairly pure Perl. > How compliant > are they? How much of SPARQL (in memory, in SQL, in other things; > SPARQL protocol; SPARQL 1.1?) is covered? RDF::Query has very good SPARQL 1.0 support, and some SPARQL 1.1. It can operate on in-memory and database-backed models. Additionally, RDF::Query::Client provides an interface for SPARQL-protocol endpoints, using an almost identical API, so you can switch between a local model and a remote endpoint very easily. > RDFa? GRDDL? OWL? RIF? N3? POWDER? My RDFa parser passes the RDFa 1.0 test suite, and I'm working on experimental RDFa 1.1 support. If my parser's installed, RDF::Trine will pick it up and use it. GRDDL I have on my TODO list. One of the things we were hoping to work on at the workshop was a rule-based forward-chaining reasoner, with a ruleset for RDFS. Greg already has one in his git repo, but it needs some cleaning up for release. I imagine support for a large subset of OWL would be pretty easy to add too, and vocab-specific reasoning (e.g. for FOAF, generate mbox_sha1sum automatically from mbox properties). I don't think anyone has anything planned regarding N3, RIF or POWDER yet. > Are the tools happily packaged in CPAN? (and Debian etc, if that's > needed?). Are they well tested, actively maintained? Everything I've mentioned above is on CPAN except the reasoner. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100419194431.07979bf5%40miranda.g5n.co.uk Re: call to arms 2010-04-19T18:44:31 2010-04-19T18:44:31 2010-04-19T18:44:31 On Sat, 17 Apr 2010 18:35:16 +0200 Danny Ayers <danny.ayers@gmail.com> wrote: > how easy is it to flip from Gnome to KDE? You can run KDE programs within GNOME and vice versa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 17 Apr 2010 18:35:16 +0200 Danny Ayers <danny.ayers@gmail.com> wrote: > how easy is it to flip from Gnome to KDE? You can run KDE programs within GNOME and vice versa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100419232701.3c5ee688%40miranda.g5n.co.uk Re: call to arms 2010-04-19T22:27:01 2010-04-19T22:27:01 2010-04-19T22:27:01 On Mon, 19 Apr 2010 22:49:06 +0100 adasal <adam.saltiel@gmail.com> wrote: > Can you run dolphin within gnome? Of course. They're all just X-Windows programs. You could run it within fluxbox or fvwm I'm sure. > I think that nepomuk is intimately tied to it, and some other > applications that I had thought were KDE specific. The point is that > KDE pulls in the correct set of dependencies for th... On Mon, 19 Apr 2010 22:49:06 +0100 adasal <adam.saltiel@gmail.com> wrote: > Can you run dolphin within gnome? Of course. They're all just X-Windows programs. You could run it within fluxbox or fvwm I'm sure. > I think that nepomuk is intimately tied to it, and some other > applications that I had thought were KDE specific. The point is that > KDE pulls in the correct set of dependencies for that version. That > would be more difficult outside of KDE. KDE's libraries and other supporting files would obviously need to be installed, but I'd expect the distribution's package manager to take care of that. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100420084342.7dd32978%40miranda.g5n.co.uk RDFa 1.1 support in RDF::RDFa::Parser 2010-04-20T07:43:42 2010-04-20T07:43:42 2010-04-20T07:43:42 Last night I uploaded preview release 1.09_01 of RDF::RDFa::Parser to CPAN. It includes the following new RDFa 1.1 features: * Support for @vocab * Support for @profile These are disabled by default; the default configuration follows XHTML+RDFa 1.0 rules. Version 1.00 already included experimental optional support for all of RDFa 1.1's other new features (@prefix, full URIs in RDFa attributes, ... Last night I uploaded preview release 1.09_01 of RDF::RDFa::Parser to CPAN. It includes the following new RDFa 1.1 features: * Support for @vocab * Support for @profile These are disabled by default; the default configuration follows XHTML+RDFa 1.0 rules. Version 1.00 already included experimental optional support for all of RDFa 1.1's other new features (@prefix, full URIs in RDFa attributes, case-insensitive CURIE prefixes, etc), so with the new features, it should offer complete support for RDFa Core 1.1 and XHTML+RDFa 1.1. The web services at: http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= http://srv.buzzword.org.uk/rdfa-to-xml.cgi?uri= offer a mixture of RDFa 1.0 and 1.1 support. If given a URI that responds with a 'text/html' media type, it will parse it as HTML4+RDFa1.1 or HTML5+RDFa1.1 depending on DOCTYPE. Reponses with XML media types will be parsed as XHTML+RDFa1.0, Atom+RDFa1.0, SVG+RDFa1.0 or XML+RDFa1.0, depending on root element namespace. In the case of XHTML, you can request RDFa 1.1 parsing support by adding &version=1.1 to the request. (Rationalising these combinations is on my todo list.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100421090140.4b77f0b5%40miranda.g5n.co.uk @profile in XHTML+RDFa 1.1 2010-04-21T08:01:40 2010-04-21T08:01:40 2010-04-21T08:01:40 For XHTML+RDFa 1.1 it might make sense to have a rule where @profile on the <head> element is applied to the whole document. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> For XHTML+RDFa 1.1 it might make sense to have a rule where @profile on the <head> element is applied to the whole document. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100421144123.37249b39%40miranda.g5n.co.uk Re: A couple of XMLLiteral-related questions. 2010-04-21T13:41:23 2010-04-21T13:41:23 2010-04-21T13:41:23 On Sat, 17 Apr 2010 08:19:31 +0200 Ivan Herman <ivan@w3.org> wrote: > So the question is: do all xml parsers retain the comments in the > resulting DOM tree? Is that specified? Because if this is left > unspecified by XML (I must admit I did not check) and/or if widely > used XML toolsets remove the comments, then we should not prescribe > this behavior and leave it open. If some XML toolsets re... On Sat, 17 Apr 2010 08:19:31 +0200 Ivan Herman <ivan@w3.org> wrote: > So the question is: do all xml parsers retain the comments in the > resulting DOM tree? Is that specified? Because if this is left > unspecified by XML (I must admit I did not check) and/or if widely > used XML toolsets remove the comments, then we should not prescribe > this behavior and leave it open. If some XML toolsets remove comments from the resultant tree, I don't think that's an argument in favour of leaving it unspecified. Rather it's an argument in favour of saying that all RDFa processors MUST ignore comments regardless of whether their XML toolkit exposes them. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100421212724.177b0ed4%40miranda.g5n.co.uk Re: Notification: Role Attribute Editor's Draft available 2010-04-21T20:27:24 2010-04-21T20:27:24 2010-04-21T20:27:24 On Wed, 21 Apr 2010 12:31:19 -0500 Shane McCarron <shane@aptest.com> wrote: > Please review this document, in particular Appendix A, so that you > understand what we are trying to do and that you agree with the > direction I am taking that spec in. Firstly, given: <div id="quux" role="foo:bar"> It currently generates: <#quux> xhv:role foo:bar . Another possibility would be: <> foo:bar ... On Wed, 21 Apr 2010 12:31:19 -0500 Shane McCarron <shane@aptest.com> wrote: > Please review this document, in particular Appendix A, so that you > understand what we are trying to do and that you agree with the > direction I am taking that spec in. Firstly, given: <div id="quux" role="foo:bar"> It currently generates: <#quux> xhv:role foo:bar . Another possibility would be: <> foo:bar <#quux> . Is there any reason you've chosen the former over the latter? Was the latter considered and dismissed for any particular reason? Secondly, as @role uses CURIEs, does role use @prefix? The previous drafts relied on @xmlns only. If @role is still restricted to using @xmlns, then an RDFa processor would need to keep track of two different sets of CURIE prefix definitions. Lastly, the draft says "an RDFa Processor MUST process the role values as follows". This could be interpreted in two different ways: 1. If an RDFa processor chooses to process @role, then the following is the way it MUST do it; or 2. RDFa processors MUST process @role, and this is how they MUST do it. If the latter, I'd object to this document published outside the RDFa WG making normative assertions about RDFa processing. I ought to have a working implementation of this pretty soon. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100421235428.10361295%40miranda.g5n.co.uk Re: RDFa 1.1 support in RDF::RDFa::Parser 2010-04-21T22:54:28 2010-04-21T22:54:28 2010-04-21T22:54:28 On Tue, 20 Apr 2010 08:43:42 +0100 Toby Inkster <tai@g5n.co.uk> wrote: > http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= > http://srv.buzzword.org.uk/rdfa-to-xml.cgi?uri= These now have optional parameters 'host' and 'version' which default to 'xhtml' and '1.0'. Values for 'host' include: xhtml, html4, html5, svg, atom, xml And obviously, 'version' can be 1.0 or 1.1. Any combination of h... On Tue, 20 Apr 2010 08:43:42 +0100 Toby Inkster <tai@g5n.co.uk> wrote: > http://srv.buzzword.org.uk/rdfa-to-ntriples.cgi?uri= > http://srv.buzzword.org.uk/rdfa-to-xml.cgi?uri= These now have optional parameters 'host' and 'version' which default to 'xhtml' and '1.0'. Values for 'host' include: xhtml, html4, html5, svg, atom, xml And obviously, 'version' can be 1.0 or 1.1. Any combination of host language and RDFa version is possible. However, whether to use an HTML or XML parser to build the DOM tree itself is determined entirely by the HTTP Content-Type header, not by choice of host language. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100422094411.07f86e13%40miranda.g5n.co.uk Re: Notification: Role Attribute Editor's Draft available 2010-04-22T08:44:11 2010-04-22T08:44:11 2010-04-22T08:44:11 On Wed, 21 Apr 2010 15:53:29 -0500 Shane McCarron <shane@aptest.com> wrote: > > I ought to have a working implementation of this pretty soon. > > Cool! I haven't even thought about implementing it yet. I got it implemented in my RDFa parser last night. It's disabled by default though, and currently the web service doesn't offer the granular control over enabling and disabling options that is necessary to test it that way. If people want to test it, RDF::RDFa::Parser 1.09_03 is on CPAN. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 21 Apr 2010 15:53:29 -0500 Shane McCarron <shane@aptest.com> wrote: > > I ought to have a working implementation of this pretty soon. > > Cool! I haven't even thought about implementing it yet. I got it implemented in my RDFa parser last night. It's disabled by default though, and currently the web service doesn't offer the granular control over enabling and disabling options that is necessary to test it that way. If people want to test it, RDF::RDFa::Parser 1.09_03 is on CPAN. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100422104815.0181e03a%40miranda.g5n.co.uk Re: @profile in XHTML+RDFa 1.1 2010-04-22T09:48:15 2010-04-22T09:48:15 2010-04-22T09:48:15 On Wed, 21 Apr 2010 10:31:12 -0500 Shane McCarron <shane@aptest.com> wrote: > But I see Toby's (implied) point that @profile is only legal > on head in HTML4, so people are used to putting it there. Whatsmore, XHTML+RDFa 1.0 said authors SHOULD include: <head profile="http://www.w3.org/1999/xhtml/vocab"> The idea being that this profile licensed the keywords 'next', 'prev', etc. (Though RDF... On Wed, 21 Apr 2010 10:31:12 -0500 Shane McCarron <shane@aptest.com> wrote: > But I see Toby's (implied) point that @profile is only legal > on head in HTML4, so people are used to putting it there. Whatsmore, XHTML+RDFa 1.0 said authors SHOULD include: <head profile="http://www.w3.org/1999/xhtml/vocab"> The idea being that this profile licensed the keywords 'next', 'prev', etc. (Though RDFa parsers need to still recognise those keywords even if the profile is absent.) This licence applied not only to the <head> of the document, but to the <body> too. (And <html rel="next" resource="foo"> works too!) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100422105915.2bf9e209%40miranda.g5n.co.uk Re: @profile in XHTML+RDFa 1.1 2010-04-22T09:59:15 2010-04-22T09:59:15 2010-04-22T09:59:15 On Wed, 21 Apr 2010 15:31:04 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > I'm pretty certain it was you who spotted that if you did this: > > <html typeof="foaf:Document"> > > or this: > > <head typeof="foaf:Document"> > > you would end up with a bnode as the subject of all of the triples in > the head. Currently, the former example *does* create a bnode, and the latter on... On Wed, 21 Apr 2010 15:31:04 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > I'm pretty certain it was you who spotted that if you did this: > > <html typeof="foaf:Document"> > > or this: > > <head typeof="foaf:Document"> > > you would end up with a bnode as the subject of all of the triples in > the head. Currently, the former example *does* create a bnode, and the latter one does not. Here's an interesting one: <html typeof="foaf:Document" property="dc:creator" content="Joe Bloggs"> <title property="dc:title">Foo</title> </html> Parsed as HTML (which automatically implies missing <head> and <body> elements), it produces: _:blank a foaf:Document ; dc:creator "Joe Bloggs" . <> dc:title "Foo" . Because the missing <head> element is implied as a wrapper for <title>, and the RDFa processing sequence implies about="" on it. But parsed as XHTML, it generates: _:blank a foaf:Document ; dc:creator "Joe Bloggs" ; dc:title "Foo" . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/c91d0d5b6cfb55d9d3bd74c1cb5e2d40.squirrel%40goddamn.co.uk Re: Notification: Role Attribute Editor's Draft available 2010-04-23T09:35:43 2010-04-23T09:35:43 2010-04-23T09:35:43 > Very specifically, I would change Appendix A in the Role documentation to > something that describes how RDF triples can be created from a document > with a @role attribute, without any reference to RDFa processing. And I do > not think there should be any reference to @role in the HTML+RDFa > document. > > (I have no problem with Role referring to the URI/CURIE mechanism of RDFa, > of course, b... > Very specifically, I would change Appendix A in the Role documentation to > something that describes how RDF triples can be created from a document > with a @role attribute, without any reference to RDFa processing. And I do > not think there should be any reference to @role in the HTML+RDFa > document. > > (I have no problem with Role referring to the URI/CURIE mechanism of RDFa, > of course, but that is a different matter.) +1. I've implemented support for @role in my parser, but don't really consider it part of RDFa. (It's just too trivial a thing to justify writing a whole separate parser for, so might as well bundle it in with RDFa.) > It might also be worth considering defining a 'role' object in an API, > that could refer to the core RDFa API elements like triplets or blank > nodes. But, again, that should be disjoint from the strictly rdfa part of > the API. > > Sorry if I sound a bit harsh...:-) Role would probably benefit from a different, non-RDF API. Something like: var elements = document.getElementsByRole('contentinfo'); for (var i=0; elements[i]; i++) { var roles = element[i].getRoles; for (var j=0; roles[j]; j++) { if (roles[j] != 'contentinfo') { window.alert("This contentinfo element also has role "+roles[j]); } } } Node.getElementsByRole would take a single string parameter interpreted as a URI. If the string matched NCName, it would be prepended with "http://www.w3.org/1999/xhtml/vocab#". It would return all child nodes that had that role. Element.getRoles would return an array of role URIs that an element had. If a role URI began "http://www.w3.org/1999/xhtml/vocab#" and the rest of the role URI matched NCName, then this URI would be abbreviated by removing that prefix. Element.addRole and Element.removeRole might be handy too. Something like that seems like it would be a lot more natural for those who are used to traversing/manipulating the DOM tree via tag names, classes, IDs, attributes, etc. @role becomes another facet of the DOM tree they can use to find what they want on the page. -Toby http://tobyinkster.co.uk/message/6126deb07e363feb3e660326b05c4908.squirrel%40goddamn.co.uk Re: How to Stringify RDFTriple and BlankNode 2010-04-23T10:33:38 2010-04-23T10:33:38 2010-04-23T10:33:38 > What would you expect to be the result of the following print statements: > > 1. var bn = new BlankNode() > print(bn.toString()) Something like: _:fsdfsdgfdrg Where everything after "_:" is a string that cannot be relied upon to be stable. > 2. subject = new URI("http://www.example.com#foo"); > var triple1 = new RDFTriple(subject, rdfa.rdfs.label, new > PlainLiteral("a,b c; g")); >... > What would you expect to be the result of the following print statements: > > 1. var bn = new BlankNode() > print(bn.toString()) Something like: _:fsdfsdgfdrg Where everything after "_:" is a string that cannot be relied upon to be stable. > 2. subject = new URI("http://www.example.com#foo"); > var triple1 = new RDFTriple(subject, rdfa.rdfs.label, new > PlainLiteral("a,b c; g")); > print(triple1.toString()); Definately: http://www.example.com#foo And not: <http://www.example.com#foo> toString is called by the Javascript engine automatically when an object is coerced into a string, so needs to return the most useful representation of the object. Returning without the angled brackets allows it to be used like this: for (each triple blah blah) { if (triple.subject == document.location.href) { do something; } } > 3. subject = new URI("http://www.example.com#foo"); > var triple1 = new RDFTriple(subject, rdfa.rdfs.label, new > PlainLiteral("http://www.example.com#foo")); > print(triple1.toString()); > > In an early release of the JS Prototype of the RDFa DOM API, I used > TURTLE syntax in general. > This would solve the problem but seems to be too much RDF in this API. I'd expect an N-Triples representation of the triple with some canonicalised whitespace agreed on. Say, a single space character between each of the subject, predicate, object and full stop; and no trailing whitespace or new line characters. That makes it possible to easily check a triple against a known value: if (triple == '<http://example.com/joe#me> <http://xmlns.com/foaf/0.1/name> "Joe" .') { do something; } -Toby http://tobyinkster.co.uk/message/171283762bce4935a57e02ff7c233e7a.squirrel%40goddamn.co.uk Re: Perl and AllegroGraph (was: Re: Hacking RDF with Perl hackathon cancelled) 2010-04-23T10:42:00 2010-04-23T10:42:00 2010-04-23T10:42:00 > I think the blueprint would be something we should have fleshed out F2F, > so it is a pity it didn't happen. Hopefully at some future date... > Thus, there is potential for a lot of common code for working with RDF > over HTTP, so this is probably something that should be slightly > coordinated. There already exists RDF::Trine::Store::SPARQL which can be used to work with any store that expos... > I think the blueprint would be something we should have fleshed out F2F, > so it is a pity it didn't happen. Hopefully at some future date... > Thus, there is potential for a lot of common code for working with RDF > over HTTP, so this is probably something that should be slightly > coordinated. There already exists RDF::Trine::Store::SPARQL which can be used to work with any store that exposes a SPARQL Protocol endpoint, albeit read-only. Hopefully as SPARQL Update approaches standardisation, it will become read-write, or acquire a read-write sister module. One store I keep meaning to write is RDF::Trine::Store::JenaSDB to allow Trine to use the SQL database stores created by Jena. SDB's data layout is not a million miles away from how Trine's DBI store already works. -Toby http://tobyinkster.co.uk/message/1ef296b22da9969642641dcb36ded747.squirrel%40goddamn.co.uk Re: How to Stringify RDFTriple and BlankNode 2010-04-23T15:43:15 2010-04-23T15:43:15 2010-04-23T15:43:15 > Why the "_:" prefix? Does it provide any functionality? > Couldn't we let developers decide how to serialize it? For consistency with how bnodes are represented in N-Triples (and thus, how they'd be represented in Triple.toString). -Toby > Why the "_:" prefix? Does it provide any functionality? > Couldn't we let developers decide how to serialize it? For consistency with how bnodes are represented in N-Triples (and thus, how they'd be represented in Triple.toString). -Toby http://tobyinkster.co.uk/message/20100424084143.424935ca%40miranda.g5n.co.uk Re: Rename @prefix 2010-04-24T07:41:43 2010-04-24T07:41:43 2010-04-24T07:41:43 On Fri, 23 Apr 2010 14:44:35 -0400 Doug Schepers <schepers@w3.org> wrote: > Quite apart from any issues about whether the 'prefix' attribute is > the right mechanism, it is a confusing and unintuitive attribute > name. It describes a syntactic convention, not the underlying > concept which is its true function. CURIE prefixes are entirely syntactic sugar though. They have no semantics in themse... On Fri, 23 Apr 2010 14:44:35 -0400 Doug Schepers <schepers@w3.org> wrote: > Quite apart from any issues about whether the 'prefix' attribute is > the right mechanism, it is a confusing and unintuitive attribute > name. It describes a syntactic convention, not the underlying > concept which is its true function. CURIE prefixes are entirely syntactic sugar though. They have no semantics in themselves. > My suggestions for a more accurate attribute name are: > > * 'ontology' > * 'context' > * 'scope' > * 'reference' > * 'model' > > ... or anything similar. @prefix can be used as follows: <div prefix="a: http://dbpedia.org/resource/a" about="[a:lbert_Einstein]"> The URI <http://dbpedia.org/resource/a> is certainly not an ontology, a reference or a model; and it's a bit of a stretch to refer to it as a scope or reference either. It's a purely syntactic artefact. @prefix seems an appropriate name for this, and it's consistent with the @prefix keyword in Turtle and the PREFIX keyword in SPARQL. The only possible quibble I have with the name of this attribute is that it's singular, while it's possible to define multiple prefixes at once: <div prefix="foaf: http://xmlns.com/foaf/0.1/ dc: http://purl.org/dc/terms/ sioc: http://rdfs.org/sioc/ns#"> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100424093349.56919a6b%40miranda.g5n.co.uk Re: Facebook - RDFa in Open Graph Protocol 2010-04-24T08:33:49 2010-04-24T08:33:49 2010-04-24T08:33:49 On Wed, 21 Apr 2010 21:33:04 +0200 Dan Brickley <danbri@danbri.org> wrote: > http://opengraphprotocol.org/ Last night I added some OGP-specific functionality to my RDFa parser. No parsing tweaks needed, but some syntactic sugar to help people get at OGP data without needing to know SPARQL or the intricacies of the RDF data model. It's as easy as: $rdfa = RDF::RDFa::Parser->new_from_url('http... On Wed, 21 Apr 2010 21:33:04 +0200 Dan Brickley <danbri@danbri.org> wrote: > http://opengraphprotocol.org/ Last night I added some OGP-specific functionality to my RDFa parser. No parsing tweaks needed, but some syntactic sugar to help people get at OGP data without needing to know SPARQL or the intricacies of the RDF data model. It's as easy as: $rdfa = RDF::RDFa::Parser->new_from_url('http://example.net/'); print $rdfa->opengraph('site_name'); In RDF terms, the opengraph method takes a property as a string. If the property is not a full URI, it prepends the opengraph URI to make it one. Then it finds triples such that the subject is the document's base URL, the property is the URI provided, and the object is not a blank node. It then returns a value or list of values as plain strings (i.e. it doesn't differentiate between literals, resources, etc). If the opengraph method is called without any parameters, it instead returns a list of properties that the page has. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100427083643.2a2690d2%40miranda.g5n.co.uk RDFa API - global object 2010-04-27T07:36:43 2010-04-27T07:36:43 2010-04-27T07:36:43 The 'rdfa' object in the current draft appears to be a global object? Is this true? I'd like to propose making it a property of the existing global 'document' object, so you'd access it in Javascript as: rdfa = document.rdfa; Why? Firstly, globals are evil. Secondly, because the 'document' object is already presented to the user in a number of convenient places. For example, it'saccessible ac... The 'rdfa' object in the current draft appears to be a global object? Is this true? I'd like to propose making it a property of the existing global 'document' object, so you'd access it in Javascript as: rdfa = document.rdfa; Why? Firstly, globals are evil. Secondly, because the 'document' object is already presented to the user in a number of convenient places. For example, it'saccessible across IFRAME elements. I can do this: <iframe src="otherdoc.html"></iframe> <script type="text/javascript"> var frames = document.getElementsByTagName('iframe'); var fdoc = frames[0].contentDocument; window.alert(fdoc.body.innerHTML); </script> Or I can perform an XMLHttpRequest for some external file, get the response and do something like this: var response = ... XML response ...; window.alert(response.responseXML.documentElement.innerHTML); So making 'rdfa' a property of the document object would enable one page to load another page either as an iframe or via AJAX, and read RDFa from the other page. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100427092304.3e00dd8a%40miranda.g5n.co.uk RDFa API - uniting bnode, uri and projected objects 2010-04-27T08:23:04 2010-04-27T08:23:04 2010-04-27T08:23:04 This is a proposal to create a superclass of blank nodes and URI references; and provide some extra methods and attributes on this superclass to make the current Projection interface unneeded. For want of a better term, I'll call this superclass "Resource" as it's analogous to an rdfs:Resource. interface Resource { readonly attribute DOMString value; readonly attribute Node element; readon... This is a proposal to create a superclass of blank nodes and URI references; and provide some extra methods and attributes on this superclass to make the current Projection interface unneeded. For want of a better term, I'll call this superclass "Resource" as it's analogous to an rdfs:Resource. interface Resource { readonly attribute DOMString value; readonly attribute Node element; readonly attribute Sequence[URI] properties; [NameGetter] Sequence[any] get (in DOMString name); } The rdfa.extractObject/rdfa.project method would no longer be needed. Given a page containing: <a vocab="http://xmlns.com/foaf/0.1/" about="#me" typeof="Person" rel="homepage" href="http://example.net/" property="name" content="Joe Bloggs"> <span property="http://purl.org/dc/terms/title" >Joe's World of Fun</span> </a> A script could do something like this: >>> joe = new URI("#me"); >>> joe = new Resource("#me"); /* either works */ >>> name = joe['http://xmlns.com/foaf/0.1/name'][0]; >>> /* name is a PlainLiteral object */ >>> print(name); Joe Bloggs >>> page = joe['http://xmlns.com/foaf/0.1/homepage'][0]; >>> /* page is a URI object, hence also a Resource object */ >>> title = page['http://purl.org/dc/terms/title'][0]; >>> print(title); Joe's World of Fun -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100427141616.7e12c11d%40miranda.g5n.co.uk Re: RDFa API - uniting bnode, uri and projected objects 2010-04-27T13:16:16 2010-04-27T13:16:16 2010-04-27T13:16:16 On Tue, 27 Apr 2010 09:23:04 +0100 Toby Inkster <tai@g5n.co.uk> wrote: > For want of a better term, I'll call this superclass "Resource" as > it's analogous to an rdfs:Resource. Expanding on this a little... var x = new URI("#foo"); var y = new URI("#foo"); if (x == y) { this_should_work(); } So, in particular: <span about="#foo" predicate="ex:test" href="#bar"></span> <span about="#foo... On Tue, 27 Apr 2010 09:23:04 +0100 Toby Inkster <tai@g5n.co.uk> wrote: > For want of a better term, I'll call this superclass "Resource" as > it's analogous to an rdfs:Resource. Expanding on this a little... var x = new URI("#foo"); var y = new URI("#foo"); if (x == y) { this_should_work(); } So, in particular: <span about="#foo" predicate="ex:test" href="#bar"></span> <span about="#foo" predicate="ex:test" href="#baz"></span> <script type="text/javascript"> var triple_list = rdfa.filter(); var t0 = triple_list[0]; var t1 = triple_list[1]; // the subjects are the same if (t0.subject == t1.subject) { // this should work } </script> But t0.subject.element doesn't make sense now. t0.subject and t1.subject are the same resource, but have different elements. So, further to my previous proposal we should extend the current RDFTriple interface to include three additional readonly attributes: readonly attribute Node subjectElement; readonly attribute Node predicateElement; readonly attribute Node objectElement; -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100427164701.67e7d34c%40miranda.g5n.co.uk Re: Some thoughts on the RDFa DOM API document 2010-04-27T15:47:01 2010-04-27T15:47:01 2010-04-27T15:47:01 On Tue, 27 Apr 2010 09:42:32 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Good catch, Benjamin... I wonder why Blank Nodes aren't allowed as > predicates? It's a bit of an annoying restriction. A lot of N-ary relationship problems could be solved by bnode predicates. e.g. <#school> [ rdfs:subPropertyOf teaching:teacher ; teaching:subject thesaurus:Maths ; rdfs:label "m... On Tue, 27 Apr 2010 09:42:32 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Good catch, Benjamin... I wonder why Blank Nodes aren't allowed as > predicates? It's a bit of an annoying restriction. A lot of N-ary relationship problems could be solved by bnode predicates. e.g. <#school> [ rdfs:subPropertyOf teaching:teacher ; teaching:subject thesaurus:Maths ; rdfs:label "maths teacher"@en ] <#joe> . N3 allows blank node predicates; the SPARQL query language does too (though pretty much all SPARQL engines sit on top of RDF quad or triple stores, so in practice they never get a chance to see any bnode predicates). RDF doesn't though. Along with literal subjects, it's an oft-mentioned wishlist item for a future version of RDF should there ever be one. TimBL noted that blank node predicates would be useful when he reviewed the RDF Concepts & Abstract Data Model: <http://www.w3.org/2002/07/29-rdfcadm-tbl.html#xtocid48022>. So, while RDF doesn't allow bnode predicates, we should bear in mind that a future version of RDF might. This means that while RDFa and the DOM API shouldn't allow bnode predicates, we should try to avoid making decisions that would make it difficult to add that feature in a future version. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100427175750.688c5d33%40miranda.g5n.co.uk Re: Facebook's Open Graph Protocol 2010-04-27T16:57:50 2010-04-27T16:57:50 2010-04-27T16:57:50 On Tue, 27 Apr 2010 12:18:04 +1000 Renato Iannella <renato@nicta.com.au> wrote: > Disappointing in that they ignore the past and "reinvent" a new > namespace for already well established semantics.... It's not difficult to pick holes in the OGP schema, but I think it's more important to support the idea overall. The bigger point is that they chose to reuse RDF rather than inventing their own pro... On Tue, 27 Apr 2010 12:18:04 +1000 Renato Iannella <renato@nicta.com.au> wrote: > Disappointing in that they ignore the past and "reinvent" a new > namespace for already well established semantics.... It's not difficult to pick holes in the OGP schema, but I think it's more important to support the idea overall. The bigger point is that they chose to reuse RDF rather than inventing their own proprietary markup. Given that choice, you can use off-the-shelf reasoning tools to map OGP's schema to whatever other vocabs you like. If they hadn't used RDF, that would be a whole lot harder. Besides which, most OGP properties don't have drop-in replacements in existing vocabs. For example the following triple: <> og:region ?place . Is not really equivalent to: <> foaf:based_near ?place . But is closer to: <> foaf:primaryTopic [foaf:based_near [rdfs:label ?place]] . If they'd reused existing vocabs, they probably wouldn't have been able to keep their data structure as flat as it is. This flat schema may prove important for adoption. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100428213601.031e3f39%40miranda.g5n.co.uk Re: rdf:XMLLiteral and the RDF namespace 2010-04-28T20:36:01 2010-04-28T20:36:01 2010-04-28T20:36:01 On Wed, 28 Apr 2010 17:07:40 +0200 "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com> wrote: > 1) the RDF prefix and namespace should be obligatory if the datatype > rdf:XMLLiteral is used Yes, this is the case. @datatype is a CURIE, so you must define the CURIE prefix. The "rdf:" prefix is nothing special in this regard. Test 0094 in the RDFa test suite is relevant here. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 28 Apr 2010 17:07:40 +0200 "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com> wrote: > 1) the RDF prefix and namespace should be obligatory if the datatype > rdf:XMLLiteral is used Yes, this is the case. @datatype is a CURIE, so you must define the CURIE prefix. The "rdf:" prefix is nothing special in this regard. Test 0094 in the RDFa test suite is relevant here. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100429084958.1404421c%40miranda.g5n.co.uk Re: ISSUE-114 (rel-canonical-organization): Chairs Solicit Proposals 2010-04-29T07:49:58 2010-04-29T07:49:58 2010-04-29T07:49:58 On Wed, 28 Apr 2010 21:03:55 -0700 Maciej Stachowiak <mjs@apple.com> wrote: > "link tag: rel: associate pages about the same organization across > many sites for searches without a canonical page and despite a > confusingly indistinct name" I'd be happy to write proposals for issues 114 and 115. The gist of the proposal would be that the existing RDFa and Microdata extensions already cover ... On Wed, 28 Apr 2010 21:03:55 -0700 Maciej Stachowiak <mjs@apple.com> wrote: > "link tag: rel: associate pages about the same organization across > many sites for searches without a canonical page and despite a > confusingly indistinct name" I'd be happy to write proposals for issues 114 and 115. The gist of the proposal would be that the existing RDFa and Microdata extensions already cover these two cases syntactically and that no spec changes are needed; the proposal would also suggest publishing a vocabulary to cover the use cases, along with RDFa and Microdata recipes using the vocabulary. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100429090727.2c885566%40miranda.g5n.co.uk Re: Facebook's Open Graph Protocol 2010-04-29T08:07:27 2010-04-29T08:07:27 2010-04-29T08:07:27 On Wed, 28 Apr 2010 09:45:32 +0200 Dan Brickley <danbri@danbri.org> wrote: > Meta question: do we think the "prefix=" variant on xmlns= is stable > enough to encourage people to use? I'm on the RDFa working group, but the following is my personal assessment, not an official reply from the WG. @prefix is pretty sure to become an RDFa feature, but the syntax of the attribute value is not set in ... On Wed, 28 Apr 2010 09:45:32 +0200 Dan Brickley <danbri@danbri.org> wrote: > Meta question: do we think the "prefix=" variant on xmlns= is stable > enough to encourage people to use? I'm on the RDFa working group, but the following is my personal assessment, not an official reply from the WG. @prefix is pretty sure to become an RDFa feature, but the syntax of the attribute value is not set in stone. There were objections (including from me) about colons being used as the delimiters between URIs and prefixes, given that URIs (not just can, but always do) contain colons. We settled on the syntax in the FPWD as an interim agreement, but that discussion is not yet over. > Are parsers supporting prefix= ? Latest development version of my parser does; and Ivan's (PyRDFa) too. Perhaps others. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100429102845.6636f891%40miranda.g5n.co.uk Re: RDFa API - uniting bnode, uri and projected objects 2010-04-29T09:28:45 2010-04-29T09:28:45 2010-04-29T09:28:45 On Thu, 29 Apr 2010 01:46:06 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > First thing that pops to mind is that this will be quite the CPU hog > to implement. Note that the 'properties' attribute has to be built for > /every/ triple extracted from the document. Not for every triple; only for every resource (i.e. blank nodes and URIs). Some languages would allow the properties attribut... On Thu, 29 Apr 2010 01:46:06 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > First thing that pops to mind is that this will be quite the CPU hog > to implement. Note that the 'properties' attribute has to be built for > /every/ triple extracted from the document. Not for every triple; only for every resource (i.e. blank nodes and URIs). Some languages would allow the properties attribute to be built on-the-fly when it's first accessed, so no need to pre-emptively do so for all resources. Javascript is obviously an important target language for the API; I'm not sure if this on-demand building of the attribute is possible there. An alternative would be to provide a method instead. This would be conceptually similar, though syntactically slightly different. Instead of: joe = new URI("#me"); print(joe[rdfa.foaf.name]); you'd use: joe = new URI("#me"); print(joe.property(rdfa.foaf.name)); -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100502125221.32c917d2%40miranda.g5n.co.uk Re: RDFa Core 1.1 feedback 2010-05-02T11:52:21 2010-05-02T11:52:21 2010-05-02T11:52:21 On Sat, 1 May 2010 22:59:27 -0400 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > * Section 9 Note 3: Indicates that if a subject has more than one > triple with a predicate of rdfa:uri or rdfa:term, all triples > associated with the subject should be ignored (how I read it). What > if there are multiple values for rdfa:prefix? Does this imply > multiple prefix mappings, is is this also inval... On Sat, 1 May 2010 22:59:27 -0400 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > * Section 9 Note 3: Indicates that if a subject has more than one > triple with a predicate of rdfa:uri or rdfa:term, all triples > associated with the subject should be ignored (how I read it). What > if there are multiple values for rdfa:prefix? Does this imply > multiple prefix mappings, is is this also invalid? Indeed, this section needs tightening up. We need to consider what mappings are established in these three cases: ## Multiple URIs [] rdfa:term "Person" ; rdfa:uri <a> , <b> . ## Multiple terms [] rdfa:term "Person" , "Dude" ; rdfa:uri <a> . ## Multiple terms and URIs [] rdfa:term "Person" , "Dude" ; rdfa:uri <a> , <b> . And the corresponding rdfa:prefix cases. Also: ## Both these in the same profile [] rdfa:term "Person" ; rdfa:uri <a> . [] rdfa:term "Person" ; rdfa:uri <b> . Relying on the order that the mappings are specified might work for profiles written in RDFa, but what about profiles written in other profile serialisations? In many cases, RDFa parsers will hook into third-party parsers for those, and it's unlikely they'll be able to rely on triples being returned in any particular order. A good method of tightening up the definition of profiles might be for the spec to provide SPARQL SELECT queries that should be applied to profiles to yield the lists of mappings. (Implementations would not be required to implement SPARQL, but could use any technique to extract the lists of mappings which yielded the same results.) I don't actually see any harm in allowing terms to be expanded to multiple URIs. So, for example the term "title" could be mapped to both dcterms:title and rdfs:label. This would allow for profiles to be created that, say, simultaneously provided data in FOAF plus Google's vocab. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100503085200.3e870119%40miranda.g5n.co.uk //head/object 2010-05-03T07:52:00 2010-05-03T07:52:00 2010-05-03T07:52:00 In HTML 4, <object> is allowed as a child of <head>. Not so in the current HTML5 draft. I can't seem to find any mention of this change in the draft spec, nor in the html5-diff draft. I've searched for '"object element" html5 head' on Google to try to find the reasoning for it, but nothing's come up. Can I ask why the change? If this is an oversight, and we do want to continue to allow <object> in <head>, then can the draft spec be updated; otherwise can the html5-diff draft be updated? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> In HTML 4, <object> is allowed as a child of <head>. Not so in the current HTML5 draft. I can't seem to find any mention of this change in the draft spec, nor in the html5-diff draft. I've searched for '"object element" html5 head' on Google to try to find the reasoning for it, but nothing's come up. Can I ask why the change? If this is an oversight, and we do want to continue to allow <object> in <head>, then can the draft spec be updated; otherwise can the html5-diff draft be updated? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100503090803.12ae45f8%40miranda.g5n.co.uk Re: HTML+RDFa 1.1 (working on new heartbeat WD) 2010-05-03T08:08:03 2010-05-03T08:08:03 2010-05-03T08:08:03 On Mon, 03 May 2010 00:47:41 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > As always, questions, concerns or comments are very welcome - please > send them to the HTML WG mailing list. Minor editorial fix: "This specification has been jointly developed by the RDFa Task Force and the HTML Working Group and is currently being published by the HTML Working Group to further discussions ... On Mon, 03 May 2010 00:47:41 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > As always, questions, concerns or comments are very welcome - please > send them to the HTML WG mailing list. Minor editorial fix: "This specification has been jointly developed by the RDFa Task Force and the HTML Working Group and is currently being published by the HTML Working Group to further discussions there." "RDFa Task Force" should be "RDFa Working Group". Also: in section C.3, members of the RDFa WG are acknowledged; members of the HTML WG are not. Any reason? Lastly: "The document should conform to the constraints expressed in the HTML 4.01 + RDFa 1.1 Document Type Definition located in the Appendix." I don't think that's true for HTML5+RDFa documents. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100503155536.14f98de9%40miranda.g5n.co.uk Re: //head/object 2010-05-03T14:55:36 2010-05-03T14:55:36 2010-05-03T14:55:36 On Mon, 3 May 2010 12:01:38 +0200 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > Use case? I was thinking of using <object> in <head> as a way of embedding RDFa or microdata without disturbing the appearance of the page. While RDFa can encode graphs and deep trees in a flat sequence of <link> or <meta> tags, it can be made more pithy by wrapping some elements within other elemen... On Mon, 3 May 2010 12:01:38 +0200 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > Use case? I was thinking of using <object> in <head> as a way of embedding RDFa or microdata without disturbing the appearance of the page. While RDFa can encode graphs and deep trees in a flat sequence of <link> or <meta> tags, it can be made more pithy by wrapping some elements within other elements - <object> and <param> seemed perfect candidates. For microdata on the other hand, without <object> it seems completely impossible to embed data in the <head> in HTML. And Maceij wrote: > Assuming you accept the explanation that others have given (that > <object> implicitly closes the <head> and starts the <body> in most > browsers), could you please file a bug against the diffs document to > mention this difference? > > Bug filing URL: > http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG In most browsers as measured by counting the number of vendors perhaps, but in most browsers as measured by counting the number of users it seems not. Filing a bug against html5-diffs seems to beg the bigger question of whether <object> should be allowed inside <head>. I can't find any record of this having been discussed - the HTML5 draft spec seems to have just accepted the behaviour of Opera, Gecko and WebKit, even though it goes against the HTML 4 specification, and against Internet Explorer's behaviour. I don't have a strong opinion either way, but before filing a bug, I think we need to discuss whether that bug should be against html5-diffs or against html5. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100503160648.165ccc4c%40miranda.g5n.co.uk Re: RDFa 1.1 and the future of RDFa 1.0 2010-05-03T15:06:48 2010-05-03T15:06:48 2010-05-03T15:06:48 On Mon, 3 May 2010 13:29:46 +0000 Stéphane Corlosquet <scorlosquet@gmail.com> wrote: > With RDFa 1.1 around the corner, is it safe to ship new applications > (such as Drupal 7) with RDFa 1.0, or should we migrate to RDFa 1.1? > Will RDFa parsers still understand RDFa 1.0 in say two years from > now? (Note that the page templates included in Drupal 7 are all > XHTML). The RDFa Working Group's cha... On Mon, 3 May 2010 13:29:46 +0000 Stéphane Corlosquet <scorlosquet@gmail.com> wrote: > With RDFa 1.1 around the corner, is it safe to ship new applications > (such as Drupal 7) with RDFa 1.0, or should we migrate to RDFa 1.1? > Will RDFa parsers still understand RDFa 1.0 in say two years from > now? (Note that the page templates included in Drupal 7 are all > XHTML). The RDFa Working Group's charter says specifically that we're supposed to keep 1.1 compatible with 1.0. That is, RDFa 1.1 parsers will still be able to read RDFa 1.0 documents; and RDFa 1.0 parsers will be able to read RDFa 1.1 documents, though perhaps only see a subset of the triples. So you should be pretty safe sticking with 1.0 as a publisher. There is one exception noted in the charter with regards to the default datatype for literals - right now, in the case of: <span property="foaf:name">Albert <b>Einstein</b></span> and XMLLiteral would be generated; but in RDFa 1.1 this *might* be changed to a plain literal. (XMLLiterals would still be possible to mark up, they'd just need an explicit datatype attribute.) We've not made any changes in this area yet, but we have open issues in the tracker. > Is there any document listing the difference and/or benefits between > RDFa 1.0 and RDF 1.1? Not an official one yet, but Ivan's blog post offers a good summary: http://ivan-herman.name/2010/04/22/rdfa-1-1-drafts/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100504204839.19be2a29%40miranda.g5n.co.uk Re: //head/object 2010-05-04T19:48:39 2010-05-04T19:48:39 2010-05-04T19:48:39 On Tue, 4 May 2010 16:20:22 +0200 Krzysztof Maczyński <1981km@gmail.com> wrote: > I can't see how it makes those browsers' parsers simpler. Certainly allowing <object> in <head> doesn't increase parser complexity. It would be a simple matter of switching from treating it like, say, <div> which automatically triggers the <body> element to start, to treating it like <script> which does not. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 4 May 2010 16:20:22 +0200 Krzysztof Maczyński <1981km@gmail.com> wrote: > I can't see how it makes those browsers' parsers simpler. Certainly allowing <object> in <head> doesn't increase parser complexity. It would be a simple matter of switching from treating it like, say, <div> which automatically triggers the <body> element to start, to treating it like <script> which does not. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100504235905.413d85ca%40miranda.g5n.co.uk Re: Profile issues 2010-05-04T22:59:05 2010-05-04T22:59:05 2010-05-04T22:59:05 On Tue, 4 May 2010 12:31:48 +0200 Ivan Herman <ivan@w3.org> wrote: > if, at some element, @profile cannot be dereferenced, then the whole > subtree would be taken out of RDFa processing. (It is a fairly > drastic move but makes a lot of sense in my view.) I quite like it. It satisfies most of my objections to @profile. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 4 May 2010 12:31:48 +0200 Ivan Herman <ivan@w3.org> wrote: > if, at some element, @profile cannot be dereferenced, then the whole > subtree would be taken out of RDFa processing. (It is a fairly > drastic move but makes a lot of sense in my view.) I quite like it. It satisfies most of my objections to @profile. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/101a05026ef4ac3984338908db5e38a4.squirrel%40goddamn.co.uk Re: [Admin] Wiki pages for comments 2010-05-05T09:19:33 2010-05-05T09:19:33 2010-05-05T09:19:33 > To make things easier I stole a template from the OWL WG: > > http://www.w3.org/2010/02/rdfa/wiki/Template:Creply I've edited the template to include a category link - this should mean that all replies will automatically get listed here: http://www.w3.org/2010/02/rdfa/wiki/Category:WorkingGroupAnswers -Toby > To make things easier I stole a template from the OWL WG: > > http://www.w3.org/2010/02/rdfa/wiki/Template:Creply I've edited the template to include a category link - this should mean that all replies will automatically get listed here: http://www.w3.org/2010/02/rdfa/wiki/Category:WorkingGroupAnswers -Toby http://tobyinkster.co.uk/message/20100505143059.5ab2038b%40miranda.g5n.co.uk RDFa linting/validation [Re: Tomorrow: Social Web XG Meeting cancelled again] 2010-05-05T13:30:59 2010-05-05T13:30:59 2010-05-05T13:30:59 On Tue, 4 May 2010 21:53:23 +0200 Dan Brickley <danbri@danbri.org> wrote: > Suggested 'homework' for the week off: think about rdfa validators > and how they could be made modular to help publishers check which > consumer sites will understand their data... This is an interesting idea, and one I'd be interested in working on. I think that the Perl RDF modules on CPAN cover this area quite well, ... On Tue, 4 May 2010 21:53:23 +0200 Dan Brickley <danbri@danbri.org> wrote: > Suggested 'homework' for the week off: think about rdfa validators > and how they could be made modular to help publishers check which > consumer sites will understand their data... This is an interesting idea, and one I'd be interested in working on. I think that the Perl RDF modules on CPAN cover this area quite well, and it would not be too difficult to get a pretty useful tool working. Basic technique: 1. We need RDF::RDFa::Linter::Google, RDF::RDFa::Linter::Facebook, etc. These would provide the following methods: * RDF::RDFa::Linter::Foo->usual_prefixes A list of the vocabs used by the service, with the prefixes they're "normally" bound to, as recommended by the service's documentation. * RDF::RDFa::Linter::Foo->filter Given a stream of triples, should filter some out to leave only triples that are thought to be understood by the service. e.g. RDF::RDFa::Linter::Facebook would leave only the OGP triples. * RDF::RDFa::Linter::Foo->required_predicates($class) For any given class URI, returns a list of URIs of predicates that the service considers to be required. e.g. some services might insist that all foaf:Person instances have a foaf:name. 2. We need RDF::RDFa::Linter which uses RDF::RDFa::Parser to parse an RDFa document, auto-correcting missing CURIE bindings (but remembering the error) using the information from a service's 'usual_prefixes' method, filters using the service's 'filter' function, and generates warnings based on the 'required_predicates'. 3. We need RDF::RDFa::Writer::Pretty to take an RDF graph and write it out as pretty, human-readable RDFa. As well as the graph, it should be able to take a collection of warnings (each of which has a subject resource URI or bnode identifier associated with it), and include them in the output. 4. Lastly, we'd need to wrap it up in a web form that asks for a URI and then presents the results of the various linters in a nice, tabbed interface. This seems like a lot of "we need" rather than "we have" given that I've already said that the Perl RDF modules cover a lot of what we need. What we already have that should prove useful: - An RDF parser that supports tag soup HTML, and provides onprefix, oncurie and ontriple callbacks that would be needed for this; and - A decent framework for querying the resulting graph for the "required predicates". I'm going to have a go at #3 this evening on my train journey, because I've been wanting something similar for other purposes anyway. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100505144846.4d60f8a9%40miranda.g5n.co.uk Re: Design rationale behind the current schema for Facebook Open Graph Protocol 2010-05-05T13:48:46 2010-05-05T13:48:46 2010-05-05T13:48:46 On Sat, 01 May 2010 17:35:30 -0400 Peter Mika <pmika@yahoo-inc.com> wrote: > Would you take a crack at it? In a similar fashion, an OGP to JSON > mapping would be also highly desirable, otherwise implementations > will diverge on the JSON serialization. At http://srv.buzzword.org.uk/opengraph-to-json.html I do the following: 1. Parse the input document as RDFa; 2. Create a new, empty associat... On Sat, 01 May 2010 17:35:30 -0400 Peter Mika <pmika@yahoo-inc.com> wrote: > Would you take a crack at it? In a similar fashion, an OGP to JSON > mapping would be also highly desirable, otherwise implementations > will diverge on the JSON serialization. At http://srv.buzzword.org.uk/opengraph-to-json.html I do the following: 1. Parse the input document as RDFa; 2. Create a new, empty associative array called $RV. 3. Run a query equivalent to: SELECT $predicate $object WHERE { <> $predicate $object . FILTER(!isBlank($object)) } 4. For each row of results: If $predicate is in the OGP namespace, trim the OGP namespace away; If $RV[$predicate] is not defined, set it to an empty array; If $RV[$object] is a URI, push it onto the array $RV[$predicate]; If $RV[$object] is a literal, push the plain value onto the array $RV[$predicate]. 5. Return $RV as JSON. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100509220255.41bd6263%40miranda.g5n.co.uk Public domain icons 2010-05-09T21:02:55 2010-05-09T21:02:55 2010-05-09T21:02:55 I'm writing an RDF linter/visualiser and need some icons, preferably public domain. I've been using Tango, but they don't cover all the concepts I need. I want a coherent icon set covering the following: - Person - Organisation - Group (of people) - Document - Project - Book - Video/Film - Song - Album - Event - Place - Review - Other/Generic - Unknown Anyone have any pointers? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I'm writing an RDF linter/visualiser and need some icons, preferably public domain. I've been using Tango, but they don't cover all the concepts I need. I want a coherent icon set covering the following: - Person - Organisation - Group (of people) - Document - Project - Book - Video/Film - Song - Album - Event - Place - Review - Other/Generic - Unknown Anyone have any pointers? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100515201637.5c9d5e23%40miranda.g5n.co.uk Re: Linking a vCard to its holder 2010-05-15T19:16:37 2010-05-15T19:16:37 2010-05-15T19:16:37 On Fri, 14 May 2010 14:23:47 +0100 Ian Davis <lists@iandavis.com> wrote: > http://open.vocab.org/terms/businessCard Nathan has also posted this, but http://purl.org/uF/hCard/terms/hasCard has pretty much identical semantics. It's part of a vocabulary I put together a couple of years ago that I needed for parsing hCard into RDF. I revised it a few days ago to clean it up a little as I've recently been making some big changes to my microformats parser. I'd gladly take any suggestions for improvements. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 14 May 2010 14:23:47 +0100 Ian Davis <lists@iandavis.com> wrote: > http://open.vocab.org/terms/businessCard Nathan has also posted this, but http://purl.org/uF/hCard/terms/hasCard has pretty much identical semantics. It's part of a vocabulary I put together a couple of years ago that I needed for parsing hCard into RDF. I revised it a few days ago to clean it up a little as I've recently been making some big changes to my microformats parser. I'd gladly take any suggestions for improvements. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100515205840.5c4ed10b%40miranda.g5n.co.uk Re: Migrating from slash to fragment 2010-05-15T19:58:40 2010-05-15T19:58:40 2010-05-15T19:58:40 On Fri, 14 May 2010 17:53:50 +0100 Nathan <nathan@webr3.org> wrote: > I'm wondering if there are any recommended paths for migrating RDF or > specifically an ontology from slash to fragment URIs (?) Cool URIs don't change. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 14 May 2010 17:53:50 +0100 Nathan <nathan@webr3.org> wrote: > I'm wondering if there are any recommended paths for migrating RDF or > specifically an ontology from slash to fragment URIs (?) Cool URIs don't change. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100517001532.6442dcc4%40miranda.g5n.co.uk Fw: OGP Validator 2010-05-16T23:15:32 2010-05-16T23:15:32 2010-05-16T23:15:32 I just announced this on the Open Graph Protocol mailing list. I'm putting together an RDFa linter that aims to check how well a page conforms to the flavours of RDFa understood by various consumers. So far I'm only got Facebook's OGP covered, but now that most of the framework's in place, it should be pretty easy to write modules for other consumers (e.g. Google, Yahoo, ccRel, etc). Begin for... I just announced this on the Open Graph Protocol mailing list. I'm putting together an RDFa linter that aims to check how well a page conforms to the flavours of RDFa understood by various consumers. So far I'm only got Facebook's OGP covered, but now that most of the framework's in place, it should be pretty easy to write modules for other consumers (e.g. Google, Yahoo, ccRel, etc). Begin forwarded message: Date: Mon, 17 May 2010 00:08:59 +0100 From: Toby Inkster <mail@tobyinkster.co.uk> To: Open Graph Protocol <open-graph-protocol@googlegroups.com> Subject: OGP Validator I've been doing a little work on an RDFa validator/linter library and to begin with have been looking at validating the Open Graph Protocol, because it's a small, simple set of terms. As an early demonstration, I've put up an OGP validator here: http://srv.buzzword.org.uk/opengraph-validator.cgi?url= Just plug in the URL of the page to check ('http:' only - no other URL schemes allowed). Some examples: http://srv.buzzword.org.uk/opengraph-validator.cgi?url=http://opengraphprotocol.org/ http://srv.buzzword.org.uk/opengraph-validator.cgi?url=http://uk.rottentomatoes.com/m/1198124-shutter_island/ This is the first step in an RDFa validation service that will cover not just OGP, but also check the RDFa understood by Google, Yahoo and various other services. This will all be open sourced soonish. Feedback to this mailing list or to my personal address is welcomed! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100517081753.2c37dcba%40miranda.g5n.co.uk Re: RDFa DOM API Document update 2010-05-17T07:17:53 2010-05-17T07:17:53 2010-05-17T07:17:53 On Sun, 16 May 2010 21:50:18 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/Overview-src.html How exactly do these getElementsByX methods work? Although RDFa defines how to generate an RDF graph from a DOM tree, it doesn't offer a clear and unambiguous mapping back from the RDF graph to DOM nodes. For example: <a about="#me" typeof="... On Sun, 16 May 2010 21:50:18 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/Overview-src.html How exactly do these getElementsByX methods work? Although RDFa defines how to generate an RDF graph from a DOM tree, it doesn't offer a clear and unambiguous mapping back from the RDF graph to DOM nodes. For example: <a about="#me" typeof="foaf:Person" rel="foaf:homepage" href="http://example.com/"> <span rel="rdf:type" resource="[foaf:Document]" property="dc:title">My Homepage</span> </a> <i about="#me" property="foaf:name">Joe</i> What element would be returned in the case of getElementsByType('foaf:Person')? Presumably the <a> element because it set the subject for the {?thing rdf:type foaf:Person} triple. But what about the getElementsByType('foaf:Document')? If we apply the same reasoning, it would be the <a> element too. Would the <i> element be selected by getElementsByType('foaf:Person')? After all, we know #me is a foaf:Person. As much as I think these getElementsByX methods would be useful, I don't think they can be implemented in an especially obvious, consistent and predictable way. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100517112106.15afcd81%40miranda.g5n.co.uk Re: On ISSUE-6 (invalid values in @datatypes cause plain literals to be generated) 2010-05-17T10:21:06 2010-05-17T10:21:06 2010-05-17T10:21:06 On Mon, 17 May 2010 12:04:40 +0200 Ivan Herman <ivan@w3.org> wrote: > - @datatype="***goofy***" is not an NCNAME ie, it is not a term; it > does not lead to a proper CURIE either because (prefix must be an > NCNAME); ie, it has to be processed as a URI, yielding the URI: > > http://baseuri/***goofy*** I was under the impression that the TERMorCURIEorURI attributes required full URIs, not just ... On Mon, 17 May 2010 12:04:40 +0200 Ivan Herman <ivan@w3.org> wrote: > - @datatype="***goofy***" is not an NCNAME ie, it is not a term; it > does not lead to a proper CURIE either because (prefix must be an > NCNAME); ie, it has to be processed as a URI, yielding the URI: > > http://baseuri/***goofy*** I was under the impression that the TERMorCURIEorURI attributes required full URIs, not just relative URI references, though this doesn't seem to be mentioned in the current core draft. There seem to be very few use cases where relative references in @property, @rel, @rev, @datatype or @typeof would come in handy. Can we clarify this either way in the next draft? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100517132349.2d2e1e35%40miranda.g5n.co.uk Re: On ISSUE-6 (invalid values in @datatypes cause plain literals to be generated) 2010-05-17T12:23:49 2010-05-17T12:23:49 2010-05-17T12:23:49 On Mon, 17 May 2010 13:31:46 +0200 Ivan Herman <ivan@w3.org> wrote: > So, in mind mind, the question does not arise in these terms but > rather: what is the specific problem that forces us to artificially > disallow relative URI-s? > > Note that the frequent usage for attribute values is something like > > @datatype="blabla" > > which will NOT be a relative URI, but will be interpreted (if > ... On Mon, 17 May 2010 13:31:46 +0200 Ivan Herman <ivan@w3.org> wrote: > So, in mind mind, the question does not arise in these terms but > rather: what is the specific problem that forces us to artificially > disallow relative URI-s? > > Note that the frequent usage for attribute values is something like > > @datatype="blabla" > > which will NOT be a relative URI, but will be interpreted (if > possible) as a term. This is precisely the specific problem that should force us to disallow relative URIs. If people think they can use relative URIs, they'll use things like datatype="foo.html", but that will be interpreted as a term, as "." is allowed in NCNames. The rules on when something is interpreted as a relative URI reference and when it's interpreted as a token would be confusing to authors. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100519114301.5f2244c8%40miranda.g5n.co.uk RDFa linter - announcement and request 2010-05-19T10:43:01 2010-05-19T10:43:01 2010-05-19T10:43:01 First, the announcement: This is still in the very early stages, but hopefully you can see the direction I'm going with it: Just plug a URL into here: http://srv.buzzword.org.uk/rdfa-check/check.cgi?url= For example: http://srv.buzzword.org.uk/rdfa-check/check.cgi?url=http://opengraphprotocol.org/ http://srv.buzzword.org.uk/rdfa-check/check.cgi?url=http://tobyinkster.co.uk/ http://srv.buzzwo... First, the announcement: This is still in the very early stages, but hopefully you can see the direction I'm going with it: Just plug a URL into here: http://srv.buzzword.org.uk/rdfa-check/check.cgi?url= For example: http://srv.buzzword.org.uk/rdfa-check/check.cgi?url=http://opengraphprotocol.org/ http://srv.buzzword.org.uk/rdfa-check/check.cgi?url=http://tobyinkster.co.uk/ http://srv.buzzword.org.uk/rdfa-check/check.cgi?url=http://www.w3.org/ Other services I'm planning to add support for include Google, Yahoo and FOAF+SSL. This is all open source; the code is at http://goddamn.co.uk/viewvc/perlmods/ Now the request: Is there anyone willing to give this service a home? Right now it's hosted on my home computer, which is reasonably powerful, but only on an ADSL connection. It seems that the existence of this linting service is probably beneficial to all RDFa consumers, especially those with tabs along the top, so perhaps a big RDFa consumer like Creative Commons, Google, etc would be willing to offer me a spare server to host it on. I need an account on a Linux/Unix box with Perl 5.8 or above installed, and SSH access to it. Oh and another request: Anyone with any ideas about how to improve the service? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100519131933.1cafef42%40miranda.g5n.co.uk Re: RDFa DOM API Document update 2010-05-19T12:19:33 2010-05-19T12:19:33 2010-05-19T12:19:33 On Tue, 18 May 2010 23:25:53 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > Doing this has the effect of keeping track of all of the *objects* in > the tree (in the RDF sense of objects, not the OO sense), because it's > always objects that cause triples to be generated. (@typeof is not an > exception -- it just happens to be an abbreviation for a > predicate/object pair.) Just to b... On Tue, 18 May 2010 23:25:53 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > Doing this has the effect of keeping track of all of the *objects* in > the tree (in the RDF sense of objects, not the OO sense), because it's > always objects that cause triples to be generated. (@typeof is not an > exception -- it just happens to be an abbreviation for a > predicate/object pair.) Just to be difficult, sometimes the subject causes the triples to be generated. e.g. <div resource="[foaf:Person]"> <p property="ex:note">Here are some foaf:Persons.</p> <ul rev="rdf:type"> <li src="#alice" property="foaf:name">Alice</li> <li src="#bob" property="foaf:name">Bob</li> <li src="#carol" property="foaf:name">Carol</li> </ul> </div> Though in that particular case, the subject node is probably more useful to return! And to answer Manu's question, yes, this technique does satisfy me. It might not always return the best possible node, but at least it's a fairly simple and predictable rule. We need to explicitly state it somewhere though! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100519133648.1085ff3f%40miranda.g5n.co.uk Re: RDFa DOM API (Fully merged) 2010-05-19T12:36:48 2010-05-19T12:36:48 2010-05-19T12:36:48 On Wed, 19 May 2010 00:08:28 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/ I really don't like some of the method names. In particular, the document.getObjectsByX names are galling given that their function is to get groups of statements sharing a common *subject* (not object). For anyone just starting out with RDF and RDFa, who has ... On Wed, 19 May 2010 00:08:28 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/ I really don't like some of the method names. In particular, the document.getObjectsByX names are galling given that their function is to get groups of statements sharing a common *subject* (not object). For anyone just starting out with RDF and RDFa, who has just grasped the notion of subject, predicate and object, the following method name will make their head asplode... document.getObjectsBySubject How about renaming them getItemsByX? Or is that too close to Microdata's API. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100519154546.750b472e%40miranda.g5n.co.uk Re: RDFa linter - announcement and request 2010-05-19T14:45:46 2010-05-19T14:45:46 2010-05-19T14:45:46 On Wed, 19 May 2010 16:35:38 +0200 "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com> wrote: > How about an upload facility for people who want to check offline > files? That's a good idea. Not sure how relative links would be parsed in that situation, but I'll have a think about it. Perhaps the "cid:" URL scheme could be used in some way. I don't think keeping the links relative is ... On Wed, 19 May 2010 16:35:38 +0200 "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com> wrote: > How about an upload facility for people who want to check offline > files? That's a good idea. Not sure how relative links would be parsed in that situation, but I'll have a think about it. Perhaps the "cid:" URL scheme could be used in some way. I don't think keeping the links relative is an option - my entire code infrastructure more or less assumes that they're absolute. Similarly, the ability to paste chunks of code seems desirable. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100519160936.5797ea02%40miranda.g5n.co.uk Re: RDFa linter - announcement and request 2010-05-19T15:09:36 2010-05-19T15:09:36 2010-05-19T15:09:36 On Wed, 19 May 2010 16:52:47 +0200 "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com> wrote: > You could force base/@href to be populated, or assume a value of > http://www.example.com/, maybe? I'm considering assuming a default value of "widget://x.rdfa/" (the "widget" URL scheme is defined in a working draft from the W3C Web Applications WG) where "x" is the SHA1 sum of the file uploaded. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 19 May 2010 16:52:47 +0200 "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com> wrote: > You could force base/@href to be populated, or assume a value of > http://www.example.com/, maybe? I'm considering assuming a default value of "widget://x.rdfa/" (the "widget" URL scheme is defined in a working draft from the W3C Web Applications WG) where "x" is the SHA1 sum of the file uploaded. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100523193313.1bb1a366%40miranda.g5n.co.uk Re: HTML5 Profiles - First Editors Draft 2010-05-23T18:33:13 2010-05-23T18:33:13 2010-05-23T18:33:13 On Sat, 22 May 2010 11:38:43 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > The first draft of the HTML5 Profiles document is ready for feedback. > It's a tiny spec, which will hopefully mean that reviews will be quick > and we can decide whether to do a FPWD on it or kill it. I support it in principle. Scoped profiles for microformats would cause me personal aggravation as it would req... On Sat, 22 May 2010 11:38:43 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > The first draft of the HTML5 Profiles document is ready for feedback. > It's a tiny spec, which will hopefully mean that reviews will be quick > and we can decide whether to do a FPWD on it or kill it. I support it in principle. Scoped profiles for microformats would cause me personal aggravation as it would require a lot of reworking for my microformat parser (which currently uses profiles only on a document-wide basis), but it's a good idea, so something I'd be prepared to support. It's potentially very useful, especially in the case of transclusions, where you might grab a snippet of HTML from a trusted API and insert it into your own page. A few thoughts on the current draft: * Currently @profile is only allowed on <head>, so there is a convention that profiles found on that element are allowed to apply to the entire document. Microformats currently use this, with profiles found on <head> applying to microformats which are pretty consistently used in <body>. GRDDL does too. * The relationship to GRDDL needs to be clarified; should GRDDL processors continue to only look for profiles on <head> and ignore others? If profiles are found on other elements, should only the subtree be passed through the GRDDL transformation? * "When processing attribute values, each URI must be processed from left to right" - firstly this is ambiguous, does it merely define a chronological order that processors must use (in which case, why rule out parallel processing?) or does it mean that profiles to the right over-rule profiles to the left in the case of conflicts? If the latter, this is consistent with the current RDFa Core 1.1 draft, but at odds with the XMDP specification which says that profiles to the left win in the case of conflicts. There is IIRC an open issue on the RDFa WG tracker about this. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100523195608.55e1d250%40miranda.g5n.co.uk Re: Migrating from slash to fragment 2010-05-23T18:56:08 2010-05-23T18:56:08 2010-05-23T18:56:08 On Tue, 18 May 2010 19:39:02 +0900 "KangHao Lu (Kenny)" <kennyluck@csail.mit.edu> wrote: > I think this can be generalized and it shouldn't be con:preferredURI > but something like link:preferredURI. Have you taken a look at <http://purl.org/NET/uri#>? It's a vocab for talking about the different URIs that a thing has. I've just added an extra term for indicating that a particular URI is preferred by someone. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 18 May 2010 19:39:02 +0900 "KangHao Lu (Kenny)" <kennyluck@csail.mit.edu> wrote: > I think this can be generalized and it shouldn't be con:preferredURI > but something like link:preferredURI. Have you taken a look at <http://purl.org/NET/uri#>? It's a vocab for talking about the different URIs that a thing has. I've just added an extra term for indicating that a particular URI is preferred by someone. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100524213706.2d978f32%40miranda.g5n.co.uk Re: Noembed markup 2010-05-24T20:37:06 2010-05-24T20:37:06 2010-05-24T20:37:06 On Fri, 21 May 2010 11:42:35 +0200 "Aude Ogier" <a.ogier@solvimo.com> wrote: > Can you tell me the valid W3C code that replaces the markup <noembed> > (displayed by browsers wich cannot read the elements of the embed > tag) ? You'd be better off asking this on public-html@w3.org - it's not really got anything to do with the Semantic Web. But, try using <object> instead of <embed>. <object> can ... On Fri, 21 May 2010 11:42:35 +0200 "Aude Ogier" <a.ogier@solvimo.com> wrote: > Can you tell me the valid W3C code that replaces the markup <noembed> > (displayed by browsers wich cannot read the elements of the embed > tag) ? You'd be better off asking this on public-html@w3.org - it's not really got anything to do with the Semantic Web. But, try using <object> instead of <embed>. <object> can contain fallback content for browsers that are unable to render the object. e.g. <object data="myvideo.mpeg" type="video/mpeg" height="240" width="320"> <p>Please download and watch <a href="myvideo.mpeg" >my video of an elephant</a>.</p> </object> Browsers that can't render the object render the paragraph instead. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100525103247.54461d95%40miranda.g5n.co.uk Re: Potentials of the RDFa DOM API 2010-05-25T09:32:47 2010-05-25T09:32:47 2010-05-25T09:32:47 On Tue, 25 May 2010 10:19:49 +0200 Ivan Herman <ivan@w3.org> wrote: > it is also not 100% whether the community would accept and/or would > be interested in having a standard RDF API. What language(s) (Java, > Python, Javascript, etc)? What happens to the deployed applications > of Jena vs. Sesame vs. Redland vs....? Etc, etc. As far as having a standard common API for RDF in general, we already... On Tue, 25 May 2010 10:19:49 +0200 Ivan Herman <ivan@w3.org> wrote: > it is also not 100% whether the community would accept and/or would > be interested in having a standard RDF API. What language(s) (Java, > Python, Javascript, etc)? What happens to the deployed applications > of Jena vs. Sesame vs. Redland vs....? Etc, etc. As far as having a standard common API for RDF in general, we already do: Jena, Sesame and Redland already all provide SPARQL. Once SPARQL Update is more standardised, that API will become read-write. The RDFa DOM API is something different though, distinguishing itself from existing RDF APIs by taking advantage of RDFa's embeddedness in host languages, integrating with the existing API of the host language (i.e. the HTML/XML DOM). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100525104811.2e70d305%40miranda.g5n.co.uk Re: HTML5 Profiles - First Editors Draft 2010-05-25T09:48:11 2010-05-25T09:48:11 2010-05-25T09:48:11 On Mon, 24 May 2010 22:11:30 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > It's the latter. That's a good summary of the situation. I don't quite > understand the reasoning behind XMDP where the first profile overrules > all other profiles in the attribute. Anyone on here know the reasoning > behind that decision? It seems backwards. It's because the HTML 4 rec states that only the firs... On Mon, 24 May 2010 22:11:30 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > It's the latter. That's a good summary of the situation. I don't quite > understand the reasoning behind XMDP where the first profile overrules > all other profiles in the attribute. Anyone on here know the reasoning > behind that decision? It seems backwards. It's because the HTML 4 rec states that only the first profile in the list is significant, the others being ignored. XMDP revises this to say that the first is most significant, and others are listed in decreasing significance. Why does HTML 4 make it a whitespace separated list of URIs, if all but the first should be ignored? Because they recognised the possible future need for multiple profiles, and wanted to make sure that any consuming tools were equipped to split the list on spaces. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100526094157.04ad3ea3%40miranda.g5n.co.uk for telecon: ISSUE-25 @profile Document Retrieval Failure 2010-05-26T08:41:57 2010-05-26T08:41:57 2010-05-26T08:41:57 The issue: assume that profiles 'a' and 'b' both define the term 'Person' as tokens for different URIs. Additionally, assume that 'b' defines the prefix 'dc' to point to 'http://purl.org/dc/terms/'. Then: <html profile="http://example.com/a" prefix="dc: http://purl.org/dc/elements/1.1/ foaf: http://xmlns.com/foaf/0.1/"> ... <body profile="http://example.net/b"> <address> ... The issue: assume that profiles 'a' and 'b' both define the term 'Person' as tokens for different URIs. Additionally, assume that 'b' defines the prefix 'dc' to point to 'http://purl.org/dc/terms/'. Then: <html profile="http://example.com/a" prefix="dc: http://purl.org/dc/elements/1.1/ foaf: http://xmlns.com/foaf/0.1/"> ... <body profile="http://example.net/b"> <address> Last modified by <a typeof="Person" rel="foaf:homepage" href="/joe" property="foaf:name">Joe Bloggs</a> on <span property="dc:modified">2010-05-26</span>. </address> </body> </html> If profile 'b' is inaccessible (e.g. the host example.net is down temporarily or permanently) then an RDFa processor will create erroneous triples. typeof="Person" will be mapped to its definition from profile 'a'; and the 'dc' in 'dc:modified' will be mapped to the older Dublin Core 1.1 URI, which does not define a property called 'modified'. The suggested solution, originally from Jeni Tennison is that when parsers encounter a profile URI that cannot be retrieved, they should not process that subtree. My interpretation/clarification of this is: If the profile does not return an HTTP 200 status (or equivalent for any non-HTTP profile URIs) possibly after following some redirections, then the profile is a "Failed Profile". If the profile is delivered in a media type or dialect which the RDFa processor is not able to handle (e.g. delivered in Turtle to a processor that cannot handle Turtle), it is also deemed a Failed Profile. Having processed @profile, if any of the profiles are Failed Profiles, then an RDFa processor cannot continue. It completes any incomplete triples using the following method to determine the subject of incomplete forward triples / object of incomplete reversed triples: 1. if @about is set to a relative URI, use that; 2. otherwise, if @about is set, use a new blank node; 3. otherwise, if @src is set, use that; 4. otherwise, if @resource is set to a relative URI, use that; 5. otherwise, if @resource is set, use a new blank node; 6. otherwise, if @href is set, use that; 7. otherwise, use a new blank node. Note that this method will result in any token containing a colon resulting in a blank node - this is because it becomes impossible to determine whether that token represents a CURIE that would have been defined by the Failed Profile, or is an absolute URI. Descendant elements are then not processed. I'll add that there is actually a safe subset of RDFa to process within the subtree of Failed Profiles, however the rules for determining this safe subset are complex, so for the sanity of RDFa publishers, it's simpler to say that a Failed Profile causes the subtree to be ignored. For the record though, a method for continuing parsing safely is: * when a parser encounters a Failed Profile, it empties the local lists of prefix mappings and terms. * it continues processing (including processing other profiles, as the @profile attribute is a list of profiles) with a small modification in behaviour - when a token is encountered that matches the CURIE syntax but does not match a prefix mapping, instead of assuming that it's an absolute URI, the parser assumes it's an undefined value. I don't recommend that method though as it might lead to confusion amongst authors. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100526094537.1124e0fc%40miranda.g5n.co.uk for telecon: ISSUE-23 @profile order 2010-05-26T08:45:37 2010-05-26T08:45:37 2010-05-26T08:45:37 Currently RDFa Core 1.1 says that when @profile includes multiple profiles, e.g. profile="http://example.com/a http://example.net/b" these are processed from left to right. This means that if a particular term or prefix is defined in both profiles, then the definition in the latter profile "wins". If we were defining RDFa in isolation, this might make perfect sense, but @profile is an attribut... Currently RDFa Core 1.1 says that when @profile includes multiple profiles, e.g. profile="http://example.com/a http://example.net/b" these are processed from left to right. This means that if a particular term or prefix is defined in both profiles, then the definition in the latter profile "wins". If we were defining RDFa in isolation, this might make perfect sense, but @profile is an attribute from HTML 4 and is (at least theoretically, though often not in practise) used by microformats, so we need to take into account this historical baggage. HTML 4 defines @profile as a list but says that only the first URI is deemed to be significant, the rest being ignored. If we make allow later profiles to overrule the first profile, then this seems at odds with HTML 4 - we're saying that later profiles are more significant than the first. XMDP, the profile format used by microformats, extends the definition of @profile by saying that profiles are listed in descending significance. This means that when a term is defined in two profiles, the first profile wins. If we do this the other way around, it may prove an annoyance for people wishing to publish hybrid RDFa/microformats documents. It seems apt to mention GRDDL if only in passing. In GRDDL it doesn't matter which order you process profiles in. That's fine. Lastly, let's think about human psychology. We tend to employ a technique called cognitive frontloading - i.e. we get the most important things out of the way first. That means, if there's a bunch of profiles I'm going to type into a list, chances are that I'm going to type in the most important ones first. Given that, it makes sense for us to allow earlier profiles to override later ones. So my proposal is for RDFa Core 1.1 to state that profiles are handled from right to left. As an aside, we may wish to mention somewhere that implementations should be free to download and parse the profiles in any order, or in parallel. What's important is that the terms and prefixes defined in them are added to the lists of terms and prefixes in the correct order. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100526105614.25c7aec0%40miranda.g5n.co.uk for telecon: check.rdfa 2010-05-26T09:56:14 2010-05-26T09:56:14 2010-05-26T09:56:14 Hoping to discuss this on the telecon under "any other business". I've been tinkering with an RDFa linter, currently to be found at: http://check.rdfa.info/ The idea is to parse a page for RDFa, then filter it in different ways to show you what various services see. e.g. Google only looks at properties and classes defined at <http://rdf.data-vocabulary.org/#>; Facebook only looks at the Open G... Hoping to discuss this on the telecon under "any other business". I've been tinkering with an RDFa linter, currently to be found at: http://check.rdfa.info/ The idea is to parse a page for RDFa, then filter it in different ways to show you what various services see. e.g. Google only looks at properties and classes defined at <http://rdf.data-vocabulary.org/#>; Facebook only looks at the Open Graph Protocol properties. It also performs some general linting like detecting the use of CURIEs with undefined prefixes, etc. I'd appreciate people's feedback. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100527221025.3ee5890b%40miranda.g5n.co.uk Re: for telecon: check.rdfa 2010-05-27T21:10:25 2010-05-27T21:10:25 2010-05-27T21:10:25 On Wed, 26 May 2010 10:56:14 +0100 Toby Inkster <tai@g5n.co.uk> wrote: > Hoping to discuss this on the telecon under "any other business". > http://check.rdfa.info/ Unicode handling problems were discussed this afternoon. I think I have these fixed now. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 26 May 2010 10:56:14 +0100 Toby Inkster <tai@g5n.co.uk> wrote: > Hoping to discuss this on the telecon under "any other business". > http://check.rdfa.info/ Unicode handling problems were discussed this afternoon. I think I have these fixed now. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100529230800.7ef084e8%40miranda.g5n.co.uk Re: RDFa DOM API - New Editor's Draft 2010-05-29T22:08:00 2010-05-29T22:08:00 2010-05-29T22:08:00 On Sat, 29 May 2010 13:56:45 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > I agree... Mark and I have been trying to find another name for > "Property Groups" for a few weeks now... here's what we've already > discussed, and rejected: > > Extendos > Web Objects > Dynamic Objects > Data Objects > Structured Data Containers Here are a few ideas: * Resource Objects * Resources * Web Resources * DataThings -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 29 May 2010 13:56:45 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > I agree... Mark and I have been trying to find another name for > "Property Groups" for a few weeks now... here's what we've already > discussed, and rejected: > > Extendos > Web Objects > Dynamic Objects > Data Objects > Structured Data Containers Here are a few ideas: * Resource Objects * Resources * Web Resources * DataThings -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100530095636.0949d3f4%40miranda.g5n.co.uk Re: JSON-LD - experimenting with universal Linked Data markup for Web Services 2010-05-30T08:56:36 2010-05-30T08:56:36 2010-05-30T08:56:36 On Sat, 29 May 2010 21:06:31 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://rdfa.digitalbazaar.com/specs/source/json-ld/ The document at several times uses the term "unambiguous", but I don't think it is. For example, it says: In order to differentiate between plain text and IRIs, the < and > are used around IRIs. But what about plain text that happens to start with "<" ... On Sat, 29 May 2010 21:06:31 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://rdfa.digitalbazaar.com/specs/source/json-ld/ The document at several times uses the term "unambiguous", but I don't think it is. For example, it says: In order to differentiate between plain text and IRIs, the < and > are used around IRIs. But what about plain text that happens to start with "<" and end with ">"? For example: { "dc:abstract" : "A discussion of the abbreviations in HTML.", "dc:title" : "<abbr> versus <acronym>" } Also, if you imagine the following two RDFa snippets, with different meanings, they seem to have the same representation in JSON-LD: <!-- snippet 1 --> <div typeof=""> <span property="dc:modified" datatype="xsd:dateTime">2010-05-29T14:17:39+02:00</span> </div> <!-- snippet 2 --> <div typeof=""> <span property="dc:modified">2010-05-29T14:17:39+02:00</span> <span property="dc:modified">^^xsd:dateTime</span> </div> Both are represented as: { "dc:modified" : ["2010-05-29T14:17:39+02:00", "^^xsd:dateTime"] } This could possibly be addressed by representing datatyped values like this (i.e. similarly to RDF/JSON): { "dc:modified" : { "value" : "2010-05-29T14:17:39+02:00", "datatype" : "xsd:dateTime", } } A solution like that would also handle the edge case of plain text literals that begin with '<' and end with '>'. You could insist that whenever a plain text value begins and ends like that, it must be written out in "longhand" form: { "dc:abstract" : "A discussion of the abbreviations in HTML.", "dc:title" : { "value":"<abbr> versus <acronym>" } } How language tags are represented is not mentioned in the document, but they could perhaps be handled similarly to datatypes. > Just getting some thoughts that Mark and I have been exploring over > the past two weeks down. No intention of publishing via this WG at the > moment... perhaps via HTML WG? or WebApps? Or working with industry to > see how it works in the field and then bringing it into W3C. It seems pretty far out of scope for HTMLWG. Perhaps SWIG? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100603231416.6c8550be%40miranda.g5n.co.uk Re: Comment re SPARQL 1.1 Service Description 2010-06-03T22:14:16 2010-06-03T22:14:16 2010-06-03T22:14:16 A suggestion I've made before is for /.well-known/sparql to be the host's main/preferred SPARQL endpoint. This currently works on my own site: http://tobyinkster.co.uk/.well-known/sparql -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> A suggestion I've made before is for /.well-known/sparql to be the host's main/preferred SPARQL endpoint. This currently works on my own site: http://tobyinkster.co.uk/.well-known/sparql -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1275651033.4259.33.camel%40ophelia2.g5n.co.uk Re: Removing triples from a store? 2010-06-04T11:30:35 2010-06-04T11:30:35 2010-06-04T11:30:35 On Fri, 2010-06-04 at 10:36 +0200, Ivan Herman wrote: > There is currently no method to remove a triple from a store. I wonder > whether there are reasons to add this facility... Right now, I suppose the workaround would be to create a new store, iterate through the old store, adding each triple to the new one except for those you wanted to remove, and then replace any references to the old store with references to the new store. That's not an especially nice solution though. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2010-06-04 at 10:36 +0200, Ivan Herman wrote: > There is currently no method to remove a triple from a store. I wonder > whether there are reasons to add this facility... Right now, I suppose the workaround would be to create a new store, iterate through the old store, adding each triple to the new one except for those you wanted to remove, and then replace any references to the old store with references to the new store. That's not an especially nice solution though. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1275663727.4259.41.camel%40ophelia2.g5n.co.uk Re: Removing triples from a store? 2010-06-04T15:02:09 2010-06-04T15:02:09 2010-06-04T15:02:09 On Fri, 2010-06-04 at 15:37 +0100, Martin McEvoy wrote: > Not an easy task, the simplest approach I would say is not let them > get in there in the first place... you could introduce an attribute > for this task > > <div exclude="foo bar"> > <a rel="bookmark foo bar" href="http://...">...</a> > </div> > > exclude could be used to "exclude" a triple from the graph. There are various (albeit hac... On Fri, 2010-06-04 at 15:37 +0100, Martin McEvoy wrote: > Not an easy task, the simplest approach I would say is not let them > get in there in the first place... you could introduce an attribute > for this task > > <div exclude="foo bar"> > <a rel="bookmark foo bar" href="http://...">...</a> > </div> > > exclude could be used to "exclude" a triple from the graph. There are various (albeit hackish) ways of excluding elements from processing already; e.g. <div profile="urn:x-rdfa-ignore"> ... an RDFa processor should ignore everything here ... </div> or (I think!) <div property="" datatype="rdf:XMLLiteral"> ... an RDFa processor should ignore everything here ... </div> This thread is more about asking how a piece of Javascript, which has parsed some RDFa into a Store can then remove some triples from the Store. For example, a script parses a page and then deletes any xhv:stylesheet triples because it finds them boring. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100606101858.39aea2e6%40miranda.g5n.co.uk Re: Request for Feedback, Suggestions on TaxonConcept Species Concepts 2010-06-06T09:18:58 2010-06-06T09:18:58 2010-06-06T09:18:58 On Fri, 4 Jun 2010 18:06:08 -0500 Peter DeVries <pete.devries@gmail.com> wrote: > I would appreciate feedback on these models and any suggestions for > how they could be improved. :-) The following: @prefix txn: <http://lod.taxonconcept.org/ontology/txn.owl#> . <http://lod.taxonconcept.org/ses/mCcSp#Species> a owl:Class ; txn:kingdom "Animalia" ; txn:phylum "Arthropoda" ; txn:class "Insect... On Fri, 4 Jun 2010 18:06:08 -0500 Peter DeVries <pete.devries@gmail.com> wrote: > I would appreciate feedback on these models and any suggestions for > how they could be improved. :-) The following: @prefix txn: <http://lod.taxonconcept.org/ontology/txn.owl#> . <http://lod.taxonconcept.org/ses/mCcSp#Species> a owl:Class ; txn:kingdom "Animalia" ; txn:phylum "Arthropoda" ; txn:class "Insecta" ; txn:order "Lepidoptera" ; txn:family "Nymphalidae" ; txn:genus "Danaus" ; txn:epithet "plexippus" ; txn:author_year "(Linnaeus, 1758)" ; txn:commonName "Monarch Butterfly" ; foaf:page <foo> . Appears to be an almost identical way of representing a species concept to the one I came up with a couple of years ago: @prefix txn: <http://purl.org/NET/biol/ns#> . <http://lod.taxonconcept.org/ses/mCcSp#Species> a txn:Taxonomy ; # note: txn:Taxonomy rdfs:subClassOf rdfs:Class. txn:kingdom "Animalia" ; txn:phylum "Arthropoda" ; txn:class "Insecta" ; txn:order "Lepidoptera" ; txn:family "Nymphalidae" ; txn:genus "Danaus" ; txn:species "plexippus" ; txn:authority "Linnaeus, 1758" ; txn:commonName "Monarch Butterfly" ; txn:seeAlso <foo> . I wonder if you could reuse the URIs I minted rather than creating new ones? If we could stamp out any incompatibilities between the two ontologies, then I'd be happy to point the http://purl.org/NET/biol/ns URI at your ontology, so we'd just have a single merged ontology. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100608221809.0ce0a326%40miranda.g5n.co.uk RDFa API FPWD published 2010-06-08T21:18:09 2010-06-08T21:18:09 2010-06-08T21:18:09 Just seen this from @w3c on identi.ca. http://www.w3.org/TR/2010/WD-rdfa-api-20100608/ Great news, but quick comment: We have a normative reference on N3 - this is wrong; it should be N-Triples. This was discussed on our call a few weeks ago: http://www.w3.org/2010/02/rdfa/meetings/2010-04-29#line0039 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Just seen this from @w3c on identi.ca. http://www.w3.org/TR/2010/WD-rdfa-api-20100608/ Great news, but quick comment: We have a normative reference on N3 - this is wrong; it should be N-Triples. This was discussed on our call a few weeks ago: http://www.w3.org/2010/02/rdfa/meetings/2010-04-29#line0039 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100609151646.25d5f675%40miranda.g5n.co.uk Re: Describing Images (and similar), and Descriptor discovery. 2010-06-09T14:16:46 2010-06-09T14:16:46 2010-06-09T14:16:46 On Wed, 09 Jun 2010 14:01:32 +0100 Nathan <nathan@webr3.org> wrote: > I'm just wondering what approaches people are taking to describing > non rdf/html resources, such as Images, PDFs and similar? As Michael pointed out, if you consider the RDF document to be a "representation" (in HTTP terminology) of the image, then you can serve both the binary image and the RDF from the same URI using conneg... On Wed, 09 Jun 2010 14:01:32 +0100 Nathan <nathan@webr3.org> wrote: > I'm just wondering what approaches people are taking to describing > non rdf/html resources, such as Images, PDFs and similar? As Michael pointed out, if you consider the RDF document to be a "representation" (in HTTP terminology) of the image, then you can serve both the binary image and the RDF from the same URI using conneg. However, usually an RDF description of an image would considered a separate resource from the image itself. (They're likely to have different dc:created dates, and possibly different dc:creators too.) In this case, they should have separate URIs. For example: http://example.com/image (the image) http://example.com/describe?uri=http://example.com/image (RDF) Or: http://example.com/image (the image) http://example.com/image,about (RDF) So, now that we're serving the image and the RDF as different resources, it becomes a question of how to discover the RDF data given the image's URI. The Web Linking Internet Draft provides a way forward. http://tools.ietf.org/html/draft-nottingham-http-link-header-10 HTTP responses to requests for the image itself would include the following HTTP header (line-wrapped for legibility): Link: </image,about>; rel="describedby"; type="application/rdf+xml" The Web Linking draft is due to become an RFC Real Soon Now, and hopefully once that happens, linked data clients will start adding transparent support for it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100609215333.3a4b05e9%40miranda.g5n.co.uk Re: When is equal and when is it nonequal (eg, the IRI interface) 2010-06-09T20:53:33 2010-06-09T20:53:33 2010-06-09T20:53:33 On Wed, 9 Jun 2010 17:44:41 +0200 Ivan Herman <ivan@w3.org> wrote: > The problem is as follows. In a package like RDFLib, the equality is > fairly simple, it is based on the equality of the URIs (let us put, > for a moment, the issue of IRI vs URI and its encoding aside). > However, our version of the IRI has two attributes: the 'value' and > the 'origin'. Ie, to IRI instances that have the same ... On Wed, 9 Jun 2010 17:44:41 +0200 Ivan Herman <ivan@w3.org> wrote: > The problem is as follows. In a package like RDFLib, the equality is > fairly simple, it is based on the equality of the URIs (let us put, > for a moment, the issue of IRI vs URI and its encoding aside). > However, our version of the IRI has two attributes: the 'value' and > the 'origin'. Ie, to IRI instances that have the same value but > different origins are different. 'origin' as specified needs fixing. Rather than: triple.subject.origin We should have: triple.subjectOrigin That way testing for equivalence between IRIs, Blank nodes and Literals becomes obvious. <> rdfs:seeAlso <http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Apr/0161.html>. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100610071736.1e82cbb6%40miranda.g5n.co.uk Re: Telecon Agenda - June 10th 2010, 1400 UTC 2010-06-10T06:17:36 2010-06-10T06:17:36 2010-06-10T06:17:36 On Wed, 09 Jun 2010 23:30:29 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > 2) ISSUE-5: @datatype and rdf:XMLLiteral (on Toby) > http://www.w3.org/2010/02/rdfa/track/issues/5 I have to send my regrets today I'm afraid, but here are my thoughts on the issue... I think this issue is fairly non-contraversial. RDFa 1.0 and 1.1 both do/should require that XML literals are generated when t... On Wed, 09 Jun 2010 23:30:29 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > 2) ISSUE-5: @datatype and rdf:XMLLiteral (on Toby) > http://www.w3.org/2010/02/rdfa/track/issues/5 I have to send my regrets today I'm afraid, but here are my thoughts on the issue... I think this issue is fairly non-contraversial. RDFa 1.0 and 1.1 both do/should require that XML literals are generated when the datatype URI is <http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>. However, the RDFa 1.0 rec was a little ambiguous as to whether this only happened if the @datatype CURIE was literally "rdf:XMLLiteral", or whether "xyz:XMLLiteral" also worked assuming that "xyz" was appropriately bound. The RDFa 1.0 test suite makes it clear that "xyz" or anything else you like should work. But we probably need to clarify in the 1.1 spec that it's the URI you expand the datatype out to that matters, and not the CURIE/token found in the datatype attribute. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100610072727.1b6d38de%40miranda.g5n.co.uk Re: Telecon Agenda - June 10th 2010, 1400 UTC 2010-06-10T06:27:27 2010-06-10T06:27:27 2010-06-10T06:27:27 On Wed, 09 Jun 2010 23:10:46 -0500 Shane McCarron <shane@aptest.com> wrote: > http://www.w3.org/WAI/PF/role-attribute/#using-role-in-conjunction-with-rdfa > > I know that people disagreed with this, but if we could reach a > consensus I have a narrow window when I can update the draft before > publication. I don't think this draft should be attempting to make normative-sounding requirements f... On Wed, 09 Jun 2010 23:10:46 -0500 Shane McCarron <shane@aptest.com> wrote: > http://www.w3.org/WAI/PF/role-attribute/#using-role-in-conjunction-with-rdfa > > I know that people disagreed with this, but if we could reach a > consensus I have a narrow window when I can update the draft before > publication. I don't think this draft should be attempting to make normative-sounding requirements for RDFa processors. Rather, it could say something like: """ When @role is included in a markup language that also includes RDFa Core attributes [RDFA-CORE], a Processor that supports both RDFa and @role MAY provide a graph that includes data from both. In that case, it MUST process the role values as follows: * The subject is the value of @id if present. Otherwise the subject is a unique newly created bnode. * The predicate is the term role in the vocabulary defined at http://www.w3.org/1999/xhtml/vocab. * Each value of @role is an object, forming an RDF triple with the subject and predicate defined above. """ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100610101848.55e8509a%40miranda.g5n.co.uk Re: When is equal and when is it nonequal (eg, the IRI interface) 2010-06-10T09:18:48 2010-06-10T09:18:48 2010-06-10T09:18:48 On Thu, 10 Jun 2010 10:27:54 +0200 Ivan Herman <ivan@w3.org> wrote: > Put it another way, the model for our stores is, say, a 6-store,... > (or a quadstore with the fourth item packaging information about the > 3 DOM nodes). I wonder how many triples the following generates in the API? <div about="#me" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-... On Thu, 10 Jun 2010 10:27:54 +0200 Ivan Herman <ivan@w3.org> wrote: > Put it another way, the model for our stores is, say, a 6-store,... > (or a quadstore with the fourth item packaging information about the > 3 DOM nodes). I wonder how many triples the following generates in the API? <div about="#me" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <span property="foaf:name rdfs:name http://xmlns.com/foaf/0.1/name">Toby Inkster</span> </div> Or how many this generates? <span prefix="owl: http://www.w3.org/2002/07/owl#" about="#alice" resource="#alice" rel="owl:sameAs" rev="owl:sameAs" >Alice, Alice, who the **** is Alice?!</span> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100614083642.5e82ad4e%40miranda.g5n.co.uk Re: Telecon Agenda - June 17th 2010, 1400 UTC 2010-06-14T07:36:42 2010-06-14T07:36:42 2010-06-14T07:36:42 On Sun, 13 Jun 2010 20:26:22 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Toby, Mark, Shane - could you guys please write up a proposed solution > for the issues below by this Thursday? I wrote mine up last week: <http://www.w3.org/mid/20100610071736.1e82cbb6@miranda.g5n.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 13 Jun 2010 20:26:22 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Toby, Mark, Shane - could you guys please write up a proposed solution > for the issues below by this Thursday? I wrote mine up last week: <http://www.w3.org/mid/20100610071736.1e82cbb6@miranda.g5n.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100614160517.3d54ff24%40miranda.g5n.co.uk Re: Announce: java-rdfa 0.4 2010-06-14T15:05:17 2010-06-14T15:05:17 2010-06-14T15:05:17 On Mon, 14 Jun 2010 10:26:30 +0100 Damian Steer <pldms@mac.com> wrote: > * (Finally) support overlapping literals. No one noticed this didn't > work! This reminds me. ODF has an interesting construction which can be thought of like this: <x property="ex:p1">Foo<y property="ex:p2">Bar</x>Baz</y> So you'd get these triples: <> ex:p1 "FooBar" ; ex:p2 "BarBaz" . It uses proper XML though, ... On Mon, 14 Jun 2010 10:26:30 +0100 Damian Steer <pldms@mac.com> wrote: > * (Finally) support overlapping literals. No one noticed this didn't > work! This reminds me. ODF has an interesting construction which can be thought of like this: <x property="ex:p1">Foo<y property="ex:p2">Bar</x>Baz</y> So you'd get these triples: <> ex:p1 "FooBar" ; ex:p2 "BarBaz" . It uses proper XML though, with empty elements to mark the start and end of the literals. Now, those are overlapping literals! I do plan on adding support at some stage... -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100615080454.07ff387c%40miranda.g5n.co.uk Re: Announce: java-rdfa 0.4 2010-06-15T07:04:54 2010-06-15T07:04:54 2010-06-15T07:04:54 On Mon, 14 Jun 2010 16:24:12 +0100 Damian Steer <pldms@mac.com> wrote: > Dear lord, we need Jeni's advice on this. Creole support in RDFa? [1] I can't see it being adopted in RDFa Core. In RDFa 1.1 it's unlikely to fit in the WG's remit - the charter specifies compatibility with 1.0 content (with one exception). And personally I can't see it getting into a future version of RDFa Core either - pr... On Mon, 14 Jun 2010 16:24:12 +0100 Damian Steer <pldms@mac.com> wrote: > Dear lord, we need Jeni's advice on this. Creole support in RDFa? [1] I can't see it being adopted in RDFa Core. In RDFa 1.1 it's unlikely to fit in the WG's remit - the charter specifies compatibility with 1.0 content (with one exception). And personally I can't see it getting into a future version of RDFa Core either - pretty esoteric, though I can see why it can be useful in ODF. From a parsing perspective, it ought not to be too difficult - it's just a fourth pathway for generating literals (the existing three being XML literals, plain literals from the content attribute, and plain literals from text nodes). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100616141823.2fd36517%40miranda.g5n.co.uk Re: 'owl:Class and rdfs:Class' vs. 'owl:Class or rdfs:Class' 2010-06-16T13:18:23 2010-06-16T13:18:23 2010-06-16T13:18:23 On Wed, 16 Jun 2010 14:37:29 +0200 Bob Ferris <zazi@elbklang.net> wrote: > - if one uses OWL features for modelling an ontology, define the > concepts only with owl:Class, because RDFS systems, wouldn't know how > to handle these features I think most times people use OWL for modelling an ontology, they also tend to sprinkle in bits of RDFS (most importantly: rdfs:subPropertyOf, rdfs:subClassOf... On Wed, 16 Jun 2010 14:37:29 +0200 Bob Ferris <zazi@elbklang.net> wrote: > - if one uses OWL features for modelling an ontology, define the > concepts only with owl:Class, because RDFS systems, wouldn't know how > to handle these features I think most times people use OWL for modelling an ontology, they also tend to sprinkle in bits of RDFS (most importantly: rdfs:subPropertyOf, rdfs:subClassOf, rdfs:domain, rdfs:range). So RDFS reasoning systems should still be able to perform some reasoning on the OWL ontology, even if they're not able to infer quite as much as an OWL DL or OWL Full processor. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100616204031.1e86ba2e%40miranda.g5n.co.uk Fw: CPAN Upload: T/TO/TOBYINK/RDF-RDFa-Parser-1.09_11.tar.gz 2010-06-16T19:40:31 2010-06-16T19:40:31 2010-06-16T19:40:31 Begin forwarded message: Date: Wed, 16 Jun 2010 17:36:28 +0100 From: Toby Inkster <mail@tobyinkster.co.uk> To: dev@lists.perlrdf.org Subject: Fw: CPAN Upload: T/TO/TOBYINK/RDF-RDFa-Parser-1.09_11.tar.gz Just uploaded RDF-RDFa-Parser-1.09_11.tar.gz. Biggest change is that support for OpenDocument Format 1.2 is included. OpenDocument 1.2 files are essentially ZIP files that contain a collection o... Begin forwarded message: Date: Wed, 16 Jun 2010 17:36:28 +0100 From: Toby Inkster <mail@tobyinkster.co.uk> To: dev@lists.perlrdf.org Subject: Fw: CPAN Upload: T/TO/TOBYINK/RDF-RDFa-Parser-1.09_11.tar.gz Just uploaded RDF-RDFa-Parser-1.09_11.tar.gz. Biggest change is that support for OpenDocument Format 1.2 is included. OpenDocument 1.2 files are essentially ZIP files that contain a collection of XML files (each of which may contain OpenDocument's own unique flavour of RDFa) and RDF/XML files. RDF::RDFa::Parser provides transparent support for it, so you don't need to worry about extracting archives, etc. Assuming your server sends the correct media type, it's as simple as: my $model = RDF::RDFa::Parser ->new_from_url('http://example.com/foo.odt') ->graph; The model will actually contain quads, so that you can track which XML or RDF/XML file inside the ZIP was the source for each statement. OpenDocument 1.2 is still a draft, and not yet fully utilised by OpenOffice.org (the flagship OpenDocument software), so for now you're unlikely to see much RDFa-in-OpenDocument content in the wild. The release also includes various bugfixes and cleanups too boring to list here. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> _______________________________________________ Dev mailing list Dev@lists.perlrdf.org http://lists.perlrdf.org/listinfo/dev http://tobyinkster.co.uk/message/20100618002216.73a2ce56%40miranda.g5n.co.uk Re: What is it that's wrong with rdf:List 2010-06-17T23:22:16 2010-06-17T23:22:16 2010-06-17T23:22:16 On Thu, 17 Jun 2010 23:19:40 +0100 Norman Gray <norman@astro.gla.ac.uk> wrote: > What is it that's so wrong/bad/wicked with rdf:List? Can anyone > point me to some reading? rdf:Lists are tricky to query in the current version of SPARQL, and pretty annoying to deal with in RDF tools that don't include explicit functions to deal with them. They also look ugly when output in RDF serialisations tha... On Thu, 17 Jun 2010 23:19:40 +0100 Norman Gray <norman@astro.gla.ac.uk> wrote: > What is it that's so wrong/bad/wicked with rdf:List? Can anyone > point me to some reading? rdf:Lists are tricky to query in the current version of SPARQL, and pretty annoying to deal with in RDF tools that don't include explicit functions to deal with them. They also look ugly when output in RDF serialisations that don't have syntactic sugar for them (e.g. N-Triples, RDFa). That said, there are some modelling situations where they're useful, and in those cases, you should probably use them, but before doing so, you should consider whether there's a better way. If you need to keep a bunch of resources in order, there are often other options. For example, next/previous predicates: <#chapter1> :next <#chapter2> . <#chapter2> :next <#chapter3> . # ... Sometimes you have a bunch of resources which have next/previous relationships along multiple dimensions/axes/lines. Take for example, the London Underground - what is "next" from Victoria station? Even if you pick a convention on whether "next" means to go North or to go South, you still have to worry about stations which are on multiple lines. We've moved from a situation whether nodes have inherant next/previous relationships to one where nodes can participate in multiple sequences. This can still be modelled with next/previous predicates: :nextAlongVictoriaLine rdfs:subPropertyOf :next . :nextAlongDistrictLine rdfs:subPropertyOf :next . <#Victoria> :nextAlongVictoriaLine <#Pimlico> . <#Victoria> :nextAlongDistrictLine <#SloaneSquare> . But this method is starting to look less ideal. Lists offer a neater way of defining things: <#VictoriaLine> :stations (<#Brixton> <#Stockwell> ...) . <#DistrictLine> :stations (<#Richmond> <#Kew> ...) . That's a good way of modelling the order of stations along a line. But if you're using SPARQL 1.0, then try figuring out which lines Green Park is on and you'll find yourself in a muddle. A good solution is to supplement your rdf:List data with some non-list data for each station, linking back to the lines without using lists: <#Victoria> :servedBy <#CircleLine> , <#DistrictLine> , <#VictoriaLine> . I do actually have a railway vocab <http://ontologi.es/rail/vocab#> which models data much like that. <#someStation> rail:located_at [ rail:distance [ unit:metres 123 ] ; rail:along_route <#someRoute> ] . <#someRoute> rail:stations (<#someStation> ...) . So yeah, my suggestion would be that if you need to publish data about ordered nodes rdf:List is a good way of doing it, especially if the order of the nodes is not intrinsic to them. But try to back it up with some additional non-List triples for people who don't care about the order. > And what's the alternative, if I want to say in RDF that a particular > thing is related to an ordered set of other things -- perhaps an > article has a particular sequence of authors? Using my technique of a list backed up with non-list triples, something like: <#doc> ex:authors (<#carol> <#alice> <#bob>) ; foaf:maker <#alice> , <#bob> , <#carol> . > [4] refers to an OWLList ontology (and a broken link to a rationale). > I follow how that ontology works, but don't get the significance of > the apparently minor ways in which it's different from rdf:List. It seems to be more or less the same as rdf:List. I'd certainly not use it as you gain nothing, but sacrifice rdf:List's syntactic sugar in Turtle and RDF/XML, and sacrifice any special support for rdf:List that RDF toolkits have to offer. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100619152238.1aa51f74%40miranda.g5n.co.uk Re: General feedback on the RDFa API draft 2010-06-19T14:22:38 2010-06-19T14:22:38 2010-06-19T14:22:38 On Sat, 19 Jun 2010 00:36:41 +0100 Nathan <nathan@webr3.org> wrote: > Without delving in to too many specifics, I'm slightly (something) > that the RDFa API only caters for handling RDFa inside a User Agent > with DOM support, It only deals with handling RDFa in *environments* with DOM support. The term "user agent" generally implies a browser-or-browser-like-thing. The RDFa API should be implem... On Sat, 19 Jun 2010 00:36:41 +0100 Nathan <nathan@webr3.org> wrote: > Without delving in to too many specifics, I'm slightly (something) > that the RDFa API only caters for handling RDFa inside a User Agent > with DOM support, It only deals with handling RDFa in *environments* with DOM support. The term "user agent" generally implies a browser-or-browser-like-thing. The RDFa API should be implementable on top of any DOM implementation; not just browsers. For what it's worth, although I don't use the RDFa API for it yet (it's too new), the RDFa linter at check.rdfa.info uses extensive DOM scripting on the server-side: 1. the page being linted is parsed into a DOM using either an XML or an HTML parser; 2. RDFa is extracted from that DOM; 3. an empty second DOM is created; 4. the final report is written in the second DOM using standard DOM methods (appendChild, setAttribute, etc); 5. the second DOM is serialised as either HTML or XML (conneg), and printed back to the client. The RDFa API looks like it would simplify writing such a service. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100621143734.7900af4b%40miranda.g5n.co.uk Re: Correction needed to rdfa syntax 1.0 2010-06-21T13:37:34 2010-06-21T13:37:34 2010-06-21T13:37:34 On Mon, 21 Jun 2010 10:29:01 +0100 Damian Steer <pldms@mac.com> wrote: > This conflicts with <http://www.w3.org/TR/rdfa-syntax/#sec_5.5.1020>, > where @src is only used to provide a subject. In fact, any of @about, @src, @resource and @href can be used to set either the subject or the object. Here's an example where @src sets the object: <p about="#me" rel="foaf:img"> <img src="photo.jpeg" a... On Mon, 21 Jun 2010 10:29:01 +0100 Damian Steer <pldms@mac.com> wrote: > This conflicts with <http://www.w3.org/TR/rdfa-syntax/#sec_5.5.1020>, > where @src is only used to provide a subject. In fact, any of @about, @src, @resource and @href can be used to set either the subject or the object. Here's an example where @src sets the object: <p about="#me" rel="foaf:img"> <img src="photo.jpeg" alt="Me" /> </p> Though the quote you mentioned: > A [URI resource] object can be set using one of @rel or @rev to > express a [predicate], and then either using one of @href, @resource > or @src to provide an object resource explicitly ... doesn't seem to be referring to that. It seems to be a relic of very old drafts where @src was treated more like @href. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100622102845.749e291a%40miranda.g5n.co.uk Re: Meta tags in HTML documents 2010-06-22T09:28:45 2010-06-22T09:28:45 2010-06-22T09:28:45 On Tue, 22 Jun 2010 10:35:44 +0200 Dan Brickley <danbri@danbri.org> wrote: > I've seen a few people ask "why not name= in the header?"; any plans > to change this in 1.1? Or a nice link I can point people at that > explains the reasoning? (This isn't an answer on behalf of the WG.) Mark pointed towards the reasoning on the OGP list. @name in HTML is overloaded already - it means so many differe... On Tue, 22 Jun 2010 10:35:44 +0200 Dan Brickley <danbri@danbri.org> wrote: > I've seen a few people ask "why not name= in the header?"; any plans > to change this in 1.1? Or a nice link I can point people at that > explains the reasoning? (This isn't an answer on behalf of the WG.) Mark pointed towards the reasoning on the OGP list. @name in HTML is overloaded already - it means so many different things in different places. Consider the difference between: <meta name="foo"> <input name="foo"> <a name="foo"> <param name="foo"> For RDFa 1.0, it was decided that a clean slate was needed, and that meant using a different attribute. There aren't any *plans* to change this in 1.1, but I don't think our charter would rule it out, so it's probably a reasonable thing to take a look at. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100622111525.4a2c9760%40miranda.g5n.co.uk Fragments in <base href> 2010-06-22T10:15:25 2010-06-22T10:15:25 2010-06-22T10:15:25 So how is the following to be interpreted? <html> <head rel=":test" resource=""> <base href="http://example.net/#foo" /> </head> </html> I can imagine arguments in favour of: <#foo> xhv:test <> . <#foo> xhv:test <#foo> . <> xhv:test <> . I think this needs clarification; not just in RDFa 1.1, but also as an errata for RDFa 1.0. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> So how is the following to be interpreted? <html> <head rel=":test" resource=""> <base href="http://example.net/#foo" /> </head> </html> I can imagine arguments in favour of: <#foo> xhv:test <> . <#foo> xhv:test <#foo> . <> xhv:test <> . I think this needs clarification; not just in RDFa 1.1, but also as an errata for RDFa 1.0. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100622112355.4dc7c069%40miranda.g5n.co.uk Re: Fragments in <base href> 2010-06-22T10:23:55 2010-06-22T10:23:55 2010-06-22T10:23:55 On Tue, 22 Jun 2010 11:19:21 +0100 Nathan <nathan@webr3.org> wrote: > Doesn't base have to be IRI/URI Absolute - ie no fragments allowed on > a base (?) If only it were that simple. Even relative URL references are allowed. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 22 Jun 2010 11:19:21 +0100 Nathan <nathan@webr3.org> wrote: > Doesn't base have to be IRI/URI Absolute - ie no fragments allowed on > a base (?) If only it were that simple. Even relative URL references are allowed. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100622210710.6432cd71%40miranda.g5n.co.uk Re: Namespacing RDFa attributes in custom XML vocabularies 2010-06-22T20:07:10 2010-06-22T20:07:10 2010-06-22T20:07:10 On Mon, 21 Jun 2010 11:12:04 -0500 Alan Jeffrey <ajeffrey@bell-labs.com> wrote: > RDFa requires that RDFa attributes be in the > default anonymous namespace, for example: > > <example xmlns="http://ex.com/" about="http://ex.com/foo" > rel="http://ex.com/bar" href="http://ex.com/baz"/> > > is fine, but the same document in a named namespace is not: > > <ns:example xmlns:ns="http://e... On Mon, 21 Jun 2010 11:12:04 -0500 Alan Jeffrey <ajeffrey@bell-labs.com> wrote: > RDFa requires that RDFa attributes be in the > default anonymous namespace, for example: > > <example xmlns="http://ex.com/" about="http://ex.com/foo" > rel="http://ex.com/bar" href="http://ex.com/baz"/> > > is fine, but the same document in a named namespace is not: > > <ns:example xmlns:ns="http://ex.com/" ns:about="http://ex.com/foo" > ns:rel="http://ex.com/bar" ns:href="http://ex.com/baz"/> Though the following should be fine: <ns:example xmlns:ns="http://ex.com/" about="http://ex.com/foo" rel="http://ex.com/bar" href="http://ex.com/baz" /> There is actually one RDFa host language that uses namespace-prefixed RDFa attributes: OpenDocument Format 1.2. (It puts them in the namespace <http://www.w3.org/1999/xhtml>.) I'm not entirely sure what their reasoning for this was. A reason to allow an alternative RDFa namespace in RDFa Core (though for backwards compatibility, we'd need to continue to support the null namespace) would be a commonly used XML tool that lacks support for non-namespaced attributes, but in my experience none seem to have a problem - the DOM, XSLT, XPath, XQuery, etc should all be OK. Frankly they have to be OK, because otherwise they'd not be able to process any of the many languages that use non-namespaced attributes, including XHTML, SVG, Atom, MathML, etc. I'm not convinced so-far that there's a case for adding this to RDFa Core. If you know of real-life tools that the current RDFa attributes cause problems for, then do please follow up. As OpenDocument shows, host languages can already choose to place the RDFa attributes in an alternative namespace, but they do so at the cost of compatibility with generic RDFa processors. For what it's worth, the latest development version of my RDFa parser (RDF::RDFa::Parser - this is the parser that powers check.rdfa.info) does allow for namespaced attributes (though all the attributes have to reside in the same namespace as each other). There is a little hack you can use to enable it: <meta name="http://search.cpan.org/dist/RDF-RDFa-Parser/#auto_config" content="ns=http://example.com/some-namespace" /> This can be used in non-XHTML/HTML content too: <x:meta xmlns:x="http://www.w3.org/1999/xhtml" name="http://search.cpan.org/dist/RDF-RDFa-Parser/#auto_config" content="ns=http://example.com/some-namespace" /> Auto-config is (clearly) a parser-specific feature, really just intended for testing interesting/experimental features of RDF::RDFa::Parser. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100623111010.05d004a5%40miranda.g5n.co.uk Re: WG Decision: Publish six heartbeat drafts, as well as Polyglot, Alt Techniques as FPWDs 2010-06-23T10:10:10 2010-06-23T10:10:10 2010-06-23T10:10:10 On Wed, 23 Jun 2010 10:41:58 +0200 "Anne van Kesteren" <annevk@opera.com> wrote: > Since there was confusion I thought I should mention I have always > addressed all outstanding comments whenever I update html5-diff. If > there is no need to update html5-diff, the comments can wait. The html5-diff document still does not note the following change, which I think is a significant change from HTM... On Wed, 23 Jun 2010 10:41:58 +0200 "Anne van Kesteren" <annevk@opera.com> wrote: > Since there was confusion I thought I should mention I have always > addressed all outstanding comments whenever I update html5-diff. If > there is no need to update html5-diff, the comments can wait. The html5-diff document still does not note the following change, which I think is a significant change from HTML 4: The content model of <head> no longer allows <object> elements. Can I request that this difference is noted in html5-diff? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100623233144.2461af78%40miranda.g5n.co.uk Re: Org. Namespace Example 2010-06-23T22:31:44 2010-06-23T22:31:44 2010-06-23T22:31:44 On Wed, 23 Jun 2010 14:52:29 -0700 (PDT) Gannon Dick <gannon_dick@yahoo.com> wrote: > An RDF/XML example for each type is below These examples are strange. Firstly, bridges and beaches are not typically considered organisations. Secondly, you appear to be using some of the classes defined by the org vocabulary as if they were properties. Lastly, none of the URIs you're using in rdf:about, rdf:resource or rdf:datatype make any sense whatsoever. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 23 Jun 2010 14:52:29 -0700 (PDT) Gannon Dick <gannon_dick@yahoo.com> wrote: > An RDF/XML example for each type is below These examples are strange. Firstly, bridges and beaches are not typically considered organisations. Secondly, you appear to be using some of the classes defined by the org vocabulary as if they were properties. Lastly, none of the URIs you're using in rdf:about, rdf:resource or rdf:datatype make any sense whatsoever. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1277457039.19031.10.camel%40ophelia2.g5n.co.uk Re: The Counter Ontology 2010-06-25T09:10:42 2010-06-25T09:10:42 2010-06-25T09:10:42 On Thu, 2010-06-24 at 23:22 +0200, Bob Ferris wrote: > Here is the Counter Ontology Yay! Now we can do mid-90s style web page hit counters in RDFa! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 2010-06-24 at 23:22 +0200, Bob Ferris wrote: > Here is the Counter Ontology Yay! Now we can do mid-90s style web page hit counters in RDFa! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1277462252.19031.22.camel%40ophelia2.g5n.co.uk Re: The Counter Ontology 2010-06-25T10:37:33 2010-06-25T10:37:33 2010-06-25T10:37:33 On Fri, 2010-06-25 at 12:21 +0200, Bob Ferris wrote: > I don't know about a good translation for this, but a good German phrase > for describing this situation is: "Es wurde ja auch Zeit!". I don't know > about any good English translation for this, yet. My German is not as good as it used to be, but I think it should be translated as: "it's about time!" Have had further thoughts on counters i... On Fri, 2010-06-25 at 12:21 +0200, Bob Ferris wrote: > I don't know about a good translation for this, but a good German phrase > for describing this situation is: "Es wurde ja auch Zeit!". I don't know > about any good English translation for this, yet. My German is not as good as it used to be, but I think it should be translated as: "it's about time!" Have had further thoughts on counters in RDF. Given that SVG Tiny 1.2 supports RDFa, we ought to be able to do the following... Page with hit counter says: <img alt="hit counter" src="http://hitcounter.example.com/hits.svg" rev="meta" resource="" /> And the counter itself is: <SVG xmlns="...svg..." xmlns:co="http://purl.org/ontology/co/" xmlns:xs="http://www.w3.org/2001/XMLSchema#" about="#c(http://example.com/page.xhtml)" property="co:count" content="12345" datatype="xs:int" rev="co:counter" resource="http://example.com/page.xhtml"> ... whatever gubbins are needed to render the counter ... </SVG> Who knows, I might even take a stab at writing such a beast? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100629235344.6287a98e%40miranda.g5n.co.uk Re: ISSUE 27: Proposal regarding use of relative URIs in the datatype TERMorCURIEorURI 2010-06-29T22:53:44 2010-06-29T22:53:44 2010-06-29T22:53:44 On Tue, 29 Jun 2010 12:13:46 -0500 Shane McCarron <shane@aptest.com> wrote: > Consider the following: > > 1. A TERM is visually indistinguishable from a relative URI. > 2. If relative URIs are permitted, there is NO way to flag an > illegal token during parsing. Every string that matches the > production(s) will result in a triple. > 3. There are no compelling use cases for supporting ... On Tue, 29 Jun 2010 12:13:46 -0500 Shane McCarron <shane@aptest.com> wrote: > Consider the following: > > 1. A TERM is visually indistinguishable from a relative URI. > 2. If relative URIs are permitted, there is NO way to flag an > illegal token during parsing. Every string that matches the > production(s) will result in a triple. > 3. There are no compelling use cases for supporting relative URIs - > at least not in the places where this datatype is used. > 4. Excluding relative URIs makes explaining how this datatype works > easier, and therefore can reduce the barrier to adoption. Agreed. I'd like to add to this list: 5. It would be nice to have some lexical space in @property, @rel, @rev, etc that RDFa 1.1 leaves undefined and RDFa 1.1 processors are required to ignore - this provides future versions of RDFa with scope to improve these attributes. (e.g. allowing SPARQL-1.1-style property paths.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100630120507.35cbe830%40miranda.g5n.co.uk Default apache index.html 2010-06-30T11:05:07 2010-06-30T11:05:07 2010-06-30T11:05:07 I've just noticed that the index.html file installed by default in the document root by Mandriva's (and possibly other distros/upsteam?) Apache httpd packages includes the following: <h1 property=":title">It works!</h1> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I've just noticed that the index.html file installed by default in the document root by Mandriva's (and possibly other distros/upsteam?) Apache httpd packages includes the following: <h1 property=":title">It works!</h1> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100630124530.0c04159f%40miranda.g5n.co.uk Re: The Ordered List Ontology 2010-06-30T11:45:30 2010-06-30T11:45:30 2010-06-30T11:45:30 On Wed, 30 Jun 2010 10:54:20 +0100 Dan Brickley <danbri@danbri.org> wrote: > That said, i'm sure sameAs and differentIndividual (or however it is > called) claims could probably make a mess, if added or removed... You can create some pretty awesome messes even without OWL: # An rdf:List that loops around... <#mylist> a rdf:List ; rdf:first <#Alice> ; rdf:next <#mylist> . # A looping, branching mess... <#anotherlist> a rdf:List ; rdf:first <#anotherlist> ; rdf:next <#anotherlist> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 30 Jun 2010 10:54:20 +0100 Dan Brickley <danbri@danbri.org> wrote: > That said, i'm sure sameAs and differentIndividual (or however it is > called) claims could probably make a mess, if added or removed... You can create some pretty awesome messes even without OWL: # An rdf:List that loops around... <#mylist> a rdf:List ; rdf:first <#Alice> ; rdf:next <#mylist> . # A looping, branching mess... <#anotherlist> a rdf:List ; rdf:first <#anotherlist> ; rdf:next <#anotherlist> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100630221947.7d32c1fd%40miranda.g5n.co.uk Re: Subjects as Literals 2010-06-30T21:19:47 2010-06-30T21:19:47 2010-06-30T21:19:47 On Wed, 30 Jun 2010 14:54:47 -0600 Robert Sanderson <azaroth42@gmail.com> wrote: > "London" dcterms:isPartOf "England" > > That is true only for the particular London which is the capital of > England, not London, Texas, London, Ontario or London in Kiribati. Consider: "London" dcterms:isPartOf dbpedia:England . How is that any worse than this? dbpedia:England dcterms:hasPart "London" . Both are bad. Preventing literal subjects doesn't prevent the badness. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 30 Jun 2010 14:54:47 -0600 Robert Sanderson <azaroth42@gmail.com> wrote: > "London" dcterms:isPartOf "England" > > That is true only for the particular London which is the capital of > England, not London, Texas, London, Ontario or London in Kiribati. Consider: "London" dcterms:isPartOf dbpedia:England . How is that any worse than this? dbpedia:England dcterms:hasPart "London" . Both are bad. Preventing literal subjects doesn't prevent the badness. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100630222553.655e3040%40miranda.g5n.co.uk Re: Subjects as Literals, [was Re: The Ordered List Ontology] 2010-06-30T21:25:53 2010-06-30T21:25:53 2010-06-30T21:25:53 On Wed, 30 Jun 2010 13:18:25 -0700 Jeremy Carroll <jeremy@topquadrant.com> wrote: > Here are the reasons I voted this way: > > - it will mess up RDF/XML No it won't - it will just mean that RDF/XML is only capable of representing a subset of RDF graphs. And guess what? That's already the case. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 30 Jun 2010 13:18:25 -0700 Jeremy Carroll <jeremy@topquadrant.com> wrote: > Here are the reasons I voted this way: > > - it will mess up RDF/XML No it won't - it will just mean that RDF/XML is only capable of representing a subset of RDF graphs. And guess what? That's already the case. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100702002513.4da4e42a%40miranda.g5n.co.uk Re: Show me the money - (was Subjects as Literals) 2010-07-01T23:25:13 2010-07-01T23:25:13 2010-07-01T23:25:13 On Thu, 01 Jul 2010 13:05:54 -0400 Kingsley Idehen <kidehen@openlinksw.com> wrote: > W3C only officially acknowledges RDF/XML as Markup Language for RDF > Data Model. I hear this time and time again, but it is not true anymore. XHTML+RDFa 1.0 became a W3C Recommendation in October 2008. It has the same publication status as RDF/XML. (And as it happens, XHTML+RDFa 1.0 is capable of representing... On Thu, 01 Jul 2010 13:05:54 -0400 Kingsley Idehen <kidehen@openlinksw.com> wrote: > W3C only officially acknowledges RDF/XML as Markup Language for RDF > Data Model. I hear this time and time again, but it is not true anymore. XHTML+RDFa 1.0 became a W3C Recommendation in October 2008. It has the same publication status as RDF/XML. (And as it happens, XHTML+RDFa 1.0 is capable of representing a larger subset of the RDF data model than RDF/XML is, as it uses CURIEs rather than QNames. CURIEs are capable of expressing predicate URIs such as <http://example.com/1> which cannot be expressed as QNames.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1278065879.27064.22.camel%40ophelia2.g5n.co.uk Re: Show me the money - (was Subjects as Literals) 2010-07-02T10:18:02 2010-07-02T10:18:02 2010-07-02T10:18:02 On Fri, 2010-07-02 at 08:39 +0100, Ian Davis wrote: > I would prefer to see this kind of effort put into n3 as a general > logic expression system and superset of RDF that perhaps we can move > towards once we have achieved mainstream with the core data expression > in RDF. I'd like to see 5 or 6 alternative and interoperable n3 > implementations in use to iron out the problems, just like we have ... On Fri, 2010-07-02 at 08:39 +0100, Ian Davis wrote: > I would prefer to see this kind of effort put into n3 as a general > logic expression system and superset of RDF that perhaps we can move > towards once we have achieved mainstream with the core data expression > in RDF. I'd like to see 5 or 6 alternative and interoperable n3 > implementations in use to iron out the problems, just like we have > with RDF engines (I can name 10+ and know of no interop issues between > them) I agree with this, but think it's largely a matter of terminology. I think as a community we ought to be moving to a multi-graph model with literal subjects, blank node predicates, etc. Whether that new model is called "RDF" or "RDF 2" or something else entirely is largely a matter of branding. Though that's not to say that branding isn't important - it may be that calling the superset something other than RDF increases confidence in both RDF and its superset. As it happens I've recently been looking at implementing N3 (the syntax and data model, though not the rules language) in Perl. (The RDF::Trine framework was so incredibly close to supporting the data model already, so I'm building on that.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100705211143.6eeb55c6%40miranda.g5n.co.uk Re: Updating RDFa Core 2010-07-05T20:11:43 2010-07-05T20:11:43 2010-07-05T20:11:43 On Mon, 05 Jul 2010 14:39:07 -0500 Shane McCarron <shane@aptest.com> wrote: > This version reflects our first attempt at getting RDFa embedded in > the document. Looks pretty good. A few nits to pick: 1. Would be nice if dcterms:modified could be in xsd:dateTime format with an appropriate datatype. 2. dcterms:publisher probably shouldn't be <http://www.w3.org/> but rather a blank node with a h... On Mon, 05 Jul 2010 14:39:07 -0500 Shane McCarron <shane@aptest.com> wrote: > This version reflects our first attempt at getting RDFa embedded in > the document. Looks pretty good. A few nits to pick: 1. Would be nice if dcterms:modified could be in xsd:dateTime format with an appropriate datatype. 2. dcterms:publisher probably shouldn't be <http://www.w3.org/> but rather a blank node with a homepage: [ a foaf:Organization; foaf:homepage <http://www.w3.org/> ] And it would be nice if the URI for Ivan's workplaceHomepage could match the spelling of the publisher's homepage (one ends in a slash, the other does not). 3. xhv:biblioentry and xhv:disclosure don't exist in the XHTML vocab as far as I know. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100705214255.1db581c7%40miranda.g5n.co.uk Re: HTML5 and RDFa 2010-07-05T20:42:55 2010-07-05T20:42:55 2010-07-05T20:42:55 On Mon, 5 Jul 2010 14:29:09 -0400 Sergey Chernyshev <sergey.chernyshev@gmail.com> wrote: > Sorry, I was originally mailing the old list, but it's still > mentioned all over the place - what's the right place for such > questions? Hope public+rdfa is the right place ;) Yep, public-rdfa is the place for general questions. > I'm sorry for not following whole HTML5 + RDFa discussion to close > late... On Mon, 5 Jul 2010 14:29:09 -0400 Sergey Chernyshev <sergey.chernyshev@gmail.com> wrote: > Sorry, I was originally mailing the old list, but it's still > mentioned all over the place - what's the right place for such > questions? Hope public+rdfa is the right place ;) Yep, public-rdfa is the place for general questions. > I'm sorry for not following whole HTML5 + RDFa discussion to close > lately, by I came across the practical issue of picking a DOCTYPE for > my project on performance side (Show Slow) and there are no reasons > why I shouldn't pick HTML5 DOCTYPE except for one - I want RDFa there. There's an HTML+RDFa specification published by the HTML Working Group with input from the RDFa Working Group. It's still just a Working Draft, and it's not supported by the W3C validator, but if you're not concerned about getting a big green tick from the validator, it's probably your best bet. HTML5+RDFa is supported by my Perl RDFa parser, RDF::RDFa::Parser; by Ivan's PyRDFa, and by Damien Steer's java-rdfa. Probably others too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100706080536.623d9c97%40miranda.g5n.co.uk Re: Subjects as Literals 2010-07-06T07:05:36 2010-07-06T07:05:36 2010-07-06T07:05:36 On Mon, 5 Jul 2010 17:43:17 -0500 Pat Hayes <phayes@ihmc.us> wrote: > Well, nobody is suggesting allowing literals as predicates (although > in fact the RDF semantics would easily extend to this usage, if > required, and the analogous structures are allowed, and do have > genuine use cases, in ISO Common Logic.) Actually, I have suggested allowing them just to make things simpler - URIs, b... On Mon, 5 Jul 2010 17:43:17 -0500 Pat Hayes <phayes@ihmc.us> wrote: > Well, nobody is suggesting allowing literals as predicates (although > in fact the RDF semantics would easily extend to this usage, if > required, and the analogous structures are allowed, and do have > genuine use cases, in ISO Common Logic.) Actually, I have suggested allowing them just to make things simpler - URIs, blank nodes and literals would all be allowed in any position. However, a statement with a literal in the predicate position would be officially defined to have no meaning. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100706113508.27fb4bfe%40miranda.g5n.co.uk Re: How do I unsubscribe from this list? 2010-07-06T10:35:08 2010-07-06T10:35:08 2010-07-06T10:35:08 On Tue, 6 Jul 2010 11:23:33 +0300 Shlomi Fish <shlomif@iglu.org.il> wrote: > how do I unsubscribe from this list? I cannot find any unsubscription > information in: > > 1. The body of the messages sent to the list. Try the headers of the messages. They say: List-Unsubscribe: <mailto:public-rdfa-request@w3.org?subject=unsubscribe> > 3. http://lists.w3.org/Archives/Public/public-rdfa/ - here. ... On Tue, 6 Jul 2010 11:23:33 +0300 Shlomi Fish <shlomif@iglu.org.il> wrote: > how do I unsubscribe from this list? I cannot find any unsubscription > information in: > > 1. The body of the messages sent to the list. Try the headers of the messages. They say: List-Unsubscribe: <mailto:public-rdfa-request@w3.org?subject=unsubscribe> > 3. http://lists.w3.org/Archives/Public/public-rdfa/ - here. Really? I see a link on that labelled "unsubscribe from this list" - it's even highlighted in red if you use a CSS-capable browser. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100706143518.4f2b1cd4%40miranda.g5n.co.uk Re: Subjects as Literals 2010-07-06T13:35:18 2010-07-06T13:35:18 2010-07-06T13:35:18 On Tue, 6 Jul 2010 14:03:19 +0200 "Michael Schneider" <schneid@fzi.de> wrote: > So, if > > :s "lit" :o . > > must not have a semantic meaning, what about > > "lit" rdf:type rdf:Property . > > ? As, according to what you say above, you are willing to allow for > literals in subject position, this triple is fine for you > syntactically. But what about its meaning? Would this also be > ... On Tue, 6 Jul 2010 14:03:19 +0200 "Michael Schneider" <schneid@fzi.de> wrote: > So, if > > :s "lit" :o . > > must not have a semantic meaning, what about > > "lit" rdf:type rdf:Property . > > ? As, according to what you say above, you are willing to allow for > literals in subject position, this triple is fine for you > syntactically. But what about its meaning? Would this also be > officially defined to have no meaning? It would have a meaning. It would just be a false statement. The same as the following is a false statement: foaf:Person a rdf:Property . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100706183747.616526ad%40miranda.g5n.co.uk Re: Subjects as Literals 2010-07-06T17:37:47 2010-07-06T17:37:47 2010-07-06T17:37:47 On Tue, 6 Jul 2010 16:30:06 +0200 "Michael Schneider" <schneid@fzi.de> wrote: > What do you mean by "false statement"? False in the same sense that this is false: <http://danbri.org/foaf.rdf#danbri> foaf:name "Barry Chuckle" . Whether it is provably false by an automated agent is debatable. It doesn't violate any axioms; there are conceivable universes where it is true. But in this one, it's false. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 6 Jul 2010 16:30:06 +0200 "Michael Schneider" <schneid@fzi.de> wrote: > What do you mean by "false statement"? False in the same sense that this is false: <http://danbri.org/foaf.rdf#danbri> foaf:name "Barry Chuckle" . Whether it is provably false by an automated agent is debatable. It doesn't violate any axioms; there are conceivable universes where it is true. But in this one, it's false. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100706210038.6f0816d0%40miranda.g5n.co.uk Re: Updating RDFa Core 2010-07-06T20:00:38 2010-07-06T20:00:38 2010-07-06T20:00:38 On Tue, 06 Jul 2010 13:15:05 -0500 Shane McCarron <shane@aptest.com> wrote: > True. Those were always provided by ReSpec.js and I am loathe to > remove them. By our own rules for RDFa, they MUST NOT generate > triples, since they are not in the vocab we have defined as the > default. They're generating triples in PyRDFa's RDFa 1.1 implementation. I imagine this stems from: <http://www.w3.org/... On Tue, 06 Jul 2010 13:15:05 -0500 Shane McCarron <shane@aptest.com> wrote: > True. Those were always provided by ReSpec.js and I am loathe to > remove them. By our own rules for RDFa, they MUST NOT generate > triples, since they are not in the vocab we have defined as the > default. They're generating triples in PyRDFa's RDFa 1.1 implementation. I imagine this stems from: <http://www.w3.org/2010/02/rdfa/drafts/2010/ED-xhtml-rdfa-20100705/#additional-rdfa-processing-rules> "The default vocabulary URI is http://www.w3.org/1999/xhtml/vocab#." Currently I've not implemented it like this in my parser because of false positives such as these. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100707125740.785ce7a8%40miranda.g5n.co.uk Re: RDF Extensibility 2010-07-07T11:57:40 2010-07-07T11:57:40 2010-07-07T11:57:40 On Tue, 6 Jul 2010 16:11:19 -0500 Pat Hayes <phayes@ihmc.us> wrote: > The world doesn't have facts like that in it. Classes and properties > are intellectual constructs, not the stuff of reality. Hell, if a > particle can be a wave, then surely a class can be a property. > Anyway, RDF doesn't make logical a priori rulings about these kind > of metaphysical segregations. For example, xsd:Numbe... On Tue, 6 Jul 2010 16:11:19 -0500 Pat Hayes <phayes@ihmc.us> wrote: > The world doesn't have facts like that in it. Classes and properties > are intellectual constructs, not the stuff of reality. Hell, if a > particle can be a wave, then surely a class can be a property. > Anyway, RDF doesn't make logical a priori rulings about these kind > of metaphysical segregations. For example, xsd:Number is a class, a > property and an individual in RDF. Indeed - but who has claimed that classes and properties are disjoint? Although they may well overlap in some cases, foaf:Person still isn't a property. Without knowing the definition of foaf:Person, it's difficult to conclude that foaf:Person is not a property. However, even without knowing the definition of a literal, it is easy to conclude that it is not a suitable node to be used as a property, so in my opinion, it is sensible to state that triples containing a literal as the predicate have no meaning (even though I think they should be syntactically allowed). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100707142744.03b910ae%40miranda.g5n.co.uk Re: Telecon Agenda - July 8th 2010, 1400 UTC 2010-07-07T13:27:44 2010-07-07T13:27:44 2010-07-07T13:27:44 On Mon, 05 Jul 2010 17:50:15 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Thursday, July 8th 2010 I might even be able to call in this week! Yay! I've found a SIP terminator service (i.e. VoIP => PSTN) in the US. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 05 Jul 2010 17:50:15 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Thursday, July 8th 2010 I might even be able to call in this week! Yay! I've found a SIP terminator service (i.e. VoIP => PSTN) in the US. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100707170621.7f7c1e49%40miranda.g5n.co.uk Re: ISSUE-26: RDFa-specific vs. Earl-like Processor Status vocabulary 2010-07-07T16:06:21 2010-07-07T16:06:21 2010-07-07T16:06:21 On Wed, 07 Jul 2010 11:35:27 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > -1 to the EARL-based mechanism. > +1 to the simpler, RDFa-specific vocabulary. -1 to both. No other RDF serialisation does anything like this. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 07 Jul 2010 11:35:27 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > -1 to the EARL-based mechanism. > +1 to the simpler, RDFa-specific vocabulary. -1 to both. No other RDF serialisation does anything like this. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100708014805.3cc1ca9e%40miranda.g5n.co.uk Re: ISSUE-26: RDFa-specific vs. Earl-like Processor Status vocabulary 2010-07-08T00:48:05 2010-07-08T00:48:05 2010-07-08T00:48:05 On Wed, 7 Jul 2010 18:31:48 +0200 Ivan Herman <ivan@w3.org> wrote: > I am sorry Toby I do not understand. We have a decision that errors > should be added to a processor graph. Does it mean that you are > against that resolution altogether? Indeed. I've never been in favour of it. It's simply a bad idea to *require* RDFa processors to build a graph of errors in order to be conforming. Case: Ali... On Wed, 7 Jul 2010 18:31:48 +0200 Ivan Herman <ivan@w3.org> wrote: > I am sorry Toby I do not understand. We have a decision that errors > should be added to a processor graph. Does it mean that you are > against that resolution altogether? Indeed. I've never been in favour of it. It's simply a bad idea to *require* RDFa processors to build a graph of errors in order to be conforming. Case: Alice is building a search engine to index the web and allow people to search for content by license. She's only interested in triples of the form { ?item xhv:license ?license . }. Why must she generate error triples if she knows they're never going to be queried (as the error vocab doesn't use the xhv:license predicate)? I'm not saying that there should not be a vocabulary for describing errors found in RDFa documents - I'm just saying that processors should not be required to build an error graph. What's the harm in making this optional? If I'm wrong and everyone else is right, then there'll be such massive consumer demand for this feature that all processors will implement it. But I really think this will turn out to be quite a niche feature. > As for no other RDF serializations doing something similar: that is > true. But, although we do say that RDFa is yet another serialization, > the fact is that it does require a more complex processor than, say, > an RDF/XML or a Turtle parser. In this sense I am not sure the > comparison is fair... I don't see how the complexity of writing a parser comes into it. (And RDF/XML is hardly simple!) It's more the issue is that from what I can see, it simply doesn't seem useful for most people. I'll note here that not only do I not know of another RDF serialisation that makes requirements on processors as to how they report errors, but I don't know of any specification for a data format that makes such requirements. Even XML, which is pretty rigid on when errors need to be reported, doesn't mandate the mechanism by which they're reported. Shane wrote: > Do you have an alternative plan for dealing with errors during > processing? Yes - just let processors deal with it however they like; which will probably be in a manner appropriate for their environment. e.g. command-line clients might write to STDERR; Visual Basic libraries may prefer to raise resumable errors; XSLT scripts might insert XML comments into their output to note errors; browser-based RDFa processors might write to the browser's error console. In particular, if you're implementing RDFa parser for an RDF toolkit that already contains other parsers, I'd expect that RDFa should use the same error handling mechanism that the rest of the parsers do. By all means, add error handling to the RDFa API, but it just doesn't need to be in RDFa Core. See also Mark's e-mail http://www.w3.org/mid/AANLkTinVaASo26g4Sls5Gtxrt333EtUp491RQVMqJf9A@mail.gmail.com -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100708082749.146fa704%40miranda.g5n.co.uk Re: ISSUE-15 PROPOSAL: @version attribute in HTML5 2010-07-08T07:27:49 2010-07-08T07:27:49 2010-07-08T07:27:49 On Thu, 08 Jul 2010 00:35:07 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > We have a couple of options in front of us, that could be combined: > > 1. Keep everything as it is right now, ignoring the polyglot > ramifications of the decision. > 2. Harmonize the HTML5+RDFa and XHTML5+RDFa @version strings. > 3. Specify that @version SHOULD NOT be used unless an author > would like to... On Thu, 08 Jul 2010 00:35:07 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > We have a couple of options in front of us, that could be combined: > > 1. Keep everything as it is right now, ignoring the polyglot > ramifications of the decision. > 2. Harmonize the HTML5+RDFa and XHTML5+RDFa @version strings. > 3. Specify that @version SHOULD NOT be used unless an author > would like to force the RDFa Processor into a particular mode. We could say that @version is a plus-separated list of features in use, and that RDFa processors can split it on the '+', and only need to concern themselves with the feature that matches the regular expression /RDFa(\s.+)?/i If the 'HTML' and 'XHTML' features are respectively defined as 'can be parsed as HTML' and 'can be parsed as XHTML', then a polyglot document could legitimately use any of: HTML+RDFa 1.1 RDFa 1.1+HTML (order is not important) XHTML+RDFa 1.1 XHTML+HTML+RDFa 1.1 RDFa 1.1 One can even imagine people aiming to build polyglot RDFa 1.0 and RDFa 1.1 documents - i.e. documents that yield the same graph parsed as either version of RDFa: XHTML+RDFa 1.0+RDFa 1.1 This interpretation of the @version attribute should be compatible with the XHTML+RDFa 1.0 Rec. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100708193919.782c2945%40miranda.g5n.co.uk Re: ISSUE-24 discussion 2010-07-08T18:39:19 2010-07-08T18:39:19 2010-07-08T18:39:19 On Thu, 08 Jul 2010 12:29:46 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > <markbirbeck> The tricky bit now though is that we have to decide > whether to continue with case-sensitive values in @rel... > <markbirbeck> ...with the risk that some browsers might pull the rug > from under us. I really can't see that happening. DOM Level 2 says that enumerated attributes (of which @rel is not... On Thu, 08 Jul 2010 12:29:46 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > <markbirbeck> The tricky bit now though is that we have to decide > whether to continue with case-sensitive values in @rel... > <markbirbeck> ...with the risk that some browsers might pull the rug > from under us. I really can't see that happening. DOM Level 2 says that enumerated attributes (of which @rel is not one) should be case-normalised by browsers, but in practise this has never happened because it breaks too many scripts. """ <p id="foo" align="LeFT"></p> <script type="text/javascript"> function doit() { p = document.getElementById('foo'); p.innerHTML = p.align; } window.onload = doit; </script> """ According to DOM Level 2, the paragraph should read "left", but I believe all browsers show "LeFT" (if they support scripting at all!) If, after all these years case-normalisation hasn't been implemented for those few attributes it was specified for, then I can't imagine anyone clamouring to add case-normalisation requirements for even more attributes. The only way I can see the case-preservation of @rel and @rev being changed is out of spite. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100708202817.3fae48c5%40miranda.g5n.co.uk Re: RDF Extensibility 2010-07-08T19:28:17 2010-07-08T19:28:17 2010-07-08T19:28:17 On Thu, 8 Jul 2010 12:16:06 -0500 Pat Hayes <phayes@ihmc.us> wrote: > I would veto this option. To do this would be a lot more work than > not doing it; and it would greatly complicate the semantic > specification, which would have to keep track of this > 'meaninglessness'. Why would tools need to keep track of the meaninglessness? True "meaning" is only assigned to triples by their human consu... On Thu, 8 Jul 2010 12:16:06 -0500 Pat Hayes <phayes@ihmc.us> wrote: > I would veto this option. To do this would be a lot more work than > not doing it; and it would greatly complicate the semantic > specification, which would have to keep track of this > 'meaninglessness'. Why would tools need to keep track of the meaninglessness? True "meaning" is only assigned to triples by their human consumers. > One could have a situation, for example, in which A entails B entails > C, A and C are perfectly fine, but B has been declared 'meaningless'. > Should this inference be blocked? Should it be an error? No, and no. While B is meaningless in itself, C might not be. Rules/entailments operate over symbols, not over meaning. It's perfectly feasible that something meaningful might be discovered by applying a set of rules to symbols that are meaningless. An entailment that generates a meaningless statement is probably a dodgy entailment, but that doesn't mean it should be considered an error by the rules engine. What could { <#Alice> "56.2"^^xsd:decimal <#Bob> . } possibly mean? If we assume the class of numbers and the class of relationships is disjoint [1], then "56.2"^^xsd:decimal cannot be a relationship. If the triple doesn't contain a relationship between a subject and an object, but Concepts says that all RDF triples do. So a triple with an xsd:decimal predicate makes no sense according to Concepts. So my point in saying that literals should be allowed as predicates but considered meaningless is to reconcile an arguably desirable feature (the simplicity of allowing any node type to occupy any position in a triple/quad) with an inescapable fact (that a triple with a literal for a predicate doesn't make any sense). The pragmatic solution is to just say, they're allowed -- tools can operate on them as normal -- but should have no meaning to humans. In much the same way as { <#Alice> <#xyzzy> <#Bob> . } has no meaning until we have additional information about <#xyzzy>. I'll add that it has been mentioned that one could mint a datatype URI for relationships (e.g. ^^rdf:relationship). As a datatype is essentially a mapping from strings to things, this would allow for the creation of literals that represent relationships. In this case, I'd concede that a triple with one of these datatyped literals as a predicate would be meaningful. However, this does seem to be a bit of a pathological edge case. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100708212857.35ae2330%40miranda.g5n.co.uk Re: FYI: Blog on HTTP Link header and host-wide well-known URI-s, and Linked Data 2010-07-08T20:28:57 2010-07-08T20:28:57 2010-07-08T20:28:57 On Wed, 7 Jul 2010 07:03:21 +0200 Ivan Herman <ivan@w3.org> wrote: > http://www.w3.org/QA/2010/07/new_opportunities_for_linked_d.html Not sure why my comment yesterday has still not shown up, but for the benefit of these lists... I've been supporting some of these technologies in my Perl modules <http://search.cpan.org/~tobyink/> for a few months now. For example, my SPARQL Protocol client is a... On Wed, 7 Jul 2010 07:03:21 +0200 Ivan Herman <ivan@w3.org> wrote: > http://www.w3.org/QA/2010/07/new_opportunities_for_linked_d.html Not sure why my comment yesterday has still not shown up, but for the benefit of these lists... I've been supporting some of these technologies in my Perl modules <http://search.cpan.org/~tobyink/> for a few months now. For example, my SPARQL Protocol client is able to auto-discover SPARQL endpoints from resource URIs (including documents, FTP addresses, e-mail addresses) using the discovery stack. So you could just do something like: $sparql = "SELECT ?name WHERE { [] foaf:name ?name ; foaf:mbox <mailto:joe@example.com> . }"; $query = RDF::Query::Client->new($sparql); $results = $query->discover_execute('mailto:joe@example.com'); It would use the discovery techniques discussed in that blog article to find a SPARQL endpoint relevant to the e-mail address, and then execute the query on that endpoint. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1278692150.3887.63.camel%40ophelia2.g5n.co.uk Re: Not waiting on browser manufacturers for RDFa 1.1 2010-07-09T16:15:51 2010-07-09T16:15:51 2010-07-09T16:15:51 On Fri, 2010-07-09 at 14:46 +0100, Mark Birbeck wrote: > But as I said way back during the discussions on profile, if you allow > profiles to be defined using JSON then you don't have this problem. Mark, I know you know this, but it's good to be clear... JSON does *not* allow you to circumvent browser cross-origin policies; JSONP does. Why is this an important distinction? Because JSONP is esse... On Fri, 2010-07-09 at 14:46 +0100, Mark Birbeck wrote: > But as I said way back during the discussions on profile, if you allow > profiles to be defined using JSON then you don't have this problem. Mark, I know you know this, but it's good to be clear... JSON does *not* allow you to circumvent browser cross-origin policies; JSONP does. Why is this an important distinction? Because JSONP is essentially a profile of Javascript. You bypass browser cross-origin policies because instead of fetching the profile, you embed (and thus execute) the profile as a script. While in practise there may be situations where this is a reasonable way to operate, executing unchecked third-party scripts carries a pretty big risk. I imagine that if we recommended this technique in the spec, there'd be a lot of pushback. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1278692211.3887.64.camel%40ophelia2.g5n.co.uk Re: Not waiting on browser manufacturers for RDFa 1.1 2010-07-09T16:16:51 2010-07-09T16:16:51 2010-07-09T16:16:51 On Fri, 2010-07-09 at 14:46 +0100, Mark Birbeck wrote: > But as I said way back during the discussions on profile, if you allow > profiles to be defined using JSON then you don't have this problem. Mark, I know you know this, but it's good to be clear... JSON does *not* allow you to circumvent browser cross-origin policies; JSONP does. Why is this an important distinction? Because JSONP is esse... On Fri, 2010-07-09 at 14:46 +0100, Mark Birbeck wrote: > But as I said way back during the discussions on profile, if you allow > profiles to be defined using JSON then you don't have this problem. Mark, I know you know this, but it's good to be clear... JSON does *not* allow you to circumvent browser cross-origin policies; JSONP does. Why is this an important distinction? Because JSONP is essentially a profile of Javascript. You bypass browser cross-origin policies because instead of fetching the profile, you embed (and thus execute) the profile as a script. While in practise there may be situations where this is a reasonable way to operate, executing unchecked third-party scripts carries a pretty big risk. I imagine that if we recommended this technique in the spec, there'd be a lot of pushback. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1278693052.3887.77.camel%40ophelia2.g5n.co.uk Re: CPAN as linked data 2010-07-09T16:30:54 2010-07-09T16:30:54 2010-07-09T16:30:54 On Wed, 2010-04-07 at 15:20 +0100, Toby Inkster wrote: > This lunch time I threw together a quick Linked Data wrapper around > CPAN::SQLite. And today I've added a few updates. The most immediately apparent is that all data is available as RDFa. > Example author: > > http://purl.org/NET/cpan-uri/person/gwilliams > > Example distribution: > > http://purl.org/NET/cpan-uri/dist/RDF-Trine/pro... On Wed, 2010-04-07 at 15:20 +0100, Toby Inkster wrote: > This lunch time I threw together a quick Linked Data wrapper around > CPAN::SQLite. And today I've added a few updates. The most immediately apparent is that all data is available as RDFa. > Example author: > > http://purl.org/NET/cpan-uri/person/gwilliams > > Example distribution: > > http://purl.org/NET/cpan-uri/dist/RDF-Trine/project > > Example version: http://purl.org/NET/cpan-uri/dist/RDF-Trine/v_0-124 > If you visit the page of a version that cannot be found on CPAN, then the > wrapper naively assumes that it does/will/did exist, so serves up a page > anyway: > > http://purl.org/NET/cpan-uri/dist/RDF-Trine/v_9-999 This "feature" has been fixed. It now uses the BackPAN archive as an authoritative list of released versions. > If module authors use Module::Install::DOAPChangeSets and include a > Changes.ttl file in their distribution, then the project data will > automatically pick up data from Changes.ttl: > > http://purl.org/NET/cpan-uri/dist/RDF-TrineShortcuts/project One last change, there are now URIs defined for Perl modules too. (In Perl/CPAN terms, a single CPAN distribution provides zero or more modules.) e.g. http://purl.org/NET/cpan-uri/module/RDF::TrineShortcuts/v_0-100 Distribution versions link to the modules they provide, and also to the modules that are their dependencies. Modules link back to the distribution versions that provide them. As all this is built on-the-fly, I don't provide a SPARQL endpoint, but now I've added BackPAN as a data source, I can see a route to creating a full data dump, and thus eventually a SPARQL endpoint. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100712094414.27c088b0%40miranda.g5n.co.uk Re: WebID pre-alpha specification (uses RDFa) 2010-07-12T08:44:14 2010-07-12T08:44:14 2010-07-12T08:44:14 On Sun, 11 Jul 2010 17:28:51 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Here's the link to the e-mail announcement on payswarm-dev: > > http://payswarm.com/pipermail/payswarm-dev/2010-July/000035.html This seems like a good start. However, the SPARQL query shown uses the deprecated form for marking up keys: PREFIX cert: <http://www.w3.org/ns/auth/cert#> PREFIX rsa: <http://www.w3.o... On Sun, 11 Jul 2010 17:28:51 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Here's the link to the e-mail announcement on payswarm-dev: > > http://payswarm.com/pipermail/payswarm-dev/2010-July/000035.html This seems like a good start. However, the SPARQL query shown uses the deprecated form for marking up keys: PREFIX cert: <http://www.w3.org/ns/auth/cert#> PREFIX rsa: <http://www.w3.org/ns/auth/rsa#> SELECT ?modulus ?exp WHERE { ?key cert:identity <http://example.org/webid#public>; a rsa:RSAPublicKey; rsa:modulus [ cert:hex ?modulus; ]; rsa:public_exponent [ cert:decimal ?exp ] . } The newer form uses datatypes instead of the cert:hex and cert:decimal properties: PREFIX cert: <http://www.w3.org/ns/auth/cert#> PREFIX rsa: <http://www.w3.org/ns/auth/rsa#> SELECT ?modulus ?exp WHERE { ?key cert:identity <http://example.org/webid#public>; a rsa:RSAPublicKey; rsa:modulus ?modulus; rsa:public_exponent ?exp . } It's possible to support both in the same SPARQL query: PREFIX cert: <http://www.w3.org/ns/auth/cert#> PREFIX rsa: <http://www.w3.org/ns/auth/rsa#> SELECT ?modulus ?exp ?modulus2 ?exp2 WHERE { ?key cert:identity <http://example.org/webid#public>; a rsa:RSAPublicKey; rsa:modulus ?modulus; rsa:public_exponent ?exp . OPTIONAL { ?modulus cert:hex ?modulus2 . } OPTIONAL { ?exp cert:decimal ?exp2 . } } Using ?modulus2 and ?exp2 if they are bound; ?modulus and ?exp otherwise. A few other thoughts... The definition of "WebID URL" is: | A URL specified in the Subject Alternative Name field | of the Identification Certificate that identifies a | WebID Profile document. Actually, the WebID URL identifies an Agent, typically a Person. The URL will normally contain a fragment identifier though, and by removing the fragment, you get the URL for a WebID Profile document; or if it does not contain a fragment identifier, it should perform a 303 redirect to the WebID Profile document. There should probably be a definition for "WebID Holder" or something similar. And we should note that the WebID Profile may provide a description of the WebID Holder, typically using FOAF. I'd also like for RDF/XML to be another format that implementations are *required* to support. RDF/XML and XHTML+RDFa are the two RDF serialisations at W3C Rec status, so it seems sensible to grant them both equal status in the WebID spec. (Of course, there's growing interest within the W3C in standardising both Turtle and a JSON serialisation of RDF. I don't know how many serialisations it makes sense to require.) I think section 2.3.5 should be dropped. Once the identity of the agent has been established, it's up to the server what to do with that information. We should draw a line between authentication and authorisation. Apache does this and it works very well: you can swap authn and authz modules in and out independently of each other. Lastly, it would be nice to keep the foaf-protocols mailing list copied into this thread, as it's the main place where FOAF+SSL is discussed. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100712223055.5d60c3cd%40miranda.g5n.co.uk Re: [foaf-protocols] WebID pre-alpha specification (uses RDFa) 2010-07-12T21:30:55 2010-07-12T21:30:55 2010-07-12T21:30:55 On Mon, 12 Jul 2010 16:19:00 +0200 Reto Bachmann-Gmür <me@farewellutopia.com> wrote: > - I'm against requiring RDFA as this means I cannot expose my triple > store as a collection of Web-Ids without adding some templates. RDFa is a fairly suitable format for triple store dumps - after all, there's no rule saying that the HTML you generate must be pretty - a bunch of empty <span> elements garnish... On Mon, 12 Jul 2010 16:19:00 +0200 Reto Bachmann-Gmür <me@farewellutopia.com> wrote: > - I'm against requiring RDFA as this means I cannot expose my triple > store as a collection of Web-Ids without adding some templates. RDFa is a fairly suitable format for triple store dumps - after all, there's no rule saying that the HTML you generate must be pretty - a bunch of empty <span> elements garnished with @about, @rel, @resource, @property, @content, @datatype and @xml:lang ought to do the trick. RDFa 1.1 will be an even better format for dumps, as it removes the need to split the predicate and datatype URIs into CURIEs. Though there are some tricks for generating lazy CURIEs in 1.0, e.g. <span about="#i" xmlns:p="http://xmlns.com/foaf/0.1/name" property="p:" content="Toby Inkster"></span> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100714093158.672b66db%40miranda.g5n.co.uk Duplicates in @prefix 2010-07-14T08:31:58 2010-07-14T08:31:58 2010-07-14T08:31:58 How is the following to be interpreted? <title prefix=" dc: http://purl.org/dc/terms/ dc: http://purl.org/dc/elements/1.1/ " property="dc:title">Hello World</title> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> How is the following to be interpreted? <title prefix=" dc: http://purl.org/dc/terms/ dc: http://purl.org/dc/elements/1.1/ " property="dc:title">Hello World</title> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100714100303.1bf42f8f%40miranda.g5n.co.uk Re: ISSUE-24: Proposal for dealing with case-insensitive terms in the XHTML vocabulary 2010-07-14T09:03:03 2010-07-14T09:03:03 2010-07-14T09:03:03 On Tue, 13 Jul 2010 17:01:52 -0500 Shane McCarron <shane@aptest.com> wrote: > In XHTML+RDFa 1.1 we should say: > > When referencing TERMs in the vocabulary at > http://www.w3.org/1999/xhtml/vocab, TERMs must be mapped to lower > case. Does this also cover the case of the empty prefix? According to my reading of XHTML+RDFa 1.0, given the following: rel="Next" rel=":Next" The first is... On Tue, 13 Jul 2010 17:01:52 -0500 Shane McCarron <shane@aptest.com> wrote: > In XHTML+RDFa 1.1 we should say: > > When referencing TERMs in the vocabulary at > http://www.w3.org/1999/xhtml/vocab, TERMs must be mapped to lower > case. Does this also cover the case of the empty prefix? According to my reading of XHTML+RDFa 1.0, given the following: rel="Next" rel=":Next" The first is mapped to lower-case; the second is treated case-sensitively. This is because the former is a term and the latter is a CURIE. I suggest we retain this distinction, as there do exist mixed-case terms defined in the XHTML vocabulary (though they're not used by RDFa currently). Ivan wrote: > 2. in RDFa+XHTML (and I presume in RDFa+HTML5) there is a a default > @vocab, namely http://www.w3.org/1999/xhtml/vocab# and, if this is the > one in effect, then terms are interpreted in a case insensitive way, > ie, terms must be mapped on lower case. Personally I'd ditch that too -- you get too many junk results. Better to say that the default vocabulary in (X)HTML+RDFa is null. Otherwise you'll end up with having to deal with rel values from Microformats, etc. The problem with that it that Microformats have their own ways of determining what the "subject" is for a rel; applying RDF's @about/@src/chaining rules doesn't work well. To handle the case of rel="next", rel="prev", etc define a default *profile* for XHTML+RDFa, and have that profile define those terms case-insensitively. (The profile SHOULD be hard-coded in XHTML+RDFa parsers; authors MAY include an explicit @profile attribute referencing the default profile.) This means that parsers need to internally allow profiles to define both case-sensitive and case-insensitive terms, though we may decide not that profiles other than the XHTML vocab are not privileged to declare case-insensitive terms. This solution allows us to pick up "our" @rel terms but skim safely over the @rel terms used by Microformats, Javascript libraries, etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100714130528.6d39153b%40miranda.g5n.co.uk SHOULD vs MUST ignore @version 2010-07-14T12:05:28 2010-07-14T12:05:28 2010-07-14T12:05:28 Essentially what we want parsers to do is ignore @version -- i.e. always use the latest version of RDFa. Firstly, let's check that we've left enough space for future innovation. I think we have. If a future version of RDFa, say 2.0, is so incompatible with RDFa 1.x that version detection is needed, they can say that authors MUST include a particular profile attribute on their root element, say: ... Essentially what we want parsers to do is ignore @version -- i.e. always use the latest version of RDFa. Firstly, let's check that we've left enough space for future innovation. I think we have. If a future version of RDFa, say 2.0, is so incompatible with RDFa 1.x that version detection is needed, they can say that authors MUST include a particular profile attribute on their root element, say: profile="urn:w3c:rdfa:2.0" As it's deliberately unresolvable, an RDFa 1.1 processor will skip the root element. This effectively allows future RDFa Working Groups to re-establish versioning, so I think we have that covered. So the versioning discussion only needs to apply to RDFa 1.0 and 1.1. Now, let's assume that somebody *wants* to do version detection, despite us saying it's a bad idea. Their code might be something like this: function rdfa11_processor ($doc) { if (check_version($doc)==1.0) { return rdfa10_parse($doc); } else { return rdfa11_parse($doc); } } If we prohibit this and say it's not conforming, they just refactor their code: function html_processor ($doc) { if (check_version($doc)==1.0) { return rdfa10_processor($doc); } else { return rdfa11_processor($doc); } } Now they're still doing version detection, but their rdfa11_processor function is technically conforming, because the version detection occurs externally to it. So my argument is that we make ignoring @version a SHOULD rather than a MUST, because if it's a MUST people can just work around it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100714165552.040441cc%40miranda.g5n.co.uk Re: ISSUE-24: Proposal for dealing with case-insensitive terms in the XHTML vocabulary 2010-07-14T15:55:52 2010-07-14T15:55:52 2010-07-14T15:55:52 On Wed, 14 Jul 2010 09:33:18 -0500 Shane McCarron <shane@aptest.com> wrote: > I agree that rel=":Next" refers to a CURIE, not a term. As such, the > special processing rules I proposed to not apply. However, I looked > at the terms defined in http://www.w3.org/1999/xhtml/vocab/ and, at > least for now, none of these terms are mixed case. "itsRules" is mixed-case. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 14 Jul 2010 09:33:18 -0500 Shane McCarron <shane@aptest.com> wrote: > I agree that rel=":Next" refers to a CURIE, not a term. As such, the > special processing rules I proposed to not apply. However, I looked > at the terms defined in http://www.w3.org/1999/xhtml/vocab/ and, at > least for now, none of these terms are mixed case. "itsRules" is mixed-case. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1279290434.22738.10.camel%40ophelia2.g5n.co.uk Re: ISSUE-36 (Default vocab specification): Should Profile documents allow the specification of a default vocabulary? [RDFa 1.1 Core] 2010-07-16T14:27:15 2010-07-16T14:27:15 2010-07-16T14:27:15 On Fri, 2010-07-16 at 10:17 -0400, Manu Sporny wrote: > Good point - so that's an argument for @vocab overriding any default > vocabulary specified in the @profile document. @vocab overriding @profile is consistent with @prefix overriding it (which is what currently happens). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 2010-07-16 at 10:17 -0400, Manu Sporny wrote: > Good point - so that's an argument for @vocab overriding any default > vocabulary specified in the @profile document. @vocab overriding @profile is consistent with @prefix overriding it (which is what currently happens). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100717151510.1e8f0416%40miranda.g5n.co.uk Re: spam 2010-07-17T14:15:10 2010-07-17T14:15:10 2010-07-17T14:15:10 On Sat, 17 Jul 2010 12:02:19 +0100 Richard Light <richard@light.demon.co.uk> wrote: > If [a museum] were to follow the dbpedia model, and publish a set of > [unrelated] triples with the object identifier as subject, embedded > in their web page for the object, there is nothing to stop someone > else putting out a page containing lies about that object, also > expressed as simple triples with the... On Sat, 17 Jul 2010 12:02:19 +0100 Richard Light <richard@light.demon.co.uk> wrote: > If [a museum] were to follow the dbpedia model, and publish a set of > [unrelated] triples with the object identifier as subject, embedded > in their web page for the object, there is nothing to stop someone > else putting out a page containing lies about that object, also > expressed as simple triples with the object URL as subject. There's also nothing to stop people publishing a page containing the truth about an object if they notice that the museum has told lies about it. > By the time Google has indexed both those pages "semantically" (see > yesterday's acquisition of FreeBase) and merged the results in its > uber-index, you won't know the difference. That assumes a fairly naive approach to graph management. Most large-scale RDF stores keep statements as quads (or even quints), giving you a slot to record the provenance of each piece of information. The consumer can then apply as sophisticated a policy as they like to decide which sources they trust. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100717152008.295a28a3%40miranda.g5n.co.uk Re: Predicate for external links on dbpedialite.org? 2010-07-17T14:20:08 2010-07-17T14:20:08 2010-07-17T14:20:08 On Thu, 15 Jul 2010 17:09:36 +0100 Nicholas Humfrey <nicholas.humfrey@bbc.co.uk> wrote: > I have added external links to dbpedialite, for example see Berlin: > http://dbpedialite.org/things/3354 > > Is there a better predicate to use than rdfs:seeAlso? You could use the very matter-of-fact sioc:links_to. (The subject of a sioc:links_to link would be the page about Berlin, not Berlin itself.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 15 Jul 2010 17:09:36 +0100 Nicholas Humfrey <nicholas.humfrey@bbc.co.uk> wrote: > I have added external links to dbpedialite, for example see Berlin: > http://dbpedialite.org/things/3354 > > Is there a better predicate to use than rdfs:seeAlso? You could use the very matter-of-fact sioc:links_to. (The subject of a sioc:links_to link would be the page about Berlin, not Berlin itself.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100721124851.2d2e918c%40miranda.g5n.co.uk Re: The Counter Ontology 2010-07-21T11:48:51 2010-07-21T11:48:51 2010-07-21T11:48:51 On Tue, 20 Jul 2010 14:56:05 +0200 Bob Ferris <zazi@elbklang.net> wrote: > How can I make sure that the value of my counter concept is of the > type xsd:Integer? co:Counter rdfs:subClassOf [ a owl:Restriction ; owl:onProperty rdf:value ; owl:allValuesFrom xsd:integer ] ; # and to say that it's a functional property... rdfs:subClassOf [ a owl:Restriction ; owl:onProperty rdf:value ; owl:cardinality 1 ] . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 20 Jul 2010 14:56:05 +0200 Bob Ferris <zazi@elbklang.net> wrote: > How can I make sure that the value of my counter concept is of the > type xsd:Integer? co:Counter rdfs:subClassOf [ a owl:Restriction ; owl:onProperty rdf:value ; owl:allValuesFrom xsd:integer ] ; # and to say that it's a functional property... rdfs:subClassOf [ a owl:Restriction ; owl:onProperty rdf:value ; owl:cardinality 1 ] . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100721133521.0ab01e30%40miranda.g5n.co.uk Re: The Counter Ontology 2010-07-21T12:35:21 2010-07-21T12:35:21 2010-07-21T12:35:21 On Wed, 21 Jul 2010 14:07:25 +0200 Bob Ferris <zazi@elbklang.net> wrote: > Finally, what do you think should we use now: rdf:value and some > restrictions on it for co:Counter or co:count as it is already > defined + a cardinality restriction of 1 on co:Counter for co:count? I'm indifferent as to which you should use. Was merely pointing out that OWL allows you to set effective range and funct... On Wed, 21 Jul 2010 14:07:25 +0200 Bob Ferris <zazi@elbklang.net> wrote: > Finally, what do you think should we use now: rdf:value and some > restrictions on it for co:Counter or co:count as it is already > defined + a cardinality restriction of 1 on co:Counter for co:count? I'm indifferent as to which you should use. Was merely pointing out that OWL allows you to set effective range and functional property requirements on rdf:value almost as easily as it allows you to do so on a custom property. > Your second statement (... owl:cardinality 1 ...) restricts the > existence of co:count. That means this property must exist for every > co:Counter instance. That seems sensible to me. The open world assumption means that even though a co:count *exists* for every co:Counter, it is not necessarily the case that every description of the co:Counter includes the co:count. For example, a cardinality restriction on a hypothetical foaf:bloodtype property for foaf:Persons would mean that every person has a blood type, but it doesn't mean that every RDF file mentioning a foaf:Person must provide the person's blood type. Even if you won't want to use owl:cardinality, there's always owl:maxCardinality. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100722094756.6bdc1be6%40miranda.g5n.co.uk Re: Telecon Agenda - July 22nd 2010, 1400 UTC 2010-07-22T08:47:56 2010-07-22T08:47:56 2010-07-22T08:47:56 On Mon, 19 Jul 2010 17:25:03 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Scribe: Mark, Knud, Shane, Ivan, Toby (in scribe-list order) I'm afraid I won't be able to make today's telecon, nor the 29th. Am happy to scribe on the 5th though! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 19 Jul 2010 17:25:03 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Scribe: Mark, Knud, Shane, Ivan, Toby (in scribe-list order) I'm afraid I won't be able to make today's telecon, nor the 29th. Am happy to scribe on the 5th though! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100722220743.2eb1608c%40miranda.g5n.co.uk Re: ISSUE-36: Specifying a default vocabulary via an RDFa Profile 2010-07-22T21:07:43 2010-07-22T21:07:43 2010-07-22T21:07:43 On Thu, 22 Jul 2010 12:05:05 -0500 Shane McCarron <shane@aptest.com> wrote: > Comments? Objections? All seems good to me. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 22 Jul 2010 12:05:05 -0500 Shane McCarron <shane@aptest.com> wrote: > Comments? Objections? All seems good to me. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1280766348.18922.26.camel%40ophelia2.g5n.co.uk Re: ISSUE-29: Re: When is equal and when is it nonequal (eg, the IRI interface) 2010-08-02T16:25:50 2010-08-02T16:25:50 2010-08-02T16:25:50 On Sun, 2010-08-01 at 21:28 -0400, Manu Sporny wrote: > Unfortunately, I don't think the answer to this one is as simple as > that, Toby. It assumes that we're operating in a DOM environment, > which we can't depend on for the RDFa API. > > I've updated the RDFa API spec to move "origin" into a > developer-modifiable attribute called info. We also had to rename > "origin" to "source" due to Thoma... On Sun, 2010-08-01 at 21:28 -0400, Manu Sporny wrote: > Unfortunately, I don't think the answer to this one is as simple as > that, Toby. It assumes that we're operating in a DOM environment, > which we can't depend on for the RDFa API. > > I've updated the RDFa API spec to move "origin" into a > developer-modifiable attribute called info. We also had to rename > "origin" to "source" due to Thomas' input on ISSUE-29. So, the way you > access the property at the moment is: > > triple.subject.info.source What it's called does not matter so much to me. What I'm concerned about is that the origin is being attached to the IRI, PlainLiteral, TypedLiteral and BlankNode interfaces when it's more useful if attached to the RDFTriple interface. i.e. what we now have, in a JSON-ish notation is something like this for an RDF triple: { "subject" : { "value" : "http://tobyinkster.co.uk/#i", "origin" : (some node) }, "predicate" : { "value" : "http://xmlns.com/foaf/0.1/name", "origin" : (some node) }, "object" : { "value" : "Toby Inkster", "origin" : (some node) }, } Whereas it would be better if it were: { "subject" : { "value" : "http://tobyinkster.co.uk/#i" }, "predicate" : { "value" : "http://xmlns.com/foaf/0.1/name" }, "object" : { "value" : "Toby Inkster" }, "subjectOrigin" : (some node), "predicateOrigin" : (some node), "objectOrigin" : (some node) } Or: { "subject" : { "value" : "http://tobyinkster.co.uk/#i" }, "predicate" : { "value" : "http://xmlns.com/foaf/0.1/name" }, "object" : { "value" : "Toby Inkster" }, "origins" : { "subject" : (some node), "predicate" : (some node), "object" : (some node) } } Or even: { "subject" : { "value" : "http://tobyinkster.co.uk/#i" }, "predicate" : { "value" : "http://xmlns.com/foaf/0.1/name" }, "object" : { "value" : "Toby Inkster" }, "origins" : [(some node), (some node), (some node)] } By moving the origins outside the IRI, PlainLiteral, TypedLiteral and BlankNode interfaces, it becomes trivial to test for equivalence between nodes. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/bd11e07b6857681b4c1d25e21df964b0.squirrel%40goddamn.co.uk 2010-08-12T09:24:08 2010-08-12T09:24:08 2010-08-12T09:24:08 On Fri, 6 Aug 2010 07:40:04 +0200 Ivan Herman <ivan@w3.org> wrote: > This was discussed several times on the mailing list and I fully > understand your issues. Here is the reason I was in favour of the > current setup, but I am absolutely open to discussion because, well, > it does complicate processing (speaking as an implementer). FWIW, I agree with your reasoning for the current vocab. Prefix... On Fri, 6 Aug 2010 07:40:04 +0200 Ivan Herman <ivan@w3.org> wrote: > This was discussed several times on the mailing list and I fully > understand your issues. Here is the reason I was in favour of the > current setup, but I am absolutely open to discussion because, well, > it does complicate processing (speaking as an implementer). FWIW, I agree with your reasoning for the current vocab. Prefix and term mappings are semantically a relationship between two strings. Imagine this: <http://xmlns.com/foaf/0.1/> rdfa:prefix "foaf" . Now, the following is also true (probably): <http://xmlns.com/foaf/0.1/> a owl:Ontology ; owl:sameAs <http://dbpedia.org/resource/FOAF_(software)> . Thus it follows that: <http://dbpedia.org/resource/FOAF_(software)> rdfa:prefix "foaf" . Thus an RDFa processor could expand 'foaf:name' to: <http://dbpedia.org/resource/FOAF_(software)name> Which we wouldn't want to happen. In RDF terms, when we're defining prefixes and terms we're not describing the underlying resources - we're just talking about the xsd:strings. We're not even talking about xsd:anyURIs, because say, "htt" is a valid expansion for a prefix, which might be used as follows: prefix="h: htt" property="h:p://xmlns.com/foaf/0.1/" So I'd recommend keeping the current pattern, though I think the range of rdfa:uri should be changed to xsd:string for the above reason. Another argument against switching to <http://xmlns.com/foaf/0.1/> rdfa:prefix "foaf" . would be the fact that you'd lose the owl:FunctionalProperty-ness of rdfa:prefix and rdfa:term. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/398d20a723bf2f3598d96c04e53fae6a.squirrel%40goddamn.co.uk Re: Getting the XHTML+RDFa default profile to be interesting 2010-08-15T09:28:16 2010-08-15T09:28:16 2010-08-15T09:28:16 > So, who's willing to work on this? I'd be happy to put together an updated profile. IIRC I don't think I have CVS access to the W3C servers though. -Toby > So, who's willing to work on this? I'd be happy to put together an updated profile. IIRC I don't think I have CVS access to the W3C servers though. -Toby http://tobyinkster.co.uk/message/a7814ec426ee7d944b99a22018d4e9f2.squirrel%40goddamn.co.uk Re: Getting the XHTML+RDFa default profile to be interesting 2010-08-15T21:48:15 2010-08-15T21:48:15 2010-08-15T21:48:15 > I don't have access to there either. Just make updates and we can get > someone to check them in once they are solid. OK, here's a first stab at it: http://buzzword.org.uk/2010/xhtml-vocab-20100815.xhtml I've not touched part 3 yet, but should have time to before the next telecon. -Toby > I don't have access to there either. Just make updates and we can get > someone to check them in once they are solid. OK, here's a first stab at it: http://buzzword.org.uk/2010/xhtml-vocab-20100815.xhtml I've not touched part 3 yet, but should have time to before the next telecon. -Toby http://tobyinkster.co.uk/message/20100817234958.6c9856d0%40miranda.g5n.co.uk Re: longdesc URLs and RDFa 2010-08-17T22:49:58 2010-08-17T22:49:58 2010-08-17T22:49:58 On Sun, 15 Aug 2010 18:50:41 +0200 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > <blockquote id="q1" about="#q1" rel="cite" > resource="urn:ISBN:0140449132"/> This question on semanticoverflow seems relevant: http://www.semanticoverflow.com/questions/1198/how-to-express-a-book-quote-into-rdfahtml-use-cases -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 15 Aug 2010 18:50:41 +0200 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > <blockquote id="q1" about="#q1" rel="cite" > resource="urn:ISBN:0140449132"/> This question on semanticoverflow seems relevant: http://www.semanticoverflow.com/questions/1198/how-to-express-a-book-quote-into-rdfahtml-use-cases -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100818100230.59cec2c1%40miranda.g5n.co.uk Re: longdesc URLs and RDFa 2010-08-18T09:02:30 2010-08-18T09:02:30 2010-08-18T09:02:30 On Wed, 18 Aug 2010 06:48:43 +0200 Ivan Herman <ivan@w3.org> wrote: > You said that the floodgate was opened when RDFa accepted @href and > @src. While this may very well be true, what you describe in your > examples go further. To stick to @longdesc, you seem to ask not only > to interpret @longdesc somehow, but also to assign a specific > property to it I think the easiest, least disruptive a... On Wed, 18 Aug 2010 06:48:43 +0200 Ivan Herman <ivan@w3.org> wrote: > You said that the floodgate was opened when RDFa accepted @href and > @src. While this may very well be true, what you describe in your > examples go further. To stick to @longdesc, you seem to ask not only > to interpret @longdesc somehow, but also to assign a specific > property to it I think the easiest, least disruptive and most useful way to interpret @longdesc, were we to add it would be the following: - parse the value in the same way as @src/@href (i.e. it's a single URI, no space delimiting, no CURIEs) - treat that URI in the same was as the URIs we get from @typeof, except instead of hard-coding the predicate rdf:type, hardcode rdfs:seeAlso or a subproperty of rdfs:seeAlso. Importantly, unlike @resource/@href it does not set the attribute value as a new subject in chaining. That way: <img src="foo.jpeg" longdesc="foo.html" alt="" /> Gets parsed as: @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . <foo.jpeg> rdfs:seeAlso <foo.html> . And the following: <div typeof="ex:Widget" longdesc="my-widget.html"> <span property="ex:identifier">1234</span> </div> Gets parsed as: @prefix ex: <http://example.net/ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . [] a ex:Widget ; rdfs:seeAlso <my-widget.html> ; ex:identifier "1234" . (Whether longdesc on a non-img element is considered valid is a matter for HTMLWG - RDFa treats all elements more or less equally.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100818170904.7eae3ac6%40miranda.g5n.co.uk Re: longdesc URLs and RDFa 2010-08-18T16:09:04 2010-08-18T16:09:04 2010-08-18T16:09:04 On Wed, 18 Aug 2010 13:08:37 +0200 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > > That way: > > > > <img src="foo.jpeg" longdesc="foo.html" alt="" /> > > > > Gets parsed as: > > > > @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . > > <foo.jpeg> rdfs:seeAlso <foo.html> . > > I of course think this sounds interesteing. But would the > "hard-coding" mean that it woul... On Wed, 18 Aug 2010 13:08:37 +0200 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > > That way: > > > > <img src="foo.jpeg" longdesc="foo.html" alt="" /> > > > > Gets parsed as: > > > > @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . > > <foo.jpeg> rdfs:seeAlso <foo.html> . > > I of course think this sounds interesteing. But would the > "hard-coding" mean that it would be impossible to replace the > rdfs:seeAlso predicate with one's won predicate? E.g. like this: > > <img src="foo.jpeg" rel="foo" longdesc="foo.html" alt="" /> > > What, eventually, is the motivation for doing so? I wouldn't rule out minting a longdesc-specific predicate, such as xhv:longdesc in the XHTML vocabulary to cover the purpose rather than re-using rdfs:seeAlso. But I do think the predicate should be hard-coded. First of all, that allows longdesc to be used alongside the @rel/@resource combination: <img src="foo.jpeg" alt="foo" longdesc="foo.html" rel="cc:license" href="http://example.net/foo-public-license" /> And secondly, and more importantly, the predicate should be hard-coded to reflect the established meaning in HTML that longdesc has (which is somewhat close to rdfs:seeAlso). One wouldn't want @longdesc polluted as a place to put generic image-related links which aren't links to long descriptions. e.g. <img src="foo.jpeg" alt="foo" rel="ex:larger" longdesc="foo-big.jpeg" /> > And an idea to - at some undecided point in the undecided future - > either globalize @longdesc or mint new, global, attribute with the > same functionality, is floating in the air. That's nice to hear. IIRC ARIA has something to offer in this department. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100818204545.46b8c1d5%40miranda.g5n.co.uk Re: longdesc URLs and RDFa 2010-08-18T19:45:45 2010-08-18T19:45:45 2010-08-18T19:45:45 On Wed, 18 Aug 2010 12:39:32 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > That's why at the very beginning of this discussion I said that we > should look at how we allow host languages to define their own > 'mappings' from attributes and elements to predicates. This seems to be straying into reinventing GRDDL. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 18 Aug 2010 12:39:32 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > That's why at the very beginning of this discussion I said that we > should look at how we allow host languages to define their own > 'mappings' from attributes and elements to predicates. This seems to be straying into reinventing GRDDL. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100818205305.2567dfc0%40miranda.g5n.co.uk Re: longdesc URLs and RDFa 2010-08-18T19:53:05 2010-08-18T19:53:05 2010-08-18T19:53:05 On Wed, 18 Aug 2010 12:13:51 -0400 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > The first would draw an equivalence between @src and @about. But there isn't an equivalence between them in RDFa 1.0, nor in the current 1.1 drafts. Firstly, @about takes precedence over @src. Secondly, @about can take a CURIE or blank node identifier as a value, whereas @src can't. Yes, I'm sure those differences could be catered for, but at some point it becomes easier to just define a GRDDL namespaceTransformation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 18 Aug 2010 12:13:51 -0400 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > The first would draw an equivalence between @src and @about. But there isn't an equivalence between them in RDFa 1.0, nor in the current 1.1 drafts. Firstly, @about takes precedence over @src. Secondly, @about can take a CURIE or blank node identifier as a value, whereas @src can't. Yes, I'm sure those differences could be catered for, but at some point it becomes easier to just define a GRDDL namespaceTransformation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100818211754.613cf06d%40miranda.g5n.co.uk Re: XSD ontology 2010-08-18T20:17:54 2010-08-18T20:17:54 2010-08-18T20:17:54 On Tue, 17 Aug 2010 16:56:43 -0700 Joshua Shinavier <josh@fortytwo.net> wrote: > Very nice! Will you also add rdfs:label's? rdfs:isDefinedBy might be nice too. > It might be nice to have the type hierarchy [1] in a machine-readable > format, as well, if there is an RDF property suitable for expressing > the subtype relationship. rdfs:subClassOf should do that job. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 17 Aug 2010 16:56:43 -0700 Joshua Shinavier <josh@fortytwo.net> wrote: > Very nice! Will you also add rdfs:label's? rdfs:isDefinedBy might be nice too. > It might be nice to have the type hierarchy [1] in a machine-readable > format, as well, if there is an RDF property suitable for expressing > the subtype relationship. rdfs:subClassOf should do that job. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100818213412.3e7825ec%40miranda.g5n.co.uk Re: foaf-search.net now offers free API to search FOAF social graph 2010-08-18T20:34:12 2010-08-18T20:34:12 2010-08-18T20:34:12 On Wed, 18 Aug 2010 10:04:18 +0200 Michael Brunnbauer <brunni@netestate.de> wrote: > netEstate GmbH I seem to remember speculation about this netEstate crawler and what it might be a few months ago. I'm pretty impressed. It would be nice if there were an "other people based near here" link next to foaf:based_here locations. Would also be nice if your profile pages included embedded RDFa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 18 Aug 2010 10:04:18 +0200 Michael Brunnbauer <brunni@netestate.de> wrote: > netEstate GmbH I seem to remember speculation about this netEstate crawler and what it might be a few months ago. I'm pretty impressed. It would be nice if there were an "other people based near here" link next to foaf:based_here locations. Would also be nice if your profile pages included embedded RDFa. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100818214926.38df8d6a%40miranda.g5n.co.uk Re: making statements about the lexical form of a URI 2010-08-18T20:49:26 2010-08-18T20:49:26 2010-08-18T20:49:26 On Thu, 12 Aug 2010 20:08:47 +0100 Nathan <nathan@webr3.org> wrote: > The specific question is, how do you unambiguously identify a URI in > order to make statements about the lexical form of that URI? My URI ontology <http://purl.org/NET/uri#> should work for such things. Its focus is saying what URIs a resource has, who minted the URIs and their stability, though adding some extra predicates for things like u:authority is a possibility - I'd be happy to do so if someone requests them. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 12 Aug 2010 20:08:47 +0100 Nathan <nathan@webr3.org> wrote: > The specific question is, how do you unambiguously identify a URI in > order to make statements about the lexical form of that URI? My URI ontology <http://purl.org/NET/uri#> should work for such things. Its focus is saying what URIs a resource has, who minted the URIs and their stability, though adding some extra predicates for things like u:authority is a possibility - I'd be happy to do so if someone requests them. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100828215118.12e00569%40miranda.g5n.co.uk Re: A possible design to incorporate collections and containers into RDFa? 2010-08-28T20:51:18 2010-08-28T20:51:18 2010-08-28T20:51:18 On Wed, 25 Aug 2010 13:40:50 +0200 Ivan Herman <ivan@w3.org> wrote: > I wrote down my current design on the Wiki: > > http://www.w3.org/2010/02/rdfa/wiki/ContainersAndCollections I think this is a good start. Little problem though re the use of @resource to trigger the list behaviour. Consider the following: <div about="#eachpeach"> <i property="dc:title">Each Peach Pear Plum</i> <u... On Wed, 25 Aug 2010 13:40:50 +0200 Ivan Herman <ivan@w3.org> wrote: > I wrote down my current design on the Wiki: > > http://www.w3.org/2010/02/rdfa/wiki/ContainersAndCollections I think this is a good start. Little problem though re the use of @resource to trigger the list behaviour. Consider the following: <div about="#eachpeach"> <i property="dc:title">Each Peach Pear Plum</i> <ul rel="dc:creator" resource="::Bag"> <li property="::member">Janet Ahlberg</li> <li property="::member">Allen Ahlberg</li> </ul> </div> <div about="#megmog"> <i property="dc:title">Meg and Mog</i> <ul rel="dc:creator" resource="::Bag"> <li property="::member">Helen Nicoll</li> <li property="::member">Jan Pienkowski</li> </ul> </div> If this were parsed in an RDFa 1.0 parser, it would come out as: <#eachpeach> dc:title "Each Peach Pear Plum" ; dc:creator <./::Bag> . <#megmog> dc:title "Meg and Mog" ; dc:creator <./::Bag> . <./::Bag> <http://www.w3.org/1999/xhtml/vocab#:member> "Janet Ahlberg" ; <http://www.w3.org/1999/xhtml/vocab#:member> "Allen Ahlberg" ; <http://www.w3.org/1999/xhtml/vocab#:member> "Helen Nicoll" ; <http://www.w3.org/1999/xhtml/vocab#:member> "Jan Pienkowski" . Any automated agent looking at that would conclude that the two books have the same authors. Something using, say, @typeof wouldn't suffer from this problem. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100903093738.52ed93ef%40miranda.g5n.co.uk Re: UMarks - a universal bookmark system. 2010-09-03T08:37:38 2010-09-03T08:37:38 2010-09-03T08:37:38 On Thu, 02 Sep 2010 18:35:01 +0100 UMarks <info@umarks.org> wrote: > I hadn't heard of XBEL, so I have checked it out in an attempt to > answer your question. It's a pretty well-known format for bookmarks, and is the native bookmark format for several browsers. Revising XBEL to create a v1.2 compatible with existing software seems a much more productive route than devising a new format. > First... On Thu, 02 Sep 2010 18:35:01 +0100 UMarks <info@umarks.org> wrote: > I hadn't heard of XBEL, so I have checked it out in an attempt to > answer your question. It's a pretty well-known format for bookmarks, and is the native bookmark format for several browsers. Revising XBEL to create a v1.2 compatible with existing software seems a much more productive route than devising a new format. > Firstly, it looks like it has been some time since XBEL was updated. > Much of the documentation dates from 1998, and the last update to > anything I could find was 2002. It doesn't seem to be under active > development. One man's "not under active development" is another man's "stable". > Bookmarks have moved on since then, and this shows in the scope of > XBEL. For example it lacks support for favicons, keywords or > summaries; most of which are additions that have become more > commonplace since the late 90's. There is a <metadata> tag where one > could ostensibly capture some of this mind you. There is a <desc> tag suitable for summaries. Keywords/tags can be stored using <metadata> (there's an example of using <metadata> for tags here - http://www.xml.com/pub/a/2005/03/02/restful.html). There is an "icon" attribute on <folder> and <bookmark> elements, though it's not a URI, so may be of limited utility. > I couldn't quite work out how a bookmark hierarchy was maintained, > although I assumed it was by creating a nested arrangement within the > file itself. The same xml.com article I linked to above (which is the first hit on Google for 'xbel example') contains an example with nested <folder> elements. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100903093949.43f654a0%40miranda.g5n.co.uk jsonGRDDL spec revision 2010-09-03T08:39:49 2010-09-03T08:39:49 2010-09-03T08:39:49 I've just published a fairly major revision of the jsonGRDDL draft spec: http://buzzword.org.uk/2008/jsonGRDDL/spec.20100903 jsonGRDDL is a GRDDL-like mechanism for mapping from generic JSON data to RDF graphs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I've just published a fairly major revision of the jsonGRDDL draft spec: http://buzzword.org.uk/2008/jsonGRDDL/spec.20100903 jsonGRDDL is a GRDDL-like mechanism for mapping from generic JSON data to RDF graphs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100904004222.1567c5e5%40miranda.g5n.co.uk LOB - linked open bard 2010-09-03T23:42:22 2010-09-03T23:42:22 2010-09-03T23:42:22 Every play by Shakespeare in RDF: http://ontologi.es/lob/ For example: http://ontologi.es/lob/Hamlet.ttl "Two Noble Kinsmen" is not included, as I couldn't find a good XML version to convert to RDF, and Shakespeare only co-wrote it anyway. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Every play by Shakespeare in RDF: http://ontologi.es/lob/ For example: http://ontologi.es/lob/Hamlet.ttl "Two Noble Kinsmen" is not included, as I couldn't find a good XML version to convert to RDF, and Shakespeare only co-wrote it anyway. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100904004409.331ad8a7%40miranda.g5n.co.uk LOB - linked open bard 2010-09-03T23:44:09 2010-09-03T23:44:09 2010-09-03T23:44:09 Every play by Shakespeare in RDF: http://ontologi.es/lob/ For example: http://ontologi.es/lob/Hamlet.ttl "Two Noble Kinsmen" is not included, as I couldn't find a good XML version to convert to RDF, and Shakespeare only co-wrote it anyway. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Every play by Shakespeare in RDF: http://ontologi.es/lob/ For example: http://ontologi.es/lob/Hamlet.ttl "Two Noble Kinsmen" is not included, as I couldn't find a good XML version to convert to RDF, and Shakespeare only co-wrote it anyway. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100905005557.5e3a07d1%40miranda.g5n.co.uk Re: LOB - linked open bard 2010-09-04T23:55:57 2010-09-04T23:55:57 2010-09-04T23:55:57 On Sat, 4 Sep 2010 14:44:38 -0400 Ed Summers <ehs@pobox.com> wrote: > Do you have idea where the file URIs are coming from? > > rapper -o turtle http://ontologi.es/lob/ Thanks - fixed. index.rdf and vocab.rdf had been generated by rapper from index.ttl and vocab.ttl, but without setting the base URI correctly. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 4 Sep 2010 14:44:38 -0400 Ed Summers <ehs@pobox.com> wrote: > Do you have idea where the file URIs are coming from? > > rapper -o turtle http://ontologi.es/lob/ Thanks - fixed. index.rdf and vocab.rdf had been generated by rapper from index.ttl and vocab.ttl, but without setting the base URI correctly. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/db4f69bc8f158bc224030cb04fbb54b0.squirrel%40goddamn.co.uk WordNet RDF 2010-09-08T11:39:36 2010-09-08T11:39:36 2010-09-08T11:39:36 Dear all, I've created a think RDF wrapper around the WordNet 3.0 database (nouns only). For example: http://ontologi.es/WordNet/data/Fool This is nothing especially new - Dan Brickley did something similar with WordNet 1.6, many moons ago, and the W3C has also published an RDF version of WordNet 2.something. Here are a few features of note: Dan's version represented each noun as an rdfs:Cl... Dear all, I've created a think RDF wrapper around the WordNet 3.0 database (nouns only). For example: http://ontologi.es/WordNet/data/Fool This is nothing especially new - Dan Brickley did something similar with WordNet 1.6, many moons ago, and the W3C has also published an RDF version of WordNet 2.something. Here are a few features of note: Dan's version represented each noun as an rdfs:Class; the W3C version represents each word as something like a skos:Concept (though it uses a pre-SKOS vocabulary). Mine does both, using separate URIs. For instance: <http://ontologi.es/WordNet/class/Fool-1> An rdfs:Class defined as "a person who lacks good judgment". <http://ontologi.es/WordNet/concept/Fool-1> A skos:Concept defined as "a person who lacks good judgment". These are related using foaf:focus to link from skos:Concept to rdfs:Class, and rdfs:seeAlso to link back the other way. The skos:Concept is rich with narrower/broader/related relationships, and alternative labels; the rdfs:Class less so. Note that "Fool-1" is just one sense that the English word "fool" can be taken to mean. There are two other senses: as a synonym of "chump" or "fallguy"; and as a synonym of "jester". There's a class: <http://ontologi.es/WordNet/class/Fool> which acts as a superclass of all three senses of the word "fool". With "fool", the meanings of each sense are close enough that the distinction is not especially important, but with say "crack" this could refer to a small gap (a doorway that's open a crack), a break (a crack in a mirror), a sound (the crack of a whip) or crack cocaine - so distinguishing is more useful. This data is not SPARQLable as it's assembled on request. I ought to be able to release the source code for it fairly soon, which will allow you to create a local mirror if you want to, say, crawl the data. -Toby http://tobyinkster.co.uk/message/20100908150408.391906c2%40miranda.g5n.co.uk Re: Ongoing objection to RDFa Profiles format (as XHTML+RDFa) 2010-09-08T14:04:08 2010-09-08T14:04:08 2010-09-08T14:04:08 On Wed, 08 Sep 2010 06:44:41 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > #1) We have a software architecture where the foundations depend on > the finished product. It's really just a case of recursion. Anyone who's taken a course in programming will have had to write a function like this: function fib ($n) { if (!is_int($n) || $n < 0) return null; elseif ($n < 2) return ... On Wed, 08 Sep 2010 06:44:41 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > #1) We have a software architecture where the foundations depend on > the finished product. It's really just a case of recursion. Anyone who's taken a course in programming will have had to write a function like this: function fib ($n) { if (!is_int($n) || $n < 0) return null; elseif ($n < 2) return $n; else return fib($n-1) + fib($n-2); } Recursive programming is not inherently bad design; it's sometimes a little inefficient, and you need to take care to avoid loops, but it can be quite a neat way of coding. > #2) It's not good RDF...it's a pattern that no-one else uses. Having profiles *at all* is something that no-one else does. Personally I'm still not convinced we need such a feature. > #3) To implement it properly you need to be able to query the triple > store. True, but that doesn't have to be using SPARQL - a single iteration over the triple store ought to be sufficient to extract all the data you need from a profile. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100910235822.1edde66a%40miranda.g5n.co.uk Re: WordNet RDF 2010-09-10T22:58:22 2010-09-10T22:58:22 2010-09-10T22:58:22 On Thu, 9 Sep 2010 14:30:52 +0100 Ian Davis <lists@iandavis.com> wrote: > This is based on the RDF conversion at > http://semanticweb.cs.vu.nl/lod/wn30/ > > How similar is your work to this version? They're similar in that they're both based on Wordnet 3. There are some key differences though: 1. The vu.nl version includes all of Wordnet. Mine is just the nouns. 2. The vu.nl version uses a SK... On Thu, 9 Sep 2010 14:30:52 +0100 Ian Davis <lists@iandavis.com> wrote: > This is based on the RDF conversion at > http://semanticweb.cs.vu.nl/lod/wn30/ > > How similar is your work to this version? They're similar in that they're both based on Wordnet 3. There are some key differences though: 1. The vu.nl version includes all of Wordnet. Mine is just the nouns. 2. The vu.nl version uses a SKOS-like modelling (though not SKOS): "cat" for example has an rdf:type of something like "Noun". In mine, "Cat" would have an rdf:type of rdfs:Class - i.e. I define each noun as a class. I also include a parallel SKOS mapping of Wordnet 3 and reference between them using rdfs:seeAlso/foaf:focus. 3. I define superclasses to group all reasonable interpretations of English language words. e.g. a "Fool" superclass that is the union of "Fool, as in incompetent person", "Fool, as in gullible person" and "Fool, as in jester". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100913211758.08df824b%40miranda.g5n.co.uk Re: Small @profile question 2010-09-13T20:17:58 2010-09-13T20:17:58 2010-09-13T20:17:58 On Fri, 10 Sep 2010 10:21:14 +0100 Nathan <nathan@webr3.org> wrote: > Perhaps that's a question I should ask then, if an (X)HTML+RDFa 1.1 > document contains CURIE-s that cannot be resolved, ... This is a situation which I don't think can arise. A CURIE-like token that doesn't correspond to an existing CURIE prefix is taken to be a URI. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 10 Sep 2010 10:21:14 +0100 Nathan <nathan@webr3.org> wrote: > Perhaps that's a question I should ask then, if an (X)HTML+RDFa 1.1 > document contains CURIE-s that cannot be resolved, ... This is a situation which I don't think can arise. A CURIE-like token that doesn't correspond to an existing CURIE prefix is taken to be a URI. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100913211958.67761aa2%40miranda.g5n.co.uk Re: Small @profile question 2010-09-13T20:19:58 2010-09-13T20:19:58 2010-09-13T20:19:58 On Fri, 10 Sep 2010 10:21:14 +0100 Nathan <nathan@webr3.org> wrote: > I mean that if I have an RDF Graph which I serialize as Turtle, > RDF/XML and (X)HTML+RDFa and expose via content negotiation, where > all three variants are valid and produce the same set of RDF Triples > at Last-Modified time, and where the RDFa variant relies on profiles, > then it's possible for the Graph produced by parsin... On Fri, 10 Sep 2010 10:21:14 +0100 Nathan <nathan@webr3.org> wrote: > I mean that if I have an RDF Graph which I serialize as Turtle, > RDF/XML and (X)HTML+RDFa and expose via content negotiation, where > all three variants are valid and produce the same set of RDF Triples > at Last-Modified time, and where the RDFa variant relies on profiles, > then it's possible for the Graph produced by parsing the RDFa > Document to vary over time without modifying the file/representation, > whilst not-so with the other two variants. Actually it's possible for the meaning of the RDF/XML file to vary too, using entities defined in an external DTD. Though not many RDF/XML parsers support external DTDs, so people tend not to do that. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100914081552.44a7f616%40miranda.g5n.co.uk Re: Small @profile question 2010-09-14T07:15:52 2010-09-14T07:15:52 2010-09-14T07:15:52 On Tue, 14 Sep 2010 06:32:38 +0200 Ivan Herman <ivan@w3.org> wrote: > I think that is the important point regarding the original issue. > There won't be _different_ triples (if the @profile is not loadable) > but _no_ triples. That was the issue of Jeni that led to this > resolution There will be different triples if the profile is loadable but no mappings can be extracted from it. e.g. if a pr... On Tue, 14 Sep 2010 06:32:38 +0200 Ivan Herman <ivan@w3.org> wrote: > I think that is the important point regarding the original issue. > There won't be _different_ triples (if the @profile is not loadable) > but _no_ triples. That was the issue of Jeni that led to this > resolution There will be different triples if the profile is loadable but no mappings can be extracted from it. e.g. if a profile defined a mapping for prefix 'dc' then the triple: <> <http://purl.org/dc/terms/title> "Example"@en . might become: <> <dc:title> "Example"@en . This situation could occur if the server hosting the profile serves, say, an error response (e.g. Not Found) with an incorrect HTTP status code. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100914145725.67c3ed0d%40miranda.g5n.co.uk Re: Small @profile question 2010-09-14T13:57:25 2010-09-14T13:57:25 2010-09-14T13:57:25 On Tue, 14 Sep 2010 09:27:26 +0200 Ivan Herman <ivan@w3.org> wrote: > On Sep 14, 2010, at 09:15 , Toby Inkster wrote: > > > This situation could occur if the server hosting the profile serves, > > say, an error response (e.g. Not Found) with an incorrect HTTP > > status code. > > Hm. I do not think I agree with your last statement, though I agree > with the rest. An HTTP not found should mean... On Tue, 14 Sep 2010 09:27:26 +0200 Ivan Herman <ivan@w3.org> wrote: > On Sep 14, 2010, at 09:15 , Toby Inkster wrote: > > > This situation could occur if the server hosting the profile serves, > > say, an error response (e.g. Not Found) with an incorrect HTTP > > status code. > > Hm. I do not think I agree with your last statement, though I agree > with the rest. An HTTP not found should mean the file is not loadable > so the 'no triple generated' feature should kick in. I agree that an HTTP not found *should* do that, but the situation I outlined is where a "Not Found" or similar error page has been served with an incorrect HTTP status code - such as 200 OK. One does see such things from time to time - mainly on sites with poorly written content management systems. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100915170140.5e7f9922%40miranda.g5n.co.uk Re: Absorbing Microdata 2010-09-15T16:01:40 2010-09-15T16:01:40 2010-09-15T16:01:40 On Wed, 15 Sep 2010 11:04:03 +0200 Ivan Herman <ivan@w3.org> wrote: > I think having a document that states very clearly how the microdata > information can be turned into RDF would be very good. You mean like this? http://www.w3.org/TR/microdata/#rdf Implemented here: http://search.cpan.org/~tobyink/HTML-HTML5-Microdata-Parser/ > If there was a possibility to map an HTML5+Microdata file to a ... On Wed, 15 Sep 2010 11:04:03 +0200 Ivan Herman <ivan@w3.org> wrote: > I think having a document that states very clearly how the microdata > information can be turned into RDF would be very good. You mean like this? http://www.w3.org/TR/microdata/#rdf Implemented here: http://search.cpan.org/~tobyink/HTML-HTML5-Microdata-Parser/ > If there was a possibility to map an HTML5+Microdata file to a > HTML5+RDFa file or, to put it another way, a DOM->DOM type > transformation then that would of course be useful. You mean like this? http://search.cpan.org/~tobyink/HTML-HTML5-Microdata-ToRDFa/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100915170700.00a8b7fb%40miranda.g5n.co.uk Re: Absorbing Microdata 2010-09-15T16:07:00 2010-09-15T16:07:00 2010-09-15T16:07:00 On Tue, 14 Sep 2010 23:19:53 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > There are still problems with nesting itemprops/itemscopes and the > types that Microdata has specified for vcard, vevent and work... > don't know if anybody else has looked at this yet. Just throwing it > out there. I do not think this is a good idea. RDFa and Microdata have different methods for establishing su... On Tue, 14 Sep 2010 23:19:53 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > There are still problems with nesting itemprops/itemscopes and the > types that Microdata has specified for vcard, vevent and work... > don't know if anybody else has looked at this yet. Just throwing it > out there. I do not think this is a good idea. RDFa and Microdata have different methods for establishing subjects, etc. If you actually tried to parse a document that contained both RDFa and Microdata this way, you'd end up with a jumble of nonsense. RDFa and Microdata each have a well-defined algorithm for parsing into an RDF graph. Just parse each and then merge the graphs. PS: if you think @itemref is similar to @about, you need to re-read the Microdata draft spec! There is nothing similar to @itemref in RDFa. Implementing support for it was probably the toughest part of my Microdata to RDFa converter. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100915171416.2b79741b%40miranda.g5n.co.uk Re: HTML WG: ISSUE-120 Use of prefixes is too complicated for a Web technology 2010-09-15T16:14:16 2010-09-15T16:14:16 2010-09-15T16:14:16 On Wed, 15 Sep 2010 08:59:53 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://www.w3.org/html/wg/tracker/issues/120 Ultimately I think people will use prefixes whether RDFa provides such a facility or not. If prefixes were taken out of RDFa (which they should not be BTW as it would cause massive backwards incompatibility - but deprecating them might be a possibility) then people wou... On Wed, 15 Sep 2010 08:59:53 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > http://www.w3.org/html/wg/tracker/issues/120 Ultimately I think people will use prefixes whether RDFa provides such a facility or not. If prefixes were taken out of RDFa (which they should not be BTW as it would cause massive backwards incompatibility - but deprecating them might be a possibility) then people would end up using things like this in server-side code: <?php $FOAF = 'http://xmlns.com/foaf/0.1/'; // ... echo "<span property=\"${FOAF}name\">${name}</span>\n"; ?> People are going to want to abbreviate URIs somehow. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100915210917.57d7d1fa%40miranda.g5n.co.uk Re: Absorbing Microdata 2010-09-15T20:09:17 2010-09-15T20:09:17 2010-09-15T20:09:17 On Wed, 15 Sep 2010 19:58:17 +0200 Ivan Herman <ivan@w3.org> wrote: > thank you, but this seems to be the same document that Toby was > referring to. But that is not what I was looking for:-( That document > defines a Microdata->RDF transformation; what I am wondering is > whether it is possible to have a Microdata->RDFa transformation, too. > If so, then existing RDFa implementations could be ea... On Wed, 15 Sep 2010 19:58:17 +0200 Ivan Herman <ivan@w3.org> wrote: > thank you, but this seems to be the same document that Toby was > referring to. But that is not what I was looking for:-( That document > defines a Microdata->RDF transformation; what I am wondering is > whether it is possible to have a Microdata->RDFa transformation, too. > If so, then existing RDFa implementations could be easily extended to > include microdata, too. If RDFa implementations wish to support Microdata, then converting Microdata to RDFa before parsing is just about the most complicated way they could offer said support. I've been trying to think of more complicated ways they could do it, but I can't. ;-) Most of the conversion is relatively easy. It's generally just a matter of detecting certain Microdata attributes, or combinations thereof, and replacing them with RDFa equivalents. There are two main exceptions: 1. The combination of @itemprop, @itemscope and @itemtype on the same element. In RDFa terms this is roughly equivalent to: <div rel="itemprop" resource="itemscope" resource-typeof="itemtype"> i.e. it sets the type for the object of the triple rather than the subject. I get around this by adding a hidden <span> child element and including an rdf:type triple on that hidden element. Nothing too tricky. 2. The @itemref attribute - as I previously mentioned, RDFa has no equivalent. Consider this: <p id="age"> The following people are all aged <span itemprop="http://xmlns.com/foaf/0.1/age" >30</span>: </p> <ul> <li itemscope itemref="#age"> <b itemprop="http://xmlns.com/foaf/0.1/name">Alice</b> </li> <li itemscope itemref="#age"> <b itemprop="http://xmlns.com/foaf/0.1/name">Bob</b> </li> <li itemscope itemref="#age"> <b itemprop="http://xmlns.com/foaf/0.1/name">Carol</b> </li> </ul> From what I can tell, the only way this can be converted to RDFa is: If an element has @itemscope and @itemref, hand that element (call it 'X') over to a Microdata parser. For each triple you get back, skip the triple if the element it was generated on was X itself, or a descendent of X. For each triple that has not been skipped, create a hidden <span> element as a child of X and add RDFa attributes to encode the triple. It's actually slightly more complicated than that in that you need to align bnode identifiers. But the upshot of it is that I don't think you can get away with doing Microdata-to-RDFa without embedding a full Microdata parser. Microdata-to-RDFa has potential uses for publishers, and middle-man conversion services, but I don't think it's especially useful for RDFa consumers. I'd be happy to write it up though. My algorithm's not been tested on a wide variety of input, though it seems to work in theory. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100915212745.0b764e36%40miranda.g5n.co.uk Re: Absorbing Microdata 2010-09-15T20:27:45 2010-09-15T20:27:45 2010-09-15T20:27:45 On Wed, 15 Sep 2010 20:04:42 +0100 Martin McEvoy <martin@weborganics.co.uk> wrote: > ARC2 will transform RDFa to Microdata and also Microdata to RDFa ;) Well, yes, it's easy enough to parse one format and then serialise it as another. The algorithm I've been discussing translates the Microdata in place, creating a document that's otherwise more or less identical to the input. e.g. Microdata in... On Wed, 15 Sep 2010 20:04:42 +0100 Martin McEvoy <martin@weborganics.co.uk> wrote: > ARC2 will transform RDFa to Microdata and also Microdata to RDFa ;) Well, yes, it's easy enough to parse one format and then serialise it as another. The algorithm I've been discussing translates the Microdata in place, creating a document that's otherwise more or less identical to the input. e.g. Microdata input: http://buzzword.org.uk/2010/md2rdfa/example1/microdata.html RDFa output: http://buzzword.org.uk/2010/md2rdfa/example1/rdfa.xhtml With RDFa 1.1, the output could be made a little nicer, as URIs don't need rewriting as CURIEs plus xmlns. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100918160541.083a9eb9%40miranda.g5n.co.uk Re: Absorbing Microdata 2010-09-18T15:05:41 2010-09-18T15:05:41 2010-09-18T15:05:41 On Fri, 17 Sep 2010 10:33:07 +0100 Martin McEvoy <martin@weborganics.co.uk> wrote: > <figcaption > xmlns:md="http://www.w3.org/1999/xhtml/microdata#"property="md:http%3A%2F%2Fn.whatwg.org%2Fwork%23%3Atitle"about="_:HTMLAutoNode000">The > house I found.</figcaption> > > shouldn't the correct output be something like... > > <figcaption > xmlns:work="http://n.whatwg.org/work#"property="work:title"... On Fri, 17 Sep 2010 10:33:07 +0100 Martin McEvoy <martin@weborganics.co.uk> wrote: > <figcaption > xmlns:md="http://www.w3.org/1999/xhtml/microdata#"property="md:http%3A%2F%2Fn.whatwg.org%2Fwork%23%3Atitle"about="_:HTMLAutoNode000">The > house I found.</figcaption> > > shouldn't the correct output be something like... > > <figcaption > xmlns:work="http://n.whatwg.org/work#"property="work:title"about="_:HTMLAutoNode000">The > house I found.</figcaption> No, the crazy-looking predicate URIs are mandated by the Microdata spec: http://www.w3.org/TR/microdata/#generate-the-triples-for-an-item See step 6.1.5, "If name contains no U+003A COLON characters". If you want non-crazy predicate URIs in Microdata, you need to use full URIs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100922001833.1502de8b%40miranda.g5n.co.uk Re: WordNet RDF 2010-09-21T23:18:33 2010-09-21T23:18:33 2010-09-21T23:18:33 On Mon, 20 Sep 2010 13:45:07 +0200 Antoine Isaac <aisaac@few.vu.nl> wrote: > Very interesting! I'm curious though: what's the application scenario > that made you create this version? It makes it easy to insult people in RDF. <#you> a wordnet:Fool . #!!! More seriously, it's mostly just designed as a drop-in replacement for danbri's old Wordnet RDF stuff which went offline some time ago. Thou... On Mon, 20 Sep 2010 13:45:07 +0200 Antoine Isaac <aisaac@few.vu.nl> wrote: > Very interesting! I'm curious though: what's the application scenario > that made you create this version? It makes it easy to insult people in RDF. <#you> a wordnet:Fool . #!!! More seriously, it's mostly just designed as a drop-in replacement for danbri's old Wordnet RDF stuff which went offline some time ago. Though this is based on a newer version of Wordnet and has SKOSey stuff thrown in as a bonus. > How do you make the distinction between the two situations--I mean, > based on which elements in the Wordnet data? *I* don't. If somebody decides that wordnet:Crack is accurate and specific enough for them, even though it's a class that covers sound effects, Class A drugs and fissures, then that's fine by me. If they want more specific classes, then those are provided too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100924084052.69ec458a%40miranda.g5n.co.uk Re: Time for quintuples? 2010-09-24T07:40:52 2010-09-24T07:40:52 2010-09-24T07:40:52 On Fri, 24 Sep 2010 01:12:45 +0200 Bob Ferris <zazi@elbklang.net> wrote: > However, if I have for example three "shortcut relations" (e.g. a > skill, an expertise and and interest) in a graph, which have all the > same topic, I can't match them to the related cognitive > characteristic statement (as you can also see in the original > example[1]). What's wrong with this? ex:APerson cco:skil... On Fri, 24 Sep 2010 01:12:45 +0200 Bob Ferris <zazi@elbklang.net> wrote: > However, if I have for example three "shortcut relations" (e.g. a > skill, an expertise and and interest) in a graph, which have all the > same topic, I can't match them to the related cognitive > characteristic statement (as you can also see in the original > example[1]). What's wrong with this? ex:APerson cco:skill <http://dbpedia.org/resource/Football_(soccer)> . ex:CC1 a cco:CognitiveCharacteristic ; cco:agent ex:APerson ; #added this cco:characteristic cco:skill ; #added this cco:topic <http://dbpedia.org/resource/Football_(soccer)>; wo:weight [ a wo:Weight ; wo:weight_value 6.0 ; wo:scale ex:AScale ]; cco:activity <http://sw.opencyc.org/concept/Mx4rwJRiEpwpEbGdrcN5Y29ycA> . The following N3 rule would allow you to infer the shortcut property from the longer form: { ?cc cco:agent ?s ; cco:characteristic ?p ; cco:topic ?o . } => { ?s ?p ?o . } . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100925212723.086d8ce7%40miranda.g5n.co.uk Re: BlankNode in subject 2010-09-25T20:27:23 2010-09-25T20:27:23 2010-09-25T20:27:23 On Sat, 25 Sep 2010 18:39:41 +0100 Nathan <nathan@webr3.org> wrote: > reworded.. are the following equivalent: > > [ :firstname "Ora" ] dc:wrote [ dc:title "Moby Dick" ] . > > _:b1 owl:sameAs [ :firstname "Ora" ]; > dc:wrote [ dc:title "Moby Dick" ] . > > as in, can either be used to produce the same pseudo triples / graph > in NTriples. They have the same meaning when interpreted ... On Sat, 25 Sep 2010 18:39:41 +0100 Nathan <nathan@webr3.org> wrote: > reworded.. are the following equivalent: > > [ :firstname "Ora" ] dc:wrote [ dc:title "Moby Dick" ] . > > _:b1 owl:sameAs [ :firstname "Ora" ]; > dc:wrote [ dc:title "Moby Dick" ] . > > as in, can either be used to produce the same pseudo triples / graph > in NTriples. They have the same meaning when interpreted through an OWL tool, but they produce different RDF triples. To begin with the first example contains three triples and the second one contains four. They will certainly produce different output as N3. Here are various ways that the first example can be rewritten in Turtle which produce the same triples: _:a :firstname "Ora" . _:a dc:wrote _:b . _:b dc:title "Moby Dick" . _:a :firstname "Ora" ; dc:wrote _:b . _:b dc:title "Moby Dick" . _:a :firstname "Ora" ; dc:wrote [ dc:title "Moby Dick" ] . [] :firstname "Ora" ; dc:wrote [ dc:title "Moby Dick" ] . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100925220104.7d0c1dc5%40miranda.g5n.co.uk Re: Inverse of rdf:type 2010-09-25T21:01:04 2010-09-25T21:01:04 2010-09-25T21:01:04 On Sat, 25 Sep 2010 16:17:35 +0100 Nathan <nathan@webr3.org> wrote: > Simply, is there a pre defined / well known property which is the > inverse of rdf:type? No. Given that most RDF serialisations provide nice shortcuts (RDF/XML has element names, Turtle and N3 have "a", RDFa has @typeof), there's a lot of momentum for people to use rdf:type rather than an inverse. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 25 Sep 2010 16:17:35 +0100 Nathan <nathan@webr3.org> wrote: > Simply, is there a pre defined / well known property which is the > inverse of rdf:type? No. Given that most RDF serialisations provide nice shortcuts (RDF/XML has element names, Turtle and N3 have "a", RDFa has @typeof), there's a lot of momentum for people to use rdf:type rather than an inverse. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100926123113.47f419e8%40miranda.g5n.co.uk Re: Property instantiation/ predicate individuals (was Time for quintuples?) 2010-09-26T11:31:13 2010-09-26T11:31:13 2010-09-26T11:31:13 On Sun, 26 Sep 2010 11:41:53 +0200 Bob Ferris <zazi@elbklang.net> wrote: > ex:APerson ex:ASkill ex:ATopic . > > ex:ASkill a cco:skill ; > ... . # further descriptions I think, as cco:skill is currently defined anyway, that should be: ex:ASkill rdfs:subPropertyOf cco:skill . This kind of pattern is the main use case for allowing predicates to be blank nodes. (The current version of RDF does not allow this, but N3 does.) ex:APerson [ rdfs:subPropertyOf cco:skill ; ... ] ex:ATopic . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 26 Sep 2010 11:41:53 +0200 Bob Ferris <zazi@elbklang.net> wrote: > ex:APerson ex:ASkill ex:ATopic . > > ex:ASkill a cco:skill ; > ... . # further descriptions I think, as cco:skill is currently defined anyway, that should be: ex:ASkill rdfs:subPropertyOf cco:skill . This kind of pattern is the main use case for allowing predicates to be blank nodes. (The current version of RDF does not allow this, but N3 does.) ex:APerson [ rdfs:subPropertyOf cco:skill ; ... ] ex:ATopic . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20100930190805.2dcf69e3%40miranda.g5n.co.uk Re: RDFa Meeting minutes... 2010-09-30T18:08:05 2010-09-30T18:08:05 2010-09-30T18:08:05 On Thu, 30 Sep 2010 17:19:21 +0200 Ivan Herman <ivan@w3.org> wrote: > Note that we had two issue resolutions, but several people were > missing. I think that we should consider those resolutions accepted > and the issues closed unless there is an objection within 48 hours. Sorry for my lack of regular attendance recently. You can add my vote of support to both of these resolutions. As a commen... On Thu, 30 Sep 2010 17:19:21 +0200 Ivan Herman <ivan@w3.org> wrote: > Note that we had two issue resolutions, but several people were > missing. I think that we should consider those resolutions accepted > and the issues closed unless there is an objection within 48 hours. Sorry for my lack of regular attendance recently. You can add my vote of support to both of these resolutions. As a comment on ISSUE-35, there's nothing to stop someone defining an RDFa profile covering the IETF linktype registry. We (i.e. the RDFa development community) could even host such a profile on rdfa.info perhaps? Also, welcome to Nathan! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101003210625.580fb657%40miranda.g5n.co.uk Re: PROPOSAL to close ISSUE-37: is _ a special prefix? or a URI? 2010-10-03T20:06:25 2010-10-03T20:06:25 2010-10-03T20:06:25 On Sun, 03 Oct 2010 13:08:22 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > The argument of whether or not "_:abc" is a true URI or whether it > is merely a mapping to RDF's "_" mechanism was discussed as well. While we're clear that it *semantically* maps to the RDF concept of blank nodes, I do think it would be useful if we could indicate how it is treated *syntactically* - i.e. is it ... On Sun, 03 Oct 2010 13:08:22 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > The argument of whether or not "_:abc" is a true URI or whether it > is merely a mapping to RDF's "_" mechanism was discussed as well. While we're clear that it *semantically* maps to the RDF concept of blank nodes, I do think it would be useful if we could indicate how it is treated *syntactically* - i.e. is it a special CURIE prefix, or a special URI scheme? This is important as the former can be used as part of the Safe CURIE syntax (wrapped with brackets) whereas the latter must not. I think in RDFa 1.0, it was treated as a special CURIE prefix. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101003211129.5bc8c62a%40miranda.g5n.co.uk Re: PROPOSAL to close ISSUE-17: @role integration 2010-10-03T20:11:29 2010-10-03T20:11:29 2010-10-03T20:11:29 On Sun, 03 Oct 2010 13:21:27 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Please comment in 7 days from this post if you object to this > proposal. If there are no objections within 7 days, ISSUE-17 will be > closed. I think there's still an issue, but an issue at the PFWG side. Namely, that the current wording of the role attribute draft makes it seem like it's placing normative requirements on XHTML+RDFa and HTML+RDFa processors. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 03 Oct 2010 13:21:27 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Please comment in 7 days from this post if you object to this > proposal. If there are no objections within 7 days, ISSUE-17 will be > closed. I think there's still an issue, but an issue at the PFWG side. Namely, that the current wording of the role attribute draft makes it seem like it's placing normative requirements on XHTML+RDFa and HTML+RDFa processors. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1286190308.4100.41.camel%40ophelia2.g5n.co.uk Re: PROPOSAL to close ISSUE-17: @role integration 2010-10-04T11:05:10 2010-10-04T11:05:10 2010-10-04T11:05:10 On Mon, 2010-10-04 at 12:31 +0200, Ivan Herman wrote: > And I indeed object to that. The PF WG has no mandate of imposing any > MUST on an RDFa processor. I am o.k. if the MUST is exchanged against > a MAY. And it is up to the RDFa processor whether and how they do that > (e.g., by a special switch). I think the gist of the role attribute spec should be along these lines: If a markup language co... On Mon, 2010-10-04 at 12:31 +0200, Ivan Herman wrote: > And I indeed object to that. The PF WG has no mandate of imposing any > MUST on an RDFa processor. I am o.k. if the MUST is exchanged against > a MAY. And it is up to the RDFa processor whether and how they do that > (e.g., by a special switch). I think the gist of the role attribute spec should be along these lines: If a markup language contains the role attribute, then an RDFa processor processing a document written in that markup language according to the rules of that markup language (not simply according to the rules of RDFa Core) MAY generate additional triples for role attributes. If these additional triples are being generated, then this is the method that MUST be followed... i.e. an RDFa processor should not be looking at @role, but a Foo processor may generate triples for @role assuming that Foo is a markup language that incorporates @role and RDFa. For "Foo" in the preceding paragraph you may wish to substitute "XHTML 1.2" or "HTML5+RDFa". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101005170547.11453ad0%40miranda.g5n.co.uk Re: PROPOSAL to close ISSUE-39: RDFa term mapping triples 2010-10-05T16:05:47 2010-10-05T16:05:47 2010-10-05T16:05:47 On Tue, 5 Oct 2010 15:46:57 +0200 Ivan Herman <ivan@w3.org> wrote: > I did (and still do to a certain extend) have my issues, yes, so > indeed it is unfair to put the weight on solely Mark's (admittingly > wide) shoulders:-). I think Toby had similar issues, too. Indeed - I think Ivan's original way of modelling terms and prefixes is the way to go. Richards proposal is simpler, sure, but profile... On Tue, 5 Oct 2010 15:46:57 +0200 Ivan Herman <ivan@w3.org> wrote: > I did (and still do to a certain extend) have my issues, yes, so > indeed it is unfair to put the weight on solely Mark's (admittingly > wide) shoulders:-). I think Toby had similar issues, too. Indeed - I think Ivan's original way of modelling terms and prefixes is the way to go. Richards proposal is simpler, sure, but profiles are a WORM format (write once, read many -- in this case, use many). I was prepared to go with Richard's proposal in the interests of consensus when it looked like consensus was heading in that direction, but I do feel that Ivan's existing vocab is the way to go. In fact, I'd like to add a couple of extra terms to it: rdfa:ProfileDocument (a subclass of foaf:Document) and rdfa:defines. So that the profile graph looks like: <http://example.com/rdfa-profile> a rdfa:ProfileDocument ; rdfa:defines [ a rdfa:TermMapping ; rdfa:term "title"^^xsd:string ; rdfa:uri "http://purl.org/dc/terms/title"^^xsd:anyURI ] ; rdfa:defines [ a rdfa:PrefixMapping ; rdfa:prefix "foaf"^^xsd:string ; rdfa:uri "http://xmlns.com/foaf/0.1/"^^xsd:anyURI ] . Though the rdfa:defines, rdfa:ProfileDocument stuff would not affect how terms and prefixes are extracted from a profile, so would be effectively optional stuff, just added by people who want their profiles to have added semantic goodness. Also, I think ideally the range of rdfa:uri should be xsd:string, not xsd:anyURI. This is because CURIE prefix expansions could theoretically be too truncated to be legal URIs until the suffix is added. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101005204722.5f42c068%40miranda.g5n.co.uk Re: PROPOSAL to close ISSUE-39: RDFa term mapping triples 2010-10-05T19:47:22 2010-10-05T19:47:22 2010-10-05T19:47:22 On Tue, 5 Oct 2010 17:26:44 +0100 Richard Cyganiak <richard.cyganiak@deri.org> wrote: > Can you point me to the place where you raised your concerns? On the 2010-09-09 telecon, though it wasn't minuted much as I was scribing and find it hard to scribe while talking. Some of my concerns are outlined in <http://www.w3.org/mid/bd11e07b6857681b4c1d25e21df964b0.squirrel@goddamn.co.uk>. It mostly dis... On Tue, 5 Oct 2010 17:26:44 +0100 Richard Cyganiak <richard.cyganiak@deri.org> wrote: > Can you point me to the place where you raised your concerns? On the 2010-09-09 telecon, though it wasn't minuted much as I was scribing and find it hard to scribe while talking. Some of my concerns are outlined in <http://www.w3.org/mid/bd11e07b6857681b4c1d25e21df964b0.squirrel@goddamn.co.uk>. It mostly discusses prefix mapping, though many of the same concerns apply to term mapping, albeit to a lesser degree. Even if those concerns didn't apply to terms at all, I still think there is value in keeping term mappings as-is for consistency with prefix mappings. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101005210625.0ca1a956%40miranda.g5n.co.uk Re: RDFa API comments from TimBL 2010-10-05T20:06:25 2010-10-05T20:06:25 2010-10-05T20:06:25 On Tue, 05 Oct 2010 17:30:24 +0100 Nathan <nathan@webr3.org> wrote: > so let's say we put all this in a property .graph, then you could do: > var nathan = store.graph[":nathan"]; > and `nathan` would contain an object with all the properties as > properties, and each value as an array of objects. > > likewise if you did store.graph[":nathan"]["foaf:knows"] you'd get an > array of ["manu", "... On Tue, 05 Oct 2010 17:30:24 +0100 Nathan <nathan@webr3.org> wrote: > so let's say we put all this in a property .graph, then you could do: > var nathan = store.graph[":nathan"]; > and `nathan` would contain an object with all the properties as > properties, and each value as an array of objects. > > likewise if you did store.graph[":nathan"]["foaf:knows"] you'd get an > array of ["manu", "ivan", "mark"] back - this should work in other > languages too, certainly does in PHP and the likes. getItemBySubject and the PropertyGroup interface is intended to be conceptually similar: var nathan = document.getItemBySubject("#nathan"); var nathans_friends = nathan.get("foaf:knows"); for (var i in nathans_friends) { window.alert(nathans_friends[i]); } -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101005232652.5c198224%40miranda.g5n.co.uk Re: RDFa API comments from TimBL 2010-10-05T22:26:52 2010-10-05T22:26:52 2010-10-05T22:26:52 On Tue, 05 Oct 2010 21:08:54 +0100 Nathan <nathan@webr3.org> wrote: > indeed! don't have document.anything* on the server side or in other > languages though.. Why not? check.rdfa.info uses an XML DOM all over the place at the server end, in Perl. Plenty of $document->getElementsById('#foo') sort of stuff going on. The RDFa API is mostly aimed at Javascript, and mostly in a browser environment... On Tue, 05 Oct 2010 21:08:54 +0100 Nathan <nathan@webr3.org> wrote: > indeed! don't have document.anything* on the server side or in other > languages though.. Why not? check.rdfa.info uses an XML DOM all over the place at the server end, in Perl. Plenty of $document->getElementsById('#foo') sort of stuff going on. The RDFa API is mostly aimed at Javascript, and mostly in a browser environment. If you're implementing it in another environment there is always going to be the possibility that some things that need some slight adjustments. Whenever an API is defined for multiple languages, implementations of that API are probably going to have to make some compromises in order to actually work in their target language, and to behave in the way that their users expect. For example, in XML::LibXML, a popular Perl DOM implementation (though it's just a wrapper around a C library) some DOM methods which are supposed to return NodeList objects can be called in such a way that they'll return native Perl arrays - just because Perl developers are more likely to be comfortable with them. Looking at an example from the RDFa API, store.forEach is essentially passed a function as its argument. In some languages, like Java or PHP, functions aren't first-class objects; they can't be passed as arguments. A PHP implementation of the RDFa API would instead probably be passed the name of a callback function as a string; a Java one would use whatever convoluted workaround is currently popular in that world, probably involving a dummy class with just a single method. If, in your language/environment, document.getItemBySubject is unworkable or would be an unexpected way of doing things, then do it differently, but note the difference in your documentation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1286377683.7066.12.camel%40ophelia2.g5n.co.uk RDFa Core, section 4.2 2010-10-06T15:08:04 2010-10-06T15:08:04 2010-10-06T15:08:04 Something smells wrong here: > If the Host Language uses XML Namespaces [XML-NAMES], the attributes > in this specification should be incorporated in the namespace of the > Host Language. No existing host language does this. XHTML+RDFa, HTML5+RDFa, SVG and Yahoo's DataRSS all use unnamespaced attributes for RDFa. OpenDocument 1.2 is a bit of an exception, as it places the RDFa attributes in the <http://www.w3.org/1999/xhtml> namespace, which not even XHTML does. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Something smells wrong here: > If the Host Language uses XML Namespaces [XML-NAMES], the attributes > in this specification should be incorporated in the namespace of the > Host Language. No existing host language does this. XHTML+RDFa, HTML5+RDFa, SVG and Yahoo's DataRSS all use unnamespaced attributes for RDFa. OpenDocument 1.2 is a bit of an exception, as it places the RDFa attributes in the <http://www.w3.org/1999/xhtml> namespace, which not even XHTML does. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101008111455.77babe4c%40miranda.g5n.co.uk Re: ISSUE-46 (conversion of plain literals to IRIs): Should plain literals that match fully qualified IRIs be automatically converted to IRIs [RDFa 1.1 Core] 2010-10-08T10:14:55 2010-10-08T10:14:55 2010-10-08T10:14:55 On Thu, 7 Oct 2010 11:52:48 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > My understanding of the use-case described was not 'hey > everyone...let's just make literals and URIs the same', but rather the > motivation was that authors wanting to use something like OGP might > accidently use @property/@content instead of @rel/@resource/@href. Authors using: <meta property="og:url" c... On Thu, 7 Oct 2010 11:52:48 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > My understanding of the use-case described was not 'hey > everyone...let's just make literals and URIs the same', but rather the > motivation was that authors wanting to use something like OGP might > accidently use @property/@content instead of @rel/@resource/@href. Authors using: <meta property="og:url" content="http://example.com/" /> Are not doing so accidentally but intentionally. This is the correct use of the OGP vocab. OGP is certainly not the only place where URIs may appear as literals deliberately. See, for instance: <http://purl.org/NET/uri> <http://open.vocab.org/docs/canonicalUri> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101008161915.6a050a84%40miranda.g5n.co.uk Final Report comments 2010-10-08T15:19:15 2010-10-08T15:19:15 2010-10-08T15:19:15 XRD === References LRDD for discovery. LRDD, as a standalone spec, is defunct. It's been subsumed by the host-meta draft spec as of revision 10. http://tools.ietf.org/html/draft-hammer-hostmeta-13#appendix-B PortableContacts ================ States that it's a superset of vCard. While it's certainly derived from vCard, it's not a superset. Many of the property names are changed (e.g. ADR -> a... XRD === References LRDD for discovery. LRDD, as a standalone spec, is defunct. It's been subsumed by the host-meta draft spec as of revision 10. http://tools.ietf.org/html/draft-hammer-hostmeta-13#appendix-B PortableContacts ================ States that it's a superset of vCard. While it's certainly derived from vCard, it's not a superset. Many of the property names are changed (e.g. ADR -> addresses) and many are removed (LOGO, ROLE, TITLE, etc). It's also syntactically entirely different. vCard is serialised using text/directory (the same as iCalendar); PortableContacts is serialised as XML or, more usually, JSON. Microformats ============ > common properties of HTML such as "rel", "class", and "span" huh? How about: established HTML attributes such as 'rel', 'class' and 'rev'. > 94 percent of Google Rich Snippets data indexed by Google Rich > Snippets is based on microformats rather than RDFa or microdata. This is a somewhat misleading statistic and may need clarifying. Doesn't compare Microformats against RDFa and Microdata; it compares microformats against the use of Google's own vocabulary in RDFa and Microformats. i.e. commonly used vocabs such as FOAF, SIOC, vCard, iCalendar, Dublin Core are not included. Open Graph Protocol =================== > The Facebook Open Graph Protocol allows any web site to a "Like" > button to an item in the page by adding only a small amount of > simplified RDFa to the header of a web-site No, it doesn't. The open graph protocol is a metadata vocabulary for describing documents and (indirectly) their topics, not that dissimilar from Dublin Core. It is typically serialised in RDFa in <meta> elements in HTML pages. The Facebook "like" button is a separate thing, added via Javascript. It is an application that *uses* the open graph protocol. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101010021143.54b0b056%40miranda.g5n.co.uk Re: prefix case-insensitivity 2010-10-10T01:11:43 2010-10-10T01:11:43 2010-10-10T01:11:43 On Sat, 09 Oct 2010 17:35:39 +0100 Nathan <nathan@webr3.org> wrote: > PS: this is my understanding, that it is case insensitive - and Shane > indicated the same to me, just wanted to 100% clarify so I can cater > for it in the RDFa API and ensure this is stated in RDFa Core (if not > already). Do we have somewhere we note backcompat issues? This is different between RDFa 1.0 and 1.1. Not likely to catch many people out, but we should note it in an appendix or something. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 09 Oct 2010 17:35:39 +0100 Nathan <nathan@webr3.org> wrote: > PS: this is my understanding, that it is case insensitive - and Shane > indicated the same to me, just wanted to 100% clarify so I can cater > for it in the RDFa API and ensure this is stated in RDFa Core (if not > already). Do we have somewhere we note backcompat issues? This is different between RDFa 1.0 and 1.1. Not likely to catch many people out, but we should note it in an appendix or something. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101010110653.14085e7a%40miranda.g5n.co.uk Re: RDFa API - adding Namespace 2010-10-10T10:06:53 2010-10-10T10:06:53 2010-10-10T10:06:53 On Sat, 09 Oct 2010 18:44:16 +0100 Nathan <nathan@webr3.org> wrote: > foaf('name'); This is probably something that doesn't need to be done as part of the API itself. Individual scripters or library/toolkit authors can very easily implement something like that on top of the API. function prefixMapper (p) { return function (s) { return p+s; }; } var foaf = prefixMapper('http://xmlns.com/f... On Sat, 09 Oct 2010 18:44:16 +0100 Nathan <nathan@webr3.org> wrote: > foaf('name'); This is probably something that doesn't need to be done as part of the API itself. Individual scripters or library/toolkit authors can very easily implement something like that on top of the API. function prefixMapper (p) { return function (s) { return p+s; }; } var foaf = prefixMapper('http://xmlns.com/foaf/0.1/'); var dc = prefixMapper('http://purl.org/dc/terms/'); window.alert(foaf('name')); window.alert(dc('title')); -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101010163218.45a927fd%40miranda.g5n.co.uk Re: HTML5 Polyglot spec and RDFa 2010-10-10T15:32:18 2010-10-10T15:32:18 2010-10-10T15:32:18 On Sun, 10 Oct 2010 10:15:07 +0200 Ivan Herman <ivan@w3.org> wrote: > I am still not 100% sure that the issue raised by Gregg is, in > practice, such a show stopper that it would warrant to change the > current (clearly simplistic) solution. As far as I'm concerned there are four possible paths that we could go down which are all quite sensible. (And probably dozens of silly paths we could take.... On Sun, 10 Oct 2010 10:15:07 +0200 Ivan Herman <ivan@w3.org> wrote: > I am still not 100% sure that the issue raised by Gregg is, in > practice, such a show stopper that it would warrant to change the > current (clearly simplistic) solution. As far as I'm concerned there are four possible paths that we could go down which are all quite sensible. (And probably dozens of silly paths we could take.) #1. How RDFa Core 1.1 is currently specified: all terms are case-insensitive. #2. All terms are case-sensitive. #3. Terms are case-sensitive generally, but a host language's default profile MAY be case-insensitive if the host language's specification states that it is (and XHTML+RDFa 1.1 would). #4. Profiles may indicate which terms are case-sensitive and which are not. Currently I've implemented #3 in my parser, though will obviously switch to whatever the WG has resolved as RDFa 1.1 approaches stability. #3 or #4 are my preferred solutions, because they seem to offer profile designers a bit of control while taking into account grandfathered case-insensitive terms. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101012003943.3f6134c3%40miranda.g5n.co.uk Re: RDFa API - adding Namespace 2010-10-11T23:39:43 2010-10-11T23:39:43 2010-10-11T23:39:43 On Mon, 11 Oct 2010 09:19:43 +0100 Nathan <nathan@webr3.org> wrote: > perhaps if we ask "why not add it?", is there a good reason not to? Antoine de Saint Exupery (author of one of my favourite books) wrote: Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. Which is usually translated into English as: Perfection is... On Mon, 11 Oct 2010 09:19:43 +0100 Nathan <nathan@webr3.org> wrote: > perhaps if we ask "why not add it?", is there a good reason not to? Antoine de Saint Exupery (author of one of my favourite books) wrote: Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. Which is usually translated into English as: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. While perfection is certainly too ambitious a target, I do think we should be guided by the principle of less-is-more. A smaller API spec is going to be easier to implement, resulting in a greater number of implementations, and hopefully fewer places for bugs to hide. The API spec needs to tread a careful path between minimal and useful. There are some things that clearly need to be in it, but when something seems optional we need to ask what percentage of users are actually going to use it, and might they be better served by layering a library on top of the API to provide syntactic sugar and shortcuts? Bear in mind that this: function NS(p){return function(s){return p+s}} is less than 50 characters. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1286982547.24218.92.camel%40ophelia2.g5n.co.uk Re: [ANN] JSON Datsets / any HTML to RDF 2010-10-13T15:09:11 2010-10-13T15:09:11 2010-10-13T15:09:11 On Wed, 2010-10-13 at 12:15 +0100, Martin McEvoy wrote: > I am pleased to announce JSON Datasets[1] a way to extract RDF from > any HTML document using JSON. Hi Martin, I seem to remember reading some of your early work on this concept some months ago. Can't remember how I stumbled upon it. Anyhow, it's an interesting idea. It seems to be that it's quite GRDDL-like, in that an HTML file can li... On Wed, 2010-10-13 at 12:15 +0100, Martin McEvoy wrote: > I am pleased to announce JSON Datasets[1] a way to extract RDF from > any HTML document using JSON. Hi Martin, I seem to remember reading some of your early work on this concept some months ago. Can't remember how I stumbled upon it. Anyhow, it's an interesting idea. It seems to be that it's quite GRDDL-like, in that an HTML file can link to a file that contains a set of rules which, once applied to the original file, produce RDF as output. I know that you're quite the XSLT transformation guru, and are probably quite familiar with GRDDL. Are you also aware that GRDDL allows transformations to be written using languages other than XSLT? Your JSON-based language seems like it would make a good transformation language for GRDDL. Essentially all that would need to be done to make JSON Datasets conformant to GRDDL would be to replace this method of linking: <link rel="dataset" href="http://example.com/my-dataset.json" type="application/json"> With the GRDDL methods of linking to a transformation. There are two such methods that are relevant to HTML (there are another two which are XML-based) - firstly a direct link from the document to the JSON file: <link rel="transformation" href="http://example.com/my-dataset.json" type="application/json"> And secondly, an indirect link from the document to a profile document <head profile="http://example.com/profile"> Where the profile document contains a link to the JSON: <link rel="profileTransformation" href="http://example.com/my-dataset.json" type="application/json"> If those were used by JSON datasets instead of rel="dataset" then you might find that your apprach receives wider support. For example, my Perl implementation of GRDDL supports pluggable transformation languages; adding support for your JSON-based format would not be especially tough. Adding support for rel="dataset" though, I would consider to be out of scope for the project. Some critiques of the JSON format itself: The use of the term "where" is a little confusing. The terminology of the query syntax seems to borrow from SQL and SPARQL, but the behaviour of "where" seems totally different. In SQL and SPARQL, "where" is essentially used to perform joins, and to narrow down criteria. In your language it seems to be a mapping from one structure (a graph) to another (RDF triples) - that seems to be more similar to SQL's "SELECT foo AS bar". Perhaps this: { "select": { "from": "http://example.com/", "prefix": { "dc": "http://purl.org/dc/elements/1.1/" }, "where": { "title": { "label": "dc:title" } } } } Might be better expressed as: { "prefix": { "dc": "http://purl.org/dc/elements/1.1/" }, "select": { "title": { "label": "dc:title" } }, "from": "http://example.com/" } And actually, "label" might be better is called "as": { "prefix": { "dc": "http://purl.org/dc/elements/1.1/" }, "select": { "title": { "as": "dc:title" } }, "from": "http://example.com/" } Are prefixes required, or just a shortcut? Could the above be written as the following? { "select": { "title": { "as": "http://purl.org/dc/elements/1.1/title" } }, "from": "http://example.com/" } It's not clear whether selectors may be combined. "h1", ".example" and "#heading" are all valid selectors, but what about "h1.example" and "#heading h1.example". If you're going to use a subset of CSS, you need to be awfully clear about what subset you're specifying, otherwise people coming to your spec, knowing CSS already, are going to say, "well, it's like CSS, so I must be able to do foo." You might consider switching to, or at least allowing XPath for selectors. It's mighty powerful, and should be able to handle useful idioms like class=fn which is inside class=vcard, but not inside a nested class=vcard. Lastly in your spec, you use a lot of XML terminology when describing the output. Personally I found that quite confusing. You might want to consider explaining how the output is constructed in terms of the abstract triples, or if you want to describe it in more concrete terms, in terms of N-Triples. I think if you did that, it might even help clarify the format in your own mind and further improve it - for example, you may not have noticed, but because you've defined the "label" property in XML terms, you've ended up with a property which sometimes ends up setting an RDF property, and at other times an RDF class, as in the case of <http://weborganics.co.uk/dataset/#query-rev> where it's used to set a class of "Person". How it sometimes sets one and sometimes sets the other seems to happen via magic (perhaps using the same rule as RDF/XML where the same also happens, and is similarly confusing). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1286985552.24218.117.camel%40ophelia2.g5n.co.uk Re: Are literals owl:Things? 2010-10-13T15:59:15 2010-10-13T15:59:15 2010-10-13T15:59:15 On Sun, 2010-10-10 at 23:59 +0200, Antoine Zimmermann wrote: > So the conclusion is that literals are not owl:Thing under the direct > (Description-Logics-based) semantics but are owl:Thing under the > RDF-based semantics. This might look like a significant problem but in > practical case it seems that it does not affect much the > interoperability of DL and non-DL tools, as far as I can tell. ... On Sun, 2010-10-10 at 23:59 +0200, Antoine Zimmermann wrote: > So the conclusion is that literals are not owl:Thing under the direct > (Description-Logics-based) semantics but are owl:Thing under the > RDF-based semantics. This might look like a significant problem but in > practical case it seems that it does not affect much the > interoperability of DL and non-DL tools, as far as I can tell. I don't like statements like that. It's like light being sometimes a wave, and sometimes a particle: I don't accept that. I'm happy enough to say that light exhibits properties of each, and depending on what you're doing and how you're modelling things, it might be useful to ignore light's particle nature or its wave nature. But that doesn't effect what light *is*. Likewise, I'm happy to accept a statement like: literals are owl:Things, but a DL-based reasoner will never come to the conclusion that they are. Is that not a more reasonable description of the way things are in OWL? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101013221307.409aa425%40miranda.g5n.co.uk Re: Correct Usage of rdfs:idDefinedBy in Vocabulary Specifications with a Hash-based URI Pattern 2010-10-13T21:13:07 2010-10-13T21:13:07 2010-10-13T21:13:07 On Thu, 30 Sep 2010 09:06:46 +0200 Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote: > 1. http://purl.org/vso/ns# for the ontology as an abstract artefact > 2. http://purl.org/vso/ns for the syntactical representation of the > ontology (its serialization) > > Shall the rdfs:isDefinedBy statements refer to #1 or #2 ? I tend to use the <#> URI as the URI for the Ontology, and the object of r... On Thu, 30 Sep 2010 09:06:46 +0200 Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote: > 1. http://purl.org/vso/ns# for the ontology as an abstract artefact > 2. http://purl.org/vso/ns for the syntactical representation of the > ontology (its serialization) > > Shall the rdfs:isDefinedBy statements refer to #1 or #2 ? I tend to use the <#> URI as the URI for the Ontology, and the object of rdfs:isDefinedBy triples. This is at least partly because I tend to write vocabs in N3, which makes this easy. @prefix my: <http://example.com/my#> . my: a owl:Ontology ; rdfs:label "My Ontology"@en . my:Term a owl:Class ; rdfs:isDefinedBy my: . Whereas I couldn't reuse the prefix if I were leaving off the hash of the rdfs:isDefinedBy object URI. (Though I suppose <> would still be usable as a shortcut.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101013222934.1cabcbfc%40miranda.g5n.co.uk Re: Reification alternative 2010-10-13T21:29:34 2010-10-13T21:29:34 2010-10-13T21:29:34 On Wed, 13 Oct 2010 15:02:01 +0200 Mirko <idonthaveenoughinformation@googlemail.com> wrote: > I try to understand alternatives to reification for Linked Data > publishing, since reification is discouraged. For completeness, as it's not been mentioned, one method would be to publish two files. This is semantically similar to the use of named graphs, but allows you to stay within the RDF data mode... On Wed, 13 Oct 2010 15:02:01 +0200 Mirko <idonthaveenoughinformation@googlemail.com> wrote: > I try to understand alternatives to reification for Linked Data > publishing, since reification is discouraged. For completeness, as it's not been mentioned, one method would be to publish two files. This is semantically similar to the use of named graphs, but allows you to stay within the RDF data model, and thus use purely RDF tools and serialisations. #### data.ttl #### @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix : <http://example.org/> . :User foaf:interest :Item . #### meta.ttl #### @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix : <http://example.org/> . <data.ttl> rdfs:label "Statement that describes user interest in a document"@en; dc:publisher :Service; dc:created "2010-10-13"^^xsd:date; dc:license :License . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101015210515.4f9a2fea%40miranda.g5n.co.uk Re: Are literals owl:Things? 2010-10-15T20:05:15 2010-10-15T20:05:15 2010-10-15T20:05:15 On Fri, 15 Oct 2010 09:38:24 -0700 Jeremy Carroll <jeremy@topquadrant.com> wrote: > I would actually say " I think you mean > > _:x owl:sameAs "42"^^xsd:integer . > _:x rdf:type xsd:decimal . > " Another way to express: "42"^^xsd:integer rdf:type xsd:decimal . without needing to go as far as OWL might be: :x rdfs:range xsd:decimal ; :x "42"^^xsd:integer . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 15 Oct 2010 09:38:24 -0700 Jeremy Carroll <jeremy@topquadrant.com> wrote: > I would actually say " I think you mean > > _:x owl:sameAs "42"^^xsd:integer . > _:x rdf:type xsd:decimal . > " Another way to express: "42"^^xsd:integer rdf:type xsd:decimal . without needing to go as far as OWL might be: :x rdfs:range xsd:decimal ; :x "42"^^xsd:integer . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101019153528.6a6ab145%40miranda.g5n.co.uk Re: PROPOSAL to close ISSUE-16: RDF Collections 2010-10-19T14:35:28 2010-10-19T14:35:28 2010-10-19T14:35:28 On Tue, 19 Oct 2010 06:49:54 -0200 Ivan Herman <ivan@w3.org> wrote: > I do not agree with the argument that this is RDF Next WG's work (and > I do not think it will be part of the charter). Collections is well > specified in RDF and there is no reason to come back to them right > now. FWIW, I'd welcome an easy way to represent rdf:List structures in RDFa. Shortcuts for rdf:{Bag,Seq,Alt} I'm no... On Tue, 19 Oct 2010 06:49:54 -0200 Ivan Herman <ivan@w3.org> wrote: > I do not agree with the argument that this is RDF Next WG's work (and > I do not think it will be part of the charter). Collections is well > specified in RDF and there is no reason to come back to them right > now. FWIW, I'd welcome an easy way to represent rdf:List structures in RDFa. Shortcuts for rdf:{Bag,Seq,Alt} I'm not so concerned about - they're not especially difficult to represent anyway. I do have some concerns with Ivan's proposed method as it involves modifying the DOM during a preprocessing step. But if someone could find a way to implement it as part of the current one-pass parse, then I'd be in favour. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101019205108.55cbd78d%40miranda.g5n.co.uk Re: Updated RDFa Core Editor's Draft 2010-10-19T19:51:08 2010-10-19T19:51:08 2010-10-19T19:51:08 On Mon, 18 Oct 2010 22:19:06 -0500 Shane McCarron <shane@aptest.com> wrote: > Sorry for the confusion earlier. There is an updated editor's > draft at > http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-core-20101018/ 2.2: the profile example is wrong dc/dcterms. 3.3-3.6, 7.3, 8.1-8.2: the URIs for Albert Einstein, the German Empire, the United States, etc should not start with <http://dbpe... On Mon, 18 Oct 2010 22:19:06 -0500 Shane McCarron <shane@aptest.com> wrote: > Sorry for the confusion earlier. There is an updated editor's > draft at > http://www.w3.org/2010/02/rdfa/drafts/2010/ED-rdfa-core-20101018/ 2.2: the profile example is wrong dc/dcterms. 3.3-3.6, 7.3, 8.1-8.2: the URIs for Albert Einstein, the German Empire, the United States, etc should not start with <http://dbpedia.org/page/> but <http://dbpedia.org/resource/>. 3.10: mentions @src in the same breath as @resource and @href, whereas @src actually behaves more like @about. 6: "An RDFa Processor must not use the XML 'default namespace' as the 'default prefix'." -- perhaps needs rephrasing, as is suggests that something like this is illegal: <g xmlns="http://example.com/" vocab="http://example.com/"> 8: Most of these examples are missing prefix mappings. For little snippets which don't purport to be full documents, that's fine. For the longer ones which include entire <html> elements, at least an @profile should be there. 8.3.1.3: A lot of problems here. "It does not help to escape the content, since the output would simply be a string of text containing numerous ampersands" is simply nonsense. The following: <html property=":foo" content="&lt;bar&gt;" /> is parsed as: <> :foo "<bar>" . The phrase "To make authoring easier, if there are child elements and no @datatype attribute, then the effect is the same as if @datatype have been explicitly set to rdf:XMLLiteral" is no longer true. That phrase and the following couple of examples with their explanations need removing/revising. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101019213853.7633d57c%40miranda.g5n.co.uk Re: Re 2: PROPOSAL to close ISSUE-37: Clarifying bnode explanation 2010-10-19T20:38:53 2010-10-19T20:38:53 2010-10-19T20:38:53 How about: """ After processing, the following triples will be generated: _:john foaf:mbox <mailto:john@example.org> . _:sue foaf:mbox <mailto:sue@example.org> . _:john foaf:knows _:sue . The blank node identifiers ("_:john" and "_:sue") are arbitrary and implementations are not required to maintain the same identifiers as occur in the RDFa markup. The above data could have equivalently b... How about: """ After processing, the following triples will be generated: _:john foaf:mbox <mailto:john@example.org> . _:sue foaf:mbox <mailto:sue@example.org> . _:john foaf:knows _:sue . The blank node identifiers ("_:john" and "_:sue") are arbitrary and implementations are not required to maintain the same identifiers as occur in the RDFa markup. The above data could have equivalently been represented as: _:a foaf:mbox <mailto:john@example.org> . _:b foaf:mbox <mailto:sue@example.org> . _:a foaf:knows _:b . For clarity, this document retains blank node identifiers in examples, but developers must not rely on RDFa implementations returning identifiers that are consistent with the RDFa markup. """ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101019215115.3ccb5959%40miranda.g5n.co.uk Re: Need volunteer reviewers for RDFa Core 1.1 (pre-Last Call) 2010-10-19T20:51:15 2010-10-19T20:51:15 2010-10-19T20:51:15 On Tue, 12 Oct 2010 01:53:56 +0200 Christoph LANGE <ch.lange@jacobs-university.de> wrote: > The latter (i.e. putting attributes into the empty namespace) is > what, according to Toby, all currently existing host languages do. No, it's not what all existing host languages do. Somewhat annoyingly, OpenDocument Format 1.2 puts the RDFa attributes in the {http://www.w3.org/1999/xhtml} namespace. >... On Tue, 12 Oct 2010 01:53:56 +0200 Christoph LANGE <ch.lange@jacobs-university.de> wrote: > The latter (i.e. putting attributes into the empty namespace) is > what, according to Toby, all currently existing host languages do. No, it's not what all existing host languages do. Somewhat annoyingly, OpenDocument Format 1.2 puts the RDFa attributes in the {http://www.w3.org/1999/xhtml} namespace. > However, I would strongly advise providing for the alternative > possibility to put RDFa attributes into some non-empty namespace, > possibly xmlns:rdfa="http://www.w3.org/ns/rdfa#". Yep - I'd agree with that. I'd suggest that host languages *SHOULD* keep them in the empty namespace, but it makes sense to provide a namespace they can use if need be. However, host languages must pick one and stick with it. Putting @href in one namespace, @prefix in another and @about in the empty namespace would be horrible! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101019222924.3142a230%40miranda.g5n.co.uk Re: Need volunteer reviewers for RDFa Core 1.1 (pre-Last Call) 2010-10-19T21:29:24 2010-10-19T21:29:24 2010-10-19T21:29:24 On Mon, 18 Oct 2010 16:02:25 -0500 Shane McCarron <shane@aptest.com> wrote: > The rdfa attributes are currently defined in the XHTML namespace - > and I think it is adequate that they stay there. Since this clause > is a SHOULD, a host language MAY also use the attributes in their > XHTML namespace. However, I would note that no processor today knows > how to deal with that. Mine's been able t... On Mon, 18 Oct 2010 16:02:25 -0500 Shane McCarron <shane@aptest.com> wrote: > The rdfa attributes are currently defined in the XHTML namespace - > and I think it is adequate that they stay there. Since this clause > is a SHOULD, a host language MAY also use the attributes in their > XHTML namespace. However, I would note that no processor today knows > how to deal with that. Mine's been able to since June. It can be configured with a namespace in which to look for RDFa attributes instead of (not as well as!) the default "no namespace" namespace. ############################################################ use RDF::RDFa::Parser; use RDF::TrineShortcuts qw[rdf_string]; my $config = RDF::RDFa::Parser::Config ->new('xml', '1.1', ns => 'urn:x-namespace:rdfa'); my $parser = RDF::RDFa::Parser ->new(<<'MARKUP', 'http://example.com/base', $config); <foo xmlns:blah="urn:x-namespace:rdfa" xmlns:x="http://example.com/ns#" blah:about="[x:s]" blah:rel="x:p" blah:resource="[x:o]" /> MARKUP print rdf_string($parser->graph, 'N-Triples'); ############################################################ Outputs one triple: <http://example.com/ns#s> <http://example.com/ns#p> <http://example.com/ns#o> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101019234854.43e17520%40miranda.g5n.co.uk Re: Need volunteer reviewers for RDFa Core 1.1 (pre-Last Call) 2010-10-19T22:48:54 2010-10-19T22:48:54 2010-10-19T22:48:54 On Wed, 20 Oct 2010 00:08:00 +0200 Christoph LANGE <ch.lange@jacobs-university.de> wrote: > … indeed you had said that before. As you say "annoying", am I right > to assume that OpenDocument could afford putting the RDFa attributes > into the empty namespace? I.e. that there are no conflicts with > other attributes having the same name. I'm no expert on OpenDocument, but I don't think there wo... On Wed, 20 Oct 2010 00:08:00 +0200 Christoph LANGE <ch.lange@jacobs-university.de> wrote: > … indeed you had said that before. As you say "annoying", am I right > to assume that OpenDocument could afford putting the RDFa attributes > into the empty namespace? I.e. that there are no conflicts with > other attributes having the same name. I'm no expert on OpenDocument, but I don't think there would be any problems. From what I can tell, all OpenDocument's attributes are namespaced, so adding RDFa attributes in no namespace shouldn't cause any conflicts. I imagine they put the attributes in the XHTML namespace to maintain the all-OpenDocument's-attributes-are-namespaced situation. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101020135216.06310a4e%40miranda.g5n.co.uk Re: Re 2: PROPOSAL to close ISSUE-37: Clarifying bnode explanation 2010-10-20T12:52:16 2010-10-20T12:52:16 2010-10-20T12:52:16 On Wed, 20 Oct 2010 09:35:22 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > The bnode identifiers need to be the same *on the way in*. Your > example is fine when it comes to querying the triples *on the way > out*, but that isn't what the examples are trying to show. I don't understand this whole "way in"/"way out" distinction. It assumes a workflow of a parser putting the triples ... On Wed, 20 Oct 2010 09:35:22 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > The bnode identifiers need to be the same *on the way in*. Your > example is fine when it comes to querying the triples *on the way > out*, but that isn't what the examples are trying to show. I don't understand this whole "way in"/"way out" distinction. It assumes a workflow of a parser putting the triples into a store, and then the triples being retrieved from the store by some process. There may not be a store at all. Consider this example using my parser which simply prints triples to STDOUT in N-Triples format as they occur. No stores. ############################################################ use RDF::RDFa::Parser; my $xml = <<'XML'; <p> <span about="[_:foo]" rev="next Index CONTENTS" resource="[_:bar]"></span> </p> XML # new($markup, $baseuri, Config->new($hostlang, $rdfaversion)) my $p = RDF::RDFa::Parser->new($xml, "http://example.com/", RDF::RDFa::Parser::Config->new('html4', '1.1')); $p->set_callbacks({ pretriple_resource => 'print', pretriple_literal => 'print', }); $p->consume; 1; ############################################################ Blank node identifiers will be random-looking ones not bearing any relationship to the strings "foo" and "bar" (they're generated using UUID numbers). These random-looking blank node identifiers are generated at the time of processing @about and @resource for CURIEs - before they're combined with the predicates to form triples - so at no point (not even a transitional stage in memory) does a triple exist which has blank node identifier "_:foo" or "_:bar". As far as I'm concerned, that's a conformant implementation. But there is no "way in" stage that has access to the triples in the state you describe - the triples simply never exist in that state. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101023152932.38d7e4a0%40miranda.g5n.co.uk Re: RDFa WG telecon minutes for 2010-10-21 2010-10-23T14:29:32 2010-10-23T14:29:32 2010-10-23T14:29:32 On Sat, 23 Oct 2010 15:22:37 +0100 Nathan <nathan@webr3.org> wrote: > In reality though, whilst that door is left open, the only MUST is > RDFa so interoperability is guaranteed, and for the time being the > only alternative is other RDF Serializations (which technically is > only RDF/XML since it's the only one which is IANA registered.. > debatable but true-ish). Just to horrify you: PDF is IANA registered and can contain embedded RDF data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sat, 23 Oct 2010 15:22:37 +0100 Nathan <nathan@webr3.org> wrote: > In reality though, whilst that door is left open, the only MUST is > RDFa so interoperability is guaranteed, and for the time being the > only alternative is other RDF Serializations (which technically is > only RDF/XML since it's the only one which is IANA registered.. > debatable but true-ish). Just to horrify you: PDF is IANA registered and can contain embedded RDF data. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101024133438.38e82905%40miranda.g5n.co.uk Some RDFa 1.1 Core edge cases that we need to clarify 2010-10-24T12:34:38 2010-10-24T12:34:38 2010-10-24T12:34:38 EXAMPLE 1: <html vocab="http://example.com/1#"> <head> <base href="http://example.com/base" /> </head> <body vocab="2#"> <h1 property="title">Hello World</h1> </body> </html> What is the triple here? @vocab is supposed to be an absolute URI, but here on <body> it's relative. So, should parsers error-correct and thus create a triple with predicate <http://example.com/2#title>; sho... EXAMPLE 1: <html vocab="http://example.com/1#"> <head> <base href="http://example.com/base" /> </head> <body vocab="2#"> <h1 property="title">Hello World</h1> </body> </html> What is the triple here? @vocab is supposed to be an absolute URI, but here on <body> it's relative. So, should parsers error-correct and thus create a triple with predicate <http://example.com/2#title>; should they ignore that vocab attribute, and generate a triple with predicate <http://example.com/1#title>; or should the invalid vocab value reset the default vocabulary to undefined, meaning that the token "title" can't be expanded to anything, thus no triple is generated? EXAMPLE 2: A profile defines: [] rdfa:term "Agent" ; rdfa:uri foaf:Agent . [] rdfa:term "agent" ; rdfa:uri event:agent . [] rdfa:term "name" ; rdfa:uri foaf:name . That's fine, and this should work: <div about="#myevent" rel="agent"> <span typeof="Agent" property="name">Toby Inkster</span> </div> But what happens here? It doesn't seem to be well-defined. <div about="#myevent" rel="AGENT"> <span typeof="AGENT" property="NAME">Toby Inkster</span> </div> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101025115520.71e289c2%40miranda.g5n.co.uk Re: Some RDFa 1.1 Core edge cases that we need to clarify 2010-10-25T10:55:20 2010-10-25T10:55:20 2010-10-25T10:55:20 On Sun, 24 Oct 2010 14:00:39 -0400 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > On Oct 24, 2010, at 5:34 AM, Toby Inkster wrote: > >> EXAMPLE 1: > > My read of section 7.4 is that the body @vocab is ignored, so the one > that remains in effect is that on the html element. This would result > in <http://example.com/1#title>. > > TERMorCURIEorAbsURI But @vocab is a URI, not a TERMorCURIEorAbsURI. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 24 Oct 2010 14:00:39 -0400 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > On Oct 24, 2010, at 5:34 AM, Toby Inkster wrote: > >> EXAMPLE 1: > > My read of section 7.4 is that the body @vocab is ignored, so the one > that remains in effect is that on the html element. This would result > in <http://example.com/1#title>. > > TERMorCURIEorAbsURI But @vocab is a URI, not a TERMorCURIEorAbsURI. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101025164559.5016b0a5%40miranda.g5n.co.uk Re: Some RDFa 1.1 Core edge cases that we need to clarify 2010-10-25T15:45:59 2010-10-25T15:45:59 2010-10-25T15:45:59 On Mon, 25 Oct 2010 13:15:44 +0100 Martin McEvoy <martin@weborganics.co.uk> wrote: > The second vocab attribute "2#" would resolve to > http://example.com/base2#which may be wrong? No, that's not how base works. Check this in a browser: <html> <base href="http://example.com/base"> <a href="2#">hover over this link, look at status bar</a> </html> > I think @vocab should always be an absolute ... On Mon, 25 Oct 2010 13:15:44 +0100 Martin McEvoy <martin@weborganics.co.uk> wrote: > The second vocab attribute "2#" would resolve to > http://example.com/base2#which may be wrong? No, that's not how base works. Check this in a browser: <html> <base href="http://example.com/base"> <a href="2#">hover over this link, look at status bar</a> </html> > I think @vocab should always be an absolute URI (easier to parse an > less complicated) We already need to support relative links in @about, @resource, @src and @href, so supporting relative URIs in @vocab is not too much to ask from a parser. Actually, re-reading the RDFa Core 1.1 spec, it seems we already allow @vocab to be relative (or at least we don't seem to forbid it anywhere). If so, then it seems my concerns are unwarranted, and vocab="2#" is well-defined. > I would Imagine that your second example would be dropped from the > graph because RDFa is case sensitive and you haven't included the > uppercase values in the profile, AGENT, agent and Agent are not the > same in the RDF world. Not so: profile terms are checked case-sensitively, falling back to a case-insensitive check. The URIs they expand to are of course case-sensitive. The case was similar under RDFa 1.0 too: rel="next", rel="NEXT" and rel="nExT" each were expanded to the case-sensitive URI <http://www.w3.org/1999/xhtml/vocab#next>. The problem here is that "AGENT" doesn't match either "Agent" or "agent" case-sensitively, and when the fallback match is attempted, it matches both equally. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101025221342.3bfdcd2e%40miranda.g5n.co.uk Re: Some RDFa 1.1 Core edge cases that we need to clarify 2010-10-25T21:13:42 2010-10-25T21:13:42 2010-10-25T21:13:42 On Mon, 25 Oct 2010 10:50:03 -0500 Shane McCarron <shane@aptest.com> wrote: > Yeah.... that's just ugly. I think we should say the terms are put > in the list in the order they are declared, and that it is the FIRST > case-insensitive match that counts. But profiles are written in RDF, and the expected behaviour of RDF implementations is that the order the triples are expressed in a file is no... On Mon, 25 Oct 2010 10:50:03 -0500 Shane McCarron <shane@aptest.com> wrote: > Yeah.... that's just ugly. I think we should say the terms are put > in the list in the order they are declared, and that it is the FIRST > case-insensitive match that counts. But profiles are written in RDF, and the expected behaviour of RDF implementations is that the order the triples are expressed in a file is not significant (and note that in my example both "agent" and "Agent" were defined in the same profile). Asking implementations to take notice of the order of term declarations in a profile will cause a lot of hassle for people building RDFa parsers on top of off-the-shelf RDF libraries. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101026220806.7ffcd952%40miranda.g5n.co.uk Re: Some RDFa 1.1 Core edge cases that we need to clarify 2010-10-26T21:08:06 2010-10-26T21:08:06 2010-10-26T21:08:06 On Tue, 26 Oct 2010 18:24:07 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > I don't think we should go any further than the canonicalisation > algorithm. FWIW, RDFa 1.0 says to use XML exclusive c14n. However, test case 0101 in the RDFa 1.0 test suite calls for xml:lang attributes to be copied into the child elements of literal - that's a feature of xml c14n, but as I understand it,... On Tue, 26 Oct 2010 18:24:07 +0100 Mark Birbeck <mark.birbeck@webbackplane.com> wrote: > I don't think we should go any further than the canonicalisation > algorithm. FWIW, RDFa 1.0 says to use XML exclusive c14n. However, test case 0101 in the RDFa 1.0 test suite calls for xml:lang attributes to be copied into the child elements of literal - that's a feature of xml c14n, but as I understand it, xml ec14n explicitly says not to do this. Personally I'd be happiest to go with using plain old ec14n. It's a stable specification. XMLLiterals are a rare enough use case that anyone doing particularly delicate things with them should be expected to handle making the literal as self-contained as possible themselves rather than relying on the parser to do so. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101026230516.5ff8bbd4%40miranda.g5n.co.uk default prefix versus no prefix 2010-10-26T22:05:16 2010-10-26T22:05:16 2010-10-26T22:05:16 We need to be clear on the terminology. Default prefix : rel=":foobar" No prefix : rel="foobar". @vocab effects the latter but not the former. RDFa Core 1.1 appendix C.1 says: > You can define a default prefix (via @vocab) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> We need to be clear on the terminology. Default prefix : rel=":foobar" No prefix : rel="foobar". @vocab effects the latter but not the former. RDFa Core 1.1 appendix C.1 says: > You can define a default prefix (via @vocab) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101028095131.771200fa%40miranda.g5n.co.uk Re: ISSUE-58: PlainLiteral and TypedLiteral value for strings [RDFa 1.1 API] 2010-10-28T08:51:31 2010-10-28T08:51:31 2010-10-28T08:51:31 On Thu, 28 Oct 2010 01:42:50 +0000 RDFa Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: > If somebody implements an N-Triples parser, then the value of Plain > Literals will be ascii safe That's not true. The following RDFa and N-Triples should each result in the same triple, with an object consisting of a single non-ASCII character: <div about="#nbsp" property="http://example.com/lit" >&#xA0;</div> <#nbsp> <http://example.com/lit> "\u00A0" . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 28 Oct 2010 01:42:50 +0000 RDFa Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: > If somebody implements an N-Triples parser, then the value of Plain > Literals will be ascii safe That's not true. The following RDFa and N-Triples should each result in the same triple, with an object consisting of a single non-ASCII character: <div about="#nbsp" property="http://example.com/lit" >&#xA0;</div> <#nbsp> <http://example.com/lit> "\u00A0" . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101028095426.2eef09df%40miranda.g5n.co.uk Re: [Fwd: ACTION-487 Assess potential impact of IRI draft on RDF/XML, OWL, and Turtle] 2010-10-28T08:54:26 2010-10-28T08:54:26 2010-10-28T08:54:26 On Thu, 28 Oct 2010 03:13:39 +0100 Nathan <nathan@webr3.org> wrote: > Similarly, 'RDFa in XHTML' does not define 'URI reference' and the > reasonable assumption would be that these are inherited from RDF > Concepts or 3986. > > Unfortunately RDFa has a definition of CURIEs that normatively > references RFC 3987. We should probably seek guidance from TAG regarding what normative reference to in... On Thu, 28 Oct 2010 03:13:39 +0100 Nathan <nathan@webr3.org> wrote: > Similarly, 'RDFa in XHTML' does not define 'URI reference' and the > reasonable assumption would be that these are inherited from RDF > Concepts or 3986. > > Unfortunately RDFa has a definition of CURIEs that normatively > references RFC 3987. We should probably seek guidance from TAG regarding what normative reference to include for URIs/IRIs, as I assume they know the landscape and can guess what direction other XML/HTML/RDF-related specs are headed better than anyone on this WG can. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101028184313.0db888ce%40miranda.g5n.co.uk Re: ISSUE-58: PlainLiteral and TypedLiteral value for strings [RDFa 1.1 API] 2010-10-28T17:43:13 2010-10-28T17:43:13 2010-10-28T17:43:13 On Thu, 28 Oct 2010 11:54:29 +0100 Nathan <nathan@webr3.org> wrote: > Primarily, if we have the following triple: > > <#nbsp> <http://example.com/lit> "Hello \n\tWorld." . > > Do we expect the related call to object.toString() and/or > object.value to return > > "Hello \n\tWorld." > > or > > "Hello > World." I would expect the following to succeed (assuming an assert function is defined... On Thu, 28 Oct 2010 11:54:29 +0100 Nathan <nathan@webr3.org> wrote: > Primarily, if we have the following triple: > > <#nbsp> <http://example.com/lit> "Hello \n\tWorld." . > > Do we expect the related call to object.toString() and/or > object.value to return > > "Hello \n\tWorld." > > or > > "Hello > World." I would expect the following to succeed (assuming an assert function is defined which takes an expression and throws an exception if the expression is false): assert(object.toString() == object.value); assert(object.toString() == "Hello \n\tWorld."); assert(object.toString() != "Hello \\n\\tWorld."); -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101028190302.6d758f34%40miranda.g5n.co.uk Re: [Fwd: ACTION-487 Assess potential impact of IRI draft on RDF/XML, OWL, and Turtle] 2010-10-28T18:03:02 2010-10-28T18:03:02 2010-10-28T18:03:02 On Thu, 28 Oct 2010 14:23:51 +0200 Ivan Herman <ivan@w3.org> wrote: > Guys, help me out please: what is the difference between 3986 and > 3987? RFC 3986 is URI; RFC 3987 is IRI. URIs are US-ASCII only; IRIs are Unicode and allow characters beyond U+007F in many places. Many protocols and formats are not Unicode aware, so the IRI RFC defines a mapping from IRIs to URIs. (A mapping in the reverse ... On Thu, 28 Oct 2010 14:23:51 +0200 Ivan Herman <ivan@w3.org> wrote: > Guys, help me out please: what is the difference between 3986 and > 3987? RFC 3986 is URI; RFC 3987 is IRI. URIs are US-ASCII only; IRIs are Unicode and allow characters beyond U+007F in many places. Many protocols and formats are not Unicode aware, so the IRI RFC defines a mapping from IRIs to URIs. (A mapping in the reverse direction is unnecessary as all URIs are automatically IRIs.) All things being equal, we probably want to use IRIs - they allow people to use non-Latin characters in identifiers which is likely to be a boon for RDFa's acceptability in cultures where the usual alphabets are not derived from the Latin alphabet (e.g. Chinese, Greek, Japanese, Thai, Iranian, etc). The problem is that RDF itself uses URIs as it was defined prior to to existence of IRIs, so this would be an inconsistency between RDF and RDFa. However, this doesn't seem to have proved a practical problem for SPARQL which uses IRIs. We should get advice from TAG as they may be able to provide us with information on what direction RDF is likely to go (stick with URIs or switch to IRIs). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101029224748.3d4068b4%40miranda.g5n.co.uk Re: Review of XHTML+RDFa 1.1 (http://www.w3.org/TR/2010/WD-xhtml-rdfa-20100803/) (Tom) 2010-10-29T21:47:48 2010-10-29T21:47:48 2010-10-29T21:47:48 On Fri, 29 Oct 2010 13:01:04 +0200 Thomas Steiner <tomac@google.com> wrote: > A conforming RDFa Processor must not use the value of @version to > effect its processing. [WHAT MECHANISM IS RECOMMENDED BY THE WG > INSTEAD? THE PREFERRED VERSIONING MECHANISM REMAINS UNCLEAR.] We discussed this on a call a long time ago. Can't remember the outcome of it, but I've always thought this should be a SHO... On Fri, 29 Oct 2010 13:01:04 +0200 Thomas Steiner <tomac@google.com> wrote: > A conforming RDFa Processor must not use the value of @version to > effect its processing. [WHAT MECHANISM IS RECOMMENDED BY THE WG > INSTEAD? THE PREFERRED VERSIONING MECHANISM REMAINS UNCLEAR.] We discussed this on a call a long time ago. Can't remember the outcome of it, but I've always thought this should be a SHOULD NOT. Reason... the above prohibition appears to make this illegal (in weird XML pseudo-code): <BEGIN what="RDFa 1.1 Parser"> <IF version="1.0"> <SWITCH-TO what="RDFa 1.0 Parser" /> </IF> <ELSE> <DO what="process using RDFa 1.1 rules" /> </ELSE> </BEGIN> But it does not forbid the following (and I don't think we could forbid it): <BEGIN what="General Semantic XHTML Parser"> <IF version="1.0"> <SWITCH-TO what="RDFa 1.0 Parser" /> </IF> <ELSE> <SWITCH-TO what="RDFa 1.1 Parser" /> </ELSE> </BEGIN> Even though the externally observable behaviour of each system is the same. That is, if people want to use @version to do version detection, then they can. And even if we say they MUST NOT do it as part of a conforming RDFa 1.1 processor, they can work around the prohibition by simply moving the version check outside the RDFa 1.1 processor, and remain conforming. For what it's worth, my RDFa parser supports 1.0 and 1.1, and also has a "guess" mode that checks @version. I'd certainly claim this is conforming - the RDFa 1.1 parser totally ignores @version; it's only the "guess" parser that looks at it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101031100052.070f7ab8%40miranda.g5n.co.uk API: An ?whatever is an anything that 2010-10-31T10:00:52 2010-10-31T10:00:52 2010-10-31T10:00:52 I've spotted this phrase at least twice in the latest API WD. The second "an" needs to be dropped. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> I've spotted this phrase at least twice in the latest API WD. The second "an" needs to be dropped. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101031143330.10c573b1%40miranda.g5n.co.uk API typos 2010-10-31T14:33:30 2010-10-31T14:33:30 2010-10-31T14:33:30 The default DataContext is said to contain this mapping: document.data.context.setMapping("xsd", "http://www.w3.org/2001/XMLSchema-datatypes#"); That should probably be: document.data.context.setMapping("xsd", "http://www.w3.org/2001/XMLSchema#"); Also, there are two occurrences of the ungrammatical "is an anything that can be". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> The default DataContext is said to contain this mapping: document.data.context.setMapping("xsd", "http://www.w3.org/2001/XMLSchema-datatypes#"); That should probably be: document.data.context.setMapping("xsd", "http://www.w3.org/2001/XMLSchema#"); Also, there are two occurrences of the ungrammatical "is an anything that can be". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101031160503.1895d9cd%40miranda.g5n.co.uk API question 2010-10-31T16:05:03 2010-10-31T16:05:03 2010-10-31T16:05:03 An instance of TypedLiteral will have a "valueOf" method. When this is called, how does it "know" which TypedLiteralConverter to use? TypedLiteralConverters are registered in the DataContext, but there could theoretically be several DataContext objects, each instantiated via document.data.createContext(), and each with different converters registered. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> An instance of TypedLiteral will have a "valueOf" method. When this is called, how does it "know" which TypedLiteralConverter to use? TypedLiteralConverters are registered in the DataContext, but there could theoretically be several DataContext objects, each instantiated via document.data.createContext(), and each with different converters registered. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101031163155.34fc2e92%40miranda.g5n.co.uk Re: API typos 2010-10-31T16:31:55 2010-10-31T16:31:55 2010-10-31T16:31:55 In the list of datatypes that implementations must provide built-in converters for, xsd:boolean seems to be so important that we've included it twice. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> In the list of datatypes that implementations must provide built-in converters for, xsd:boolean seems to be so important that we've included it twice. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101031210955.3bb42d95%40miranda.g5n.co.uk Re: API question 2010-10-31T21:09:55 2010-10-31T21:09:55 2010-10-31T21:09:55 On Sun, 31 Oct 2010 16:25:08 +0000 Nathan <nathan@webr3.org> wrote: > Toby, see: > http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0327.html > > Just raised this myself a few days ago - snap! Great. I think this is a feature that's useful, but very problematic to implement it as specified. Some of the CURIE mapping stuff is similar. It could be redeemed quite easily though I think... On Sun, 31 Oct 2010 16:25:08 +0000 Nathan <nathan@webr3.org> wrote: > Toby, see: > http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0327.html > > Just raised this myself a few days ago - snap! Great. I think this is a feature that's useful, but very problematic to implement it as specified. Some of the CURIE mapping stuff is similar. It could be redeemed quite easily though I think: just move all the DataContext functionality onto the DocumentData interface and get rid of DataContext/document.data.context/document.data.createContext. This should fix things, as all DataStore/DataQuery objects (i.e. the objects which actually use CURIE mapping and type conversion) are created using factory methods on DocumentData, thus could "remember" the DocumentData instance that created them, and use the type conversions and CURIE mappings defined there. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101031223024.1c4b046a%40miranda.g5n.co.uk Re: API question 2010-10-31T22:30:24 2010-10-31T22:30:24 2010-10-31T22:30:24 On Sun, 31 Oct 2010 21:46:37 +0000 Nathan <nathan@webr3.org> wrote: > Two points here, one is why should any object need to remember the > DocumentData instance that created them? currently the only one that > needs anything like this memory is TypedLiteralConverter and that's > only because it has a toValue() method, it would be very easy and > clean to simply drop that toValue method and ensu... On Sun, 31 Oct 2010 21:46:37 +0000 Nathan <nathan@webr3.org> wrote: > Two points here, one is why should any object need to remember the > DocumentData instance that created them? currently the only one that > needs anything like this memory is TypedLiteralConverter and that's > only because it has a toValue() method, it would be very easy and > clean to simply drop that toValue method and ensure that DocumentData > or DataContext (or something!) had a fromTypedLiteral(in TypedLiteral > t) method on it (and the converse, as outlined above). Stores don't need a route back to the TypedLiteralConverter registry, but they do need a route back to the CURIE prefix registry thanks to createTypedLiteral, createTriple, etc. CURIEs are allowed all over the API, but unless the objects that make use of them have a route back to the prefix mapping list, I can't see how they're going to work. I'm starting to think that using closures for prefix mapping will solve a lot of problems. a la: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0131.html The way we're doing it now seems awfully complicated for something that could easily be implemented in "user space". -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101101143842.31571ffb%40miranda.g5n.co.uk Re: API question 2010-11-01T14:38:42 2010-11-01T14:38:42 2010-11-01T14:38:42 On Mon, 01 Nov 2010 11:17:04 +0000 Nathan <nathan@webr3.org> wrote: > and if we add in a simple rule saying that strings which aren't > curies map to PlainLiterals then we can also enable: > > context.createTriple(":me", "foaf:name", "nathan" ); I assume by CURIEs in the above, you mean CURIEs-or-URIs, so full URIs would be OK. I don't think that's a good idea though. It could result in surp... On Mon, 01 Nov 2010 11:17:04 +0000 Nathan <nathan@webr3.org> wrote: > and if we add in a simple rule saying that strings which aren't > curies map to PlainLiterals then we can also enable: > > context.createTriple(":me", "foaf:name", "nathan" ); I assume by CURIEs in the above, you mean CURIEs-or-URIs, so full URIs would be OK. I don't think that's a good idea though. It could result in surprising consequences. Consider the following (and let's forget daylight savings yesterday): context.createTriple(":me", "vcard:tz", "UTC+01:00"); You may surprised to find that <UTC+01:00> is a syntactically valid URI. It has a scheme of "UTC+01" (which is unregistered, but we shouldn't require implementations to track which URI schemes are registered) and a scheme-specific part of "00". APIs should try to avoid surprises. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101101190043.70892519%40miranda.g5n.co.uk Re: Review of XHTML+RDFa 1.1 (http://www.w3.org/TR/2010/WD-xhtml-rdfa-20100803/) (Tom) 2010-11-01T19:00:43 2010-11-01T19:00:43 2010-11-01T19:00:43 On Mon, 1 Nov 2010 17:51:02 +0000 Mark Birbeck <mark.birbeck@x-port.net> wrote: > Just because you can't remember the rationale, doesn't make it > stupid... ;) Personally I think it's a bit of an annoying quirk. It means that, say: <html about="#topic"> <head rel="foaf:isPrimaryTopicOf" resource=""> <meta property="dc:title" ...> <link rel="next" ...> </head> </html> Doesn't work p... On Mon, 1 Nov 2010 17:51:02 +0000 Mark Birbeck <mark.birbeck@x-port.net> wrote: > Just because you can't remember the rationale, doesn't make it > stupid... ;) Personally I think it's a bit of an annoying quirk. It means that, say: <html about="#topic"> <head rel="foaf:isPrimaryTopicOf" resource=""> <meta property="dc:title" ...> <link rel="next" ...> </head> </html> Doesn't work properly, whereas it would if the elements were <div>, <span>, etc. It also means that while <head typeof="foaf:Document"> doesn't generate a blank node, <html typeof="foaf:Document"> does. I'd be in favour of dropping the rule if it weren't for the fact that this would be an incompatibility between 1.0 and 1.1, which would probably be even more of an annoying quirk. FWIW my parser has an option to ignore the special treatment of <head> and <body>: $graph = RDF::RDFa::Parser ->new_from_url($url, { xhtml_elements => 0 }) ->graph; -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1288792227.20489.81.camel%40ophelia2.g5n.co.uk [Fwd: [Bug 11169] New: HTML+RDFa - Infer @content from @datetime on time tag] 2010-11-03T13:50:29 2010-11-03T13:50:29 2010-11-03T13:50:29 Almost missed this. This is a bug report / feature request against HTML +RDFa on the HTMLWG issue tracker. We might want to consider it as input to the RDFaWG too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Almost missed this. This is a bug report / feature request against HTML +RDFa on the HTMLWG issue tracker. We might want to consider it as input to the RDFaWG too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1288794798.20489.83.camel%40ophelia2.g5n.co.uk Re: [Fwd: [Bug 11169] New: HTML+RDFa - Infer @content from @datetime on time tag] 2010-11-03T14:33:20 2010-11-03T14:33:20 2010-11-03T14:33:20 Bother! This was meant for public-rdfa-wg... On Wed, 2010-11-03 at 13:50 +0000, Toby Inkster wrote: > Almost missed this. This is a bug report / feature request against HTML > +RDFa on the HTMLWG issue tracker. We might want to consider it as input > to the RDFaWG too. > > email message attachment, "Forwarded message — [Bug 11169] New: HTML > +RDFa - Infer @content from @datetime on time tag" > ... Bother! This was meant for public-rdfa-wg... On Wed, 2010-11-03 at 13:50 +0000, Toby Inkster wrote: > Almost missed this. This is a bug report / feature request against HTML > +RDFa on the HTMLWG issue tracker. We might want to consider it as input > to the RDFaWG too. > > email message attachment, "Forwarded message — [Bug 11169] New: HTML > +RDFa - Infer @content from @datetime on time tag" > > -------- Forwarded Message -------- > > From: bugzilla@jessica.w3.org > > To: public-html@w3.org > > Subject: [Bug 11169] New: HTML+RDFa - Infer @content from @datetime > > on time tag > > Date: Fri, 29 Oct 2010 17:53:18 +0000 > > > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11169 > > > > Summary: HTML+RDFa - Infer @content from @datetime on time tag > > Product: HTML WG > > Version: unspecified > > Platform: All > > OS/Version: All > > Status: NEW > > Severity: normal > > Priority: P2 > > Component: HTML+RDFa (editor: Manu Sporny) > > AssignedTo: msporny@digitalbazaar.com > > ReportedBy: waters.boyd@gmail.com > > QAContact: public-html-bugzilla@w3.org > > CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, > > public-html@w3.org, msporny@digitalbazaar.com > > > > > > Consider this markup: > > > > <body prefix="dc: http://purl.org/dc/terms/"> > > <time datetime="2010-10-29T15:48:11" property="dc:modified" pubdate>October > > 29th 2010 at 11:48 AM</time> > > <time datetime="2010-10-29T15:36:24" property="dc:created">October 29th 2010 at > > 11:36 AM</time> > > </body> > > > > I would like the @content attribute to be inferred from the time's @datetime. > > > > In the spec right now it seems that the @content attribute will get the text > > contents of the time tag, in this case "October 29th 2010 at 11:48 AM". Which > > is invalid. > > > > Or perhaps the markup is invalid, because the @content is missing. > > > > But it SHOULD be an error to say something like > > <time datetime="2010-10-29T15:48:11" property="dc:modified" > > content="2007-01-01"> > > > > That's valid markup -- it's possible to set @content to any valid W3 date value > > -- but what are the semantics? > > > > > > (I have not participated in semantic web activity in about 7 years, and my > > specification-reading skills have blown away. So perhaps the current draft > > HTML+RDFa spec already has this. But I don't think so.) > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1288804510.20489.95.camel%40ophelia2.g5n.co.uk Re: Best practice for RDF vocabularies documentation reference? 2010-11-03T17:15:12 2010-11-03T17:15:12 2010-11-03T17:15:12 On Wed, 2010-11-03 at 11:04 +0100, Bernard Vatant wrote: > Using rdfs:seeAlso seems OK, but one would like some more precise > property. <http://example.org/vocab> <http://www.w3.org/1999/xhtml/vocab#help> <http://example.org/vocab/primer.pdf> . <http://example.org/vocab/primer.pdf> <http://www.w3.org/1999/xhtml/vocab#glossary> <http://example.org/vocab.html> . <http://example.org/vocab/primer.pdf> <http://www.w3.org/1999/xhtml/vocab#glossary> <http://example.org/vocab.rdf> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 2010-11-03 at 11:04 +0100, Bernard Vatant wrote: > Using rdfs:seeAlso seems OK, but one would like some more precise > property. <http://example.org/vocab> <http://www.w3.org/1999/xhtml/vocab#help> <http://example.org/vocab/primer.pdf> . <http://example.org/vocab/primer.pdf> <http://www.w3.org/1999/xhtml/vocab#glossary> <http://example.org/vocab.html> . <http://example.org/vocab/primer.pdf> <http://www.w3.org/1999/xhtml/vocab#glossary> <http://example.org/vocab.rdf> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1288804718.20489.97.camel%40ophelia2.g5n.co.uk Re: Combined proposed IDL for RDFa API 2010-11-03T17:18:38 2010-11-03T17:18:38 2010-11-03T17:18:38 On Mon, 2010-11-01 at 12:30 +0000, Nathan wrote: > I'm aware that with all the open issues and conversations etc around the > API that it's getting a bit confusing, thus here's a combined IDL from > all proposals, issues, comments etc and I guess how I'm personally > seeing the API at the minute should all issues be resolved in line with > this... Left you some comments in IRC: http://chatlogs.planetrdf.com/swig/2010-11-03.html#T16-35-28 Also some comments for Ivan there too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2010-11-01 at 12:30 +0000, Nathan wrote: > I'm aware that with all the open issues and conversations etc around the > API that it's getting a bit confusing, thus here's a combined IDL from > all proposals, issues, comments etc and I guess how I'm personally > seeing the API at the minute should all issues be resolved in line with > this... Left you some comments in IRC: http://chatlogs.planetrdf.com/swig/2010-11-03.html#T16-35-28 Also some comments for Ivan there too. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101103215701.4f2c7e4a%40miranda.g5n.co.uk Re: Possible issue w/ @profile and http vs. https 2010-11-03T21:57:01 2010-11-03T21:57:01 2010-11-03T21:57:01 On Wed, 03 Nov 2010 16:37:07 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Just throwing this out there as I do think that we would want to > ensure that the browsers that implement RDFa Core "fail to load a > profile" when a profile is loaded from an HTTPS page in non-HTTPS > mode. It's really implementation guidance, but perhaps something that > should be placed into the RDFa API spec ... On Wed, 03 Nov 2010 16:37:07 -0400 Manu Sporny <msporny@digitalbazaar.com> wrote: > Just throwing this out there as I do think that we would want to > ensure that the browsers that implement RDFa Core "fail to load a > profile" when a profile is loaded from an HTTPS page in non-HTTPS > mode. It's really implementation guidance, but perhaps something that > should be placed into the RDFa API spec or the RDFa Core spec? However, "http:" profiles are probably OK on secure pages *if* the parser has hard-coded them. In addition to allowing "https:" profiles on secure pages, there are a few other URI schemes that should be safe to allow, if the library you're using to fetch URIs supports them: sftp: svn+ssh: scp: And "data:" URIs should also be safe to load from HTTPS pages, though it's not clear why anyone would want to. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101103232022.4e534b58%40miranda.g5n.co.uk cookbook 2010-11-03T23:20:22 2010-11-03T23:20:22 2010-11-03T23:20:22 Collecting some recipe ideas for an RDFa Cookbook http://www.w3.org/2010/02/rdfa/wiki/Cookbook -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Collecting some recipe ideas for an RDFa Cookbook http://www.w3.org/2010/02/rdfa/wiki/Cookbook -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101106233133.5bab2570%40miranda.g5n.co.uk Re: Hash vs Slash in relation to the 303 vs 200 debate (was: Is 303 really necessary - demo) 2010-11-06T23:31:33 2010-11-06T23:31:33 2010-11-06T23:31:33 On Sat, 6 Nov 2010 12:33:34 +0000 Ian Davis <lists@iandavis.com> wrote: > On a practical level using frags can be inefficient when your linked > data output is backed by a triple store. If you use a slash URI then > generating the data for html/xml/turtle output is just a simple > "describe <uri>". For hash URIs you need to describe all the resources > with a common prefix because the fragment is... On Sat, 6 Nov 2010 12:33:34 +0000 Ian Davis <lists@iandavis.com> wrote: > On a practical level using frags can be inefficient when your linked > data output is backed by a triple store. If you use a slash URI then > generating the data for html/xml/turtle output is just a simple > "describe <uri>". For hash URIs you need to describe all the resources > with a common prefix because the fragment is not sent by the browser > with the request. That might mean a filter with a regex or string > functions which will be more inefficient. Not necessarily. If you take your ex:isDescribedBy predicate and add that to a triple store where the non-Information-Resource resources are identified using hash URIs, then the SPARQL query is just: DESCRIBE <uri> ?res WHERE { ?res ex:isDescribedBy <uri> . } which needn't be very slow. > The other downside of fragments is you can't say "it exists but I have > no description of it". <#foo> a rdfs:Resource . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101106234240.06f71fc3%40miranda.g5n.co.uk Fw: [foaf-dev] EON - event of note 2010-11-06T23:42:40 2010-11-06T23:42:40 2010-11-06T23:42:40 Begin forwarded message... Date: Thu, 4 Nov 2010 00:32:50 +0000 From: Toby Inkster <tai@g5n.co.uk> To: foaf-dev <foaf-dev@lists.foaf-project.org> Subject: [foaf-dev] EON - event of note Let's do a bit of collaborative work to flesh out a FOAF-like lightweight vocabulary for describing events, suitable for embedding in RDFa to describe concerts, conferences, birthdays, anniversaries, national hol... Begin forwarded message... Date: Thu, 4 Nov 2010 00:32:50 +0000 From: Toby Inkster <tai@g5n.co.uk> To: foaf-dev <foaf-dev@lists.foaf-project.org> Subject: [foaf-dev] EON - event of note Let's do a bit of collaborative work to flesh out a FOAF-like lightweight vocabulary for describing events, suitable for embedding in RDFa to describe concerts, conferences, birthdays, anniversaries, national holidays and so on. Sure, we have the iCalendar RDF vocab, but I've come to the conclusion that that's more suited to representing calendar entries - not the events themselves. I'm thinking of a simple set of extensions for Yves Raimond's Event Ontology. Let's kickstart this with the class eon:Event which would be a trivial subclass of <http://purl.org/NET/c4dm/event.owl#Event>. Here's a sketch of how an event might look in Turtle: <#this> a eon:Event ; foaf:name "Lewes Bonfire" ; foaf:page <http://www.lewesbonfirecouncil.org.uk/> ; eon:date "2010-11-05"^^xsd:date ; eon:location [ foaf:name "Lewes" ; foaf:page wikipedia:Lewes ] . Properties that I think should be included: * eon:start and eon:end - which can be xsd:dateTime or xsd:date (if the latter, then the event starts/ends at an unspecified time on that day) * eon:date - a subproperty of both eon:start and eon:end with range xsd:date. * eon:location - range geo:SpatialThing Probably need an attendee property and an organizer/participant property. Maybe eon:cost, eon:details, eon:bookings. I've placed a sketch on my data wiki <http://wiki.ontologi.es/>. Feel free to edit; and add yourself as a foaf:maker if you do! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101107191334.6ed5b1c0%40miranda.g5n.co.uk Re: RDFa API: thoughts on PropertyGroup 2010-11-07T19:13:34 2010-11-07T19:13:34 2010-11-07T19:13:34 On Sun, 7 Nov 2010 00:49:50 +0100 Niklas Lindström <lindstream@gmail.com> wrote: > 1. The name of the interface "PropertyGroup". Since the methods used > to retrieve these are named "getItemBy[...]", why is it not named > "RDFItem" or similar? Just a detail perhaps, but the naming of things > is quite important IMHO. (It could also be called Description, in > honor of the "D" in RDF.. ;) ) Yeah,... On Sun, 7 Nov 2010 00:49:50 +0100 Niklas Lindström <lindstream@gmail.com> wrote: > 1. The name of the interface "PropertyGroup". Since the methods used > to retrieve these are named "getItemBy[...]", why is it not named > "RDFItem" or similar? Just a detail perhaps, but the naming of things > is quite important IMHO. (It could also be called Description, in > honor of the "D" in RDF.. ;) ) Yeah, the name's pretty awful. I was explaining to danbri on IRC a few days ago exactly what a property group was, and when the penny dropped his reaction was along the lines of, "ah... so it's a Description". It's not a complicated concept - it's one that will be familiar to anyone who's done much coding with RDF - it's just a poorly named interface so it takes a while for people to notice that it's something they're familiar with. Of course, people who have done lots of coding with RDF are not our only target audience, but I don't know if the current name is especially helpful for people who haven't either. So +1 to Description; or even ResourceDescription. It's not dissimilar to the rdf:Description element in RDF/XML. > 2. The PropertyGroup should have an attribute for the subject it > represents the properties of ("readonly attribute RDFResource > subject;"). +1 to this too. > 3 a. It would be really convenient to easily get a PropertyGroup for > an RDFResource (i.e. IRI:s and BNodes), so I suggest adding a > method to RDFResource for getting a PropertyGroup with the given > resource as subject, such as "getItem()". This is to avoid having to > repeatedly call "document.getItemBySubject(...)" when traversing > linked resources. Yes, I think I've suggested this before. The one possible problem is that this means that IRIs and blank nodes need to "know" what graph they are part of. That is, the code behind someResource.getItem() needs to know which graph to look at for triples. Perhaps an alternative would be to add getItemsByX methods to DataStore or RDFGraph or whatever we're calling it these days. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101107212127.23d7e19e%40miranda.g5n.co.uk Re: [foaf-dev] EON - event of note 2010-11-07T21:21:27 2010-11-07T21:21:27 2010-11-07T21:21:27 On Sun, 7 Nov 2010 13:26:15 +0100 "Michael Schneider" <schneid@fzi.de> wrote: > For your information, the term "EON" is also used as the acronym of > the "International Workshop on Evaluation of Ontology-based Tools", > an (almost-) yearly event that exists since 2002. See [1] for the > proceedings of the first EON workshop. It would probably not be > advisable to reuse the acronym for something ... On Sun, 7 Nov 2010 13:26:15 +0100 "Michael Schneider" <schneid@fzi.de> wrote: > For your information, the term "EON" is also used as the acronym of > the "International Workshop on Evaluation of Ontology-based Tools", > an (almost-) yearly event that exists since 2002. See [1] for the > proceedings of the first EON workshop. It would probably not be > advisable to reuse the acronym for something else in the Semantic Web > context. I'm aware of it, but thought that confusion between them would likely be minimal. What do other people think? If others think confusion is likely, I have a backup name: the Event Representation Argot. :-) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101107224934.696649c4%40miranda.g5n.co.uk Re: [foaf-dev] EON - event of note 2010-11-07T22:49:34 2010-11-07T22:49:34 2010-11-07T22:49:34 On Sun, 7 Nov 2010 14:50:58 -0700 Robert Sanderson <azaroth42@gmail.com> wrote: > Is there some reason not to use LODE? > > http://linkedevents.org/ontology/ A few, though they could possibly be addressed by a revision of LODE: 1. lode:Event appears to be restricted to events which have already happened. One of the main use cases for EON is to describe events which are planned. 2. I... On Sun, 7 Nov 2010 14:50:58 -0700 Robert Sanderson <azaroth42@gmail.com> wrote: > Is there some reason not to use LODE? > > http://linkedevents.org/ontology/ A few, though they could possibly be addressed by a revision of LODE: 1. lode:Event appears to be restricted to events which have already happened. One of the main use cases for EON is to describe events which are planned. 2. Its time properties use OWL Time which is overly complicated for the lightweight FOAF-style vocabulary I'm aiming for, suitable for easy embedding in web pages. 3. It's missing certain properties that seem to be useful to cover the kind events that are advertised/mentioned on the Web - cost, booking links, etc. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101108083711.11478bc7%40miranda.g5n.co.uk Re: Is 303 really necessary? 2010-11-08T08:37:11 2010-11-08T08:37:11 2010-11-08T08:37:11 On Thu, 04 Nov 2010 18:10:02 -0400 David Booth <david@dbooth.org> wrote: > ISSUE 1: Whether there is need to use different URIs for the toucan > versus the toucan's web page. Some time ago I showed that there is no > *architectural* need to distinguish between the two: > http://dbooth.org/2007/splitting/ > (Sorry that page is a bit messy, but the reasoning is sound.) The > essential reason is t... On Thu, 04 Nov 2010 18:10:02 -0400 David Booth <david@dbooth.org> wrote: > ISSUE 1: Whether there is need to use different URIs for the toucan > versus the toucan's web page. Some time ago I showed that there is no > *architectural* need to distinguish between the two: > http://dbooth.org/2007/splitting/ > (Sorry that page is a bit messy, but the reasoning is sound.) The > essential reason is that the ambiguity created by using the same URI > for both is not fundamentally different from the ambiguity that > *always* exists when a resource is defined. Hmmm... that is a good point. Concrete example: <http://example.com/toucan> identifies a particular living bird. <http://example.com/doc> identifies a document providing a description of that bird. Now, the Toucan has a brain transplant, swapping its brain with a Monkey. Does <http://example.com/toucan> now identify the Toucan with a Monkey's mind, or the Monkey with a Toucan's mind? Sounds a little contrived? But consider <http://dbpedia.org/resource/China> and think about China, the political entity, as being equivalent to the Toucan's mind; and China, the physical area, as being equivalent to its body. What happens if China's borders change, or it divides into multiple other nations? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101108101111.4f34bc5a%40miranda.g5n.co.uk Re: Is 303 really necessary? 2010-11-08T10:11:11 2010-11-08T10:11:11 2010-11-08T10:11:11 On Thu, 4 Nov 2010 13:22:09 +0000 Ian Davis <me@iandavis.com> wrote: > http://iand.posterous.com/is-303-really-necessary Ian brings up numerous difficulties with 303 responses. The two biggest issues in my opinion are: 1. 303s can be tricky to configure unless you know your way around the server environment you're using, and have sufficient permissions on the server; and 2. They req... On Thu, 4 Nov 2010 13:22:09 +0000 Ian Davis <me@iandavis.com> wrote: > http://iand.posterous.com/is-303-really-necessary Ian brings up numerous difficulties with 303 responses. The two biggest issues in my opinion are: 1. 303s can be tricky to configure unless you know your way around the server environment you're using, and have sufficient permissions on the server; and 2. They require an additional HTTP request to get to the data the client actually wants. I think that without using RDF-specific publishing platforms (think WordPress for Linked Data) #1 is always going to be a difficulty. Even if we accept 200 OK as a response code for non-IR resources, this only solves part of the server configuration problem. There are still other issues to be solved - Apache doesn't come preconfigured with media type information for N3/Turtle/N-Triples. And getting neat-looking URIs (no ".rdf" suffix at the end) requires something like mod_rewrite, Apache multiviews or ForceType to be configured. You could try publishing an N-Triples file with no suffix, and cross your fingers that Apache's default media type of "text/plain" will bubble up. #2 on the other hand can be addressed quite easily. 303 responses are allowed -- indeed encouraged -- to include an entity body. Servers could be configured to duplicate the description of the non-IR resource in this entity body. Or perhaps provide a more summarised description there. Clients just need to look at it before deciding whether to follow the redirect. e.g. >>>> GET /toucan HTTP/1.1 Host: example.com <<<< HTTP/1.1 303 See Other Location: http://example.com/doc Content-Type: text/turtle @prefix foaf: <http://xmlns.com/foaf/0.1/> . <toucan> foaf:name "Harry the Toucan" ; foaf:isPrimaryTopicOf <doc> . !!!! Here the client decides whether that's enough information. !!!! If it needs more, it continues by dereferencing <doc>. >>>> GET /doc HTTP/1.1 Host: example.com <<<< HTTP/1.1 200 OK Content-Location: http://example.com/doc.ttl Content-Type: text/turtle @prefix foaf: <http://xmlns.com/foaf/0.1/> . <toucan> foaf:name "Harry the Toucan" ; foaf:isPrimaryTopicOf <doc> ; foaf:birthday "10-24" . <doc> foaf:maker <alice> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101108111732.1c2bb15c%40miranda.g5n.co.uk Re: isDefinedBy and isDescribedBy, Tale of two missing predicates 2010-11-08T11:17:32 2010-11-08T11:17:32 2010-11-08T11:17:32 On Fri, 5 Nov 2010 15:53:34 +0000 Ian Davis <lists@iandavis.com> wrote: > Suppose I assign the ID 'mars' to represent the planet mars in my RDFa > document. I can then refer to it using http://example.com/foo#mars. > What does it mean when my javascript calls > document.getElementById('mars')? Should I expect now to manipulate the > planet mars? If you are using the URI <http://example.com/foo#m... On Fri, 5 Nov 2010 15:53:34 +0000 Ian Davis <lists@iandavis.com> wrote: > Suppose I assign the ID 'mars' to represent the planet mars in my RDFa > document. I can then refer to it using http://example.com/foo#mars. > What does it mean when my javascript calls > document.getElementById('mars')? Should I expect now to manipulate the > planet mars? If you are using the URI <http://example.com/foo#mars> to represent a planet, then you should not use the same URI to represent an HTML element, as it's likely that the set of HTML elements and the set of planets are disjoint. (In Aug 2006 the IAU finally settled on a definition of planets that at least seems to exclude HTML elements from being planets in their own right.) Given that the planet Mars and your HTML element are in disjoint sets, they must be separate entities so must not share a URI. The upshot of this, is that if you use the following RDFa: <div about="#mars" typeof="iau:Planet"> then you ought not to be including id="mars" on any element in your document, as it introduces ambiguity over what is identified by the URI <http://example.com/foo#mars>. Take a look at my Ontology at <http://ontologi.es/persona> which is serialised in RDFa. It uses a URI of: <http://ontologi.es/persona#Persona> to identify a class, and: <http://ontologi.es/persona#term_Persona> to identify an element in the document where a description of the class can be found. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101108160339.71d1ea0d%40miranda.g5n.co.uk Re: Is 303 really necessary? 2010-11-08T16:03:39 2010-11-08T16:03:39 2010-11-08T16:03:39 On Fri, 5 Nov 2010 10:24:43 +0000 Ian Davis <me@iandavis.com> wrote: > On Fri, Nov 5, 2010 at 10:05 AM, Nathan <nathan@webr3.org> wrote: > >> Not at all, I'm saying that if big-corp makes a /web crawler/ that >> describes what documents are about and publishes RDF triples >> >>  </toucan> :primaryTopic dbpedia:Toucan ; a :Document . > > i don't think so. If the bigcorp is producing triples fr... On Fri, 5 Nov 2010 10:24:43 +0000 Ian Davis <me@iandavis.com> wrote: > On Fri, Nov 5, 2010 at 10:05 AM, Nathan <nathan@webr3.org> wrote: > >> Not at all, I'm saying that if big-corp makes a /web crawler/ that >> describes what documents are about and publishes RDF triples >> >>  </toucan> :primaryTopic dbpedia:Toucan ; a :Document . > > i don't think so. If the bigcorp is producing triples from their crawl > then why wouldn't they use the triples they are sent (and/or > content-location, link headers etc). Perhaps they try to use them, but don't understand the serialisation you're providing. Or perhaps they can parse your triples, but don't realise that {</toucan> a ex:Toucan.} implies Not({</toucan> a foaf:Document.}). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101109012540.0320e314%40miranda.g5n.co.uk Re: isDefinedBy and isDescribedBy, Tale of two missing predicates 2010-11-09T01:25:40 2010-11-09T01:25:40 2010-11-09T01:25:40 On Fri, 05 Nov 2010 09:05:09 +0000 Phil Archer <phil.archer@talis.com> wrote: > I wrote a short blog entry-like piece last night [1]. My basic point > being that I agree wholly with Ian's analysis but disagree with his > conclusions and I argue the case for a new HTTP status code. I also had that thought. Instead of: 200 OK We'd have: 250 This Might Do I created a test script to play aro... On Fri, 05 Nov 2010 09:05:09 +0000 Phil Archer <phil.archer@talis.com> wrote: > I wrote a short blog entry-like piece last night [1]. My basic point > being that I agree wholly with Ian's analysis but disagree with his > conclusions and I argue the case for a new HTTP status code. I also had that thought. Instead of: 200 OK We'd have: 250 This Might Do I created a test script to play around with this idea a few days ago, then promptly forgot all about it. http://examples.tobyinkster.co.uk/test-status-codes.cgi/250/This%20Might%20Do -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101109184003.515b58fd%40miranda.g5n.co.uk Fw: wdrs:describedby = @rel describedby. Erratum published 2010-11-09T18:40:03 2010-11-09T18:40:03 2010-11-09T18:40:03 How controversial would it be to add describedby as a term to the XHTML profile for RDFa 1.1? I'm suggesting: [ a rdfa:TermMapping ] rdfa:term "describedby" ; rdfa:uri "http://www.w3.org/2007/05/powder-s#describedby" . I say "controversial" because if it were added to the XHTML profile it would be the only term to expand to a URI outside the XHTML vocabulary namespace. But it seems usef... How controversial would it be to add describedby as a term to the XHTML profile for RDFa 1.1? I'm suggesting: [ a rdfa:TermMapping ] rdfa:term "describedby" ; rdfa:uri "http://www.w3.org/2007/05/powder-s#describedby" . I say "controversial" because if it were added to the XHTML profile it would be the only term to expand to a URI outside the XHTML vocabulary namespace. But it seems useful to have, as this relation is used quite a bit in the XRD/LRDD/WebFinger world. -Toby ---- Begin forwarded message: Date: Mon, 08 Nov 2010 13:04:57 +0000 From: Phil Archer <phila@w3.org> To: Public POWDER <public-powderwg@w3.org>, "public-lod@w3.org" <public-lod@w3.org>, Semantic Web <semantic-web@w3.org> Subject: wdrs:describedby = @rel describedby. Erratum published As noted on the LOD and POWDER mailing lists in recent days, the revived 303/200 with content-location header debate brought to my attention the mismatch in the documentation of wdrs:describedby. Two headlines ============= 1. On behalf of the former POWDER WG, I apologise for the confusion and for the fact that we hadn't realised the mistake earlier. 2. It has now been fixed as far as it can be for now, with the expectation of a complete fix in the new year. Brief detail ============ The @rel type of 'describedby' is introduced at [1] and formally defined at [2] thus: "The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource." The namespace document for wdrs [3] has now been edited to make it clear that wdrs:describedby is semantically identical to this. The previous, erroneous, range restriction has been removed. Much as I wish I could, I can't just edit the actual POWDER Recommendation - that requires the following of a change process. However, I have published an erratum [4] that makes it clear what edits are expected to be made once the process has been followed (as well as a link to details of the process itself, currently in draft form). The erratum gives full details of the issue and points to the mailing list through which comments can be made. It's worth noting in this context that the @rel value describedby is included Mark Nottingham's Web linking document, that has now, at last, become an RFC [5]. So, with confidence, we can say that all of the following are legitimate and semantically identical: (X)HTML, ATOM <link rel="describedby" href="/doc" type="foo/bar" /> HTTP Link: </doc>; rel="describedby" type="foo/bar"; RDF @prefix wdrs: <http://www.w3.org/2007/05/powder-s#> . <> wdrs:describedby </doc> . Phil. [1] http://www.w3.org/TR/powder-dr/#assoc-linking [2] http://www.w3.org/TR/powder-dr/#appD [3] http://www.w3.org/2007/05/powder-s.html#describedby [4] http://www.w3.org/2007/powder/powder-errata#describedby [5] http://tools.ietf.org/html/rfc5988 -- Phil Archer Former POWDER WG chair http://philarcher.org/ @philarcher1 N.B. For POWDER-related issues neither my Talis nor my W3C Team affiliation is appropriate. Instead, I am allied to Institute of Informatics & Telecommunications (IIT), NCSR "Demokritos" for this. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101109184746.4240375d%40miranda.g5n.co.uk Re: [foaf-dev] EON - event of note 2010-11-09T18:47:46 2010-11-09T18:47:46 2010-11-09T18:47:46 On Tue, 9 Nov 2010 11:24:56 +0100 Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote: > OMG! That additional complexity is something I would certainly want > to avoid. I guess there may be good OWL reasons why one would want to > do that, but I cannot think of any good reasons why you would want to > put the data type into the predicate like this in most cases. Just > think about the horror of writing t... On Tue, 9 Nov 2010 11:24:56 +0100 Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote: > OMG! That additional complexity is something I would certainly want > to avoid. I guess there may be good OWL reasons why one would want to > do that, but I cannot think of any good reasons why you would want to > put the data type into the predicate like this in most cases. Just > think about the horror of writing this in RDFa... And how it also > becomes an extra line in a SPARQL query. There are legitimate use cases for it. OWL Time models instants and periods of time as non-literals to allow relationships to be drawn between them, and for them to be annotated in detail. e.g. [ a owltime:Instant ] :before [ a owltime:Instant ] . If literals were being used, RDF's non-literal-subject restriction would not allow such a statement to be used. However, this complexity is overkill for most use cases. And that's why I want to start a new event vocabulary from scratch - well, by subclassing existing event vocabularies - something dead easy to embed in web pages as RDFa, but that covers most use cases. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101109185358.00193d25%40miranda.g5n.co.uk Re: wdrs:describedby = @rel describedby. Erratum published 2010-11-09T18:53:58 2010-11-09T18:53:58 2010-11-09T18:53:58 On Tue, 09 Nov 2010 12:43:14 -0600 Shane McCarron <shane@aptest.com> wrote: > Note that there are a number of ARIA terms in there too. One of > which is describedBy (I think). ARIA has a describedby attribute, but the XHTML vocab only include's ARIA's roles. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 09 Nov 2010 12:43:14 -0600 Shane McCarron <shane@aptest.com> wrote: > Note that there are a number of ARIA terms in there too. One of > which is describedBy (I think). ARIA has a describedby attribute, but the XHTML vocab only include's ARIA's roles. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101109230429.237cb1a4%40miranda.g5n.co.uk Re: Getting the XHTML+RDFa default profile to be interesting 2010-11-09T23:04:29 2010-11-09T23:04:29 2010-11-09T23:04:29 On Sun, 15 Aug 2010 22:48:14 +0100 "Toby Inkster" <tai@g5n.co.uk> wrote: > OK, here's a first stab at it: > > http://buzzword.org.uk/2010/xhtml-vocab-20100815.xhtml Here's some further revisions: http://buzzword.org.uk/2010/xhtml-vocab-20101109.xhtml I've also provisionally added a "describedby" term. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 15 Aug 2010 22:48:14 +0100 "Toby Inkster" <tai@g5n.co.uk> wrote: > OK, here's a first stab at it: > > http://buzzword.org.uk/2010/xhtml-vocab-20100815.xhtml Here's some further revisions: http://buzzword.org.uk/2010/xhtml-vocab-20101109.xhtml I've also provisionally added a "describedby" term. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101109231101.47c0070e%40miranda.g5n.co.uk Re: wdrs:describedby = @rel describedby. Erratum published 2010-11-09T23:11:01 2010-11-09T23:11:01 2010-11-09T23:11:01 On Tue, 09 Nov 2010 19:28:09 +0000 Phil Archer <phila@w3.org> wrote: > Checking through http://www.w3.org/1999/xhtml/vocab/, I don't see > describedby (any capitalisation) in any section. But there is a > definition of meta. I /think/ this is the only definition of this > term, despite it having been in common use for a long time? rel="meta" is defined in the drafts of XHTML2. XHTML2's keyword... On Tue, 09 Nov 2010 19:28:09 +0000 Phil Archer <phila@w3.org> wrote: > Checking through http://www.w3.org/1999/xhtml/vocab/, I don't see > describedby (any capitalisation) in any section. But there is a > definition of meta. I /think/ this is the only definition of this > term, despite it having been in common use for a long time? rel="meta" is defined in the drafts of XHTML2. XHTML2's keywords fed into the RDFa work, so it's subsequently defined in the XHTML+RDFa 1.0 Rec. XHTML+RDFa 1.1 and HTML+RDFa will define it indirectly via the XHTML vocabulary. It's also the method of linking to RDF from HTML which has been recommended by the FOAF project for ages. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101109235513.060d3040%40miranda.g5n.co.uk Re: Getting the XHTML+RDFa default profile to be interesting 2010-11-09T23:55:13 2010-11-09T23:55:13 2010-11-09T23:55:13 On Tue, 09 Nov 2010 23:09:12 +0000 Nathan <nathan@webr3.org> wrote: > cool - what about http://tools.ietf.org/html/rfc5988#section-6.2.2 > and > http://www.iana.org/assignments/link-relations/link-relations.xhtml - > aren't the same terms mapped to (or may be mapped to) different IRIs? Atom (which fed into RFC 5988) maps link relations by adding this prefix: http://www.iana.org/assignments/rel... On Tue, 09 Nov 2010 23:09:12 +0000 Nathan <nathan@webr3.org> wrote: > cool - what about http://tools.ietf.org/html/rfc5988#section-6.2.2 > and > http://www.iana.org/assignments/link-relations/link-relations.xhtml - > aren't the same terms mapped to (or may be mapped to) different IRIs? Atom (which fed into RFC 5988) maps link relations by adding this prefix: http://www.iana.org/assignments/relation/ RDFa 1.0 maps many of the same relations to: http://www.w3.org/1999/xhtml/vocab# RDFa 1.1 can't really differ from 1.0 - we're chartered to maintain backwards compatibility as much as possible. However, the vocab could use owl:equivalentProperty or rdfs:subPropertyOf to link to the IANA URIs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101110124910.7e4b407d%40miranda.g5n.co.uk Safe Subsets of RDFa 2010-11-10T12:49:10 2010-11-10T12:49:10 2010-11-10T12:49:10 Both Google and Facebook seem to consume subsets of RDFa. Some subsets of RDFa are safer to consume than others though, as this Wiki page demonstrates: http://www.w3.org/2010/02/rdfa/wiki/Subsets I think it would be useful for this WG to publish as a note something like the above, as guidance for people wishing to implement partial RDFa processors. Alternatively this could be added as informative guidance to RDFa Core, but I think it would overcomplicate the spec. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Both Google and Facebook seem to consume subsets of RDFa. Some subsets of RDFa are safer to consume than others though, as this Wiki page demonstrates: http://www.w3.org/2010/02/rdfa/wiki/Subsets I think it would be useful for this WG to publish as a note something like the above, as guidance for people wishing to implement partial RDFa processors. Alternatively this could be added as informative guidance to RDFa Core, but I think it would overcomplicate the spec. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101110141755.37730f07%40miranda.g5n.co.uk Re: What would break, a question for implementors? (was Re: Is 303 really necessary?) 2010-11-10T14:17:55 2010-11-10T14:17:55 2010-11-10T14:17:55 On Tue, 9 Nov 2010 17:04:44 -0500 (EST) joel sachs <jsachs@csee.umbc.edu> wrote: > I think we can, though we might not be properly understood, e.g. > "Kingsley was great in Gandhi and Sexy Beast." > > Wasn't this part of the summer's argument regarding literals as > rdf:subjects , i.e. But: "Kingsley" film:isStarOf <#SexyBeast> . "Kingsley" film:isStarOf <#Ghandi> . is no more ambiguous tha... On Tue, 9 Nov 2010 17:04:44 -0500 (EST) joel sachs <jsachs@csee.umbc.edu> wrote: > I think we can, though we might not be properly understood, e.g. > "Kingsley was great in Gandhi and Sexy Beast." > > Wasn't this part of the summer's argument regarding literals as > rdf:subjects , i.e. But: "Kingsley" film:isStarOf <#SexyBeast> . "Kingsley" film:isStarOf <#Ghandi> . is no more ambiguous than: <#SexyBeast> film:star "Kingsley" . <#Ghandi> film:star "Kingsley" . And what exactly is ambiguous about the following example? "2010-11-10"^^xsd:date d:precedes "2010-11-11"^^xsd:date . Whether an identifier is ambiguous and whether it's a literal are two mostly orthogonal issues. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101110221122.32ebb64d%40miranda.g5n.co.uk Re: dcterms:creator in RDFa Core 1.1, WD of October 26 2010-11-10T22:11:22 2010-11-10T22:11:22 2010-11-10T22:11:22 On Wed, 10 Nov 2010 15:34:32 -0500 Thomas Baker <tbaker@tbaker.de> wrote: > Some of the examples in [1] generate triples such as: > > <> foaf:primaryTopic <#bbq> . > <> dcterms:creator "Jo" . > > However, http://purl.org/dc/terms/creator has a range of > dcterms:Agent. Using dc:creator would not be incorrect because > http://purl.org/dc/elements/1.1/creator has no specified range > (or ... On Wed, 10 Nov 2010 15:34:32 -0500 Thomas Baker <tbaker@tbaker.de> wrote: > Some of the examples in [1] generate triples such as: > > <> foaf:primaryTopic <#bbq> . > <> dcterms:creator "Jo" . > > However, http://purl.org/dc/terms/creator has a range of > dcterms:Agent. Using dc:creator would not be incorrect because > http://purl.org/dc/elements/1.1/creator has no specified range > (or rather, by default, rdfs:Resource). This seems to me to be a conflict between: 1. the desire to use the latest and greatest version of Dublin Core; and 2. the desire to use a literal object so that the example includes both a literal and a URI. Perhaps something like dcterms:modified could be used in the example instead of dcterms:creator, as that has a literal object? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101110230719.70dc4ceb%40miranda.g5n.co.uk Re: Status codes / IR vs. NIR -- 303 vs. 200 2010-11-10T23:07:19 2010-11-10T23:07:19 2010-11-10T23:07:19 On Wed, 10 Nov 2010 12:30:35 -0800 Bradley Allen <bradley.p.allen@gmail.com> wrote: > Nathan- I think you are overly discounting scalability problems with > fragment URIs. > > Most of the use cases I am dealing with in moving linked data into > production at Elsevier entail SKOS concept schemes with concepts > numbering in the 100,000's to millions, which will be constantly under > curation, pre... On Wed, 10 Nov 2010 12:30:35 -0800 Bradley Allen <bradley.p.allen@gmail.com> wrote: > Nathan- I think you are overly discounting scalability problems with > fragment URIs. > > Most of the use cases I am dealing with in moving linked data into > production at Elsevier entail SKOS concept schemes with concepts > numbering in the 100,000's to millions, which will be constantly under > curation, preferably using REST APIs that allow POSTs and PUTs to > create and update individual concepts. The Library of Congress Subject Headings consist of over a quarter of a million SKOS concepts. They use hash URIs. e.g. http://id.loc.gov/authorities/sh85121735#concept http://id.loc.gov/authorities/sh85121591#concept http://id.loc.gov/authorities/sh85119315#concept http://id.loc.gov/authorities/sh86001831#concept http://id.loc.gov/authorities/sh85072413#concept -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101110232626.7c2b628e%40miranda.g5n.co.uk Re: Status codes / IR vs. NIR -- 303 vs. 200 2010-11-10T23:26:26 2010-11-10T23:26:26 2010-11-10T23:26:26 On Wed, 10 Nov 2010 15:13:42 -0800 Bradley Allen <bradley.p.allen@gmail.com> wrote: > Thanks; that's a useful example. So the convention in that case is to > append '#concept' to the end of the IR? #concept is what LOC is using for their SKOS Concepts. #me or similar might be more conventional for FOAF Persons. The BBC uses #artist for the BBC Music site, e.g. http://www.bbc.co.uk/music/artis... On Wed, 10 Nov 2010 15:13:42 -0800 Bradley Allen <bradley.p.allen@gmail.com> wrote: > Thanks; that's a useful example. So the convention in that case is to > append '#concept' to the end of the IR? #concept is what LOC is using for their SKOS Concepts. #me or similar might be more conventional for FOAF Persons. The BBC uses #artist for the BBC Music site, e.g. http://www.bbc.co.uk/music/artists/cc197bad-dc9c-440d-a5b5-d52ba2e14234#artist And the BBC Programmes guide uses #programme: http://www.bbc.co.uk/programmes/b006mvhd#programme #this is a good general fragment ID if you can't think of a better convention for your data. I think it's what Virtuoso uses for a lot of its URIs. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101110234401.17e1322b%40miranda.g5n.co.uk Re: Status codes / IR vs. NIR -- 303 vs. 200 2010-11-10T23:44:01 2010-11-10T23:44:01 2010-11-10T23:44:01 On Wed, 10 Nov 2010 23:07:19 +0000 Toby Inkster <tai@g5n.co.uk> wrote: > http://id.loc.gov/authorities/sh85121735#concept > http://id.loc.gov/authorities/sh85121591#concept > http://id.loc.gov/authorities/sh85119315#concept > http://id.loc.gov/authorities/sh86001831#concept > http://id.loc.gov/authorities/sh85072413#concept I should add: http://id.loc.gov/authorities/sh85093901#concept http://id.loc.gov/authorities/sh85131236#concept -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 10 Nov 2010 23:07:19 +0000 Toby Inkster <tai@g5n.co.uk> wrote: > http://id.loc.gov/authorities/sh85121735#concept > http://id.loc.gov/authorities/sh85121591#concept > http://id.loc.gov/authorities/sh85119315#concept > http://id.loc.gov/authorities/sh86001831#concept > http://id.loc.gov/authorities/sh85072413#concept I should add: http://id.loc.gov/authorities/sh85093901#concept http://id.loc.gov/authorities/sh85131236#concept -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101111150101.3e56a44c%40miranda.g5n.co.uk Re: PROPOSAL to close ISSUE-57: TypedLiteralConverter Failures and Exceptions 2010-11-11T15:01:01 2010-11-11T15:01:01 2010-11-11T15:01:01 On Wed, 10 Nov 2010 20:28:10 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > TypedLiteral Conversion Algorithm: > If a TypedLiteralConverter is registered for the .type of the > typedliteral then try to convert it, if successful return the > converted type (for instance a Date) in all other cases (including > exceptions) return the TypedLiteral. I'd have thought it more useful to return .value in other cases. That's how DataContext.convertType works in the current WD. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 10 Nov 2010 20:28:10 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > TypedLiteral Conversion Algorithm: > If a TypedLiteralConverter is registered for the .type of the > typedliteral then try to convert it, if successful return the > converted type (for instance a Date) in all other cases (including > exceptions) return the TypedLiteral. I'd have thought it more useful to return .value in other cases. That's how DataContext.convertType works in the current WD. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101111151043.2d7274a1%40miranda.g5n.co.uk Re: PROPOSAL to close ISSUE-49: RDFNode type, equality and canonicalization 2010-11-11T15:10:43 2010-11-11T15:10:43 2010-11-11T15:10:43 On Wed, 10 Nov 2010 20:42:51 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > The equals() method will return true if both RDFNodes have the same > nodeType() and the same toCanonical() result. Simple string comparison > between the two methods is sufficient when testing for equality > between RDFNodes. My implementation already has an isEqual method that works precisely that way. :-) I'll... On Wed, 10 Nov 2010 20:42:51 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > The equals() method will return true if both RDFNodes have the same > nodeType() and the same toCanonical() result. Simple string comparison > between the two methods is sufficient when testing for equality > between RDFNodes. My implementation already has an isEqual method that works precisely that way. :-) I'll just need to rename it. FWIW my isEqual also accepts a string as a parameter, so: $iri = RDF::RDFa::API::IRI->new('http://example.com/'); $iri->isEqual('<http://example.com/>'); # true There's a reason for that - I overload Perl's normal 'eq' operator which tests for string equality, so I can do this: $iri = RDF::RDFa::API::IRI->new('http://example.com/'); if ($iri eq '<http://example.com/>') { # this will happen } -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101112191659.63961cc3%40miranda.g5n.co.uk Re: survey: who uses the triple foaf:name rdfs:subPropertyOf rdfs:label? 2010-11-12T19:16:59 2010-11-12T19:16:59 2010-11-12T19:16:59 On Fri, 12 Nov 2010 12:08:36 +0100 Dan Brickley <danbri@danbri.org> wrote: > This is one of several things that OWL DL oriented tools (eg. > http://www.mygrid.org.uk/OWL/Validator) don't seem to like, since it > mixes application schemas with the W3C builtins. DL is a tiresome bore. Add a few more non-DL constructs to give those DL tools a good kicking! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 12 Nov 2010 12:08:36 +0100 Dan Brickley <danbri@danbri.org> wrote: > This is one of several things that OWL DL oriented tools (eg. > http://www.mygrid.org.uk/OWL/Validator) don't seem to like, since it > mixes application schemas with the W3C builtins. DL is a tiresome bore. Add a few more non-DL constructs to give those DL tools a good kicking! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101112221603.13b24cf3%40miranda.g5n.co.uk Re: Datatype normalization 2010-11-12T22:16:03 2010-11-12T22:16:03 2010-11-12T22:16:03 On Fri, 12 Nov 2010 11:33:12 +0000 Nathan <nathan@webr3.org> wrote: > What reason would there be not to just infer/pull the type and > convert to a typed literal? It probably is sensible to do it, but not in a general RDF library. Why? Because probably the place where you're going to be able to do it most reliably/usefully will be where the value is actually used to do something. Replacing your... On Fri, 12 Nov 2010 11:33:12 +0000 Nathan <nathan@webr3.org> wrote: > What reason would there be not to just infer/pull the type and > convert to a typed literal? It probably is sensible to do it, but not in a general RDF library. Why? Because probably the place where you're going to be able to do it most reliably/usefully will be where the value is actually used to do something. Replacing your { ex:prop rdfs:range xsd:decimal . } with an ex:costs property (same range), the specific programming which actually processes these as prices, rather than the generic programming which is processing them as typed literals, will have better knowledge of what the data is supposed to look like, so how best to clean it up. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101113221529.7ad5ce59%40miranda.g5n.co.uk Re: RDF vocabulary for describing news? 2010-11-13T22:15:29 2010-11-13T22:15:29 2010-11-13T22:15:29 On Fri, 12 Nov 2010 01:09:39 -0500 Stéphane Corlosquet <scorlosquet@gmail.com> wrote: > What do people use to describe news articles in RDF? I have some code that converts the hNews microformat to RDF. hNews is an extension of hAtom, so for my conversion I created a small vocabulary that extends Henry Story's AtomOWL: http://ontologi.es/hnews# I'd be happy to add any other terms you need to the vocabulary should you decide to use it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 12 Nov 2010 01:09:39 -0500 Stéphane Corlosquet <scorlosquet@gmail.com> wrote: > What do people use to describe news articles in RDF? I have some code that converts the hNews microformat to RDF. hNews is an extension of hAtom, so for my conversion I created a small vocabulary that extends Henry Story's AtomOWL: http://ontologi.es/hnews# I'd be happy to add any other terms you need to the vocabulary should you decide to use it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101113235035.2bf6a138%40miranda.g5n.co.uk Re: RDF vocabulary for describing news? 2010-11-13T23:50:35 2010-11-13T23:50:35 2010-11-13T23:50:35 On Sat, 13 Nov 2010 18:21:58 -0500 Stéphane Corlosquet <scorlosquet@gmail.com> wrote: > thanks for that link. However I could not find any RDF class in > hnews, so I looked at AtomOWL in my quest for a class describing a > news item: the closest I found is awol:Entry [1] whose description is > "An Entry is an Entry, and that's all you need to know!". Yep - every property in the hnews vocab has a... On Sat, 13 Nov 2010 18:21:58 -0500 Stéphane Corlosquet <scorlosquet@gmail.com> wrote: > thanks for that link. However I could not find any RDF class in > hnews, so I looked at AtomOWL in my quest for a class describing a > news item: the closest I found is awol:Entry [1] whose description is > "An Entry is an Entry, and that's all you need to know!". Yep - every property in the hnews vocab has a domain of atomowl:Entry. > There is a > reference to §4.1.2 of the rfc 4287 spec [2] but that spec does not > exist anymore (at least not at this URI). RFC 4287 can be found in hundreds of locations, including: http://www.ietf.org/rfc/rfc4287.txt > In any case, it seem that the AtomOwl Entry is very similar to the > concept of RSS Item, which is rather vague (you can find any piece of > content in an RSS feed these days). Yep - pretty much the same concept. It would certainly be possible to add an extra class to the hnews vocab to cover the concept of a news item, but it's unclear how this would be helpful, as the concept of a news item is pretty vague anyway. Do blog entries count as news? Tweets? Wiki updates? > fyi, not really related, but the item-license element is missing from > hnews (not that I actually need it but thought I'd mention it for > completeness - or maybe you left it out for some reason.). I use <http://creativecommons.org/ns#license> to cover licenses. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101114195353.46f09ffa%40miranda.g5n.co.uk Atom 1.0 + RDFa 1.1 2010-11-14T19:53:53 2010-11-14T19:53:53 2010-11-14T19:53:53 I've been thinking a bit more about RDFa in Atom, and thought it would be useful if there were a document describing how RDFa works in this host language. As there is no other group that seems like it would be working in this area either inside the W3C or outside (Yahoo's scaled back its SearchMonkey development IIRC), this WG is probably best placed to publish such a document. It's not in our cha... I've been thinking a bit more about RDFa in Atom, and thought it would be useful if there were a document describing how RDFa works in this host language. As there is no other group that seems like it would be working in this area either inside the W3C or outside (Yahoo's scaled back its SearchMonkey development IIRC), this WG is probably best placed to publish such a document. It's not in our charter so would need to be a Note or something of even less status than that. I've started on the Wiki: http://www.w3.org/2010/02/rdfa/wiki/Atom_plus_RDFa -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1289818581.9995.26.camel%40ophelia2.g5n.co.uk Re: Atom 1.0 + RDFa 1.1 2010-11-15T10:56:32 2010-11-15T10:56:32 2010-11-15T10:56:32 On Mon, 2010-11-15 at 11:18 +0100, Ivan Herman wrote: > From a technical point of view, I must admit I feel a bit uneasy by > the fact that the your document requires changes on the processing > model. I assume you're talking about inferring typeof="" on <entry> elements. (Actually the Wiki also says to do this for <feed> - it shouldn't - I'll fix that.) It's not really my document that require... On Mon, 2010-11-15 at 11:18 +0100, Ivan Herman wrote: > From a technical point of view, I must admit I feel a bit uneasy by > the fact that the your document requires changes on the processing > model. I assume you're talking about inferring typeof="" on <entry> elements. (Actually the Wiki also says to do this for <feed> - it shouldn't - I'll fix that.) It's not really my document that requires it - it's the existing Atom 1.0 syntax and semantics. Given: <feed xmlns="http://www.w3.org/2005/Atom"> <entry> <link rel="self" href="page1" /> <link rel="next" href="page2" /> </entry> <entry> <link rel="self" href="page2" /> <link rel="previous" href="page1" /> </entry> </feed> It is the entries that are the subjects of those links, not the feed itself. If we don't set a new subject for each entry, then we'll just get junk data back parsing existing Atom feeds. Yes, this does require coding rather than configuration, but if you wanted to abstract this kind of processing away from your parsing code you could add typeof="" attributes via an XSLT preprocess. (And you could do the same for about="" on <head> and <body> in HTML.) You'd have a single XSLT preprocessing file for each host language much like you'd have a single default profile. PS: if you dislike Atom+RDFa, wait until you start trying to parse OpenDocument's RDFa. :-) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1289820700.9995.39.camel%40ophelia2.g5n.co.uk Re: Atom 1.0 + RDFa 1.1 2010-11-15T11:31:42 2010-11-15T11:31:42 2010-11-15T11:31:42 On Mon, 2010-11-15 at 11:18 +0100, Ivan Herman wrote: > I will check whether the group would be authorized to publish a note > on something that is not in its charter in the first place. If so, and > the group agrees on the content, publishing a Note might be a good > idea indeed. Thanks - that would be my preferred route. If it proves tricky administratively, then Julian's suggestion of publish... On Mon, 2010-11-15 at 11:18 +0100, Ivan Herman wrote: > I will check whether the group would be authorized to publish a note > on something that is not in its charter in the first place. If so, and > the group agrees on the content, publishing a Note might be a good > idea indeed. Thanks - that would be my preferred route. If it proves tricky administratively, then Julian's suggestion of publishing an informational RFC might be a good alternative. On a related note, when this WG ceases to be, what will happen to the wiki? Will it disappear; be archived in a read-only state; or continue to be fully usable by former WG members? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1289824525.9995.52.camel%40ophelia2.g5n.co.uk Re: Atom 1.0 + RDFa 1.1 2010-11-15T12:35:26 2010-11-15T12:35:26 2010-11-15T12:35:26 On Mon, 2010-11-15 at 13:02 +0100, Ivan Herman wrote: > Actually, this may be an idea on the specification level, too. Why > don't we specify these things as a virtual DOM->DOM transformation in > the document, too? Ie, let us not touch the formal processing steps of > RDFa Core; rather, any host language could be defined by such > transformations (and possibly a default profile). That would sugge... On Mon, 2010-11-15 at 13:02 +0100, Ivan Herman wrote: > Actually, this may be an idea on the specification level, too. Why > don't we specify these things as a virtual DOM->DOM transformation in > the document, too? Ie, let us not touch the formal processing steps of > RDFa Core; rather, any host language could be defined by such > transformations (and possibly a default profile). That would suggest a > much cleaner separation specification-wise. I'd be happy with this provided that it doesn't lead to implementations being required to support XSLT. XSLT (2.0 in particular) is a pretty heavy-weight dependency. Perhaps something along the lines of: "Host language specifications SHOULD provide an XSLT transformation that may be used to transform a host language document into a document capable of being parsed as RDFa Core 1.1. Processing software MAY use this as part of a pre-processing step to handle the host language." The only problem with this -- and pre-processing in general -- is the XMLLiteral edge case. e.g. <feed xmlns="http://www.w3.org/2005/Atom" property="http://example.com/xml" datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral" ><entry /></feed> Should result in the following triple: <> <http://example.com/xml> "<entry xmlns=\"http://www.w3.org/2005/Atom\"></entry>"^^rdf:XMLLiteral . But if a pre-processor were used, might result in: <> <http://example.com/xml> "<entry xmlns=\"http://www.w3.org/2005/Atom\" typeof=\"\"></entry>"^^rdf:XMLLiteral . The XSLT needs to be pretty clever to avoid things like this. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1289833855.9995.59.camel%40ophelia2.g5n.co.uk Re: Atom 1.0 + RDFa 1.1 2010-11-15T15:10:58 2010-11-15T15:10:58 2010-11-15T15:10:58 On Mon, 2010-11-15 at 13:44 +0100, Ivan Herman wrote: > And that is an XSLT problem that we should not deal with. > > I guess an ATOM+RDFa description would simply describe that a > transformation should be applied whereby each <feed> element gets a > @typeof="" attribute before processing it through RDFa Core. Should be <entry>, not <feed>. But my point is, what about XMLLiterals that have <en... On Mon, 2010-11-15 at 13:44 +0100, Ivan Herman wrote: > And that is an XSLT problem that we should not deal with. > > I guess an ATOM+RDFa description would simply describe that a > transformation should be applied whereby each <feed> element gets a > @typeof="" attribute before processing it through RDFa Core. Should be <entry>, not <feed>. But my point is, what about XMLLiterals that have <entry> elements as descendants? These then end up with a typeof="" attribute which shouldn't be there. That's a general pre-processing edge case which will occur whether you're using XSLT or Python+DOM or even just plain old regular expressions. Here's the example again: <feed xmlns="http://www.w3.org/2005/Atom" property="http://example.com/xml" datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral" ><entry /></feed> Consider the XMLLiteral generated. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1289835800.9995.76.camel%40ophelia2.g5n.co.uk Re: Atom 1.0 + RDFa 1.1 2010-11-15T15:43:22 2010-11-15T15:43:22 2010-11-15T15:43:22 On Mon, 2010-11-15 at 16:22 +0100, Ivan Herman wrote: > > Here's the example again: > > > > <feed xmlns="http://www.w3.org/2005/Atom" > > property="http://example.com/xml" > > datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral" > >> <entry /></feed> > > is this a realistic example? I mean: how would such a situation in > Atom occur? What does it mean? Is it a real-life issue? ... On Mon, 2010-11-15 at 16:22 +0100, Ivan Herman wrote: > > Here's the example again: > > > > <feed xmlns="http://www.w3.org/2005/Atom" > > property="http://example.com/xml" > > datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral" > >> <entry /></feed> > > is this a realistic example? I mean: how would such a situation in > Atom occur? What does it mean? Is it a real-life issue? No, it's not realistic - it's a minimal example. If you'd prefer... <div about="" property="dc:description" datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> This page is all about the book <div about="http://www.worldcatlibraries.org/isbn/9780262912423" typeof="bibo:Book" class="book-template"> <em property="dc:title">A Semantic Web Primer</em> <ul rel="dc:creator" resource="::List"> <li property="::member">Grigoris Antoniou</li> <li property="::member">Frank van Harmelen</li> </ul> </div> </div> If this is processed using http://www.w3.org/2010/02/rdfa/wiki/ContainersAndCollections#Collection.2FContainer_transformation_of_the_DOM then the XMLLiteral will contain dummy elements that were inserted by the pre-processor. And in fact, these dummy elements will break the HTML content model, as they need to be parents of <li> but children of <ul>, and I don't think any such elements exist (perhaps <noscript>??) Pre-processing in general is incompatible with XMLLiterals, unless the preprocessor is exceptionally careful at not changing any elements that will be part of an XMLLiteral; or there is some sort of communication between the code that does the pre-processing and the code that generates XMLLiterals, to make sure that any changes made by the pre-processor are undone when generating an XMLLiteral. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1289841120.9995.85.camel%40ophelia2.g5n.co.uk Re: Atom 1.0 + RDFa 1.1 2010-11-15T17:12:02 2010-11-15T17:12:02 2010-11-15T17:12:02 On Mon, 2010-11-15 at 17:01 +0100, Ivan Herman wrote: > For an RDFa-savy preprocessing is of course easy because it can find > an XML Literal declaration. A pre-processor can easily find an XMLLiteral declaration? What about datatype="foo"? What if "foo" is defined as expanding to rdf:XMLLiteral in some profile somewhere? A pre-processor would effectively need to handle all the term mapping stuff, including profiles, to be able to know if it's treading inside an XMLLiteral. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2010-11-15 at 17:01 +0100, Ivan Herman wrote: > For an RDFa-savy preprocessing is of course easy because it can find > an XML Literal declaration. A pre-processor can easily find an XMLLiteral declaration? What about datatype="foo"? What if "foo" is defined as expanding to rdf:XMLLiteral in some profile somewhere? A pre-processor would effectively need to handle all the term mapping stuff, including profiles, to be able to know if it's treading inside an XMLLiteral. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101115234350.584527cc%40miranda.g5n.co.uk unsubscribe 2010-11-15T23:43:50 2010-11-15T23:43:50 2010-11-15T23:43:50 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101115234648.592931ad%40miranda.g5n.co.uk unsubscribe 2010-11-15T23:46:48 2010-11-15T23:46:48 2010-11-15T23:46:48 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101116101709.25ef1dfc%40miranda.g5n.co.uk Re: An interesting viewpoint about the negatives of profiling 2010-11-16T10:17:09 2010-11-16T10:17:09 2010-11-16T10:17:09 On Tue, 16 Nov 2010 00:01:21 -0600 Shane McCarron <shane@aptest.com> wrote: > I read this. I will read it again. But when we are talking about > subsetting RDFa and the problems it could cause... we should remember > this article. > http://radar.oreilly.com/2010/11/semantic-web-linked-data.html For what it's worth, my subsetting document is designed to allow people to subset RDF in very OG... On Tue, 16 Nov 2010 00:01:21 -0600 Shane McCarron <shane@aptest.com> wrote: > I read this. I will read it again. But when we are talking about > subsetting RDFa and the problems it could cause... we should remember > this article. > http://radar.oreilly.com/2010/11/semantic-web-linked-data.html For what it's worth, my subsetting document is designed to allow people to subset RDF in very OGP-like ways safely. OGP, for example, can be considered to be a conjunction of filtered triples (ignoring any triples that don't have a predicate in the OGP namespace), and ignoring particular elements (in XPath terms, '/html/body', '/html/head/*[not(self::meta)]'). Of course the current Facebook implementation doesn't implement RDFa fully - it seems to ignore prefix-to-URI mappings and imply meaning from the CURIE prefix. The subsetting document is guidance for how consumers like Facebook could upgrade their parsers to handle RDFa correctly, while still restricting themselves to consuming the subset they desire. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101116161525.377674a3%40miranda.g5n.co.uk Re: An interesting viewpoint about the negatives of profiling 2010-11-16T16:15:25 2010-11-16T16:15:25 2010-11-16T16:15:25 On Tue, 16 Nov 2010 14:41:22 +0100 Ivan Herman <ivan@w3.org> wrote: > There is a reference to a blog comparing RDFa to microformats which > is hopelessly outdated and, as far as I can judge, was factually > wrong even at the time it was written, etc... In fairness to Evan, whose blog post is referenced, it was written in September 2007, before the first public working draft of XHTML+RDFa 1.0 was... On Tue, 16 Nov 2010 14:41:22 +0100 Ivan Herman <ivan@w3.org> wrote: > There is a reference to a blog comparing RDFa to microformats which > is hopelessly outdated and, as far as I can judge, was factually > wrong even at the time it was written, etc... In fairness to Evan, whose blog post is referenced, it was written in September 2007, before the first public working draft of XHTML+RDFa 1.0 was published, when the only public W3C documents describing RDFa were the XHTML 2.0 working drafts. Evan is now lead developer of StatusNet, the software that powers identi.ca. While the only RDFa StatusNet publishes is the grandfathered-in rel values and a little OGP here and there, it does publish some pretty good FOAF, SIOC and RSS in RDF/XML. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101117015407.483ff55e%40miranda.g5n.co.uk Re: CONFIRM u3198229052 2010-11-17T01:54:07 2010-11-17T01:54:07 2010-11-17T01:54:07 On Mon, 15 Nov 2010 23:47:18 +0000 public-egov-ig-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > should be deleted from the public-egov-ig mailing list. > > It has NOT yet been unsubscribed from the list. > To unsubscribe you need to confirm the unsubscription > request by sending an email to the address: > > public-egov-ig-reque... On Mon, 15 Nov 2010 23:47:18 +0000 public-egov-ig-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > should be deleted from the public-egov-ig mailing list. > > It has NOT yet been unsubscribed from the list. > To unsubscribe you need to confirm the unsubscription > request by sending an email to the address: > > public-egov-ig-request@w3.org > > with the Subject string: > > CONFIRM u3198229052 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm > string has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed > above will be (un)subscribed. If the address above is incorrect, > please do not send the confirmation message listed above. Instead, > send a new (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event > that you did not send a request to (un)subscribe, the headers of the > message may help you discover who sent the request. > > > >From tai@g5n.co.uk Mon Nov 15 23:47:18 2010 > >Received: from bart.w3.org ([128.30.52.63]) > > by frink.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1PI8lZ-0007YQ-T7 > > for public-egov-ig-request@listhub.w3.org; Mon, 15 Nov 2010 > > 23:47:17 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by bart.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1PI8lW-00007Q-VM > > for public-egov-ig-request@w3.org; Mon, 15 Nov 2010 23:47:17 > > +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id CB584B9802 > > for <public-egov-ig-request@w3.org>; Mon, 15 Nov 2010 > > 23:46:43 +0000 (GMT) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, > > port 10025) with ESMTP id CBDvO3tL+c3y for > > <public-egov-ig-request@w3.org>; Mon, 15 Nov 2010 23:46:38 > > +0000 (GMT) > >Received: from miranda.g5n.co.uk (unknown [192.168.0.144]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 72BC8B9801 > > for <public-egov-ig-request@w3.org>; Mon, 15 Nov 2010 > > 23:46:38 +0000 (GMT) > >Date: Mon, 15 Nov 2010 23:46:48 +0000 > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-egov-ig-request@w3.org > >Subject: unsubscribe > >Message-ID: <20101115234648.592931ad@miranda.g5n.co.uk> > >X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.9; i586-mandriva-linux-gnu) > >Link: <http://tobyinkster.co.uk/#i>; > >rel="http://xmlns.com/foaf/0.1/maker > > http://purl.org/dc/terms/creator"; > > rev="http://xmlns.com/foaf/0.1/made" > >Mime-Version: 1.0 > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: bart.w3.org 1PI8lW-00007Q-VM > >d53b6e094ba8f1b78eca3551de7ee6a5 > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101117015455.4f8a2385%40miranda.g5n.co.uk Re: CONFIRM u784515111 2010-11-17T01:54:55 2010-11-17T01:54:55 2010-11-17T01:54:55 On Mon, 15 Nov 2010 23:44:21 +0000 public-rdb2rdf-wg-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > should be deleted from the public-rdb2rdf-wg mailing list. > > It has NOT yet been unsubscribed from the list. > To unsubscribe you need to confirm the unsubscription > request by sending an email to the address: > > public-rdb2rdf... On Mon, 15 Nov 2010 23:44:21 +0000 public-rdb2rdf-wg-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > should be deleted from the public-rdb2rdf-wg mailing list. > > It has NOT yet been unsubscribed from the list. > To unsubscribe you need to confirm the unsubscription > request by sending an email to the address: > > public-rdb2rdf-wg-request@w3.org > > with the Subject string: > > CONFIRM u784515111 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm > string has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed > above will be (un)subscribed. If the address above is incorrect, > please do not send the confirmation message listed above. Instead, > send a new (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event > that you did not send a request to (un)subscribe, the headers of the > message may help you discover who sent the request. > > > >From tai@g5n.co.uk Mon Nov 15 23:44:21 2010 > >Received: from bart.w3.org ([128.30.52.63]) > > by frink.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1PI8ij-0003vZ-B2 > > for public-rdb2rdf-wg-request@listhub.w3.org; Mon, 15 Nov > > 2010 23:44:21 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by bart.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1PI8ih-0007Oa-As > > for public-rdb2rdf-wg-request@w3.org; Mon, 15 Nov 2010 > > 23:44:21 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 5E85AB9802 > > for <public-rdb2rdf-wg-request@w3.org>; Mon, 15 Nov 2010 > > 23:43:47 +0000 (GMT) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, > > port 10025) with ESMTP id zU3jCB-KNQCw for > > <public-rdb2rdf-wg-request@w3.org>; Mon, 15 Nov 2010 > > 23:43:41 +0000 (GMT) > >Received: from miranda.g5n.co.uk (unknown [192.168.0.144]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 3FADAB9801 > > for <public-rdb2rdf-wg-request@w3.org>; Mon, 15 Nov 2010 > > 23:43:40 +0000 (GMT) > >Date: Mon, 15 Nov 2010 23:43:50 +0000 > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-rdb2rdf-wg-request@w3.org > >Subject: unsubscribe > >Message-ID: <20101115234350.584527cc@miranda.g5n.co.uk> > >X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.9; i586-mandriva-linux-gnu) > >Link: <http://tobyinkster.co.uk/#i>; > >rel="http://xmlns.com/foaf/0.1/maker > > http://purl.org/dc/terms/creator"; > > rev="http://xmlns.com/foaf/0.1/made" > >Mime-Version: 1.0 > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: bart.w3.org 1PI8ih-0007Oa-As > >918098254fc2f573fdf780dd2c9ada71 > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101120191331.343f64f7%40miranda.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-11-20T19:13:31 2010-11-20T19:13:31 2010-11-20T19:13:31 On Sat, 20 Nov 2010 18:28:24 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > 1. Would each 'location' be a document or a resource? Web of > Documents vs Web of Resources? > > 2. Could we use foaf:image and dcterms:desc for the game pages? > > 3. How would you model the link on each page? Sounds like a pretty awesome idea. I'd personally model it like this: <#node1> a game:Nod... On Sat, 20 Nov 2010 18:28:24 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > 1. Would each 'location' be a document or a resource? Web of > Documents vs Web of Resources? > > 2. Could we use foaf:image and dcterms:desc for the game pages? > > 3. How would you model the link on each page? Sounds like a pretty awesome idea. I'd personally model it like this: <#node1> a game:Node ; foaf:name "Dark Cave" ; foaf:depiction <...> ; dcterms:description "..." . I'd say that game:Node is not disjoint with foaf:Document. That gives you flexibility - in some cases a node might be a page, and in other cases you might have several nodes described on the same page. Links to other places could be accomplished using: <#node1> game:north <#node2> ; game:south <otherdoc.xhtml#wasteland> ; game:east <http://example.net/game#node9> . The description itself would have more detailed descriptions of the directions like "To the south lies a desolate wasteland.". Directions you'd want would probably be eight compass, points plus "up", "down", "inside", "outside". Each node should probably also have co-ordinates (not in WGS84, but a made-up co-ordinate system), along the lines of: <#node1> game:latitude 123 ; game:longitude -45 . This would not be used for gameplay, but to aid authoring new nodes. You'd want to have your "north" triple link to a node that you could plausibly reach by going a short distance north. > I'm not sure how the rendering would work, but perhaps it's easy > enough in RDFa once we have a model. I'd be happy to mock-up an interface - perhaps tonight! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101120234318.6863ce3d%40miranda.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-11-20T23:43:18 2010-11-20T23:43:18 2010-11-20T23:43:18 On Sat, 20 Nov 2010 19:13:31 +0000 Toby Inkster <tai@g5n.co.uk> wrote: > I'd be happy to mock-up an interface - perhaps tonight! Here are a few test nodes: http://buzzword.org.uk/2010/game/test-nodes/london http://buzzword.org.uk/2010/game/test-nodes/birmingham http://buzzword.org.uk/2010/game/test-nodes/brighton http://buzzword.org.uk/2010/game/test-nodes/hove The vocab they use is: http://p... On Sat, 20 Nov 2010 19:13:31 +0000 Toby Inkster <tai@g5n.co.uk> wrote: > I'd be happy to mock-up an interface - perhaps tonight! Here are a few test nodes: http://buzzword.org.uk/2010/game/test-nodes/london http://buzzword.org.uk/2010/game/test-nodes/birmingham http://buzzword.org.uk/2010/game/test-nodes/brighton http://buzzword.org.uk/2010/game/test-nodes/hove The vocab they use is: http://purl.org/NET/game# I've put together a little web-based client you can use to "play" the game here: http://buzzword.org.uk/2010/game/client/?Node=http%3A%2F%2Fbuzzword.org.uk%2F2010%2Fgame%2Ftest-nodes%2Flondon Source code is here: http://buzzword.org.uk/2010/game/client/source-code As you should be able to see from the source, while the four test nodes only link to each other, they could theoretically link to nodes elsewhere on the Web, and the client would follow the links happily. Melvster wrote: > However most book based text games will have a description added to > each link, rather than simply directions to travel. The way I've written this client, the nodes themselves can extend the pre-defined link directions: <#node1> <#hide-under-rug> <#node2> . <#hide-under-rug> rdfs:label "hide under the rug" ; rdfs:subPropertyOf game:exit . The client will notice you've defined a custom direction, and offer it as an option. One possible addition, that would go way beyond what the CYOA books could offer would be for the client to have a stateful store. So when you entered a room, there could be a list of room contents which you could collect into your store. The objects that you've collected could then influence the progress of the game. Probably need to think a bit more about how this should work. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101121165601.5f3258f6%40miranda.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-11-21T16:56:01 2010-11-21T16:56:01 2010-11-21T16:56:01 On Sun, 21 Nov 2010 15:05:12 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > The way I've written this client, the nodes themselves can extend > > the pre-defined link directions: > > > >        <#node1> <#hide-under-rug> <#node2> . > > > >        <#hide-under-rug> > >                rdfs:label "hide under the rug" ; > >                rdfs:subPropertyOf game:exit . > > I do like the... On Sun, 21 Nov 2010 15:05:12 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > The way I've written this client, the nodes themselves can extend > > the pre-defined link directions: > > > >        <#node1> <#hide-under-rug> <#node2> . > > > >        <#hide-under-rug> > >                rdfs:label "hide under the rug" ; > >                rdfs:subPropertyOf game:exit . > > I do like the exits, and think they are all useful and needed. > > However, just thinking that this might not be ideal for scaling wrt > CYOA. Every game choice would have to be added to the ontology if we > used exclusively this technique. Not at all - the <#hide-under-rug> predicate above is not part of the vocabulary at <http://purl.org/NET/game> - it's been defined in the same file as <#node1> and <#node2>. That seems to be a pretty scalable/ distributed way of doing things. <http://purl.org/NET/game> itself doesn't need to define the exit predicates like north, south, etc - it could rely on them to be defined externally, in the same files as the nodes. But for convenience, it predefines a few common exit points. > Forgive my dropping into the conversation to be critical, but in > <#node1> <#hide-under-rug> <#node2> . > #hide-under-rug does not seem like a predicate defining the > relationship between two nodes. "hide under rug" is not a relationship, no - it's an action. But <#hide-under-rug> is a relationship because that's the way I've defined it. Specifically it's the relationship between two nodes such that the object node is the node that would be reached by hiding under the rug when the player's current node is the subject node. The fact that this relationship's URI's fragment ID reads a bit like an action is of no consequence - URIs are opaque. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101121171252.42e6eac2%40miranda.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-11-21T17:12:52 2010-11-21T17:12:52 2010-11-21T17:12:52 On Sun, 21 Nov 2010 20:43:34 +0800 Joshua Shinavier <josh@fortytwo.net> wrote: > 1) a "node" should not be *only* a location, but should also include a > game-specific context. E.g. instead of a node for "London", have a > node for "running from zombies in London", with a geo:location link to > the DBpedia resource for London. Yep, that's certainly the idea. A node is equivalent to a page in the... On Sun, 21 Nov 2010 20:43:34 +0800 Joshua Shinavier <josh@fortytwo.net> wrote: > 1) a "node" should not be *only* a location, but should also include a > game-specific context. E.g. instead of a node for "London", have a > node for "running from zombies in London", with a geo:location link to > the DBpedia resource for London. Yep, that's certainly the idea. A node is equivalent to a page in the CYOA books; not just a physical location. A node may in fact describe a long journey and so describe many locations. The fact that my test nodes correspond with locations is entirely a consequence of the lack of effort and imagination I put into them. > 2) give nodes opaque URIs, so that if you're "playing" the game in a > generic browser like Tabulator which reveals the URIs, it doesn't ruin > the surprise. E.g. <node2> instead of <eaten-by-a-grue>. For the same > reason, it might be best to have one node per document, rather than > several nodes in the same document Certainly - you don't want to give away a surprise twist in a URI. But also maybe the game client could help obfuscate the node URIs a little. e.g. instead of ?Node=<uri> use ?Node=<base64-uri> in links. > Here's the beginning of a game which links (by way of another node) > into Toby's examples: > > http://fortytwo.net/2010/11/game/wowbagger1 Yay! -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101121191035.707ae725%40miranda.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-11-21T19:10:35 2010-11-21T19:10:35 2010-11-21T19:10:35 On Sat, 20 Nov 2010 23:43:18 +0000 Toby Inkster <tai@g5n.co.uk> wrote: > One possible addition, that would go way beyond what the CYOA books > could offer would be for the client to have a stateful store. So when > you entered a room, there could be a list of room contents which you > could collect into your store. The objects that you've collected could > then influence the progress of the game.... On Sat, 20 Nov 2010 23:43:18 +0000 Toby Inkster <tai@g5n.co.uk> wrote: > One possible addition, that would go way beyond what the CYOA books > could offer would be for the client to have a stateful store. So when > you entered a room, there could be a list of room contents which you > could collect into your store. The objects that you've collected could > then influence the progress of the game. Probably need to think a bit > more about how this should work. After further thought, this could/should probably be implemented as a second layer, above the linked data game. A stateful endpoint would exist which would be a quad store. When you began a game, a graph would be created in that store representing your game - this could be multi-player. The graph would be prepopulated with triples along the lines of: <#object13> game:location <#node12> . At each node, you'd query this endpoint to find what objects exist (and thus can be collected) at that node. When collecting an object you'd send an update to the endpoint to remove the triple: <#object13> game:location <#node12> . And add: <#object13> game:carrier <#player3> . When dropping an object you'd do the inverse. The question though is: how far would we want to go to prevent cheating? For a single-player game, there's probably no reason to worry about cheating ("you're only cheating yourself"). For multi-player, while (in my current model) the client software can pretty easily prevent cheating, the server software cannot. Do we add lots of crypto, or do we rely on trust? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101121231422.0ff2f266%40miranda.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-11-21T23:14:22 2010-11-21T23:14:22 2010-11-21T23:14:22 On Sun, 21 Nov 2010 21:24:22 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > Im also looking for a CYOA game that has the data available. http://outer-court.com/goodies/madv.htm http://jerz.setonhill.edu/if/crowther/ Aside: this is quite a cool article - http://samizdat.cc/cyoa/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 21 Nov 2010 21:24:22 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > Im also looking for a CYOA game that has the data available. http://outer-court.com/goodies/madv.htm http://jerz.setonhill.edu/if/crowther/ Aside: this is quite a cool article - http://samizdat.cc/cyoa/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101122022410.684907cd%40miranda.g5n.co.uk The HTML 4.01 + RDFa 1.1 DTD 2010-11-22T02:24:10 2010-11-22T02:24:10 2010-11-22T02:24:10 http://dev.w3.org/html5/rdfa/#the-html-4.01---rdfa-1.1-dtd The DTD RDFa attributes on the following elements non-conforming: BDO BASEFONT FONT BR FRAMESET FRAME (except @src) IFRAME (except @src) ISINDEX BASE (except @href) STYLE SCRIPT (except @src) Is this intentional? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://dev.w3.org/html5/rdfa/#the-html-4.01---rdfa-1.1-dtd The DTD RDFa attributes on the following elements non-conforming: BDO BASEFONT FONT BR FRAMESET FRAME (except @src) IFRAME (except @src) ISINDEX BASE (except @href) STYLE SCRIPT (except @src) Is this intentional? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101124224453.6546d2ca%40miranda.g5n.co.uk Re: Failed to port datastore to RDF, will go Mongo 2010-11-24T22:44:53 2010-11-24T22:44:53 2010-11-24T22:44:53 On Wed, 24 Nov 2010 18:12:50 +0000 Ben O'Steen <bosteen@gmail.com> wrote: > That's not the point that is being made. A competent developer, using > all the available links and documentation, spending days researching > and learning and trying to implement, is unable to make an app using a > triplestore that is on a par with one they can create very quickly > using a relational database. Or, to p... On Wed, 24 Nov 2010 18:12:50 +0000 Ben O'Steen <bosteen@gmail.com> wrote: > That's not the point that is being made. A competent developer, using > all the available links and documentation, spending days researching > and learning and trying to implement, is unable to make an app using a > triplestore that is on a par with one they can create very quickly > using a relational database. Or, to put a different slant on it: a competent developer who has spent years using SQL databases day-to-day finds it easier to use SQL and the relational data model than a different data model and different query language that he's spent a few days trying out. It's not surprising. I often find it difficult to code things in Python and end up switching to Perl. Why? Is it because Perl's an inherently easier language? Or is it because Perl has been one of my main development tools for the best part of a decade whereas I dig out Python only occasionally. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101125185444.0dc9c8be%40miranda.g5n.co.uk Re: microformat for turtle? 2010-11-25T18:54:44 2010-11-25T18:54:44 2010-11-25T18:54:44 On Thu, 25 Nov 2010 16:51:39 +0000 Nathan <nathan@webr3.org> wrote: > You can pretty much already do this unambiguously in a nice way by > leveraging the <script> element <> rdfs:seeAlso <http://esw.w3.org/N3inHTML> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 25 Nov 2010 16:51:39 +0000 Nathan <nathan@webr3.org> wrote: > You can pretty much already do this unambiguously in a nice way by > leveraging the <script> element <> rdfs:seeAlso <http://esw.w3.org/N3inHTML> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101125192716.66dbcee9%40miranda.g5n.co.uk Re: microformat for turtle? 2010-11-25T19:27:16 2010-11-25T19:27:16 2010-11-25T19:27:16 On Thu, 25 Nov 2010 19:02:31 +0000 Nathan <nathan@webr3.org> wrote: > Toby, why CDATA? for XHTML only ya? N3inHTML works for either XHTML or HTML. The examples shown on the wiki page just happen to all be XHTML examples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Thu, 25 Nov 2010 19:02:31 +0000 Nathan <nathan@webr3.org> wrote: > Toby, why CDATA? for XHTML only ya? N3inHTML works for either XHTML or HTML. The examples shown on the wiki page just happen to all be XHTML examples. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101128232759.769a4793%40miranda.g5n.co.uk Re: Is 303 really necessary? 2010-11-28T23:27:59 2010-11-28T23:27:59 2010-11-28T23:27:59 On Sun, 28 Nov 2010 14:52:21 +0100 Giovanni Tummarello <giovanni.tummarello@deri.org> wrote: > is clearly a web page but its also an actor, it is pointed by their > graph in other pages as such and the same page contains the opengraph > triple "type" "actor" That's consistent with the definition of the og:type property. og:type is roughly equivalent to the following property chain in N3: foaf... On Sun, 28 Nov 2010 14:52:21 +0100 Giovanni Tummarello <giovanni.tummarello@deri.org> wrote: > is clearly a web page but its also an actor, it is pointed by their > graph in other pages as such and the same page contains the opengraph > triple "type" "actor" That's consistent with the definition of the og:type property. og:type is roughly equivalent to the following property chain in N3: foaf:primaryTopic!rdf:type!rdfs:label So if a page contains: <> og:type "actor" . That's equivalent to: <> foaf:primaryTopic [ a [ rdfs:label "actor" ] ] . This is similar in spirit to foaf:workplaceHomepage which could be written as a chain of ex:workplace!foaf:homepage. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101130110518.5537dae6%40miranda.g5n.co.uk Re: suggestion for abolition of <hgroup> 2010-11-30T11:05:18 2010-11-30T11:05:18 2010-11-30T11:05:18 On Tue, 30 Nov 2010 08:04:48 +0800 "Bruce Lawson" <brucel@opera.com> wrote: > <h1>brucelawson.co.uk</h1> > <h2>Gorgeousness in a gimp mask</h2> Personally, I've always liked: <h1> <span>brucelawson.co.uk</span><br> <small>Gorgeousness in a gimp mask</small> </h1> The span element is semantically redundant but can be useful for styling. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 30 Nov 2010 08:04:48 +0800 "Bruce Lawson" <brucel@opera.com> wrote: > <h1>brucelawson.co.uk</h1> > <h2>Gorgeousness in a gimp mask</h2> Personally, I've always liked: <h1> <span>brucelawson.co.uk</span><br> <small>Gorgeousness in a gimp mask</small> </h1> The span element is semantically redundant but can be useful for styling. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101130124335.63e63632%40miranda.g5n.co.uk subscribe 2010-11-30T12:43:35 2010-11-30T12:43:35 2010-11-30T12:43:35 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101130125114.06e56220%40miranda.g5n.co.uk Re: CONFIRM s2833829433 2010-11-30T12:51:14 2010-11-30T12:51:14 2010-11-30T12:51:14 On Tue, 30 Nov 2010 12:44:15 +0000 public-cwm-talk-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-cwm-talk mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-cwm-talk-requ... On Tue, 30 Nov 2010 12:44:15 +0000 public-cwm-talk-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-cwm-talk mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-cwm-talk-request@w3.org > > with the Subject string: > > CONFIRM s2833829433 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm > string has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed > above will be (un)subscribed. If the address above is incorrect, > please do not send the confirmation message listed above. Instead, > send a new (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event > that you did not send a request to (un)subscribe, the headers of the > message may help you discover who sent the request. > > > >From tai@g5n.co.uk Tue Nov 30 12:44:15 2010 > >Received: from bart.w3.org ([128.30.52.63]) > > by frink.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1PNPZ9-0007eI-AU > > for public-cwm-talk-request@listhub.w3.org; Tue, 30 Nov 2010 > > 12:44:15 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by bart.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1PNPZ6-0005G0-9m > > for public-cwm-talk-request@w3.org; Tue, 30 Nov 2010 > > 12:44:15 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 630FFB9802 > > for <public-cwm-talk-request@w3.org>; Tue, 30 Nov 2010 > > 12:43:40 +0000 (GMT) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, > > port 10025) with ESMTP id rpJWUQz9crWW for > > <public-cwm-talk-request@w3.org>; Tue, 30 Nov 2010 12:43:36 > > +0000 (GMT) > >Received: from miranda.g5n.co.uk (unknown [192.168.229.18]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id 9C00AB9801 > > for <public-cwm-talk-request@w3.org>; Tue, 30 Nov 2010 > > 12:43:36 +0000 (GMT) > >Date: Tue, 30 Nov 2010 12:43:35 +0000 > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-cwm-talk-request@w3.org > >Subject: subscribe > >Message-ID: <20101130124335.63e63632@miranda.g5n.co.uk> > >X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.9; i586-mandriva-linux-gnu) > >Link: <http://tobyinkster.co.uk/#i>; > >rel="http://xmlns.com/foaf/0.1/maker > > http://purl.org/dc/terms/creator"; > > rev="http://xmlns.com/foaf/0.1/made" > >Mime-Version: 1.0 > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: bart.w3.org 1PNPZ6-0005G0-9m > >fb5ba6c57136e55db72986761442e847 > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1291201961.32297.20.camel%40ophelia2.g5n.co.uk Re: Error in the XHTML Profile 2010-12-01T11:12:44 2010-12-01T11:12:44 2010-12-01T11:12:44 On Wed, 2010-12-01 at 11:02 +0100, Ivan Herman wrote: > Victor Andrée (cc-d) contacted me a few days ago because he found some > bug in my newest pyRdfa code. However... one issue was not my bug but > yours:-) I volunteered to rewrite the XHTML vocab a few months ago. My rewrite is here: http://buzzword.org.uk/2010/xhtml-vocab-20101110.xhtml It still needs a few changes I think: * We should di... On Wed, 2010-12-01 at 11:02 +0100, Ivan Herman wrote: > Victor Andrée (cc-d) contacted me a few days ago because he found some > bug in my newest pyRdfa code. However... one issue was not my bug but > yours:-) I volunteered to rewrite the XHTML vocab a few months ago. My rewrite is here: http://buzzword.org.uk/2010/xhtml-vocab-20101110.xhtml It still needs a few changes I think: * We should discuss whether to include "describedby" in the profile mapping to <http://www.w3.org/2007/05/powder-s#describedby>. This relationship is used by POWDER and XRD/WebFinger, so it might be nice to adopt it. We should have a resolution to adopt it or not. * We should adopt a revision policy for the document. I'd suggest a policy of: new terms are added via W3C Recs. A mailing list is provided for the announcement of new terms. New terms must be announced on that list either three months before they're added to the vocab, or when the spec defining them hits Last Call - whichever comes first! This allows the vocab to change over time, but also gives implementers reasonable security in hard-coding or aggressively caching the vocab. * The information above the Introduction section needs revising in that the XHTML2 Working Group is ceasing to exist within the W3C. But once those issues are resolved, it would be nice to publish the updated vocabulary document. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101202001339.57eb087a%40miranda.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-12-02T00:13:39 2010-12-02T00:13:39 2010-12-02T00:13:39 On Wed, 1 Dec 2010 23:06:42 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > I think the next thing I need to model is 'items'. > > At present need to work out a way to say a location has an item. Perhaps model it the other direction? <item22> game:initial_position <node394> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 1 Dec 2010 23:06:42 +0100 Melvin Carvalho <melvincarvalho@gmail.com> wrote: > I think the next thing I need to model is 'items'. > > At present need to work out a way to say a location has an item. Perhaps model it the other direction? <item22> game:initial_position <node394> . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101202001644.4af7d709%40miranda.g5n.co.uk Re: order within a @prefix 2010-12-02T00:16:44 2010-12-02T00:16:44 2010-12-02T00:16:44 On Wed, 1 Dec 2010 11:21:55 +0100 Ivan Herman <ivan@w3.org> wrote: > @prefix="a: http://a.b a: http://c.d" > > will end in a->http://c.d > > However, I tried to locate this in the document and I could not... That's what I do, but I agree we need to make this explicit as it's a case that implementors will definitely need to handle. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 1 Dec 2010 11:21:55 +0100 Ivan Herman <ivan@w3.org> wrote: > @prefix="a: http://a.b a: http://c.d" > > will end in a->http://c.d > > However, I tried to locate this in the document and I could not... That's what I do, but I agree we need to make this explicit as it's a case that implementors will definitely need to handle. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101202192328.0a1c81c5%40miranda.g5n.co.uk Case-insensitivity of terms 2010-12-02T19:23:28 2010-12-02T19:23:28 2010-12-02T19:23:28 Re-raising this as a last call comment for RDFa Core so that it doesn't get lost... Example 2 in this message - http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0269.html The issue that a profile can define both these terms: agent Agent to map to different URIs, but while typeof="agent" and typeof="Agent" are clear and unambiguous, typeof="agENT" is not. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> Re-raising this as a last call comment for RDFa Core so that it doesn't get lost... Example 2 in this message - http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0269.html The issue that a profile can define both these terms: agent Agent to map to different URIs, but while typeof="agent" and typeof="Agent" are clear and unambiguous, typeof="agENT" is not. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101202204022.104bde72%40miranda.g5n.co.uk Re: Case-insensitivity of terms 2010-12-02T20:40:22 2010-12-02T20:40:22 2010-12-02T20:40:22 On Thu, 02 Dec 2010 15:11:37 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > Didn't we address this issue with the following text: > > http://www.w3.org/TR/2010/WD-rdfa-core-20101026/#s_terms > > """ > Check if the term matches an item in the list of local term mappings. > First compare against the list case-sensitively, and if there is no > match then compare case-insensitively. If ther... On Thu, 02 Dec 2010 15:11:37 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > Didn't we address this issue with the following text: > > http://www.w3.org/TR/2010/WD-rdfa-core-20101026/#s_terms > > """ > Check if the term matches an item in the list of local term mappings. > First compare against the list case-sensitively, and if there is no > match then compare case-insensitively. If there is a match, use the > associated URI. > """ No, that doesn't address the issue. It was that resolution that *caused* the issue. > ... or are you saying that it is indeterminate which term mapping will > be picked? Precisely. Neither "Agent" nor "agent" matches case-sensitively, so case-insensitive matching occurs - and then *both* match. Gregg proposes a solution here: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0272.html That would work, though I fear it may be confusing to explain to document authors. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101204082734.72c37426%40miranda.g5n.co.uk Re: Any reason for ontology reuse? 2010-12-04T08:27:34 2010-12-04T08:27:34 2010-12-04T08:27:34 On Fri, 3 Dec 2010 18:15:08 -0200 Percy Enrique Rivera Salas <privera.salas@gmail.com> wrote: > I would like to know, which are the specific reason(s), > for reuse terms from well-known vocabularies in the process of Publish > Linked Data on the Web? Consider this question: I would like to know, which are the specific reason(s) for reusing well-known words in the process of publishing English te... On Fri, 3 Dec 2010 18:15:08 -0200 Percy Enrique Rivera Salas <privera.salas@gmail.com> wrote: > I would like to know, which are the specific reason(s), > for reuse terms from well-known vocabularies in the process of Publish > Linked Data on the Web? Consider this question: I would like to know, which are the specific reason(s) for reusing well-known words in the process of publishing English text on the Web? Answer: When you're writing something in English, you should avoid inventing new words unless you're fairly sure that a word for the concept you're trying to describe does not exist. This is because if you invent a new word, you need to describe what it means for other people to be able to understand you. And even when you do that, you've increased the cognitive load for your readers. URIs are the vocabulary of linked data, just like words are the vocabulary of the English language. For analogous reasons, you should avoid minting new URIs when an existing URI will do. If you mint a new URI that means the same as an existing one, then not only do you have to go to the effort of documenting its meaning, but consumers have to perform extra work (such as subproperty/subclass inferencing) to understand it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101208161329.21b20d98%40miranda.g5n.co.uk Re: Media Capture 2010-12-08T16:13:29 2010-12-08T16:13:29 2010-12-08T16:13:29 On Wed, 8 Dec 2010 15:56:38 +0100 Robin Berjon <robin@berjon.com> wrote: > Since then, the DAP WG has been editing a simple draft[1] matching > the discussion, as planned. There is, however, some hesitation on one > crucial, if somewhat bikeshed-shaped, point: syntax. Opening another pot of paint, have you considered using the role attribute which is already part of HTML5, also defined as an XH... On Wed, 8 Dec 2010 15:56:38 +0100 Robin Berjon <robin@berjon.com> wrote: > Since then, the DAP WG has been editing a simple draft[1] matching > the discussion, as planned. There is, however, some hesitation on one > crucial, if somewhat bikeshed-shaped, point: syntax. Opening another pot of paint, have you considered using the role attribute which is already part of HTML5, also defined as an XHTML 1.1 module, and has a mapping to RDF? Something like: <input type="file" name="motion-mugshot" accept="video/ogg" role="capture-audio capture-video"> DAP would define a set of (case-insensitive) terms that can appear in the role attribute. Implementations can experiment by using full (case-sensitive) URIs to identify their oddball capture devices: <input type="file" name="motion-mugshot" accept="video/ogg" role="capture-audio http://example.com/smellyvision"> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101208161957.21347b58%40miranda.g5n.co.uk Re: Media Capture 2010-12-08T16:19:57 2010-12-08T16:19:57 2010-12-08T16:19:57 On Wed, 8 Dec 2010 17:07:46 +0100 Robin Berjon <robin@berjon.com> wrote: > The argument that there is a potential clash is certainly acceptable. > I wonder if one potential work around is to only accept the capture > parameter on {audio,video,image}/*. (Just a thought.) I think you could meaningfully capture text/plain from a microphone using speech recognition software. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 8 Dec 2010 17:07:46 +0100 Robin Berjon <robin@berjon.com> wrote: > The argument that there is a potential clash is certainly acceptable. > I wonder if one potential work around is to only accept the capture > parameter on {audio,video,image}/*. (Just a thought.) I think you could meaningfully capture text/plain from a microphone using speech recognition software. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101208162345.51fa0884%40miranda.g5n.co.uk Re: proposal: drop bugzilla@jessica.w3.org emails from public-html human lists 2010-12-08T16:23:45 2010-12-08T16:23:45 2010-12-08T16:23:45 On Mon, 6 Dec 2010 14:09:55 -0500 Aryeh Gregor <Simetrical+w3c@gmail.com> wrote: > Mailing lists are also annoying because you can't access the history > after joining in the same way as you can access the history since you > joined. A lot of mailing list software (including W3C lists) make mbox archives available - usually in monthly or quarterly format. These can be imported into many e-mail clients. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 6 Dec 2010 14:09:55 -0500 Aryeh Gregor <Simetrical+w3c@gmail.com> wrote: > Mailing lists are also annoying because you can't access the history > after joining in the same way as you can access the history since you > joined. A lot of mailing list software (including W3C lists) make mbox archives available - usually in monthly or quarterly format. These can be imported into many e-mail clients. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101209001325.6694963e%40miranda.g5n.co.uk Re: proposal: drop bugzilla@jessica.w3.org emails from public-html human lists 2010-12-09T00:13:25 2010-12-09T00:13:25 2010-12-09T00:13:25 On Wed, 8 Dec 2010 12:00:36 -0500 Karl Dubost <karld@opera.com> wrote: > I prefer mails to bugzilla, but the mbox archives are available only > to people with Member access I think > http://lists.w3.org/Archives/Public/public-html/mboxes/ You do need a W3C login, but don't need to be a W3C Member. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 8 Dec 2010 12:00:36 -0500 Karl Dubost <karld@opera.com> wrote: > I prefer mails to bugzilla, but the mbox archives are available only > to people with Member access I think > http://lists.w3.org/Archives/Public/public-html/mboxes/ You do need a W3C login, but don't need to be a W3C Member. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101209001821.1fe146b2%40miranda.g5n.co.uk Re: ISSUE-67 (Core - Henri Sivonen): RDFa Core 1.1 LC comments from Henri Sivonen [LC Comment - RDFa Core 1.1] 2010-12-09T00:18:21 2010-12-09T00:18:21 2010-12-09T00:18:21 On Tue, 07 Dec 2010 15:25:53 +0000 RDFa Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: > ISSUE-67 (Core - Henri Sivonen): RDFa Core 1.1 LC comments from Henri > Sivonen [LC Comment - RDFa Core 1.1] This does not constitute an official WG reply, but just a few of my jumbled thoughts... > To be Compatible with Existing Content, RDFa 1.1 doesn't need to be > backwards compatible in the... On Tue, 07 Dec 2010 15:25:53 +0000 RDFa Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: > ISSUE-67 (Core - Henri Sivonen): RDFa Core 1.1 LC comments from Henri > Sivonen [LC Comment - RDFa Core 1.1] This does not constitute an official WG reply, but just a few of my jumbled thoughts... > To be Compatible with Existing Content, RDFa 1.1 doesn't need to be > backwards compatible in the sense of parsing the same triples out of > any valid RDFa 1.0 input as RDFa 1.0. Instead, it needs only to > produce the right triples for the content that's already out there. > Thus, Compatibility with Existing Content could be mostly achieved by > performing by hard-coding the meanings of the common prefixes used in > deployed content that purports to use RDFa. While I can see the advantages of this, I do not think this would work. There are plenty of CURIE prefixes which are customarily used as abbreviations for different URI prefixes. While many of them might only occur in very small sets of existing RDFa content, two spring to mind that seem very common: * "dc" which sometimes refers to http://purl.org/dc/elements/1.1/ and at other times http://purl.org/dc/terms/. (Occasionally also the /1.0/ version but that is vanishingly rare.) While both are versions of the same vocabulary, the differences between them were considered great enough to assign them different URIs. Conflating the two could cause potential harm. * "v" is often used to refer to the W3C's vCard vocab, but also to Google's Rich Snippets vocab. There is a small overlap between these two, but they're substantially different. > * It seems questionable that formsplayer.com (site of a product that > one of the Editors has a commercial interest in) is used in an > example. Agreed. I imagine that this was just copied and pasted from an example in one of the tutorials or demonstrations Mark has published, but it doesn't look good to be in the spec. > * The Creative Commons license example in section 2.2 uses the > anti-pattern of saying "a Creative Commons license" (instead of > saying which one of the numerous licenses) in the human-readable > prose. +1 > * I reiterate my previous comment that prefix-based indirection > confuses authors and complicates implementation. Please use absolute > URLs only instead of CURIEs. I'm not going to elaborate on this > point, because I realize that the WG isn't going to change this. I disagree that this is inherently confusing for authors. In other technologies indirection (not prefix-based I grant you) is positively encouraged. Authors for example are typically advised to use: <style type="text/css"> .important { color: red; } </style> <span class="important">Red!</span> Rather than: <span style="color:red">Red</span> The latter is simpler for new authors to grok - they don't have to learn about the tangled webs of CSS inheritance (which changed BTW between CSS 1 and 2). But the former does end up as a more flexible and efficient way of working once you're used to it. Something I think we should consider is moving the full URI example to before the CURIE examples in section 2 - right now CURIEs are shown first. That would make it clearer that CURIEs are just syntactic sugar, and not meaningful in their own right. > * Loading prefix definitions from an external file seems to make > RDFa brittle in case the external file can't be loaded. Also, > blocking RDFa processing in order to do IO to fetch the prefix > definitions complicates implementation. My initial stance on external profiles was much the same. And I agree that these are valid concerns. I was swayed by the rest of the WG though - profiles do seem overall beneficial for RDFa, even if they do have their downsides. Performance problems can be offset by performing profile fetches in parallel with each other where multiples are provided on a single element, and by using in-memory caches of profiles, and even hard-coding common ones. In my own RDFa parser I've not noticed significant performance issues for those profiles I've hard-coded. As far as brittleness is concerned, while in theory I'm with you, in practice the web relies on linking to external data sources all over the place. If a flickr page was marked up in RDFa using a profile, we should probably be more concerned over the brittleness of <img src> than we should over the brittleness of the RDFa profile. It may be useful to add an informative note though that people who are more than averagely concerned about the longevity of their data may wish to avoid using profiles. > * (This is a general RDF problem but...) It seems author-hostile to > require authors to specify the datatype of e.g. date literals instead > of making the datatype of a property a characteristic of the property > in the vocabulary/ontology. This is a problem to be addressed at a different level of the RDF stack. Rumour has it that a new RDF Working Group will be formed, so you could try addressing this concern to them. There are already solutions for this using RIF, but that's a rather heavy-weight solution to a simple problem. > * It seems unfortunate to use XML Schema Datatype as an example > considering how much weird variability XML Schema Datatypes allow. xsd datatypes are incredibly commonly used in practise though. In much RDF data, those (and rdf:XMLLiteral) will be the only datatypes you see. > * Under 4.1 the statement about whitespace seems to say that authors > should assume non-conforming processors. Hmmm... I hadn't noticed this paragraph before. Does anyone have any specific examples to justify this? "However, it may be the case that the architecture in which a processor operates does not make all white space available." > * xmlns:prefix is marked as an optional feature. Please remove the > feature altogether, because xmlns:prefix parses differently in > text/html and application/xhtml+xml which are the media types most > likely to be used to transfer RDFa. I've not heard of anyone else who has found this feature technically problematic. (It may be tricky in XSLT, but then again, most things are tricky in XSLT.) My RDFa implementation, Ivan's implementation and Damien Steer's (not sure if he subscribes to this list) all make use of HTML5 parsers for text/html content. When I switched to making use of an HTML5 parser I didn't need to change my xmlns-handling code from how it had worked under XHTML. I'm not aware of any problems suffered by Ivan of Damien. Personally I'd categorise any unnecessary differences between HTML and XHTML with regards to how syntax is parsed into a DOM as a bug in HTML5. -1 to removing the feature altogether as we're chartered to maintain compatibility with RDFa 1.0. However I'd be in favour of deprecating it in order to leave a path to an xmlns-free version of RDFa open for a future revision of the spec. > * It's weird that the prefix attribute requires a single space > between the colon following the prefix and the URI but allows > multiple spaces between the URI and the next prefix. This probably needs adjusting slightly. > * If the spec contains rules for how to extract a set of prefix to > URI mappings from the prefix attribute, the rules are hard to locate. We did have a regex for it... why has this not made it into the spec? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1291893109.20693.108.camel%40ophelia2.g5n.co.uk Re: ISSUE-27 Change Proposal: defer to the Microformats community for cataloging HTML rel values 2010-12-09T11:11:53 2010-12-09T11:11:53 2010-12-09T11:11:53 On Wed, 2010-12-08 at 16:49 -0800, Edward O'Connor wrote: > Please consider this Change Proposal when deciding ISSUE-27: > http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-27 A few things to consider: "Reflect reality" You quote a survey by DeWitt Clinton where he finds the top 25 rel values and compare which are currently present in the microformats wiki list, and which are registered with ... On Wed, 2010-12-08 at 16:49 -0800, Edward O'Connor wrote: > Please consider this Change Proposal when deciding ISSUE-27: > http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-27 A few things to consider: "Reflect reality" You quote a survey by DeWitt Clinton where he finds the top 25 rel values and compare which are currently present in the microformats wiki list, and which are registered with IANA, discovering that the microformats wiki comes out very favourably. However, the same survey also notes that the top 11 rel values, between them account for 90% of the use of the rel attribute on the web. Comparing just those first 11 values, you find it comes out as: Microformats wiki: 8; IANA registry: 7. That's a pretty small difference, and I doubt it's statistically significant. This comparison also doesn't reflect the fact that the IANA registry has only been open for a couple of months. The expert review process takes time, and given time the IANA registry is likely to catch up in reflecting reality, and perhaps overtake the microformats wiki. "Must be able to register HTML-specific details" Leif Halvard Sillil might have more to say on this, as I seem to remember he has written on this topic before, but the importance of these HTML-specific details seems overstated. "Provisional registration" While the microformats wiki offers a form of provisional registration, what remains to be seen is whether it offers a route for provisionally registered values to be achieve full registration. While the "microformats process" is frequently cited as such a mechanism, it should be noted that the microformats process has never resulted in a single non-draft microformat being published. All the non-draft microformat specifications currently on the microformats wiki are a result of the bootstrapping process, the specs having been copied across from the Technorati wiki, the GPMG.org website and various other sites many years ago. In the several years since then, no new non-draft specifications have been developed. Compare these two copies of the wiki main page from July 2005 and December 2010: http://microformats.org/wiki/Main_Page?oldid=28922#Specifications http://microformats.org/wiki/Main_Page?oldid=43375#Specifications "Discoverability" Google for "rel registry" and the IANA one comes up as number 4. No microformats.org page is on the first page of Google. These things are organic and change frequently though - the IANA registry has only existed a short while and is likely to move up in search engine results over the coming months and years. "Responses to anticipated objections" Under this section you mention the microformats admins. The process of becoming a microformats admin is opaque and does not appear to follow democratic or indeed easily understood principles. The admin team has frequently been accused of acting as a cabal, e.g. http://microformats.org/discuss/mail/microformats-discuss/2007-August/010377.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1291906575.20693.228.camel%40ophelia2.g5n.co.uk Re: New RDF API and RDFa API Editor's Drafts 2010-12-09T14:56:18 2010-12-09T14:56:18 2010-12-09T14:56:18 On Thu, 2010-12-09 at 00:59 -0500, Manu Sporny wrote: > The RDF API > http://www.w3.org/2010/02/rdfa/sources/rdf-api/ > > The RDFa API > http://www.w3.org/2010/02/rdfa/sources/rdfa-api/ A few comments: Firstly, what's the point of the callback parameter to DataParser.parse(). It seems pretty useless, but it's not optional. If I want "foo" to happen to the graph after parsing is complete, it's ... On Thu, 2010-12-09 at 00:59 -0500, Manu Sporny wrote: > The RDF API > http://www.w3.org/2010/02/rdfa/sources/rdf-api/ > > The RDFa API > http://www.w3.org/2010/02/rdfa/sources/rdfa-api/ A few comments: Firstly, what's the point of the callback parameter to DataParser.parse(). It seems pretty useless, but it's not optional. If I want "foo" to happen to the graph after parsing is complete, it's encouraging me to use: turtle.parse(doc, function(g) { foo(g); }); whereas it seems far more simple and natural to do this: turtle.parse(doc, null, null, null, g); foo(g); Anticipating an answer of "parallel processing", I'll counter with "look at the return value of parse()"! If parse() has to wait to return a success indicator, it can't be processed in parallel with the following code. Unless there's some incredibly good reason to use a callback here that I'm missing, please don't. It just confuses people and will complicate implementation in programming languages that don't treat functions as a first class. Given that (at least in the way it's currently defined) it's pretty esoteric it should be made optional, and placed *after* the other more useful parameters like base, filter and graph in the method's argument list. Secondly, PropertyGroups (which are still an awful name by the way, or are they now Projections?) seem to make a lot more sense as part of the RDF API. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1291973300.20693.239.camel%40ophelia2.g5n.co.uk Re: Possible Idea For a Sem Web Based Game? 2010-12-10T09:28:25 2010-12-10T09:28:25 2010-12-10T09:28:25 On Fri, 2010-12-10 at 02:58 +0100, Melvin Carvalho wrote: > Real world locations might be the way forward. > http://www.youtube.com/watch?v=NMQ5DFkU794 That reminds me - there was an article in the New Scientist a few weeks ago about "newsgames". These are essentially journalism in an alternative media (rather like photo journalism is): telling a news story through a game rather than a tradition... On Fri, 2010-12-10 at 02:58 +0100, Melvin Carvalho wrote: > Real world locations might be the way forward. > http://www.youtube.com/watch?v=NMQ5DFkU794 That reminds me - there was an article in the New Scientist a few weeks ago about "newsgames". These are essentially journalism in an alternative media (rather like photo journalism is): telling a news story through a game rather than a traditional linear narrative. e.g. You are a detainee in Guantanamo Bay and are innocent of the crimes of which you have been accused. Your mission is to get out by any means possible. The point the journalist wants to make is conveyed as the player discovers which, if any, techniques (reasoning, bribery, tunnelling, disguises) are successful, and which result in failure. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101210222930.221d78c0%40miranda.g5n.co.uk Fw: [wbs] response to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' 2010-12-10T22:29:30 2010-12-10T22:29:30 2010-12-10T22:29:30 Begin forwarded message: Date: Thu, 09 Dec 2010 11:48:01 +0000 From: webmaster@w3.org (WBS Mailer on behalf of tai@g5n.co.uk) To: tai@g5n.co.uk,www-archive@w3.org Subject: [wbs] response to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' The following answers have been successfully submitted to 'ISSUE-118 Specification br... Begin forwarded message: Date: Thu, 09 Dec 2010 11:48:01 +0000 From: webmaster@w3.org (WBS Mailer on behalf of tai@g5n.co.uk) To: tai@g5n.co.uk,www-archive@w3.org Subject: [wbs] response to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' The following answers have been successfully submitted to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' (HTML Working Group) for Toby Inkster. --------------------------------- Objections to the Change Proposal to Create a well founded consolidation of the link types ---- We have a Change Proposal to change some link types to their pre-HTML5 meaning, but also change some other link relations to be synonyms and consolidate the set overall. If you have strong objections to adopting this Change Proposal, please state your objections below. Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it. Objections: No objections. --------------------------------- Objections to the Change Proposal to Simplify the incumbent rel="" model ---- We have a Change Proposal to simply some link relations relative to HTML4. If you have strong objections to adopting this Change Proposal, please state your objections below. Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it. Objections: Strong objection. This changes the definitions of rel values (especially rel=index) from HTML4, introducing differences between how it's defined in HTML5 and how it's defined virtually everywhere else (HTML4, XHTML 1.x, RDFa and the IANA link registry). The proposal cites a single implementation as justification for the change. While I grant that this implementation is a major one, given that it's just one implementation, a small patch could bring it into line with the rest of the world. Wordpress has a history of security problems, so many of its users upgrade on a very frequent basis. Thus, if new releases of Wordpress were brought into line with the semantics of other implementations, data published using old releases would quickly diminish to insignificance. Wordpress also has a history of using outputting fairly good, semantically correct HTML. Thus if clear guidelines on which rel values are synonymous, which differ, and how they all should be used were included in the HTML5 specification, such as the guidelines summarised in the first change proposal, it seems likely that Wordpress' developers would be amenable to accepting such a patch. --------------------------------- Objections to the Change Proposal to Drop support for certain rel="" values ---- We have a Change Proposal to drop support for certain rel entirely, based on lack of interest from users and implementors. If you have strong objections to adopting this Change Proposal, please state your objections below. Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it. Objections: Weak objection. These semantics seem useful enough to keep in the specification. These answers were last modified on 9 December 2010 at 11:47:38 U.T.C. by Toby Inkster Answers to this questionnaire can be set and changed at http://www.w3.org/2002/09/wbs/40318/issue-118-objection-poll/ until 2010-12-16. Regards, The Automatic WBS Mailer -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101211113052.085bd4c4%40miranda.g5n.co.uk Fw: [wbs] response to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' 2010-12-11T11:30:52 2010-12-11T11:30:52 2010-12-11T11:30:52 Meant to forward this to public-rdfa-wg rather than public-rdfa... Begin forwarded message: Date: Thu, 09 Dec 2010 11:48:01 +0000 From: webmaster@w3.org (WBS Mailer on behalf of tai@g5n.co.uk) To: tai@g5n.co.uk,www-archive@w3.org Subject: [wbs] response to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' The following answ... Meant to forward this to public-rdfa-wg rather than public-rdfa... Begin forwarded message: Date: Thu, 09 Dec 2010 11:48:01 +0000 From: webmaster@w3.org (WBS Mailer on behalf of tai@g5n.co.uk) To: tai@g5n.co.uk,www-archive@w3.org Subject: [wbs] response to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' The following answers have been successfully submitted to 'ISSUE-118 Specification breaks semantics of existing link relations "index" and "first" - Straw Poll for Objections' (HTML Working Group) for Toby Inkster. --------------------------------- Objections to the Change Proposal to Create a well founded consolidation of the link types ---- We have a Change Proposal to change some link types to their pre-HTML5 meaning, but also change some other link relations to be synonyms and consolidate the set overall. If you have strong objections to adopting this Change Proposal, please state your objections below. Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it. Objections: No objections. --------------------------------- Objections to the Change Proposal to Simplify the incumbent rel="" model ---- We have a Change Proposal to simply some link relations relative to HTML4. If you have strong objections to adopting this Change Proposal, please state your objections below. Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it. Objections: Strong objection. This changes the definitions of rel values (especially rel=index) from HTML4, introducing differences between how it's defined in HTML5 and how it's defined virtually everywhere else (HTML4, XHTML 1.x, RDFa and the IANA link registry). The proposal cites a single implementation as justification for the change. While I grant that this implementation is a major one, given that it's just one implementation, a small patch could bring it into line with the rest of the world. Wordpress has a history of security problems, so many of its users upgrade on a very frequent basis. Thus, if new releases of Wordpress were brought into line with the semantics of other implementations, data published using old releases would quickly diminish to insignificance. Wordpress also has a history of using outputting fairly good, semantically correct HTML. Thus if clear guidelines on which rel values are synonymous, which differ, and how they all should be used were included in the HTML5 specification, such as the guidelines summarised in the first change proposal, it seems likely that Wordpress' developers would be amenable to accepting such a patch. --------------------------------- Objections to the Change Proposal to Drop support for certain rel="" values ---- We have a Change Proposal to drop support for certain rel entirely, based on lack of interest from users and implementors. If you have strong objections to adopting this Change Proposal, please state your objections below. Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it. Objections: Weak objection. These semantics seem useful enough to keep in the specification. These answers were last modified on 9 December 2010 at 11:47:38 U.T.C. by Toby Inkster Answers to this questionnaire can be set and changed at http://www.w3.org/2002/09/wbs/40318/issue-118-objection-poll/ until 2010-12-16. Regards, The Automatic WBS Mailer -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101212091236.20b11b6a%40miranda.g5n.co.uk Re: Mailing list archives and the Semantic Web 2010-12-12T09:12:36 2010-12-12T09:12:36 2010-12-12T09:12:36 On Sat, 11 Dec 2010 10:22:57 +0100 Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote: > Is anybody of you aware of an open-source substitute for MailMan/ > Pipermail that > - allows, at least, adding RDFa to the HTML output of the mail > archive entries, > or, better, > - uses a more comprehensive (e.g. SIOC-based) RDF model in the > background, ideally accessible via SPARQL? I do have a sc... On Sat, 11 Dec 2010 10:22:57 +0100 Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote: > Is anybody of you aware of an open-source substitute for MailMan/ > Pipermail that > - allows, at least, adding RDFa to the HTML output of the mail > archive entries, > or, better, > - uses a more comprehensive (e.g. SIOC-based) RDF model in the > background, ideally accessible via SPARQL? I do have a script somewhere for converting mbox archives to RDF (SIOC, FOAF, DC Terms, etc). I used this to import the entire backhistory of this mailing list, and several other W3C mailing lists, into a Jena SDB store, and then put a demiblog3 <http://demiblog.org/> installation in front of it. While the result was pretty good, it was incredibly slow and CPU-intensive, so it's offline right now. :-( -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101212224656.74937a42%40miranda.g5n.co.uk Re: Last Call comments on RDFa Core 2010-12-12T22:46:56 2010-12-12T22:46:56 2010-12-12T22:46:56 The following is not an official WG response - just my initial thoughts. On Sun, 12 Dec 2010 19:26:17 -0000 (GMT) "Harry Halpin" <hhalpin@w3.org> wrote: > 1) Remove any reference to @href and @src to the XHTML and HTML5 > documents about using RDFa. They do not really make sense in the > core, as the are obviously specialized for use in making RDFa easier > to use with a certain number of HTML e... The following is not an official WG response - just my initial thoughts. On Sun, 12 Dec 2010 19:26:17 -0000 (GMT) "Harry Halpin" <hhalpin@w3.org> wrote: > 1) Remove any reference to @href and @src to the XHTML and HTML5 > documents about using RDFa. They do not really make sense in the > core, as the are obviously specialized for use in making RDFa easier > to use with a certain number of HTML elements, i.e. <a> and <img>. > Having them in RDFa core needlessly complicates the document, and > makes the parsing algorithm much more complicated. It's OK to keep > them in XHTML or HTML5 profiles of RDFa for ease of hand-authoring I > assume, although much of their work can just be done by use of <span> > tags. Removing them from the parsing algorithm in Core would make that parsing algorithm unable to cope with XHTML+RDFa 1.0 as it exists in the wild. @href in particular is especially important, not just in HTML/XHTML hosts, but also in Atom and potentially in SVG. > 2) Please pick either @rel or @property for marking predicates, and > do not encourage the use of both. Without both, how does one express this: <a about="#me" rel="foaf:homepage" href="http://tobyinkster.co.uk/" property="foaf:name">Toby Inkster</a> > Note that OGP already treats @property as something marking out URIs, > not literals, i.e. from [1]: > > <meta property="og:url" > content="http://www.imdb.com/title/tt0117500/" /> <meta > property="og:image" > content="http://ia.media-imdb.com/images/rock.jpg" /> I don't see why everyone takes this as an indication that RDFa is too complex. Personally whether OGP were being expressed in Turtle, RDF/XML or some other RDF serialisation, I'd day that the value of og:url should be a literal. Why? Because you're actually talking about the URI itself, not about the resource identified by the URI. og:image is a somewhat more questionable case, but only slightly. > 6) Lastly, as shown by OGP, there's two distinct use-cases for > vocabularies, one where one is talking about the things a web-page is > about, and the other a web-page. Right now RDFa is optimized to talk > about the web-page. This is perhaps something better handled at the RDF layer, by designing vocabularies that fit naturally with RDFa - vocabularies where the most common properties take an information resource as the subject, and either a literal or another information resource as the object. OGP is an example of such a vocabulary, the XHTML vocabulary is another. As a case in point, the xfn:friend-hyperlink property in Richard Cyganiak's port of XFN to RDF. This has a domain and range of foaf:Document. <alice.html> xfn:friend-page <bob.html> . With some rules-based reasoning, you can infer: _:a foaf:page <alice.html> ; xfn:friend _:b . _:b foaf:page <bob.html> . > 8) Also, I can't tell if this is allowed (again, thanks to Kavi for > the example): > > Let's say I have a review about a restaurant. The markup to convey the > relationship is: > <span typeof="abc:Review"> > <span rel="abc:itemReviewed"> > <span typeof="abc:Restaurant"> > > Microdata and microformats both remove one layer of nested html > elements for this scenario. For example in microdata, it is: > > <span itemtype="site.com/Review"> > <span itemprop="itemReviewed" itemscope > itemtype="site.com/Restaurant"> > > And in microformats it would be shorter still: > <span class="hreview"> > <span class="item hrestaurant"> > > Can we just have in RDFa? > > <span typeof="abc:Review"> > <span rel="abc:itemReviewed" typeof="abc:Restaurant"> > > I can't see why not, but not sure what the parsing algorithm does > here. That last sample parses as: _:node1 a abc:Review . _:node2 a abc:Restaurant ; abc:itemReviewed ?x . Where ?x is whatever's described inside that inner <span> element. Why? You can understand it easier if we swap the attributes around... <span typeof="abc:Review"> <span typeof="abc:Restaurant" rel="abc:itemReviewed"> But it can still be reduced to two elements in RDFa, just not the way you've done it: <span typeof="abc:Review" rel="abc:itemReviewed"> <span typeof="abc:Restaurant"> If you don't mind leaving out the rdf:type triple for the the restaurant, you can reduce it to just one element: <span typeof="abc:Review" rel="abc:itemReviewed" resource="_:node1"> Here's a full restaurant review in RDFa 1.1: <div vocab="http://example.com/review#" typeof="Review" property="text" rel="item"> <a typeof="Restaurant" rel="url" href="http://example.net/" property="name" >Il Massimo Tramezzino</a> is great! </div> Two elements. It corresponds to the following six triples in Turtle: @prefix : <http://example.com/review#> . [] a :Review ; :text "Il Massimo Tramezzino is great!" ; :item _:x1 . _:x1 a :Restaurant ; :url <http://example.net/> ; :name "Il Massimo Tramezzino" . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1292235721.5556.54.camel%40ophelia2.g5n.co.uk XHTML Vocabulary 2010-12-13T10:22:04 2010-12-13T10:22:04 2010-12-13T10:22:04 There are a number of things I'd like to discuss with the WG surrounding the XHTML vocabulary. It would be nice if we could schedule some time on one of the calls to resolve some things, etc. Perhaps 6th Jan? I've been working on a replacement for the current XHTML vocabulary document. The current draft is here: http://buzzword.org.uk/2010/xhtml-vocab-20101110.xhtml The main update is to add ma... There are a number of things I'd like to discuss with the WG surrounding the XHTML vocabulary. It would be nice if we could schedule some time on one of the calls to resolve some things, etc. Perhaps 6th Jan? I've been working on a replacement for the current XHTML vocabulary document. The current draft is here: http://buzzword.org.uk/2010/xhtml-vocab-20101110.xhtml The main update is to add mappings between XHTML vocabulary terms and other common vocabularies including Dublin Core, RDFS, Creative Commons and the IETF Link Relations registry. Firstly, I'd like us to vote on a revision policy for this document. If parser developers are going to hard-code or aggressively cache the vocabulary, they need to be confident that they know how and when it's going to change. My proposed policy is this: New terms may only be added via W3C Recs. A dedicated low-traffic mailing list would be provided by the W3C for the announcement of new terms. New terms must be announced on that list either three months before they're added to the vocab, or when the specification defining them hits Last Call - whichever comes first. Any policy probably also needs to be agreed to by PFWG and any other groups with a vested interest in the XHTML vocabulary. Secondly, I'm proposing we add describedby to the XHTML vocabulary's profile, but not the the vocabulary itself. That is describedby would be an RDFa term that mapped to a full URI outside the XHTML vocabulary. The full URI would be <http://www.w3.org/2007/05/powder-s#describedby>. Thirdly, the introductory text above even the Introduction section needs reworking. The XHTML2 Working Group is effectively defunct. There is probably some sort of lengthy process for RDFa WG / PFWG to officially take over maintenance of the document. Steven, in your position as HTML Activity Lead, would you be able to help arrange this? Assuming of course that you agree it's a good idea. Lastly, while most of the terms in the XHTML vocabulary are also registered in the IETF Link Relations registry, six are not. While there's no technical reason we need them to be registered, I think the WG should attempt to register them so that the terms can also safely be used in other non-RDFa places where "rel" can be used (e.g. plain, non-RDFa Atom; and HTTP Link headers). One of the IETF Designated Experts for the registry has told me he thinks it's a good idea to register them. The six terms are: * cite * itsrules * meta * p3pv1 * role * top I'd expect "cite", "meta" and "top" to not be controversial. However "role" is an interesting one in that it's a term in the vocab that we don't really expect to be used as a rel value much - it's more intended as support for the @role attribute. We may need to review how "p3pv1" and "itsrules" are defined. RFC 5988 says: | Registered relation types MUST NOT constrain the media type of the | context IRI, and MUST NOT constrain the available representation | media types of the target IRI. However, they can specify the | behaviours and properties of the target resource (e.g., allowable | HTTP methods, request and response media types that must be | supported). So for example we might need to redefine "p3pv1" which is currently described as "p3pv1 refers to a P3P Policy Reference File" and broaden it to allow other media types - e.g. "p3pv1 refers to a resource serving as a privacy policy, usually available as a P3P Policy Reference File". To register the Link Relations, we'd need to publish a copy of the template <http://tools.ietf.org/html/rfc5988#section-6.2.1>, filled in appropriately for each of the relations. This should be a document with a permanent URL in w3.org address space - it could be as an appendix to XHTML+RDFa, but given that we're in Last Call for that perhaps changes are undesired. So anyway, I'd like to discuss this on the 6th Jan telecon, if that's OK with the chairs. It would be good if we could as much discussion as possible about the above issues done on the mailing list, so that when the telecon comes round we can quickly run through resolving them all, and not take up too much telecon time. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1292237353.5556.75.camel%40ophelia2.g5n.co.uk Re: Last Call comments on RDFa Core 2010-12-13T10:49:15 2010-12-13T10:49:15 2010-12-13T10:49:15 On Mon, 2010-12-13 at 10:49 +0100, Ivan Herman wrote: > I believe Toby's point is a little bit different. For all the reasons > you cite Facebook has decided to use a vocabulary whereby the objects > are all literals. That is their right, and they use RDFa consistently > in this sense. Yes, but further I was also trying to say that if I were designing a property like og:url I'd design it to take ... On Mon, 2010-12-13 at 10:49 +0100, Ivan Herman wrote: > I believe Toby's point is a little bit different. For all the reasons > you cite Facebook has decided to use a vocabulary whereby the objects > are all literals. That is their right, and they use RDFa consistently > in this sense. Yes, but further I was also trying to say that if I were designing a property like og:url I'd design it to take a literal value - not for pragmatic reasons, but because it makes sense. When you use a URI in the subject, predicate or object position of a triple, you're not really taking about the URI, you're talking about the resource identified by the URI. When you need to talk about the URI itself, and not the resource identified by it, you need to use a literal (or, to get around RDF's literal subject restriction, a blank node which is owl:sameAs the literal). <http://en.wikipedia.org/wiki/Use–mention_distinction> is a good explanation of the distinction. For a less dry take on it though, I'll call upon the late, great Charles Lutwidge Dodgson: Alice was walking beside the White Knight in Looking Glass Land. "You are sad." the Knight said in an anxious tone: "let me sing you a song to comfort you." "Is it very long?" Alice asked, for she had heard a good deal of poetry that day. "It's long." said the Knight, "but it's very, very beautiful. Everybody that hears me sing it - either it brings tears to their eyes, or else -" "Or else what?" said Alice, for the Knight had made a sudden pause. "Or else it doesn't, you know. The name of the song is called 'Haddocks' Eyes.'" "Oh, that's the name of the song, is it?" Alice said, trying to feel interested. "No, you don't understand," the Knight said, looking a little vexed. "That's what the name is called. The name really is 'The Aged, Aged Man.'" "Then I ought to have said 'That's what the song is called'?" Alice corrected herself. "No you oughtn't: that's another thing. The song is called 'Ways and Means' but that's only what it's called, you know!" "Well, what is the song then?" said Alice, who was by this time completely bewildered. "I was coming to that," the Knight said. "The song really is 'A-sitting On a Gate': and the tune's my own invention." -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1292242375.5556.108.camel%40ophelia2.g5n.co.uk Re: Last Call comments on RDFa Core 2010-12-13T12:12:57 2010-12-13T12:12:57 2010-12-13T12:12:57 On Mon, 2010-12-13 at 11:19 +0000, Harry Halpin wrote: > To my knowledge, I have not seen a single halfway convincing usecase > where there is a reason why you would want to 'mention' a URI, i.e. > refer to it as a literal or xsd string. Given the following: ### @prefix con: <http://www.w3.org/2000/10/swap/pim/contact#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . <http://www.w3.org/Peopl... On Mon, 2010-12-13 at 11:19 +0000, Harry Halpin wrote: > To my knowledge, I have not seen a single halfway convincing usecase > where there is a reason why you would want to 'mention' a URI, i.e. > refer to it as a literal or xsd string. Given the following: ### @prefix con: <http://www.w3.org/2000/10/swap/pim/contact#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . <http://www.w3.org/People/Berners-Lee/card#i> con:preferredURI <http://www.w3.org/People/Berners-Lee/card#i> ; owl:sameAs <http://identi.ca/user/45563> . ### An OWL-capable processor can make the following conclusion: ### @prefix con: <http://www.w3.org/2000/10/swap/pim/contact#> . <http://www.w3.org/People/Berners-Lee/card#i> con:preferredURI <http://identi.ca/user/45563> . ### However, given: ### @prefix con: <http://www.w3.org/2000/10/swap/pim/contact#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . <http://www.w3.org/People/Berners-Lee/card#i> con:preferredURI "http://www.w3.org/People/Berners-Lee/card#i" ; owl:sameAs <http://identi.ca/user/45563> . ### It will not come to a mistaken conclusion about what timbl's preferred URI for himself is. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101217145052.1146ac4d%40miranda.g5n.co.uk Re: Obsolete tests in RDFa 1.1 Test Suite 2010-12-17T14:50:52 2010-12-17T14:50:52 2010-12-17T14:50:52 On Tue, 14 Dec 2010 20:38:27 -0500 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > test 0086: NO triple for a non-reserved @rel value, (negative test) – > Now generates a triple with default vocabulary In XHTML+RDFa the default vocabulary is initially undefined, so this should still generate no triple. > test 0105: inner @rel neither CURIE nor LinkType – Now generates a > triple with default ... On Tue, 14 Dec 2010 20:38:27 -0500 Gregg Kellogg <gregg@kellogg-assoc.com> wrote: > test 0086: NO triple for a non-reserved @rel value, (negative test) – > Now generates a triple with default vocabulary In XHTML+RDFa the default vocabulary is initially undefined, so this should still generate no triple. > test 0105: inner @rel neither CURIE nor LinkType – Now generates a > triple with default vocabulary Ditto. > test 0116: Reserved word used in @property should not generate triple > – Now generates a triple with default vocabulary Should not generate a triple using default vocabulary, as XHTML+RDFa has no initial default vocabulary. It should generate a triple though owing to the term being defined in the default profile. > test 0125: datatype XMLLiteral with other embedded RDFa, (negative > test) – XMLLiterals are now deeply parsed Note to self: need to implement this change myself! > test 0142: xmlns prefix 'xml' with correct URI – <xml:test> is a > legitimate URI > test 0160: Undeclared prefix 'xml'– <xml:test> is a legitimate URI > test 0162: Undeclared prefix 'xmlns'– <xmlns:test> is a legitimate URI Not sure of the best solution for these. According to XML Namespaces, the QName prefixes 'xml' and 'xmlns' are predefined. This needn't have effect on how CURIEs work, but we may want to consider building them in. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20101217221130.02a68b05%40miranda.g5n.co.uk Re: The Two Dogs Problem 2010-12-17T22:11:30 2010-12-17T22:11:30 2010-12-17T22:11:30 On Fri, 17 Dec 2010 09:48:58 -0500 Sandro Hawke <sandro@w3.org> wrote: > Or you could use some kind of registration number. In the > US, some people register their dogs with akc.org My cats have RFID chips under the skin in their necks for the purpose of identification. If they're found and handed in at a police station or veterinary surgery, then this can be scanned and we'll be contacted. Pre... On Fri, 17 Dec 2010 09:48:58 -0500 Sandro Hawke <sandro@w3.org> wrote: > Or you could use some kind of registration number. In the > US, some people register their dogs with akc.org My cats have RFID chips under the skin in their necks for the purpose of identification. If they're found and handed in at a police station or veterinary surgery, then this can be scanned and we'll be contacted. Presumably the RFID just encodes a unique identifying number, which would be suitable as an OWL key. I'm still not sure whether this makes my cats technically bionic. But I like to think it does. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110101231134.5e7a4f16%40miranda.g5n.co.uk Re: DOM comments inside a <style> element 2011-01-01T23:11:34 2011-01-01T23:11:34 2011-01-01T23:11:34 On Mon, 27 Dec 2010 13:11:24 +0100 "Simon Pieters" <simonp@opera.com> wrote: > For styling languages that consist of pure text This seems to me that the agent needs to know which styling languages "consist of pure text" (whatever that means! does CSS consist of pure text? does XML?) I'd suggest something along the lines of... For <style> elements where the type attribute matches /\/(.+\+)xml$/... On Mon, 27 Dec 2010 13:11:24 +0100 "Simon Pieters" <simonp@opera.com> wrote: > For styling languages that consist of pure text This seems to me that the agent needs to know which styling languages "consist of pure text" (whatever that means! does CSS consist of pure text? does XML?) I'd suggest something along the lines of... For <style> elements where the type attribute matches /\/(.+\+)xml$/i the style sheet consists of the DOM subtree within the <style> element. Any other styling languages consist of pure text; user agents must evaluate style elements by passing the concatenation of the contents of all the text nodes that are direct children of the style element (not any other nodes such as comments or elements), in tree order, to the style system. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110103234505.486f68c8%40miranda.g5n.co.uk Re: RDFa Core Review: Versioning 2011-01-03T23:45:05 2011-01-03T23:45:05 2011-01-03T23:45:05 On Mon, 3 Jan 2011 20:37:51 +0000 Jeni Tennison <jeni@jenitennison.com> wrote: > Manu asked me to do a review of the RDFa Core Last Call Working Draft > at: > http://www.w3.org/TR/2010/WD-rdfa-core-20101026/ Hi, these are my initial thoughts on your e-mail. This is not an official WG reply. > * the introduction of the prefix attribute > * the introduction of terms and profiles > * the i... On Mon, 3 Jan 2011 20:37:51 +0000 Jeni Tennison <jeni@jenitennison.com> wrote: > Manu asked me to do a review of the RDFa Core Last Call Working Draft > at: > http://www.w3.org/TR/2010/WD-rdfa-core-20101026/ Hi, these are my initial thoughts on your e-mail. This is not an official WG reply. > * the introduction of the prefix attribute > * the introduction of terms and profiles > * the interpretation of complex content lacking an explicit > datatype as a plain literal rather than an XML literal There are others actually: * case insensitivity of prefix mappings * when an XML literal is parsed, in RDFa 1.0, child elements are not checked for further triples; in RDFa 1.1, they are. * the pre-defined rel/rev keywords in RDFa 1.0 will also work in other attributes in XHTML+RDFa 1.1 (that perhaps isn't a Core comment though) > As someone managing a large site that produces RDFa, the questions I > need answered are: > > 1. What are the minimal steps I need to take to ensure that my RDFa > 1.0 site continues to be interpreted in the same way by an RDFa 1.1 > processor? Make sure you don't use any prefixes that differ in case only; use an explicit datatype for XML Literals; don't use RDFa inside XML Literals. > 2. When I move to using RDFa 1.1, how do I ensure that my > site is interpreted in the same way by an RDFa 1.0 processor as it is > by RDFa 1.1 processors? Abide by the guidelines in my answer to previous question; don't use @prefix; don't use profiles. > As a developer of an RDFa processor, the questions I need answered > are: > > 3. Can my processor be both a conformant RDFa 1.0 processor and a > conformant RDFa 1.1 processor? If you hope to offer both, then the divergent code paths are not too many. However, I can't remember exactly how we resolved this issue, but it might be non-conformant with regards to 1.1 for your parser to automatically switch to a 1.0 mode based on the @version attribute. With one exception, which will be fixed in the next release, I'm pretty sure my RDFa parser handles both versions correctly. > I think it's absolutely necessary that a section on backwards > compatibility is created that answers the above questions. Agreed. > I would suggest that you try hard to make it possible for RDFa > processors to be both conformant RDFa 1.0 processors and conformant > RDFa 1.1 processors, as I think not doing so will make it harder for > both those managing RDFa websites and those creating RDFa processors. > You could do this by introducing a notion of a 'backwards-compatible > mode' that is triggered by the presence of the version="XHTML+RDFa > 1.0" attribute that SHOULD be present in RDFa 1.0 documents. I'm not sure this is necessary. With the exception of the XMLLiteral stuff, an RDFa 1.1 processor can operate on RDFa 1.0 documents pretty safely. The only other places differences would creep in are fairly contrived. > I would also like to see something that will provide a method for the > next version of RDFa (should there be one) to be backwards compatible > with this one. Deprecating @version because it 'doesn't scale well as > a language announcement mechanism' (and I'm not sure what that means) > is fine, but I can't see what you've actually replaced it with? A future version of RDFa could use something like: profile="rdfa:2.0" to mark a document, or even a subtree as 2.0-only. An RDFa 1.1 processor would ignore the document/subtree as it would be unable to dereference the profile. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110104085232.3c91b594%40miranda.g5n.co.uk Re: Telecon Agenda - January 6th 2011, 1400 UTC 2011-01-04T08:52:32 2011-01-04T08:52:32 2011-01-04T08:52:32 On Mon, 03 Jan 2011 22:07:28 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > If you have any changes or updates to the Agenda, please send them > in before the telecon or mention something during the beginning of > the call. As per my previous message [1] I'd like to add a collection of XHTML profile issues to the agenda for this week: 1. http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/0054.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 03 Jan 2011 22:07:28 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > If you have any changes or updates to the Agenda, please send them > in before the telecon or mention something during the beginning of > the call. As per my previous message [1] I'd like to add a collection of XHTML profile issues to the agenda for this week: 1. http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Dec/0054.html -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110104192647.53fdee62%40miranda.g5n.co.uk Documenting SPARQL extension functions 2011-01-04T19:26:47 2011-01-04T19:26:47 2011-01-04T19:26:47 SPARQL has a number of built-in functions like STR() and REGEX() which can be used in filters, and since SPARQL 1.1, can be bound as results. As well as the built-in functions, SPARQL can be extended with additional functions which are identified by URIs. While there's no requirement that those URIs be dereferencable, experience from linked data tells us that it's probably a good idea for them to... SPARQL has a number of built-in functions like STR() and REGEX() which can be used in filters, and since SPARQL 1.1, can be bound as results. As well as the built-in functions, SPARQL can be extended with additional functions which are identified by URIs. While there's no requirement that those URIs be dereferencable, experience from linked data tells us that it's probably a good idea for them to be. But what should be the representation delivered when a client dereferences them? I've been writing a few extension functions for Gregory Williams' RDF::Query Perl SPARQL implementation recently, so I was pondering this question and stumbled upon what I think is a pretty good solution. Take for example, the function I've defined which takes no parameters and returns a UUID string as a literal. That function has the URI: http://buzzword.org.uk/2011/functions/util#uuid If you dereference that URI sending "Accept: application/ecmascript" you'll get an ECMAScript (JavaScript) implementation of the function, built on the RDF API which is currently being worked on by the RDFa Working Group. The ECMAScript implementations there aren't directly used by the Perl implementation - they just serve as documentation for the functions identified by the URIs. What do people think of this as a solution for documenting SPARQL extension functions? -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110105064402.493d8d9e%40miranda.g5n.co.uk Re: Last Call Comment: Support Token-like behavior in @prefix 2011-01-05T06:44:02 2011-01-05T06:44:02 2011-01-05T06:44:02 On Tue, 04 Jan 2011 23:01:56 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > <div xmlns:Person="http://xmlns.com/foaf/0.1/Person" > xmlns:name="http://xmlns.com/foaf/0.1/name" > about="#me" typeof="Person" property="name">Frank</div> I've had an option to enable support for using CURIE prefixes minus colons for quite some time now, but I've kept it disabled by default. It's pre... On Tue, 04 Jan 2011 23:01:56 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > <div xmlns:Person="http://xmlns.com/foaf/0.1/Person" > xmlns:name="http://xmlns.com/foaf/0.1/name" > about="#me" typeof="Person" property="name">Frank</div> I've had an option to enable support for using CURIE prefixes minus colons for quite some time now, but I've kept it disabled by default. It's pretty easy to implement, though I've not really looked at how it should work with regards to case-sensitivity (right now we have different case-sensitivity policies for CURIE prefixes versus tokens). Right now I think I just treat them as CURIE prefixes, so case-sensitive in RDFa 1.0 and case-insensitive in RDFa 1.1. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110105225757.624d34fc%40miranda.g5n.co.uk Re: RDFa Core Review: Host Language conformance 2011-01-05T22:57:57 2011-01-05T22:57:57 2011-01-05T22:57:57 On Wed, 5 Jan 2011 17:40:27 +0000 Jeni Tennison <jeni@jenitennison.com> wrote: > Pulling together the statements that are scattered elsewhere in the > spec, it appears that the Host Language specification can determine > things that aren't expressible within an RDFa Profile. Ultimately, as things are now, a host language can make whatever changes it likes to RDFa Core processing. The examples yo... On Wed, 5 Jan 2011 17:40:27 +0000 Jeni Tennison <jeni@jenitennison.com> wrote: > Pulling together the statements that are scattered elsewhere in the > spec, it appears that the Host Language specification can determine > things that aren't expressible within an RDFa Profile. Ultimately, as things are now, a host language can make whatever changes it likes to RDFa Core processing. The examples you cite are actually quite minor compared to how RDFa has been adopted in OpenDocument. Firstly, OpenDocument is zipped XML files. Secondly it has a construction along these lines: <paragraph> Foo bar <start property=":example" name="x"/>quux </paragraph> <paragraph> xyzzy<end name="x"/> garb. </paragraph> Which would produce (putting whitespace issues aside) this triple: <> :example "quux xyzzy" . Ultimately I think market forces will keep host languages in check. If you're producing an XML-based language for a fairly obscure use case, and want to allow RDFa to be embedded in it, then you're going to want to stick pretty closely to RDFa Core unless you want to spend your life begging RDFa consumer implementers to add special cases for your markup language. If you're revising an already popular XML format to include RDFa, then implementers are more likely to be willing to meet you half-way. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1294656253.31359.31.camel%40ophelia2.g5n.co.uk hgroup: a possible alternative 2011-01-10T10:44:15 2011-01-10T10:44:15 2011-01-10T10:44:15 Not sure if there's an open issue on hgroup that's accepting change proposals, but here's the stub of an alternative idea for discussion anyway. It seems to me that much of the dislike of <hgroup> can be solved by turning it inside out. Instead of: <hgroup> <h1>Medieval Beekeeping</h1> <h2>The evolution of an artform</h2> </hgroup> You could have: <h1> <hline>Medieval Beekeeping</hlin... Not sure if there's an open issue on hgroup that's accepting change proposals, but here's the stub of an alternative idea for discussion anyway. It seems to me that much of the dislike of <hgroup> can be solved by turning it inside out. Instead of: <hgroup> <h1>Medieval Beekeeping</h1> <h2>The evolution of an artform</h2> </hgroup> You could have: <h1> <hline>Medieval Beekeeping</hline> <hline small>The evolution of an artform</hline> </h1> <hline> would be a brand new element with an optional boolean attribute "small". You'd normally style it something like this: hline { display:block; } hline[small] { font-size: smaller; } The "small" attribute it not really presentational - it indicates a line within the heading of lesser significance. If someone can think of a better name for it, please do so. Why <hline> and not <div> or <p>? Because allowing block elements within a heading breaks the content model of headings going back pre-HTML-2.0 and would require incompatible changes to parsers. Stephen Stewart recently posted a link to http://goo.gl/5wCVt - a very interesting book chapter that deals with headlines from a newspaper editors' perspective and contains several good examples of multi-part headers, some of which seem like they could be better represented via the <hline> construct (often by adding class attributes to hlines) rather than <hgroup>. Here are some of the examples from that article marked up using <hline>: <h1> <hline small class="kicker">Weird science</hline> <hline>High school inventions lean toward the wacky</hline> </h1> <h1> <hline class="hammer">Clinton <strong>Acquitted</strong></hline> <hline small>Perjury, obstruction charges defeated</hline> </h1> <h1> <hline>Olympic bid may be probed</hline> <hline small class="underline">Gift violation may reopen Atlanta case</hline> </h1> <h1> <hline small class="summary">Gov. Jesse Ventura blended his new job with an old one, filling in for a day as a talk-show host on KSTP Radio</hline> <hline>Broadcast muse</hline> </h1> There is one possible problem with this approach: headings are traditionally written without terminal punctuation unless the punctuation is especially significant (e.g. an exclamation point or question mark). Given that, older screen readers which would not be aware of the semantics of <hline> could possibly run the lines of the heading into each other as a single sentence. I'm not sure if a display:block presentation has any effect on this. If someone could test whether the following is run together as a single sentence in screen readers, that might help... <div> <span style="display:block">Hello world</span> <span style="display:block">Hello world</span> </div> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1294664677.31359.51.camel%40ophelia2.g5n.co.uk Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF? 2011-01-10T13:04:38 2011-01-10T13:04:38 2011-01-10T13:04:38 On Sun, 2011-01-09 at 18:21 +0300, Vasiliy Faronov wrote: > Maybe it's time to define several specializations of rdfs:seeAlso with > stronger semantics? Don't we already have enough of those? <s> powder-s:describedby <o> . # <o> provides some more information about <o>, often in a # machine-readable format. <s> rdfs:seeAlso <o> . # Like powder-s:describedby but perhaps more tangential. # <o> ... On Sun, 2011-01-09 at 18:21 +0300, Vasiliy Faronov wrote: > Maybe it's time to define several specializations of rdfs:seeAlso with > stronger semantics? Don't we already have enough of those? <s> powder-s:describedby <o> . # <o> provides some more information about <o>, often in a # machine-readable format. <s> rdfs:seeAlso <o> . # Like powder-s:describedby but perhaps more tangential. # <o> might have information on something similar to <s>; or # if <s> is a document, <o> might have information on the # things described by <s>. <s> foaf:page <o> . # <o> provides information about <s>, often in a human-readable # format. <s> rdfs:isDefinedBy <o> . # <o> provides the canonical definition of <s> . We also have foaf:isPrimaryTopicOf, various terms from the XHTML vocabulary (xhv:meta, xhv:next, xhv:prev, etc), various terms from Dublin Core (dc:source, dc:relation, dc:replaces/isReplacedBy, dc:references/isReferencedBy, dc:hasVersion/isVersionOf, dc:hasPart/isPartOf, dc:isFormatOf/hasFormat) and countless others. To answer the original question, I'd say foaf:page is a better predicate than rdfs:seeAlso for a large PDF. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1294665441.31359.59.camel%40ophelia2.g5n.co.uk Re: Is it best practices to use a rdfs:seeAlso link to a potentially multimegabyte PDF?, existing predicate for linking to PDF? 2011-01-10T13:17:23 2011-01-10T13:17:23 2011-01-10T13:17:23 On Mon, 2011-01-10 at 08:55 +0000, Phil Archer wrote: > I'd be happy enough to see greater granularity for rdfs:seeAlso. I > have a use case where I want to say something like "the <uri> has been > minted recently by a source that is not authoritative but that, if > widely adopted, could become so. Either way, it's worth noting that he > and I are talking about the same thing" - and rdfs:seeAlso d... On Mon, 2011-01-10 at 08:55 +0000, Phil Archer wrote: > I'd be happy enough to see greater granularity for rdfs:seeAlso. I > have a use case where I want to say something like "the <uri> has been > minted recently by a source that is not authoritative but that, if > widely adopted, could become so. Either way, it's worth noting that he > and I are talking about the same thing" - and rdfs:seeAlso doesn't > really cover that nuance! @prefix dc: <http://purl.org/dc/terms/> . @prefix uri: <http://purl.org/NET/uri#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <foo> rdfs:seeAlso <http://example.com/bar> . <http://example.com/bar> uri:identifier [ uri:literal "http://example.com/bar"^^xsd:anyURI ; dc:issued "2011-01-08"^^xsd:date ; u:policy _:ExampleDotComUriPolicy ; u:assigned_by <http://example.com/alice#me> ] . _:ExampleDotComUriPolicy rdfs:comment "These URIs are not authoritative, but may become so."@en . -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1294747028.21876.0.camel%40ophelia2.g5n.co.uk Re: Telecon Agenda - January 13th 2011, 1400 UTC 2011-01-11T11:57:10 2011-01-11T11:57:10 2011-01-11T11:57:10 On Mon, 2011-01-10 at 23:48 -0500, Manu Sporny wrote: > Thursday, January 13th 2010 My apologies - can't make it this week. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2011-01-10 at 23:48 -0500, Manu Sporny wrote: > Thursday, January 13th 2010 My apologies - can't make it this week. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1294752982.21876.98.camel%40ophelia2.g5n.co.uk RDF API thoughts 2011-01-11T13:36:24 2011-01-11T13:36:24 2011-01-11T13:36:24 Here are some thoughts on the RDF API draft which a recent discussion in the #swig IRC channel helped my clarify in my head. The current RDF API draft is really a Notation 3 API in stealth. The current RDF API draft goes beyond the RDF data model in several ways. I'm a big fan of the Notation 3 data model - the RDF data model comes with various restrictions which are seemingly arbitrary. However... Here are some thoughts on the RDF API draft which a recent discussion in the #swig IRC channel helped my clarify in my head. The current RDF API draft is really a Notation 3 API in stealth. The current RDF API draft goes beyond the RDF data model in several ways. I'm a big fan of the Notation 3 data model - the RDF data model comes with various restrictions which are seemingly arbitrary. However, for the RDF API it makes more sense for us to stick with the RDF data model. Why? Firstly, packaging something up and calling it an RDF API when it goes significantly beyond the RDF API will irritate some people. Secondly, it will make it difficult to implement the RDF API as a layer on top of existing RDF toolkits. Notation 3 support should be stripped out and worked on as an extension to the RDF API separate document. A Notation 3 API extension is almost certainly beyond the RDFa Working Group's current charter, but that is fine as it doesn't stop RDFa Working Group members from working on this extension outside of RDFa WG time. The Notation 3 API extension should probably not be Rec track, at least not until some time when Notation 3 itself is. The only nod towards Notation 3 that the RDF API itself should offer is to avoid making that extension difficult. In other words, don't add normative requirements that would preclude a conformant RDF API implementation from also supporting Notation 3. In particular I'd like to see the following changes made to the RDF API: 1. Drop the GraphLiteral interface. 2. Allow but do not require RDFEnvironment.createTriple to throw an exception if the triple would not be RDF compatible. (For example, if the subject is a literal.) 3. Allowbut do not require Graph.add to throw an exception if the triple being added is not RDF compatible. 4. Allowbut do not require DataSerializer.serialize to throw an exception if the triple being added is not RDF compatible, or if it otherwise cannot be serialised. (For example, some RDF compatible triples cannot be serialised as RDF/XML because their predicate URIs cannot be represented as a valid QName.) Possibly provide a mode for DataSerializer objects to silently skip triples which cannot be serialised. Other high-level changes unrelated to Notation 3 that should be made: 1. Literals are currently allowed to have both a datatype and a language. This goes beyond even the Notation 3 data model, so I do not see what is gained by allowing this in the RDF API. Literals should be forced to pick a camp. 2. Drop special support for rdf:PlainLiteral. rdf:PlainLiteral is not used much in the wild and was never intended to be - it's a datatype used internally by OWL 2 and RIF. Adding special support for it complicates implementations for no reason - it should be treated the same as any other custom datatype. 3. Move terms, prefixes and profiles into the RDFa API or, better yet, drop them altogether. They make the API harder to implement and harder to grok while adding very little benefit. For those people who want to use prefixes and terms, they can be implemented quite trivially in "user space". See: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0131.html 4. Move or copy PropertyGroups from the RDFa API into the RDF API. The Graph interface should have getItemsByType, getItemBySubject and getItemsByProperty methods which return PropertyGroups or arrays of them. 5. Rename PropertyGroup to something like "RDFItem", "RDFResource" or "Description", or indeed "FartWarbler" - any name you pick out a hat will be better than the status quo. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1294756347.21876.147.camel%40ophelia2.g5n.co.uk Re: hgroup: a possible alternative 2011-01-11T14:32:31 2011-01-11T14:32:31 2011-01-11T14:32:31 On Mon, 2011-01-10 at 23:46 +0100, James Graham wrote: > Why not <h1>Main Heading <subhead>Subheading</subhead></h1> Yes, or that. Either way, the key point is to flip the <hgroup> inside out, so rather than putting stuff outside the <h1> element, you put stuff inside it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Mon, 2011-01-10 at 23:46 +0100, James Graham wrote: > Why not <h1>Main Heading <subhead>Subheading</subhead></h1> Yes, or that. Either way, the key point is to flip the <hgroup> inside out, so rather than putting stuff outside the <h1> element, you put stuff inside it. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110111215522.692e83f6%40miranda.g5n.co.uk Re: RDF API thoughts 2011-01-11T21:55:22 2011-01-11T21:55:22 2011-01-11T21:55:22 On Tue, 11 Jan 2011 15:10:00 +0000 Nathan <nathan@webr3.org> wrote: > they may very well be included in the next revision of RDF, > as per the potential RDF WG draft charter I don't think it's going to be fruitful to try to cater for RDF 1.1 or 2.0 or whatever it ends up being called. Even if we recharter the RDFa WG with an extension, the new RDF version recs will not be delivered until a good... On Tue, 11 Jan 2011 15:10:00 +0000 Nathan <nathan@webr3.org> wrote: > they may very well be included in the next revision of RDF, > as per the potential RDF WG draft charter I don't think it's going to be fruitful to try to cater for RDF 1.1 or 2.0 or whatever it ends up being called. Even if we recharter the RDFa WG with an extension, the new RDF version recs will not be delivered until a good 18 months after this group's charter ends - and that's if they're delivered on time, which seems pretty unlikely to me. Let's deliver an RDF API for RDF as it's defined today and not try to guess what the RDF WG will do in the future. If it turns out that the RDF API we develop is inadequate to cover the next version of RDF, then the RDF WG worry about that. > Profiles are required by RDFa processors (default profile etc), may > well be adopted by the RDF WG for turtle and RDF, hence the > specification - generally the interfaces will need to be supported by > one of the two APIs regardless, can't just be dropped afaict. I'm sorry, but this is a non-sequitur. My RDFa parser is implemented on top of an existing RDF API (not *the* RDF API, *an* RDF API - RDF::Trine's API); Ivan's is implemented on top of an existing RDF API (rdflib's API). Neither of these APIs have built-in profile support, but we both managed to implement RDFa 1.1. So implementing an RDFa parser does not require profile support in the underlying RDF API. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110112131356.2205299e%40miranda.g5n.co.uk implementation: Representing vCard Objects in RDF (Member Submission) 2011-01-12T13:13:56 2011-01-12T13:13:56 2011-01-12T13:13:56 The W3C "Representing vCard Objects in RDF" Member Submission was, in a way, part of the output of the SWXG. Here 'tis: http://www.w3.org/Submission/vcard-rdf/ I've recently released a Perl module capable of converting from the RDF representation of vCard to vCard 3.0 format: http://search.cpan.org/dist/RDF-vCard/ Conversion in the other direction is also planned. This also slots in quite n... The W3C "Representing vCard Objects in RDF" Member Submission was, in a way, part of the output of the SWXG. Here 'tis: http://www.w3.org/Submission/vcard-rdf/ I've recently released a Perl module capable of converting from the RDF representation of vCard to vCard 3.0 format: http://search.cpan.org/dist/RDF-vCard/ Conversion in the other direction is also planned. This also slots in quite nicely with my Microformat parser which is capable of parsing hCard and outputting it as RDF: http://search.cpan.org/dist/HTML-Microformats/ -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110112143850.253a5d92%40miranda.g5n.co.uk Re: Reverse Links and HTTP Referer 2011-01-12T14:38:50 2011-01-12T14:38:50 2011-01-12T14:38:50 On Wed, 12 Jan 2011 02:47:34 +0000 Nathan <nathan@webr3.org> wrote: > 1: does anybody send HTTP Referer headers from their linked data > clients and crawlers? I don't have a linked data client or crawler. However, I have written a GRDDL implementation which needs to follow various links to find transformation files. It does send Referer headers. My RDFa parser currently does not send Referer headers when dereferencing RDFa 1.1 profiles. I consider this to be bug. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 12 Jan 2011 02:47:34 +0000 Nathan <nathan@webr3.org> wrote: > 1: does anybody send HTTP Referer headers from their linked data > clients and crawlers? I don't have a linked data client or crawler. However, I have written a GRDDL implementation which needs to follow various links to find transformation files. It does send Referer headers. My RDFa parser currently does not send Referer headers when dereferencing RDFa 1.1 profiles. I consider this to be bug. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110114221010.2c6646f1%40miranda.g5n.co.uk subscribe 2011-01-14T22:10:10 2011-01-14T22:10:10 2011-01-14T22:10:10 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110114221019.045d472c%40miranda.g5n.co.uk subscribe 2011-01-14T22:10:19 2011-01-14T22:10:19 2011-01-14T22:10:19 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110114221155.46b6611d%40miranda.g5n.co.uk Re: CONFIRM s2833922584 2011-01-14T22:11:55 2011-01-14T22:11:55 2011-01-14T22:11:55 On Fri, 14 Jan 2011 22:10:23 +0000 public-xg-webid-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-xg-webid mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-xg-webid-requ... On Fri, 14 Jan 2011 22:10:23 +0000 public-xg-webid-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-xg-webid mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-xg-webid-request@w3.org > > with the Subject string: > > CONFIRM s2833922584 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm > string has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed > above will be (un)subscribed. If the address above is incorrect, > please do not send the confirmation message listed above. Instead, > send a new (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event > that you did not send a request to (un)subscribe, the headers of the > message may help you discover who sent the request. > > > >From tai@g5n.co.uk Fri Jan 14 22:10:23 2011 > >Received: from lisa.w3.org ([128.30.52.41]) > > by frink.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1Pdrqh-0005rp-89 > > for public-xg-webid-request@listhub.w3.org; Fri, 14 Jan 2011 > > 22:10:23 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by lisa.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1Pdrqf-0002dd-Ow > > for public-xg-webid-request@w3.org; Fri, 14 Jan 2011 > > 22:10:23 +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id A95C3B9803 > > for <public-xg-webid-request@w3.org>; Fri, 14 Jan 2011 > > 22:09:50 +0000 (GMT) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, > > port 10025) with ESMTP id kvIXZ5oZ8bdw for > > <public-xg-webid-request@w3.org>; Fri, 14 Jan 2011 22:09:48 > > +0000 (GMT) > >Received: from miranda.g5n.co.uk (unknown [192.168.0.144]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id F2504B9801 > > for <public-xg-webid-request@w3.org>; Fri, 14 Jan 2011 > > 22:09:47 +0000 (GMT) > >Date: Fri, 14 Jan 2011 22:10:19 +0000 > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-xg-webid-request@w3.org > >Subject: subscribe > >Message-ID: <20110114221019.045d472c@miranda.g5n.co.uk> > >X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.9; i586-mandriva-linux-gnu) > >Link: <http://tobyinkster.co.uk/#i>; > >rel="http://xmlns.com/foaf/0.1/maker > > http://purl.org/dc/terms/creator"; > > rev="http://xmlns.com/foaf/0.1/made" > >Mime-Version: 1.0 > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: lisa.w3.org 1Pdrqf-0002dd-Ow > >4304f4c3f036aafb46c99656a746cd08 > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110116105740.7b9c393f%40miranda.g5n.co.uk Re: Vocabulary for describing translation relationship 2011-01-16T10:57:40 2011-01-16T10:57:40 2011-01-16T10:57:40 On Sat, 15 Jan 2011 11:43:19 +0900 KANZAKI Masahide <mkanzaki@gmail.com> wrote: > PRISM (Publishing Requirements for Industry Standard Metadata) > vocabulary has prism:hasTranslation and prism:isTranslationOf. > > http://prismstandard.org/namespaces/basic/2.0/ Also Dublin Core has dc:isVersionOf/dc:hasVersion. As Nathan is using RDFa, it's easy to use both vocabularies on a single link: <a rel... On Sat, 15 Jan 2011 11:43:19 +0900 KANZAKI Masahide <mkanzaki@gmail.com> wrote: > PRISM (Publishing Requirements for Industry Standard Metadata) > vocabulary has prism:hasTranslation and prism:isTranslationOf. > > http://prismstandard.org/namespaces/basic/2.0/ Also Dublin Core has dc:isVersionOf/dc:hasVersion. As Nathan is using RDFa, it's easy to use both vocabularies on a single link: <a rel="dc:hasVersion prism:hasTranslation" href="index.fr.html"> <span property="dc:language" content="fr" datatype="dc:RFC5646">en Français</span> </a> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110117090155.350e9a55%40miranda.g5n.co.uk Re: Last Call Response to ISSUE-64: Add rel=describedby to the XHTML vocab 2011-01-17T09:01:55 2011-01-17T09:01:55 2011-01-17T09:01:55 On Sun, 16 Jan 2011 21:42:15 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > The term will be added to the XHTML default vocabulary document. > [...] > Since this is a Last Call issue, we ask that you please respond to > this e-mail and let us know if this solution works for you. Excellent! (complete with C Montgomery Burns hands.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 16 Jan 2011 21:42:15 -0500 Manu Sporny <msporny@digitalbazaar.com> wrote: > The term will be added to the XHTML default vocabulary document. > [...] > Since this is a Last Call issue, we ask that you please respond to > this e-mail and let us know if this solution works for you. Excellent! (complete with C Montgomery Burns hands.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110118164620.4b640223%40miranda.g5n.co.uk Re: Generalized triples (Fwd: Non-Javascript RDF API-s?) 2011-01-18T16:46:20 2011-01-18T16:46:20 2011-01-18T16:46:20 On Tue, 18 Jan 2011 14:26:24 +0000 Andy Seaborne <andy.seaborne@epimorphics.com> wrote: > I asked around - 4Store, for example, makes use of the fact that > literals only occur in the object position in both indexing and query > optimization. RDF::Trine uses generalised triples in most places, but the SQL-backed store optimises using RDF rules on which node types are allowed in which positions. (There's an option to disable these optimisations which then allows you to store and retrieve generalised triples.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Tue, 18 Jan 2011 14:26:24 +0000 Andy Seaborne <andy.seaborne@epimorphics.com> wrote: > I asked around - 4Store, for example, makes use of the fact that > literals only occur in the object position in both indexing and query > optimization. RDF::Trine uses generalised triples in most places, but the SQL-backed store optimises using RDF rules on which node types are allowed in which positions. (There's an option to disable these optimisations which then allows you to store and retrieve generalised triples.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110120003738.4d46f47a%40miranda.g5n.co.uk Re: Datasets on UK transport ? 2011-01-20T00:37:38 2011-01-20T00:37:38 2011-01-20T00:37:38 On Wed, 19 Jan 2011 22:31:04 +0000 Andrea Splendiani <andrea.splendiani@bbsrc.ac.uk> wrote: > I have checked a bit the transport endpoint of data.gov.uk, but found > a lot of information on stations, including their position, but no > information on their connectivity. http://ontologi.es/rail/ In particular: http://ontologi.es/rail/routes/gb/VTB3 I do have vague plans for a version 0.2 soonish. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 19 Jan 2011 22:31:04 +0000 Andrea Splendiani <andrea.splendiani@bbsrc.ac.uk> wrote: > I have checked a bit the transport endpoint of data.gov.uk, but found > a lot of information on stations, including their position, but no > information on their connectivity. http://ontologi.es/rail/ In particular: http://ontologi.es/rail/routes/gb/VTB3 I do have vague plans for a version 0.2 soonish. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110120124512.433b6043%40miranda.g5n.co.uk Re: Datasets on UK transport ? 2011-01-20T12:45:12 2011-01-20T12:45:12 2011-01-20T12:45:12 On Thu, 20 Jan 2011 01:32:18 +0000 Andrea Splendiani <andrea.splendiani@bbsrc.ac.uk> wrote: > very interesting, where did you get the data from ? I mean, I've seen > the sources, but did you extract data from National Railways ? At a > first look, it looks like the coverage is good as well. Scraping HTML and cross-referncing data from multiple sources. One of the key sources is Phil Deaves' "Ra... On Thu, 20 Jan 2011 01:32:18 +0000 Andrea Splendiani <andrea.splendiani@bbsrc.ac.uk> wrote: > very interesting, where did you get the data from ? I mean, I've seen > the sources, but did you extract data from National Railways ? At a > first look, it looks like the coverage is good as well. Scraping HTML and cross-referncing data from multiple sources. One of the key sources is Phil Deaves' "Railways codes and other data" website. In particular, the station listings, after a bit of processing, are the key to figuring out connectivity. For instance: http://deaves47.users.btopenworld.com/stations/stationl.htm Currently the London Underground is not covered. Some other stations only served by metropolitan light rail may also be missing. Heritage railways are also mostly missing. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110121121028.2cde139e%40miranda.g5n.co.uk Re: ISSUE-120 (rdfa-prefixes): Chairs Solicit Proposals 2011-01-21T12:10:28 2011-01-21T12:10:28 2011-01-21T12:10:28 On Wed, 8 Dec 2010 15:30:51 +0000 Paul Cotton <Paul.Cotton@microsoft.com> wrote: > ISSUE-120 (rdfa-prefixes): Use of prefixes is too complicated for a > Web technology > > Per the decision policy, at this time the Chairs would like to > solicit volunteers to write Change Proposals for ISSUE-120 Here is a change proposal for this issue: http://www.w3.org/html/wg/wiki/ChangeProposals/RDFaPrefixesNoChange -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 8 Dec 2010 15:30:51 +0000 Paul Cotton <Paul.Cotton@microsoft.com> wrote: > ISSUE-120 (rdfa-prefixes): Use of prefixes is too complicated for a > Web technology > > Per the decision policy, at this time the Chairs would like to > solicit volunteers to write Change Proposals for ISSUE-120 Here is a change proposal for this issue: http://www.w3.org/html/wg/wiki/ChangeProposals/RDFaPrefixesNoChange -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110121131154.6b00d942%40miranda.g5n.co.uk Re: "Triage" of ISSUE-69 2011-01-21T13:11:54 2011-01-21T13:11:54 2011-01-21T13:11:54 On Fri, 21 Jan 2011 12:03:52 +0100 Ivan Herman <ivan@w3.org> wrote: > 1. Include a sentence in the RDFa 1.1 Core which disallows the usage > of 'xml' and 'xmlns' as valid prefixes, both in their definitions > (ie, listed in @prefix) and in using them as a CURIE. Ie, hitting > such a CURIE should generate an error. The RDFa 1.0 test suite had a test (test 0142) that required implementations to in... On Fri, 21 Jan 2011 12:03:52 +0100 Ivan Herman <ivan@w3.org> wrote: > 1. Include a sentence in the RDFa 1.1 Core which disallows the usage > of 'xml' and 'xmlns' as valid prefixes, both in their definitions > (ie, listed in @prefix) and in using them as a CURIE. Ie, hitting > such a CURIE should generate an error. The RDFa 1.0 test suite had a test (test 0142) that required implementations to interpret xmlns:xml="..." and xmlns:xmlns="..." as not establishing prefix mappings unless they were set to their predefined meaning. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110121154412.42ac8d4d%40miranda.g5n.co.uk HTML+RDFa issue 120 2011-01-21T15:44:12 2011-01-21T15:44:12 2011-01-21T15:44:12 Heads up! There is an issue filed against HTML+RDFa with the HTML WG on the use of CURIEs within RDFa. Ian Hickson has written a change proposal for HTML+RDFa: http://lists.w3.org/Archives/Public/www-archive/2011Jan/att-0022/cp-120.html This proposal, if adopted, would make the @profile and @prefix attributes non-conforming in HTML+RDFa, and require user agents to ignore them. It would also req... Heads up! There is an issue filed against HTML+RDFa with the HTML WG on the use of CURIEs within RDFa. Ian Hickson has written a change proposal for HTML+RDFa: http://lists.w3.org/Archives/Public/www-archive/2011Jan/att-0022/cp-120.html This proposal, if adopted, would make the @profile and @prefix attributes non-conforming in HTML+RDFa, and require user agents to ignore them. It would also require user agents to ignore @xmlns:* attributes. In summary, there would be no mechanism for authors to define prefix mappings. In my capacity as invited expert to the HTML WG, I've submitted a counter-proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/RDFaPrefixesNoChange This proposes that no technical changes be made to HTML+RDFa, but editorial changes be made to promote the use of full URIs in RDFa, and make it clearer that CURIEs are simply an abbreviation for the full URIs. The proposal also suggests that the HTML+RDFa editor (Manu) work with the RDFa Working Group to make sure examples with full URIs are similarly featured more prominently in XHTML+RDFa and RDFa Core. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110121202714.3b5b6931%40miranda.g5n.co.uk Re: Specific media types for rdf vocabularies 2011-01-21T20:27:14 2011-01-21T20:27:14 2011-01-21T20:27:14 On Fri, 21 Jan 2011 00:07:29 +0000 Phil Archer <phil.archer@talis.com> wrote: > IMO, the answer to your question is a clear 'yes, the generic media > type is appropriate.' Agreed. But if Peter needs to have a talisman to use for, say, content negotiation, he could use something like this: Content-Type: application/rdf+xml;x-vocab=foobar -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Fri, 21 Jan 2011 00:07:29 +0000 Phil Archer <phil.archer@talis.com> wrote: > IMO, the answer to your question is a clear 'yes, the generic media > type is appropriate.' Agreed. But if Peter needs to have a talisman to use for, say, content negotiation, he could use something like this: Content-Type: application/rdf+xml;x-vocab=foobar -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110122125943.1aa479e5%40miranda.g5n.co.uk subscribe 2011-01-22T12:59:43 2011-01-22T12:59:43 2011-01-22T12:59:43 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110122130446.654a869d%40miranda.g5n.co.uk Re: CONFIRM s578419617 2011-01-22T13:04:46 2011-01-22T13:04:46 2011-01-22T13:04:46 On Sat, 22 Jan 2011 12:59:44 +0000 public-rdf-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdf mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-rdf-request@w3.org > >... On Sat, 22 Jan 2011 12:59:44 +0000 public-rdf-request@w3.org wrote: > It has been requested that the following address: > > tai@g5n.co.uk > > be added to the public-rdf mailing list. > > The address has NOT yet been subscribed to the mailing list. > To subscribe you need to confirm the subscription > request by sending an email to the address: > > public-rdf-request@w3.org > > with the Subject string: > > CONFIRM s578419617 > > (A reply to this message should be sufficient) > > Please do not modify the subject line when replying. If the confirm > string has been removed or changed the confirmation will fail! > > When your confirmation message has been received, the address listed > above will be (un)subscribed. If the address above is incorrect, > please do not send the confirmation message listed above. Instead, > send a new (un)subscribe request containing the Subject: > > subscribe correct-address@correct-domain > > or > > unsubscribe correct-address@correct-domain > > and wait for a new confirmation message. > > A copy of the (un)subscription request appears below. In the event > that you did not send a request to (un)subscribe, the headers of the > message may help you discover who sent the request. > > > >From tai@g5n.co.uk Sat Jan 22 12:59:43 2011 > >Received: from lisa.w3.org ([128.30.52.41]) > > by frink.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1Pgd4B-00055y-Q7 > > for public-rdf-request@listhub.w3.org; Sat, 22 Jan 2011 > > 12:59:43 +0000 > >Received: from ophelia.g5n.co.uk ([81.2.120.180]) > > by lisa.w3.org with esmtp (Exim 4.69) > > (envelope-from <tai@g5n.co.uk>) > > id 1Pgd49-00014V-Na > > for public-rdf-request@w3.org; Sat, 22 Jan 2011 12:59:43 > > +0000 > >Received: from localhost (ophelia2.g5n.co.uk [127.0.0.1]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id CE312B9802 > > for <public-rdf-request@w3.org>; Sat, 22 Jan 2011 12:59:09 > > +0000 (GMT) > >X-Virus-Scanned: amavisd-new at ophelia.g5n.co.uk > >Received: from ophelia.g5n.co.uk ([127.0.0.1]) > > by localhost (ophelia2.g5n.co.uk [127.0.0.1]) (amavisd-new, > > port 10025) with ESMTP id rM7+z9YLox4n for > > <public-rdf-request@w3.org>; Sat, 22 Jan 2011 12:59:06 +0000 > > (GMT) > >Received: from miranda.g5n.co.uk (unknown [192.168.0.144]) > > by ophelia.g5n.co.uk (Postfix) with ESMTP id E1E06B9801 > > for <public-rdf-request@w3.org>; Sat, 22 Jan 2011 12:59:06 > > +0000 (GMT) > >Date: Sat, 22 Jan 2011 12:59:43 +0000 > >From: Toby Inkster <tai@g5n.co.uk> > >To: public-rdf-request@w3.org > >Subject: subscribe > >Message-ID: <20110122125943.1aa479e5@miranda.g5n.co.uk> > >X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.9; i586-mandriva-linux-gnu) > >Link: <http://tobyinkster.co.uk/#i>; > >rel="http://xmlns.com/foaf/0.1/maker > > http://purl.org/dc/terms/creator"; > > rev="http://xmlns.com/foaf/0.1/made" > >Mime-Version: 1.0 > >Content-Type: text/plain; charset=US-ASCII > >Content-Transfer-Encoding: 7bit > >Received-SPF: none > >X-SPF-Guess: pass > >X-W3C-Hub-Spam-Status: No, score=-2.6 > >X-W3C-Hub-Spam-Report: BAYES_00=-2.599 > >X-W3C-Scan-Sig: lisa.w3.org 1Pgd49-00014V-Na > >de78bea73e9476d9347601b40c82482d > > > > > > > >-- > >Toby A Inkster > ><mailto:mail@tobyinkster.co.uk> > ><http://tobyinkster.co.uk> > > > > -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110122132706.1deb792a%40miranda.g5n.co.uk Re: URI Comparisons: RFC 2616 vs. RDF 2011-01-22T13:27:06 2011-01-22T13:27:06 2011-01-22T13:27:06 On Tue, 18 Jan 2011 21:43:08 -0600 Peter DeVries <pete.devries@gmail.com> wrote: > I have URI's where case is important only at the terminal identifier. > (HTML URI's in this example) > http://lod.taxonconcept.org/ses/v6n7p.html > should be different than > http://lod.taxonconcept.org/ses/v6N7p.html > Am I correct in thinking that this is OK? Yes, HTTP URIs are case-sensitive apart from the sche... On Tue, 18 Jan 2011 21:43:08 -0600 Peter DeVries <pete.devries@gmail.com> wrote: > I have URI's where case is important only at the terminal identifier. > (HTML URI's in this example) > http://lod.taxonconcept.org/ses/v6n7p.html > should be different than > http://lod.taxonconcept.org/ses/v6N7p.html > Am I correct in thinking that this is OK? Yes, HTTP URIs are case-sensitive apart from the scheme (http), host (lod.taxonconcept.org) and percent-escaped characters (e.g. %7e vs %7E). Any URI canonicalisation tool that treats the above two URIs as the same is plain broken. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1295997092.4229.6.camel%40ophelia2.g5n.co.uk DRAFT review of XHTML Role Attribute Module 2011-01-25T23:11:33 2011-01-25T23:11:33 2011-01-25T23:11:33 Review of: XHTML Role Attribute Module A module to support role classification of elements W3C Working Group Note 16 December 2010 <http://www.w3.org/TR/2010/NOTE-xhtml-role-20101216> Previous versions of this note included a mapping of the XHTML role attribute to RDF, though this seems to have been removed in the current version. The RDFa working group had been critical of the wording of th... Review of: XHTML Role Attribute Module A module to support role classification of elements W3C Working Group Note 16 December 2010 <http://www.w3.org/TR/2010/NOTE-xhtml-role-20101216> Previous versions of this note included a mapping of the XHTML role attribute to RDF, though this seems to have been removed in the current version. The RDFa working group had been critical of the wording of this mapping, as it appeared to place normative requirements on conformant RDFa processors. However, I think we were broadly in favour of such a mapping existing, as it provided an easy method of making simple statements about XHTML elements themselves. (Whereas RDFa focuses on making statements about XHTML documents, and about the things described in them.) With that in mind, it seems a shame this feature has been removed, though it's understandable if consensus could not be achieved on this mapping. The note includes a normative reference to CURIE Syntax 1.0. While CURIE Syntax 1.0 is not the subject of this review, the RDFa working group hopes that it is broadly compatible with RDFa's own CURIE syntax. In RDFa 1.1, attributes which accept CURIEs also accept absolute URIs. Is this feature supported in the role attribute? If so, then the note could do with clarification. If not, then it would be useful to note this difference. The HTML working group's current drafts of HTML 5 include an attribute named role, so HTML+RDFa implementations may need to be aware of the role attribute. It would be useful if an informative section could be included in the XHTML role attribute note detailing to what extent (if any) it is compatible with HTML 5's role attribute. The author of this review would also like to point out that markup like the following: <mylang xmlns="http://www.example.com/dtd/mylang" xmlns:xh="http://www.w3.org/1999/xhtml" xml:lang="en" xh:role="foo"> is inconsistent with the role attribute in XHTML, where it is not in any namespace at all (not even in the XHTML namespace). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1295997403.4229.10.camel%40ophelia2.g5n.co.uk ISSUE-67 triage 2011-01-25T23:16:43 2011-01-25T23:16:43 2011-01-25T23:16:43 Here are Henri Sivonen's comments (HS) and my replies (TI). In paragraphs where I suggest an editorial change, I've included the marker "[EDIT]". In paragraphs where I suggest opening a new issue, I've included the marker "[ISSUE]". I've divided Henri's comments into three broad categories - "Editorial Fixes", "Won't Fix" and "Needs Addressing By WG" - though there's some overlap. (For example an... Here are Henri Sivonen's comments (HS) and my replies (TI). In paragraphs where I suggest an editorial change, I've included the marker "[EDIT]". In paragraphs where I suggest opening a new issue, I've included the marker "[ISSUE]". I've divided Henri's comments into three broad categories - "Editorial Fixes", "Won't Fix" and "Needs Addressing By WG" - though there's some overlap. (For example an issue that we won't make any technical changes to RDFa to fix, but could make some editorial changes to clarify if the WG thinks this is needed.) ---- Editorial Fixes =============== HS: It seems questionable that formsplayer.com (site of a product that one of the Editors has a commercial interest in) is used in an example. TI: Please replace with something like example.com. [EDIT] HS: The Creative Commons license example in section 2.2 uses the anti-pattern of saying "a Creative Commons license" (instead of saying which one of the numerous licenses) in the human-readable prose. TI: Please include the name of the license in this example - possibly mark it up in RDFa as the license's dc:title or rdfs:label. [EDIT] HS: The processing model for the case where the optional xmlns:prefix feature is supported isn't specified. TI: Step 4 in the processing sequence could be expanded upon. Need to indicate that @xmlns:* is processed first, if permitted by host language; then @prefix which can override the previous mappings from @xmlns:*. [EDIT] HS: It's weird that the prefix attribute requires a single space between the colon following the prefix and the URI but allows multiple spaces between the URI and the next prefix. TI: This seems to be a mistake. We should allow one or more whitespace characters in both cases. We need to make sure the regular expression or algorithm for extracting mappings from @prefix can cope with that (see next question). [EDIT] HS: If the spec contains rules for how to extract a set of prefix to URI mappings from the prefix attribute, the rules are hard to locate. TI: We used to have a regular expression for parsing the prefix mapping. (Perhaps on the rdfa.info wiki?) Could this be added to RDFa Core, or as an alternative a detailed algorithm for parsing @prefix? [EDIT] Won't Fix ========= HS: To be Compatible with Existing Content, RDFa 1.1 doesn't need to be backwards compatible in the sense of parsing the same triples out of any valid RDFa 1.0 input as RDFa 1.0. Instead, it needs only to produce the right triples for the content that's already out there. Thus, Compatibility with Existing Content could be mostly achieved by performing by hard-coding the meanings of the common prefixes used in deployed content that purports to use RDFa. TI: There exist at least three commonly-used prefixes that I can think of that this would not work for: 'dc', 'v' and 'og'. 'dc' is variously used to abbreviate <http://purl.org/dc/terms/> and <http://purl.org/dc/elements/1.1/>; 'v', <http://rdf.data-vocabulary.org/#> and <http://www.w3.org/2006/vcard/ns#>; 'og', <http://www.opengraphprotocol.org/schema/> and <http://ogp.me/ns#>. While in two of these cases the different URIs merely indicate different versions of the same or similar sets of terms, switching them - as inevitably would happen if any of these prefixes were to be hard-coded ignoring the document's own mappings - would be unacceptable for any format that purports to be a serialisation of RDF. TI (cont'd): Further, from a more theoretical standpoint, blessing a finite set of vocabularies and forcing others to use a more long-winded notation discourages truly decentralised development of vocabularies. Decentralised development is an important use case which RDFa and RDF more generally were developed to cater for. HS: I reiterate my previous comment that prefix-based indirection confuses authors and complicates implementation. Please use absolute URLs only instead of CURIEs. I'm not going to elaborate on this point, because I realize that the WG isn't going to change this. TI: Prefix-based abbreviation of URIs is considered a feature of RDFa. Dropping support for it would, in our opinion harm the usability of the language. It would also severely break backwards compatibility, as RDFa 1.0 in many places *only* supports CURIEs, and disallows full URIs. This working group is chartered to maintain backwards compatibility except in one particular area. TI (cont'd): That having been said, there are some editorial changes we should consider, including shifting the examples where full URIs are used earlier in the RDFa Core, before CURIEs are introduced. This would make it clearer that CURIEs are an optional abbreviation for URIs, rather than URIs being an unusual way of expressing CURIEs. [EDIT] TI (cont'd): Further, in examples where we are not specifically trying to illustrate CURIEs, we could take the default position of using absolute URIs. This includes all the examples in section 7.3 of RDFa Core. [EDIT] HS: Loading prefix definitions from an external file seems to make RDFa brittle in case the external file can't be loaded. Also, blocking RDFa processing in order to do IO to fetch the prefix definitions complicates implementation. TI: The working group has attempted to, as much as possible, limit the harm that is done when external profiles are unavailable. TI (cont'd): In a hypothetical world where Youtube and Flickr both implemented RDFa using profiles, then the brittleness of their links to profile documents seems secondary to the brittleness of their links to video and image files respectively. If the latter is not seen as problematic, then it's not clear why the former should be. TI (cont'd): Profiles are an optional feature of RDFa, and when an author is more than averagely concerned with the longevity of their data, they are perhaps a feature best avoided. We may wish to explicitly state this somewhere in RDFa Core. [EDIT] HS: (This is a general RDF problem but...) It seems author-hostile to require authors to specify the datatype of e.g. date literals instead of making the datatype of a property a characteristic of the property in the vocabulary/ontology. TI: This is something perhaps better addressed further up the RDF stack. We note that an RDF working group has recently been established by the W3C. HS: It seems unfortunate to use XML Schema Datatype as an example considering how much weird variability XML Schema Datatypes allow. TI: With the exception of rdf:XMLLiteral, XML Schema datatypes are the most commonly used datatypes in RDF data in the wild. It makes sense to use these datatypes rather than perhaps theoretically "better" but less realisitic examples. HS: xmlns:prefix is marked as an optional feature. Please remove the feature altogether, because xmlns:prefix parses differently in text/html and application/xhtml+xml which are the media types most likely to be used to transfer RDFa. TI: We cannot remove this feature, as it would break compatibility with RDFa 1.0. We are chartered to retain compatibility. TI (cont'd): Further, we are not aware of any RDFa implementors who have had problems caused by this difference. A number of RDFa implementors have built processors that accept DOMs generated by both HTML5 and XML parsers, with no reported difficulties. HS: It's a bad idea to use xs:anyURI as part of a definition, because the meaning on xs:anyURI has shifted over time and, IIRC, now any string is an xs:anyURI. TI: RDF's use of XML Schema datatypes differs from XML's use of them - they are not merely syntactic checks, but impart meaning to literals. Thus, in RDF terms, there is a difference between stating a property's range is xsd:string versus xsd:anyURI, even if they allow syntactically the same literal values. Needs Addressing By WG ====================== HS: The concept of "processor graph" seems to be an open-ended loophole of non-interoperability. TI: We should open a new issue for this. [ISSUE] HS: Under 4.1 the statement about whitespace seems to say that authors should assume non-conforming processors. TI: Would anyone object to removing the second and third sentances from the last paragraph of section 4.1? [EDIT] -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110128115008.26c8ff05%40miranda.g5n.co.uk Re: [foaf-protocols] Secure Email using WebID and Webfinger 2011-01-28T11:50:08 2011-01-28T11:50:08 2011-01-28T11:50:08 On Wed, 26 Jan 2011 11:52:07 +0100 Henry Story <henry.story@bblfish.net> wrote: > At a later stage one could imagine even being able to > avoid WebFinger by having a new e-mail header such as > Sent-by-WebID: . I already include a header along these lines in my messages... Link: <http://tobyinkster.co.uk/#i>; rel="http://xmlns.com/foaf/0.1/maker" This is a direct port of Web Linking (RFC 5988) over to e-mail (as e-mail headers work pretty much the same as HTTP ones). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Wed, 26 Jan 2011 11:52:07 +0100 Henry Story <henry.story@bblfish.net> wrote: > At a later stage one could imagine even being able to > avoid WebFinger by having a new e-mail header such as > Sent-by-WebID: . I already include a header along these lines in my messages... Link: <http://tobyinkster.co.uk/#i>; rel="http://xmlns.com/foaf/0.1/maker" This is a direct port of Web Linking (RFC 5988) over to e-mail (as e-mail headers work pretty much the same as HTTP ones). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110129092204.217e55dd%40miranda.g5n.co.uk Re: WebID-ISSUE-7 (bblfish): Move esw wiki contents? [WebID wiki] 2011-01-29T09:22:04 2011-01-29T09:22:04 2011-01-29T09:22:04 On Fri, 28 Jan 2011 07:38:27 +0000 WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org> wrote: > There is a lot of info on the esw wiki on WebID both at > > http://esw.w3.org/foaf+ssl > http://esw.w3.org/WebID > > There is no reason to move the content. W3C groups automatically get MediaWiki instances of their own. Ours is here: http://www.w3.org/2005/Incubator/webid/wiki/Main_Page H... On Fri, 28 Jan 2011 07:38:27 +0000 WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org> wrote: > There is a lot of info on the esw wiki on WebID both at > > http://esw.w3.org/foaf+ssl > http://esw.w3.org/WebID > > There is no reason to move the content. W3C groups automatically get MediaWiki instances of their own. Ours is here: http://www.w3.org/2005/Incubator/webid/wiki/Main_Page However, when I asked on the RDFa WG about the persistence of the wiki once the group has closed, it seems the answer is that there are no guarantees about it remaining writeable by the former group's members. So I'd be in favour of keeping the WebID wiki stuff on esw. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110129215519.0f7e25f8%40miranda.g5n.co.uk unsubscribe 2011-01-29T21:55:19 2011-01-29T21:55:19 2011-01-29T21:55:19 -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110129221629.12ee463e%40miranda.g5n.co.uk Re: WebID-ISSUE-9 (bblfish): Develop WebID Test Suite [WebID Spec] 2011-01-29T22:16:29 2011-01-29T22:16:29 2011-01-29T22:16:29 On Sat, 29 Jan 2011 10:10:28 +0000 WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org> wrote: > There were some tests out there already. Something to place in the > mercurial repository. Beginnings of a test suite is here: http://buzzword.org.uk/2008/foaf_ssl/tests/manifest.ttl The idea is that a test harness (and there's an example test harness provided at http://buzzword.org.uk/2008/... On Sat, 29 Jan 2011 10:10:28 +0000 WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org> wrote: > There were some tests out there already. Something to place in the > mercurial repository. Beginnings of a test suite is here: http://buzzword.org.uk/2008/foaf_ssl/tests/manifest.ttl The idea is that a test harness (and there's an example test harness provided at http://buzzword.org.uk/2008/foaf_ssl/tests/test-harness.pl) would take the manifest as input and run each test against an endpoint which is what's being tested. The endpoint is a WebID-secured script which simply echoes out a text/plain document consisting of a single line: a dash if authentication is unsuccessful; the WebID URI otherwise. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/20110130230706.4b090508%40miranda.g5n.co.uk Re: WebID-ISSUE-11 (bblfish): define an inverse of cert:identity [ontologies] 2011-01-30T23:07:06 2011-01-30T23:07:06 2011-01-30T23:07:06 On Sun, 30 Jan 2011 18:33:49 +0100 Dominik Tomaszuk <ddooss@wp.pl> wrote: > In HTML5 inverse can be represented by @data-rev custom data > attribute. data-foo is essentially useless for our purposes. It's an extension point for site authors to use, but that third-party services and standards are explicitly forbidden from building upon. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> On Sun, 30 Jan 2011 18:33:49 +0100 Dominik Tomaszuk <ddooss@wp.pl> wrote: > In HTML5 inverse can be represented by @data-rev custom data > attribute. data-foo is essentially useless for our purposes. It's an extension point for site authors to use, but that third-party services and standards are explicitly forbidden from building upon. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1296486262.21876.188.camel%40ophelia2.g5n.co.uk Re: Some further thoughts on the default profile issue ( ISSUE-78 and ISSUE-73 ) 2011-01-31T15:04:26 2011-01-31T15:04:26 2011-01-31T15:04:26 On Mon, 2011-01-31 at 10:44 +0100, Ivan Herman wrote: > However, from a spec writing and definition point of view, it may also > simplify one thing. The current rule is that if we have a CURIE, but > the prefix does not resolve to a defined URI, then the whole CURIE is > considered to be a full URI. This is how we could accommodate having > @rel="http://www.example.org/bla". But... we could also r... On Mon, 2011-01-31 at 10:44 +0100, Ivan Herman wrote: > However, from a spec writing and definition point of view, it may also > simplify one thing. The current rule is that if we have a CURIE, but > the prefix does not resolve to a defined URI, then the whole CURIE is > considered to be a full URI. This is how we could accommodate having > @rel="http://www.example.org/bla". But... we could also remove this > thing altogether (thereby making things simpler and closer to RDFa > 1.0. Instead, we could agree that the default profile would include > the prefix mapping 'http' -> 'http:' (and the same for a bunch of > other http schemes). That would work for "http:", but not for, say, "urn:". Why? Take for example the mapping "urn"=>"urn:". We want to then represent the IRI <urn:isbn:0123456789> as a CURIE. The suffix part of a CURIE is defined as an irelative-ref (from the IRI spec). This in turn is defined as an irelative-part optionally followed by a query string and fragment. Focusing on the irelative-part, it can be one of: 1. something that has an authority (which will always start "//", so not relevant here) 2. an absolute path (which will always start "/", so ditto) 3. an ipath-noscheme 4. empty OK, so clearly if we're representing that ISBN IRI as a CURIE, we're needing to use ipath-noscheme, but drilling down into the definition of that, an ipath-noscheme cannot contain any colons before its first slash (it's not required to contain a slash though). So the mapping "urn"=>"urn:" cannot be used to create a CURIE for <urn:isbn:0123456789>. (Which is not to say that this IRI can't be represented as a CURIE - it can - you just need to create a different mapping, such as "urn-isbn"=>"urn:isbn:".) A possible fix would be to broaden the allowed syntax for CURIEs. The suffix part of a CURIE (a.k.a. reference) would be defined as any string containing no whitespace characters. (And we do already define whitespace.) It would not surprise me if we discovered that many RDFa implementations already use that definition. [ Aside: the current definition of CURIE needs fixing anyway. The empty string (i.e. no prefix, no colon and no suffix) is allowed as a CURIE, which will map to the "no prefix" mapping with nothing appended. However, it's impossible to detect an empty string CURIE in a whitespace-delimited list; and we do not interpret datatype="" as being the empty string CURIE. We should almost certainly explicitly forbid the use of the empty string as a CURIE. (Though we should still allow it as a safe CURIE.) ] In general I'm in favour of this suggestion, but I do think it needs to be combined with this broader syntax definition for CURIEs. We'd need to discuss which URI schemes get included in the default profile. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1296553860.21876.212.camel%40ophelia2.g5n.co.uk Re: Documenting implicit assumptions? 2011-02-01T09:51:07 2011-02-01T09:51:07 2011-02-01T09:51:07 On Mon, 2011-01-31 at 18:07 +0000, Nathan wrote: > Well historically many other issues have been brought up and > consequently rejected or ignored, tell me what has changed in the > protocol since FOAF+SSL [1] almost 3 years ago? > [1] http://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global Since that document? In terms of the protocol itself, we've got a reasonably stable vocab for desc... On Mon, 2011-01-31 at 18:07 +0000, Nathan wrote: > Well historically many other issues have been brought up and > consequently rejected or ignored, tell me what has changed in the > protocol since FOAF+SSL [1] almost 3 years ago? > [1] http://blogs.sun.com/bblfish/entry/foaf_ssl_creating_a_global Since that document? In terms of the protocol itself, we've got a reasonably stable vocab for describing X.509 certificates; and we've decided on subjectAltName as the place to announce the WebID URI. Not much, but nevertheless important steps for interoperability. That blog post was not the beginning though, but the culmination of a period of discussions on the semantic-web@w3.org mailing list where a lot of changes were made. If you go back to: http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0207.html You'll see quite a bit has changed. The WebID URI was previously announced in the HTTP "From" header. And the client's WebID profile previously included not a modulus and exponent but the key's serial number. (Which doesn't work by the way - the serial number is too easy to forge, though I didn't realise that back then. Henry's innovation of using the modulus and exponent was a critical one.) I think you'll see a pattern like this with a lot of inventions. A period of rapid changes at the start, followed by a longer period of slower refinements - many of which are important, but none of which are earth-shattering. (I bet in those first few weeks, they must have tried tonnes of different shapes, but since then development of the wheel has been mostly bikeshedding.) -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1296557861.21876.249.camel%40ophelia2.g5n.co.uk Re: Documenting implicit assumptions? 2011-02-01T10:57:46 2011-02-01T10:57:46 2011-02-01T10:57:46 On Mon, 2011-01-31 at 19:59 +0000, Nathan wrote: > subjectAltName tightly binds WebID to x509v3 certificates, x509v3 > certificates with subjectAltName extensions are very hard to produce > with common libraries (unless you have a custom setup - e.g. > openssl). Point and click certificate generation (on Linux and similar - requires OpenSSL and Gambas): http://buzzword.org.uk/2008/foaf_ssl/Ma... On Mon, 2011-01-31 at 19:59 +0000, Nathan wrote: > subjectAltName tightly binds WebID to x509v3 certificates, x509v3 > certificates with subjectAltName extensions are very hard to produce > with common libraries (unless you have a custom setup - e.g. > openssl). Point and click certificate generation (on Linux and similar - requires OpenSSL and Gambas): http://buzzword.org.uk/2008/foaf_ssl/MakeWebIDCert/ > is subjectAltName IRI compatible? HTTP isn't IRI compatible. Very few protocols are. But luckily that doesn't matter because there is a mapping from IRIs to URIs - for every valid IRI you can calculate an equivalent URI. In fact the only official syntax definition for IRIs exclusively defines them in terms of a mapping to URIs. (To paraphrase, "if a Unicode string processed this way results in a valid URI, then what you started with was an IRI".) > use of content negotiation on webid URI dereferencing limits usage to > HTTP. Who says you need to conneg? A WebID profile with a single representation is perfectly fine. This could be an "ftp:" URI, or even (potentially) a "data:" URI. (Anyone played around with "data:" WebIDs yet? I've been thinking about them for some time, but my OpenSSL wizardry is not quite up to it yet.) > use of RDF requires RDF support, use of XML requires XML support, use > of HTML+RDFa requires DOM and RDFa support. Use of the network stack requires an Internet connection. So what? Virtually any technology these days has a long list of dependencies. The number of people programming on bare metal these days is not statistically significant. libxml + librdf + libraptor comes in pretty small compared to the amount of code needed to, say, playback video found on the web. > no required serialization makes interoperability nigh on impossible. Yes, I agree here. My stance on it is that WebID profiles MUST be available in at least one W3C Recommended serialisation of RDF. If they're available in other formats too, and if consumers of the profiles prefer the other formats, then more power to them. Mandating that they be available in one blessed serialisation of RDF is not a big ask. It's not like the W3C comes up with new ones every day - there was the XML one back in the 1990s; and there was RDFa[1] in 2008. That's two. Yes, there will probably be a few more over the next few years, with the RDFa working group expecting to publish an RDFa 1.1 Recommendation real soon now, and the RDF working group expected to publish Turtle and some sort of JSON serialisation. But we'll still be able to count them on one hand. If we think this is too uncontrolled we could stipulate that the mandated list of serialisations for WebID is the list of W3C Recommended RDF serialisations at the time of WebID's publication. So serialisations recommended after WebID is published don't get on the list. ____ 1. One could argue that RDFa is not a single serialisation, but a family of them. XHTML+RDFa and SVG+RDFa are already Recommendations, HTML+RDFa is on the Rec track, and I'm personally trying to get Atom+RDFa published as a working group note. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1296559093.21876.260.camel%40ophelia2.g5n.co.uk Re: WebID-ISSUE-18: Transfer Protocol Independence [WebID Spec] 2011-02-01T11:18:16 2011-02-01T11:18:16 2011-02-01T11:18:16 On Tue, 2011-02-01 at 10:18 +0000, WebID Incubator Group Issue Tracker wrote: > The WebID Protocol currently defines and constrains the usage of WebID > to the HTTP transfer protocol, however TLS is a /transport/ protocol > which can be used with multiple /transfer/ and /application/ > protocols. While the current draft does define it for HTTP-over-TLS, I don't think it *constrains* it. There's n... On Tue, 2011-02-01 at 10:18 +0000, WebID Incubator Group Issue Tracker wrote: > The WebID Protocol currently defines and constrains the usage of WebID > to the HTTP transfer protocol, however TLS is a /transport/ protocol > which can be used with multiple /transfer/ and /application/ > protocols. While the current draft does define it for HTTP-over-TLS, I don't think it *constrains* it. There's nothing to stop people using WebID with other protocols, we just don't explain how to do it. (I think people have experimented with WebID and XMPP-over-TLS.) This is similar to how RDFa was initially defined in XHTML. Yahoo started promoting RDFa in Atom almost immediately. There are advantages to limiting the scope of the definition, at least initially. Many of the RDFa Working Group's current issues resolve around where the border between RDFa 1.1 and its various host languages lies. If we can avoid some of that by saying we define it only for HTTPS, then great. We could add a note saying something along the lines of "This document defines an authentication technique for HTTPS. The same principles could be applied to other TLS-secured protocols, though how to apply these principles to those protocols is not covered in this document." -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk> http://tobyinkster.co.uk/message/1296562025.21876.289.camel%40ophelia2.g5n.co.uk Re: WebID-ISSUE-24: Privacy issues from WebID URI dereferencing [WebID Spec] 2011-02-01T12:07:08 2011-02-01T12:07:08 2011-02-01T12:07:08 On Tue, 2011-02-01 at 11:27 +0000, WebID Incubator Group Issue Tracker wrote: > Namely, privacy is not guaranteed, an intermediary (or a > "webid/profile host") can detect a request from a server (say a bank, > a private site, an adult site, a gambling site) to a users WebID URI > and thus know the user has attempted to identify on said site. s/know the user has/suppose the user may have possibl... On Tue, 2011-02-01 at 11:27 +0000, WebID Incubator Group Issue Tracker wrote: > Namely, privacy is not guaranteed, an intermediary (or a > "webid/profile host") can detect a request from a server (say a bank, > a private site, an adult site, a gambling site) to a users WebID URI > and thus know the user has attempted to identify on said site. s/know the user has/suppose the user may have possibly/ My WebID is <http://tobyinkster.co.uk/#i>. Of all HTTP requests for "/" on my domain name, WebID authentication attempts make up a pretty small fraction. > This may be something which the protocol needs to address (for > instance, force TLS for dereferencing), or may be something that is > best noted and addressed by specification text (note as a security > consideration and give advice). Forcing TLS doesn't help much. The host of the profile still knows which profile was requested and when. (They probably log it.) This problem can be somewhat mitigated by providing multiple WebIDs in a single document. e.g. if Alice and Bob's WebIDs are: http://example.com/smith-family.rdf#alice http://example.com/smith-family.rdf#bob Then when an HTTP request for <http://example.com/smith-family.rdf> is made, nobody listening knows who (if anybody) is trying to authenticate. Adult sites, and others which may want to protect their users privacy, could make their HTTP requests via a proxy. -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>