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
