Re: New version of primer

Some comments from me on the doc so far. I'm not bothering with "this 
could be phrased better" or typos at this point.

Abstract:
"There are two varieties of POWDER, a complex, semantically rich 
variety, called POWDER-S and a simplified version called POWDER which is 
intended for day-to-day usage."

This goes to our Issue-50 (a.k.a Ivan 3) about whether it is advisable 
to create POWDER-S documents. See my mail of 30/3 [1]. If the resolution 
is accepted then I suggest:

"There are two varieties of POWDER, a complex, semantically rich 
variety, called POWDER-S and a much simpler version, just called POWDER, 
which is intended as the primary transport mechanism for Description 
Resources. POWDER-S can be generated automatically from POWDER."

Status section: Add place holder for reference to the Test Suite. Just 
looking at GRDDL, their Primer looks likely to be a Note but the Test 
Suite is a full Rec document.


1. What is POWDER
=================
I'd rewrite this original text:

"There are two varieties of POWDER, a complex, semantically rich 
variety, called POWDER-S and a simplified version.
The simplified version, also called the operational semantics, is 
written in XML for easy day to day use.
The formal semantics, POWDER-S, are intended to provide mechanism to 
harness the semantic web and underpin the operational semantics. A GRDDL 
transform will create the needed RDF/XML for this use.
There is no restriction on which form to use, but it should be noted 
that the simplified version is intended for the exchange of information 
between systems.
The POWDER-S version is designed to facilitate incorporation of POWDER 
information in larger RDF based systems.

Thus POWDER allows a variety of questions to be answered about a given 
web resource or group thereof, without having to actually retrieve the 
resource."

as

"There are two varieties of POWDER, a complex, semantically rich 
variety, called POWDER-S and a simple version, known simply as POWDER.
The simple version has relatively loose, human-readable 'operational 
semantics,' and is written in XML.

The semantically-rich version, known as POWDER-S, allows POWDER to 
harness the semantic web at large and includes formal semantics that 
underpin the operational semantics. A GRDDL transform automatically 
generates POWDER-S as RDF/OWL from a POWDER document.

There is no restriction on which form to use, but it should be noted 
that the simple version is intended as the primary exchange mechanism 
between systems. All POWDER tools will process POWDER. It is OPTIONAL 
whether this is done using the POWDER-S form so that a processor MAY NOT 
understand this form.

POWDER-S is designed to facilitate incorporation of POWDER information 
in larger RDF-based systems and it should be noted that such systems 
will need to implement two Semantic Extensions to do this (see 
@@@section X@@@).

Importantly, POWDER allows a variety of questions to be answered about a 
given web resource or group thereof, without having to actually retrieve 
the resource(s)."

Rather than a separate section 2, I'd be inclined to end the 
Introduction with a list of the other documents in the suite and give a 
brief explanation of what they cover - the Primer is the starting point, 
the other docs provide the detail.

4 How does POWDER work in the real world?
=========================================
We'll have to check what is and isn't allowed in terms of W3C policy but 
I wonder whether we can provide real world examples here that illustrate 
the abstract use cases. That is, show an actual example of an ICRA 
label, a Technosite label, a Segala label etc. There is precedent for 
this in that the RDF specs make references to PRISM, DC etc. The PICS 
specs include copies of the RSACi and Safe Surf ratings systems. Perhaps 
we could include our 'in house' examples to start with and use this to 
go to others during CR and use the possibility of inclusion in the doc 
as an incentive to implement the tech? basically, as much as the WG 
members are able to supply and commit to in public would be good - and 
that goes as much for Vodafone, AOL and Opera as it does for us 
labelling types!

5. How DO I Use POWDER?
=======================
The first example is (obviously) copied from the DR doc which has since 
been updated so that the maker element takes a ref (see the meeting 
agenda mail for 31/2 [2]). I wonder whether it might be appropriate to 
introduce the key elements of attribution, scope and description and 
then add the angle brackets? The definition of a DR might also be 
useful. See second para of intro to DR doc: "a resource that contains a 
description, a definition of the scope of the description and assertions 
about both the circumstances of its own creation and the entity that 
created it." This comes from the XG Report which may, again, provide 
some useful background [3]. Such a discussion may end up with a repeat 
of the generic example but I'm not sure it should start that way. The 
line by line description of the example is probably too tech for the Primer?

How Do I publish a DR?
======================

1. the DR must be created

That's true of course but I think in a lot of cases (ICRA, Segala, 
Technosite) these are going to be generated on the fly from a database 
so it might be more appropriate to say "made available from a URI"

2. the resources must have some form of reference to the DR that 
describes the resource in question.

Not necessarily. Of course, it's good if the resources do have a link to 
a DR that describes it, but it's not essential. I'd say that step 2 
could be made more generic by saying: "

2. Make the DR easily discoverable. This can be achieved through a link 
from the described resource or through including the DR in a repository 
of many DRs that describe resources that have relevant features in common.

I'm still not 100% sure whether the relationship type is going to be 
powder or possibly describedBy - there's a load of discussion on the 
HTTP list about this and I will be reporting to the group on it in the 
near future. For now, the link example is OK. describedBy may well be 
more appropriate for POWDER-S as I think the expectation may end up 
being that the resource returns a load of triples rather than an XML 
doc. More news when I have it.


When do I use POWDER-S or POWDER?
=================================
See [1].

How do I process DRs?
=====================
Yep, we need some scripts and things here. Chaals promised some such and 
I'm hoping to have some Perl to offer before long (I just need to teach 
myself how to process XML in Perl first, just a small hump to get over 
;-) ).

And yes, we should publish some XQueries. Kev/Andrea should be able to 
help here in due course.

How do I process POWDER-S?
==========================

I think this section needs to include things like SPARQL queries and 
examples from RDF/OWL systems that do and don't implement the semantic 
extension - which gives us a dependency on that development work but the 
doc won't be finished until after CR so that's OK. Explaining the 
Semantic Extensions in natural language here is good. I can work on this 
with our Greek partners. I don't think we need to devote much of the 
Primer to POWDER-S.

6 What do I need to use POWDER?
===============================
I think we want 'the average webmaster' to be feel that they can add 
POWDER to their content without any specialist knowledge. So maybe we 
could create a generic description of a not entirely fictional scenario. 
In ICRA's case, the webmaster will, as now, use our online tool to 
create a DR. They don't need to understand the underlying technology, 
all they need to know is what it says.

I think Technosite and Segala will do similar things, that is, we'll 
take care of the POWDER side of things. So if you use such a service, 
all you need to be able to do is to add a link element to your HTML (and 
even that's going to be optional!).

So if you can do this:

<link rel="stylesheet" href="/styles.css" type="text/css" />

You can easily do this

<link rel="powder" href="/powder.xml" type="application/xml" />

Note the MIME type is application/xml, not the RDF one of 
application/rdf+xml

We also need to include sections on:

1. Having a single URI for the 'latest DR' which uses a 302 redirect to 
the current one which will have its own URI (as discussed at length in 
Washington last year).

2. Reusing elements in a POWDER doc rather than repeating it.

3. Setting up a repository, the FOAF file etc.

This looks daunting, I know, but if the doc has place holders, it can 
show where we're heading and it can evolve based on real experience 
during CR.

Sorry Kai, Diana... you did ask for feedback!

P


[1] 
http://lists.w3.org/Archives/Member/member-powderwg/2008Apr/0001.html 
(member only)
[2] http://lists.w3.org/Archives/Member/member-powderwg/2008Mar/0136.html
[3] http://www.w3.org/2005/Incubator/wcl/XGR-wcl/

Scheppe, Kai-Dietrich wrote:
>  <<WD-powder-primer-20080326.htm>> Hi,
> 
> After the London meeting I have made the discussed changes in the
> document and added Diana's part.
> 
> I would appreciate input to the document in general, some input on those
> items outlined as a pinkish editor's note and also a thorough going
> through on a technical level.
> 
> 
> Thanks
> Kai

Received on Monday, 7 April 2008 13:11:35 UTC