- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 08 Mar 2002 15:47:23 +0200
- To: ext Elliotte Rusty Harold <elharo@metalab.unc.edu>, WWW TAG <www-tag@w3.org>
- Message-ID: <B8AE8D8F.10539%patrick.stickler@nokia.com>
On 2002-03-01 17:15, "ext Elliotte Rusty Harold" <elharo@metalab.unc.edu> wrote: > At 7:03 PM +0100 2/28/02, Patrick Stickler wrote: > > >> Hmmmm... this seems to suggest to me that there would be utility in a >> standardized means by which applications could obtain knowledge about what >> URI schemes mean, in some standardized manner and according to some >> standardized ontologies, to determine what is expected of them. >> > > This reminds me of Java protocol handlers. Of course, protocol handlers: > > 1. Were specific to Java > 2. Never really worked in the first place > >> Would not the Semantic Web offer a means of extensibility for >> URI scheme semantics so that agents need not know, as part of their >> static design, about all possible URI schemes? >> >> We provide auxiliary, supporting knowledge for XML instances that >> say how to validate them, display them, transform them, etc. so that >> applications need not understand natively what the significance >> of particular markup vocabularies are. Why then would it be >> unreasonable to provide auxiliary knowledge about URI schemes so that >> applications could be similarly informed about what a given URI means, >> even if it has never seen one of that scheme before? >> > > This is a very interesting idea. If this could be defined through an > XML description of the protocol, as opposed to compiled code, then it > might succeed where protocol handlers failed. As a proof of concept I > wonder if it's possible to design an XML format sufficiently general > that it could describe all the information that a single client would > need to implement the following used but widely diverse protocols: > > 1. http (TCP, request-response, single socket) > 2. ftp (TCP, multiple sockets, bidirectional, client and server) > 3. telnet (TCP, interactive, user input required after connection) > 4. mailto (TCP, interactive, user input required before connection) > 5. rtspu (UDP) > 6. file (no sockets at all) > > That's a pretty diverse batch. If you can cover those six, I'd be > willing to bet you could cover most other URLs and probably URIs too. > However, remember that for this to work the client would have to have > no preexisting knowledge of any of the protocols. Attached are two RDF Schemas, very experimental, but which I believe together provide the proof of concept you outlined above. I am presuming that an RDF description satisfies your specification of an XML description ;-) The first is an initial stab at a formal ontology for URI Classes and Schemes that is very much a work in progress. The second schema is a off-the-cuff attempt at capturing your examples above. The vocabulary used in proto.rdf is probably not quite right, and certainly overly simplistic, but it illustrates the approach quite well I think. One open question is how detailed the description of the protocols must be. How ignorant do we allow the clients to be? Of course, RDF would allow for the protocols to be defined in as brutal detail as necessary. Also attached is an RDF Schema (in N3 notation) that demonstrates the need for a formal and precise distinction between names of locations, names of non-location resources, and reified URIs themselves, which reflects much of the motivation for the URI ontology in uri.rdf. Regarding the RDFL ontology and the voc: URI scheme, c.f. http://www-nrc.nokia.com/sw/rdfl.html http://www-nrc.nokia.com/sw/draft-pstickler-voc-01.html Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com
Attachments
Received on Friday, 8 March 2002 08:45:37 UTC