- From: David Rooks <drooks@segala.com>
- Date: Tue, 6 May 2008 16:05:20 +0100
- To: "Powder public" <public-powderwg@w3.org>
- Message-ID: <57e42cb10805060805o446b7902hdbdfe391b4f37b7a@mail.gmail.com>
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 UTC