Re: Exceptions to a label's normal rules

Thanks Stasinos,

Your comments have helped me to understand better what Alan was asking 
in the first place!

Your POWDER-S methods clearly all work and have the right semantics but 
I wonder whether we're getting into domain-specifics here.

In the nudity section of the ICRA vocabulary we have the following:

1 Exposed breasts
2 Bare buttocks
3 Visible genitals
4 No nudity

Where if you assert any of 1 - 3 then 4 cannot be true. Although we 
cannot physically prevent people from asserting all 4, the label 
generator uses JavaScript to prevent you from doing this, in the label 
tester it shows as invalid and so on. If you assert 4 then this is a 
positive declaration that there is no nudity present. So what happens if 
you assert none of them? Then we say that 'Nudity may be, but is not 
necessarily, present'.

This all stretches the formal semantics a little but it's the way we've 
always interpreted it (irrespective of encoding).

I think what Alan might consider is setting up some properties for each 
accessibility check point that take a Boolean value, so in POWDER we'd have

<descriptorset>
   <ts:cp1.1_compliance>1</ts:cp1.1_compliance>
   ...
   <ts:cp11.4_compliance>1</ts:cp11.4_compliance>
   <ts:cp12.1_compliance>0</ts:cp12.1_compliance>
   <descriptiontext>This material meets some, but not all, WCAG A 
checkpoints</descriptiontext>
</descriptorset>

which positively asserts that check points 1.1 - 11.4 have passed, and 
that 12.1 failed (which is different from saying nothing about 12.1 at all).

In POWDER-S that would automatically be rendered as

<owl:Class rdf:nodeId="descriptorset_1">
   <dc:description>This material meets some,
       but not all, WCAG A checkpoints</dc:description>
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="&ts;#cp1.1_compliance"/>
       <owl:hasValue>1</owl:hasValue>
     </owl:Restriction>
     ...
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="&ts;#cp11.4_compliance"/>
       <owl:hasValue>1</owl:hasValue>
     </owl:Restriction>
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Restriction>
       <owl:onProperty rdf:resource="&ts;#cp12.1_compliance"/>
       <owl:hasValue>0</owl:hasValue>
     </owl:Restriction>
   </owl:intersectionOf>
</owl:Class>

This gives a granular description and the Boolean value is appropriate. 
Alan could include in the vocabulary a single Class that represented 
WCAG A and point to that in the POWDER doc as

<descriptorset rdf:resource="&ts;A" />

Which, according to the discussion we had [1] would mean that the 
POWDER-S would be

<owl:Class rdf:nodeID="descriptorset_1">
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Class rdf:about="&ts;A" />
   </owl:IntersectionOf>
</owl:Class>

Which is more verbose than necessary but is practical in terms of the 
XSLT. (Incidentally, I've learnt to write <owl:Class rdf:about="... not 
rdr:resource...)

In other words, I think the POWDER design we're working flat out to get 
written up fully and published is already sufficient - it's a question 
of designing the vocabulary effectively. All of which is very good 
material for the Primer!

Phil.

[1] http://lists.w3.org/Archives/Public/public-powderwg/2008Apr/0054.html


Stasinos Konstantopoulos wrote:
> Alan,
> 
> On Tue Apr 29 14:40:30 2008 Alan Chuter said:
> 
>> Phil suggests:
>> ...if you want to have a ready-made label that has several checkpoints
>> except others then the vocab file could include, say:
>>
>> <owl:Class rdf:about="&tswcag10;A">
>>      <rdfs:label xml:lang="en">Technosite Label WCAG 1.0 Level A</rdfs:label>
>>      <owl:intersectionOf rdf:parseType="Collection">
>>        <owl:Class rdf:about="#cp1.1_compliance" />
>>        <owl:Class rdf:about="#cp1.2_compliance" />
>>        <owl:Class rdf:about="#cp1.3_compliance" />
>>        <owl:Class rdf:about="#cp1.4_compliance" />
>>        <owl:Class rdf:about="#cp2.1_compliance" />
>>        <owl:Class rdf:about="#cp4.1_compliance" />
>>        <owl:Class rdf:about="#cp5.1_compliance" />
>>        <owl:Class rdf:about="#cp5.2_compliance" />
>>        <owl:Class rdf:about="#cp6.1_compliance" />
>>        <owl:Class rdf:about="#cp6.2_compliance" />
>>        <owl:Class rdf:about="#cp6.3_compliance" />
>>        <owl:Class rdf:about="#cp7.1_compliance" />
>>        <owl:Class rdf:about="#cp9.1_compliance" />
>>        <owl:Class rdf:about="#cp11.4_compliance" />
>>      </owl:intersectionOf>
>>      <owl:complementOf rdf:parseType="Collection">
>>        <owl:Class rdf:about="#cp12.1_compliance" />
>>        <owl:Class rdf:about="#cp14.1_compliance" />
>>      </owl:complementOf>
>>    </owl:Class>
>>
>> As you'll recognize this specifically excludes checkpoints 12.1 and 14.1.
> 
> This should be:
> 
> <owl:Class rdf:about="&tswcag10;A">
>   <rdfs:label xml:lang="en">Technosite Label WCAG 1.0 Level A</rdfs:label>
>   <owl:intersectionOf rdf:parseType="Collection">
>     <owl:Class rdf:about="#cp1.1_compliance" />
>     <owl:Class rdf:about="#cp1.2_compliance" />
>     <owl:Class rdf:about="#cp1.3_compliance" />
>     <owl:Class rdf:about="#cp1.4_compliance" />
>     <owl:Class rdf:about="#cp2.1_compliance" />
>     <owl:Class rdf:about="#cp4.1_compliance" />
>     <owl:Class rdf:about="#cp5.1_compliance" />
>     <owl:Class rdf:about="#cp5.2_compliance" />
>     <owl:Class rdf:about="#cp6.1_compliance" />
>     <owl:Class rdf:about="#cp6.2_compliance" />
>     <owl:Class rdf:about="#cp6.3_compliance" />
>     <owl:Class rdf:about="#cp7.1_compliance" />
>     <owl:Class rdf:about="#cp9.1_compliance" />
>     <owl:Class rdf:about="#cp11.4_compliance" />
>     <owl:Class>
>       <owl:complementOf>
>         <owl:Class rdf:about="#cp12.1_compliance" />
>       </owl:complementOf>
>     </owl:Class>
>     <owl:Class>
>       <owl:complementOf>
>         <owl:Class rdf:about="#cp14.1_compliance" />
>       </owl:complementOf>
>     </owl:Class>
>   </owl:intersectionOf>
> </owl:Class>
> 
> Although I don't think there is a way of saying in POWDER/XML that a
> property does not hold, this this document would have to be written
> directly in POWDER-S. Or the WG should consider providing for negation
> in POWDER/XML.
> 
> NOTE that according to OWL open-world semantics there is no assumption
> made about unspecified properties, so that not stating that a property
> holds is different from stating that a property does not hold. Any
> property defined anywhere in the universe might hold for a resource
> unless there is an explicit or inferred statement to the contrary.
> 
>> Alan says: But I this means creating a new label for each case, in
>> OWL. Is there no way to simply say *in the label* that some of the
>> rules are not complied with?
> 
> That's exactly what you're doing here, giving a name to
> interesting and commonly seen mixtures of haves and have-nots. 
> 
> You can create a hierarchy of increasingly specific label-aggregates:
> 
> <owl:Class rdf:about="&tswcag10;AB">
>   <rdfs:label xml:lang="en">Technosite Label WCAG 1.0 Level A or B</rdfs:label>
>   <owl:intersectionOf rdf:parseType="Collection">
>     <owl:Class rdf:about="#cp1.1_compliance" />
>     <owl:Class rdf:about="#cp1.2_compliance" />
>     <owl:Class rdf:about="#cp1.3_compliance" />
>     <owl:Class rdf:about="#cp1.4_compliance" />
>     <owl:Class rdf:about="#cp2.1_compliance" />
>     <owl:Class rdf:about="#cp4.1_compliance" />
>     <owl:Class rdf:about="#cp5.1_compliance" />
>     <owl:Class rdf:about="#cp5.2_compliance" />
>     <owl:Class rdf:about="#cp6.1_compliance" />
>     <owl:Class rdf:about="#cp6.2_compliance" />
>     <owl:Class rdf:about="#cp6.3_compliance" />
>     <owl:Class rdf:about="#cp7.1_compliance" />
>     <owl:Class rdf:about="#cp9.1_compliance" />
>     <owl:Class rdf:about="#cp11.4_compliance" />
>   </owl:intersectionOf>
> </owl:Class>
> 
> which leaves cp12.1 and cp14.1 unspecified, and can have two refinements
> which inherit the common properties and build upon them:
> 
> <owl:Class rdf:about="&tswcag10;A">
>   <rdfs:label xml:lang="en">Technosite Label WCAG 1.0 Level A</rdfs:label>
>   <owl:intersectionOf rdf:parseType="Collection">
>     <owl:Class rdf:about="#AB" />
>     <owl:Class>
>       <owl:complementOf>
>         <owl:Class rdf:about="#cp12.1_compliance" />
>       </owl:complementOf>
>     </owl:Class>
>     <owl:Class>
>       <owl:complementOf>
>         <owl:Class rdf:about="#cp14.1_compliance" />
>       </owl:complementOf>
>     </owl:Class>
>   </owl:intersectionOf>
> </owl:Class>
> 
> <owl:Class rdf:about="&tswcag10;B">
>   <rdfs:label xml:lang="en">Technosite Label WCAG 1.0 Level B</rdfs:label>
>   <owl:intersectionOf rdf:parseType="Collection">
>     <owl:Class rdf:about="#AB" />
>     <owl:Class rdf:about="#cp12.1_compliance" />
>     <owl:Class rdf:about="#cp14.1_compliance" />
>   </owl:intersectionOf>
> </owl:Class>
> 
> Obviously, both #A and #B are rdfs:subClassOf #AB, which can be
> explicitly stated but does not need to, as any OWL tool will be able
> to infer it.
> 
> You *cannot* have defaults which are subsequently overriden.
> 
> Hope this helps a bit,
> stasinos
> 
>

Received on Friday, 2 May 2008 08:36:30 UTC