Re: Summary various 'about:' solutions (rough first cut)

On Mar 04, 2004, at 15:25, ext Dirk-Willem van Gulik wrote:

> L.S.
> Solutions over heard in the corridor here in Cannes over the last 48 
> hours over the tell me 'about:' that URI "problem" or the shallow side 
> of the "bootstrap problem" (below ideas are from others; mistakes are 
> mine) (*):
> ->	MGET
> 	Treat the URL as a URL - but add an MGET method; which unlike
> 	the GET method returns information about that what the GET method
> 	would have returned. [1]
> 	E.g. the URL is no longer the location of the resource - but also the
> 	location of the data about the location.

Er. Not quite. The URI denotes a resource. One can use GET to request
a representation of that resource. Or one can use MGET to request a
concise bounded description of that resource. There is no need to posit
any concept of "location"; either of the resource or its description.

> ->	DDDS
> 	Use DDDS on the URI to get a list of protocols/services available	for 
> a given URI; such as the URL, the resource itself, a canonical
> 	name or data about the resourcce (e..g rdf).
> ->	HDRS
> 	Add a few headers to the HTTP reply of a GET/HDRS on the
> 	actual resource which includes the location of the metadata
> 	about the resource.
> ->	RULE
> 	A fixed rule how to rewrite a source URLinto a URL about
> 	the metadata. I.e. add '.RDF' to the end to get RDF about
> 	the document if it exists.
> Each of the above requires:
> -	Creation of data about the object somewhere/somehow (the
> 	metadata)
> -	Tracking (by table or by 'rule/regex') of the locatations
> 	or otherwise of that metadata.
> 	->	E.g. register them in some data base or
> 	->	have a rule like
> 		e.g. .	(.*)RL.html ---> $/1URL.html.rdf
>         			(.*)URL.jpg   ---> $1/URL.jpg.rdf

But with some approaches, such as URIQA, the relation between
resource and description is left up to each web authority rather
than mandated globally or requiring some centralized machinery.

In fact, URIQA differs from the other approaches in that it is
not actually manditory that each description be given a distinct
URI (though a distinct URI would be needed if one were to make
statements about the description).

All the other approaches require an explicit URI denoting the
description in order to work. With URIQA, it's optional.

> Each of the above requires code and/or changes in either
> server, client or both:
> MGET:	extra code in the origin (web) server to understand MGET
> 		extra text in the document describing HTTP

??? Do you mean modification of the HTTP spec? I don't see that
as a requirement. The specification of WebDAV is distinct from HTTP.
I see no reason why the specification of URIQA would not be distinct
from HTTP.

> 		change of semantics of the URL (My opinion -

URIQA in no way changes the semantics of URLs or any other kind of URI.

URIQA is fully RESTful.

> see
> 		see thread about *exactly* that on www-rdf-rules from Patrick,
> 		Danny and Graham
> 			->  
> )

I'm sorry, but I don't see how the reference thread has anything to do
with your opinion that URIQA changes the semantics of URLs. Can you
elaborate specifically about why you hold such an opinion?

> 		extra code in the agent (client/browser) to do an MGET
> 		and deal with the result.


I don't see how URIQA imposes any "extra" code in the agent (and, 
me, Nokia is *very* concerned about anything that imposes extra code in
the agent ;-)

With URIQA, the agent specifies the request method (which is no more
burdensome than specifying one of the existing HTTP methods), and
it processes the results (presumably an RDF/XML description) which is
no more burdensome than for any other approach having the same goals,
namely to obtain a description of some resource.

If anything, URIQA is the lightest, most efficient approach insofar
as client implementation is concerned.

> DDDS:	one or more lines in the fqdn's zone DNS server, the
> 		so called NAPTR lines.
> 		no extra documents needed - RFC standards track.
> 		extra code in the agent (client/browser) to do so
> 		use the URL returned.

I was quite infatuated with the DDDS approach, and for a solid 24 hours
trully thought it might be a more optimal approach than URIQA. That was
until I realized how impractical (socially/politically/culturally) it
would be to have *everyone* world-wide touch their DNS records to
support resource description discovery.

Technically, it's a great approach. But practically, I just don't see it
happening (even less so than introducing three new methods ;-)

> HDRS:	extra code in the origing (web) server to add HTTP headers.
> 		simple document describing the extra headers
> 		extra code in the agent (client/browser) to do
> 		something useful with the URL of the metadata.

Doesn't scale. Leads to potentially catastrophic side effects if the
server misunderstands or ignores the headers. See the FAQ section
of the URIQA spec for more.

> RULE:	simple document describing the rule.
> 		extra code required in the agent (client/
> 		browser)
> Some differences I perceive between them:
> MGET:	Pro:	you can get at the metadata right away
> 			with an MGET
> 		-	Little code in the client/agent needed.

No special code whatsoever in the client/agent needed.

> 		Con:	protocol change
> 		-	not too rich - all you can do is get the
> 			metadata over HTTP.
> 		-	significant web server code needed.
> 		-	Corperate webserver often managed by
> 			marketing drones; hard to get it changed.

Er. Actually, in comparison to getting DNS records changed, it's a 

> 		-	Every server needs to be changed.

No. Not every server.

Only those servers used to publish resource descriptions.

It's very similar to WebDAV. Not every server on the planet has to
support WebDAV for WebDAV to be successfully deployed. Nor does
every server on the planet have to support URIQA for URIQA to be
successfully deployed.

Furthermore, one can use proxies to redirect URIQA requests for
a entire domain to a centralized authoritative URIQA service portal
such that only one centralized server has to support URIQA.

> DDDS:	Pro:	All on standards track - no new
> 			documents needed; all done long ago.
> 		-	No changes except for an entry in
> 			DNS needed.

That's one gonzo mother of an "except".

> 		-	Often just a single line is needed, especially
> 			for the (.*) -> $1.rtf rule/substitution case.
> 		-	Can do more than just 'about' data; can
> 			deal with other protocols, dual-use is
> 			possible (e.g. LSiD for the advanced
> 			browser of the biologist, http for the mere
> 			mortals).
> 		-	Network/speed/resource wise
> 			very cheap.
> 		-	Easy to lay blanket rewrite across
> 			all servers in the company; no need
> 			to change -any- web server; just
> 			need to add one for the metadata.
> 		-	NAPTR already pops up in this
> 			sort of use in Liberty, SIP/VoIP,
> 			RfId etc.
> 		-	Positive and Negative caching plus
> 			caching hierachy natural to DNS and
> 			already deployed.
> 		Con:	 DNS perceived as very 'scary'.
> 		-	Corperate DNS often managed by
> 			god like beared wizzards which mere
> 			employees usually do not want to anger.

Much to my own personal disappointment (really) I think this
is the nail in the coffin for the DDDS approach.

DNS is also widely (and probably justly) considered fragile and
when DNS fails, the network dies, so repurposing DNS in this
way seems dangerous at best.

Perhaps what is needed is a "parallel" DNS, isolated from the
"real" or "traditional" DNS, but which provides for less critical
functionality such as DDDS, without risk of impacting the critical


> 		-	DNS perceived as very 'scary'.
> 		-	Requires 10-20 lines of DDDS algorithm
> 			in the client which interact with the bind/dns
> 			library of the system.
> HDRS:	Pro:	People add headers all the time, done
> 			a lot. Easy to parse for the client.
> 		-	Though every server needs to be changed,
> 			the URL can refer to a central one.
> 		Con:	To get the metadata location you need
> 			an GET/HDRS over TCP first.
> 		-	Corperate webserver often managed by
> 			marketing drones; hard to get it changed.
> 		-	not too rich - all you can do is get the
> 			metadata over HTTP.
> 		-	Code needed in Server and in Client.
> 		-	Every server needs to be changed.

Also, for PUT/DELETE like operations, if the header is not understood,
bad and unintended things can happen.

Also, if the default representation is 250MB and the header stuck on
a GET request is not understood, the agent is force-fed the 
(true, could use HEAD instead, but still...)

> RULE:	Pro:	Just client side.
> 		-	Trivial to implement.
> 		Con:	 URL space polution.
> 		-	Corperate webserver often managed by
> 			marketing drones; hard to get it changed.
> 		-	not too rich - all you can do is get the
> 			metadata over HTTP.
> 		-	If there is no metadata you only find out
> 			after an full blown TCP/GET.
> Did I miss anything ? Help needed here :-)

I hope what I provided above is considered as "help" ;-)



> Thanks,
> Dw
> (Thanks Graham, Andy, Jeremey, Patrick, Libby, Dan, Alberto (in no 
> particular order for feedback and thought provoking/shaping 
> conversations).
> *: 	I am lumping together several concepts; i.e. you want to specify 
> that for most cases,
> 	people mean "metadata about the resource" as the "concise bounded 
> description"
> 	2] or as a synonym of "RDF data object" [3][4] - i.e. "give me the 
> location (URI) of the
> 	metadata  about that URI" or "give me the location (URI) of metadata 
> about anything
> 	*you* know about that other URI", etc
> [1]
> [2]
> [3]
> [4]


Patrick Stickler
Nokia, Finland

Received on Monday, 8 March 2004 08:54:53 UTC