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

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

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sat, 15 Oct 2011 14:45:15 +0100
Cc: public-html-data-tf@w3.org
Message-Id: <5D3E0DBC-99E0-411A-9157-101E3DA39323@jenitennison.com>
To: Gregg Kellogg <greggkellogg@gmail.com>

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

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>

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" ;
     ] ;

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.



[1] http://dev.w3.org/html5/md/Overview.html#typed-item
Jeni Tennison
Received on Saturday, 15 October 2011 13:45:48 UTC

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