- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Wed, 2 Nov 2011 12:56:38 -0400
- To: Lin Clark <lin.w.clark@gmail.com>
- CC: HTML Data Task Force WG <public-html-data-tf@w3.org>
- Message-ID: <FB2E5384-5362-4367-B6EE-5711FB50C9FF@kellogg-assoc.com>
Sent from my iPad On Nov 2, 2011, at 1:43 AM, "Lin Clark" <lin.w.clark@gmail.com<mailto:lin.w.clark@gmail.com>> wrote: Thanks Gregg for listing it out, that makes it really clear what to comment on. On Wed, Nov 2, 2011 at 3:58 AM, Gregg Kellogg <gregg@kellogg-assoc.com<mailto:gregg@kellogg-assoc.com>> wrote: 1) A Microdata processor uses a registry (with undefined format and update procedure for now) to control the behavior of property URI generation. +1 A registry is necessary. 2) A Microdata processor uses a registry (with undefined format and update procedure for now) to control the serialization of multi-valued properties. 0 I really dislike the idea of having to work with RDF lists because of the complexity they introduce to querying, but I know it's important for some use cases. 3) One property URI generation strategy is _vocabulary_, which defines a common URI to use for creating URIs for items with an @itemtype which begins with the vocabulary URI e.g., @itemtype=http://schema.org/Person, @itemprop=name => http://schema.org/name. Also @itemtype=http://schema.org/Person/Deceased, @itempropt=name => http://schema.org/name +1 4) One property URI generation strategy is _type_, which defines creates property URIs by appending a the property name to the itemtype URI separated by a '#' e.g. @itemtype=http://microformats.org/hcard, @itemprop=name => http://microformats.org/hcard#name -1 I don't think that this should use a hash by default. The registry should specify the base URI pattern to use, whether slash or hash (or potentially something else). We could potentially add another value, or a separate key/value to define the separator. 5) On property URI generation strategy is _base_, which creates a property URI by using the portion of the itemtype URI up to and including the final '#' or '/' e.g., @itemtype=http://schema.org/Person, @itemprop=name => http://schema.org/name. Also @itemtype=http://schema.org/Person/Deceased, @itempropt=name => http://schema.org/Person/name 0/+1 I'm confused on <base> because of the example. I don't think there is any situation where http://schema.org/Person/name would be a valid property name. This isn't the proper way to extend schema.org<http://schema.org> according to their extension mechanism. It should be something like http://schema.org/name<http://schema.org/Person/name>/deceased if there is a property that extends the name property. I picked this example just to illustrate the effect; not suggesting it would be valid for schema.org<http://schema.org>. I believe we would need <base> for a lot of RDF vocabularies though. My thought is that if it is registered, it will probably be _vocabulary_ for most existing RDF vocabularies. 6) The default URI generation strategy is _base_. 0 Maybe the default should be _vocabulary_. I think that a lot of new vocabulary developers outside the RDF community will use Schema.org<http://Schema.org> as their model. I think we can depend on the RDF community to register their vocabularies more than we can newbies, so perhaps the default should assume if it isn't registered, it's a vocab by someone who doesn't follow RDF URI conventions. The _vocabulary_ strategy requires a base URI; base doesn't require anything, which is why I suggest this as a default. 7) One multi-valued property serialization strategy is _unordered_, which creates triples for multiple values with a common subject and predicate. 0 8) One multi-valued property serialization strategy is _list_, which places all values in an RDF Collection (rdf:List) as the object of a triple. 0 9) There is no _contextual_ URI generation strategy, and the Microdata to RDF property generation is lossy with respect to JSON, in that properties of untyped sub-items will result in the same URI, rather than being distinct. +1 Thanks for yor feedback! Gregg
Received on Wednesday, 2 November 2011 16:58:26 UTC