Re: [whatwg] Microdata and Linked Data
(I trimmed public-html from the CC list to avoid cross-posting, and because the whatwg list has had most of the traffic on this topic so far; please feel free to forward this to public-html if you would rather discuss that there instead.) On Fri, 24 Jul 2009, Peter Mika wrote: The use of a URI as the value of the id attribute. It seems to me there is actually nothing in the spec that would stop this: Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute. This is great because in principle I could do something like: section id=http://john.example.com#hedral; item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 /section I assume you can achieve something similar with the about property but that would require me to write: section item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section This is longer by itself, and if I want an internal identifier as well, than I have to write: section id=hedral item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section In practice, all the use cases that were brought up that needed to identify the item were cases where there was a URL already in the page, e.g. in a link or an img or a video element, such that it actually ends up better if we use itemprop=about rather than having a dedicated attribute (like id= or about=) for identifying types. Are there use cases where this is not the case? For example, when would you need to have an internal identifier? The other area that could be possibly improved is the connection of type identifiers with ontologies on the web. I would actually like the notion of reverse domain names if -- there would be an explicit agreement that they are of the form xxx.yyy.zzz.classname -- there would be a registry for mappings from xxx.yyy.zzz to URIs. For example, org.foaf-project.Person could be linked to http://xmlns.com/foaf/0.1/Person by having the mapping from org.foaf-project to http://xmlns.com/foaf/0.1/. It wouldn't be perfect, the FOAF ontology as you see is not at org.foaf-project but at com.xmlns. However, it would be a step in the right direction. What problem is this solving? I would consider adding the sameAs property as part of the standard vocabulary. This is a term from the OWL vocabulary that is widely used in the Linked Data world for connecting entities that are deemed to be equivalent. Alternatively, we could add the entire RDFS and OWL vocabulary to the spec. Could you elaborate on this? What are the use cases that this is intended to address? What do you mean by adding the sameAs property? I don't expect that writing full URIs for property names will be appealing to users, but of course I'm not a big fan either of defining prefixes individually as done in RDFa with the CURIE mechanism. Still, prefixes would be useful, e.g. foaf:Person is much shorter to write than com.foaf-project.Person and also easier to remember. So would there be a way to reintroduce the notion of prefixes, with possibly pointing to a registry that defines the mapping from prefixes to namespaces? section id=hedral namespaces=http://www.w3c.org/registry/; item=animal:cat h1 itemprop=animal:nameHedral/h1 /section Here the registry would define a number of prefixes. However, the mechanism would be open in that other organizations or even individuals could maintain registries. I'm definitely against any in-page indirection mechanism, because we have seen with XML Namespaces (and with RDFa) that prefixes are simply a huge source of problems. However, there actually already is a registry for registering strings that start with a keyword and a colon: the scheme registry. So if animals become important enough that they need their own scheme, I guess people could register them that way. Alternatively, a short domain followed by a keyword seems like a reasonable option: instead of animal:cat, have org.animal.cat: it's only four more characters. (Actually, with ICANN considering opening up TLDs, people could just register those: animal.cat is a valid reverse DNS label if animal is a TLD!) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Microdata and Linked Data
Hello Ian Ian Hickson wrote: I'm definitely against any in-page indirection mechanism, because we have seen with XML Namespaces (and with RDFa) that prefixes are simply a huge source of problems. They are indeed, XML namespaces fixed one problem calling different things by the same name but they created another problem of calling the same thing by different names, Prefixes are not themselves bad, misunderstood or any kind of indirection mechanism, they are just short hand urls, they are actually quite intuitive if used correctly. RDFa Is currently trying to solve its problems with xmlns, is just a minor design flaw, xmlns is used for structure not content and they realize that issue. Best wishes -- Martin McEvoy http://weborganics.co.uk/
[whatwg] Microdata and Linked Data
Hi All, I've been taking a closer look at microdata. While I like the proposal in general, in particular the chance to unite microformat style annotations with some of the Semantic Web formalism (such as URIs for objects), there are still a number of points that I feel could be improved. So here are my proposals for discussion: #1 The use of a URI as the value of the id attribute. It seems to me there is actually nothing in the spec that would stop this: Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute. This is great because in principle I could do something like: section id=http://john.example.com#hedral; item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 /section I assume you can achieve something similar with the about property but that would require me to write: section item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section This is longer by itself, and if I want an internal identifier as well, than I have to write: section id=hedral item=org.example.animal.cat com.example.feline h1 itemprop=org.example.name com.example.fnHedral/h1 a itemprop=about href=http://john.example.com#hedral/ /section #2 The other area that could be possibly improved is the connection of type identifiers with ontologies on the web. I would actually like the notion of reverse domain names if -- there would be an explicit agreement that they are of the form xxx.yyy.zzz.classname -- there would be a registry for mappings from xxx.yyy.zzz to URIs. For example, org.foaf-project.Person could be linked to http://xmlns.com/foaf/0.1/Person by having the mapping from org.foaf-project to http://xmlns.com/foaf/0.1/. It wouldn't be perfect, the FOAF ontology as you see is not at org.foaf-project but at com.xmlns. However, it would be a step in the right direction. #3 I would consider adding the sameAs property as part of the standard vocabulary. This is a term from the OWL vocabulary that is widely used in the Linked Data world for connecting entities that are deemed to be equivalent. Alternatively, we could add the entire RDFS and OWL vocabulary to the spec. #4 I don't expect that writing full URIs for property names will be appealing to users, but of course I'm not a big fan either of defining prefixes individually as done in RDFa with the CURIE mechanism. Still, prefixes would be useful, e.g. foaf:Person is much shorter to write than com.foaf-project.Person and also easier to remember. So would there be a way to reintroduce the notion of prefixes, with possibly pointing to a registry that defines the mapping from prefixes to namespaces? section id=hedral namespaces=http://www.w3c.org/registry/; item=animal:cat h1 itemprop=animal:nameHedral/h1 /section Here the registry would define a number of prefixes. However, the mechanism would be open in that other organizations or even individuals could maintain registries. Looking forward to your feedback, Peter
Re: [whatwg] Microdata and Linked Data
On Fri, Jul 24, 2009 at 1:07 PM, Peter Mikapm...@yahoo-inc.com wrote: [...] #2 The other area that could be possibly improved is the connection of type identifiers with ontologies on the web. I would actually like the notion of reverse domain names if -- there would be an explicit agreement that they are of the form xxx.yyy.zzz.classname -- there would be a registry for mappings from xxx.yyy.zzz to URIs. For example, org.foaf-project.Person could be linked to http://xmlns.com/foaf/0.1/Person by having the mapping from org.foaf-project to http://xmlns.com/foaf/0.1/. It wouldn't be perfect, the FOAF ontology as you see is not at org.foaf-project but at com.xmlns. However, it would be a step in the right direction. [...] #4 I don't expect that writing full URIs for property names will be appealing to users, but of course I'm not a big fan either of defining prefixes individually as done in RDFa with the CURIE mechanism. Still, prefixes would be useful, e.g. foaf:Person is much shorter to write than com.foaf-project.Person and also easier to remember. So would there be a way to reintroduce the notion of prefixes, with possibly pointing to a registry that defines the mapping from prefixes to namespaces? section id=hedral namespaces=http://www.w3c.org/registry/; item=animal:cat h1 itemprop=animal:nameHedral/h1 /section Here the registry would define a number of prefixes. However, the mechanism would be open in that other organizations or even individuals could maintain registries. IMO, both of these proposals are quite related. However, you added substantial differences I can't really understand between them. For #2 you suggest to have a sort of centralized registry of mappings between the reversed domains and the vocabularies they refer to. What happens if next year I have to use an unusual vocabulary for my site that is not included on the registry? Would I have to get the vocabulary included on the registry before my pages' microdata can be mapped to the appropriate RDF graph? On the other hand, on #4, you are opening the gate to independent entities (be them organizations or individuals) to define the prefixes they would be using for their pages' metadata: why don't apply this to #2 as well? IMO, it would be more important for #2 than for #4; since #4 only provides syntax sugar while #2 enables something that would be undoable without it (mapping Microdata to arbitrary RDF). About #1, I'm not sure about what you are exacly proposing, so I can't provide much feedback on it. Maybe you could make it a bit clearer: are you proposing any specific change to the spec? If so, what would be the change? If now, what are you proposing then? Finally, about #3 I'm not familiar with the OWL vocabulary, so I can't say too much about it. But if your second proposal gets into the spec, then this would become just syntax sugar, since any property from any existing RDF vocabulary could be expressed; and if #4 also got in, the benefit of built-in properties would be minimal compared to using a reasonably short prefix (such as owl:). Just my two cents. Regards, Eduard Pascual
Re: [whatwg] Microdata and Linked Data
Yes, #2 and #4 are quite related in that they both concern the abbreviation mechanism for URIs and might be considered alternative proposals. On the other hand, on #4, you are opening the gate to independent entities (be them organizations or individuals) to define the prefixes they would be using for their pages' metadata: why don't apply this to #2 as well? IMO, it would be more important for #2 than for #4; since #4 only provides syntax sugar while #2 enables something that would be undoable without it (mapping Microdata to arbitrary RDF). Yes, the idea of distributing the registration could be applied to #2. About #1, I'm not sure about what you are exacly proposing, so I can't provide much feedback on it. Maybe you could make it a bit clearer: are you proposing any specific change to the spec? If so, what would be the change? If now, what are you proposing then? Removing the about property, showing how id can be used in this way, and changing the description of how you transform an HTML5 document to RDF. Finally, about #3 I'm not familiar with the OWL vocabulary, so I can't say too much about it. But if your second proposal gets into the spec, then this would become just syntax sugar, since any property from any existing RDF vocabulary could be expressed; and if #4 also got in, the benefit of built-in properties would be minimal compared to using a reasonably short prefix (such as owl:). I agree... I'm personally not so attached to reverse domain names, but I might have missed a lot of the previous discussions on why they are good to have. In any case, my intention was to get the discussion restarted around these issues: it seems to me there was a lot of discussion at the very beginning on microdata vs. RDFa when microdata was first proposed, but then the discussion died without necessarily finding the best solution (for my taste). Cheers, Peter
Re: [whatwg] Microdata and Linked Data
Fair point. Just brainstorming here: how about making about an attribute? div item id=amanda about=http://;/div pName: span subject=amanda itemprop=nameAmanda/span/p We still have two identifiers, but at least giving the URI is simplified. Best, Peter Julian Reschke wrote: Peter Mika wrote: Hi All, I've been taking a closer look at microdata. While I like the proposal in general, in particular the chance to unite microformat style annotations with some of the Semantic Web formalism (such as URIs for objects), there are still a number of points that I feel could be improved. So here are my proposals for discussion: #1 The use of a URI as the value of the id attribute. It seems to me there is actually nothing in the spec that would stop this: ... IDs like that would be very hard to use as fragment identifier... ... BR, Julian
