[uf-new] title vs. summary (was: Third attempt at hAudio)

[Scott Reynen]

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:

http://microformats.org/wiki/abbr-design-pattern

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  
> arguments.

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:

http://microformats.org/wiki/profile-uris

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  
data-publishing beginners.

> 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[1].
>
> [1] 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:

<div class="haudio">
	<span class="title">Purple Haze</span> by
	<span class="hcard">
		<span class="fn">Jimi Hendrix</span>, <span class="title">musical  
legend</span>
	</span>
</div>

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:

http://typewriting.org/about/scott/

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:

http://microformats.org/wiki/mfo

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.

--
Scott Reynen
MakeDataMakeSense.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070608/5a676b67/attachment-0001.html