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

[Martin McEvoy]

On Fri, 2007-06-08 at 23:09 -0700, Joe Andrieu wrote:

> So, if hAtom uses "entry-title", why is "audio-title" bad?

and 

On Sat, 2007-06-09 at 15:26 -0400, Manu Sporny wrote:
> What are the arguments against 'audio-title', again? We have
> 'entry-title', why can't we have an 'audio-title'? 

I think I need to give you and everyone an insight into my logic and
explain a little why I proposed "summary" instead of FN I cannot vouch
for my accuracy in the following statements It is just how *I* see our
problem.

Why do I think audio-title is bad? because hAudio is not really based on
any standard audio-title would reflect the meaning of entry-title in
hAtom yes?

The hAtom entry-title matches the atom value of atom:title a property
that can only be used once within an atom:entry (hentry) and built upon
the RFC 4287 standard

*snip
The "atom:title" element is a Text construct that conveys a
human-readable title for an entry or feed

Although I was tempted to suggest we try entry-title this still doesn't
mean what we want our haudio title to mean

imagine...

haudio
  entry-title vcard fn [main title]
haudio
     entry-title download [track title] 
haudio
     entry-title download [track title]

Can you see the scenario hAudio has the need to define TWO different
titles depending on in which context it is used, song titles which are
used to describe a single track, and a title to describe an album or
collection which is a number of tracks. Atom does not yet have the
ability to do this.

Your audio-title would then have the same issues as work-title,
work-title for me worked, but threw up the issues of creating another
definition of title in vcard which is not really possible. This is only
because hAudio is not based on any standard and as such has to share its
meanings with other established microformats. We cant just pick names
out of the air and say this is what we will use they have to be based on
some kind of logic or established practices.

So the decision ended at FN as it closley mached our definition of
work-title

*snip
To specify the formatted text corresponding to the name of the object

great yes? it says what we mean, accept when you do this...

haudio
  vcard fn fn [Main title]
haudio
  fn download [track title] 
haudio
  fn download [track title]

confusing isn't it? because vCard in the same way as Atom does not yet
have the ability to convey FN as two different meanings or three in this
case.

hAudio is not designed or based upon any standard but it does use
standards compliant terms, its sole intention was to reuse existing
microformats, because it makes it easy to use, quicker to uptake, and
has a low cognitive load, and many other microformats that don't use any
particular standard are made in this way.

"summary" to me is what what we are left with:

hResume
summary[re-used from iCal rfc 2445]:: The class name summary is used to
mark up an overview of qualifications and objectives.
http://microformats.org/wiki/hresume#Field_details

a bit vague but over overview of a song or album is roughly how you
would describe a hAudio title...

hReview
summary[re-used from iCal rfc 2445]:: This optional field serves as a
title for the review itself.
http://microformats.org/wiki/hreview#Field_details

now this is better not exactly a review but it is a title...

hCalendar [Is based on iCal rfc 2445]
summary:: Short synopsis, title, or  name of the event. 
http://www.ietf.org/rfc/rfc2445.txt section 4.8.1.12.

...this gets even better uses the word title to mean title and it is
based on a standard.

The problem I am gathering is that "summary" is still a bit vague and
people would still like us to use title, am I correct? 

we have already established that we cant pick names out of thin air.

To do this sensibly is to base our proposal on a widely used
specification. *This is how Microformats scale*.

Our choices may be SMIL or ASX but we can't as all these formats are not
based upon open standards [patent issues]. 

RSS from what I can gather was owned by Netscape then Userland and was
later donated to a not-for-profit organization Harvard Law school.
RSS is still not an open standard and may be inadequate for our needs
[patent issues].

Atom was created in response to this [an open format].
http://en.wikipedia.org/wiki/ATOM#Development_History
 
So back to hAtom again, Although hAudio does have atomic properties Atom
does have a strict rule-set, things you are allowed to do and not
allowed to do. hAudio would have to adhere to the same principles. like
having two atom:title's within one atom:entry is a no no and have a
minimum required markup atom:title and atom:updated not too bad you
would say but how many examples can you find that have a date along side
the track title? relevant for a podcast I would say, but not enough
scope for hAudio.

So I would like to suggest that If we do want to base our proposal on a
standard then I would recommend using XSPF.
http://www.xspf.org/xspf-v1.html 

The reasons are, It is very similar to Atom, It uses XML (Great for
transformational uses, xslt), and it is an open format. 

I suggested It to Manu some time ago but he had the thought that it may
not be accepted and deemed pointless because we have hAtom at the time I
agreed with his point and put the idea to the back of my mind, 
At the time I had spent some time maping hAudio properties to XSPF. 
I am not saying this is in any way relevant just something to illustrate
my thought, I put all my findings in my user talk page on the wiki, The
work is not there now but you can see a diff here
http://microformats.org/wiki?title=User_talk:WebOrganics&diff=16847&oldid=16846#hSpiff_0.0.2

Im not too sure that we shouldn't use something like this now judging by
the current discussion...

Knowingly or not hAudio does share its naming structure with XSPF. All
the properties hAudio has and needs are available in XSPF, we could use
title in two different contexts and still have meaning.
 We would not have to create an new meaning for our hAudio title because
our proposal would be based on a standard. We can use x-title or
something similar. We can re-use all XSPF elements in hAudio hVideo
hImage, and as far as I know microformateer Kevin Marks may be able to
direct us further on this as I believe he Is/was one of the contributors
of XSPF and had strong influence on its architecture.

*Thought*

Podcasting has been around for a long time but imagine the scope that
xCast [or whatever name we would choose] could present to the podcasting
community and applications like SongBird. I could imagine that xCast
would be as popular in the podcasting community as hAtom is in Blogging.

[Sorry @Scott for thinking too far ahead I have to sometimes]

So there you go as simple as I can, If we cant use summary-track/song
and dfn-Album/collection then I recommend that we base our proposal on a
widely recognized format XSPF or something similar.

-Martin-  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070609/025430f9/smime-0001.bin