RE: New version of primer

Hi Phil,

Great feedback and not daunting at all!
A lot of the suggested additions will have be supplied by others, so
please read the document...

Thanks
Kai


 

> -----Original Message-----
> From: public-powderwg-request@w3.org 
> [mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
> Sent: Monday, April 07, 2008 2:55 PM
> To: Public POWDER
> Subject: 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 15:08:31 UTC