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

[Tantek Ç elik]

On 8/11/05 7:10 AM, "Bud Gibson" <bud at thecommunityengine.com> wrote:

> Robert et al., count on me moving forward with experimental support
> for the interpretation of embedded hCard in xFolk (RC2).

Why?

There hasn't been research that shows the real world examples of folks
publishing distributed tagging along with their authorship *specific* to the
distributed tagging.

If there has, publish it on the wiki first, and then we can continue the
discussion.

I'd say some amount of real-world examples, including links to them on the
web (as you did with the original background research for xfolk) is
necessary requirement before making any addition.

Let me make this clear.

All of us should be resisting, fighting and saying *NO* by default to any
request to add a feature to any microformat.  That's the *only* way they
will stay micro.

Someone *asking* for a feature is insufficient.  We've covered this somewhat
already in the process document:

 http://microformats.org/wiki/process

On the other hand, if you want to work on open ended formats which accept
all feature requests are never "done", there are already other communities
"serving" those kinds of designs.


> The date  
> issue is still open per the conversation.  If the semantics of
> hReview work for you, it is still an option.

And to be clear, hReview documented numerous real world examples of reviews
on the web that themselves had both the author information (reviewer) and
the when it was reviewed (dtreviewed).  That's why those features are in
there.


> There are a couple of other experimental elements coming in RC2

BTW Bud,

If we do add more features to xfolk, this is a good reason why naming it RC1
was premature and simply bumping the lesser version number (e.g. v0.5) would
have been more appropriate.

If you want to use traditional software release versioning terminology like
"RC", then you should re-use the semantics of that terminology as well.
"RC" doesn't allow for any more new features.  It's a statement that the
features are done.  That the only changes coming will be *very* minor and
*only* in response to necessary bug fixes,  "blockers" as they say.

This is another reason to not add any features to xfolk 1.0.  By declaring
it RC, you declared it feature complete, and all features working as
expected.

Perhaps you should instead be gathering this as request for xfolk 1.1?


> that  
> have arisen as implementation issues, one for a person doing a
> massive scale site.

This should be documented first on an xfolk-issues page before proceeding
with any kind of proposed solution.

 http://microformats.org/wiki/xfolk-issues


> I respond below with details justifying my views on hCard.
> 
> On Aug 11, 2005, at 7:38, Tantek Çelik wrote:
> 
> 
>> 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.
>> 
> 
> If you say to people they can embed an hcard, that's not violating
> the modularity principle.  I would see this working the same way
> reltag works for tags in xFolk.  hReview uses hCard in a way that
> also seems modular.

Very good.  Yes, by reference is modular.


> Tantek, some of your inferences seem to rely on the notion that a
> page has one author.  That's just not always the case, at all.

It is the 80/20 case. That's what microformats are designed for.

We deliberately *accept* that there will be some folks out there for whom
the microformat won't suffice.  This is an *excellent* trade-off because it
avoids bloating the microformat, and thus making it more complex for
*everyone* just to benefit the few.

If you seek to solve the 100% case, you will end up with an overdesigned
format, not a microformat.


> By embedding the hCard, you make authorship of a particular snippet
> explicit.  There is nothing wrong with being explicit.

True, there is nothing wrong with being explicit.

HOWEVER

The key question is:

Are people already being explicit with authorship TODAY with the distributed
tagging that they publish?  (my assertion is no, they are not)

If they are being explicit with their distributed tagging, then great, let's
provide some microformat markup for them to insert into the data THEY ARE
ALREADY PUBLISHING.

If they're not, then you're asking publishers to change their behavior and
publish more information than they already are.  That's not a winning
proposition.


Now, in the first case, you may find examples of people being explicit
*today* about the "authorship" of their distributed tagging.

I would posit that those folks are being explicit about the authorship of
their *blog posts* (e.g. in group blogs) rather than specific to *just* the
distributed tagging that they do.

Thus a better solution to this would be to provide input to the
blog-post-format discussion, have that microformat solve the "authorship"
issue, and then simply embed xfolk in such microformatted blog posts.

This would be a better solution because it would reflect what people are
actually publishing, rather than trying to change the model of what people
publish.

This would also be better from a modularity perspective.

xfolk isn't the only microformat that you can imagine (and see examples of)
folks wanting to be explicit about the authorship.  Thus it makes sense to
put that in the container (as it were) rather than in every microformat.

Note that Atom 1.0 has such a notion of authorship in its individual feed
items as well as for a feed as a whole.  There are some established patterns
/ formats / schema to be re-used here.


> As for dates, Tantek, the question is whether you can nail this down
> sufficiently to provide a concrete implementation that responds to
> all the use cases.

Re: "all the use cases" -- see above about 80/20.

> My vote is that you can nail it down,

Based on what evidence?

> but you have a more encyclopaedic understanding.

No, I have a more socratic understanding.  I'm claiming we don't know enough
(e.g. have enough real world examples / needs) to justify an elemental
datetime microformat.

Thanks,

Tantek