Re: [BioRDF] URI Resolution

> I (or my software) would send you a small package of triples. 
> Effectively:
>
> 1. The location of the ontology that includes VitaminSourceDemoThing
> 2. The resource of interest: http://www.example.org/NM_013987_XML
>
> You would know (because we have agreed on the outline of how we 
> resolve URIs) to follow the steps in slide 34 (repeated here)
>
> Call (get-information-resource-location 
> !<http://www.example.org/NM_013987_XML> )
> Which does the following
> 1. Get the getMethod of NM_013987_XML
> => !vitaminSourceDemoMethod (inherited)
> 2. Get the direct type of the method. It is !SPARQLRetrieval
> 3. Dispatch to code based on type
> 4. Code retrieves queryPattern => “PREFIX biozen:….%%URI%%…”
> 5. Code retrieves URIVariableString => “%%URI%%”
> 6. Code replaces %%URI%% with NM_013987_XML uri
> 7. Code retrieves useSPARQLEndpoint (2 of them)
> 8. Constructs http gets, e.g.
> http://neuroscientific.net/vitamin-source/endpointone/
> endpoint.php?query=PREFIX%20biozen:%20%3Chttp://neuroscientific.net/biozen. 
>
> owl%23%3E%20SELECT%20?url%20WHERE%20%7B%3Chttp://www.example.
> org/NM_013987_XML%3E%20biozen:download%20?url%20.%20%7D"
> http://tinyurl.com/u6ztt
> 9. Query returns =>
> http://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=nucleotide&id=7669537&rettype=xml 
>

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? 

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

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.

Xiaoshu

Received on Monday, 5 February 2007 17:43:16 UTC