- From: Phil Archer <parcher@icra.org>
- Date: Tue, 06 May 2008 15:25:01 +0100
- To: Powder public <public-powderwg@w3.org>
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 14:26:09 UTC