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

Re: Exceptions to a label's normal rules

From: Alan Chuter <achuter@technosite.es>
Date: Mon, 5 May 2008 13:27:10 +0200
Message-ID: <79cab0900805050427k5a4adb6bkd7e3dded11019101@mail.gmail.com>
To: "Powder public" <public-powderwg@w3.org>

Thanks all for working on this. As I understand it, there is no prior
assumption about whether content conforms to the checkpoints or not,
the label schema simply enumerates what checkpoints are evaluated for
the label with the necessary boolean value.

A label with an exception would still be a new label, but a subclass
of the main one, with the relevant values as false rather than true.
Is that the intention? Like this:

<owl:Class rdf:about="&tswcag10;siteSpecificLabel">
  <rdfs:label xml:lang="en">Technosite Label WCAG 1.0 Level A, except
that content doesn't comply with checkpoint 1.5</rdfs:label>
  <rdfs:subClassOf rdfs:resource="&tswcag10;AA" />
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Restriction>
      <owl:onProperty rdf:resource="#cp1.5_compliance" />
    </owl:Restriction>
    <owl:hasValue>0</owl:hasValue>
  </owl:intersectionOf>
</owl:Class>

regards,

Alan





2008/5/2 Phil Archer <parcher@icra.org>:
>
>  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
> >
> >
> >
>
>
>
>



-- 
Alan Chuter,
Senior Web Accessibility Consultant, Technosite (www.technosite.es)
Researcher, Inredis Project (www.inredis.es/)
Email: achuter@technosite.es
Alternative email: achuter.technosite@yahoo.com
Blogs: www.blogger.com/profile/09119760634682340619
Received on Monday, 5 May 2008 11:27:51 GMT

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