[microformats-discuss] what gets pruned/closed, making existing web data useful

[Tantek Ç elik]

On 7/13/05 7:52 AM, "Danny Ayers" <danny.ayers at gmail.com> wrote:

> Hmm, I'm sorry about my irritable reaction,

No apology necessary Danny.  I know you want to make all this stuff work.


> but there's another factor
> in the cost/benefit equation, that of who bears the cost/gains the
> benefit.

That's a very reasonable question to bring up.

With microformats we are deliberately optimizing to minimize costs for the
most humans.

What does that mean?

That typically translates to:
 - easier to hand author (even if few bits end up hand authors, most *start*
that way, especially developers, they start that way).
 - easier to build into *current* pages
 - easier to build into *current* publishing systems

In my opinion the publishers are providing the most value here, so therefore
they should have to bear as little of the cost as possible.

On the other hand, the indexers/consumers/aggregators etc. will derive more
of the value, and therefore it is reasonable to ask them to bear a bit more
of the cost.

This is a bit of the opposite of "traditional" format efforts which are
typically more programmer focused (rather than publisher focused), and end
up being easier to code to consume, but harder, or more inconvenient to code
to produce.


> Using my own RDF/SPARQL play as an example, where there's mixing and
> interconnection of data from a variety of sources, for microformats to
> be a useful source of data term disambiguation is pretty vital.

Ok, I'll take your real-world example (I'm assuming by "play" you mean
something you built) as a given.


> So
> however chicken-little naming clashes might be, their occurrence could
> potentially be catastrophic.

I'm really not afraid of them because I think with judicious discussion and
design, we can actually proactively avoid 99% of the problems.

We do things like:

 1. pick unique root class names like vcard, vcalendar, hreview, xfolkentry,
and let contained class names be defined by context if necessary.

 2. for the same concept, we use the same name.  we use "description" in
hCalendar, and thus in hReview, and now in xFolks as well, rather than
"description", and then "review-text", and then "extended".

 3. for different concepts, use different names.

We keep the number of vocabulary terms used as minimal as possible, as
opposed to encouraging an explosion.  We re-use current terms whenever
possible rather than reinventing new terms.


> I really don't think they will an issue,

Agreed.


> having profile URI(s) easily available will push clashes way out into
> improbability-land.

Yes.  That plus healthy communication/discussion.  No silos.  No Chinese
Walls.


> But that does mean there's a far higher premium on
> those profile URIs

I don't understand what you mean by higher premium here.


> than there would be for say building a stylish
> microcontent viewer.

microcontent is meaningless if it's not built from one or more microformats.

This is why I prefer to focus the discussion on the microformats, rather
than bandying about what is little more than a buzzword "microcontent".

Thanks,

Tantek