Radio Clash 113: From Brussels With Love TWI 007 / Cuddle the Present mk2

[...]

Kerrier District (aka Luke Vibert) - Disco Nasty

> Note that descriptions on the page can have many different > groupings of > the content on the page. In this example, the band is related to or > grouped with television shows (which are groups in and of themselves), > bands are also groups with other bands: > http://www.bitmunk.com/view/media/6068744 This is a page about a single album, and the same kind of album-track markup above would work. The TV shows don't specify which songs were played on which shows, so even if we considered that within scope here (which I think is a stretch) we couldn't mark up the show-track grouping at all, because it's not published. > This one is especially important. Note that the album is described > first, then the top songs as an ordered list, then what the listeners > also bought, and then finally the songs that are related to the album > mentioned at the very beginning of the page. > http://www.misrolas.com/downloadmusic/album.php?id=1316 Each of those tracks from other albums and each of those albums could be microformatted on their own album pages, where more complete info is available. With only the tracks in the relevant album remaining, the same album-track grouping above would work. > Does that help clarify the difference between a sparse grouping and a > non-sparse grouping? Yes. I think what makes these all "sparse" is secondary information that can be left alone or microformatted on more relevant pages while we microformat enough useful information to address the audio-info problem statement. We shouldn't feel compelled to microformat everything. -- Scott Reynen MakeDataMakeSense.com From scott at makedatamakesense.com Wed May 2 18:40:55 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed May 2 18:41:01 2007 Subject: [uf-new] First draft of hAudio proposal In-Reply-To: <46390F23.40905@digitalbazaar.com> References: <00a001c78d03$b642adf0$bc08a8c0@nzto22> <46390F23.40905@digitalbazaar.com> Message-ID: <12E61003-D0D4-4AA4-A2D0-E721F8F8B3EB@makedatamakesense.com> On May 2, 2007, at 5:22 PM, Manu Sporny wrote: > Scott, why don't we allow verbs for rel-design-patterns? Unless otherwise noted, I'm only speaking for myself on this list. This is why I don't like verbs in rel: The rel attribute is short for relationship, not action. Verbs describe actions. Nouns describe relationships. Most rel- microformats follow this convention. The one that doesn't has this as the first open issue: http://microformats.org/wiki/rel-nofollow#open_issues "nofollow indicates a behavior rather than a relationship" I'll retract my suggestion to change from a verb to a noun and instead suggest changing from rel to class. I think what we're describing is a class of link, specifically the class that allows us to acquire, not a relationship between two documents. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Thu May 3 08:09:36 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 3 08:09:40 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <21e523c20705021408j5eb2e00exfcdd88b05e3399d8@mail.gmail.com> References: <4637779A.30301@digitalbazaar.com> <4637E01A.2030507@digitalbazaar.com> <1178099894.17022.28.camel@localhost.localdomain> <4638986A.2030303@digitalbazaar.com> <1178121483.18770.24.camel@localhost.localdomain> <4638C7CD.1070408@digitalbazaar.com> <21e770780705021050w17a34068k910364d16a43d2c1@mail.gmail.com> <4638F47B.2020001@digitalbazaar.com> <21e523c20705021408j5eb2e00exfcdd88b05e3399d8@mail.gmail.com> Message-ID: <4639FB30.8080902@digitalbazaar.com> David Janes wrote: > This comment is sort of meta, but here goes anyway... > > When I was designing hAtom, I framed the discussion in terms of > semantic elements discovered / brainstormed -- Feed, Entry, Entry > Title, Entry Author and so forth, and the relationships between them. This has been done for hAudio as well in the brainstorming section: http://microformats.org/wiki/audio-info-brainstorming#Discovered_Elements > Note that you're always free to adopt a subset of elements from hAtom > and hWhatever if they have the appropriate meaning. In fact you > probably _should_ maybe even _must_ adopt them. Then the question at > the end becomes "does it make sense to grab the top level container > element/class for this microformat, or grab a new one" Very good advice, we would be wise to be wary of new tags that are not needed. We should re-use old tags if they do they carry the same semantics as the newly proposed tags. -- manu From msporny at digitalbazaar.com Thu May 3 08:15:56 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 3 08:15:59 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <4rtUDTQpCQOGFwW5@pigsonthewing.org.uk> References: <4637779A.30301@digitalbazaar.com> <21e770780705011037i6e519759x7d074d80b007edf8@mail.gmail.com> <4637E01A.2030507@digitalbazaar.com> <1178099894.17022.28.camel@localhost.localdomain> <4638986A.2030303@digitalbazaar.com> <1178121483.18770.24.camel@localhost.localdomain> <4638C7CD.1070408@digitalbazaar.com> <21e770780705021050w17a34068k910364d16a43d2c1@mail.gmail.com> <4638F47B.2020001@digitalbazaar.com> <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com> <4rtUDTQpCQOGFwW5@pigsonthewing.org.uk> Message-ID: <4639FCAC.70309@digitalbazaar.com> Andy Mabbett wrote: > In message <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com>, > Scott Reynen writes > >> length -> new class="length", or defer in first draft > > Should be a measure format I agree... but we don't have a measure format yet and nobody seems to be pushing that initiative forward. Most of the audio-info-examples never specify units (seconds are assumed). >> price -> new class="price", or defer in first draft > > Should be a currency format It is in the current proposal: http://microformats.org/wiki/audio-info-proposal#Price -- manu From msporny at digitalbazaar.com Thu May 3 08:34:12 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 3 08:34:16 2007 Subject: [uf-new] First draft of hAudio proposal In-Reply-To: <12E61003-D0D4-4AA4-A2D0-E721F8F8B3EB@makedatamakesense.com> References: <00a001c78d03$b642adf0$bc08a8c0@nzto22> <46390F23.40905@digitalbazaar.com> <12E61003-D0D4-4AA4-A2D0-E721F8F8B3EB@makedatamakesense.com> Message-ID: <463A00F4.3060404@digitalbazaar.com> Scott Reynen wrote: > I'll retract my suggestion to change from a verb to a noun and instead > suggest changing from rel to class. I think what we're describing is a > class of link, specifically the class that allows us to acquire, not a > relationship between two documents. Good point and good solution. I've updated the wiki to reflect your input: http://microformats.org/wiki/audio-info-proposal#Schema http://microformats.org/wiki/audio-info-proposal#Acquire -- manu From bsittler at gmail.com Thu May 3 08:39:55 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Thu May 3 08:39:59 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <4639FCAC.70309@digitalbazaar.com> References: <4637779A.30301@digitalbazaar.com> <4638986A.2030303@digitalbazaar.com> <1178121483.18770.24.camel@localhost.localdomain> <4638C7CD.1070408@digitalbazaar.com> <21e770780705021050w17a34068k910364d16a43d2c1@mail.gmail.com> <4638F47B.2020001@digitalbazaar.com> <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com> <4rtUDTQpCQOGFwW5@pigsonthewing.org.uk> <4639FCAC.70309@digitalbazaar.com> Message-ID: allow 8601 duration notation (see e.g. http://en.wikipedia.org/wiki/ISO_8601#Duration ) but treat an unmarked number as seconds and you'll have power and flexibility while also using standards. because of its unambiguous form, you could even support seconds only for now, and add 8601 duration support later, but that runs the risk of horribly confusing the first generation of implementations with the second generation of data (as has happened with some other specs that have made this change.) notations for 3 hours ten seconds and three hundredths of a second: PT3H10.03S ^- duration notation PT03:00:10.03 ^- combined notation 10810.03 ^- pure seconds (not 8601 but too simple not to allow) -ben On 5/3/07, Manu Sporny wrote: > Andy Mabbett wrote: > > In message <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com>, > > Scott Reynen writes > > > >> length -> new class="length", or defer in first draft > > > > Should be a measure format > > I agree... but we don't have a measure format yet and nobody seems to be > pushing that initiative forward. Most of the audio-info-examples never > specify units (seconds are assumed). > > >> price -> new class="price", or defer in first draft > > > > Should be a currency format > > It is in the current proposal: > > http://microformats.org/wiki/audio-info-proposal#Price > > -- manu > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From martin at weborganics.co.uk Thu May 3 11:06:29 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu May 3 11:05:54 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: References: <4637779A.30301@digitalbazaar.com> <4638986A.2030303@digitalbazaar.com> <1178121483.18770.24.camel@localhost.localdomain> <4638C7CD.1070408@digitalbazaar.com> <21e770780705021050w17a34068k910364d16a43d2c1@mail.gmail.com> <4638F47B.2020001@digitalbazaar.com> <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com> <4rtUDTQpCQOGFwW5@pigsonthewing.org.uk> <4639FCAC.70309@digitalbazaar.com> Message-ID: <1178215589.24455.6.camel@localhost.localdomain> On Thu, 2007-05-03 at 08:39 -0700, Ben Wiley Sittler wrote: > allow 8601 duration notation (see e.g. > http://en.wikipedia.org/wiki/ISO_8601#Duration ) but treat an unmarked > number as seconds and you'll have power and flexibility while also > using standards. because of its unambiguous form, you could even > support seconds only for now, and add 8601 duration support later, but > that runs the risk of horribly confusing the first generation of > implementations with the second generation of data (as has happened > with some other specs that have made this change.) > > notations for 3 hours ten seconds and three hundredths of a second: > > PT3H10.03S > ^- duration notation > PT03:00:10.03 > ^- combined notation > 10810.03 > ^- pure seconds (not 8601 but too simple not to allow) > > -ben so this would be better to specify length 3m 30s maybe this needs to be added to http://microformats.org/wiki/measure-brainstorming > > On 5/3/07, Manu Sporny wrote: > > Andy Mabbett wrote: > > > In message <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com>, > > > Scott Reynen writes > > > > > >> length -> new class="length", or defer in first draft > > > > > > Should be a measure format > > > > I agree... but we don't have a measure format yet and nobody seems to be > > pushing that initiative forward. Most of the audio-info-examples never > > specify units (seconds are assumed). > > > > >> price -> new class="price", or defer in first draft > > > > > > Should be a currency format > > > > It is in the current proposal: > > > > http://microformats.org/wiki/audio-info-proposal#Price > > > > -- manu > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -------------- 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/20070503/4c1b7de6/smime.bin From martin at weborganics.co.uk Thu May 3 11:09:21 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu May 3 11:08:44 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <1178215589.24455.6.camel@localhost.localdomain> References: <4637779A.30301@digitalbazaar.com> <4638986A.2030303@digitalbazaar.com> <1178121483.18770.24.camel@localhost.localdomain> <4638C7CD.1070408@digitalbazaar.com> <21e770780705021050w17a34068k910364d16a43d2c1@mail.gmail.com> <4638F47B.2020001@digitalbazaar.com> <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com> <4rtUDTQpCQOGFwW5@pigsonthewing.org.uk> <4639FCAC.70309@digitalbazaar.com> <1178215589.24455.6.camel@localhost.localdomain> Message-ID: <1178215761.24455.8.camel@localhost.localdomain> On Thu, 2007-05-03 at 19:06 +0100, Martin McEvoy wrote: > On Thu, 2007-05-03 at 08:39 -0700, Ben Wiley Sittler wrote: > > allow 8601 duration notation (see e.g. > > http://en.wikipedia.org/wiki/ISO_8601#Duration ) but treat an unmarked > > number as seconds and you'll have power and flexibility while also > > using standards. because of its unambiguous form, you could even > > support seconds only for now, and add 8601 duration support later, but > > that runs the risk of horribly confusing the first generation of > > implementations with the second generation of data (as has happened > > with some other specs that have made this change.) > > > > notations for 3 hours ten seconds and three hundredths of a second: > > > > PT3H10.03S > > ^- duration notation > > PT03:00:10.03 > > ^- combined notation > > 10810.03 > > ^- pure seconds (not 8601 but too simple not to allow) > > > > -ben > > so this would be better to specify length > > 3m 30s sorry typo title="3:00" ahem... > > maybe this needs to be added to > > http://microformats.org/wiki/measure-brainstorming > > > > > On 5/3/07, Manu Sporny wrote: > > > Andy Mabbett wrote: > > > > In message <32FB44E8-37B8-4A19-92F1-083D5EE6122F@makedatamakesense.com>, > > > > Scott Reynen writes > > > > > > > >> length -> new class="length", or defer in first draft > > > > > > > > Should be a measure format > > > > > > I agree... but we don't have a measure format yet and nobody seems to be > > > pushing that initiative forward. Most of the audio-info-examples never > > > specify units (seconds are assumed). > > > > > > >> price -> new class="price", or defer in first draft > > > > > > > > Should be a currency format > > > > > > It is in the current proposal: > > > > > > http://microformats.org/wiki/audio-info-proposal#Price > > > > > > -- manu > > > _______________________________________________ > > > microformats-new mailing list > > > microformats-new@microformats.org > > > http://microformats.org/mailman/listinfo/microformats-new > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new -------------- 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/20070503/7898934f/smime.bin From msporny at digitalbazaar.com Thu May 3 12:25:39 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 3 12:25:42 2007 Subject: [uf-new] hAtom is not a silver bullet Message-ID: <463A3733.9020405@digitalbazaar.com> The argument has been put forth several times during the audio-info exploratory process that hAtom should be used, directly, for publishing information related to audio. Let us first understand what hAtom is: "hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the Atom (http://www.atomenabled.org/) syndication format." [1] "hAtom is a microformat for identifying semantic information in weblog posts and practically any other place Atom (http://www.atomenabled.org/) may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions." [2] While hAtom /could/ be used for this purpose, I hope to outline several reasons on why this is a bad idea. The main points that will be addressed are: 1. The concepts identified for hAtom are not the same concepts that were identified for hAudio. The problem space is different. 2. hAtom has a very strong "syndication" background and is not fit for describing audio recordings. They are different solutions. 3. Extending hAtom to fit hAudio is a bad design approach, we must not allow unnecessary feature creep. Confusing hAtom and hAudio Concepts ----------------------------------- There have been several proposed mappings (both on the list and off of the list) from hAtom to hAudio. One of them is used for example, but can be extended to every hAtom-hAudio mapping proposal: > work-title -> hatom entry-title hAudio isn't specifying an entry in a blog or syndication. We are talking about the title of a creative work. This is an important distinction. The hAtom documentation states this for entry-title: "an Entry Title element represents the concept of an Atom entry title" [3] That concept is defined as the following: "The 'atom:title' element is a Text construct that conveys a human-readable title for an entry or feed." [4] And further research shows that and entry is defined thusly: "The 'atom:entry' element represents an individual entry, acting as a container for metadata and data associated with the entry. This element can appear as a child of the atom:feed element, or it can appear as the document (i.e., top-level) element of a stand-alone Atom Entry Document." [5] Feed is also defined thusly: "The 'atom:feed' element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed. Its element children consist of metadata elements followed by zero or more atom:entry child elements." [6] 'entry-title' is specifically meant for titles in entries, which the language of hAtom and the Atom specification associate very directly with syndication of content. We should be making the argument that hAtom should be kept simple and not extended. We should be saying that hAtom can encapsulate other Microformats such as audio, video and image metadata. hAtom is Strongly Related to Syndication ---------------------------------------- There is no denying the very strong link that hAtom has with syndication. It is a fantastic Microformat for that purpose,