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

Re: Uniform access to descriptions

From: Phil Archer <parcher@icra.org>
Date: Thu, 27 Mar 2008 14:43:12 +0000
Message-ID: <47EBB280.9050306@icra.org>
To: Jonathan Rees <jar@creativecommons.org>
CC: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "www-tag@w3.org WG" <www-tag@w3.org>



Jonathan Rees wrote:
> 
> 
> On Mar 26, 2008, at 12:47 PM, Booth, David (HP Software - Boston) wrote:
[..]
> 
>> Can you explain *why* there are few adopters?  For example, suppose 
>> Acme's CGI script is configured such that for any document URI u, 
>> http://acme.example/metadata?u yields the metadata for u.  It wouldn't 
>> seem onerous for an application wanting metadata about u to prepend 
>> http://acme.example/metadata? in order to get it.
[..]
>>
>> Okay, so the Acme prefix only works for Acme's documents, and other 
>> publishers will need to supply their own prefixes.  So for an SWeb 
>> application to work uniformly across publishers, the app would need a 
>> standard way to map groups of documents to prefixes.  Hmm, haven't I 
>> seen that problem somewhere else?  :)  POWDER documents could indicate 
>> the necessary mappings from document URI patterns to metadata prefixes.
> 
> This would work fine for this use case. Now how would an application 
> discover such mappings or POWDER documents? (Sorry, I haven't read 
> through the POWDER literature... ) If you can answer this question, then 
> we will be able to contribute this alternative solution to the list of 
> possible solutions. Maybe there could be a central registry or two that 
> gets shared around, but this approach has obvious problems. I think that 
> without discovery working in a decentralized way for arbitrary URIs, we 
> do not have a *uniform* solution. I vaguely remember some discussion of 
> site metadata in the past...

Well, POWDER could certainly convey the message that for all IRIs for 
which the most significant part of the host is acme.org, the metadata 
prefix is http://acme.example/metadata? but this wouldn't help you 
discover the POWDER document that said this. You'd still need a pointer 
to the POWDER doc. So I'm not sure it moves us much further forward.

> 
>> This seems like it would *mostly* address your use case, but it does 
>> leave one detail unaddressed that your use case didn't mention: the 
>> SWeb application using the POWDER document would have no way to easily 
>> (mechanically) determine that any given mapping rule is 
>> *authoritative*.  Thus it would not be able to determine [for example] 
>> whether the obtained metadata should be considered a part of the 
>> document URI's *declaration* rather than merely being ancillary 
>> assertions about the document.  In contrast, a new HTTP header would 
>> clearly establish authority, and thus the returned metadata could 
>> constitute some of the core assertions of the document URI's declaration.

As for authoritative vs. trust, this is very much at the heart of what 
POWDER is about. A POWDER doc is invalid (in the XML sense of the word) 
if it does not include a bit of FOAF information telling you who created 
the descriptions within the document. How you decide whether or not to 
trust such data... well, we must leave that up to the beholder of course.

To get an idea of what POWDER is in 30 seconds of your time, take a peek 
at http://www.w3.org/TR/2008/WD-powder-dr-20080317/#eg2-1. A GRDDL 
transform will be associated with the root namespace that will turn that 
XML into RDF/OWL as shown in 
http://www.w3.org/TR/2008/WD-powder-dr-20080317/#eg2-3

Phil.
[..]

-- 
Phil Archer
Chief Technical Officer,
Skype: philarcher
w. http://www.fosi.org/people/philarcher/
Received on Thursday, 27 March 2008 14:44:00 GMT

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