Re: [BioRDF] URI Resolution

On Feb 5, 2007, at 12:42 PM, Xiaoshu Wang wrote:

> So, instead of saying "hey, here is the URI".  You would say "Oh,  
> here is the URI and then go here and there, and follow these  
> protocols, you can then know something about this resource." Do you  
> honestly consider this an elegant solution?

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!

> Also, doesn't what you suggested sound like another DNS in RDF  
> disguise? Don't you think it would be better to try to persuade the  
> entire web community to adopt something like LSID, than using the  
> proposed solution?

It does not sound like a DNS in RDF disguise to me. To me, the  
protocols that LSID and DNS and content negotiation implement are  
hidden knowledge that I want exposed. Our semantic web languages are  
good at representing knowledge. By explicitly representing our  
protocols and having a generic interpreter we have the opportunity to  
do some things DNS does, all things LSID does, and other things not  
contemplated in their design (like the query against a SPARQL  
endpoint I demonstrate as a getMethod).

>>> But it does not mean that the engine should dereference  
>>> dereference the URI of vs:vitaminSourceDemoMethod instead of  
>>> http://bar.com/#bar, am I right? Because there might be some  
>>> other interesting knowledge at "http://bar.com/#bar" that is not  
>>> available at vs:vitaminSourceDemoMethod.
> That is supposed not to make sense because I was trying to  
> illustrate the difference in the semantics of a native DL  engine.  
> And what the proposed is a second layer of semantics (URI  
> dereference) based on that semantics.  In other words, you must  
> implement additional logic on top of an RDF engine to support that  
> functionality.

Not logic, procedure. But javascript will do. So I am not worried. I  
am already advocating that OWL include some sort of safe(in the  
computational complexity sense) computed property values. So let's  
anticipate that something like a property definition that is a bit of  
javascript code which is able to do SPARQL queries on the triple  
store in which it is embedded. If we have this we have all we need -  
we no longer have to ask for the method and then interpret it  
ourselves - we just ask for the property value and the (extended) DL  
reasoner runs the javascript and returns the result.

>> I am not assuming you are retrieving each uri one by one. Chunks  
>> of things come in files. The ontology as a whole is in one file.  
>> You are correct that one always has a bootstrap issue. However I  
>> anticipate that the core of the URI resolution ontology, given its  
>> importance, would be available and most likely cached, and that  
>> this ontology would have enough defined to declare alternate  
>> methods of getting itself in the future.
> But tell me how? Don't I have to say explicitly that
>
> http://bar.com/#bar a vs:VitaminSourceDemoThing

Yes. Good point - you are starting to get it. I forgot to include  
that triple. So 3 instead of the 2 triples I initially wrote are sent.

> in order to use the predefined value of the vs:getMethod? Sure,  
> chunks of things come in files.  But each file contain totally  
> different kind of things, each of which has to be described  
> explicitly, right? How do you describe resources in chunk? I am not  
> sure I can understand that.

The attached "chunk" includes the ontology in the slides, as well as  
the descriptions of the resources. So you have an existence proof. I  
could also split this into two "chunks" one which was the uri  
ontology, and the second the specific resources being described which  
owl:imports the other. Not really sure what's confusing here - please  
explain what the problem is.

Regards,

-Alan