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

Re: Summary various 'about:' solutions (rev. 2)

From: Dirk-Willem van Gulik <dirkx@asemantics.com>
Date: Fri, 5 Mar 2004 09:44:49 +0100
Message-Id: <5CC6B006-6E81-11D8-933A-000A95CDA38A@asemantics.com>
Cc: www-rdf-interest@w3.org, www-rdf-rules@w3.org
To: Dirk-Willem van Gulik <dirkx@asemantics.com>

Thanks for the feedback (Though I am a bit surprized this is done by 
private mails
rather than on this list - but this may be my IETF/apache shaped 
expectations).

Rev:	1	first cut 2004-04-04
	2	 added Create Commons method (HTML)

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.

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

->	HTML

	Add a <!-- block --> in the HTML with the RDF, as currently
	used by www.creativecomments.com; and by extentsion
	use things like Adobe XMP's to somehow encode it into
	binary formats.

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

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

		change of semantics of the URL (My opinion - see
		see thread about *exactly* that on www-rdf-rules from Patrick,
		Danny and Graham
			->  
http://lists.w3.org/Archives/Public/www-rdf-rules/2003Nov/0066.html )

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

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.

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.

RULE:	simple document describing the rule.

		extra code required in the agent (client/
		browser)

HTML:	simple document describing the rule; esp.
		if XMP is used - groundwork done.

		extra code required in the agent (client/browser).

Some differences perceived between them:

MGET:	Pro:	you can get at the metadata right away
			with an MGET

		-	Little code in the client/agent needed
			which is similar to what is already there.

		Con:	protocol change; and care needs to
			be taken to make this RESTfull enough
			to survive CDNs and proxies.

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

		-	Every server needs to be changed.

DDDS:	Pro:	All on standards track - no new
			documents needed; all done long ago.

		-	No changes except for an entry in
			DNS needed.

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

		-	DNS perceived as very 'scary'.

		-	Requires coding of the 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.

		- 	Clients already parse headers; not
			much extra code.

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

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.

HTML:	Pro:	Just client side.

		-	Trivial to implement <!-- .. -->

		-	Using something like XMP makes other
			formats easy too.

		-	Metadata and resource stay close
			together.

		-	Can fit very well with the way content
			is managed and created in organisations.

		Con:	Need to fetch the whole resource
			always; and it thus needs to be
			public and downloadable.

		-	Metadata and resource stay close
			together.
			
		-	Deep integration in the content
			creation chain needed.

		-	Not possible to provide the
			metadata from some specific system
			or management part.

		-	Can be an ill fit with the way content
			is managed and created in organisations.

Thanks,

Dw

(Thanks Graham, Andy, Jeremey, Patrick, Libby, Dan, Ben, 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] http://sw.nokia.com/uriqa/URIQA.html
[2] http://sw.nokia.com/uriqa/URIQA.html#cbd
[3] http://www.joseki.org/RDF_data_objects.html
[4] http://www.hpl.hp.com/techreports/2002/HPL-2002-315.html
Received on Friday, 5 March 2004 03:45:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 18 February 2014 13:20:06 UTC