W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2003

RE: Standard URI Set, ... -> keep it simple ?

From: Sherman Monroe <shermanmonroe@yahoo.com>
Date: Wed, 21 May 2003 21:08:19 -0700 (PDT)
Message-ID: <20030522040819.55162.qmail@web14708.mail.yahoo.com>
To: Leo Sauermann <leo@ist.org>, www-rdf-interest@w3.org
Thanks for the response. Indeed, more issues to think about. 
 
- every application from web browser to Java.io.URL will have problems with rdp://
 
Yes, they certainly will if they try to use the URI to retreive a document, about as much trouble as they would encounter trying to locate a document at somebody@somesite.com, or trying to send an email to http://www.somesite.com/
 
One thing that is becoming more obvious to me is that if the Semantic Web is going to work, then it will have to become a space that is separate from the www. 
 
Let's take a url: http://www.microsoft.com
 
In the www, what this means to a browser is "there exists a document that resides at the given URL". That is because the www and http:// is built around making requests for and fetching documents, so the vocabulary is quite rigid. All the terms (i.e. URL) reference documents and files (and the definition of a document/file is also strictly defined).
 
But in the semantic space, URI's can point to anything, not just documents. A machine operating in the semantic space can't make the same prenotions about http://www.microsoft.com as it could in the www space. The machine can't use the URI to fetch a document, because there are no documents in the semantic space. To do that, the machine would have to journey back over the the www space and, if the URI conforms to the www/http:// protocols, then it can expect to be returned a document.
 
So if there are no documents in the semantic space, then what does the semantic space consist of? It consist, on the most rudimentary level, only of a bunch of symbols that are used to dereference concepts. And that is all a machine in the semantic space can assume about a URI, that it represents some concept that can be thought of by a human. Thus, http://www.microsoft.com regresses into an atomic character string used only to "stand for" something.
 
So if the semantic space is to then be divided from the www in this way, we should have a protocol to let both machines and humans know what space the URI should be applied in. Sure, we could use http:// uris in the semantic space, but we could also use scissors to slice bread. Why be sloppy? It would make life alot easier to resolve this minor detail before hand.
 
-sherman 


Leo Sauermann <leo@ist.org> wrote:
 
I am designing and implementing a framework right now that uses uris with a "own" schema part.
but that is very experimental and I think I am dancing on thin ice with this,
because:
 
- W3C won't be happy to introduce a new schema (I think, hey, what does W3C think?)
 
- this will result in a new Port number and protocol and THAT is not required. we got http, thats fine, SOAP is nice, too :-)
 
- every application from web browser to Java.io.URL will have problems with rdp://
 
 
so this is my fear of change
 
but i have some practical experience here, too:
 
= go ahead, create the new protocol =
rdp:// sounds cool and it will be surely needed.
but what kind of protocol is it anyway ?
i am developing some kind of protocol right now but what protocol should we use ?
- Sesame-style
- RDFSuite-style 
- RDFGateway-style
- ????
 
so I'd say do it W3C style:
propose a protocol and have it discussed.
wait.
(repeat)
 
= stick to HTTP as transfer protocol =
serious. 
think of proxys and ports
think of "fear of change"
 
= use a new DOMAIN NAME =
just add a http://rdf.microsoft.com/billgates and everybody is happy ? 
This has been best practice since 1970 ? 
you know: pop.ms.com, news.ms.com, smtp.ms.com 
 
and you are really amazed when typing
http://pop3.server.com and see that some wise guy installed a web interface for your email server.
like a web interface on your RDF server ?
 
= use TRICKY URLS that everybody can understand =
and thats my own experience from programming :  Example
I have a server with my rdf data:
http://rdf.leolize.it
 
I have some files there that belong to ME and i use
file://rdf.leolize.it/~leo/semweb/thesis.doc
 
the server itself may have public files, too
file://rdf.leolize.it/~pub/music/iLikeKaraoke.mp3
 

this is the uri of a person:
http://rdf.leolize.it/~leo
 
and HERE is my problem that I have to admit - solve the same way as you do:
 
i have an outlook appointment that belongs to user LEO
 
rdf://leo@rdf.leolize.it/outlook/appointment/12301928301823098123
 
well, i really came far but not far enough to stick to my rules mentioned above, perhaps i could just use http:// here....
 
.... what remains is fear of change ....
 
hope this injects inspiration
 
Leo Sauermann
Vienna, Austria
 

-----Original Message-----
From: www-rdf-interest-request@w3.org [mailto:www-rdf-interest-request@w3.org] On Behalf Of Sherman Monroe
Sent: Wednesday, May 21, 2003 7:44 PM
To: www-rdf-interest@w3.org
Subject: Standard URI Set, and Resource Description Protocol (rdp://)



Hi. I want to bring to your attention an effort that I would like to launch. 

Global URI Set

I am in the process of developing a global, standard URI set. The set will contain exactly one URI for each ďconceptĒ within the setís domain. In other words, a concept will be represented by exactly one URI. The idea is to solve the problem of interoperability. When RDF publishers wish to describe a resource, they use URI's which they have looked up the in the global URI set. This would/could develop into a defacto consensus. This does two things: 

1)       Gives publishers URIís that are in wide use, and thus, are semantically robust and well-defined

2)       Allows publishers to interoperate with each other, since we are all using the same URI ďvocabularyĒ to unambiguously describe concepts and resources



This global set is a mosaic of URIís from many, many RDF ontologies in wide use. Ontology creators will be able to add URIs/ontologies via an informal process. 



Resource Description Protocol (rdp://)

I read TBL's paper about the URI crisis, and I agree with most of what he says. I feel that the URI should be completely opaque, and that no promises should be made as to what a URI will return if a browser is pointed to it. Browsers are for locating resources in the www space. We need a protocol that the semantic web machines can use to denote resources in the semantic space. Therefore, the URIs in our global set will begin with rdp://. This settles the issue as to what a browser will return for RDF URIís. 

If you want to locate a document that contains RDF describing a semantic resource, thatís another issue completely - that document will be located in the www space (or some other document storage space). But if you want to located a semantic resource (rdf://Microsoft.com), then you will need to had over the URI to a semantic agent equipped with the appropriate RDF knowledgebase, and the RDF model describing the resource will be returned to you.

Having our own protocol is desiralbe for several reasons:

1) If someone/somegroup creates an ontology, then decides to discontinue maintining it, the ontology's URIs can still remain and flourish in the semantic space. There is not such thing as a "broken link" once the URI has been absorbed into the global set (informally via consensus)

2) It solves the issue of what should a URI return in a browser. This will once and for all place semantic resources in a space separate from the www. In this way, the semantic URI is viewed only as an atomic symbol that simply and unambigously "stands for" some concept or resource.

I would appreciate any input on these matters, including any current efforts focuses at these or similar issues. Also, anyone wanting to get involved please email me privately.

-sherman



---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
Received on Thursday, 22 May 2003 00:08:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:59 GMT