Re: Uniform access to ...

Given the evident confusion over what the POWDER use case is about, I'll 
try and rephrase it - but it may be that I'm just too close to it to see 
the problem ;-)

The Protocol for Web Description Resources is designed first and 
foremost as a simple and efficient method of publishing metadata. A 
POWDER document contains sufficient information to yield a description 
of any resource that is within the scope of the DR(s) to which it has 
access. A key function of a POWDER Processor is therefore to return RDF 
triples that describe candidate resources.

If u is the URI or IRI of a resource, then as a minimum, a POWDER 
Processor MUST support the function describe(u) by returning RDF triples 
that describe u.

There are no formal constraints on how a POWDER Processor must be 
realized. It may be a component in a user agent or some other 
application that is able to process the descriptions it returns or a 
standalone online service. It may use HTTP to access POWDER documents 
from anywhere on the Web or it may act as a gateway to a repository of 
Description Resources. It is highly likely therefore that a real 
application will support a variety of different functions and options, 
however, a conformant POWDER Processor will support the key describe(u) 
function.

So assuming that the processor had access to this Description Resource:

<dr>

   <iriset>
     <includehosts>example.com</includehosts>
   </iriset>

   <descriptorset>
     <ex:color>red</ex:color>
     <ex:shape>square</ex:shape>
   </descriptorset>

</dr>


describe('http://www.example.com/') would return the following RDF/XML:

<rdf:Description rdf:about="http://www.example.com/">
   <ex:color>red</ex:color>
   <ex:shape>square</ex:shape>
</rdf:Description>

If it's online, requests can be sent by adding u to a query string so, 
if ipp is the IRI of a POWDER processor you can dereference this:

ipp?u=http%3A%2F%2Fwww.example.com%2F

to get the same result. (incidentally, if you use 'referer' as the value 
of u, then you'll get back RDF about whatever linked to that processor 
so you can have a link like

<link rel="meta" href="<ipp>?u=referer" type="application/rdf+xml" />

)

All this comes from a generic use case.

Does <u> match my preferences? (where preferences are likely to be 
things like accessible, child-friendly, mobileOK, licensed, recognised 
by a trustmark etc.) It would be good to know that it did before I 
fetched it/included it in my portal/search results without actually 
having to fetch it and parse it and without it having to be HTML. 
Therefore, being able just to to do a HEAD request on a URI and see if 
it had a link to a Description Resource that I could follow would be 
very useful.

In the case of access control systems (be they centred on licensing, 
child protection or device restrictions) it's good to be able to find 
out that you can't/shouldn't have something before a user agent 
downloads it, saves it on your hard drive and then parses it!

HTTP Link achieves that goal.

HTH

Phil.



Jonathan Rees wrote:
> 
> 
> On May 8, 2008, at 9:53 PM, Booth, David (HP Software - Boston) wrote:
> 
>> A quick comment on the 8-May-2008 draft of
>>  http://sw.neurocommons.org/2008/uniform-access.html
>>
>> I don't think the POWDER use case as written motivates the need for 
>> "uniform access to metadata" very well, because the metadata is both 
>> generated and consumed by the server, so the server can just 
>> coordinate with itself about where to find the metadata.  I think a 
>> much more compelling case would be if the *client* (or perhaps a 
>> filtering proxy) needed to consume the POWDER metadata.
> 
> Maybe it wasn't clear that there are two servers involved. I've changed 
> "server" to "gateway" in the description (and for consistency changed 
> "proxy" to "gateway" in the mobile web use case), but we can be still 
> more specific that the metadata comes from an origin server and is used 
> by the gateway.
> 
> I'm also struggling with choice of term X in "uniform access to X".
>   - metadata
>   - "information pertaining to a resource"
>   - links
>   - properties
>   - links and properties
>   - side information
>   - descriptions
> etc. To cover all the use cases the term needs to  be quite broad (e.g. 
> "descriptions" is too narrow, as is "metadata"), but something short 
> would be nice. For now I'm just using "metadata" hoping that the reader 
> will go along with me in interpreting it broadly and that the fact that 
> we're using it in one use case for descriptions of non-information 
> things isn't too confusing. (Strictly speaking "metadata" is data about 
> data, not data about arbitrary things. The latter would be called 
> "description" or "data" or "information".)
> 
> The specification of scope is further confused by the fact that "call by 
> reference" is an option - you can specify either a single property/link 
> giving the location of further properties (metadata), or you can specify 
> the further properties themselves directly, with the choice more or less 
> arbitrary. In one case the metadata is the metadata, and in another it's 
> a link to further metadata. Which  of these is chosen will depend on the 
> mechanism available (Link: and MGET being quite different) and on server 
> whim. I don't think I'm confused about this, but it is a rhetorical 
> annoyance.
> 
> Jonathan
>

Received on Friday, 9 May 2008 13:07:53 UTC