Misc (was: [uf-discuss] Disambiguation Conventions? (was
CommentsfromIBM/Lotus rep about Microformats))
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 .
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 . In practice,
this is usually done by using the 'fn' and 'org' class name on the
same element .
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
> 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
> 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
> 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 .
> Standards aren't meant to "evolve". The are revised. Updated.
> 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
> 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
> 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
> 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.
2. Well, really, organization-name, but we need to get that resolved
3. Like: <span class="fn org">Technorati</a>
ryan at technorati.com
More information about the microformats-discuss