Re: Athens f2f meeting summary

cc the list as discussions like this are useful for the archive I hope.

Andrea Perego wrote:
> Hi, Phil.
> 
> May I ask some questions on your example? They have some relationships 
> also on some of the ideas I'm working on.
> 
> 1. Is "POWDER" the root of the XML document (similarly to "rss" in RSS 
> or "feed" in ATOM)?

We can, of course, call it what we want, we haven't created the schema 
yet, but it seems as good as any. We ended up in Athens with the notion 
of "a POWDER document" that may contain either a single DR or multiple 
DRs in various combinations, all with a common attribution.

> 
> 2. Why the attribution is outside the DR? In such a case, if "POWDER" is 
> the root of the XML doc, we cannot include multiple DRs in the same file.

Yes, we can, but the attribution is shared. This is in line with your 
own suggestions on attributing all triples to the DR author (i.e we 
don't need to use reification, which is generally seen as a dangerous 
thing or named graphs which are not (yet) accepted as part of the SW). 
If you need to have multiple DRs with their own attribution, but 
collected in a single document somehow, you can do this:

<POWDER...>
   <attribution>
     ...
   </attribution>

   <DR rdf:resource="http://Doc_1.xml" />
   <DR rdf:resource="http://Doc_2.xml" />
   ...
</POWDER>

That's an unordered list - so each DR is additive (i.e. Doc 1 and 2 may 
or may not both apply to the same resources, but if they do, then the 
assumption is that they will cover different knowledge domains, so one 
might be a trustmark, one might be subject matter etc.)

We can make those exclusive by creating an ordered list of DRs (put <ol> 
tags before and after the list). That creates what we previously called 
a package where processing order mattered. In the XSLT, the scope of the 
second DR is its own scope _complement of_ DR_1, the scope of DR 2 is 
its own scope complement of the union of the scope of DR_1 and DR_2 and 
so on (Kevin reckons this is possible in XSLT 1 which is jolly good news)

> 
> 3. The "attribution" contains also the issue date, validity period, and 
> the DR's summary. Maybe we should change the name of such XML element 
> (no suggestion for the moment), and use "attribution" instead of "maker".

'Maker', as you know, is a reference to foaf:maker. The GRDDL(XSLT) 
transform will create the foaf:maker triple from the <maker> element - 
but if the group wants to change the names for clarity, there's no 
reason not to at this stage.
> 
> 4. What about using:
> 
>    <validity from="2008-01-01" until="2008-12-31" />
> 
> instead of:
> 
>    <validFrom>2008-01-01</validFrom>
>    <validUntil>2008-12-31</validUntil>

You're thinking XML. Yes, we're using XML but:
  - the semantics of the XML are underpinned by the formal semantics 
which are expressed in the output of the GRDDL transform.
  - There will often be cause to use the rdf namespace within a POWDER 
document.

So the triples that come out of GRDDL will be separate. Of course, we 
can call them what we like, but in POWDER-S, I think it looks clearer to 
have validFrom, validUntil etc. And if that's true, then it feels right 
to use those same terms in the original POWDER doc - but I don't have 
strong feelings either way.

> 
> Note that if "validity" is properly defined, we may also have just
> 
>    <validity from="2008-01-01" />
> 
> or just
> 
>    <validity until="2008-12-31" />

Yep - all temporal validity is optional (and orthogonal to trust btw.)

> 
> 5. Similarly, what about specifying the DR description as follows:
> 
>     <Descriptors>
>       <descriptor name="&ex;color" value="blue" />
>       <descriptor name="&ex;shape" value="square" />
>     </Descriptors>

Yes, we had that kind of construct in some of the examples, it's fine. 
However, this isn't:

<bbfc:cert>http://www.bbfc.org.uk/classification#PG</bbfc:cert>

It really should be

<bbfc:cert rdf:resource="http://www.bbfc.org.uk/classification#PG" />

i.e. if the object of the POWDER-S triple is an RDF Class then it should 
be written as such.

> 
> Note that "value" might have as datatype a space-separated list of 
> strings/URIs.

Hmmm... again, this looks like too much XML thinking. We're not 
abandoning  RDF. On the contrary, we're creating data that can be 
processed operationally in a POWDER-specific environment. If you carry 
out the GRDDL transform, you learn more, without un-learning what you 
already knew. If you implement the semantic extensions we're planning, 
you learn even more, again, without having to unlearn what you already have.

> 
> 6. I'm wondering whether we really need to throw away grouping by 
> property. Just to give an example of how it can be included into a DR-O:
> 
>   <DR>
>     <Scope>x
>       <URISet>
>         <includeHosts>example.org</includeHosts>
>       </URISet>
>       <PropertySet>
>         <ex:color>blue</ex:color>
>         <ex:shape>square</ex:shape>
>       </PropertySet>
>     </Scope>
>     <Descriptors>
>       <ex:color>blue</ex:color>
>       <ex:shape>square</ex:shape>
>     </Descriptors>
>   </DR>
> 
> Does this make sense?

To you and me, yes. To machines, no - at least, that's my understanding. 
  The semantics break down when we start talking about resources rather 
than URIs.

I hope a lot of this will be clearer when I have written more of it up. 
I'm hoping to get a new draft to the WG members by the end of tomorrow. 
Right now I'm on my way to another mobileOK Pro meeting and so am very 
time-poor this week!

Phil.

[snip]

Received on Wednesday, 6 February 2008 09:22:48 UTC