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