Re: Uniform access to ...

Phil Archer wrote:
>
> 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.
But this seems an application semantics but the HTTP semantics.  I am 
not sure how universal the pattern will be. 
>
> 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.
Of course, it can but you can also do it in other way, such as a 
customized header of content negotiation.  The issue, therefore, is if 
the POWDER use case is a universal usage pattern that warrants the 
extension of HTTP protocol.  If it is, it requires a clear definition of 
*metadata/description/....*.  If it is not, then it is the design choice 
for POWDER application but web application in general.

Xiaoshu


>
> 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 18:31:21 UTC