Re: [BioRDF] URI Resolution

Hi Xiaoshu,

On Feb 5, 2007, at 10:08 AM, Xiaoshu Wang wrote:
> Alan
>> Please review slides 31-34 in [1] for a precise example of the  
>> technique I am referring to. There is a link to working code that  
>> implements the example within lsw [2]
> O.K. Let us work on the provided example.  Assume that you found a  
> VitaminSourceDemoThing that might interest me. How are you going to  
> tell me, say something like: "Hey, Xiaoshu, check this out - http:// 
> www.example.org/NM_013987_XML".  What am I supposed to do next?

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

Now you have the actual location of the resource. You can get the  
actual data by doing a geturl.

> I was wrong using the carrot example.  But what I was trying to say  
> is that the semantics of owl:hasValue restriction should have  
> nothing to do with the URI's composition.  Take the example  
> provided, that all vs:vitaminSourceDemoThing's vs:getMethod must  
> has value of a "vs:vitaminSourceDemoMethod".  Now, if I make the  
> following assertion that
>
> http://foo.com/foo a vs:vitaminSourceDemoThing ;
>                                   vs:getMethod http://bar.com/#bar .
>
> An RDF engine should infer that
>
> "http://bar.com/#bar" owl:sameAs vs:vitaminSourceDemoMethod

Your inference is correct. However this is not an intended use. The  
hasValue was used in step 1, where the getMethod is inherited by   
NM_013987_XML from vitaminSourceDemoThing.

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

Hopefully above explains what is going on. This example doesn't  
really make sense.

> If using an ontology to decide what to dereference, an engine must  
> have parse the resource twice.  First, using the ontology to decide  
> how to get a "complete" information set. Second, to infer it to the  
> knowledge set and do some useful thing.  The semantics are  
> different. If you mixed them up together in the same system, you  
> throw yourself in an endless loop.  For instance, I am curious, how  
> should I dereference the  vs:vitaminSourceDemoMethod, how do I  
> decide the vs:getMethod of this URI? Don't you see where it is going?

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.

-Alan

Received on Monday, 5 February 2007 17:08:33 UTC