Re: Uniform access to descriptions

On Mar 26, 2008, at 12:47 PM, Booth, David (HP Software - Boston) wrote:

> Thanks Jonathan, this use case is very helpful.  A new HTTP header  
> does sound like it would be very convenient in this kind of case,  
> but just to continue exploring other options that would not require  
> additions to HTTP . . .
>
>> From: Jonathan Rees
>> [ . . . ]
>> Acme's first approach is to create a CGI script that takes
>> the article's URI as input and returns the bibliographic RDF
>> for that article. This gets few adopters and the publisher
>> realizes that monolithic action will not be very effective.
>
> I don't know what you mean by "monolithic action".

I misspoke - the word I wanted was 'unilateral'.

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

As you observe below there's little adoption because application  
designers don't want to bother to do a hack for a single publisher. A  
single site is unlikely to be sufficient motivation; but ten  
important cases might be, and thousands definitely would be.

>> At a trade conference they realize that other publishers are
>> having the same thought, and there is discussion of how they
>> can standardize so that agents can be generic across various
>> publishers - indeed over the whole web.
>
> 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...

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

  (I added "[for example]" above.)

I don't want to make the problem harder than it already is, but yes,  
I guess we will have to keep some idea of this sort in the  
requirements mill. I don't like the word "authoritative" since it's  
easily misinterpreted to mean "true" but the idea that received  
information speaks for either the agent that minted the URI or the  
agent that's responsible for dereferencing the URI seems to have value.

Jonathan

Received on Thursday, 27 March 2008 12:20:11 UTC