Re: Uniform access to descriptions

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