Re: [BioRDF] URI Resolution

> 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!
So, an email client need to run Javascript or something like that.  
Isn't this proposing some uniform treatments of URI because otherwise, 
where is the interoperability?
> 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).
Sure, RDF is good representing knowledge.  But should we abuse RDF to do 
the thing that it should not do? I remember somewhere in the web that 
joked about using XML to encode IP address. Sure, it could be done, 
right? But there is a reason that we don't. 
> 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.
DNS is procedure that intends to resolve name into IP.  Now, in your 
case, every machine on the internet should be backed by an RDF engine. 
As I said before, those extra information (dereference information) must 
exists either locally or globally, and it better be globally than 
locally for the sake of consistency.  If this does not sound like DNS in 
spirit, what does it sound like?
>>> 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.
So, each the entire RDF document will be tripled? I thought David and 
Mathias were saying that shouldn't happen if you describe the semantics 
of string that forms the URI.  But please note the difference, one is an 
Ontology describe the meanings of a strings, which in turn describes the 
meanings of some resources.
> 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.
Let's assume I have following statements originally located at 
"http://foo.com/"

http://foo.com/#foo1 rdfs:subClassOf http://foo.com/#foo_2.
http://foo.com/#foo2 rdfs:subClassOf http://foo.com/#foo_3.
...
http://foo.com/#foo_n-1 rdfs:subClassOf http://foo.com/#foo_n.
http://foo.com/#foo_n rdfs:subClassOf http://bar.com/#bar_1.

Now, if let's assume http://foo.com/ is moved to someplace else, don't 
you have to explicitly describe all the resource one by one? How do you 
describe them in chunk?

Xiaoshu

Received on Monday, 5 February 2007 18:49:22 UTC