W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2004

Re: HTTP Methods

From: Dirk-Willem van Gulik <dirkx@asemantics.com>
Date: Tue, 9 Mar 2004 11:13:36 +0100
Message-Id: <6D6B424E-71B2-11D8-B93F-000A95CDA38A@asemantics.com>
Cc: www-rdf-interest@w3.org, "ext Seaborne, Andy" <andy.seaborne@hp.com>
To: Patrick Stickler <patrick.stickler@nokia.com>

On Mar 9, 2004, at 10:37 AM, Patrick Stickler wrote:

> URIQA is agnostic. Implementations are free to decide.

I'll move those to the othter summary message; and correct if
this is not presented (as I realize you answered to the message
in a URIQA specific manner - while I more meant the whole
range of options, including CreateCommons and grddl.

> However, DDDS can be employed for non-HTTP meaningful URIs to
> obtain an alias URI which is meaningful to HTTP, via which
> URIQA can provide descriptions.

Or to other protocols; like an 'ftp' alternative, a mailto or even
a specialist protocol like EOLI or that used by the LSID folk.s

> Since resolution via DDDS is anyway dependent on there being
> some other URI which is meaningful to some protocol via which
> representations can be accessed, one can't effectively have
> e.g. DDDS without HTTP.

Without -a- protocol which can be used to fetch either the resource
and/or info about the resource etc; but HTTP is just one of many;
z39.50 could be listed as the terminal protocol, as could be LSiD.

 From RFC 3403

  IN NAPTR 100  50  "a"    "z3950+N2L+N2C"     ""   
  IN NAPTR 100  50  "a"    "rcds+N2C"          ""   
  IN NAPTR 100  50  "s"    "http+N2L+N2C+N2R"  ""   www.example.com.

or even (just for illustration)

  IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@foo.se!i"     .
  IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i"  .

Giving one

	http		for Resource, Location and metadata
	z39.50	for Location and metadata (but not the resource)
	rcds		for metadata only


> they are) then fine, but ultimately, if you want data (representations
> or descriptions) then HTTP is the best game in town.

:-) :-) Well - _that_ is a point I do not quite share; there are 
actually other
protocols out there ;-) :-) which do a fine job for specialist 

Received on Tuesday, 9 March 2004 05:14:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:48 UTC