W3C home > Mailing lists > Public > www-tag@w3.org > March 2002

Re: New question: distinguished status of http:?

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





Received on Friday, 8 March 2002 08:45:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:05 GMT