[microformats-discuss] xFolk (RC1) and Topic Maps

[Tantek Ç elik]

On 8/10/05 3:26 PM, "Ryan King" <ryan at technorati.com> wrote:

> On Aug 10, 2005, at 1:56 PM, Bud Gibson wrote:
>> On Aug 10, 2005, at 13:51, Tantek Çelik wrote:
>>> My advice is to first try to use xFolk.  If you find you *need*
>>> extra bits
>>> of information "about" the item, you'll likely find them in
>>> hReview.  If you
>>> don't, please point to the actual use cases and examples in the
>>> wild which
>>> are driving the need and we can all take a look.
>> 
>> I think this analysis makes sense for the time being.
>> 
>> That said, I'm thinking very strongly that the next iteration of
>> xFolk will allow  an embedded hcard.
> 
> Of course, an embedded hcard is already *allowed.* <address
> class="vcard">..</address> already captures these semantics without
> any definition in xFolk.

For the most part, yes.


>> As pages start to be constructed with content from many sources,
>> you want to know who did what.  If all Rob is really looking for is
>> some way to attribute the source of a tagged link, then it seems
>> xFolk should be able to accomodate that.  I have other use cases in
>> mind that I am working on right now where this makes a lot of sense.
> 
> Certainly, identification of the tagger is important in folksonomy.
> As Thomas Vanderwal put it, folksonomy requires a unique person,
> object and tag (think that's the 3 things- I heard him say it last
> night at BayCHI). So, its obvious that xFolk is lacking in the
> 'person' area.

It's actually not lacking there, though it's not obvious.

Similar to XFN, which uses the context of the page to understand the "from"
of the relationship, xFolk, also uses the context of the blog to understand
the "person" who is doing the tagging.

Thus since this information is already available in current usage, it is
actually *undesirable* to grow xfolk to represent person as well.  In fact,
that violates the modularity principle.


>> As for the date idea, I don't want to go reinventing the wheel and
>> look to the community to generate a date microformat with semantics.
> 
> This is a great idea. Awhile back, I started http://microformats.org/
> wiki/datetime-design-pattern to try and document the date pattern
> we've been using in several microformats. The question of whether
> this can stand on its own as an elemental microformat (or
> nanoformat :)) is still open.

Yes, and will stay open until someone can demonstrate significant use cases
for a stand-alone datetime elemental microformat.  So far, all use cases
have been as *a part of* something else.  Hence it's a design pattern rather
than a full fledged microformat.  We should only create new microformats
when we can demonstrate that there is a clear need.  Formats for formats
sake are outside the scope of microformats.

Thanks,

Tantek