[uf-new] Re: hAudio 1.0 Draft Release

[Martin McEvoy]

Martin McEvoy wrote:

Hello

This email is to announce the hAudio[1] 1.0 Final Draft proposed Schema


The Reviewed Proposed Schema is as follows

Properties that are 70% or over of discovered elements

haudio (required)
fn (required)
contributor
album
enclosure + type
published
duration
position
photo
Item

Item has been included because of the push back from the community as a 
whole for re-inclusion.


Definition is as follows

#  The element is identified by the class name item.
#  hAudio MAY have one or more items.
#  The contents of the element MUST contain at a minimum fn
#  The contents of the element MAY be marked up using properties in hAudio.

All references to opaqueness have been removed to bring item in line 
with how Item is currently used in other Microformats.


Proposed addition

length(size)
The length of a resource, in bytes.

Removed properties that are 70% or less of discovered elements

category
description
sample
payment
price


Thanks.

Martin


Properties that are 70% or over of discovered elements determined by 
the audio-info examples[2]


haudio (required)
fn (required)
contributor
album
enclosure
type
published
duration
position
photo

Removed properties that are 70% or less of discovered elements

category
description
sample
payment
price
item

Recommended addition

length(size)

all the examples that relate to the final download itself when clicked 
have a file size, a user agent has to first download a small part of 
the audio to determine the file size.


haudio in part reuses the concept of an atom enclosure and length is a 
required element of an atom:enclosure eg:


 enclosure url=http://www.example.org/myaudiofile.mp3;
length=12345
type=audio/mpeg /

http://www.ibm.com/developerworks/xml/library/x-atom10.html

The above is also true with RSS2 enclosures

enclosure url=http://www.scripting.com/mp3s/weatherReportSuite.mp3;
 length=12216320
 type=audio/mpeg /

http://cyber.law.harvard.edu/rss/rss.html


Publishing Recommendations

hAtom[3]  or XOXO[4] should be used for grouping audio
hAtom should be used for human edited content relating to an audio 
such as a description or press release about the audio content

hReview[5] should be used to rate and review an audio.

I hope to make the above recommendations Final  and make the above 
changes within the next week or so.


[1] http://microformats.org/wiki/haudio
[2] http://microformats.org/wiki/audio-info-examples
[3] http://microformats.org/wiki/hatom
[4] http://microformats.org/wiki/xoxo
[5] http://microformats.org/wiki/hreview

Best wishes




--
Martin McEvoy

http://weborganics.co.uk/

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] hAudio 1.0 Draft Release

[Manu Sporny]

Martin McEvoy wrote:
 In Microformats this means that if a propery is used more than 80% of
 the time then it should be included in the format, this will result in
 the top 20% of all discovered properties making their way into the final
 Microformat.

You continue to contradict yourself, which is why we're having such a
hard time with your argumentation, Martin. Your statement above makes no
sense. Let's break it down and use some real numbers to see why:

Martin McEvoy wrote:
 In Microformats this means that if a propery is used more than 80% of
 the time then it should be included in the format,

We'll call this Statement A. If we were to hold this true, then we would
be left with these properties for hAudio. We would pick only the
properties that were used in at least 80% of all sites:

# album artist: 95.12%
# track title: 90.24%
# album title: 87.80%
# album tracks: 80.49%

then you go on to state this:

Martin McEvoy wrote:
 this will result in the top 20% of all discovered properties making
 their way into the final Microformat.

Let's call this Statement B. If we were to hold this true, then out of
all discovered properties, of which there are 163 properties[1], we
would be left with the top 32 properties:

20% of 163 = 32.6

More specifically, we would be left with these properties for hAudio:

album artist   : 95.12%
track title: 90.24%
album title: 87.80%
album tracks   : 80.49%
album release date : 73.17%
album cover image  : 73.17%
track number   : 70.73%
album label: 68.29%
track sample   : 68.29%
track web-based purchase   : 60.98%
album web-based purchase   : 60.98%
album genre: 58.54%
track artist   : 56.10%
track length   : 51.22%
track price: 51.22%
album price: 48.78%
description: 39.02%
album format   : 26.83%
track release date : 26.83%
album sample   : 24.39%
album length   : 21.95%
track album: 17.07%
track genre: 14.63%
album physical-based purchase  : 14.63%
track label: 14.63%
track format   : 14.63%
album bitrate  : 12.20%
album number of tracks : 12.20%
album reviews  : 12.20%
track rating   : 9.76%
track album title  : 9.76%
album license  : 7.32%

Quite clearly, Statement A and Statement B say two different things.
However, you state that because of Statement A, Statement B follows -
even though both statements are talking about the same thing and they
contradict each other. You have to pick either Statement A OR Statement
B - not both.

We're stating that Statement B is the correct understanding of the
Pareto Principle as applied to hAudio. You are saying that both of them
are the correct understanding - again, a contradiction.

Just to be clear, here's what you said:

Martin McEvoy wrote:
 In Microformats this means that if a propery is used more than 80% of
 the time then it should be included in the format, this will result in
 the top 20% of all discovered properties making their way into the
 final Microformat.

It is because you keep repeating statements like this that I don't think
there is a good reason to remove category, description, sample, payment,
or price from hAudio. The removal of all of these properties is based on
the statement you have made above - which is a logical fallacy.

-- manu

[1]http://microformats.org/wiki/audio-info-services-ufa
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new