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

Re: Proposal to resolve ISSUE-1

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 2 Nov 2011 20:39:12 +0000
Cc: HTML Data Task Force WG <public-html-data-tf@w3.org>
Message-Id: <ED44B365-C029-4480-9057-6D22BCE4BFB0@jenitennison.com>
To: Gregg Kellogg <gregg@kellogg-assoc.com>
Gregg,

I should say, as chair, that I don't think *we* need to make final decisions on any of this. It is more important for us to provide hooks within the draft and document the options and arguments as input to future standardisation by a Working Group.

On 2 Nov 2011, at 03:58, Gregg Kellogg wrote:
> The limited feedback so far on my previous proposal came down against using _contextual_ as the default property URI generation scheme, or even including it.
> 
> I'd like to get +1/-1 from people on resolving these issues:
> 
> 1) A Microdata processor uses a registry (with undefined format and update procedure for now) to control the behavior of property URI generation.

-1 (if dynamic) / 0 (if static)

It depends on the nature of the registry.

Registries are fine as a mechanism for providing a central location at which information can be found about something. For example, if someone who was configuring a processor were to use information from a registry to work out how to configure it, but not as a place where implementations must dynamically look for that information in order to properly function.

In the dynamic case, a registry would make it hard to experiment because vocabularies have to be added to the registry before they can be used. Having implementations check a registry effectively makes their behaviour reliant on network connectivity, which makes them fragile.

Registries also create all kinds of bureaucratic headaches around hosting and governance.

> 2) A Microdata processor uses a registry (with undefined format and update procedure for now) to control the serialization of multi-valued properties.

-1 / 0 as above

> 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 (as we see this in the wild)

> 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

0 (I'm not convinced that this option is really used except in artificial examples, but I don't see the harm in describing it in the spec)

> 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

+1 (as this is how most vocabularies work)

> 6) The default URI generation strategy is _base_.

0

> 7) One multi-valued property serialization strategy is _unordered_, which creates triples for multiple values with a common subject and predicate.

+1

> 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.

+1

> 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

I don't see the harm in describing this strategy within the draft, as an option for a future WG to consider, particularly if we can spec it to an extent where it is not as sucky as the _contextual_ URI generation algorithm in Hixie's microdata/RDF mapping.


(I dunno, maybe the right thing to do is to go for the easy-to-use-and-mostly-right (base + unordered) option and describe how to use GRDDL with microdata for those situations where people need more control in what RDF is generated. But then, GRDDL processing is dependent on publisher rather than vocabulary author.)

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Wednesday, 2 November 2011 20:39:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 November 2011 20:39:37 GMT