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

Re: Generating property URIs (Was: Re: URIs for properties at schema.org)

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Sat, 15 Oct 2011 10:28:01 -0400
To: Jeni Tennison <jeni@jenitennison.com>
CC: Gregg Kellogg <greggkellogg@gmail.com>, "public-html-data-tf@w3.org" <public-html-data-tf@w3.org>
Message-ID: <5A64CE57-89B9-4F67-ADE7-B080CA3F7852@kellogg-assoc.com>
On Oct 15, 2011, at 6:46 AM, "Jeni Tennison" <jeni@jenitennison.com> wrote:

> Gregg,
> 
> On 15 Oct 2011, at 00:11, Gregg Kellogg wrote:
>> If there is no @itemtype, better to generate something rather than nothing. So, if base were http://example.com/foo, @itemprop would resolve to http://example.com/name.
> 
> As you know, I do think it's better to generate something than nothing, but I think it would be better in these circumstances (no itemtype, short name property) to generate a URI that was scoped within the document in which the markup is found, by pre-pending a # before resolving the property name, eg http://example.com/foo#name in this case. I know it means that the property URIs are likely to be different from page to page within a site, but mapping to non-hash URIs within the publisher's URI space seems likely to cause confusion.
> 
> (The same is true to a certain extent for URIs derived from type URIs, but I think that vocabulary authors are more likely to understand and support this side-effect.)

Yes, understood, I'd like to hear some more feedback on this issue. I'm certainly open to doing this, if it's the consensus opinion.

> Another situation that needs to be handled is when the property is on an item that doesn't itself have an @itemtype but is a typed item [1] by virtue of being the value of a property of a typed item. For example, in:
> 
> <section id="jack" itemscope itemtype="http://microformats.org/profile/hcard#vcard">
> <h1 itemprop="fn">
>  <span itemprop="n" itemscope>
>   <span itemprop="given-name">Jack</span>
>   <span itemprop="family-name">Bauer</span>
>  </span>
> </h1>
> ...
> </section>
> 
> The property URIs could be created using a hierarchical path with dot separators such as:
> 
>  @prefix hcard: <http://microformats.org/profile/hcard#>
> 
>  [] a hcard:vcard ;
>     hcard:fn "Jack Bauer" ;
>     hcard:n [
>       hcard:n.given-name "Jack" ;
>       hcard:n.family-name "Bauer" ;
>     ] ;
>     .
> 
> but I don't think most existing vocabularies are designed in that way, but rather with the nested properties taking on the vocabulary of the ancestor type:
> 
>  [] a hcard:vcard ;
>     hcard:fn "Jack Bauer" ;
>     hcard:n [
>       hcard:given-name "Jack" ;
>       hcard:family-name "Bauer" ;
>     ] ;
>     .

This is what the current process does.

> The current algorithm would I think give:
> 
>  [] a hcard:vcard ;
>     hcard:fn "Jack Bauer" ;
>     hcard:n [
>       <given-name> "Jack" ;
>       <family-name> "Bauer" ;
>     ] ;
>     .
> 
> which seems wrong.

Yes that would be wrong. What I describe is a restatement of Hixie's procedure: the original type is inherited, by setting the *current type* which is passed in the evaluation context to the generate triples step for this purpose. See 6.2.4.

> Cheers,
> 
> Jeni
> 
> [1] http://dev.w3.org/html5/md/Overview.html#typed-item
> -- 
> Jeni Tennison
> http://www.jenitennison.com
> 
> 
Received on Saturday, 15 October 2011 14:33:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 15 October 2011 14:33:34 GMT