[uf-new] title vs. summary (was: Third attempt at hAudio)
scott at makedatamakesense.com
Fri Jun 8 17:39:21 PDT 2007
On Jun 8, 2007, at 4:26 PM, Joe Andrieu wrote:
> Actually, this is a perfect example why hidden data is problematic.
> I actually think the outright prohibition on it is too strict,
> but as a general rule, it tends to cause problems.
There's not really an outright prohibition on the title attribute.
We use it in the abbr design pattern, for example:
But there is a knee-jerk reaction against it because we want to
maximize the visibility of content, because that's where microformats
are really unique, in using already human-visible content as machine
data. The more we make it invisible, the more we might as well be
using RDF, which is not to say that RDF is always bad, just that a
diversity of options is good, so we should emphasize what makes
microformats unique, e.g. visible data.
> I've always been puzzled by the anti-namespace and non-scoping
For me, they boil down to what I said above: emphasize what makes
microformats different (e.g. lack of namespaces) from other formats
to give publishers the most alternatives.
> The world is probably too rich to suitably represent good
> names without one or the other approach. If "audio-title" or
> "audiotitle" violates namespace principles here, then I think we are
> seriously hitting one of the scaling problems of uF.
In many ways, we are, and that's okay (in my view, of course --
others certainly disagree). RDF can scale while microformats ease
the learning curve to a more data-rich web. But we also have profile
URIs available to accomplish much of what namespaces accomplish, and
we're not really taking advantage of those now:
I doubt we'll ever focus heavily on profile URIs until someone else
develops a popular alternative use of class names that conflicts with
microformats, just because this is a community founded around solving
the most obvious problems first, and that's what it will take to make
disambiguation an obvious problem.
> Of course, it has been argued that uF isn't supposed to scale and
> perhaps this is one of those areas where the namespace and scoping
> principles induce a boundary on scale. If that's really the point
> we are at, can someone explain why this is a good thing again?
In some ways scalability and ease-of-use are mutually exclusive, and
microformats are in the ease-of-use camp. In this case, it's easier
to assume a given class name always means the same thing, so that's
what microformats let publishers do. When publishers run into a
situation where they absolutely need namespaces, then they can always
move to RDF. But if microformats were to become more like RDF, then
understanding namespaces would become a prerequisite to publishing
machine-readable data on the web, which would result in fewer
publishers doing so. I would use a metaphor of microformats as
training wheels for web-based data publishing. When publishers start
to get tired of the training wheels, they can take them off their own
bike and start using RDF. But banishing training wheels in general
is not helpful to other beginners. And right now the web is full of
> Because, it is clear to me that "title" is just the tip of the
> iceburg on this problem, and in fact "audio-title" is really just the
> hint of something in the water. Virtually all media have titles. In
> fact, the working schema for hCitation also has this problem.
>  http://microformats.org/wiki/citation-brainstorming
Right, so ideally we would choose a term specific enough to have a
clear meaning in the context of hAudio, but general enough to also be
usable in future microformats. And looking to previous microformats
is a good way to find such a term, because if it works in both
another microformat and hAudio, it probably has a good balance of
specificity and re-usability.
> So, to clarify how we got to this point, why can't "title" be bound
> to the semantics of the first parent container to have a rule
> for it?
Joe already seems to know the answer to this question, but for those
new to this issue, consider this:
<span class="title">Purple Haze</span> by
<span class="fn">Jimi Hendrix</span>, <span class="title">musical
The problem comes when trying to determine the title of this hAudio.
How do we know if it's "Purple Haze" or "musical legend"? We could
tell parsers to ignore hCards, but that requires parsers to be aware
of not only the microformat they're parsing, but also any other
microformat that might include the same property names, some of which
may not exist until after the parser is written. I don't believe
this is an impossible problem to solve, but as Brian said, it is a
difficult problem. When faced with the option of solving this
difficult problem or choosing a different name and moving on, I
expect most people interested in hAudio will opt to just choose a
different name. Repeat that over every microformat, and you get
where we are now.
> I believe the answer is that because existing parsers would have to
> be constantly updated to handle new uFs contained therein. In
> other words, hCard parsers would have to be re-written to handle
> contained hAudios. Am I following that argument correctly?
Pretty much. With "title," there's also an argument that we should
neither use the same term to mean different things nor change the
meaning of terms in already-published microformats. I expect even
slightly expanding the meaning of a term in a microformat published
as widely as hCard would be an uphill battle.
> If so, I don't quite understand the problem because hCard's don't
> contain hAudio. Or can they?
They could. My hCard is here:
If you look at the source of that page, you'll see the hCard covers
almost the entire page, because my name is at the top and my birthday
is at the bottom. If I wanted to list my favorite song on that page,
as I've previously done, I couldn't do it in hAudio without risking
the song title would become my job title, as long as there are no
rules to prevent that. This is still an edge case, but it's an edge
case that grows exponentially every time we re-use an existing class
name in a new microformat.
> Is there some way to embed arbitrary content into an hCard and have
> it actually be logically or semantically /embedded/ in the
> hCard? I know you can do it presentationally so it displays the
> data. But does the hCard data model have a place for arbitrary
> embedded content? If so, couldn't the parser simply ignore the
> children of that field when parsing for "title"?
Notes, maybe. Ideally someone would be able to include an hAudio
inside the node of an hCard without influencing the hCard at all.
Also, it would be nice if there were a general solution that worked
on any microformat embedded in any other. That's generally where
this seems to be headed:
The idea there seems to be that the included hAudio could have the
"mfo" class added, e.g. class="haudio mfo" and that would indicate to
any hCard parsers that they should ignore that section the
surrounding hCard. The same would work for embedding hAudio in
hReview if we decided to re-use summary, or with embedding hAudio in
hAtom if we re-used entry-title. But there are several issues with
that idea, and I haven't seen much interest in discussing it further.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the microformats-new