RE: Uniform access to ...

Hello Phil,

What I guess I was trying to get at was just the simple fact that something like a header based LINK header approach would not address all of your description discovery requirements. Potentially it is good for what might be thought of 1st party endorsed references.

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

> -----Original Message-----
> From: Phil Archer [mailto:parcher@icra.org]
> Sent: 09 May 2008 16:35
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org
> Subject: 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:59:00 UTC