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

Re: Proposal to resolve ISSUE-1

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 November 2011 16:58:27 GMT