RE: Descriptors linked from RS or DR? (again)

Hi Phil,

Not sure if we discussed this, but if the RS contains the description,
would it also need to allow embargo/expiration dates, and a URI from
which an updated description could be fetched in the event of
expiration? Otherwise there is a risk of untrustworthy descriptions with
no obvious way to check if they still hold.

Cheers
Kevin 

-----Original Message-----
From: public-powderwg-request@w3.org
[mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
Sent: 04 September 2007 16:09
To: Public POWDER
Subject: Re: Descriptors linked from RS or DR? (again)


This issue was discussed again in the telecon on Monday and I took an 
action item to send something to the list. Here it is...

At present, the structure of a Description Resource is:

<wdr:DR>
   <attribution>
   <ResourceSet>
   <Descriptors>
</wdr:DR>

Call that option A.

The question is, should we change this for option B:

<wdr:DR>
   <attribution>
   <ResourceSet>
     <Descriptors>
   </ResourceSet>
</wdr:DR>

Oh it looks so minor...

Points in favour of option B (correct me if I'm wrong Charles)

  1. Once you have parsed a DR and decided it's trustworthy, for 
internal processing you can throw away the attribution and the rest of 
the DR and just take the Resource Set and the Descriptors. This is a 
pointer to efficiency.

   2. It is much more sound semantically to have Resource Set -> 
Descriptors. It's a lot closer to the established RDF model (although 
I'm not convinced that you could process this entirely without having to

use POWDER-specific routines).

The points in favour of option A are (correct me if I'm wrong Andrea)

   1. The structure is much simpler to understand, especially for people

creating DRs.

   2. The real problem comes when you have a DR with a complex scope 
such as:

<wdr:DR>
   <attribution>
   <ResourceSet>
     <owl:unionOf>
       <ResourceSet1>
       <ResourceSet2>
     </owl:unionOf>
   </ResourceSet>
</wdr:DR>

If we're going to link the Descriptors from the RS, there are three 
possible places it could go. You could have:

<wdr:DR>
   <attribution>
   <ResourceSet>

     <owl:unionOf>

       <ResourceSet1>
         <Descriptors_A>
       </ResourceSet1>

       <ResourceSet2>
         <Descriptors_B>
      </ResourceSet2>

     </owl:unionOf>
     <Descriptors_C>
   </ResourceSet>

</wdr:DR>

Call this example C

That is, three separate Descriptor Classes, one for each RS. To which 
Charles says something like 'so what?' Why is that bad?

Well, IMHO it's only bad if it's an error. That is, if you didn't mean 
to associate a Descriptors Class with a particular RS. Our thinking 
tends to be: One DR has one Resource Set and one set of Descriptors 
(although a given Resource Set or Descriptors set may comprise several 
sets in union or intersection). Example C is only complicated because, 
well, it's complicated. The simple version - option B - is no more 
complex than option A. And it's the fact that the creator wants to 
describe the three different Resource Sets differently - which is a 
complex thing to want to do - that makes the DR complex.

How would you process Example C?

You'd do some SPARQL to find out that the RS is a union of two others 
and that that the Descriptors linked from that union applied to both its

constituent sub sets.

Then you'd parse each sub set and find a bunch of descriptors that 
applied to each of those (and that, for example, Descriptors_B did not 
describe RS 1. (More concrete example: RS 1 is the mobileOK stuff, RS 2 
is the accessible stuff, the overall RS is all child-friendly).

That doesn't seem bad.

Can we constrain some of this to help mitigate errors? My suggestion is 
that (if we go with option B)

1. We define the wdr:hasDescriptors property has having Resource Set as 
its domain and that an RS MUST have this property (i.e. owl:cardinality
= 1)

2. We define a sub class of Resource Set that doesn't support the 
hasDescriptors property. A processor would 'know' that such a class was 
only described when considered part of the overall RS.

It's probably a bad idea to call this a sub set but it does provide a 
partial definition of a Resource Set so how about wdr:PartSetDef.

So we might have something like

<wdr:DR>
   <attribution />
   <ResourceSet1>
     <owl:intersectionOf>

       <PartSetDef />

       <ResourceSet2>
         <Descriptors_A>
      </ResourceSet2>

     </owl:intersectionOf>
     <Descriptors_B>
   </ResourceSet1>

</wdr:DR>

This says that RS 2 is described by Descriptors A; the partial set 
definition has no description but resources that meet that definition 
AND are in RS 2 are described by Descriptors B.

This is a little complex! Actually, I'd probably want to use a package 
to do this a little differently, but the approach seems logically sound 
to me. You too??

The point about introducing the requirement that an RS MUST be linked to

a block of Descriptors is that it provides another validation step.

A DR MUST include wdr:hasScope and that MUST link to a Resource Set. In 
turn, that RS MUST have a wdr:hasDescriptors property linked to a 
Descriptor set. If you want to create a complex RS with OWL set 
operators then, if you use an RS, the validator will require you to put 
in another wdr:hasDescriptors. If that's not what you want, you 
consciously use PartSetDef which is not described.

One more thing. What Charles actually proposed in Washington was that an

RS MUST have a property of 'hasTag' - which can link to anything, 
including free text, and then we define a sub property of that which is 
the hasDescriptors property.

Any feedback? We need to nail this as it's holding us us...

Phil


Phil Archer wrote:
> 
> I had a brief chat with Charles earlier in the week and he said he
still 
> has reservations about linking to the Descriptors block from the DR 
> rather than the RS. I wanted to spend some time thinking the issues 
> through a bit more and see if the 'correct route' became any clearer.
> 
> At its most basic, a DR states that:
> 
> {Organisation} asserts that {Resource Set} is described by
{Descriptors}
> 
> It therefore makes perfect sense for the Descriptors to hang off the
RS 
> and this is why I have been supportive of Charles' point. But, a DR 
> usually will have a bit more to it than that. Actually, it's
> 
> On {issue date}, {Organisation} described {Resource Set} as 
> {Descriptors} and will stand by that until {valid until date}
> 
> Again, linking the Descriptors from the RS seems to make sense.
> 
> However... it's important that we wrap all that into a container that
we 
> call a Description Resource which has its own identity and can
therefore 
> be the subject of further assertions.
> 
> Our current structure has the Descriptors linked from the DR thus:
> 
> <wdr:DR>
>   <foaf:maker rdf:resource="http://www.example.org/foaf.rdf#me" />
>   <dcterms:issued>2007-07-20</dcterms:issued>
>   <wdr:validUntil>2008-07-19</wdr:validUntil>
> 
>   <wdr:hasScope ... />
> 
>   <wdr:hasDescriptors ... />
> </wdr:DR>
> 
> Putting that in prose we get
> 
> A {Description Resource} was created by {organisation} on {issue date}

> that will expire on {valid until date} that describes {Resource Set}
as 
> {Descriptors}.
> 
> Which seems to me to have the right semantics. What Charles is 
> advocating is
> 
> <wdr:DR>
>   <foaf:maker rdf:resource="http://www.example.org/foaf.rdf#me" />
>   <dcterms:issued>2007-07-20</dcterms:issued>
>   <wdr:validUntil>2008-07-19</wdr:validUntil>
> 
>   <scope> is Described by <Descriptors>
> 
> </wdr:DR>
> 
> Again, in prose I see this as
> 
> A {Description Resource} was created by {organisation} on {issue date}

> that will expire on {valid until date} that covers {Resource Set}
which 
> is described by {Descriptors}.
> 
> You might be able to come up with a better bit of prose but the 
> difference between the two isn't huge. There is, however, more
distance 
> between the organisation and the description they provide which I'm a 
> little uneasy about.
> 
> Andrea made the valid point about Resource Set combinations and 
> cardinality constraints and suggested that there was little difference

> in processing efficiency [1]. In order to explore this in more detail
I 
> need to see pictures.
> 
> I've created two pairs of DRs. The first pair has a single Resource
Set 
> with 'Def1.rdf' [2] putting the Descriptor block inside the Resource 
> Set. See the graph of this at [2A]. Def2.rdf has the Descriptor block 
> separate within the DR [3, 3A].
> 
> It's not clear to me which is the 'winner' here. I can write a sample 
> SPARQL query for either case that will return all the data I need.
> 
> But what if we have a composite Resource Set? i.e. we're using 
> owl:unionOf/intersectionOf to make a complicated Resource Set. As
Andrea 
> pointed out, it becomes unclear where the isDescribedBy predicate
goes. 
> So let's make it clearer by defining a new class called something like

> 'partResourceSet' which can be used in OWL set operations but cannot 
> have an isDescribedBy' predicate.
> 
> That gives the other pair of DRs. partDef1.rdf [4, 4A] has the 
> Descriptors as part of the RS block, partDef2.rdf [5, 5A] has the 
> Descriptors as part of the DR.
> 
> Again, there doesn't seem to be a  substantial difference in the 
> complexity (the use of OWL set operators make it more complicated, but

> not the positioning of the Descriptors).
> 
> So I come to the conclusion that the real difference in in the 
> semantics. For me, it makes more sense to make the Descriptors part of

> the DR directly - they're provided by the foaf:maker as much as the 
> Resource Set definition is. In other words, having given it more 
> thought, I am happy with the resolution we took last Monday to rescind

> the resolution taken the previous Monday!
> 
> If someone can argue the other way I'd be delighted.
> 
> Phil.
> 
> 
> [1] 
> http://lists.w3.org/Archives/Member/member-powderwg/2007Jul/0013.html 
> (member only sorry)
> [2]  http://www.fosi.org/projects/powder/Def1.rdf
> [2A] http://www.w3.org/RDF/Validator/ARPServlet.tmp/servlet_9601.png
> [3]  http://www.fosi.org/projects/powder/Def2.rdf
> [3A] http://www.w3.org/RDF/Validator/ARPServlet.tmp/servlet_9597.png
> [4]  http://www.fosi.org/projects/powder/partDef1.rdf
> [4A] http://www.w3.org/RDF/Validator/ARPServlet.tmp/servlet_9583.png
> [5]  http://www.fosi.org/projects/powder/partDef2.rdf
> [5A] http://www.w3.org/RDF/Validator/ARPServlet.tmp/servlet_9589.png
>

Received on Tuesday, 4 September 2007 15:32:53 UTC