W3C home > Mailing lists > Public > public-powderwg@w3.org > September 2007

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

From: Phil Archer <parcher@icra.org>
Date: Tue, 04 Sep 2007 16:54:38 +0100
Message-ID: <46DD7FBE.4060205@icra.org>
To: public-powderwg@w3.org

No, we didn't think of that, but as I understand Chaals, you'd look at 
the whole DR, including the attribution and expiry data and only then 
decide to process the RS and D. They wouldn't exist outwith the DR, but 
might be processed in an optimised system deep in a Norwegian Fjord once 
their credentials had been established.

Putting the expiry dates etc. in the RS is getting close to getting rid 
of the DR altogether and just having an RS with all the stuff in it - 
which is really back to option A.

AGH! This is driving me potty.

Yours ever,

King of Spain.

Smith, Kevin, VF-Group wrote:
> 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:54:55 GMT

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