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, it borrows almost every one of its concepts from the Atom Syndication format: "The Atom Syndication Format provides the conceptual basis for this microformat, with the following caveats: * Atom provides a lot more functionality than we need for a 'blog post' microformat, so we've taken the minimal number of elements needed. * the 'logical' model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct. * the 'physical' model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for 'bridging the gap'" [7] Even the Atom Syndication Format is very specific about what the format is intended for: "The primary use case that Atom addresses is the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents." [8] Extending hAtom to Fit hAudio is a Bad Design Approach ------------------------------------------------------ "Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title." [8] Pay particular attention to the phrase "with an extensible set of attached metadata". This is what we mean when we say that hAtom should encapsulate other Microformats, not be extended because "all we need is two more elements to make this fix the Microformat problem of the day!" We must fight feature creep into these formats, especially the established ones, every step of the way. -- manu [1] http://microformats.org/wiki/hatom [2] http://microformats.org/wiki/hatom#Introduction [3] http://microformats.org/wiki/hatom#Entry [4] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 [5] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.entry [6] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.feed [7] http://microformats.org/wiki/hatom#In_General [8] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.1 From hober0 at gmail.com Thu May 3 13:48:39 2007 From: hober0 at gmail.com (Edward O'Connor) Date: Thu May 3 13:49:01 2007 Subject: [uf-new] Re: hAtom is not a silver bullet References: <463A3733.9020405@digitalbazaar.com> Message-ID: <86sladmy54.fsf@rakim.cfhp.org> Manu Sporny wrote: > 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[...] While hAtom /could/ be > used for this purpose, I hope to outline several reasons on why this > is a bad idea[...] > > 2. hAtom has a very strong "syndication" background and is not fit for > describing audio recordings. They are different solutions. I don't understand this objection. Yes, hAtom is based on Atom, and Atom is a syndication format. But you can use hAtom for many non-syndication purposes. For instance, the basic data in an hAtom entry (id, published/updated date(s), title, author, content) map extremely well onto representing mail, e- or otherwise. An example of such a use is , a marked up form of the Federalist Papers. So the origin of hAtom in a syndication background isn't, as such, a reasonable reason to object to its use in non-syndication contexts. Ted -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From msporny at digitalbazaar.com Thu May 3 14:04:05 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 3 14:04:09 2007 Subject: [uf-new] Re: hAtom is not a silver bullet In-Reply-To: <86sladmy54.fsf@rakim.cfhp.org> References: <463A3733.9020405@digitalbazaar.com> <86sladmy54.fsf@rakim.cfhp.org> Message-ID: <463A4E45.7020602@digitalbazaar.com> Edward O'Connor wrote: > Manu Sporny wrote: > >> 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[...] While hAtom /could/ be >> used for this purpose, I hope to outline several reasons on why this >> is a bad idea[...] >> >> 2. hAtom has a very strong "syndication" background and is not fit for >> describing audio recordings. They are different solutions. > > So the origin of hAtom in a syndication background isn't, as such, a > reasonable reason to object to its use in non-syndication contexts. The objection wasn't regarding its use in non-syndication contexts. The objection was to its use when describing audio recordings: "hAtom has a very strong "syndication" background and is not fit for describing audio recordings. They are different solutions." To further underline why hAtom is not good for hAudio, please refer to this thread: http://microformats.org/discuss/mail/microformats-new/2007-May/000300.html or even this one: http://microformats.org/discuss/mail/microformats-new/2007-April/000138.html -- manu From davidjanes at blogmatrix.com Thu May 3 14:12:42 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Thu May 3 14:12:45 2007 Subject: [uf-new] Re: hAtom is not a silver bullet In-Reply-To: <463A4E45.7020602@digitalbazaar.com> References: <463A3733.9020405@digitalbazaar.com> <86sladmy54.fsf@rakim.cfhp.org> <463A4E45.7020602@digitalbazaar.com> Message-ID: <21e523c20705031412r551b6413k69d0a8254b20d7a0@mail.gmail.com> On 5/3/07, Manu Sporny wrote: > Edward O'Connor wrote: > > Manu Sporny wrote: > > > >> 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[...] While hAtom /could/ be > >> used for this purpose, I hope to outline several reasons on why this > >> is a bad idea[...] > >> > >> 2. hAtom has a very strong "syndication" background and is not fit for > >> describing audio recordings. They are different solutions. > > > > So the origin of hAtom in a syndication background isn't, as such, a > > reasonable reason to object to its use in non-syndication contexts. > > The objection wasn't regarding its use in non-syndication contexts. The > objection was to its use when describing audio recordings: > > "hAtom has a very strong "syndication" background and is not fit for > describing audio recordings. They are different solutions." Whether or not hAtom is suitable for describing audio formats is something I'll more than happily let you decide. However, your characterization of hAtom as having a "syndication" background / being some sort of syndication format is wrong, or as wrong as the statement: "blogs have a syndication background". Yes, we refer to the Atom standard, but as appropriate one is expected to make the mapping when it talks about "atom feed" to "the content being marked up with hAtom" -- the same way when reading hCard we know we're talking about content being marked up with that rather than a block of vCard text. Regards, etc... David -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From bsittler at gmail.com Thu May 3 15:52:52 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Thu May 3 15:52:56 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <1178215761.24455.8.camel@localhost.localdomain> References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> Message-ID: actually i think that should be one of: 3m 30s note the initial 'P'. that differentiates it from the interval syntax in 8601, e.g. T12:00:00/T12:03:30 (an interval starting at noon and ending 3 minutes 30 seconds later, timezone unspecified and assumed to be either UTC/GMT or localtime, depending on the application) On 5/3/07, Martin McEvoy wrote: > 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 > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > > > From msporny at digitalbazaar.com Thu May 3 16:16:15 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 3 16:16:17 2007 Subject: [uf-new] Re: hAtom is not a silver bullet In-Reply-To: <21e523c20705031412r551b6413k69d0a8254b20d7a0@mail.gmail.com> References: <463A3733.9020405@digitalbazaar.com> <86sladmy54.fsf@rakim.cfhp.org> <463A4E45.7020602@digitalbazaar.com> <21e523c20705031412r551b6413k69d0a8254b20d7a0@mail.gmail.com> Message-ID: <463A6D3F.9010909@digitalbazaar.com> David Janes wrote: > However, your characterization of hAtom as having a "syndication" > background / being some sort of syndication format is wrong I'm sure I am being dense... but I thought Atom was all about syndication? Perhaps we have different definitions of what "syndication" means? "S: (n) syndication (selling (an article or cartoon) for publication in many magazines or newspapers at the same time) 'he received a comfortable income from the syndication of his work'" [1] "In general, syndication means the distribution a news article through a syndicate - in this case an RSS feed - for publication in a number of newspapers or periodicals simultaneously. Used in the context of RSS because RSS syndication is all about distributing content for reuse or redistribution on other websites." [2] "Created by leading service providers, tool vendors and independent developers, Atom is designed to be a universal publishing standard for personal content and weblogs." [3] Am I confusing syndication with publishing? Are they really that different? > Yes, we > refer to the Atom standard, but as appropriate one is expected to make > the mapping when it talks about "atom feed" to "the content being > marked up with hAtom" -- the same way when reading hCard we know we're > talking about content being marked up with that rather than a block of > vCard text. Please clarify - the above didn't really make any sense to me (I'm not being difficult, I really don't get what you are attempting to say). Are there a large number of examples of hAtom being used for anything else than syndication/blogging/news article publishing? Perhaps your viewpoint can be backed up with some examples that I am unaware of? Who is currently using hAtom for non-syndication/non-blogging/non-news article-based publishing? Please don't use corner-cases! -- manu [1] http://wordnet.princeton.edu/perl/webwn?s=syndication [2] http://www.rsstoolchest.com/rss-glossary.html [3] http://www.atomenabled.org/ From martin at weborganics.co.uk Thu May 3 17:44:01 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu May 3 17:43:25 2007 Subject: [uf-new] Re: hAtom is not a silver bullet In-Reply-To: <463A6D3F.9010909@digitalbazaar.com> References: <463A3733.9020405@digitalbazaar.com> <86sladmy54.fsf@rakim.cfhp.org> <463A4E45.7020602@digitalbazaar.com> <21e523c20705031412r551b6413k69d0a8254b20d7a0@mail.gmail.com> <463A6D3F.9010909@digitalbazaar.com> Message-ID: <1178239441.26316.52.camel@localhost.localdomain> Oh dear! I dont mean to be abrupt with you guys but think we are all getting a bit off the path with all this Manu, you are right hAtom is not "a silver bullet" no one ever suggested it was. David, I would argue that publishing music and blog publishing have similarities but we have already established that hAtom may not be the solution to the hAudio problem. hAudio may be something we can sprinkle in to other microformats such as hAtom or any future media-info microformat. http://microformats.org/discuss/mail/microformats-new/2007-April/000096.html what we did decide was in any media-info microformat the download url is not going to be necessary, not important to media info, but a highly important factor of music-downloads. so the media-info discussion was broken down into pieces, audio info first, then video and images will hopefully fit in (although I doubt it). I hope everyone is up to speed on what we are trying to do now. On Thu, 2007-05-03 at 19:16 -0400, Manu Sporny wrote: > David Janes wrote: > > However, your characterization of hAtom as having a "syndication" > > background / being some sort of syndication format is wrong > > I'm sure I am being dense... but I thought Atom was all about > syndication? Perhaps we have different definitions of what "syndication" > means? > > "S: (n) syndication (selling (an article or cartoon) for publication in > many magazines or newspapers at the same time) 'he received a > comfortable income from the syndication of his work'" [1] > > "In general, syndication means the distribution a news article through a > syndicate - in this case an RSS feed - for publication in a number of > newspapers or periodicals simultaneously. Used in the context of RSS > because RSS syndication is all about distributing content for reuse or > redistribution on other websites." [2] > > "Created by leading service providers, tool vendors and independent > developers, Atom is designed to be a universal publishing standard for > personal content and weblogs." [3] > > Am I confusing syndication with publishing? Are they really that different? > > > Yes, we > > refer to the Atom standard, but as appropriate one is expected to make > > the mapping when it talks about "atom feed" to "the content being > > marked up with hAtom" -- the same way when reading hCard we know we're > > talking about content being marked up with that rather than a block of > > vCard text. > > Please clarify - the above didn't really make any sense to me (I'm not > being difficult, I really don't get what you are attempting to say). > > Are there a large number of examples of hAtom being used for anything > else than syndication/blogging/news article publishing? > > Perhaps your viewpoint can be backed up with some examples that I am > unaware of? Who is currently using hAtom for > non-syndication/non-blogging/non-news article-based publishing? Please > don't use corner-cases! > > -- manu > > [1] http://wordnet.princeton.edu/perl/webwn?s=syndication > [2] http://www.rsstoolchest.com/rss-glossary.html > [3] http://www.atomenabled.org/ > _______________________________________________ > 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/20070504/6d556fbd/smime.bin From danny.ayers at gmail.com Thu May 3 18:13:07 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Thu May 3 18:13:10 2007 Subject: [uf-new] Re: hAtom is not a silver bullet In-Reply-To: <1178239441.26316.52.camel@localhost.localdomain> References: <463A3733.9020405@digitalbazaar.com> <86sladmy54.fsf@rakim.cfhp.org> <463A4E45.7020602@digitalbazaar.com> <21e523c20705031412r551b6413k69d0a8254b20d7a0@mail.gmail.com> <463A6D3F.9010909@digitalbazaar.com> <1178239441.26316.52.camel@localhost.localdomain> Message-ID: <1f2ed5cd0705031813v7be181bbm207b7275e4e5322e@mail.gmail.com> It's great that this challenge (story, use case) has been set. Atom is a very good way of pushing stuff around, hAtom reflects that. If the material is such that it can be faithfully (ish) rendered in html, that's great - things like links to audio files obviously can. But (crucify me) I do think it's incumbant on advocates of microformats to acknowledge that text/html is not the only fruit. Sure, make the wordy bits renderable, but don't forget the option of expressing the information in other ways and just doing a html view, a view of some data describing some data. If it doesn't fit comfortably with a microformat expression, so be it. Do pointers from the uF (link rel etc...) to other stuff. It's easier than it looks. If it's on the web all you've really got to worry about is giving the significant bits URIs (and hopefully delivering something useful if a client sees it). At this point I pick up the bible and ask - what is the problem you're trying to solve? Cheers, Danny. // respect to the moderators for not /dev/null-ing this thread -- http://dannyayers.com From martin at weborganics.co.uk Fri May 4 05:24:13 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 4 05:23:40 2007 Subject: [uf-new] First draft of hAudio proposal In-Reply-To: <21e523c20705021438s3a4efb6q2b4a3213008f4887@mail.gmail.com> References: <4637779A.30301@digitalbazaar.com> <21e770780705011037i6e519759x7d074d80b007edf8@mail.gmail.com> <4637E01A.2030507@digitalbazaar.com> <21e523c20705020405o1f08c1d3s29a8c8bef104a830@mail.gmail.com> <21e523c20705021222v20d7fb3pf4aef9c53a2b1046@mail.gmail.com> <0btXP$QqFQOGFw0Z@pigsonthewing.org.uk> <21e523c20705021438s3a4efb6q2b4a3213008f4887@mail.gmail.com> Message-ID: <1178281453.31222.21.camel@localhost.localdomain> Manu I had a thought about collections I would like to share with you, If we look at collections in the most basic way we can this may give us an Idea of what is meant by "collection"? So... I look at my pile of books and think that these books need organizing in some way they are no good scattered around my house so I think maybe I can store these books in some kind of order. I buy a plain wooden shelf and put it up on my wall, still not a collection though eh.. its just a shelf.. but its somewhere to organize my pile of books. what makes the combination of a shelf and a pile of books a collection? is down to me and how I organize them i.e. author abc and volumes 123, title abc, topic etc... this is my collection of books. when my friend visits my house he notices my books on a shelf and says "nice collection". We may realize now that the problem of collections may have already been solved if you look at it the way you should

Are my books on a shelf. another one

download page 1

download page 2

download page 3
is my shelf
Are my books on a shelf. I hope you understand what I am driving at? also I think Scott may have a point the use of acquire may be wrong. Imagine you have to store this information in a database, you have to think about pluralization if I want to store page contents I create a table called "pages" if I want to store user information I create a table called "users" if you pluralize acquire you get acquires similar not the same meaning and still a singular yes! so you could use, acquirable which pluralizes as acquirables but this is ugly too so perhaps another word can be used? this is a good place to test this out http://nubyonrails.com/tools/pluralize Kind Regards Martin McEvoy -------------- 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/20070504/8391c0f1/smime.bin From rudy at sandbenders.ca Fri May 4 09:40:29 2007 From: rudy at sandbenders.ca (Rudy Desjardins) Date: Fri May 4 09:40:33 2007 Subject: More grouping discussion, was: Re: [uf-new] First draft of hAudio proposal Message-ID: On 5/4/07, Martin McEvoy wrote: >
> >
1. Are my books on a shelf. > > another one > >
  >
  href="http://link.to/download-1">download page 1
  >
  href="http://link.to/download-2">download page 2
  >
  href="http://link.to/download-3">download page 3
  >
  > >
  is my shelf >
  Are my books on a shelf. > It seems like some people are still missing/ignoring a few key points with regards to the problem(s) which some kind of a grouping or collection pattern are intended to address: 1) There exists a need to express a grouping relationship for data which is sparse. Please see the grouping-examplesand grouping-brainstorming wiki pages for descriptions of these types of data sets. 2) There exists a need to express an N-N grouping relationship, as opposed to simply 1-N which is all a heirarchical structure implicitly allows. Although a highly elegant solution, letting existing heirarchical markup alone define the containing and contained elements of a collection unfortunately does not address these two base problems, and I believe at this point there's a general consensus on these two problems being part of the problem space we're trying to solve with the grouping 'pattern', although additional real-world examples are still being compiled and analyzed to support this fact. -- Rudy X. Desjardins Programmer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070504/b9040556/attachment.html From martin at weborganics.co.uk Fri May 4 11:38:45 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 4 11:38:13 2007 Subject: More grouping discussion, was: Re: [uf-new] First draft of hAudio proposal In-Reply-To: References: Message-ID: <1178303925.32611.50.camel@localhost.localdomain> On Fri, 2007-05-04 at 12:40 -0400, Rudy Desjardins wrote: > On 5/4/07, Martin McEvoy wrote: >
  1. href="http://link.to/download-1">download page 1
  2. href="http://link.to/download-2">download page 2
  3. class="work-title"> href="http://link.to/download-3">download page 3
  > >
  1. Are my books on a shelf. > > another one > >
    >
    href="http://link.to/download-1">download page 1
    >
    href=" http://link.to/download-2">download page 2
    >
    class="work-title"> href=" http://link.to/download-3">download page 3
    >
    > >
    is my shelf >
    Are my books on a shelf. > > It seems like some people are still missing/ignoring a few key points > with regards to the problem(s) which some kind of a grouping or > collection pattern are intended to address: > > 1) There exists a need to express a grouping relationship for data > which is sparse. Please see the grouping-examples and > grouping-brainstorming wiki pages for descriptions of these types of > data sets. > > 2) There exists a need to express an N-N grouping relationship, as > opposed to simply 1-N which is all a heirarchical structure implicitly > allows. Hi Rudy thanks for your comments I have examined all the grouping-examples and what there is of the brainstorming. the first thing I noticed was that all the examples made an attempt at Lists some times numbered sometimes not most are either using tables or lists to do this others are using p's and div's they are all grouping these items using a container of some type in the first example I use
    to say this is my outline or grouping, the contents are haudio.
    is my content. From a human perspective need it go further than that? 2) There exists a need to express an N-N grouping relationship sorry if i seem a bit dumb but why? none of the examples to me show any need for this particular. your album.title class, namespace whatever you call it simply doesn't do this, all "." does is create an empty space or a stop or end not hey there is a relationship here. and may I add have you actually read this http://microformats.org/wiki/namespaces > > Although a highly elegant solution, Simple and easy to understand > letting existing heirarchical markup alone define the containing and > contained elements of a collection unfortunately does not address > these two base problems, and I believe at this point there's a general > consensus on these two problems being part of the problem space we're > trying to solve with the grouping 'pattern', although additional > real-world examples are still being compiled and analyzed to support > this fact. and when the real world examples are compiled both you and I shall both have more of an understanding of what we are talking about because at the moment all this is relating to is audio, when it includes Video which is a massive field on its own and would at least require grouping of un related directors or films, and Images that will require groupings of peoples own personal collections or artists by Renaissance or style, you then have to think of a more inclusive design pattern yes? > > -- > Rudy X. Desjardins > Programmer -------------- 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/20070504/42f786fd/smime.bin From msporny at digitalbazaar.com Sun May 6 19:13:03 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun May 6 19:13:06 2007 Subject: More grouping discussion, was: Re: [uf-new] First draft of hAudio proposal In-Reply-To: References: Message-ID: <463E8B2F.1090204@digitalbazaar.com> Rudy Desjardins wrote: > It seems like some people are still missing/ignoring a few key points > with regards to the problem(s) which some kind of a grouping or > collection pattern are intended to address: I have to agree with Rudy - some of you are missing the point of the grouping discussion. Perhaps it should be called the "relationships" discussion. The problem statement and examples clearly outline why just coming up with a solution for "lists" is not sufficient: "It is useful to understand the relationship between objects on a website. A blogger may want to describe several different objects on a web page and group them explicitly. It is important that the structure of the page not affect this grouping as network relationships are often not hierarchical (HTML is always hierarchical)." [1] If your answer to the problem is "just use
    and
    ", then you are only understanding half of the problem. > 1) There exists a need to express a grouping relationship for data which > is sparse. Please see the grouping-examples > and > grouping-brainstorming > wiki pages for > descriptions of these types of data sets. Again, Rudy is correct - the "ul/ol" solution does not solve the problem of sparse grouping. > 2) There exists a need to express an N-N grouping relationship, as > opposed to simply 1-N which is all a heirarchical structure implicitly > allows. The "ul/ol" solution doesn't solve N-N relationships either. > of the problem space we're trying to solve with the grouping 'pattern', > although additional real-world examples are still being compiled and > analyzed to support this fact. I find the fact that we are having to gather examples to prove that sparse sets and N-N relationships exist on the Internet a bit ridiculous. The Microformats process seems a tad bureaucratic at this point. The notion of sparse sets is fundamental to human organization and knowledge. Take this wikipedia article, for example: http://en.wikipedia.org/wiki/Sculpture There are several sparse groups listed on the page... many N-N relationships. Here are the sparse sets: * Indian sculptures * Chinese sculptures * European sculptures * pre-1700s sculptures * full-figure sculptures The N-N relationships: * full-figure sculptures + Indian sculptures * pre-1700s sculptures + Chinese sculptures Almost the entirety of Wikipedia is a lesson in sparse sets and N-N relationships. So, do we count this as 1 example... or do we count Wikipedia as 1,272,193 examples (give or take 400,000)? Remember, we're not secretly marking up any of this information. It's all there on the page and humans can understand it quite clearly. The only entity having trouble recognizing the grouping of the concepts are the computers. Microformats grouping is supposed to help solve ALL of these problems, not just provide a half-baked solution. Is the real issue that people don't think that 48 music examples plus the hundreds of thousands of Wikipedia entries aren't enough proof of sparse sets and N-N relationships? Or is the real issue that people don't like the current grouping problem solutions? Those aren't rhetorical questions - just want to know where to concentrate our efforts. -- manu [1] http://microformats.org/wiki/grouping-examples#The_Problem From msporny at digitalbazaar.com Mon May 7 07:14:00 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon May 7 07:14:04 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> Message-ID: <463F3428.2040901@digitalbazaar.com> Ben Wiley Sittler wrote: > actually i think that should be one of: > title="P210S" (210 seconds, 8601) or Ben, Your suggestion to use the ISO-8601 duration format has received favorable feedback. We should provide a very simple markup at first, providing only the bare essentials and building out to the full ISO-8601 time duration standard if necessary. Martin raised the point that this would solve the podcasting issues when attempting to specify where various clips start and end in a podcast or video. The page has been updated. "Length" has been changed to "Duration". A note specifying that we should use ISO-8601, specifically the "seconds" markup format, has been added. Thus a duration marked up for an audio recording would look like this: Three minutes, twenty-three seconds This is a good candidate for specifying time durations across Microformats and could be added to the datetime-design-pattern. -- manu From msporny at digitalbazaar.com Mon May 7 07:57:01 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon May 7 07:57:04 2007 Subject: [uf-new] Second attempt at hAudio proposal Message-ID: <463F3E3D.2090801@digitalbazaar.com> The newest proposal of hAudio (v0.3) is available: http://microformats.org/wiki/audio-info-proposal Here are the changes based on input from the community: ----------------------------------------------------------------- title -> work-title Fixed a typo on the page. There has been one objection to 'work-title'. It is suggested that we change it to 'fn', which didn't have that favorable of a reception. ----------------------------------------------------------------- collaborator -> contributor Changed collaborator element name to 'contributor' to follow Dublin Core's lead on the issue. ----------------------------------------------------------------- release-date -> published-date Changed release date to published date to be more specific about the contents of the element. ----------------------------------------------------------------- acquire Changed to be a class instead of a rel-attribute. There is still some concern over the name 'acquire'. Primarily in that it doesn't pluralize cleanly (it is a verb - it should probably be a noun?). ----------------------------------------------------------------- image-summary Unchanged. There have been suggestions to make this 'photo' or 'logo', but neither the semantics of photo or logo are correct. This element is planned to be used across audio, video and images... thus the semantics must mean the exact same in each Microformat. ----------------------------------------------------------------- genre -> category Changed genre to category as no rel-tag is needed for categories. A genre and style is a type of category, so using 'category' makes sense. ----------------------------------------------------------------- length -> duration Length is used more for spatial measurements than temporal ones. The measurement we are addressing is a temporal one, that of duration. ISO-8601 duration is used to specify the duration of an audio recording in seconds. ----------------------------------------------------------------- At the moment, there seem to be three debatable issues: - The use of 'fn' instead of 'work-title'. - The proper class name for the 'acquire' property. - Grouping (specifically, how do we tell albums apart from songs and relate songs to one another). -- manu From martin at weborganics.co.uk Mon May 7 08:36:24 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon May 7 08:35:54 2007 Subject: [uf-new] Second attempt at hAudio proposal In-Reply-To: <463F3E3D.2090801@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> Message-ID: <1178552184.18937.6.camel@localhost.localdomain> On Mon, 2007-05-07 at 10:57 -0400, Manu Sporny wrote: > The newest proposal of hAudio (v0.3) is available: > > http://microformats.org/wiki/audio-info-proposal > > Here are the changes based on input from the community: > > ----------------------------------------------------------------- > title -> work-title > > Fixed a typo on the page. There has been one objection to 'work-title'. > It is suggested that we change it to 'fn', which didn't have that > favorable of a reception. > > ----------------------------------------------------------------- > collaborator -> contributor > > Changed collaborator element name to 'contributor' to follow Dublin > Core's lead on the issue. > > ----------------------------------------------------------------- > release-date -> published-date > > Changed release date to published date to be more specific about the > contents of the element. > > ----------------------------------------------------------------- > acquire > > Changed to be a class instead of a rel-attribute. There is still some > concern over the name 'acquire'. Primarily in that it doesn't pluralize > cleanly (it is a verb - it should probably be a noun?). could we use an adjective? "obtainable" Is it the same thing? > > ----------------------------------------------------------------- > image-summary > > Unchanged. There have been suggestions to make this 'photo' or 'logo', > but neither the semantics of photo or logo are correct. This element is > planned to be used across audio, video and images... thus the semantics > must mean the exact same in each Microformat. > > ----------------------------------------------------------------- > genre -> category > > Changed genre to category as no rel-tag is needed for categories. A > genre and style is a type of category, so using 'category' makes sense. > > ----------------------------------------------------------------- > length -> duration > > Length is used more for spatial measurements than temporal ones. The > measurement we are addressing is a temporal one, that of duration. > ISO-8601 duration is used to specify the duration of an audio recording > in seconds. > > ----------------------------------------------------------------- > > At the moment, there seem to be three debatable issues: > > - The use of 'fn' instead of 'work-title'. > - The proper class name for the 'acquire' property. > - Grouping (specifically, how do we tell albums apart from songs and > relate songs to one another). > > -- manu > _______________________________________________ > 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/20070507/d25da7ce/smime.bin From jcraig at apple.com Mon May 7 10:58:22 2007 From: jcraig at apple.com (James Craig) Date: Mon May 7 10:58:27 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <463F3428.2040901@digitalbazaar.com> References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> Message-ID: Manu Sporny wrote: > Three minutes, twenty-three > seconds > > This is a good candidate for specifying time durations across > Microformats and could be added to the datetime-design-pattern. Manu et al, please keep in mind the work we are doing to correct the problem with the misuse of the abbr-design-pattern. Whatever the outcome, it will affect this misuse of ABBR as well. I'd encourage to contribute to the test case page as well. http://www.webstandards.org/2007/04/27/haccessibility/ http://microformats.org/wiki/assistive-technology-abbr-results http://microformats.org/wiki/assistive-technology http://microformats.org/wiki/accessibility From martin at weborganics.co.uk Mon May 7 11:25:28 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon May 7 11:24:57 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> Message-ID: <1178562328.19608.3.camel@localhost.localdomain> On Mon, 2007-05-07 at 10:58 -0700, James Craig wrote: > Manu Sporny wrote: > > > Three minutes, twenty-three > > seconds > > > > This is a good candidate for specifying time durations across > > Microformats and could be added to the datetime-design-pattern. > > Manu et al, please keep in mind the work we are doing to correct the > problem with the misuse of the abbr-design-pattern. Whatever the > outcome, it will affect this misuse of ABBR as well. I'd encourage to > contribute to the test case page as well. so Three minutes, twenty-three seconds would be more friendly? > > http://www.webstandards.org/2007/04/27/haccessibility/ > http://microformats.org/wiki/assistive-technology-abbr-results > http://microformats.org/wiki/assistive-technology > http://microformats.org/wiki/accessibility > > _______________________________________________ > 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/20070507/b2fadb18/smime.bin From jcraig at apple.com Mon May 7 11:30:38 2007 From: jcraig at apple.com (James Craig) Date: Mon May 7 11:30:42 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <1178562328.19608.3.camel@localhost.localdomain> References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> <1178562328.19608.3.camel@localhost.localdomain> Message-ID: Martin McEvoy wrote: > On Mon, 2007-05-07 at 10:58 -0700, James Craig wrote: >> Manu Sporny wrote: >> >>> Three minutes, twenty-three >>> seconds >>> >>> This is a good candidate for specifying time durations across >>> Microformats and could be added to the datetime-design-pattern. >> >> Manu et al, please keep in mind the work we are doing to correct the >> problem with the misuse of the abbr-design-pattern. Whatever the >> outcome, it will affect this misuse of ABBR as well. I'd encourage to >> contribute to the test case page as well. > > so > > Three minutes, twenty-three seconds > > > > would be more friendly? The final outcome has yet to be decided. I just wanted to remind you guys to keep an eye on it as the recommendation for abbr-design- pattern will most likely be changing. In the meantime, I would not recommend changing the draft. James From msporny at digitalbazaar.com Mon May 7 11:38:17 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon May 7 11:38:20 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> <1178562328.19608.3.camel@localhost.localdomain> Message-ID: <463F7219.8070501@digitalbazaar.com> James Craig wrote: > The final outcome has yet to be decided. I just wanted to remind you > guys to keep an eye on it as the recommendation for abbr-design-pattern > will most likely be changing. In the meantime, I would not recommend > changing the draft. Thanks James... we'll keep our eye out. Make sure to flog us if we miss an important change to the abbr-design-pattern. -- manu From martin at weborganics.co.uk Mon May 7 13:56:43 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon May 7 13:56:14 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <1178562328.19608.3.camel@localhost.localdomain> References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> <1178562328.19608.3.camel@localhost.localdomain> Message-ID: <1178571403.20357.13.camel@localhost.localdomain> On Mon, 2007-05-07 at 19:25 +0100, Martin McEvoy wrote: > On Mon, 2007-05-07 at 10:58 -0700, James Craig wrote: > > Manu Sporny wrote: > > > > > Three minutes, twenty-three > > > seconds > > > > > > This is a good candidate for specifying time durations across > > > Microformats and could be added to the datetime-design-pattern. > > > > Manu et al, please keep in mind the work we are doing to correct the > > problem with the misuse of the abbr-design-pattern. Whatever the > > outcome, it will affect this misuse of ABBR as well. I'd encourage to > > contribute to the test case page as well. > > so > > Three minutes, twenty-three seconds > > > > would be more friendly? this is better, Three minutes, twenty-three seconds Jaws will ignore the title attribute in (definition) and speak this as, Three minutes, twenty-three seconds and you get the tool tip too ;) here is a good article to read to help get abbr issues solved. http://alistapart.com/articles/hattrick > > > > > http://www.webstandards.org/2007/04/27/haccessibility/ > > http://microformats.org/wiki/assistive-technology-abbr-results > > http://microformats.org/wiki/assistive-technology > > http://microformats.org/wiki/accessibility > > > > _______________________________________________ > > 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/20070507/a104d21d/smime.bin From brian.suda at gmail.com Mon May 7 14:22:22 2007 From: brian.suda at gmail.com (Brian Suda) Date: Mon May 7 14:22:27 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <1178571403.20357.13.camel@localhost.localdomain> References: <4637779A.30301@digitalbazaar.com> <4639FCAC.70309@digitalbazaar.com> <1178215589.24455.6.camel@localhost.localdomain> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> <1178562328.19608.3.camel@localhost.localdomain> <1178571403.20357.13.camel@localhost.localdomain> Message-ID: <21e770780705071422v7ff63da2kc01edad6ea1c90ea@mail.gmail.com> As an FYI, the hCalendar and iCalendar spec already have a DURATION property. This could suffice for any Media format. If you choose to use class="duration" then it should be the same semantics as the hCalendar. FROM RFC2445: 4.3.6 Duration Value Name: DURATION Purpose: This value type is used to identify properties that contain a duration of time. Formal Definition: The value type is defined by the following notation: dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) dur-date = dur-day [dur-time] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-week = 1*DIGIT "W" dur-hour = 1*DIGIT "H" [dur-minute] dur-minute = 1*DIGIT "M" [dur-second] dur-second = 1*DIGIT "S" dur-day = 1*DIGIT "D" Description: If the property permits, multiple "duration" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. The format is expressed as the [ISO 8601] basic format for the duration of time. The format can represent durations in terms of weeks, days, hours, minutes, and seconds. Dawson & Stenerson Standards Track [Page 37] RFC 2445 iCalendar November 1998 No additional content value encoding (i.e., BACKSLASH character encoding) are defined for this value type. Example: A duration of 15 days, 5 hours and 20 seconds would be: P15DT5H0M20S A duration of 7 weeks would be: P7W -brian -- brian suda http://suda.co.uk From jcraig at apple.com Mon May 7 15:43:13 2007 From: jcraig at apple.com (James Craig) Date: Mon May 7 15:43:16 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <1178571403.20357.13.camel@localhost.localdomain> References: <4637779A.30301@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> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> <1178562328.19608.3.camel@localhost.localdomain> <1178571403.20357.13.camel@localhost.localdomain> Message-ID: <1861FA72-FD83-4762-BCA4-E7C5F0C21443@apple.com> Martin McEvoy wrote: > this is better, > > > > Three minutes, twenty-three seconds > > Added DFN to the test cases. http://microformats.org/wiki/assistive-technology-abbr- results#Markup_Possibilities > Jaws will ignore the title attribute in (definition) and speak > this as, "Three minutes, twenty-three seconds" Have you tested this? The test cases in the article are very different, and rely on the other element having another element's title attribute read instead of the DFN. I do not have access to JAWS now, but I would guess the example would still read the dfn[title]. Either way, I would hold off on re-implementation for now until the test cases are complete and tested. The article only mentions JAWS' behavior and, although it's the most popular stateside screen reader, it's hardly the definitive answer for what counts as accessible. James From msporny at digitalbazaar.com Tue May 8 06:53:57 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue May 8 06:54:03 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: <1178552184.18937.6.camel@localhost.localdomain> References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> Message-ID: <464080F5.4090402@digitalbazaar.com> Martin McEvoy wrote: >> ----------------------------------------------------------------- >> acquire >> >> Changed to be a class instead of a rel-attribute. There is still some >> concern over the name 'acquire'. Primarily in that it doesn't pluralize >> cleanly (it is a verb - it should probably be a noun?). > > could we use an adjective? "obtainable" > > > > Is it the same thing? Does that mean we could add 'able' to the end of verbs to solve this whole noun-verb issue for Microformat property names? acquirable? Ultimately, the contents of the 'acquire' element is a link to a process. It may be a direct link to a download, but most of the audio-info-examples contain a link to a checkout process of some kind. It is difficult to get away from verbs since a 'process' is conducive to being identified by a verb. Looking through all of the drafts on the Microformats site - all property names are nouns. Whether this happened by accident or was deliberate, there is a pattern emerging in the Microformats and that is: "We should use nouns for describing Microformat properties. Verbs describe actions, and actions don't describe data. Microformats are about describing data, not specifying actions on the data." Rather than try and identify the process, let's focus on the end result of the process (a file sitting on your hard drive that you acquired from the Internet). Here are the rename suggestions so far for hAudio 'acquire': obtainable downloadable acquireable acquisition representation rendition full-version file source resource asset receivable interpretation embodiment There have been two votes for source (Frances, Paul), one for obtainable (Martin), and one for representation (Manu). I'm pulling my support for 'acquire' (acquisition, acquirable) and placing it behind 'representation'. Representation is the root term for most of the download cases that we care about (audio, video, images) [1]. It can be re-used for audio, video and images Microformats. The examples support the word choice - "after following the process that is linked to, you will have a proper /representation/ of the work described by the hAudio/hVideo/hImage Microformat." Please show your support for this term, or if you do not support it please note why and suggest an alternative word and argument. -- manu [1] http://wordnet.princeton.edu/perl/webwn?o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&s=representation&i=2&h=0100000000000#c From msporny at digitalbazaar.com Tue May 8 07:17:29 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue May 8 07:23:35 2007 Subject: [uf-new] First attempt at hAudio proposal In-Reply-To: <21e770780705071422v7ff63da2kc01edad6ea1c90ea@mail.gmail.com> References: <4637779A.30301@digitalbazaar.com> <4639FCAC.70309@digitalbazaar.com> <1178215589.24455.6.camel@localhost.localdomain> <1178215761.24455.8.camel@localhost.localdomain> <463F3428.2040901@digitalbazaar.com> <1178562328.19608.3.camel@localhost.localdomain> <1178571403.20357.13.camel@localhost.localdomain> <21e770780705071422v7ff63da2kc01edad6ea1c90ea@mail.gmail.com> Message-ID: <46408679.3080709@digitalbazaar.com> Brian Suda wrote: > As an FYI, the hCalendar and iCalendar spec already have a DURATION > property. This could suffice for any Media format. If you choose to > use class="duration" then it should be the same semantics as the > hCalendar. Thanks Brian - I was unaware that they used ISO 8601. The main reason we decided not use the full ISO 8601 format was because we were under the impression that hAudio would be the first Microformat using it and we didn't want to create a steep implementation curve for hAudio. Since hCalendar uses "duration" as well, we are going to assume that a full ISO 8601 parser will be available and thus adopt ISO 8601 completely for hAudio's 'duration' field. The semantics between hCalendar and hAudio are the same as far as I can tell. We will still suggest (not require) that ISO 8601 mark-up occur in seconds (it is compact, is all we need for audio and video, and will hopefully make the first implementations a little easier). The hAudio wiki page has been updated: http://microformats.org/wiki/audio-info-proposal#Duration -- manu From cgriego at gmail.com Tue May 8 08:22:45 2007 From: cgriego at gmail.com (Chris Griego) Date: Tue May 8 08:22:49 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: <464080F5.4090402@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> Message-ID: <15996c030705080822p28a1eb87sfe64296c30035fbf@mail.gmail.com> rel-enclosure was ruled out because it's not always a download, but sometimes a way to purchase, right? What if hAudio suggested the use of rel-enclosure for downloads and rel-payment for ways to purchase? -- Chris Griego On 5/8/07, Manu Sporny wrote: > Martin McEvoy wrote: > >> ----------------------------------------------------------------- > >> acquire > >> > >> Changed to be a class instead of a rel-attribute. There is still some > >> concern over the name 'acquire'. Primarily in that it doesn't pluralize > >> cleanly (it is a verb - it should probably be a noun?). > > > > could we use an adjective? "obtainable" > > > > > > > > Is it the same thing? > > Does that mean we could add 'able' to the end of verbs to solve this > whole noun-verb issue for Microformat property names? > > acquirable? > > Ultimately, the contents of the 'acquire' element is a link to a > process. It may be a direct link to a download, but most of the > audio-info-examples contain a link to a checkout process of some kind. > It is difficult to get away from verbs since a 'process' is conducive to > being identified by a verb. > > Looking through all of the drafts on the Microformats site - all > property names are nouns. Whether this happened by accident or was > deliberate, there is a pattern emerging in the Microformats and that is: > > "We should use nouns for describing Microformat properties. Verbs > describe actions, and actions don't describe data. Microformats are > about describing data, not specifying actions on the data." > > Rather than try and identify the process, let's focus on the end result > of the process (a file sitting on your hard drive that you acquired from > the Internet). Here are the rename suggestions so far for hAudio 'acquire': > > obtainable > downloadable > acquireable > acquisition > representation > rendition > full-version > file > source > resource > asset > receivable > interpretation > embodiment > > There have been two votes for source (Frances, Paul), one for obtainable > (Martin), and one for representation (Manu). > > I'm pulling my support for 'acquire' (acquisition, acquirable) and > placing it behind 'representation'. Representation is the root term for > most of the download cases that we care about (audio, video, images) > [1]. It can be re-used for audio, video and images Microformats. The > examples support the word choice - "after following the process that is > linked to, you will have a proper /representation/ of the work described > by the hAudio/hVideo/hImage Microformat." > > Please show your support for this term, or if you do not support it > please note why and suggest an alternative word and argument. > > -- manu > > [1] > http://wordnet.princeton.edu/perl/webwn?o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&s=representation&i=2&h=0100000000000#c From brad.hafichuk at gmail.com Tue May 8 08:22:46 2007 From: brad.hafichuk at gmail.com (Brad Hafichuk) Date: Tue May 8 08:22:52 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: <464080F5.4090402@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> Message-ID: <620fa5c30705080822j2ce10e48l8ed1bc9e7533bc91@mail.gmail.com> Hey All! This is my first posting to this group, so please let me know if I'm overstepping my bounds. I realize that the audio-info-proposal is still being flushed out, but the description of Aquire clearly states that this is the full-version of the audio recording. I'm making an assumption that consensus have been reached on this. Using "full-version" seems to make the most sense as it's the least ambiguous term. There also seems to be a stronger correlation between using "sample" and "full-version" than with any other set of terms. As a runner-up, "source" seems to be acceptable, as we're used to using "src" for image (and embeded) media. Cheers, Brad On 5/8/07, Manu Sporny < msporny@digitalbazaar.com> wrote: > > Martin McEvoy wrote: > >> ----------------------------------------------------------------- > >> acquire > >> > >> Changed to be a class instead of a rel-attribute. There is still some > >> concern over the name 'acquire'. Primarily in that it doesn't pluralize > >> cleanly (it is a verb - it should probably be a noun?). > > > > could we use an adjective? "obtainable" > > > > > > > > Is it the same thing? > > Does that mean we could add 'able' to the end of verbs to solve this > whole noun-verb issue for Microformat property names? > > acquirable? > > Ultimately, the contents of the 'acquire' element is a link to a > process. It may be a direct link to a download, but most of the > audio-info-examples contain a link to a checkout process of some kind. > It is difficult to get away from verbs since a 'process' is conducive to > being identified by a verb. > > Looking through all of the drafts on the Microformats site - all > property names are nouns. Whether this happened by accident or was > deliberate, there is a pattern emerging in the Microformats and that is: > > "We should use nouns for describing Microformat properties. Verbs > describe actions, and actions don't describe data. Microformats are > about describing data, not specifying actions on the data." > > Rather than try and identify the process, let's focus on the end result > of the process (a file sitting on your hard drive that you acquired from > the Internet). Here are the rename suggestions so far for hAudio > 'acquire': > > obtainable > downloadable > acquireable > acquisition > representation > rendition > full-version > file > source > resource > asset > receivable > interpretation > embodiment > > There have been two votes for source (Frances, Paul), one for obtainable > (Martin), and one for representation (Manu). > > I'm pulling my support for 'acquire' (acquisition, acquirable) and > placing it behind 'representation'. Representation is the root term for > most of the download cases that we care about (audio, video, images) > [1]. It can be re-used for audio, video and images Microformats. The > examples support the word choice - "after following the process that is > linked to, you will have a proper /representation/ of the work described > by the hAudio/hVideo/hImage Microformat." > > Please show your support for this term, or if you do not support it > please note why and suggest an alternative word and argument. > > -- manu > > [1] > > http://wordnet.princeton.edu/perl/webwn?o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&s=representation&i=2&h=0100000000000#c > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070508/1cac7a54/attachment-0001.html From msporny at digitalbazaar.com Tue May 8 08:36:54 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue May 8 08:36:58 2007 Subject: [uf-new] An argument against 'fn' in hAudio (was: Second attempt at hAudio proposal) In-Reply-To: <463F3E3D.2090801@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> Message-ID: <46409916.2050607@digitalbazaar.com> Manu Sporny wrote: > - The use of 'fn' instead of 'work-title'. It has been proposed that 'fn' or 'n' be used instead of 'work-title', or 'title'. What follows is an argument against using 'fn' and 'n' for hAudio. Assumptions: - It is important that we choose the generic names that span all microformats carefully. - Our goal is to lower the cognitive load of website designers using Microformats by re-using terms that are semantically equivalent. Argument: fn is far too heavyweight for hAudio fn is short for 'full-name' and is grounded in the VCARD/hCard format. The sub-properties of 'fn' and 'n' are: family-name, given-name, additional-name, honorific-prefix, honorific-suffix [1]. These are all related to 'proper names' - none of them have any meaning when applied to hAudio. The optimization rules for interpreting 'fn' are quite complex [2], for example: "If 'FN' and 'ORG' are not the same (see previous section), and the value of the 'FN' property is exactly two words (separated by whitespace), and there is no explicit 'N' property, then the 'N' property is inferred from the 'FN' property. For 'FN's with either one word see below, and for three or more, the author MUST explicitly markup the 'N', except for the organization contact info case, see above (http://microformats.org/wiki/hcard#Organization_Contact_Info) for that." None of this applies to hAudio - and we don't want Microformat implementors confusing how to use 'fn' in hAudio and how to use 'fn' in hCard. It would be nice to use 'title' instead of 'work-title', but hCard has usurped the term to mean "job title, functional position or function of the object the vCard represents" [3]. This was a bad decision in hindsight as the definition of "title" should be far more generic. 'job-title' or 'function' should probably have been used in hCard instead. Unless a solid argument is presented for using 'fn' instead of 'work-title', the proposal will stay with 'work-title'. -- manu [1] http://microformats.org/wiki/hcard#Property_List [2] http://microformats.org/wiki/hcard#Implied_.22n.22_Optimization [3] http://www.ietf.org/rfc/rfc2426.txt From scott at makedatamakesense.com Tue May 8 08:44:01 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue May 8 08:44:13 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: <15996c030705080822p28a1eb87sfe64296c30035fbf@mail.gmail.com> References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> <15996c030705080822p28a1eb87sfe64296c30035fbf@mail.gmail.com> Message-ID: On May 8, 2007, at 10:22 AM, Chris Griego wrote: > rel-enclosure was ruled out because it's not always a download, but > sometimes a way to purchase, right? What if hAudio suggested the use > of rel-enclosure for downloads and rel-payment for ways to purchase? I think this is an excellent idea. In addition to re-using existing microformats, knowing whether a link is a direct download or a purchase form would allow tools to provide more useful options to users. -- Scott Reynen MakeDataMakeSense.com From brian.suda at gmail.com Tue May 8 08:47:13 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue May 8 08:47:15 2007 Subject: [uf-new] An argument against 'fn' in hAudio (was: Second attempt at hAudio proposal) In-Reply-To: <46409916.2050607@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> Message-ID: <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> On 5/8/07, Manu Sporny wrote: > Manu Sporny wrote: > > - The use of 'fn' instead of 'work-title'. > > It has been proposed that 'fn' or 'n' be used instead of 'work-title', > or 'title'. What follows is an argument against using 'fn' and 'n' for > hAudio. > > Assumptions: > > - It is important that we choose the generic names that span all > microformats carefully. > - Our goal is to lower the cognitive load of website designers using > Microformats by re-using terms that are semantically equivalent. > > Argument: fn is far too heavyweight for hAudio --- a disagree, FN is the lightest weight most flexible property. > fn is short for 'full-name' and is grounded in the VCARD/hCard format. > The sub-properties of 'fn' and 'n' are: family-name, given-name, > additional-name, honorific-prefix, honorific-suffix [1]. These are all > related to 'proper names' - none of them have any meaning when applied > to hAudio. --- N should NOT be considered, it has nothing to do with this conversation. hReview also uses FN for the FORMATTED NAME. FN is NOT full-name. FN was taken from VCARD, but the semantics are defined as: "The name of the object."[1] which has nothing to do with VCARD and can easily be reused in other formats. > The optimization rules for interpreting 'fn' are quite complex [2], for > example: > > "If 'FN' and 'ORG' are not the same (see previous section), and the > value of the 'FN' property is exactly two words (separated by > whitespace), and there is no explicit 'N' property, then the 'N' > property is inferred from the 'FN' property. For 'FN's with either one > word see below, and for three or more, the author MUST explicitly markup > the 'N', except for the organization contact info case, see above > (http://microformats.org/wiki/hcard#Organization_Contact_Info) for that." --- since you are NOT dealing with N and ORG, you can completely ignore all of this with no issues. > None of this applies to hAudio - and we don't want Microformat > implementors confusing how to use 'fn' in hAudio and how to use 'fn' in > hCard. --- these are two very different things. This is a non-issue. hCard parsers do onething, and you can defined Media parsers to do something completely different. FN is just a semantic value not defining parsing instructions, that is up to the format. > Unless a solid argument is presented for using 'fn' instead of > 'work-title', the proposal will stay with 'work-title'. --- i would say just the opposite. FN works, you need a strong argument on WHY we need to create YET ANOTHER property called 'work-title'? -brian [1] - http://microformats.org/wiki/classes -- brian suda http://suda.co.uk From scott at makedatamakesense.com Tue May 8 08:53:45 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue May 8 08:53:56 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: <620fa5c30705080822j2ce10e48l8ed1bc9e7533bc91@mail.gmail.com> References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> <620fa5c30705080822j2ce10e48l8ed1bc9e7533bc91@mail.gmail.com> Message-ID: On May 8, 2007, at 10:22 AM, Brad Hafichuk wrote: > As a runner-up, "source" seems to be acceptable, as we're used to > using "src" for image (and embeded) media. SOURCE is already a property in vCard [1], though it's not currently used in hCard. In vCard, it's the source of the *information* in the container, e.g. an LDAP URI, which I think is a slightly different meaning than the source of the *subject* of the container. hCard's class="url" is probably closer to the intended meaning here. SOURCE: "information how to find the source for the [container]" URL: "To specify a uniform resource locator associated with the object that the [container] refers to." [1] http://www.ietf.org/rfc/rfc2426.txt -- Scott Reynen MakeDataMakeSense.com From davidjanes at blogmatrix.com Tue May 8 09:06:14 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Tue May 8 09:06:21 2007 Subject: [uf-new] An argument against 'fn' in hAudio (was: Second attempt at hAudio proposal) In-Reply-To: <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> Message-ID: <21e523c20705080906y1278ca41j235f8d4e4fbdbe6@mail.gmail.com> On 5/8/07, Brian Suda wrote: > On 5/8/07, Manu Sporny wrote: > > Manu Sporny wrote: > > > - The use of 'fn' instead of 'work-title'. > > > > It has been proposed that 'fn' or 'n' be used instead of 'work-title', > > or 'title'. What follows is an argument against using 'fn' and 'n' for > > hAudio. > > > > Assumptions: > > > > - It is important that we choose the generic names that span all > > microformats carefully. > > - Our goal is to lower the cognitive load of website designers using > > Microformats by re-using terms that are semantically equivalent. > > > > Argument: fn is far too heavyweight for hAudio > > --- a disagree, FN is the lightest weight most flexible property. What Brian said: +1 Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From martin at weborganics.co.uk Tue May 8 10:41:40 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue May 8 10:41:13 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: <464080F5.4090402@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> Message-ID: <1178646100.27777.23.camel@localhost.localdomain> On Tue, 2007-05-08 at 09:53 -0400, Manu Sporny wrote: > Martin McEvoy wrote: > >> ----------------------------------------------------------------- > >> acquire > >> > >> Changed to be a class instead of a rel-attribute. There is still some > >> concern over the name 'acquire'. Primarily in that it doesn't pluralize > >> cleanly (it is a verb - it should probably be a noun?). > > > > could we use an adjective? "obtainable" > > > > > > > > Is it the same thing? I'd like to remove my support for obtainable, for "gain" http://www.answers.com/topic/gain To come into possession or use of; acquire: gained a small fortune in real estate; gained vital information about the enemy's plans. Buy Now coupled with one of rel="payment", rel="sample" or rel="enclosure" > > Does that mean we could add 'able' to the end of verbs to solve this > whole noun-verb issue for Microformat property names? > > acquirable? > > Ultimately, the contents of the 'acquire' element is a link to a > process. It may be a direct link to a download, but most of the > audio-info-examples contain a link to a checkout process of some kind. > It is difficult to get away from verbs since a 'process' is conducive to > being identified by a verb. > > Looking through all of the drafts on the Microformats site - all > property names are nouns. Whether this happened by accident or was > deliberate, there is a pattern emerging in the Microformats and that is: > > "We should use nouns for describing Microformat properties. Verbs > describe actions, and actions don't describe data. Microformats are > about describing data, not specifying actions on the data." > > Rather than try and identify the process, let's focus on the end result > of the process (a file sitting on your hard drive that you acquired from > the Internet). Here are the rename suggestions so far for hAudio 'acquire': > > obtainable > downloadable > acquireable > acquisition > representation > rendition > full-version > file > source > resource > asset > receivable > interpretation > embodiment > > There have been two votes for source (Frances, Paul), one for obtainable > (Martin), and one for representation (Manu). representation would be good to describe an Image, I'm not sure about a payment link? > > I'm pulling my support for 'acquire' (acquisition, acquirable) and > placing it behind 'representation'. Representation is the root term for > most of the download cases that we care about (audio, video, images) > [1]. It can be re-used for audio, video and images Microformats. The > examples support the word choice - "after following the process that is > linked to, you will have a proper /representation/ of the work described > by the hAudio/hVideo/hImage Microformat." > > Please show your support for this term, or if you do not support it > please note why and suggest an alternative word and argument. > > -- manu > > [1] > http://wordnet.princeton.edu/perl/webwn?o2=&o0=1&o7=&o5=&o1=1&o6=&o4=&o3=&s=representation&i=2&h=0100000000000#c > _______________________________________________ > 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/20070508/9f572b1a/smime.bin From brian.suda at gmail.com Tue May 8 10:50:48 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue May 8 10:50:54 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: <1178646100.27777.23.camel@localhost.localdomain> References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> <1178646100.27777.23.camel@localhost.localdomain> Message-ID: <21e770780705081050l407c8716re125bed2b76686fc@mail.gmail.com> On 5/8/07, Martin McEvoy wrote: > I'd like to remove my support for obtainable, for > > "gain" > > http://www.answers.com/topic/gain > > To come into possession or use of; acquire: gained a small fortune in > real estate; gained vital information about the enemy's plans. > > Buy Now > > coupled with one of rel="payment", rel="sample" or rel="enclosure" --- if are already having rel values, do you need to also have a 'wrapper' class of 'gain' or anything? just by the sementics of the rel value you can determine that it is a something that can be 'gained' or 'obtained'. Otherwise, you are adding additional un-needed microformat encodings. The only thing this prevents is to have a file inside a Media format that is for payment, but not part of the Media format. This is such an edge case that there is no need to have a class="gain" as well as the rel value. -brian -- brian suda http://suda.co.uk From tantek at cs.stanford.edu Tue May 8 12:11:17 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 8 12:10:55 2007 Subject: fn is formatted name (was Re: [uf-new] An argument against 'fn' in hAudio) In-Reply-To: <46409916.2050607@digitalbazaar.com> Message-ID: On 5/8/07 8:36 AM, "Manu Sporny" wrote: > fn is short for 'full-name' Not quite. In short, fn is short for formatted name. > and is grounded in the VCARD/hCard format. Yes, and per http://www.ietf.org/rfc/rfc2426.txt section 3.1.1: "the formatted text corresponding to the name of the object the vCard represents" Another way of saying formatted name, is how the name of the object is commonly displayed. As microformats are used to markup data that is *displayed* on the Web, this is actually quite relevant to not only hCard, and an audio-info microformat, but to *any* microformat which represents things and what they are called, including for example, books, movies, products etc. For example, "fn" really should be used in citation-brainstorming rather than 'title'[1]. > The sub-properties of 'fn' and 'n' are: family-name, given-name, > additional-name, honorific-prefix, honorific-suffix [1]. These are all > related to 'proper names' - none of them have any meaning when applied > to hAudio. Again, not quite. 'n' has those sub-properties yes. 'fn' has no subproperties, which renders the rest of the argument false. Thanks, Tantek [1] From msporny at digitalbazaar.com Tue May 8 12:20:19 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue May 8 12:20:22 2007 Subject: [uf-new] An argument against 'fn' in hAudio In-Reply-To: <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> Message-ID: <4640CD73.60705@digitalbazaar.com> Brian Suda wrote: >> None of this applies to hAudio - and we don't want Microformat >> implementors confusing how to use 'fn' in hAudio and how to use 'fn' in >> hCard. > > --- these are two very different things. This is a non-issue. hCard > parsers do onething, and you can defined Media parsers to do something > completely different. FN is just a semantic value not defining parsing > instructions, that is up to the format. You almost had me convinced until you said this. It seems very strange to me that something that is supposed to be 'semantically equivalent' is parsed in very different ways between two Microformats. If things are semantically equivalent, why aren't they parsed in the exact same way? To illustrate the implications of calling two things the same thing when they are different: Here's a duck, it quacks and floats on water. Here's another duck, it whinnies and gallops on land. If two things have to be parsed in different ways, how can they be semantically equivalent? I would have no problem with using 'fn' if it didn't have all of the parsing cruft from hCard. If something is parsed differently, isn't it intrinsically different? -- manu From msporny at digitalbazaar.com Tue May 8 12:53:11 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue May 8 12:53:15 2007 Subject: fn is formatted name (was Re: [uf-new] An argument against 'fn' in hAudio) In-Reply-To: References: Message-ID: <4640D527.7050401@digitalbazaar.com> Tantek ?elik wrote: > On 5/8/07 8:36 AM, "Manu Sporny" wrote: >> fn is short for 'full-name' > Not quite. In short, fn is short for formatted name. > >> and is grounded in the VCARD/hCard format. > Yes, and per http://www.ietf.org/rfc/rfc2426.txt section 3.1.1: > > "the formatted text corresponding to the name of the object the vCard > represents" > >> The sub-properties of 'fn' and 'n' are: family-name, given-name, >> additional-name, honorific-prefix, honorific-suffix [1]. These are all >> related to 'proper names' - none of them have any meaning when applied >> to hAudio. > > Again, not quite. 'n' has those sub-properties yes. > > 'fn' has no subproperties, which renders the rest of the argument false. Looks like I didn't understand what 'fn' really meant when constructing the argument against it. Getting your ass handed to you in a public forum is always a healthy exercise :) I'd still like a response to the statement Brian made about 'fn' in hCard and 'fn' in hAudio being "completely different". At this point, it looks like 'fn' (formatted name) will replace 'work-title' in hAudio (and video, and images). -- manu From scott at makedatamakesense.com Tue May 8 12:57:17 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue May 8 12:57:28 2007 Subject: [uf-new] An argument against 'fn' in hAudio In-Reply-To: <4640CD73.60705@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> Message-ID: <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> On May 8, 2007, at 2:20 PM, Manu Sporny wrote: > Brian Suda wrote: >>> None of this applies to hAudio - and we don't want Microformat >>> implementors confusing how to use 'fn' in hAudio and how to use >>> 'fn' in >>> hCard. >> >> --- these are two very different things. This is a non-issue. hCard >> parsers do onething, and you can defined Media parsers to do >> something >> completely different. FN is just a semantic value not defining >> parsing >> instructions, that is up to the format. > > You almost had me convinced until you said this. It seems very strange > to me that something that is supposed to be 'semantically > equivalent' is > parsed in very different ways between two Microformats. > > If things are semantically equivalent, why aren't they parsed in the > exact same way? Some Name is parsed the same in any microformat. But names of people are more complex than names of songs, so they have additional parsing rules to account for the additional markup options. That doesn't change the meaning of Some Name at all. > To illustrate the implications of calling two things the same thing > when > they are different: > > Here's a duck, it quacks and floats on water. Here's another duck, it > whinnies and gallops on land. Ducks and horses are two different things, but we use the same term, "animal," to refer to both. FN is a similarly generic term. > If two things have to be parsed in different ways, how can they be > semantically equivalent? The meaning is determined by the markup, not the parsing. > I would have no problem with using 'fn' if it didn't have all of the > parsing cruft from hCard. It doesn't. > If something is parsed differently, isn't it > intrinsically different? No. Every browser parsers a given HTML document differently, but the HTML document still means the same thing. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Tue May 8 13:20:56 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue May 8 13:20:59 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> Message-ID: <4640DBA8.1030806@digitalbazaar.com> Scott's argument was the final nail in the 'work-title' coffin. Work title has been changed to 'fn' and is reflected on the wiki: http://microformats.org/wiki/audio-info-proposal#Schema http://microformats.org/wiki/audio-info-proposal#Formatted_Name -- manu From andy at pigsonthewing.org.uk Tue May 8 13:55:55 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 8 13:57:24 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> <15996c030705080822p28a1eb87sfe64296c30035fbf@mail.gmail.com> Message-ID: In message , Scott Reynen writes >On May 8, 2007, at 10:22 AM, Chris Griego wrote: > >> rel-enclosure was ruled out because it's not always a download, but >> sometimes a way to purchase, right? What if hAudio suggested the use >> of rel-enclosure for downloads and rel-payment for ways to purchase? > >I think this is an excellent idea. In addition to re-using existing >microformats, knowing whether a link is a direct download or a >purchase form would allow tools to provide more useful options to >users. I can foresee problems. Suppose a publisher links to a third-party site, offering an audio track as a free sample (or vice versa). Later, that latter site decides to start charging for the track - how would the publisher know that their site is no longer correct? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue May 8 14:00:18 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 8 14:02:03 2007 Subject: [uf-new] An argument against 'fn' in hAudio (was: Second attempt at hAudio proposal) In-Reply-To: <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> Message-ID: In message <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com>, Brian Suda writes >FN works, you need a strong >argument on WHY we need to create YET ANOTHER property called >'work-title'? Because it describes something more specific (a "work", as opposed to a person). In similar fashion, "fn org" currently describes anything from say, a road junction to a football club. More specific names would enable places and organisations to have different, and therefore distinguishing, labels. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue May 8 14:08:16 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 8 14:09:25 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <4640DBA8.1030806@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> Message-ID: In message <4640DBA8.1030806@digitalbazaar.com>, Manu Sporny writes >Scott's argument was the final nail in the 'work-title' coffin. Work >title has been changed to 'fn' Thereby giving us:
    Roy Harper Bullinamingvase
    -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From tantek at cs.stanford.edu Tue May 8 14:22:15 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 8 14:21:51 2007 Subject: [uf-new] An argument against 'fn' in hAudio (was: Second attempt at hAudio proposal) In-Reply-To: Message-ID: On 5/8/07 2:00 PM, "Andy Mabbett" wrote: > In message > <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com>, Brian > Suda writes > >> FN works, you need a strong >> argument on WHY we need to create YET ANOTHER property called >> 'work-title'? > > Because it describes something more specific (a "work", as opposed to a > person). The "it describes something more specific" can be a good argument to propose a new name in general. Often times that specificity is already implied by the context, i.e. the root class name for the microformat (for an hAudio proposal vs. hCard), and thus it is actually more desirable to use a more generic term from a limited vocabulary for the properties, in order to keep that vocabulary as small as possible to lower the overall cognitive load of learning microformats in general, above and beyond learning just one. Also, there is no need to imply the specificity twice, once by context from the root, and another time in the name of the property itself. > In similar fashion, "fn org" currently describes anything from say, a > road junction to a football club. More specific names would enable > places and organisations to have different, and therefore > distinguishing, labels. The implied issue here is a good one to note, i.e. how to semantically distinguish a place vs. an org hCard. I've added it to hcard-issues. http://microformats.org/wiki/hcard-issues Thanks, Tantek From brad.hafichuk at gmail.com Tue May 8 14:30:31 2007 From: brad.hafichuk at gmail.com (Brad Hafichuk) Date: Tue May 8 14:30:35 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> <15996c030705080822p28a1eb87sfe64296c30035fbf@mail.gmail.com> Message-ID: <620fa5c30705081430q5fe92762n3bff320a7382d26f@mail.gmail.com> This kind of relates to something I was mulling over. If you link to a third party site, how do you guarantee that you don't get a 404 response? I can't think of any other solution short of periodically "pinging" that url and checking the response. In theory just checking the content-type and content-length from the request should give you enough information to at least highlight this as a problem. The argument could be made that if you're going to be relying on a third-party, then some form of formal arrangement should be made between the two parties. Cheers, Brad On 5/8/07, Andy Mabbett wrote: > > In message , > Scott Reynen writes > > >On May 8, 2007, at 10:22 AM, Chris Griego wrote: > > > >> rel-enclosure was ruled out because it's not always a download, but > >> sometimes a way to purchase, right? What if hAudio suggested the use > >> of rel-enclosure for downloads and rel-payment for ways to purchase? > > > >I think this is an excellent idea. In addition to re-using existing > >microformats, knowing whether a link is a direct download or a > >purchase form would allow tools to provide more useful options to > >users. > > I can foresee problems. > > Suppose a publisher links to a third-party site, offering an audio track > as a free sample (or vice versa). Later, that latter site decides to > start charging for the track - how would the publisher know that their > site is no longer correct? > > -- > Andy Mabbett > * Say "NO!" to compulsory ID Cards: > * Free Our Data: > * Are you using Microformats, yet: > ? > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070508/a256cbc6/attachment-0001.html From martin at weborganics.co.uk Tue May 8 15:07:31 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue May 8 15:07:04 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> Message-ID: <1178662051.29960.7.camel@localhost.localdomain> On Tue, 2007-05-08 at 22:08 +0100, Andy Mabbett wrote: > In message <4640DBA8.1030806@digitalbazaar.com>, Manu Sporny > writes > > >Scott's argument was the final nail in the 'work-title' coffin. Work > >title has been changed to 'fn' > > Thereby giving us: > >
    > > > > Roy Harper > > > > > Bullinamingvase > >
    I wandered when some one was going to pick up on this Andy you are correct we are not describing a person here we are describing a work or some kind although still technically an object so work-title or some derivative of is needed in this case. 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/20070508/c5ab333f/smime.bin From martin at weborganics.co.uk Tue May 8 15:24:58 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue May 8 15:24:30 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <1178662051.29960.7.camel@localhost.localdomain> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> <1178662051.29960.7.camel@localhost.localdomain> Message-ID: <1178663098.29960.13.camel@localhost.localdomain> On Tue, 2007-05-08 at 23:07 +0100, Martin McEvoy wrote: > On Tue, 2007-05-08 at 22:08 +0100, Andy Mabbett wrote: > > In message <4640DBA8.1030806@digitalbazaar.com>, Manu Sporny > > writes > > > > >Scott's argument was the final nail in the 'work-title' coffin. Work > > >title has been changed to 'fn' > > > > Thereby giving us: > > > >
    > > > > > > > > Roy Harper > > > > > > > > > > Bullinamingvase > > > >
    > > I wandered when some one was going to pick up on this > > Andy you are correct we are not describing a person here we are > describing a work or some kind although still technically an object > > so work-title or some derivative of is needed in this case. just a question for anyone that can answer I have been reading through this http://www.ietf.org/rfc/rfc2426.txt and I'm wondering can anyone expand on what x-name is? all I can gather its "Reserved for non-standard use" could it apply in this case? Martin > > 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/20070508/c25159fa/smime.bin From brad.hafichuk at gmail.com Tue May 8 15:42:41 2007 From: brad.hafichuk at gmail.com (Brad Hafichuk) Date: Tue May 8 15:42:45 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <1178663098.29960.13.camel@localhost.localdomain> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> <1178662051.29960.7.camel@localhost.localdomain> <1178663098.29960.13.camel@localhost.localdomain> Message-ID: <620fa5c30705081542x2ab2f334xa3dc8a4b1ff547d1@mail.gmail.com> >From what I can tell, the intention is to use the format X-something to describe a parameter that is not registered with IANA. Put differently, IANA reserves all keywords except for those starting with "X-". I haven't read-up on the work-title discussion as of yet...so no input as to whether this is applicable or not. Cheers, Brad On 5/8/07, Martin McEvoy wrote: > > On Tue, 2007-05-08 at 23:07 +0100, Martin McEvoy wrote: > > On Tue, 2007-05-08 at 22:08 +0100, Andy Mabbett wrote: > > > In message <4640DBA8.1030806@digitalbazaar.com>, Manu Sporny > > > writes > > > > > > >Scott's argument was the final nail in the 'work-title' coffin. Work > > > >title has been changed to 'fn' > > > > > > Thereby giving us: > > > > > >
    > > > > > > > > > > > > Roy Harper > > > > > > > > > > > > > > > Bullinamingvase > > > > > >
    > > > > I wandered when some one was going to pick up on this > > > > Andy you are correct we are not describing a person here we are > > describing a work or some kind although still technically an object > > > > so work-title or some derivative of is needed in this case. > > just a question for anyone that can answer > I have been reading through this http://www.ietf.org/rfc/rfc2426.txt > > and I'm wondering can anyone expand on what x-name is? all I can gather > its "Reserved for non-standard use" could it apply in this case? > > Martin > > > > Martin. > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070508/fc4fe634/attachment.html From scott at makedatamakesense.com Tue May 8 17:00:02 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue May 8 17:00:15 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> <15996c030705080822p28a1eb87sfe64296c30035fbf@mail.gmail.com> Message-ID: On May 8, 2007, at 3:55 PM, Andy Mabbett wrote: > I can foresee problems. > > Suppose a publisher links to a third-party site, offering an audio > track > as a free sample (or vice versa). Later, that latter site decides to > start charging for the track - how would the publisher know that their > site is no longer correct? They wouldn't without re-checking the links. But the same is true of every link on the web. For example, I could link to a site about salmon with the text "this is about fish" and then the linked content can change to something about whales and I would look like I don't realize that whales aren't fish. I think the truthfulness of assertions (e.g. "this is an audio file to download") over time is irrelevant to determining the best markup for making such assertions. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Wed May 9 07:22:37 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed May 9 07:22:40 2007 Subject: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties) In-Reply-To: References: <463F3E3D.2090801@digitalbazaar.com> <1178552184.18937.6.camel@localhost.localdomain> <464080F5.4090402@digitalbazaar.com> <15996c030705080822p28a1eb87sfe64296c30035fbf@mail.gmail.com> Message-ID: <4641D92D.7000307@digitalbazaar.com> Andy Mabbett wrote: > I can foresee problems. > > Suppose a publisher links to a third-party site, offering an audio track > as a free sample (or vice versa). Later, that latter site decides to > start charging for the track - how would the publisher know that their > site is no longer correct? Dangling links and website management are outside of the scope of the hAudio problem statement. This is an inherent problem with linking, isn't it? I don't see any other Microformat addressing this problem, nor do I think addressing this problem is a Microformat issue. -- manu From martin at weborganics.co.uk Wed May 9 07:57:43 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed May 9 07:57:17 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <4640DBA8.1030806@digitalbazaar.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> Message-ID: <1178722663.1907.17.camel@localhost.localdomain> On Tue, 2007-05-08 at 16:20 -0400, Manu Sporny wrote: > Scott's argument was the final nail in the 'work-title' coffin. Work > title has been changed to 'fn' and is reflected on the wiki: > > http://microformats.org/wiki/audio-info-proposal#Schema > > http://microformats.org/wiki/audio-info-proposal#Formatted_Name > > -- manu So how are we going to mark up work-title, I always thought that this term fitted quite nicely into the haudo proposal due to haudio's obvious similarities to hcard the work part I understood this to be the equivalent to type-work all haudio would come under the work classification, and title as in Mr, Mrs, President, Prime Minister, of course audio, art, video all have titles too. fn is good for the artist but not their art? as you would have two fn properties in one haudio. maybe the Artist and My Art It works but I don't know if you can have more than one word values for given-name. we clearly need to distinguish the artist from his art in some way. Thoughts ideas anyone? > > _______________________________________________ > 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/20070509/63482bc0/smime-0001.bin From scott at makedatamakesense.com Wed May 9 09:04:20 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed May 9 09:04:33 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <1178722663.1907.17.camel@localhost.localdomain> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> <1178722663.1907.17.camel@localhost.localdomain> Message-ID: <22B7AF50-0B9C-42B3-8B07-6F1557EE96B5@makedatamakesense.com> On May 9, 2007, at 9:57 AM, Martin McEvoy wrote: > fn is good for the artist but not their art? as you would have two fn > properties in one haudio. This is a parsing issue with a solution, so it shouldn't influence our choice of markup. Specifically, a solution is for parsers to recognize the context, i.e. hCard vs. hAudio, and apply the FN to the correct context. -- Scott Reynen MakeDataMakeSense.com From davidjanes at blogmatrix.com Wed May 9 09:17:42 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Wed May 9 09:17:46 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <22B7AF50-0B9C-42B3-8B07-6F1557EE96B5@makedatamakesense.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> <1178722663.1907.17.camel@localhost.localdomain> <22B7AF50-0B9C-42B3-8B07-6F1557EE96B5@makedatamakesense.com> Message-ID: <21e523c20705090917y18839a89s7b3d1574b2d748c2@mail.gmail.com> On 5/9/07, Scott Reynen wrote: > On May 9, 2007, at 9:57 AM, Martin McEvoy wrote: > > > fn is good for the artist but not their art? as you would have two fn > > properties in one haudio. > > This is a parsing issue with a solution, so it shouldn't influence > our choice of markup. Specifically, a solution is for parsers to > recognize the context, i.e. hCard vs. hAudio, and apply the FN to the > correct context. Exactly. For example, in hAtom "entry-title" can appear many times within a single "hfeed" -- the trick being, of course, the intermediary "hentry" nodes the distinguishes between them. Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From martin at weborganics.co.uk Wed May 9 10:55:42 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed May 9 10:55:18 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <21e523c20705090917y18839a89s7b3d1574b2d748c2@mail.gmail.com> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> <1178722663.1907.17.camel@localhost.localdomain> <22B7AF50-0B9C-42B3-8B07-6F1557EE96B5@makedatamakesense.com> <21e523c20705090917y18839a89s7b3d1574b2d748c2@mail.gmail.com> Message-ID: <1178733342.3232.9.camel@localhost.localdomain> On Wed, 2007-05-09 at 11:17 -0500, David Janes wrote: > On 5/9/07, Scott Reynen wrote: > > On May 9, 2007, at 9:57 AM, Martin McEvoy wrote: > > > > > fn is good for the artist but not their art? as you would have two fn > > > properties in one haudio. > > > > This is a parsing issue with a solution, so it shouldn't influence > > our choice of markup. Specifically, a solution is for parsers to > > recognize the context, i.e. hCard vs. hAudio, and apply the FN to the > > correct context. > > Exactly. For example, in hAtom "entry-title" can appear many times > within a single "hfeed" -- the trick being, of course, the > intermediary "hentry" nodes the distinguishes between them. > > Regards, etc... > hmm but haudio is the equivilent of a "hentry" its designed to fit into whatever may be hMedia , hentry only has one "entry-title" I guess haudio may be a little misleading as a name maybe It should be called vmedia or something. 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/20070509/aafb5cad/smime.bin From martin at weborganics.co.uk Wed May 9 11:04:30 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed May 9 11:04:08 2007 Subject: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio) In-Reply-To: <1178733342.3232.9.camel@localhost.localdomain> References: <463F3E3D.2090801@digitalbazaar.com> <46409916.2050607@digitalbazaar.com> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce@mail.gmail.com> <4640CD73.60705@digitalbazaar.com> <1A12DA8A-5BEB-4640-9987-E16AD3258C40@makedatamakesense.com> <4640DBA8.1030806@digitalbazaar.com> <1178722663.1907.17.camel@localhost.localdomain> <22B7AF50-0B9C-42B3-8B07-6F1557EE96B5@makedatamakesense.com> <21e523c20705090917y18839a89s7b3d1574b2d748c2@mail.gmail.com> <1178733342.3232.9.camel@localhost.localdomain> Message-ID: <1178733870.3232.13.camel@localhost.localdomain> On Wed, 2007-05-09 at 18:55 +0100, Martin McEvoy wrote: > On Wed, 2007-05-09 at 11:17 -0500, David Janes wrote: > > On 5/9/07, Scott Reynen wrote: > > > On May 9, 2007, at 9:57 AM, Martin McEvoy wrote: > > > > > > > fn is good for the artist but not their art? as you would have two fn > > > > properties in one haudio. > > > > > > This is a parsing issue with a solution, so it shouldn't influence > > > our choice of markup. Specifically, a solution is for parsers to > > > recognize the context, i.e. hCard vs. hAudio, and apply the FN to the > > > correct context. > > > > Exactly. For example, in hAtom "entry-title" can appear many times > > within a single "hfeed" -- the trick being, of course, the > > intermediary "hentry" nodes the distinguishes between them. > > > > Regards, etc... > > > > hmm but haudio is the equivilent of a "hentry" its designed to fit into > whatever may be hMedia , hentry only has one "entry-title" I guess > haudio may be a little misleading as a name maybe It should be called > vmedia or something. "maybe It should be called vmedia or something" can I withdraw that last statement. sorry Martin. > > 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/20070509/f716a31b/smime.bin From ryan at technorati.com Thu May 10 13:46:13 2007 From: ryan at technorati.com (Ryan King) Date: Thu May 10 13:46:17 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <4630A3E5.3090304@adaptavist.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> Message-ID: On Apr 26, 2007, at 7:06 AM, Guy Fraser wrote: > 1. XFN doesn't fit in to corporate environments... > > XFN can't really be used in corporate environments - in such > environments the Romantic category would instantly be removed > (making it a derivative work - see 3) and the remaining categories > don't provide enough relationships applicable to such environments > (eg. client, supplier, etc) which are very difficult to add (see 3 > and 4). There's nothing wrong with supporting only a subset of the standard. Those in corporate environments can easily leave out the romantic section in their implementations. > 2. Issues with existing XFN rel's... > > The "muse" should not be in the romantic category, full stop. I've > seen numerous people asking about this on lists (here and > elsewhere) and even in the wiki. Each time the simple fact that > "muse" doesn't belong in the romantic category is dodged by a non- > obvious definition of the romantic category (especially considering > the other things in that category) or the topic gets changed to a > discussion about "let's talk about the Romans...", etc. Why not > just move "muse" to a more logical category? Again, that would be a > derivative work (see 3). How does the mis-categorization of muse affect whether you can adopt it or not? You don't have to use the labels from the XFN profile in your applications. You don't even have to support all of the properties. > There are some conflicts/overlap of existing uF rels with these: > http://www.whatwg.org/specs/web-apps/current-work/#linkTypes (eg. > "contact" is defined differently by this document and doesn't seem > to match up with XFN's version). Is WHATWG somehow related to XFN > and microformats.org, which list of rel's takes precedence, who > owns the copyright, etc? I'm pretty new to all this so I don't know > how all these things fit together. Well, unless you're using HTML5, this is current irrelevant. Also, there are people who span both communities who are working on convergence. Remember, HTML5/WA is a draft. > ... > 4. The community seems restrictive... > > It's not possible to suggest new rel's without research and real- > world examples but corporates tend not to adopt things unless > there's something already in place. > > To get corporates to try something, they need to see that others > are trying it (generally speaking) and that there is some existing > community drive behind it. But that's not possible because I can't > submit ideas to XFN until after the corporates have tried it. It's > a chicken-and-egg situation. > > I can't make my own derivative work of XFN to try with some clients > because a) they won't try it if it doesn't fit in with existing > stuff and b) how do I get authorisation to make a derivative work, > especially when I can't provide examples of real-world use...? I'm not sure this is a big problem. Just because some people won't experiment with new markup techniques does not mean we can't find enough people to do such experimenting. > ... > > 6. Summary... > > With the licensing, patenting and conflicting versions of the same > things are making me *very* hesitant to get involved. > > When I was told about uF's, they were presented to me by friends as > a community of developers coming up with ways to descrive things > using semantically correct markup in a human friendly format. > However, I'm getting an increasingly strong feeling of an > environment which is very restrictive and divergent. I agree, the community is restrictive, but this is done on purpose, so that we can be productive and create useful formats. But, I don't know what you mean by 'divergent'? Are you saying that not everyone agrees? If so then I think that's obvious. We're not here to get everyone to agree. > -ryan From ryan at technorati.com Thu May 10 13:49:21 2007 From: ryan at technorati.com (Ryan King) Date: Thu May 10 13:49:25 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <46320927.4000901@adaptavist.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <46320927.4000901@adaptavist.com> Message-ID: <189A41C9-63AB-4D1A-84A2-0FD7D78A94D5@technorati.com> On Apr 27, 2007, at 8:31 AM, Guy Fraser wrote: > Frances Berriman wrote: >> >> What would you envision doing with supplier/client etc. type >> relationships? > > In corporate environments, professional relationships need to be > more descriptive so that managers can more easily locate suitable > staff for projects. Eg. You could quickly build up a team that has > worked with a particular customer/supplier/project before. > >> 2. Issues with existing XFN rel's... >> >> We discussed this in IRC a while back (I don't have time to dig >> through the logs) but it was pretty much the consensus that muse IS >> mis-categorised as romantic and should be (and is already used as) a >> non-romantic relationship to describe anyone who is of inspiration >> etc. The current problem is only that the documentation hasn't been >> updated to reflect this better (probably will be done when/if XFN >> gets >> updated as a whole). > > As the discussions in IRC aren't logged anywhere (or even pasted in > to the wiki as far as I can tell) there is no record of that > information. Anyone working with XFN would generally be unaware of > the future direction. Again, it's all very closed. > >>> >>> It is not clear _who_ owns the copyright or patent. Is it >>> microformats.org, one of the authors, technorati, etc? >> 3. Licensing and patenting issues... >> >> Technorati doesn't own microformats. I believe most 'formats show a >> CC declaration on the appropriate wiki page. > > Yup, that's a show stopper for most corporates. A cc-by-nd* is a > killer - if you can't make derivative works, game over. Even a cc- > by is a show stopper for most corporates because lots of banks, > etc., generally have an internal policy that prevents them using > anything along the lines of the GPL, cc-by, etc. First, it's the specifications that would be licensed under CC, not the format itself. Second, Your assertion that ND specifications won't work for 'corporates', while possible true, is unfounded here. As someone who hasn't worked in corporate environments it would be helpful if you could more clearly explain the objections (in concrete terms with examples). -ryan From ryan at technorati.com Thu May 10 13:52:21 2007 From: ryan at technorati.com (Ryan King) Date: Thu May 10 13:52:25 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <46320E52.2060100@adaptavist.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <4630B0E9.3060504@digitalbazaar.com> <46320E52.2060100@adaptavist.com> Message-ID: <3586F5E3-CE26-4988-87B2-8B0A11EA4846@technorati.com> On Apr 27, 2007, at 8:53 AM, Guy Fraser wrote: > Manu Sporny wrote: >> I can definitely sympathize with your viewpoints. I don't think the >> licensing and patenting is a concern, read on... >> > > It's very much an issue. Let's say your a company and you want to > use some software. You're told that it's copyrighted - so you > *need* a license to use that stuff by default. But then you find > that nobody really owns that copyright - um, that's an odd > situation. At this point most corporates choose some alternative > solution. > > Then you find out that it might be patented, or that there is at > least intent to patent, but because it's not currently patented you > cannot guarantee what sort of patent it will go under. Run for the > trees! What if they patent it and you are using it and then you get > sued? What if you've made derivative works or if your systems or > procedures have somehow become dependant on it? > > This stuff can't just be shrugged off. Sorry. > >> I'll be blunt: every community has a group of jerks and a group of >> people that actually get the work done. While people may seem to be >> jerk-ish on the list, most of them have good intentions. >> > > I never said there were any jerks. What I was trying to say is that > the process used for uF's is inherently closed - eg, using IRC > where unless you're on there all day every day you have no idea > what's been discussed, using mediawiki which inherently hides > content if it's not linked from a page you can find of if you don't > know what to search for (having to use the random page feature is > just insane), having to show real-world examples before things will > even be considered, etc. If you have suggestions for improving our communication technology, I'd be glad to hear it. > ... > >> I feel your pain... but, there is a great deal of good to be found in >> this community. > > Yes, uF community is making some nice stuff. I am worried that the > process may lead to divergence though - eg. it would seem logical > to me to have a uF that describes blog posts, comments, pages, > etc., all in the same format because they all share mostly the same > data. This would then allow mapping tools, navigation aides, etc., > to be far more consistent and easier to develop and maintain. But > the process effectively forces people to start new uFs for new > things because they find it so hard to get existing uF's to adapt. If you have specific feedback about specific formats that are 'hard to adapt', we should document it, unless that happens, though, it's hard to do anything about your statements. -ryan From ryan at technorati.com Thu May 10 13:58:28 2007 From: ryan at technorati.com (Ryan King) Date: Thu May 10 13:58:31 2007 Subject: [uf-new] Legal implications of using Microformats In-Reply-To: <463210FE.7050604@adaptavist.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <4630B0E9.3060504@digitalbazaar.com> <4631FE2D.50208@digitalbazaar.com> <463210FE.7050604@adaptavist.com> Message-ID: On Apr 27, 2007, at 9:04 AM, Guy Fraser wrote: > Hiya, > > Manu Sporny wrote: >> Would the mandatory placement of all examples, formats, >> brainstorming, >> proposals, and drafts under a Creative Commons Attribution-Share >> Alike >> 3.0 License go towards solving that problem? >> >> * It would allow for the commercial and non-commercial use of the >> format. >> * It would ensure that people could contribute without worrying about >> copyright assertions from other authors. >> > > Uhm, not really. > > 1. Share alike is still a problem for some corporates. This is the > whole reason why a growing number of organisations now run > screaming when they see LGPL, GPL, cc-* I'm certainly an outsider to the corporate world, but this has not been my impression. Please give us more specific reasons and examples so that we can avoid getting the same reaction from such organizations. > 2. Um, possibly. But again, why not just release under New BSD or > similar certified open source license. New BSD still requires > attribution which everyone is fine with IMHO. Having each uF under > a New BSD license and having a contributors page should make > everything crystal clear and very tempting for adoption by big > companies. > > ... > > Again, if things were released under New BSD or similar certified > open source license, there would be no problem. "Everything you put > on this site will be released under New BSD license - if you don't > like that, don't do it". IANAL, but AFAICT the BSD license, whether new or old is only suited for source code, not for documentation. Since we're talking about the licensing of specifications, not code, I'm not sure a BSD license would be appropriate. > I'm still waiting for someone to properly address these 2 key issues: > > 1. Why not just release the existing uF stuff as certified open > source? Completely remove licensing issues from the mix? Making material open source does not completely remove licensing. Open source still requires licensing. Public Domain is the only situation I know of that would eliminate licensing (but that's only in the US, I believe other nations have more complicated definitions of PD). -ryan From supercanadian at gmail.com Thu May 10 14:00:35 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu May 10 14:00:45 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <46320927.4000901@adaptavist.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <46320927.4000901@adaptavist.com> Message-ID: <84ce626f0705101400x70a194c5p74256e7d673e1b5f@mail.gmail.com> Hello, On 4/27/07, Guy Fraser wrote: > Frances Berriman wrote: > > > > What would you envision doing with supplier/client etc. type > > relationships? > > In corporate environments, professional relationships need to be more > descriptive so that managers can more easily locate suitable staff for > projects. Eg. You could quickly build up a team that has worked with a > particular customer/supplier/project before. > > > 2. Issues with existing XFN rel's... > > > > We discussed this in IRC a while back (I don't have time to dig > > through the logs) but it was pretty much the consensus that muse IS > > mis-categorised as romantic and should be (and is already used as) a > > non-romantic relationship to describe anyone who is of inspiration > > etc. The current problem is only that the documentation hasn't been > > updated to reflect this better (probably will be done when/if XFN gets > > updated as a whole). > > As the discussions in IRC aren't logged anywhere (or even pasted in to > the wiki as far as I can tell) there is no record of that information. > Anyone working with XFN would generally be unaware of the future > direction. Again, it's all very closed. > > >> > >> It is not clear _who_ owns the copyright or patent. Is it > >> microformats.org, one of the authors, technorati, etc? > > 3. Licensing and patenting issues... > > > > Technorati doesn't own microformats. I believe most 'formats show a > > CC declaration on the appropriate wiki page. > > Yup, that's a show stopper for most corporates. A cc-by-nd* is a killer > - if you can't make derivative works, game over. Even a cc-by is a show > stopper for most corporates because lots of banks, etc., generally have > an internal policy that prevents them using anything along the lines of > the GPL, cc-by, etc. Wow... banks are certainly different. Most the corporations I've dealt with have GPL stuff all over the place. (I've even had some clients seek out GPL stuff.) Just out of curiousity, why do banks (you know of) have a problem with GPL? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From ryan at technorati.com Thu May 10 14:05:25 2007 From: ryan at technorati.com (Ryan King) Date: Thu May 10 14:05:29 2007 Subject: [uf-new] Currency Proposal (and Measurements) In-Reply-To: <4630FFD5.4050607@digitalbazaar.com> References: <4630FFD5.4050607@digitalbazaar.com> Message-ID: <6719BAE8-8669-4BC0-9C75-50FF96026B69@technorati.com> On Apr 26, 2007, at 1:39 PM, Manu Sporny wrote: > Emil Thies wrote: >> Or do you think instead of an abstract design-patter, measurement >> should be a format where you can use all kind of dimensions and their >> units? > > It looks like measurement should be a new Microformat. If it is > successful, it would probably replace the currency Microformat. > > Before we start speculating, however, there should be a great > number of > examples gathered on how people are publishing measurements online. It > should be pretty easy to classify these things. Measurements usually > only have a couple of attributes (unit, scale, value). > > What everybody has been re-iterating is: > > The first step of the Microformats process is to collect as many > examples as you can find. > > The second step of the Microformats process is to analyze all those > examples and try to find some similar data that is published in all > cases. > > Then you go on to collecting formats, brainstorming and finally > creating > a proposal. It is always done in this order because it is the most > logical way to proceed with a standard. This is a great summarization of the process for creating a new microformat. Also note that at any of these stages it's possible to decide that a new format is not neccessary because there are existing formats or techniques that suffice. Finally, part of the process is to document previous and current efforts trying to solve the same problems. For example, the meter element in HTML5/WA1[1]. -ryan 1. http://www.whatwg.org/specs/web-apps/current-work/#meter From supercanadian at gmail.com Thu May 10 14:21:54 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu May 10 14:21:58 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> Message-ID: <84ce626f0705101421y5bb4d954ld8a9fd38724ddf38@mail.gmail.com> Hello Ryan, On 5/10/07, Ryan King wrote: [...] > > When I was told about uF's, they were presented to me by friends as > > a community of developers coming up with ways to descrive things > > using semantically correct markup in a human friendly format. > > However, I'm getting an increasingly strong feeling of an > > environment which is very restrictive and divergent. > > I agree, the community is restrictive, but this is done on purpose, > so that we can be productive and create useful formats. > > But, I don't know what you mean by 'divergent'? Are you saying that > not everyone agrees? If so then I think that's obvious. We're not > here to get everyone to agree. He's probably confusing Microformats with Semantic HTML. (I.e., thinking he needs our blessing to make Semantic HTML. Obviously he doesn't.) -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___________________________________________________________________________ From gfraser at adaptavist.com Thu May 10 16:21:03 2007 From: gfraser at adaptavist.com (Guy Fraser) Date: Thu May 10 16:52:16 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <189A41C9-63AB-4D1A-84A2-0FD7D78A94D5@technorati.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <46320927.4000901@adaptavist.com> <189A41C9-63AB-4D1A-84A2-0FD7D78A94D5@technorati.com> Message-ID: <4643A8DF.3050800@adaptavist.com> Ryan King wrote: > First, it's the specifications that would be licensed under CC, not > the format itself. You can't have one without the other. Why not just release under New BSD license and solve this whole problem? > Second, Your assertion that ND specifications won't work for > 'corporates', while possible true, is unfounded here. As someone who > hasn't worked in corporate environments it would be helpful if you > could more clearly explain the objections (in concrete terms with > examples). It's similar to the issues many corporates now have with GPL (which is why dual-licensing models work so well for corporates these days) and even clause 6 (from memory) of the LGPL. An example... Corporates want to bundle microformat related systems with their commercial products = problem. Corporates want to make a proprietary derivative work for internal use only = problem (primarily because it's very unclear as to who owns the copyright). Corporates have to go through all kinds of legal cruft when anything like GPL, LGPL, cc-by-nd, etc., is involved. There is also the vastly worrying submarine patent issue with microformats as well. For example, corporates could develop systems that come to rely on a microformat and sell those systems to clients and then later find that they are infringing a patent (or even just an unworkable copyright such as cc-by-nd) and then both the company and their clients find themselves dealing with very expensive and time consuming law suits. Many microforamts state that they are likely to be released under a "royalty free patent" - it's *really* vital to note that from a legal standpoint there are some absolute show-stopper problems with this: 1. Intent does not guarantee what will happen - intent can change over time. From a legal standpoint, this means any work based on microformats is playing "russian roulette" with the future status of that microformat - if it suddenly became patented, companies would face lawsuits. 2. Royalty free != free of cost. Royalty free means that when you have a license you can distribute your works under that license at no extra cost until the license expires. It does not mean that getting said license is free and the patent holder can charge anything they want. Guy From martin at weborganics.co.uk Thu May 10 16:57:47 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu May 10 16:57:16 2007 Subject: [uf-new] hAudio Test Message-ID: <1178841467.14854.10.camel@localhost.localdomain> I have set up a small test page marked up as haudio the purpose is.. well to see how it all may fit together. It uses a "real world" example from the audio-info examples page I have also tryed to mark up a collection of sorts using the class include pattern. I have left all my notes to try and explain what I am trying to attempt so you will need firebug or read the source. It would be nice if someone could say they get what I am trying to do or that it doesn't make sense so comments and criticism are welcome. http://weborganics.co.uk/haudio Kind Regards Martin McEvoy. -------------- 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/20070511/cf14a46c/smime.bin From gfraser at adaptavist.com Thu May 10 16:58:59 2007 From: gfraser at adaptavist.com (Guy Fraser) Date: Thu May 10 17:00:11 2007 Subject: [uf-new] Legal implications of using Microformats In-Reply-To: References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <4630B0E9.3060504@digitalbazaar.com> <4631FE2D.50208@digitalbazaar.com> <463210FE.7050604@adaptavist.com> Message-ID: <4643B1C3.6070004@adaptavist.com> Ryan King wrote: > I'm certainly an outsider to the corporate world, but this has not > been my impression. Please give us more specific reasons and examples > so that we can avoid getting the same reaction from such organizations. Such licenses, especially in "late-binding" languages like Java, infect other licenses such as ASL, New BSD, etc. The LGPL is badly written, particularly clause 6. The thing that confuses me most about this community is why they don't just release the stuff under New BSD or ASL license and remove this issue once and for all so that it never crops up again and we can all get on with our lives? Why does the community *want* to cause these problems or even allow them to exist? Is there some ulterior money making motive behind them or is there some firm legal reasoning that I'm missing here? (Oh, as for the issue of New BSD license being mainly for code and not documentation/specifications that I missed somewhere in this thread, fair point. However, why would people then be using things like cc-by-nd instead of cc-by? I'm thinking specifically of XFN here). > Making material open source does not completely remove licensing. Open > source still requires licensing. Public Domain is the only situation I > know of that would eliminate licensing (but that's only in the US, I > believe other nations have more complicated definitions of PD). Again, fair point - however, there are still the issues of "we might be patenting this" and the fact that nobody has a clue as to who owns the licenses or patents, etc. The licensing is only one part of the microformat problem - the ownership and patenting is a bigger worry IMHO, but should still not detract from the debate regarding licensing. I see no problem with a cc-by license for specifications, but it must be made clear that the license is specifically for the specifications. There is a grey area in my opinion whereby the cc-by overlaps with any actual implementations based on the specification. There is also the XFN microformat which for some reason looks like it's going to be done under a cc-by-nd (so people can't even extend XFN in their own systems without prior written permission from the owner of that license, but we don't even know who has the authority to give that permission!). The "we might be releasing under a royalty free patent" is the biggest worry of all :p Guy From gfraser at adaptavist.com Thu May 10 16:33:29 2007 From: gfraser at adaptavist.com (Guy Fraser) Date: Thu May 10 17:11:02 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <84ce626f0705101400x70a194c5p74256e7d673e1b5f@mail.gmail.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <46320927.4000901@adaptavist.com> <84ce626f0705101400x70a194c5p74256e7d673e1b5f@mail.gmail.com> Message-ID: <4643ABC9.2070002@adaptavist.com> Charles Iliya Krempeaux wrote: > Hello, > > Wow... banks are certainly different. > > Most the corporations I've dealt with have GPL stuff all over the place. > > (I've even had some clients seek out GPL stuff.) > > Just out of curiousity, why do banks (you know of) have a problem with > GPL? I was just using banks as a reference because I've come across these issues in that sector. It's mainly anyone who deals with software and a growing number of banks and other companies have in-house development teams. If they integrate microformats in to their systems, or in any way become dependant on them, licensing and patenting become really big issues. If you've got a key software system or process that's dependant on microformats then you find you didn't understand the license properly (clause 6 in LGPL, from vague memory, is a good example) then you find yourself experiencing a great deal of pain. Most companies are unaware of the sorts of issues that can arise, until it's too late and they find themselves facing lawsuits. Lots of things released under GPL also have a commercial license to get round this problem. Again, here is an issue - if there was a commercial license for microformats then who exactly would the money go to? Would each contributor for the microformat in question get a share of the revenues? How would the size of share be determined? Who would take the initial payment and how would they be audited? Are you seriously telling me that *any* organisation would seek out something with these credentials: * No clear owner - could be microformats.org, could be the authors, some company like Technorati, etc. Nobody really knows. * Only a statement of intent regarding the copyright - "we might use a license like this" - yeah, that fills me with confidence * A statement that it might be under a royalty free (which is not necessarily cost free) patent, but then again it might be under a normal patent and commercially exploited as much as possible. The list goes on and on. I'm still utterly amazed that people are staring this issue in the face and rather than dealing with it they are trying to brush it under the carpet. It's even more worrying that there is a community here who are devoting some of their time and energy in to microformats that are ultimately going to make other people money. Crazy situation. Still, there's nothing stopping people setting up their own independent initiatives to replace microformats with something more "open" and with far less risk submarine patents ;) Guy From gfraser at adaptavist.com Thu May 10 17:08:11 2007 From: gfraser at adaptavist.com (Guy Fraser) Date: Thu May 10 18:02:46 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <3586F5E3-CE26-4988-87B2-8B0A11EA4846@technorati.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <4630B0E9.3060504@digitalbazaar.com> <46320E52.2060100@adaptavist.com> <3586F5E3-CE26-4988-87B2-8B0A11EA4846@technorati.com> Message-ID: <4643B3EB.1070308@adaptavist.com> Ryan King wrote: >> I never said there were any jerks. What I was trying to say is that >> the process used for uF's is inherently closed - eg, using IRC where >> unless you're on there all day every day you have no idea what's been >> discussed, using mediawiki which inherently hides content if it's not >> linked from a page you can find of if you don't know what to search >> for (having to use the random page feature is just insane), having to >> show real-world examples before things will even be considered, etc. > > If you have suggestions for improving our communication technology, > I'd be glad to hear it. Heh, don't even get me started on the process :p As for media wiki, I must simply be missing some key bit of navigation - is there actually an index to all pages or a site map somewhere that lists *all* pages? The only way I could find things that weren't directly linked from some other page I could find was to use the (almost unbelievable) "Random Page" link?! :) I've since learnt that the IRC discussions are logged but I've not yet found a way to search them. >>> I feel your pain... but, there is a great deal of good to be found in >>> this community. >> >> Yes, uF community is making some nice stuff. I am worried that the >> process may lead to divergence though - eg. it would seem logical to >> me to have a uF that describes blog posts, comments, pages, etc., all >> in the same format because they all share mostly the same data. This >> would then allow mapping tools, navigation aides, etc., to be far >> more consistent and easier to develop and maintain. But the process >> effectively forces people to start new uFs for new things because >> they find it so hard to get existing uF's to adapt. > > If you have specific feedback about specific formats that are 'hard to > adapt', we should document it, unless that happens, though, it's hard > to do anything about your statements. Again, the process hinders this. One can stare the obvious convergent solution in the face for a great deal of time, but will have to wait until real world examples of that solution are available before they can properly get through the process rather than just being a side-note lost in time. By the time convergent solutions do emerge (primarily due to people realising they don't have enough hours in the day for more and more divergent approaches to similar problems) you would have a wide array of incumbent divergent microformats to deal with and, well, it's just not worth the hassle IMHO. Having an incubator somewhere where new ideas could be discussed outside the process would be very useful IMHO. Hmmm... I might just set one up to see what happens... Anyone interested? It would be a great way to more openly discuss ideas without "the process" getting in the way all the time. Guy From gfraser at adaptavist.com Thu May 10 17:33:18 2007 From: gfraser at adaptavist.com (Guy Fraser) Date: Thu May 10 18:17:46 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> Message-ID: <4643B9CE.2030809@adaptavist.com> Ryan King wrote: > On Apr 26, 2007, at 7:06 AM, Guy Fraser wrote: >> 1. XFN doesn't fit in to corporate environments... >> >> XFN can't really be used in corporate environments - in such >> environments the Romantic category would instantly be removed (making >> it a derivative work - see 3) and the remaining categories don't >> provide enough relationships applicable to such environments (eg. >> client, supplier, etc) which are very difficult to add (see 3 and 4). > > There's nothing wrong with supporting only a subset of the standard. > Those in corporate environments can easily leave out the romantic > section in their implementations. Apart from the fact that in the case of XFN it's under a cc-by-nd license = no derivatives. Removing the romantic category, or adding new categories, would be seen as a derivative work would it not? Who exactly would we see written authorisation from to enable us to freely make derivative works? >> 2. Issues with existing XFN rel's... >> >> The "muse" should not be in the romantic category, full stop. I've >> seen numerous people asking about this on lists (here and elsewhere) >> and even in the wiki. Each time the simple fact that "muse" doesn't >> belong in the romantic category is dodged by a non-obvious definition >> of the romantic category (especially considering the other things in >> that category) or the topic gets changed to a discussion about "let's >> talk about the Romans...", etc. Why not just move "muse" to a more >> logical category? Again, that would be a derivative work (see 3). > > How does the mis-categorization of muse affect whether you can adopt > it or not? You don't have to use the labels from the XFN profile in > your applications. You don't even have to support all of the properties. I didn't say it would stop me adopting XFN (the licensing, patenting, ownership of XFN, especially when used in a Java application, is what's stopping me using XFN). I was merely giving an example of an issue with XFN (and in light of how easy it would be resolve, I cannot understand why it hasn't been resolved already) and also that by me re/moving it would effectively be a derivative work "here's XFN without "muse" or with it moved somewhere more appropriate". >> There are some conflicts/overlap of existing uF rels with these: >> http://www.whatwg.org/specs/web-apps/current-work/#linkTypes (eg. >> "contact" is defined differently by this document and doesn't seem to >> match up with XFN's version). Is WHATWG somehow related to XFN and >> microformats.org, which list of rel's takes precedence, who owns the >> copyright, etc? I'm pretty new to all this so I don't know how all >> these things fit together. > > Well, unless you're using HTML5, this is current irrelevant. Also, > there are people who span both communities who are working on > convergence. Remember, HTML5/WA is a draft. I am aware of that. I also spotted Tantek's name in the acknowledgements section so I was aware of this. That being said, my question still remains: That draft will eventually become HTML 5 - what happens if it's definition of "contact" conflicts with that of XFN? > I'm not sure this is a big problem. Just because some people won't > experiment with new markup techniques does not mean we can't find > enough people to do such experimenting. I've seen several people commenting on how they couldn't get an idea added to a uF because of lack of real-world examples. For example, a page cannot be created in the wiki until there are real world examples unless my understanding is incorrect. Should the process not also accommodate uF's that by their mere existence would facilitate new ideas and solutions? >> 6. Summary... >> >> With the licensing, patenting and conflicting versions of the same >> things are making me *very* hesitant to get involved. >> >> When I was told about uF's, they were presented to me by friends as a >> community of developers coming up with ways to descrive things using >> semantically correct markup in a human friendly format. However, I'm >> getting an increasingly strong feeling of an environment which is >> very restrictive and divergent. > > I agree, the community is restrictive, but this is done on purpose, so > that we can be productive and create useful formats. I agree that there has to be some restriction - maybe an incubator is needed elsewhere for new ideas to be thrashed out in a less restricted manner and then, once more fully rounded and thought out, presented to the uF community? > But, I don't know what you mean by 'divergent'? Are you saying that > not everyone agrees? If so then I think that's obvious. We're not here > to get everyone to agree. I answered this in another post - search your inbox for "component uF" (for want of a much better term). Guy From gfraser at adaptavist.com Thu May 10 17:33:27 2007 From: gfraser at adaptavist.com (Guy Fraser) Date: Thu May 10 18:17:49 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <84ce626f0705101421y5bb4d954ld8a9fd38724ddf38@mail.gmail.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <84ce626f0705101421y5bb4d954ld8a9fd38724ddf38@mail.gmail.com> Message-ID: <4643B9D7.1020004@adaptavist.com> Charles Iliya Krempeaux wrote: > He's probably confusing Microformats with Semantic HTML. > > (I.e., thinking he needs our blessing to make Semantic HTML. > Obviously he doesn't.) > Uhm, nope, the difference between the two is clear for all to see (or at least I would think so). Take these things for example: pages, blog posts, comments, attachments There are components of all of them that are similar such as author, created date, version, who updated them, participants, etc. Currently each one would get it's own compound uF and this would likely lead to divergence. Why not create a uF that's somewhere between an elemental and a compound - a "component" uf? - ie. it would be a bit more detailed and with slightly wider and more generic scope than your average elemental, but would get used in several compound uFs. By doing this you would simplify implementation (as several compound uFs would be able to share the common attributes from the component uF) = easier for people to learn and re-use in different contexts. You would also have simpler tools (eg. mapping tools, navigation aides, etc) as they'd be able to take advantage of the common elements. From msporny at digitalbazaar.com Thu May 10 20:39:32 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 10 20:39:38 2007 Subject: [uf-new] Legal implications of using Microformats In-Reply-To: References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <4630B0E9.3060504@digitalbazaar.com> <4631FE2D.50208@digitalbazaar.com> <463210FE.7050604@adaptavist.com> Message-ID: <4643E574.3050107@digitalbazaar.com> Guy Fraser wrote: > Many microforamts state that they are likely to be released under a > "royalty free patent" - it's *really* vital to note that from a legal > standpoint there are some absolute show-stopper problems with this: > > 1. Intent does not guarantee what will happen - intent can change over > time. From a legal standpoint, this means any work based on > microformats is playing "russian roulette" with the future status of > that microformat > - if it suddenly became patented, companies would face lawsuits. > > 2. Royalty free != free of cost. Royalty free means that when you hava > license you can distribute your works under that license at no extra > cost until the license expires. It does not mean that getting said > license is free and the patent holder can charge anything they want. Guy (and others interested in this topic), I had a very long phone conversation with Rohit Khare about these topics last week. There are two issues here: Copyrights and Patents. It is my belief that we have convinced Rohit that there could be copyright issues regarding Microformats. He has stated that he will address our concerns directly via the wiki. This will happen after he has deliberated with some of the other principals in the Microformats.org group. I'm supposed to bug him about it after two weeks have passed if the changes haven't been made to the wiki regarding the copyright concerns. I was not successful in convincing him that there were potential patent issues with the authors of particular Microformats. He said that he would attempt to clarify those issues via the wiki as well. Let's wait off a bit on the copyright and patent discussion until they've been able to address the issue in the wiki. They have two weeks to do it and if there are still issues after the wiki has been updated, we could begin discussion on it again. The parties that are responsible for these things are aware that there are issues and they're working on fixing them. -- manu From scott at makedatamakesense.com Fri May 11 04:48:33 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri May 11 04:48:45 2007 Subject: [uf-new] XFN - Professionals Network microformat In-Reply-To: <4643B3EB.1070308@adaptavist.com> References: <46279082.1070008@adaptavist.com> <4630A3E5.3090304@adaptavist.com> <4630B0E9.3060504@digitalbazaar.com> <46320E52.2060100@adaptavist.com> <3586F5E3-CE26-4988-87B2-8B0A11EA4846@technorati.com> <4643B3EB.1070308@adaptavist.com> Message-ID: <70EA5447-91A7-49F0-81EF-39087F3630F4@makedatamakesense.com> On May 10, 2007, at 7:08 PM, Guy Fraser wrote: > Heh, don't even get me started on the process :p As for media wiki, > I must simply be missing some key bit of navigation - is there > actually an index to all pages or a site map somewhere that lists > *all* pages? The only way I could find things that weren't directly > linked from some other page I could find was to use the (almost > unbelievable) "Random Page" link?! :) http://microformats.org/wiki/Special:Allpages > I've since learnt that the IRC discussions are logged but I've not > yet found a way to search them. Google seems to work okay for this, e.g.: http://www.google.com/search?q=site:http://rbach.priv.at/Microformats- IRC/%20hcard > Again, the process hinders this. One can stare the obvious > convergent solution in the face for a great deal of time, but will > have to wait until real world examples of that solution are > available before they can properly get through the process rather > than just being a side-note lost in time. This is a common misunderstanding, and I recently added it to the FAQ: http://microformats.org/wiki/faq#Q._What_if_I_can.27t_find_real- world_examples_of_a_standard_I.27d_like_to_propose.3F We need to find real world examples of the *problem*, not necessarily the solution. If we can't find examples of the problem, that's often a good indication that it's not a widespread problem, so not a good candidate for a widespread solution. -- Scott Reynen MakeDataMakeSense.com From scott at makedatamakesense.com Fri May 11 05:38:25 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri May 11 05:38:37 2007 Subject: [uf-new] hAudio Test In-Reply-To: <1178841467.14854.10.camel@localhost.localdomain> References: <1178841467.14854.10.camel@localhost.localdomain> Message-ID: On May 10, 2007, at 6:57 PM, Martin McEvoy wrote: > It would be nice if someone could say they get what I am trying to > do or > that it doesn't make sense so comments and criticism are welcome. > > http://weborganics.co.uk/haudio > Aural style sheets aren't supported by most screen readers, so this will be read aloud. More generally, if data isn't appropriate for humans, it doesn't belong in a microformat. Microformats are for humans first. > 4.99 What is the purpose of the title here? It looks redundant. > > > Fifty Million People Can't > Be Wrong > It's also the job title of our hCard, which looks like an unintended consequence to using an established class name to communicate a new meaning. >
    This item-collection markup looks redundant, as the exact same relationship can be inferred from song-album markup. > > Duration: 3:41 > I don't understand this. It looks like humans are being told one thing and machines another. Also, why is this going into the note of the hCard? Is this hCard for the song or the musician? Songs don't need hCards, and musicians don't need song durations in their notes. > > Publisher: This looks wrong. The contributor should be the hCard, not the role. That's probably enough for now. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Fri May 11 06:31:00 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri May 11 06:31:05 2007 Subject: [uf-new] hAudio Test In-Reply-To: References: <1178841467.14854.10.camel@localhost.localdomain> Message-ID: <46447014.5080207@digitalbazaar.com> Scott Reynen wrote: > On May 10, 2007, at 6:57 PM, Martin McEvoy wrote: > >> It would be nice if someone could say they get what I am trying to do or >> that it doesn't make sense so comments and criticism are welcome. >> >> http://weborganics.co.uk/haudio I agree with most of Scott's feedback. In addition: > hcalendar is used to mark up published events. We don't need something as heavyweight as hcalendar to mark up the published date. The examples don't support the need for anything more heavyweight than just 'published-date' with the use of a simple datetime-design-pattern. > - Fifty Million People Can't Be > Wrong Why doesn't the text "- Fifty Million People Can't Be Wrong" show up on the rendered HTML page? Also note that implementation for hcollection parsers (what you are proposing) is going to be complex. The parsers will have to keep a global list of identifiers around and map back to the tag after the entire page has been parsed. Perhaps it would be cleaner if implemented like so:
    ...
    ...
    
    Remember, though, the 'id=' approach has been argued against in the past: http://microformats.org/discuss/mail/microformats-new/2007-April/000202.html -- manu From martin at weborganics.co.uk Fri May 11 10:57:03 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 11 10:56:31 2007 Subject: [uf-new] hAudio Test In-Reply-To: References: <1178841467.14854.10.camel@localhost.localdomain> Message-ID: <1178906223.18235.44.camel@localhost.localdomain> On Fri, 2007-05-11 at 07:38 -0500, Scott Reynen wrote: > On May 10, 2007, at 6:57 PM, Martin McEvoy wrote: > > > It would be nice if someone could say they get what I am trying to > > do or > > that it doesn't make sense so comments and criticism are welcome. > > > > http://weborganics.co.uk/haudio > > > > > Aural style sheets aren't supported by most screen readers, so this > will be read aloud. More generally, if data isn't appropriate for > humans, it doesn't belong in a microformat. Microformats are for > humans first. > > > 4.99 you are right of course should be 4 pounds, 99 pence or 4.99 > > What is the purpose of the title here? It looks redundant. > > > > > > > Fifty Million People Can't > > Be Wrong > > > > It's also the job title of our hCard, which looks like an unintended > consequence to using an established class name to communicate a new > meaning. title has an unintended consequence here you are right. this is the collection title. > > >
    > > This item-collection markup looks redundant, as the exact same > relationship can be inferred from song-album markup. you are the expert here. :) maybe I'm just not being clear, this is what I am trying to do example,
    My Stamp Book
    A stamp. I'm thinking that all this markup isn't necessary to define a collection maybe it will work with just the class includes, I personally don't know that's why I ask all you guys. > > > > > Duration: 3:41 > > > > I don't understand this. It looks like humans are being told one > thing and machines another. Also, why is this going into the note of > the hCard? Is this hCard for the song or the musician? Songs don't > need hCards, and musicians don't need song durations in their notes. kind of experimental and you are right for machines and people but not so clear this is supposed to act like a track marker. we were asked to design this microformat for a machine or machines. Songbird is one. change to this: 3:41 music downloads or purchases do have all kids of notes, bit-rate, file-size, duration, It maybe unnecessary? just trying to point prasers to a useful part of a page > > > > > Publisher: > > This looks wrong. The contributor should be the hCard, not the role. I don't agree. we have more than one contributor to an album Artists, Publishers, Distributors, Management, p.r., songwriters, the list goes on... this says the contributor role is the Publisher? > > That's probably enough for now. help!! ;) Martin. > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > 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/20070511/ace26eb5/smime.bin From martin at weborganics.co.uk Fri May 11 11:07:44 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 11 11:07:16 2007 Subject: [uf-new] hAudio Test In-Reply-To: <46447014.5080207@digitalbazaar.com> References: <1178841467.14854.10.camel@localhost.localdomain> <46447014.5080207@digitalbazaar.com> Message-ID: <1178906864.18235.55.camel@localhost.localdomain> On Fri, 2007-05-11 at 09:31 -0400, Manu Sporny wrote: > Scott Reynen wrote: > > On May 10, 2007, at 6:57 PM, Martin McEvoy wrote: > > > >> It would be nice if someone could say they get what I am trying to do or > >> that it doesn't make sense so comments and criticism are welcome. > >> > >> http://weborganics.co.uk/haudio > > I agree with most of Scott's feedback. In addition: > > > hcalendar is used to mark up published events. > > We don't need something as heavyweight as hcalendar to mark up the > published date. The examples don't support the need for anything more > heavyweight than just 'published-date' with the use of a simple > datetime-design-pattern. > > > - Fifty Million People Can't Be > > Wrong > > Why doesn't the text "- Fifty Million People Can't Be Wrong" show up on > the rendered HTML page? I hid it with the style sheet, class includes don't normally have text in the anchors but I'm not happy with that some how, people who tab around a lot like me just get empty meaningless links > > Also note that implementation for hcollection parsers (what you are > proposing) is going to be complex. > > The parsers will have to keep a global list of identifiers around and > map back to the tag after the entire page has been parsed. Perhaps it > would be cleaner if implemented like so: > >
    ...
    > ... >
    > >
    much cleaner yes > > Remember, though, the 'id=' approach has been argued against in the past: It has yes I dont think the class include pattern works without it? > > http://microformats.org/discuss/mail/microformats-new/2007-April/000202.html > > -- manu > _______________________________________________ > 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/20070511/20648557/smime.bin From martin at weborganics.co.uk Fri May 11 11:15:10 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 11 11:14:38 2007 Subject: [uf-new] hAudio Test In-Reply-To: <46447014.5080207@digitalbazaar.com> References: <1178841467.14854.10.camel@localhost.localdomain> <46447014.5080207@digitalbazaar.com> Message-ID: <1178907310.18235.63.camel@localhost.localdomain> On Fri, 2007-05-11 at 09:31 -0400, Manu Sporny wrote: > Scott Reynen wrote: > > On May 10, 2007, at 6:57 PM, Martin McEvoy wrote: > > > >> It would be nice if someone could say they get what I am trying to do or > >> that it doesn't make sense so comments and criticism are welcome. > >> > >> http://weborganics.co.uk/haudio > > I agree with most of Scott's feedback. In addition: > > > hcalendar is used to mark up published events. > > We don't need something as heavyweight as hcalendar to mark up the > published date. The examples don't support the need for anything more > heavyweight than just 'published-date' with the use of a simple > datetime-design-pattern. no I guess not, Although sometimes the release of an album can be quite an event, I don't see why we cant mark this up as hcal, I didn't think it would be to much in this scenario. > > > - Fifty Million People Can't Be > > Wrong > > Why doesn't the text "- Fifty Million People Can't Be Wrong" show up on > the rendered HTML page? > > Also note that implementation for hcollection parsers (what you are > proposing) is going to be complex. > > The parsers will have to keep a global list of identifiers around and > map back to the tag after the entire page has been parsed. Perhaps it > would be cleaner if implemented like so: > >
    ...
    > ... >
    > >
    > > Remember, though, the 'id=' approach has been argued against in the past: > > http://microformats.org/discuss/mail/microformats-new/2007-April/000202.html > > -- manu > _______________________________________________ > 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/20070511/4af8bb76/smime.bin From scott at makedatamakesense.com Fri May 11 11:43:22 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri May 11 11:43:37 2007 Subject: [uf-new] hAudio Test In-Reply-To: <1178906223.18235.44.camel@localhost.localdomain> References: <1178841467.14854.10.camel@localhost.localdomain> <1178906223.18235.44.camel@localhost.localdomain> Message-ID: <32DF4BFD-1993-445F-BC5C-2ED4342D7539@makedatamakesense.com> On May 11, 2007, at 12:57 PM, Martin McEvoy wrote: >>> >>> Publisher: >> >> This looks wrong. The contributor should be the hCard, not the role. > > I don't agree. we have more than one contributor to an album Artists, > Publishers, Distributors, Management, p.r., songwriters, the list goes > on... Those are all people and organizations with different roles. The roles themselves are not contributing. > this says the contributor role is the Publisher? Not exactly. What I'm suggesting is this: > > Publisher: > Ferret Music > This says the contributor is an organization named "Ferret Music" with a role of "Publisher." Your current markup says is that the contributor is the role of Publisher. Roles don't contribute; organizations (and people) contribute. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Fri May 11 11:45:16 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 11 11:44:43 2007 Subject: [uf-new] hAudio Test In-Reply-To: References: <1178841467.14854.10.camel@localhost.localdomain> Message-ID: <1178909116.18235.66.camel@localhost.localdomain> Updated to reflect Manu and Scott's advice. Comments? welcome Martin. On Fri, 2007-05-11 at 07:38 -0500, Scott Reynen wrote: > On May 10, 2007, at 6:57 PM, Martin McEvoy wrote: > > > It would be nice if someone could say they get what I am trying to > > do or > > that it doesn't make sense so comments and criticism are welcome. > > > > http://weborganics.co.uk/haudio > > > > > Aural style sheets aren't supported by most screen readers, so this > will be read aloud. More generally, if data isn't appropriate for > humans, it doesn't belong in a microformat. Microformats are for > humans first. > > > 4.99 > > What is the purpose of the title here? It looks redundant. > > > > > > > Fifty Million People Can't > > Be Wrong > > > > It's also the job title of our hCard, which looks like an unintended > consequence to using an established class name to communicate a new > meaning. > > >
    > > This item-collection markup looks redundant, as the exact same > relationship can be inferred from song-album markup. > > > > > Duration: 3:41 > > > > I don't understand this. It looks like humans are being told one > thing and machines another. Also, why is this going into the note of > the hCard? Is this hCard for the song or the musician? Songs don't > need hCards, and musicians don't need song durations in their notes. > > > > > Publisher: > > This looks wrong. The contributor should be the hCard, not the role. > > That's probably enough for now. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > 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/20070511/32358d62/smime-0001.bin From martin at weborganics.co.uk Fri May 11 11:55:51 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 11 11:55:24 2007 Subject: [uf-new] hAudio Test In-Reply-To: <32DF4BFD-1993-445F-BC5C-2ED4342D7539@makedatamakesense.com> References: <1178841467.14854.10.camel@localhost.localdomain> <1178906223.18235.44.camel@localhost.localdomain> <32DF4BFD-1993-445F-BC5C-2ED4342D7539@makedatamakesense.com> Message-ID: <1178909751.18235.71.camel@localhost.localdomain> On Fri, 2007-05-11 at 13:43 -0500, Scott Reynen wrote: > On May 11, 2007, at 12:57 PM, Martin McEvoy wrote: > > >>> > >>> Publisher: > >> > >> This looks wrong. The contributor should be the hCard, not the role. > > > > I don't agree. we have more than one contributor to an album Artists, > > Publishers, Distributors, Management, p.r., songwriters, the list goes > > on... > > Those are all people and organizations with different roles. The > roles themselves are not contributing. > > > this says the contributor role is the Publisher? > > Not exactly. What I'm suggesting is this: > > > > > Publisher: > > Ferret Music > > > > This says the contributor is an organization named "Ferret Music" > with a role of "Publisher." Your current markup says is that the > contributor is the role of Publisher. Roles don't contribute; > organizations (and people) contribute Right I am a bit slow sometimes. changed to reflect this point. thanks Scott Martin. > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > 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/20070511/a000994d/smime.bin From martin at weborganics.co.uk Fri May 11 15:47:09 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri May 11 15:46:36 2007 Subject: [uf-new] hAudio Test In-Reply-To: <1178906864.18235.55.camel@localhost.localdomain> References: <1178841467.14854.10.camel@localhost.localdomain> <46447014.5080207@digitalbazaar.com> <1178906864.18235.55.camel@localhost.localdomain> Message-ID: <1178923629.20339.53.camel@localhost.localdomain> On Fri, 2007-05-11 at 19:07 +0100, Martin McEvoy wrote: > On Fri, 2007-05-11 at 09:31 -0400, Manu Sporny wrote: > > Scott Reynen wrote: > > > On May 10, 2007, at 6:57 PM, Martin McEvoy wrote: > > > > > >> It would be nice if someone could say they get what I am trying to do or > > >> that it doesn't make sense so comments and criticism are welcome. > > >> > > >> http://weborganics.co.uk/haudio > > > > I agree with most of Scott's feedback. In addition: > > > > > hcalendar is used to mark up published events. > > > > We don't need something as heavyweight as hcalendar to mark up the > > published date. The examples don't support the need for anything more > > heavyweight than just 'published-date' with the use of a simple > > datetime-design-pattern. > > > > > - Fifty Million People Can't Be > > > Wrong > > > > Why doesn't the text "- Fifty Million People Can't Be Wrong" show up on > > the rendered HTML page? > > I hid it with the style sheet, class includes don't normally have text > in the anchors but I'm not happy with that some how, people who tab > around a lot like me just get empty meaningless links > > > > > Also note that implementation for hcollection parsers (what you are > > proposing) is going to be complex. > > > > The parsers will have to keep a global list of identifiers around and > > map back to the tag after the entire page has been parsed. Perhaps it > > would be cleaner if implemented like so: > > > >
    ...
    > > ... > >
    > > > >
    > > much cleaner yes > > > > > Remember, though, the 'id=' approach has been argued against in the past: > > > It has yes I dont think the class include pattern works without it? Its supposed to reflect the class include method used in hresume the id attribute is acceptable in this case, the hresume example is to save time repeating n given-name family-name. http://microformats.org/wiki/hresume#Job_Titles the reason I am using it is to link the item to a collection. at the moment class include only works for links within a page so I had to make sure a link to the collection was included
    ...
    Artist: Boys Night Out
    Album: **type here is used as the collection type** **title here is used as the collection title** Fifty Million People Can't Be Wrong **this is the link to our collection**
    ...
    big chunk of code right may be too much for parsers? 1 2 are you sure this shouldn't be class include or is this a new method I/we are proposing? the good thing about haudio is much of it is re used from existing mF's I believe item must be used a separate class so it can be used to include information about the item I am adding to the collection e.g in simple terms:
    My Stamp Book
    
    Penny Black
    I guess its more like a design pattern for collections of anything really I didnt use

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

Internal and With-Client Events

Internal and With-Client Events

Internal and With-Client Events

Internal and With-Client Events

Internal and class="vcalendar">With-Client Events

Internal > and With-Client Events

Internal > and With-Client Events

Album Title

Album Title