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).
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.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.
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
uri-resolution.owl
Description: Binary data
