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
