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

 

-----Original Message-----
From: ext Sherman Monroe [mailto:shermanmonroe@yahoo.com]
Sent: 22 May, 2003 07:08
To: Leo Sauermann; www-rdf-interest@w3.org
Subject: RE: Standard URI Set, ... -> keep it simple ?


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.  
 

No. Not a space separate from the Web, but rather a distinct mode of resolution of URIs. URIs are the
point of intersection and integration between the Web and the Semantic Web. For both the Web and
the Semantic Web the denotation of those URIs should be consistent and in agreement. Where the
difference lies is in how Web agents versus Semantic Web agents utilize those URIs. 
 
Web agents (e.g. browsers) resolve URIs to representations. Semantic Web agents need to resolve
URIs to descriptions which are suitable for reasoning about those resources.
 
The infrastructure of the Web and the Semantic Web can be largely the same, yet we simply
make the distinction between the mode of resolution explicit when agents of either type are
interacting with a given server.
 
Hence my introduction of the new HTTP header URI-Resolution-Mode which allows a SW agent
to signal to a SW Enabled server that it wants a concise bounded description of a resource
rather than (some other form of) a representation of the resource. A Web agent will either
omit the header or use it to signal that it wants a traditional representation. 
 
No new URI schemes or protocols are necessary. Only the means by which the agent and
server can differentiate between the different modes of URI resolution needed by the particular
type of agent, web or semantic web.
 

 
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).
 

Well, more precisely, it means that the URI denotes some resource, and resolving that URI by
an HTTP server will presumably result in obtaining a representation of the resource denoted
by that URI.
 
Whether or not the URI denotes a web page, an organization, or a pink zebra in a bikini is
another matter entirely.
 
Though one that URIQA aims to help solve, by allowing one to ask for a description of
the resource denoted by the particular URI rather than a representation, and that
description may very well clarify what in fact that URI denotes.
 
Thus URIQA is fully complimentary to the REST architecture, by simply providing a
different way to interact with a URI without changing what it denotes or changing how
web agents interact with URIs at present.

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.  
 

I agree. That's what URIQA aims to do.
 

 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.
 

URIs themselves are in both spaces. They constitute the intersection of the web space and the
semantic space (to use your terminology). The semantic space should not care what URI scheme
is used. It should be possible to use any arbitrary URI in the semantic space. Yet in the web
space, certain URI schemes are preferred over others, for practical reasons, the http: URI
scheme being the most common -- since there is an existing global infrastructure in place for
interacting with servers based on http: URIs.
 
The distinction between the web space and the semantic space is simply how one uses the URIs.
The URI denotes the same resource for both spaces. But in the web space, one resolves 
URIs to represenations and in the semantic web space one resolves URIs to descriptions. Both
spaces then benefit from the global HTTP infrastructure.
 
So, using http: URIs in the "semantic space" is not sloppy. Rather, it is quite elegant and effective,
as the URIQA model demonstrates.
 
Cheers,
 
Patrick
 
 

-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 <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 <http://rdf.leolize.it/> 
 
I have some files there that belong to ME and i use
file <file://rdf.leolize.it/~leo/semweb/thesis.doc>  ://rdf <file://rdf/> .leolize.it/~leo/semweb/thesis.doc
 
the server itself may have public files, too

file <file://rdf.leolize.it/~pub/music/iLikeKaraoke.mp3>  ://rdf <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 <http://www.w3.org/DesignIssues/HTTP-URI.html>  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  <http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com> New Yahoo! Search - Faster. Easier. Bingo.



  _____  

Do you Yahoo!?
The New  <http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com> Yahoo! Search - Faster. Easier. Bingo.