- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Wed, 7 Feb 2007 15:50:04 -0500
- To: "Jonathan Rees" <jonathan.rees@gmail.com>, "Matthias Samwald" <samwald@gmx.at>
- Cc: "public-semweb-lifesci" <public-semweb-lifesci@w3.org>
I haven't been able to follow this discussion entirely, so please forgive me if I missed something that should have been evident. In general I like the idea of using an ontology to express URI resolution information, but I am also partial to Xiaoshu's pleas for simplicity. To my mind, the ideal would be a simple ontology that can be straightforwardly implemented *without* the use of an OWL reasoner -- perhaps just using string substitution and the like. However, I do not yet have a clear enough understanding of the use cases and proposed solutions to know whether that ideal would be feasible. > From: Jonathan Rees > This leads me to think that the main relation we are looking for is > one between an information resource (which may have multiple URI's) > and a *string* that is a URL that will help us to get its > representation. Maybe this is obvious. Actually, I do not see it that way. It seems to me that the most important use case is one that involves pattern-based transformations of URIs as strings, rather than specifying relationships between individual URI strings and resource locations, so that simple rules can specify transformations that affect large numbers of URIs. For example, if you have old URIs that start with http://old/ , and the resources now reside at corresponding locations starting with http://new/ , then you can simply specify the pattern matching rule of transforming: http://old/(.*)$ to http://new/\1 This transformation is entirely in the space of treating URIs as strings, and it only pertains to information *retrieval* -- not resource *naming*. The old names can still be used in RDF with their existing semantics, and the application that is doing RDF reasoning using the old URIs never has to know or care that the information was retrieved using some other URIs. In other words, even though the transformation of a particular URI http://old/foo to http://new/foo can be interpreted as asserting a semantic relationship between the string http://old/foo and the information resource that http://new/foo names, it seems to me that most applications that are using the old URIs would not and should not care about that relationship. It could be hidden in a proxy, for example. Of course, a URI resolution proxy may care about such relationships if there were additional assertions made about the resulting information resources. Is that what you had in mind? And would these additional assertions really need to be made about the individual information resources? Or would it be adequate for them simply to be associated with the URI transformation rule? I guess the use cases beyond URI transformation are not yet crystal clear to me. > > The www notion of 'resource' includes things that have different > representations (bits) at different times, and things with operations > other than GET, so while I agree with the goal of being precise about > these things and avoiding content negotiation, we're in the > unfortunate position of being without identifiers for particular > representations (snapshots, versions). Note that HTTP defines the ETag response-header field for distinguishing between particular representations: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19 > > I'm updating my draft to include multiple choices for solutions, with > Alan's ontology as one among several, and will try to capture what > you've said. In your view, how would one find information (or > represent the information needed to find information) about a > non-informationresource such as foaf:name? I'm not sure what you are asking. For the foaf:name property, you should be able to follow-your-nose by deferencing the namespace. Are you talking about the need to find information about a specific person with a foaf:mbox of mailto:dbooth@hp.com , for example? David Booth
Received on Wednesday, 7 February 2007 20:50:19 UTC