- From: Phil Archer <parcher@icra.org>
- Date: Tue, 25 Mar 2008 10:31:58 +0000
- To: Jonathan Rees <jar@creativecommons.org>
- CC: "www-tag@w3.org WG" <www-tag@w3.org>
Jonathan Rees wrote: > > In response to my own call for use cases (I'm still waiting for Atom and > POWDER scenarios): I'm just back at my desk after a long weekend here (GB) and am a little surprised by this statement as I was under the, clearly false, impression, that I had provided what was needed. Apologies - this is a critical issue for POWDER and I do not wish it to be perceived otherwise through my tardiness! OK, let me add this, copied from POWDER's generic profile-matching use case [1]: Step 1 User requests Web content via their device. Step 2 A Server resolves the URI and determines that there is metadata associated with the resource that asserts access conditions. Step 3 The Server matches the assertions in the metadata, to the user's delivery context. Then either Step 4a The Server interprets that there are no constraints on the user accessing the content, Step 5a The Server responds to the User with the full Web content. or Step 4b The metadata asserts that the requested content is not appropriate to the current delivery context. Step 5b The Server adapts the content and responds to the User. The POWDER use case document then goes on to apply this abstract concept to more real-world applications. For example, the profile may indicate that the user's device is a mobile phone and that therefore that 'appropriate' means mobileOK [2, 3]. That is, only content that is likely to provide a functional user experience on a mobile device would be displayed without adaptation. This would avoid the expense, latency and frustration, for example, of downloading a 4MB file to a mobile phone only to find that the device couldn't process it. Other use cases revolve around accessibility, child protection, trust and licensing. In each case, some form of processing takes place before content is delivered to the end user. POWDER separates the description from described resource as it allows a single description to be applied to multiple resources, typically 'everything on a Web site.' Step 2 in the use case above would be more efficient if the link to the metadata (the Description Resource) were available through an HTTP header, thus obviating the need to parse the content before deciding whether it can/should be displayed directly or adapted in some way. The same would apply to any service that wished to aggregate content that met particular criteria, discoverable through POWDER Description Resources. The service would be seeking and authenticating Description Resources as a means of discovering relevant content, preferably without having to parse the content itself. Harry's point about wanting to express the same relationship in HTTP, HTML and RDF is one we support fully too. They should be semantically equivalent. I spent many years trying to persuade various companies to include PICS labels in their content. For some, doing it at server level was easy from a policy point of view, for others, it had to be at document template level. Still others, such as the many Aunt Tillies of this world, were prevented from being able to to use PICS because their Web publishing software didn't allow them to write 'custom headers' in their HTML or otherwise messed up the syntax (PICS labels containing " are still to be found). It is the PICS heritage of ICRA in particular that has lead the POWDER WG to think of HTTP Link and HTML <link> as equivalent (rightly or wrongly). In PICS, you would set a specific HTTP Header or use an http-equiv meta tag in the HTML. As I've reported before, the ICRA label tester [5], which uses Perl's LWP module, makes no distinction between a PICS label delivered as HTTP or HTML. Neither does it distinguish between a Link delivered as HTTP or HTML when looking for links to the RDF-based used by ICRA and Segala now. Incidentally, Jonathan, a clear use case for POWDER is applying cc licenses to collections of resources. The resource grouping aspect is very much at the heart of what we're doing - and the latest draft of the relevant doc [4] should be published within the next 24 hours. Please let me know if you need more, either in terms of use cases, background or direct input from the POWDER WG. Phil. [..] [1] http://www.w3.org/TR/2007/NOTE-powder-use-cases-20071031/#generic [2]http://www.w3.org/TR/mobileOK-basic10-tests/ [3] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/mobileOKPro/drafts/ED-mobileOK-pro10-tests-20080228 [4] http://www.w3.org/2007/powder/Group/powder-grouping/20080320.html [5] http://www.icra.org/cgi-bin/rdf-tester/labelTester.cgi?lang=en&url=http%3A%2F%2Ffosi.org&showHead=on&showContent=on -- Phil Archer Chief Technical Officer, Family Online Safety Institute w. http://www.fosi.org/people/philarcher/
Received on Tuesday, 25 March 2008 10:55:26 UTC