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

On Oct 15, 2011, at 16:28 , Gregg Kellogg wrote:

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

I am certainly in favour. 

Ivan



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


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf