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

Re: Exceptions to a label's normal rules

From: David Rooks <drooks@segala.com>
Date: Fri, 2 May 2008 10:08:18 +0100
Message-ID: <57e42cb10805020208v32ff78ccq71c353ea801cb707@mail.gmail.com>
To: "Powder public" <public-powderwg@w3.org>
Thats exactly how we do it Phil...

Furthermore, we can do things like pre-defining WCAG-A, AA & AAA labels.



On Fri, May 2, 2008 at 9:35 AM, Phil Archer <parcher@icra.org> wrote:

>
> 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 09:08:52 GMT

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