W3C home > Mailing lists > Public > public-powderwg@w3.org > January 2008

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

From: Phil Archer <parcher@icra.org>
Date: Thu, 17 Jan 2008 16:28:37 +0000
Message-ID: <478F8235.30707@icra.org>
To: public-powderwg@w3.org
CC: Jeremy Carroll <jjc@hpl.hp.com>

Just to come back to this for a moment (sorry)...

The OWL version of a DR, as we have discussed since Boston and that is 
now becoming 'POWDER Full' or DR-S for 'Semantic DR' (or some other name 
but can we please decide soon)... anyway, the URIset is a sub class of 
the descriptor class, as written by Jeremy C at [1] does suggest that 
for the operational (POWDER Lite) format we should have

DR -> Scope
DR -> Description

Not

DR -> Scope -> Description

Although I don't suppose we're quite done with this issue yet. If the 
practical reality is that agents are going to processes POWDER Lite 
without doing the transform into POWDER Full, then Chaals's argument 
about parsers getting the wrong end of the stick may still hold? But, 
the point of the GRDDL transform is to make the full semantics explicit 
so maybe this aspect is covered?

Yours,

Confused of Ipswich.

[1] http://www.w3.org/2007/OWL/wiki/POWDER#Example_as_POWDER_Full

Charles McCathieNevile wrote:
> 
> Su Majestad, Vos eminences,
> 
> my comments, claims, and possible errors of commission are inserted 
> below at the relevant point. The short answer is I am still holding out 
> for this issue, because I think the current data structure means that an 
> RDF processor would make incorrect assumptions about our data and 
> therefore authorise treatment of it which follows the RDF spec but 
> breaks our semantics.
> 
> On Wed, 05 Sep 2007 21:49:12 +0900, Smith, Kevin, VF-Group 
> <Kevin.Smith@vodafone.com> wrote:
> 
>> It seems that if the RS contains the DR, it will need the
>> embargo/expiration and the foaf:maker too so that trustworthiness can be
>> established.
> 
> No. If you want to keep that information around, you have the original 
> document, or you make a data structure that shifts it to suit your 
> internal purposes. You do it where you want an optimisation. If you want 
> the DR, use the full DR.
> 
>> -----Original Message-----
>> From: public-powderwg-request@w3.org
>> [mailto:public-powderwg-request@w3.org] On Behalf Of Phil Archer
>> Sent: 04 September 2007 16:55
>> To: public-powderwg@w3.org
>> Subject: Re: Descriptors linked from RS or DR? (again)
>>
>>
>> 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.
> 
> Right, and not terribly useful.
> 
>>> -----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)
> 
>>> At present, the structure of a Description Resource is:
> ...
>>> 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.
> 
> Although this is an optimisation that explicitly removes the 
> attribution, so you don't use it without realising that.
> 
>>>    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).
> 
> You cannot process this entirely without some POWDER-specific routines. 
> However, you can take a resource, such as a DR, and do intelligent 
> things with a pure RDF engine such as adding further information about 
> where it came from, or noting that there are properties and classifying 
> them even if you don't understand them, or translating the information 
> to some other formalism (database tables, looking at them in tabulator, 
> etc).
> 
> The reason for my proposal is that as I understand it, option A will 
> lead any non=POWDER-aware system to process the data in a way which is 
> actually wrong. In other words, unless you isolate this data from all 
> non-POWDER aware systems, you risk polluting the semantic web with a 
> whole lot of statements that look like RDF but in fact lead to incorrect 
> data structures.
> 
>>> The points in favour of option A are (correct me if I'm wrong Andrea)
> 
>>>    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.
> 
> But possible. I don't think you can do this at all in our current model 
> - although yu can merge two things with the same set of descriptors, or 
> you can merge two sets of resources and their sets of descriptors just 
> blindly asserting that all the descriptions from each side are accurate 
> for all the assertions.
> 
> Nothing would stop you doing that in the proposed model, except that you 
> merge at the level of RS, not DR. Since whoever did the merge should 
> take responsibility for the claim, this makes more sense than some magic 
> merge where you somehow decide which set of attribution information to 
> remove, and makes more sense than the further restriction that you can 
> only merge where the attribution is the same. In the proposed model, if 
> you decide to merge another resource set into your DR you jast grab it. 
> If you decide to make claims about the joint set beyond those which are 
> already in the RS that you accepted, you can do so.
> 
> (As I understand the owl,
> 
> <Beer>
>  <owl:unionOf>
>    <Foo>
>     <hasProp r:resource="ABar">
>     <hasProp r:resource="ABetterBar">
>    </Foo>
>    <Foo>
>     <hasProp r:resource="ABar">
>     <hasProp r:resource="AnotherBar">
>    </Foo>
>  </owl:unionOf>
> </Beer>
> 
> implies
> 
> <Beer>
>  <owl:unionOf>
>    <Foo>
>     <hasProp r:resource="ABetterBar">
>    </Foo>
>    <Foo>
>     <hasProp r:resource="AnotherBar">
>    </Foo>
>  </owl:unionOf>
>  <hasProp r:resource="ABar">
> </Beer>
> 
> but not vice versa, so if you wanted to further mess around with the 
> bits inside you should keep their descriptors explicit inside them as 
> well).
> 
>>> 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??
> 
> Yes, except that if RS supports the hasDescriptors then so does any 
> subclass. Instead, we should define a "DescribedRS" that has to have a 
> descriptor (and should normally be used) which, along with PartSetDef, 
> is a subclass of RS, and not require an RS to have a descriptor.
> 
>>> The point about introducing the requirement that an RS MUST be linked
>>> to a block of Descriptors is that it provides another validation step.
> 
> Indeed. How important is this?
> 
>>> 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.
> 
> Given the validation thing above, I would propose that we make it an RS 
> SHOULD have a hasTag (or more), and that a DescribedResourceSet MUST 
> have one (minCardinality 1), or even must have a hasDescriptor (the 
> version where we know there is a URI, not just a random tag).
> 
>>> Any feedback? We need to nail this as it's holding us us...
> 
> Actually I would be happy to note the issue in the draft and request 
> explicit feedback, and then publish.
> 
>>> Phil Archer wrote:
> ...
>>>> At its most basic, a DR states that:
>>>>
>>>> {Organisation} asserts that {Resource Set} is described by
>>>> {Descriptors}
> ...
>>>> 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.
> 
> Except in terms of RDF, which has no way, in the current structure, to 
> understand that the hasDescriptors is meant to apply properties to the 
> Resource Set, and instead specifies for any conformant RDF engine that 
> the Descriptions in hasDescriptors actually apply to the DR itself.
> 
> This seems to me a bad use of RDF. It is perfectly sound to require 
> processors to understand particular terms in order to process some 
> specific RDF vocabulary in a way that is designed to do something. Some 
> FOAF and RDFIcal systems do this, interpreting the "nearestAirport" 
> property to provide a map view or something. But it is not a good idea 
> to say that the nearestAirport applies, in RDF terms, to the RDF 
> document, and then expect people to make special processors, or just 
> never try to interpret what is in fact valid RDF (although the 
> information it tries to model is expressed incorrectly in terms of RDF's 
> basic semantics).
> 
> An alternative would be to ask some hard-core RDF geeks what the model 
> says - it may be that I am wrong in my interpretation, but I don't think 
> so.
> 
> Cheers
> 
> Chaals
> 
> --  Charles McCathieNevile, Opera Software: Standards Group
>   hablo español  -  je parle français  -  jeg lærer norsk
> chaals@opera.com   http://snapshot.opera.com - Kestrel (9.5α1)
> 
> 
> 

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/
Received on Thursday, 17 January 2008 16:28:59 GMT

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