- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Sun, 16 Oct 2011 00:19:06 -0400
- To: Jeni Tennison <jeni@jenitennison.com>
- CC: "public-html-data-tf@w3.org" <public-html-data-tf@w3.org>
On Oct 15, 2011, at 1:13 PM, "Jeni Tennison" <jeni@jenitennison.com> wrote: > Gregg, > > On 15 Oct 2011, at 15:28, Gregg Kellogg wrote: >> On Oct 15, 2011, at 6:46 AM, "Jeni Tennison" <jeni@jenitennison.com> wrote: >> 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. > > > I see it. I'm really very sorry, I should have read more closely! :( > > Have you given any thought to the handling of property URLs generated from non-HTTP-URL types? Hixie gave the examples [1]: > >> The URL is opaque, so "http://example.org/foo", "mailto:bar@invalid", and >> "uuid:171d010f-9aea-4f4d-af9e-30758eeb221e" could all be types defined to >> use the same vocabulary. > > I know that these are cases that are far removed from what people will actually do, but the mapping spec should really either handle them or explicitly say that they are out of scope and what the error behaviour is (eg no triples generated for items that use non-HTTP URI types / have types that don't share a namespace). Which way do you think we should go? Perhaps, if a type URI contains neither a "/" nor "#" we would separate add a hash and append the name, as you suggest for the base URI resolution. Ffrankly, I don't see the value for considering type URIs as purely opaque for RDF generation purposes. Gregg > Cheers, > > Jeni > > [1] http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0100.html > -- > Jeni Tennison > http://www.jenitennison.com >
Received on Sunday, 16 October 2011 04:19:38 UTC