Re: [BioRDF] URI Resolution

On Feb 5, 2007, at 3:02 PM, Xiaoshu Wang wrote:
> Alan Ruttenberg wrote:
>> On Feb 5, 2007, at 1:49 PM, Xiaoshu Wang wrote:
>>> 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?

We will need to agree on something.

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

Well, we will have to disagree about this.

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

There is no problem here. There is a single property getMethod. We  
have described what it does with what. It doesn't interfere with the  
other statements I make about the resource.

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

Have you ever read the code for a web server? Everything is messy to  
some extent. I find this less messy and more importantly I, and  
anyone else has a chance of understanding it using "view source",  
then tweaking it to serve their purpose. There is no magic behind the  
scenes like there is with content negotiation, for instance.

>> 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 [snip]

The lie would be if you did a geturl on http://purl.example.com/ 
#aColor and retrieved the bytes "010203" and you did a get on  http:// 
foo.com/#aColor and retrieved the bytes "030201". Remember, you said  
they were sameAs, and same information resources have the same bytes.  
That was the point. Since this is the case, it doesn't matter if you  
retrieve one or the other of them, which was justification for saying  
that you may try any getMethod and stop after the first one that  
retrieves something.

I'll point out once again the confusion between  
NotAnInformationResource and InformationResource. Colors are not  
information resources.

-Alan

Received on Monday, 5 February 2007 20:37:42 UTC