[uf-discuss] Live Writer and microformats

Fri Oct 6 11:21:11 PDT 2006

Just to build on what Ryan said about optimization for publishers:

Yes, microformats can be hard to parse.  However, it is significantly
easier than attempting to parse this information in the absence of
microformats (just plain text, or plain old html [POH, anyone?]).

Ben

On 10/6/06, Ryan King <ryan at technorati.com> wrote:
> On Oct 6, 2006, at 1:19 AM, Joe Andrieu wrote:
> > Because of the current structure of microformats, as a way of
> > thinking and as a process, I believe it is inherently incapable of
> > handling a rapidly growing list of microformats.
> >
> > Someone once said to a proposal of mine that a large number of
> > microformats was in fact an "anti-goal".  The way the system is set
> > up, neither the supporting technologies nor the uF community is
> > capable of handling a rapidly growing set of uF.
> >
> > We have a very slow, painstaking process,
>
> Have you tried any other standards processes?
>
> According to a talk [1] given by Tim Bray (see notes [2]), the atom
> syndication format took over 17,000 email messages to work out.
>
> And you know what? It's not done, its still in draft (or maybe
> proposed). They have at least one more round before finishing.
>
> On the other hand, I see 6,277 total messages in the history of this
> mailing list. In that time we've done hAtom, hResume, adr, geo, rel-
> directory, hListing and talked about a number of other examples.
>
> It may not seem it, but this is the fast way to do data format
> standards.
>
> Consensus takes time. Community takes time.
>
> > Second, because there is no mechanism for discovery of
> > microformats, every
> > tool has to be hand-carved to handle each microformat it wants to
> > support.
> > In contrast, if we required profiles, and if profiles provided a
> > machine
> > readable schema of the microformat, tools could at least present
> > users with
> > structured data that at least retains its typed values.  Of course,
> > the
> > /semantic/ value of that auto-discovered microformat is more
> > challenging; we
> > don't have a good way to define arbitrary semantics.  But at least
> > the data
> > can be extracted and managed in a lossless fashion. Plus, if the
> > format
> > contains well-understood components such as hCard or hEvent, at
> > least the
> > application could provide reasonable interfaces and functionality
> > for those.
>
> The idea of auto-magically making microformats work is a dream. I'll
> believe it when I see it. For a hint at some of the challenges, read
> http://microformats.org/wiki/hcard-parsing .
>
> Parsing, extracting or using microformats is not intended to be easy
> for consumers. Remember, we're optimizing for publishers, which means
> that we'll often create situations that put a burden on consumers.
> However, there's more producers than consumers, so the economics here
> are good.
>
> Also, we could try to require profiles, but I don't think it'd make
> any difference. The reality is that a lot of content on the web is
> published with systems that don't allow authors to edit the <head />
> of the document.
>
> If we were to require them, I could see two outcomes:
>
> 1. Only a minority of people use them. Consumers will have to deal
> with it the same we deal with it today.
>
> 2. The publishing tools start putting all of the profile URIs in the
> head at profile, just in case their users publish microformatted content
> through their CMS.
>
> I don't see either of those scenarios being helpful for us.
>
> > So, I think it is important to realize that the fundamental
> > structure of uF
> > as a process, organization, and way of thinking, inherently
> > restricts the
> > pace of growth.  uF is set up to slowly forge several dozens of uF,
> > crafting
> > socially accepted, shared semantics and encoding standards for use in
> > semantic XHTML.  Good stuff. And far more accessible and useful
> > than most of
> > the other semantic web technologies out there.
>
> The structure of the process and community is built to produce good
> results. Good results take time and work. Still, as I mentioned
> above, I think we're able to produce good results in less time with
> less work.
>
> > With all that said, maybe I'm looking at things upside down.  I
> > asked Tantek
> > early on how microformats scaled.  His reply was that could be better
> > answered over a beer.  Unfortunately, I haven't made it to any of
> > the social
> > functions to chat over that beer, so maybe I could get some
> > clarification
> > here.
> >
> > I'm I missing something?  Or is the scaling of uF, in terms of the
> > # of uF,
> > constrained as I've outlined here?
>
> The growth is constrained to the formats we can successfully create.
> Quality is better than speed.
>
> > At the same time, organizational development is a wicked hard
> > problem and
> > one we should be very delicate in approaching, if approaching it at
> > all.
>
> Perhaps even harder than writing software or developing data format
> standards. :D
>
> -ryan
>
> 1. http://www.tbray.org/talks/etech2006
> 2. http://www.windley.com/archives/2006/03/tim_bray_on_ato.shtml
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>