- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Fri, 09 May 2008 19:30:19 +0100
- To: Phil Archer <parcher@icra.org>
- CC: "www-tag@w3.org WG" <www-tag@w3.org>
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