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: Tue, 6 May 2008 16:05:20 +0100
Message-ID: <57e42cb10805060805o446b7902hdbdfe391b4f37b7a@mail.gmail.com>
To: "Powder public" <public-powderwg@w3.org>
I agree.

Listing exceptions in the way Alan has proposed would effectively be
creating a label with conflicting statements (i.e. a CP x is both true and
false).


On 5/6/08, Phil Archer <parcher@icra.org> wrote:
>
>
> I don't think that's quite right. I always have to think about animals
> when I need to understand sub class relationships.
>
> Whales are a sub class of mammals - i.e. all whales are mammals but not
> all mammals are whales.
>
> What you're saying is that &tswcag10;siteSpecificLabel is a sub class of
> &tswcag10;AA - which makes the site specific label the whale class and
> &tswcag10;AA as the mammal class. Since not all &tswcag10;siteSpecificLabel
> are &tswcag10;AA this doesn't hold.
>
> What you're trying to say is that all mammals are whales except those that
> live on the land, and that aren't dolphins or porpoises, and aren't otters
> and, and... and...
>
> I know it looks verbose but I think you really will have to list which
> checkpoints the site has passed, rather than listing exceptions. You can
> take short cuts though. If a site passes A _and_ some specific checkpoints
> but doesn't reach AA, then you list the A class plus those checkpoints, but
> it's still a positive list rather than a list of reasons why the creature in
> front of us would be a really good example of a whale if only it weren't
> quite so small and furry and didn't have those annoying leg things attached.
>
> Make any sense at all?
>
> If in doubt, Kai's the resident marine expert, not me ;-)
>
> P
>
>
> Alan Chuter wrote:
>
> > 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
> > > >
> > > >
> > > >
> > > >
>
>
>
Received on Tuesday, 6 May 2008 15:05:58 GMT

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