[uf-discuss] Marking Up Personal Profiles

[Tantek Ç elik]

On 10/1/06 5:34 PM, "Lachlan Hunt" <lachlan.hunt at lachy.id.au> wrote:

> Tantek Çelik wrote:
>> The key distinction with microformats is to make sure that *all* your
>> example data is based on data actually found on the Web *with* specific URLs
>> to where the data can be retrieved and analyzed by anyone.
> 
> Most of the example fields I listed were based on those found primarily
> on LavaLife and RSVP profile pages.  Other similar sites include
> match.com and AdultMatchMaker  The actual personal data values I used,
> however, was just made up for privacy reasons.
> 
> http://lavalife.com.au/
> http://www.rsvp.com.au/
> http://match.com.au/
> http://adultmatchmaker.com.au/

It would be a good start to at least add those URLs as sources for profile
information to the profile-examples page.


> (Unfortunately, on some of those sites, you need to become a member
> before you can see any profiles.)

The more closed the system, the less the likelihood that they will bother to
adopt a microformat, thus the less useful such a system is as a "real world"
example to use for modeling.

I recommend finding some sites where you don't have to become a member
before seeing any profiles.


>> In addition, I do suggest more research.
>> 
>> E.g. you mentioned supposed rel-tag limitations, giving the example of
>> "brown":
>> 
>>> The recurring problem with the use of rel-tag in most of these is that
>>> we're trying to represent name:value pairs, whereas rel-tag only really
>>> represents the value.
>>> 
>>> e.g. <a href="/tags/blue" rel="tag">Brown</a>
>>> 
>>> That doesn't indicate whether it represents hair colour, eye colour,
>>> favourite colour or something else entirely.
>> 
>> The participants of at least one "social networking" site (consumating.com)
>> have already solved this problem, WITHOUT name/value pairs with tags like:
>> 
>> brown_hair
>> blue_eyes
> 
> I thought of that, but one of the problems is that some sites may tag
> them like that, others may use "brown_(Hair_Colour)", "Brunette",
> "cheveux bruns" (French for brown hair, according to babelfish) or some
> other variation.

You are talking theoretically "some sites *may* tag them like that..."

I am talking practically.

The tags I gave above are *actual* tags used by the community of
consumating.com - they were not decided by the "site" - they were adopted by
the community that inhabits that site.  Big difference.

It is irrelevant what some sites "may" do.  What is relevant is what sites
*actually* do.  Do you have any other examples?



> I guess that's an issue with tagging in general, where
> you get people coming up with dozens of different tags to represent
> exactly the same concept.

Actually it's not.  With folksonomies, it has been demonstrated over and
over again, that communities tend to converge on tags to mean things.  Sure
there are some redundancies but the community typically ends up organically
picking a winner and using it.  This has been seen on the centralized
communities of delcious, Flickr, and even with decentralized blog post tags
that Technorati indexes.


> There are advantages to that type of tagging in some cases.  But say,
> for example, you were using a personals search engine looking for
> brunettes, a search engine should theoretically list people that have
> used either of those tags.

Even before personals search engines, there were printed personals, and
"tagging" conventions evolved there for people to quickly/accurately
describe attributes and wants.  You don't need to presolve most of these
problems with a-priori taxonomies/ontologies - the authors of the data often
solve them themselves.


> Regarding the name:value pairs issue, there are lots of cases where it's
> useful to markup this kind of structure and HTML has several different
> structures available, including <table>, <dl>, or even <meta name=""
> content=""> (for hidden data). Maybe we need some kind of design
> patterns describing these and when to choose which method?

Generic name value pairs are best marked up with <dl>s.  See XOXO for lists
etc. in combination with name value pairs.

 http://microformats.org/wiki/xoxo

<meta name> is pretty much dead.

Thanks,

Tantek