W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: Mapping Microdata to RDF

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 26 Oct 2011 13:15:13 +0100
Cc: Toby Inkster <tai@g5n.co.uk>, Gregg Kellogg <gregg@kellogg-assoc.com>
Message-Id: <0EB7A417-36E7-4FB4-90CC-265DF30CC377@jenitennison.com>
To: HTML Data Task Force WG <public-html-data-tf@w3.org>

On 26 Oct 2011, at 12:53, Toby Inkster wrote:
> A few comments on
> <https://dvcs.w3.org/hg/htmldata/raw-file/24af1cde0da1/microdata-rdf/index.html>...
> 1. Creating RDF collections for repeated properties is an awful idea.
> Consider the example in appendix A. The object of the frbr:realization
> is a blank node of type rdf:List. According to the FRBR Core vocab, the
> range of frbr:realization is frbr:Expression. If we assume that
> frbr:Expression and rdf:List are disjoint classes (which seems to be a
> reasonable assumption), you've created a logical contradiction. So the
> graph generated by parsing the microdata does not match up to the
> expectations of the vocabulary, and probably does not match up to the
> expectations of the page author.
> I can understand the desire to preserve document order to cover
> certain use cases, but it's possible to do that outside of the RDF
> model. (e.g. Rather than parse the page as a whole and operate on the
> graph returned, you could supply a callback function to the parser to
> be called as each triple is extracted from the page. The callback
> function would then receive triples in document order.)
> TLDR: generating collections breaks ranges.

Just thinking around this problem, might one way to square this be to generate separate graphs: one containing the separate values in multiple triples and another generating the values as lists? Applications could then look into the "ordered" graph only when/if they needed that information.

Jeni Tennison
Received on Wednesday, 26 October 2011 12:15:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:25 UTC