W3C home > Mailing lists > Public > public-powderwg@w3.org > April 2008

The 'missing protocol part'?

From: Phil Archer <parcher@icra.org>
Date: Wed, 23 Apr 2008 06:50:58 +0100
Message-ID: <480ECE42.8090600@icra.org>
To: Public POWDER <public-powderwg@w3.org>

Well, I tried not thinking about POWDER at 03:00 - and made it to 04:30 
(must see a doctor). The good news is that none of what follows affects 
the XSLT - but it will add at least a week to our document publishing date.

OK, I think I have spotted something non-trivial. What is 'the protocol 
part'? (as Ralph S would say) i.e. what questions can you ask 'a POWDER 
processor' and what should the reply be? We have so far been focussing 
on the POWDER->POWDER-S transformation, which is fine. A semantic tool 
can pick up a POWDER doc, run the transformation and get some RDF/OWL 
which, iff it implements the semantic extensions, can provide 
information about resources identified by their IRIs.

But I think a PP should probably be able to provide a description of a 
given URI ;-) In other words, the question might be "describe 
http://www.example.org/image.png" and the reply would be "it's red and 
square". Now, we have talked about this but it's been rather nebulous. I 
think we need to clarify what a POWDER Processor is supposed to do and 
that would give us some nice conformance/test criteria.

A first pass at this leads me to suggest that for a URI, u, the basic 
function is

describe(u)

which would return RDF triples like

<rdf:Description rdf:about="u">
   <ex:color>red</ex:color>
   <ex:shape>square</ex:shape>
</rdf:Description>

(or the same thing in other serialisations)

This assumes that the PP already has some data it can process to extract 
the description. This could come from its cache/repository or by 
resolving u to look for links to POWDER docs, fetching and processing them.

There are at least 2 optional parameters as well:

- data source (i.e. tell the PP which source(s) to use)
- maker (i.e. only use descriptions provided by an identified author)

A PP might support further options but these would be 
application-specific. We'll probably need to say that it MUST support 
RDF/XML and that good practice would be to support N3 and Turtle 
serialisations.

How would such a query be sent?

There's a whole document about how to transmit SPARQL queries [1] and 
we'd probably do well to follow that format. If I understand it 
correctly (and I've looked at it for a matter of seconds so far) it uses 
WSDL to define the query and output. Our queries are going to be a lot 
simpler since the question is always the same - we're not writing a new 
query language.

Ignoring escaping rules for a moment, the query would end up being put 
in an HTTP request as something like

?describe=http://www.example.org/image.png&data=http://example.org/powder.xml

So I guess this means defining the questions that can be asked and 
providing a means for that question to be made over HTTP. Other methods 
are equally valid but they would be application-specific function calls 
I guess.

Doing this will help to clarify exactly what a POWDER document means and 
how to use it - I hope.

Phil.

[1] http://www.w3.org/TR/rdf-sparql-protocol/
Received on Wednesday, 23 April 2008 05:51:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:12 GMT