Misc (was: [uf-discuss] Disambiguation Conventions? (was CommentsfromIBM/Lotus rep about Microformats))

Ryan King ryan at technorati.com
Mon Dec 18 11:48:20 PST 2006

On Dec 14, 2006, at 2:45 AM, Joe Andrieu wrote:
> The unique fact is that microformats is the only entity in
> the entire chain of authorship, from CCIT to Versit to IETF to change
> the spec from being about people to being about /more/ than people.
> Other changes were about adding features to extend what you could say
> about people.  We just up and redefined the core semantic.

Certainly the microformats community are the first standards  
organization to state that this vocabulary applies to more than  
people. However, this is based on actual usage of vCard. Many  
applications that produce vCards do so for organizations in addition  
to individuals [1].

The way to determine that an hCard is for an organization and not an  
individual is that the FN is the same as the ORG [2]. In practice,  
this is usually done by using the 'fn' and 'org' class name on the  
same element [3].

As far as hcards-for-places goes, that's still an open issue that we  
need to work out. If you have any suggestion on how to specify that  
an hcard is for a place and not a person or organization, it'd be  
great to hear them.

> First, we included companies and organizations in the very beginning.
> Then, a year later, we added places.  And yet, our own documentation
> contradicts itself: the profile specifies hcards for PEOPLE only, via
> RFC 2426, but the description of hCard on the wiki now extends that to
> companies, organizations, and even locations.

Well, first of all, the profile is not normative, the specification is.

Secondly, hCard uses the semantics of vCard's properties, not every  
bit of vCard. That's an important distinction in this case, that may  
not be well explained on the wiki.

> This is a pretty significant loss of semantic specificity. While a  
> human
> can disambiguate between hCards for places and hCards for people, a
> /machine/ would have a very hard time of it. The entire point of the
> semantic web is to make it easy^H^H^H^H /possible/ for machines to  
> make
> sense of the information that's out there.  Now, when a spider  
> finds an
> hCard, it can't tell if it is a person, company, organization, or  
> place.
> That sucks.  It would be much more useful if hCards could actually be
> expected to be people!  Imagine that. Then machines might be able  
> to do
> something useful with this class of entities it discovered while
> cruising around.  But that route is lost to us.

As previously stated, we already have a mechanism in hCard for  
distinguishing between people and organizations [4].

> Standards aren't meant to "evolve".  The are revised. Updated.  
> Changed.
> Explicitly. Intentionally. And with clear versioning. The nature of a
> standard is to be /standard/ across contexts, especially time.

Perhaps standards aren't meant to evolve, but in practice they do.  
After a standard is published, the usage and interpretation of that  
standard change as the use cases, environment and tools surrounding  
it change.

> With the current ad-hoc approval and revision process, I have serious
> concerns about whether or not we are capable of maintaining the  
> kind of
> rigor that would protect semantic meaning over time and in fact  
> allow a
> real standard to exist in any meaningful way.  Especially as our
> virtually non-existent versioning precludes the ability for anyone to
> meaningfully track such significant changes as the addition of  
> "places"
> in the semantics of hCard.  It's frustrating.
> I don't intend this email as an attack on anyone. I do mean it as a  
> flag
> for problems that many in the community have dismissed as unimportant.

I don't think it is an attack. At least, I don't take offense at it.  
I think you've raised some valid issues (namely, hcards for places is  
underspecified), but I also think you have some misunderstandings  
about how and why things work around here.

The reason things are loose and fluid is that it's better to have a  
specification that is in touch with reality than one set in stone.  
Sure, if you set a standard in stone and never change it, except by  
writing a new document that obsoletes all or part of the previous  
one, you can write an application that perfectly implements that  
specification. However, that says nothing about how useful that  
application would be. If popular usage of the format or technology  
changes, your application will have to change. In this case, the  
specification should continue to help with producing interoperable  
implementations. Change happens, and it's better to deal with it  
together than separately.


1. http://microformats.org/wiki/vcard- 
2. Well, really, organization-name, but we need to get that resolved  
3. Like: <span class="fn org">Technorati</a>
4. http://microformats.org/wiki/hcard#Organization_Contact_Info

Ryan King
ryan at technorati.com

More information about the microformats-discuss mailing list