Al Gilman wrote:
> *summary:
> 
> Use of @role is indicated when we can, in RDF, say pretty clearly
> what we want a processor to know about an element instance.  Because
> use of @class won't deliver a payload of connotations with anything
> like the same   
> reliability.
> 
> It is a second-generation, better-engineered venture into the same
> semantic space. Refining what is known about the current element
> instance. Not a fork into a new semantic space.  

<snip>

> The property "suitable for use in transmission through the postal
> services" is appropriate to add to an <address> element by using the
> @role attribute.  

Well, I'm glad I'm getting @role (I hope)

> 
> The real difference between @role and @class is not semantic: what it
> can mean; but computational: how you can computationally learn about
> what it means. @class gives you opaque tokens. There is no good
> Web-wide practice for associating such tokens with machinable, and
> clearly delimited, knowledge (roughly bundles of assertions). @role
> gives you something that can be expanded into a URI. RDF gives you a
> Web-standard way to associate assertions with this URI. So this is a
> chain of Web-standard "communicative gestures" that allow us to
> clearly import a known cluster of assertions to a current element
> instance.     

Except, after starting down this road, I stepped back a bit to
re-examine what I was thinking.  While @role is great because of it's
extensibility through RDF, was it not also originally envisioned as a
support to ACCESS, although it could be applied to any element?  My
original understanding was that it was identifying a conceptual block of
information, such as "banner" or "contentinfo", as much spatially as
conceptually, providing yet another method of traversing a document,
using semantic understanding.

But what I originally thought for ADDRESS is not so much block
information per se, but rather granular information within a block.
Perhaps it is more meta information than I originally surmised, so would
not the property attribute would be more appropriate?

Which makes more sense here:

	<address role="author">John Foliot</address>
	<address role="company">WATS.ca</address>
	<address role="city_state">Ottawa, ON</address>
	<address role="country">Canada</address>
	<address role="email">foliot@wats.ca</address>
	<address role="website">http://www.wats.ca</address >

or
	
	<address property="author">John Foliot</address>
	<address property="company">WATS.ca</address>
	<address property="city_state">Ottawa, ON</address>
	<address property="country">Canada</address>
	<address property="email">foliot@wats.ca</address>
	<address property="website">http://www.wats.ca</address >

(ref: http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#sec_23.3 .)

(Note, this discussion did start with the lament of needing <br /> or
<p> within the ADDRESS element for visual layout as much as anything
else)
    
> 
> See the discussions in the "RDF in HTML Task Force" list on
> "semantics of @role" for more on this. 
> 
>
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Oct/threa 
d.html#0
> 

Al, in your response on this thread you stated:

> 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.

Exactly! Do we really need this much for something as innocuous as
ADDRESS?  I believe that a controlled vocabulary should be created to
use with ADDRESS, but could it not (should it not) be a Meta Type
Vocabulary instead?

(Asking the question, don't know the answer...)

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca    
Phone: 1-613-482-7053