Re: The ROLE attribute

Distribution note:
PF copy moved to XTECH list; the "RDF in XHTML Task Force" list is 
public anyway.
For background, please consult
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Oct/thread.html#0

Lisa,

We have to distinguish the relationship Ben is after (what semantics
are implied by using an @role attribute in XHTML 2.0) and the
superclass that we have in our draft.

It may be unfortunate that the same token is used to name these
rather different things.

Ben,

Is there a definition for the rdf:type relation?

It took me a discouraging amount of time to chase through the RDF
documents until I got to a remark implying that there is no
uniqueness constraint on rdf:type; that rdf:type can be used
repeatedly to indicate multiple heredity.

<quote cite=
"http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-typed-nodes">

There may, of course, be multiple rdf:type predicates

</quote>

It's frustrating that the authors find this so obvious because there
appears to be no discussion of the rdf:type or heredity concepts in
the "RDF Concepts" volume. Without a clearly specified primitive
concept of is_a or heredity, it's very hard to say if xhtml2:role is
just a syntax/rename of rdf:type or if there is more to it (or less).

Never mind the grumbles. What we need is:

We need for the following processing logic to apply when a
wai:widgetClass is cited as xhtml2:role for an element.

The wai:widgetClass is an assertion collection with an un-bound
subject. [Is this the blank node function? Or are we in the
named-graph territory? That's where we need help from RDF Best
Practices for what has worked in actual many-unrelated-sources use.]

The element bearing the @role value of wai:widget class, by dint of
this markup, is meant to inherit [or elaborate?] assertions about
this element that aside from the logical/physical subject
substitution, are the same as in the collection articulated for this
URI=className *in the WAI document [draft:
http://www.w3.org/WAI/PF/GUI/].*

In other words, we want a provenance-pruned import of assertions
about the referenced node a.k.a. URI. This doesn't have to be true of
all uses of xhtml2:role but it's not clear the community will accept
anything which depends on a "read no further" decision being reached
based on what is at the far end of the URI (reference) which is the
expanded value of the QName value of the @role attribute.

This is the controlled-vocabulary side of our needs. We need to be
able to use controlled names in a way that the simpleminded syntax
processor in the client knows it's a controlled term and doesn't have
to get into RDF processing to figure that out.

Maybe it is enough for the simple-minded processor
http://www.w3.org/2002/02/mid/p06110405be859babf575@%5B10.0.1.2%5D;list=wai-xtech
to distinguish *known* terms and not bother with knowing in general
which of the unknown terms are controlled-vocabulary terms and which
are general RDF concept nodes amenable to modification by the
universe of web participants piling on assertions.

But even in this case there needs to be some sort of a pragma within the
RDF domain so that some RDF-breathing processors would come to the
same answer as the simple-minded processor.  At least to the extent
of knowing the distinction between the consensed assertions contained
in the W3C document as opposed to the general run of banter about these
same nodes.

Some of us looked at SKOS and found its concept applicable.  Some
of what might help us would be to compare and contrast what is in
SKOS about "defined in" and "narrows" and "resembles" vs. the
rdf:type concept.

Al

At 10:05 AM +0200 10/3/05, Lisa Seeman wrote:
>This is very important to me
>
>As part of our work at the WAI (Web Accessibility Initiative) we 
>have been building Role taxonomies to add to other base languages 
>for enhanced accessibility.
>The roles (and adaptable properties) drafts are now public.
>The main current use case at the moment is scripting and dynamic 
>content , but we intend to extend it soon to give a better structure 
>of a page and  types of content for better adaptation.
>
>  <http://www.w3.org/WAI/PF/GUI>http://www.w3.org/WAI/PF/GUI
>
>
>The current use case is explained in full detail at
><http://www.w3.org/WAI/PF/roadmap>http://www.w3.org/WAI/PF/roadmap
>
>(and the DTD for support of  adaptable properties is at 
><http://www.w3.org/WAI/PF/adaptable>http://www.w3.org/WAI/PF/adaptable)
>
>It is very important that our specification works with this decision.
>
>So far we are doing the following:
>
>1, We have defined role as follows:
>
><owl:Class rdf:ID="Role">
>
><rdfs:comment>This is a draft resource for adding semantic 
>annotations and information to Web resources. Knowing what the types 
>of content are in a Web page allows for better customized renderings 
>such as information hiding, or rendering common types of content in 
>a consistent way. It makes the Web easer to use and more accessible. 
>You can also use this for device independence so that content is 
>better formatted to fit on the device. </rdfs:comment>
>
>
><rdfs:subClassOf>
>
><owl:Restriction>
>
><owl:onProperty rdf:resource="dc:description"/>
>
><owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
>
></owl:Restriction>
>
></rdfs:subClassOf>
>
><rdfs:comment>You have to give each content type a description - 
>sorry folks (just be glad I did not put a min length on the 
>description</rdfs:comment>
>
><rdfs:comment>These are the required properties - however we 
>recommend also using also  role:importance, and supportedState. 
></rdfs:comment>
>
></owl:Class>
>
>2, We have then defined  subclasses and instances  to build the taxonomy:
>
>For example - a Checkbox is a type of  Input that is a type of 
>Widget that is a type of  Role. The new properties above an input is 
>that it must support the "checked"  state.
>
><owl:Class rdf:ID="Checkbox">
>
><rdfs:subClassOf rdf:resource="#Input"/>
>
><dc:description <xml:lang=>xml:lang="en">An input that has two 
>possible values, an equivalent to a boolean. </dc:description>
>
><role:supportedState rdf:parseType="Resource">
>     <rdfs:value>states:checked</rdfs:value>
>     <role:default>false</role:default>
></role:supportedState>
>
><rdfs:comment <xml:lang=>xml:lang="en">checked="true"|"false"</rdfs:comment>
>
><role:domRef rdf:resource="&states;childContent"/>
>
></owl:Class>
>
>3, We then refer to them in XHTML as follows:
>
>  <span class="checkbox" id="chbox1" x2:role="wairole:checkbox"  />
>
>Hope this is useful
>
>All the best
>
>Lisa Seeman
>UB Access
>
>Ben Adida wrote:
>
>>
>>Hi all,
>>
>>One of my tasks for this week was to figure out the details of the 
>>"Role Attribute" issue from the issues list:
>><http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues>http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues
>>
>>The entire discussion about this was logged during our August 2nd  telecon
>><http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Aug/0003>http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Aug/0003
>>(scroll to the near bottom, "RDF Role Attribute" just above the 
>>action items.)
>>
>>The main debate was whether the ROLE attribute would simply be 
>>syntax  for rdf:type, or whether xhtml2:role would be defined as an 
>>RDF  property that would be a subProperty of rdf:type. The problem 
>>with  the latter solution is something to do with OWL-DL 
>>compatibility.
>>
>>We should aim to resolve this issue fairly quickly: please prepare 
>>to  bring up issues and discussion points at our upcoming telecon 
>>on  Tuesday.
>>
>>-Ben

Received on Friday, 7 October 2005 21:01:32 UTC