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

[Tantek Ç elik]

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

>> 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.
> 
> Interesting, that's quite algorithmic. Getting the microformat
> designers and the parser-generators reading from the same script would
> be nice ;-)

Indeed.  These algorithms/principles are not obvious at all (IMHO). It's
taken years of mistakes to come up with them. :)


>>> 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.
> 
> The cost/benefit is levered, so from this point of view, (slightly
> exagerrated), *with* profile URIs, the microformats represent valuable
> data, *without* they're just noise.

I understand the exaggeration to make the point.

The reason for (1) above (relatively unique root class names) is give us an
"out" for things to be able to work potentially even without the explicit
profile declaration, should it be necessary.

It is very doubtful any designer etc. will use a class name like vcard,
vcalendar, therefore, when you see such names, it is a good bet that they
unique relate to a specific profile.  That's by no means 100% precise, nor
ideal, but it provides a fallback.


>>> 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".
> 
> Oops, sorry, that was a slip of the keys (que faux pas!!). What I was
> trying to describe was something that just gave an immediate
> representation of microformat data,

I think we'll see a lot of that at first.

> rather than having mixed the data
> with other material and made inferences based on the combination.

Those applications will come later I think.

> Errors in the former would generally be proportional from input to
> output, in the latter...watch that sky!

Indeed.  Combinations can introduce interesting levels of complexity.  So
let's try to keep the building blocks simple. ;)

Thanks,

Tantek