- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Thu, 28 Jul 2011 14:17:39 -0400
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: Jeni Tennison <jeni@jenitennison.com>, Michael Hausenblas <michael.hausenblas@deri.org>, Richard Cyganiak <richard.cyganiak@deri.org>, "www-tag@w3.org List" <www-tag@w3.org>
On Thu, Jul 28, 2011 at 1:19 PM, Tim Berners-Lee <timbl@w3.org> wrote: > > On 2011-07 -27, at 17:25, Jeni Tennison wrote: > > [...] > > From what I can see, the documented meaning of http://schema.org/startDate > and http://schema.org/endDate is different depending on whether the item is > a TVSeason/TVSeries or an Event. IIRC, one reason that Hixie gives for the > complexity of the generated property URIs in the current microdata/RDF > mapping is to ensure that properties with potentially different semantics > (that appear on items of different types) have distinct URIs. But of course > when you have inheritance in a vocabulary like schema.org, you don't want > distinct URIs by type. > > Makes me think you can't have a generic mapping that gives a good output in > RDF terms. > > > Yes. It is important that the semantics of the property is the same, as this > gives much greater power of data re-use. > I think the spec can't just specify the syntax, it has to specify the RDF > mapping. It is only well-defined when it has defined the > mapping from the HTML DOM into abstract RDF triples. > People don't have to use the DOM or the RDF model in their code > but as those are the abstractions which we have written a lot of > code in terms of, that is the reference point for the spec to > produce interoperability. > It can't be a mapping which maps to a notional URI which is hopeless > in practice. It has to map to a URI which looks just like the normal sort > of URIs > which RDF systems use, supported on the web as linked data, like FOAF, etc. Figuring out what the standardized mapping (if any is possible) from microdata to RDF is should be the first goal of the task force. Having the RDF mapping dropped from the microdata spec actually helps here, as it punts the ball into the hands of the community that cares - i.e. the RDF community. Hixie obviously doesn't care, and neither does the wider Web community, as they tend to use JSON anyways. However, the RDF community could upon close look at the microdata spec then request changes to the microdata spec if the mappings show ambiguities etc. in microdata, just like any other group. Also, determining the overlap of RDFa and microdata and whether or not the RDFa 1.1 spec can be effectively merged/super-setted with microdata would be the second goal. This could I imagine result in substantial simplification or even elimination of the RDFa 1.1 spec (i.e. RDFa 1.1 could become "modificaitons and a standard mapping to RDF form microdata") would be great, so that we get a single way to put data on the Web inside of HTML. I haven't taken a deep look at the issue yet, but I think it's very possible that the first goal may not work in a simple manner, as noted above. In this case, I think the GRDDL experience - in which custom mappings were used to map from microformats to RDF, shows that standardized per vocabulary extraction is not very useful for developers in a _decentralized_ manner. Most of the GRDDL mappings never got resued (perhaps due to being in XSLT). Instead, ad-hoc code libraries seem to be the way to go with custom mappings. However, ad-hoc custom mappings tend to confuse developers, would would probably rather have the embedding of data into HTML be both simple and transparent (microdata) and expressive (RDFa, at least for the RDF community). Whether or not these two desiderata are contradictory is an empirical matter. > Tim > > Cheers, > > Jeni > -- > Jeni Tennison > http://www.jenitennison.com > > > > >
Received on Thursday, 28 July 2011 18:18:24 UTC