[uf-discuss] hAtom draft - class="title"

[Benjamin Carlyle]

Kevin,

On Sat, 2005-12-31 at 15:48 -0800, Kevin Marks wrote:
> On Dec 27, 2005, at 3:43 PM, Tantek Çelik wrote:
> > This means working deliberately to avoid the two cardinal sins that
> > namespaces typical both enable and encourage:
> > 1. The same term is used to mean two different things
> > 2. Two terms are used to mean the same things
> Indeed. In fact this is one of the advantages of Atom over RSS - 
> resolving ambiguous usage.
> In RSS 'description' is used for both summary and full-content feeds.
> Atom defines distinct 'summary' and 'content' elements for this

I have suggested a possible naming on the hAtom-issues page that I would
like to see debated with a view to replacement or acceptance. I think
this fits in reasonably well with early uses of the terms involved, and
the equivalence is as follows:

atom:title = hAtom summary
atom:summary = hAtom description
atom:content = hAtom content

The disabmiguation between atom:summary and atom:content is still
afforded because there is a clear 1:1 relationship to atom's
terminology. Summary is already used by iCalendar-derived specifications
such as hCalendar and hReview to mean what I believe atom:title means.
Description can trace its roots both VJOURNAL and RSS, where I think
they were originally intended to mean a short description of content
somewhere else or of an event that has occured. I think it was overrun
by the popularity of full-text syndication which created the ambiguous
meaning we know today from rss. I think that content is still a valid
and appropriate new term introduced by atom which could be used in
similar ways by future microformats.

My association with the histories of syndication formats is not close
enough for me to really see whether this proposal is a good one or not.
I think it meets the basic technical merits, but I would like to get
some gut reactions from those with more experience in the subject
domain.

> In RSS 'link' is used for both 'entry permalink' and 'external linked 
> element from a brief entry'.

I believe this is a resolved issue in hAtom. See
<http://microformats.org/wiki/hatom-issues#Why_rel.3D.22link.22_.3F>. Do
you feel this requires further resolution?

Tantek has pointed out that choosing names for hAtom elements that
differ from those of corresponding atom elements is not necessarily a
bad thing. The technological imperative is to ensure there is a
correspondance between hAtom and atom elements. Perhaps it is indicative
of his exitement about hAtom that he made the following comments in irc
the other night[1]:

[19:24:25] <Tantek> one thing to keep in mind re: atom vs. hAtom
authors, once we have solidified hAtom, it is quite likely that hAtom
may become the largest source of Atom on the web
  * [19:24:55] <Tantek> for the same reasons that hCard is becoming the
    largest source of vCards on the web
  * [19:25:00] <Tantek> and so forth
  * [19:25:15] <Tantek> it's easier to author/publish than a separate
    file with a separate mime-type etc.
  * [19:25:41] <Tantek> thus it is more important for microformats to
    get things right, than it was for various independent/individual XML
    formats
...
  * [19:32:51] <Tantek> naming things is one of the hardest things to do
    well, especially in the context of existing work
  * [19:33:10] <Tantek> and even then, especially in the context of
    several existing works
  * [19:34:05] <Tantek> BTW, my understanding of the Atom process for
    naming was to pick the names that made the most sense on their own
    in Atom. There was no attempt (AFAIK) to reuse names of elements or
    properties from existing standards.
  * [19:35:02] <Tantek> Thus it should not surprise us that hAtom will
    likely have different names than Atom, since hAtom, as a
    microformat, is focussed on reusing pre-existing names, whereas Atom
    did not.

Noone is dissing the hAtom standard. It was developed by smart people
who knew what had to be done to fix the semantics of syndication on the
Internet. The suggestion here is that syntax, naming and a few other
issues may need to be tweaked in order to apply atom to the microformat
world. Atom's semantics and scope should still be the grounding for any
microformat syndication model. At the present this is a question about
names, not meanings. Noone wants to re-do the work of atom
standardisation.

> That said, 'title' is context-defined in Atom - it can mean 'feed 
> title' or 'entry title'.

I have raised the issue of whether the completion of hAtom depends on
the completion of mfo or not[2], but at this stage I think the answer is
"no". hAtom parsers and publishers should take heed of it if mfo reaches
maturity, but hAtom currently defines its own opacity behaviour. I have
raised another issue[3] that might still influence this question,
though.

If the possibility of overlapping definitions for terms can be excluded
from the scope of mfo then its sole responsiblity becomes completing the
triple. You have a predicate in the form of a html class. You have your
object as the content of the classified node. The question is, "what
subject does this assertion apply to?"

> So I would suggest 'entry-title'.

I (and I presume others) would welcome specific suggestions being added
to the hAtom issues page.

-- 
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>
[1] http://rbach.priv.at/Microformats-IRC/2005-12-31
[2] http://microformats.org/wiki/hatom-issues#mfo
[3]
http://microformats.org/wiki/hatom-issues#Opaqueness_of_summary_and_content