- From: Phil Archer <parcher@icra.org>
- Date: Thu, 27 Mar 2008 14:43:12 +0000
- 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 UTC