[uf-discuss] hCard to represent simple entities
andy at pigsonthewing.org.uk
Sat Jan 5 08:07:18 PST 2008
In message <00CE0169-EC88-4BE3-8E6C-4B8E07CE45C8 at eatyourgreens.org.uk>,
Jim O'Donnell <jim at eatyourgreens.org.uk> writes
>On 4 Jan 2008, at 18:29, Andy Mabbett wrote:
>>>the exact microformat I'd
>>> use depends on what I want to do with the names in the end, more
>> But that's dependent on what *you"* want to do. If you use more
>>consistent mark-up, then your users, and parsers, can deal with them
>>as they see fit.
>Sorry, I should have been clearer. What I want to do, in terms of
>marking up content, is determined by how people are going to use the
Yes, but you don't know how people are going to use it.
>If people want more intelligent searches - 'show me manuscripts
>written by Captain Cook' - then rel-tag seems like the natural tool
>for marking up names.
Suppose I want to know what Captain Cook drank; and that your manuscript
includes a letter from Cook to a friend back home, saying "I don't miss
much of home, but I could murder a pint of Mrs Hecklethump's famous
I need to tell a search engine to find all references to "Captain Cook"
But I also need to be able to specify that I don't want to know about
the vast majority of returns for that search, which are about pubs
called "Captain Cook", or the products of the Captain Cook Brewery (yes,
ether is one!).
So I need to be able to specify that I only want pages which refer to a
person called "Captain Cook" - in other words, who has an hCard whose
"honorary-prefix" is "Captain" and whose "given-name" is "Cook". [One
day, I might also be able to search for "hBeverage" or some such
(perhaps a subset of "hRecipe") instead of "beer", too.]
That's how using hCard adds re-usable semantics to a person's name, even
if that's the only "vcard" data you publish about them.
[Aside: If I worked at Google, my 20% would be spent on developing a
search engine capable of performing searches, based on microformats,
whose "advanced search" allowed the user to search by individual
attributes, including those which are implied. Or maybe that would be a
good student project. Please don't forget this message, if it leads to
you becoming the next Larry Page or Sergey Brin!]
>I don't see a use case for getting the contact details of Captain
>hCard does a specific job very, very well - it enhances social
>networking. I'm struggling to see, though, how it generalises to
>marking up the names of all people, living and dead.
As explained previously, hCard is not /just/ for contact details; it's
"for representing people, companies, organizations, and places". That's
quoted directly from its spec. And that's how it's already being used,
"in the wild".
If you want a robot to collect hCard contact details from one or more
sites, and add them to your address book; and are concerned that other,
hCards exist, with no contact details; then all you need to do is tell
it to discard hCards where none of the relevant fields are present.
>> For instance, adding a tag doesn't tell a future search engine that
>>your text is about a person.
>I think the answer to this is the rel-tag microformat coupled with
>sensible URLs to give much more intelligent tags. Imagine if the
>Maritime Museum archives used tags like:
><a rel="tag" href="/search/person/Emma_Hamilton">William Hamilton's
><a rel="tag" href="/search/vessel/HMS_Victory">the Victory</a>
><a rel="tag" href="/search/person/Captain_James_Cook">Captain Cook</a>
>There's enough info in the HTML there to allow for some quite
Only if you can get everyone to use the same URL structure, and to make
all the subjects in their content into links.
>Classes distinguishing between the different types of tag could be
>added to the links too.
Indeed - and the appropriate class, in the latter case, would be
"vcard", with "fn, "honorary-prefix" and "given name" around the content
as per the hCard spec. Why would you want to invent a new set of
More information about the microformats-discuss