Re: [BioRDF] URI Resolution

Alan Ruttenberg wrote:
> On Feb 5, 2007, at 1:49 PM, Xiaoshu Wang wrote:
>>> Indeed. What I spelled out could be implemented in javascript and 
>>> the javascript put in the rdf directly. Then it would be simply a 
>>> matter of saying javascript "eval". Think ahead!
>> So, an email client need to run Javascript or something like that.
> Is that a problem? There are free implementations of javascript. Most 
> modern mail clients have one anyways, in order to deal with html mail. 
> Many phones have one now, or will soon. Any barrier to this will be 
> overcome by technology advances in the very short term, it seems to me.
Sure, everything is doable if we agree upon doing certain things.  Just 
as our discussion on LSID, there is nothing wrong with its design and 
intension.  It is just too expensive and too time consuming to make 
everyone accept that.  Unless it is a globaly accepted practice, it 
won't solve the URI resolution problem, don't you agree?

Why I think an URI Resolution Ontology is not appropriate.  Let's just 
consider the speed.  The URI resolution problem is just a redirection or 
URI-substitute.  A simple lookup would be enough.  Using reasoning is an 
overkill of the problem at least.
> You would add
>
> Class(http://bar.com/#bar_1 Partial Restriction(getMethod 
> hasValue(transformingURIRetrievalForFoo))
> Individual(transformingURIRetrievalForFoo
>     type(transformingURIRetrieval)
>     value(matchingPattern "http://foo.com/(.*)")
>     value(replacementPattern "http://blarg.com/$1"))
This is my point.  The semantics you wanted is the "matchingPattern" of 
the string.  Therefore, you are describing the meanings of name, but not 
the meanings of the resource that the name is point to.  As your reply 
to the next question already talking about multiple getMethods and using 
heuristics, don't you think the solution is getting messier and messier?

> The assumption is that there may be multiple getMethods, and that each 
> will return the same resource if you ask for it (otherwise the sameAs 
> is a lie). Therefore a robust client will try all the getMethods for a 
> thing and all things it is same as, and stop when the first one 
> succeeds. If the getMethod for #bar is applied to #purl the worse 
> thing that can happen is that it will fail and the original getMethod 
> for #purl will eventually be tried and succeed. Smart resolvers might 
> use heuristics to choose which methods to try first, but this won't 
> change the outcome.

I don't understand the "lie" part.  Consider the following example.  
Assuming two researchers, one works on a dog. The other studies a cat.  
The dog guys make a note saying

http://purl.example.com/#thisDog ex:hasEyeColor 
http://purl.example.com/#aColor.

At the same time that the cat guys saying that

http://foo.com/#thisCat ex:hasEyeColor http://foo.com/#aColor.

But later they realized that the "http://purl.example.com/#aColor" is 
actually the same color as "http://foo.com/#aColor". Shouldn't they make 
the statement that

http://purl.example.com/#aColor" owl:sameAs "http://foo.com/#aColor".

Do you call it a lie? Will the semantics of this statement changed if 
http://foo.com/#aColor is moved to someplace else? Or it is a lie only 
because it doesn't fit your proposed URI resolution ontology?

Xiaoshu

Received on Monday, 5 February 2007 20:03:15 UTC