- From: Jonathan Rees <jar@creativecommons.org>
- Date: Fri, 4 Apr 2008 13:36:23 -0400
- To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
- Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "public-awwsw@w3.org" <public-awwsw@w3.org>
On Apr 4, 2008, at 12:45 PM, Booth, David (HP Software - Boston) wrote: > Descriptions linked from a Resource-Description header can allow > the URI owner to provide useful assertions about the resource, even > though they would be ancillary assertions rather than core > assertions. I thought that was what page > http://esw.w3.org/topic/FindingResourceDescriptions > was seeking. Yes, but such information could be found in many ways, as you point out, and if you did, then it would have no relation to your URI declaration scenario, so the use case would have to do with something else, not with URI declarations.. Can you provide a more complete use case scenario that specifically has to do with URI declarations? I will need such a thing if I'm going to include URI declarations in some future summary document. I actually have a very hard time coming up with use cases for follow- your-nose in general - the only ones I know of are web closure, semantic browsing (eg tabulator), and self describing web, and none of these seems very compelling to me - they don't have constituencies saying "I'm having a hard time getting my work done, and if only follow-your-nose worked better, I'd be much happier". Maybe it works really well right now, and everyone's happy, and the use cases are invisible because there's no problem... > However, I'm now wondering if by "Uniform Access to Descriptions" > you really meant "uniform access to *core* assertions". The key > difference is that use of a URI only implies agreement with its > *core* assertions -- not its ancillary assertions. Which was your > intent? And if your intent was ancillary assertions, then why does > it matter whether the URI owner provided them? If you look at the use cases on the page you'll see that none of them cares much about definitions of names or URI declarations of semantic web or anything of that sort. A Creative Commons license and a POWDER recommendation are certainly not core assertions. The activity around the Link: header has to do with getting the TAG to understand the need for Mark Nottingham's proposal and, if possible, to endorse it. If we won't endorse it (or an alternative) then I'll try to get the group to come up with an alternative path. Personally I took an interest because I thought it would be nice for Link: (or whatever) to become a way to provide *any* kind of assertion about the resource in situations where you couldn't put the assertions in the content; this could have the effect of bringing huge numbers of documents into the semantic web (i.e. allow you to say and infer interesting things about them) and more generally to provide a general follow-your-nose mechanism for the semantic web, since Link: (or whatever) is insensitive to whether the thing is an IR or not and therefore avoids that question completely. 303 even when it seems to work has its problems. (I've recently learned that the idea of using Link: to get to RDF metadata is at least 10 years old.) Whether your nose eventually arrives at "core" or "ancillary" assertions is of less interest to me, in this context. Anyhow now that I've allowed myself to be drafted to work on the problem I have to represent the TAG, POWDER, Atom, and others, so my own intent is not so important... I would think that with Mark's proposal you might be happy to say something like Link: my-declaration.rdf; rel="http://dbooth.org/has- uri-declaration" ? Then it's clear that the document linked is intended (by the web server) to be a declaration (core assertions) of some URI. With 303 this intent has not been communicated. (You could make has-uri-declaration a subproperty of something more general, so that the declaration document could serve other purposes as well.) (There are details around figuring out which URI is being declared and so on, but I think they could be worked out.)
Received on Friday, 4 April 2008 17:37:15 UTC