back to <address> [was: RE: domain distinction between @role and @class...]

At 12:22 PM -0500 11/10/05, John Foliot - WATS.ca wrote:
>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...)

I agree that for addresses, to be useful for machine processing, you
want to identify the sub-fields, not just the entirety.

Yes, in principle the answer is a world-wide agreed scheme of
metadata for postal addresses.

The problem is that the postal services themselves have not yet
settled their differences on a schema for postal addresses.

http://www.itu.int/osg/spu/newslog/default,date,2005-05-16.aspx

So one is left with a Tower-of-Babel world where Palm and Outlook
and .vcf and X.500 etc. all have their semi-ok and semi-interoperable
ways of expressing address information.

One internet-friendly way to deal with this is to go through the
LDAP view of X.500 and use that schema for addressing properties
of a person.

As for 'author' I would opt for dc:creator so you are making it
clear what the author is the author of.  The author-person is
an abstraction; what is in the address record is a collection
of properties, some of them structured themselves (like street
address, or City/State/Zip) of that abstract entity.

Or use .vcf terms.  But tell us what standard you are following.

In practice:

Use the terms that are used in the 'contacts' tool you use,
or the preponderance of your contacts for this communication use.

If you can find one, get a metadata professional to compare/contrast
these terms with available standards and offer amendments
to your pattern of practice.

Write up what you decided on the Web and we can work in a post-pass
how to turn that discussion into a literate-programming version of a
binding specification from schema terms to format and layout.

The more work we put into describing the microformat you are using
for addresses, the less you will have to mark in each address instance.

I am not up on the work on microformats, but 'address' sounds like
a posterKid for this approach.

Al

>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

Received on Thursday, 10 November 2005 18:14:54 UTC