Re: Uniform access to ...

Hi Stuart,

Yes, both of those usage patterns are very much in our minds. On the 
issue of trust we say this:

Trust is a central theme of POWDER, however, we do not prescribe a 
single method through which trust must be conferred on Description 
Resources. By its very nature, trust is a human judgement that can only 
be made by weighing the likelihood that the data is true against the 
consequences of it being false. This judgement is highly dependant on 
the circumstances under which the need to extend trust arises. POWDER 
does, however, provide support for, and is amenable to, a variety of 
methods through which users and user agents can establish trust.

And then give examples that include linking the data to other data that 
can provide independent verification, XML Sig and so on - the particular 
method used will be determined by the particular situation.

Phil.



Williams, Stuart (HP Labs, Bristol) wrote:
> Phil,
> 
> Would it be fair to consider broadly two usage patterns for POWDER.
> 
> - A first party usage where POWDER Description Resources are published by the publisher of the described resource as away describing their own publications (and in some sense sitemap).
> - A 3rd party usage where POWDER Description Resoruces are published by some independent party (posibly aggregated by ISPs) in order to comminicate their evaluation of some web content as a value added service.
> 
> For any given resource, u, there are in general multiple providers of the describe(u) function you mention below.
> 
> Something like the LINK header could be used to provide both first party and third party description references, however in the third party case I'd expect information consumers to be of skeptical disposition wrt to what publishers have to say of their own publications.
> 
> Part of the problem for POWDER is for information consumers (or service providers eg. clean-feeds, acting on their behalf) to be able to locate an appropriate set of describe(u) providers wrt to their particular information use.
> 
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]
>> On Behalf Of Phil Archer
>> Sent: 09 May 2008 14:07
>> To: www-tag@w3.org WG
>> Subject: 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
>>>
>>
>>
> 
> 

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

Received on Friday, 9 May 2008 15:35:58 UTC