From tantek at cs.stanford.edu Fri Feb 1 02:22:08 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Feb 1 02:20:35 2008 Subject: [uf-discuss] Digg joins DataPortability Project (Microformats mentioned) In-Reply-To: <479FDFE4.6040904@digitalbazaar.com> Message-ID: On 1/29/08 6:24 PM, "Manu Sporny" wrote: > Digg has joined the DataPortability[1] Project: > > http://blog.digg.com/?p=108 > >> From the piece: > > "Just this week, we added MicroID, a Microformat that lets you prove to > other services that you own your Digg user profile." > > Since when was "MicroID" a Microformat? Reading through the spec, it > does some very non-microformatty things: > > 5 Manu you are correct, MicroID is *not* a microformat. It did not follow the process, and violates numerous microformats principles. It can however be described as an attempt to represent some meaning in semantic HTML (although storing such potentially arbitrary data values in the class attribute is an anti-pattern). Thus it is at best a poshformat and I will list it there. http://microformats.org/wiki/poshformats > It's great that they're doing the whole data portability thing, but > looks like they're not quite sure about the details yet? Anyone know > anybody at Digg that could shed some light on where they're going with > all of this? Previous to the PR about DataPortability, Digg had already implemented a bunch of microformats support like XFN rel="me". I expect Digg to continue to implement microformats support independent of any PR efforts / announcements. Thanks, Tantek From msporny at digitalbazaar.com Fri Feb 1 07:46:58 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Feb 1 07:47:02 2008 Subject: [uf-discuss] Digg joins DataPortability Project (Microformats mentioned) In-Reply-To: References: Message-ID: <47A33EF2.4070105@digitalbazaar.com> Tantek ?elik wrote: > Manu you are correct, MicroID is *not* a microformat. It did not follow the > process, and violates numerous microformats principles. I've been in contact with Steve Williams, Digg's Technical Lead for Infrastructure Development, and he's been very open to discussion. We've since cleared up the fact that MicroID is not a Microformat and I explained a bit about the uF process. He was very open to discussing the issue and has since fixed the blog entry: http://blog.digg.com/?p=108 Steve got the impression that MicroID is a Microformat from the microid.org blog, which states: "MicroID: A Microformat for Digital Identity" I have contacted Jeremie Miller and Peter Saint-Andre (authors for the current MicroID IETF document) to politely let them know about the differences between a Microformat and the work that they have done. I have also invited them to put MicroID through the uF process or create an RDFa vocabulary. I'll let this list know when I have gotten a reply from them. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Intro to the Semantic Web in 6 minutes (video) http://blog.digitalbazaar.com/2007/12/26/semantic-web-intro From tantek at cs.stanford.edu Fri Feb 1 08:46:05 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Feb 1 08:44:34 2008 Subject: [uf-discuss] Dublin Core as a microformat (was: Re: xfn and biographies) In-Reply-To: Message-ID: On 1/30/08 4:16 PM, "Ben Ward" wrote: > Is that the only problem we'd be trying to solve in making a Dublin > Core microformat? Simply taking an existing format (like Dublin core) and reusing its vocabulary as class names is insufficient to make a microformat. microformats are based first and foremost on existing *content* publishing behaviors, not first on existing *markup*, nor first on existing *formats*. Only after existing *content* publishing behaviors are documented and implied schema are thus determined does it make sense to document previous attempts at formats for that type of content, and look at re-using *some* of their vocabulary that maps to the implied schema determined by the documented content publishing patterns. Since this has come up a few times in the past (there seem to be lots of folks that want to repurpose a previous format, no matter the actual utility or use cases, into HTML, now that microformats has demonstrated the usefulness of doing so), I've written up a process FAQ entry on this, and expanded further upon it there. Thanks, Tantek From andy at pigsonthewing.org.uk Sat Feb 2 05:00:30 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Feb 2 05:02:01 2008 Subject: [uf-discuss] n-optimisation: not for "role" Message-ID: The "n" optimisation rules (nickname, fn) should not apply where the fn is also the role: Webmaster: Duty Manager: since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name. I'll add this to -issues. -- Andy Mabbett From bjonkman at sobac.com Sat Feb 2 09:13:56 2008 From: bjonkman at sobac.com (Bob Jonkman) Date: Sat Feb 2 09:14:57 2008 Subject: [uf-discuss] Calais: a POSH project? Message-ID: <47A45E84.28396.5C5CC96@bjonkman.sobac.com> Via Techdirt [1] I found an interesting project called OpenCalais [2]. It seems designed to take arbitrary text documents and spit out semantic RDF. There's absolutely no mention of microformats on the OpenCalais web site, but I can see incorporating microformat markup into the output. And, of course, any effort at making the Web more POSH is A Good Thing. The site seems sparse on working code or examples, and I haven't even tried to download the developer package (needs a "developer key" -- not so Open, IMHO) [1] http://techdirt.com/articles/20080131/115224140.shtml [2] http://www.opencalais.com/ --Bob. -- -- -- -- Bob Jonkman http://sobac.com/sobac/ SOBAC Microcomputer Services Voice: +1-519-669-0388 6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413 Software --- Office & Business Automation --- Consulting From guillaume at lebleu.org Sat Feb 2 18:39:35 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Sat Feb 2 18:39:38 2008 Subject: [uf-discuss] Calais: a POSH project? In-Reply-To: <47A45E84.28396.5C5CC96@bjonkman.sobac.com> References: <47A45E84.28396.5C5CC96@bjonkman.sobac.com> Message-ID: <47A52967.1050904@lebleu.org> Bob Jonkman wrote: > Via Techdirt [1] I found an interesting project called OpenCalais [2]. It seems designed to > take arbitrary text documents and spit out semantic RDF. > > There's absolutely no mention of microformats on the OpenCalais web site, but I can see > incorporating microformat markup into the output. And, of course, any effort at making the > Web more POSH is A Good Thing. > Bob, thanks for the link, given the RDF output, I would imagine RDFa or eRDF would be more straightforward for them to add than microformats. > The site seems sparse on working code or examples, and I haven't even tried to download the > developer package (needs a "developer key" -- not so Open, IMHO) > I gave it a quick try. Seems to me very specific to financial/business news, but the roadmap says the 3rd party extensibility to other domains will be available later this year. More: http://lebleu.org/blog/2008/02/02/kicking-the-tires-with-opencalais/ Guillaume From mattsches at gmail.com Sun Feb 3 02:21:06 2008 From: mattsches at gmail.com (Mattsches) Date: Sun Feb 3 02:21:10 2008 Subject: [uf-discuss] Folksr is here (again) In-Reply-To: <44B061E5-6ADE-42FB-A639-01C746EB4D98@artweb-design.de> References: <44B061E5-6ADE-42FB-A639-01C746EB4D98@artweb-design.de> Message-ID: <107cffa30802030221h31e68cd5v5f17dc0372480614@mail.gmail.com> Hi Sven, I have several vote-for links on my site (http://www.numblog.de/). Yet, when I enter the URL on folksr, it tells me that it ignores my votings (although your parser correctly detected them). Can you explain why this is the case? Best - Matthias 2008/1/16, Sven Fuchs : > I introduced folksr.de as a first, highly experimental stab at an > application for distributed votings using the vote-link Microformat > quite some time ago to this list. > > # Distributed votings: folksr is here (again) ... > > I've finally come around to resurrect folksr from being pretty > stalled. I've done a complete rewrite and changed some of the way it > works to incorporate various learnings from the first, experimental > version. I've tried to keep things as basic as possible for now and > omitted everything that I felt is not necessary to get a simple, yet > useful tool going. > > In a nutshell: Folksr aggregates vote-links when the target URL of a > vote-link has been registered for a voting on folksr.de (i.e. it is > not required to link to folksr.de to get a vote in). There are two > types of votings (called 'opinions' and 'polls'). Folksr relies solely > on OpenID for sign-in. > > # How can I get you involved? > > I'd highly appreciate your feedback, suggestions, criticism, > support ... and of course ... participation and help. > > I'd particularly like to ask you folks for suggestions and help to get > some initial "real" votings and usage going. > > What could possibly be done to motivate you folks to try folksr and > publish a vote? What topics would be interesting enough? What else? > > # What's next? > > Aside from real usage which I think is really the most important thing > for folksr to evolve now, the next important thing might be to further > work on the presentation and interface design. > > I feel folksr is way to text-laden and doesn't communicate its own > purpose very well. I will continue to try to improve that. Suggestions > are very welcome. > > Unfortunately, as a programmer, I am pretty much an all-fingers-thumbs > moron when it comes to logos, graphics and stuff like that. So I also > very much appreciate every single bit of help here. > > Also I plan to add the following features in the near future: > > - plugins for some blog engines for pinging folksr about new votes > when published (Chris Messina suggested the term "voteback" which I > think is a perfect match, thanks Chris!) > - a timemachinesque history to review past states of votings and > charts to visualize a voting's history (initially suggested by Brian > Suda) > - tagging for votings (also suggested by Brian Suda) > > # Some links > > What is Folksr? > http://folksr.de/about > > How folksr works > http://folksr.de/votelinks > > FAQ > http://folksr.de/faq > > Announcement on my blog (somewhat extended version of this mail) > http://www.artweb-design.de/2008/1/16/folksr-is-here-again-distributed-votings-using-microformats > > > > > -- > sven fuchs svenfuchs@artweb-design.de > artweb design http://www.artweb-design.de > gr?nberger 65 + 49 (0) 30 - 47 98 69 96 (phone) > d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile) > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mail at tobyinkster.co.uk Sun Feb 3 04:05:54 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Feb 3 04:15:43 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" References: Message-ID: <2ang75-8r4.ln1@ophelia.g5n.co.uk>

We have three branches in London, including our head office in Kensington:

  • 123 Oxford Street
  • 5 Kensington High Street
  • 1 Pall Mall
The order of the space-delimited class attributes should be considered significant -- that is, in the content referred to by #baz is logically included as the last child of the element, but in , it is logically included as the first child. Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors. If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'. I shall add to the Wiki momentarily... -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 4 days, 18:02.] Looking Ahead to PHP 6 http://tobyinkster.co.uk/blog/2008/01/29/php6/ From mail at tobyinkster.co.uk Sun Feb 3 04:34:28 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Feb 3 05:01:16 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> Message-ID: Toby A Inkster wrote: > The order of the space-delimited class attributes should be considered > significant -- that is, in the content referred > to by #baz is logically included as the last child of the element, > but in , it is logically included as the first > child. > > I shall add to the Wiki momentarily... Wikied here: http://microformats.org/wiki/include-pattern-strawman Also fleshed out to include an example where included data is placed in the middle of its parent element rather than at the beginning or end. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 4 days, 18:50.] Looking Ahead to PHP 6 http://tobyinkster.co.uk/blog/2008/01/29/php6/ From mattsches at gmail.com Sun Feb 3 08:27:31 2008 From: mattsches at gmail.com (Matthias Gutjahr) Date: Sun Feb 3 08:33:53 2008 Subject: [uf-discuss] Folksr is here (again) In-Reply-To: <0541A792-45D6-41B8-BFFB-809DE08143DD@artweb-design.de> References: <44B061E5-6ADE-42FB-A639-01C746EB4D98@artweb-design.de> <107cffa30802030221h31e68cd5v5f17dc0372480614@mail.gmail.com> <0541A792-45D6-41B8-BFFB-809DE08143DD@artweb-design.de> Message-ID: <107cffa30802030827q5b946c5bp22090018d2a3423b@mail.gmail.com> Ok, I get it, this answers my question. - Matthias 2008/2/3, Sven Fuchs : > Hi Matthias, > > thanks for the feedback. > > Folksr needs to identify a voting (poll, opinion) to assign your > votes. It does this by looking at the href attribute of your vote > links. If it can't find a voting (in its local database) for a vote it > will ignore it. > > You can create a voting (like "What's you favorite NuJazz label?" or > whatever context you actually refer to with your vote links) here: http://folksr.de/votings > > Folksr will then aggregate your vote links accordingly. > > Does this answer your questions? > > I will try to make the message that folksr issues when it ignores a > vote more understandable and perhaps add a link to the FAQ. > > Thanks again! > > > Am 03.02.2008 um 11:21 schrieb Mattsches: > > > Hi Sven, > > > > I have several vote-for links on my site (http://www.numblog.de/). > > Yet, when I enter the URL on folksr, it tells me that it ignores my > > votings (although your parser correctly detected them). Can you > > explain why this is the case? > > > > Best > > - Matthias > > > > 2008/1/16, Sven Fuchs : > >> I introduced folksr.de as a first, highly experimental stab at an > >> application for distributed votings using the vote-link Microformat > >> quite some time ago to this list. > >> > >> # Distributed votings: folksr is here (again) ... > >> > >> I've finally come around to resurrect folksr from being pretty > >> stalled. I've done a complete rewrite and changed some of the way it > >> works to incorporate various learnings from the first, experimental > >> version. I've tried to keep things as basic as possible for now and > >> omitted everything that I felt is not necessary to get a simple, yet > >> useful tool going. > >> > >> In a nutshell: Folksr aggregates vote-links when the target URL of a > >> vote-link has been registered for a voting on folksr.de (i.e. it is > >> not required to link to folksr.de to get a vote in). There are two > >> types of votings (called 'opinions' and 'polls'). Folksr relies > >> solely > >> on OpenID for sign-in. > >> > >> # How can I get you involved? > >> > >> I'd highly appreciate your feedback, suggestions, criticism, > >> support ... and of course ... participation and help. > >> > >> I'd particularly like to ask you folks for suggestions and help to > >> get > >> some initial "real" votings and usage going. > >> > >> What could possibly be done to motivate you folks to try folksr and > >> publish a vote? What topics would be interesting enough? What else? > >> > >> # What's next? > >> > >> Aside from real usage which I think is really the most important > >> thing > >> for folksr to evolve now, the next important thing might be to > >> further > >> work on the presentation and interface design. > >> > >> I feel folksr is way to text-laden and doesn't communicate its own > >> purpose very well. I will continue to try to improve that. > >> Suggestions > >> are very welcome. > >> > >> Unfortunately, as a programmer, I am pretty much an all-fingers- > >> thumbs > >> moron when it comes to logos, graphics and stuff like that. So I also > >> very much appreciate every single bit of help here. > >> > >> Also I plan to add the following features in the near future: > >> > >> - plugins for some blog engines for pinging folksr about new votes > >> when published (Chris Messina suggested the term "voteback" which I > >> think is a perfect match, thanks Chris!) > >> - a timemachinesque history to review past states of votings and > >> charts to visualize a voting's history (initially suggested by Brian > >> Suda) > >> - tagging for votings (also suggested by Brian Suda) > >> > >> # Some links > >> > >> What is Folksr? > >> http://folksr.de/about > >> > >> How folksr works > >> http://folksr.de/votelinks > >> > >> FAQ > >> http://folksr.de/faq > >> > >> Announcement on my blog (somewhat extended version of this mail) > >> http://www.artweb-design.de/2008/1/16/folksr-is-here-again-distributed-votings-using-microformats > >> > >> > >> > >> > >> -- > >> sven fuchs svenfuchs@artweb-design.de > >> artweb design http://www.artweb-design.de > >> gr?nberger 65 + 49 (0) 30 - 47 98 69 96 (phone) > >> d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile) > >> > >> > >> > >> > >> _______________________________________________ > >> microformats-discuss mailing list > >> microformats-discuss@microformats.org > >> http://microformats.org/mailman/listinfo/microformats-discuss > >> > > -- > sven fuchs svenfuchs@artweb-design.de > artweb design http://www.artweb-design.de > gr?nberger 65 + 49 (0) 30 - 47 98 69 96 (phone) > d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile) > > > > From lists at hubmed.org Sun Feb 3 08:03:46 2008 From: lists at hubmed.org (Alf Eaton) Date: Sun Feb 3 08:41:50 2008 Subject: [uf-discuss] haudio contributor Message-ID: <47A5E5E2.2010206@hubmed.org> I was looking at using haudio today, but stumbled on the 'contributor' field: is there a reason it's 'contributor' rather than 'creator', even for the main creator (artist, in music) of the piece of audio? It doesn't seem to be based on established practice, as from the overview it looks like existing markup overwhelming uses 'artist'. http://microformats.org/wiki/audio-info-brainstorming#artist alf From lists at allinthehead.com Sun Feb 3 09:27:19 2008 From: lists at allinthehead.com (Drew McLellan) Date: Sun Feb 3 09:27:25 2008 Subject: [uf-discuss] tools.microformatic.com upgraded Message-ID: <0E85A68B-A116-4875-A8B9-6E9E71D50C3A@allinthehead.com> Following some problems with response times on tools.microformatic.com over the last 10 days, I've moved it too a new server with roughly twice the CPU and RAM. Should all be a lot faster now! My apologies to those affected by the recent slowness. http://tools.microformatic.com/ drew. From msporny at digitalbazaar.com Sun Feb 3 10:56:52 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Feb 3 11:39:19 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A5E5E2.2010206@hubmed.org> References: <47A5E5E2.2010206@hubmed.org> Message-ID: <47A60E74.5080209@digitalbazaar.com> Alf Eaton wrote: > I was looking at using haudio today, but stumbled on the 'contributor' > field: is there a reason it's 'contributor' rather than 'creator', even > for the main creator (artist, in music) of the piece of audio? We decided to not use "creator" because it would not be the proper semantic word for say, a publisher, or a composer. Most of the examples that we came across listed the publisher as well as the band that created the musical piece (CD). However, calling the publisher a "creator" would not be semantically correct. Dublin core makes this differentiation. There is a dc:creator field, which is a narrower concept from dc:contributor. Microformats try to use the most common subset of information among all examples. Some had "artist", some had "publisher", some had "label", others had "band" - these are all contributors. hAudio allows for listing multiple contributors. If only one contributor is listed, it is assumed that he/she/it is also the creator of the hAudio. If multiple contributors are listed, it is assumed that the first contributor is the creator, and all subsequent contributors played supporting roles in the creation of the hAudio. Thus, it can be said: Not all contributors are creators. Not all contributors are artists. Thus, we should not narrow the "who made it?" behind hAudio down to those more narrow categories. > It doesn't seem to be based on established practice, as from the > overview it looks like existing markup overwhelming uses 'artist'. > http://microformats.org/wiki/audio-info-brainstorming#artist If we used artist, we would not have been able to mark up publishers, composers, audio technicians, etc. Does that make sense? Does that explanation raise any further questions? -- manu From andy at pigsonthewing.org.uk Sun Feb 3 11:46:30 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 3 11:47:35 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: <2ang75-8r4.ln1@ophelia.g5n.co.uk> References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> Message-ID: In message <2ang75-8r4.ln1@ophelia.g5n.co.uk>, Toby A Inkster writes >The order of the space-delimited class attributes should be considered >significant -- that is, in the content referred >to by #baz is logically included as the last child of the >element, but in , it is logically included as the >first child. I don't understand why that's necessary. Can you elaborate, please? Meanwhile, my proposal is now on the wiki: -- Andy Mabbett From andy at pigsonthewing.org.uk Sun Feb 3 12:10:36 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 3 12:21:55 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A5E5E2.2010206@hubmed.org> References: <47A5E5E2.2010206@hubmed.org> Message-ID: In message <47A5E5E2.2010206@hubmed.org>, Alf Eaton writes >I was looking at using haudio today, but stumbled on the 'contributor' >field: is there a reason it's 'contributor' rather than 'creator', even >for the main creator (artist, in music) of the piece of audio? It seems strange that the microformat does not distinguish between the main "contributor" and others. Both the Beatles and Geoff Emerick "contributed" to "Sgt. Pepper's Lonely Hearts Club Band", for instance: but one is clearly more significant than the other. I can find no evidence of any published website which does not make such distinctions (anyone is welcome to provide some). There does seem to be a tendency in microformats, towards unduly low granularity; I find that strange. >It doesn't seem to be based on established practice, as from the >overview it looks like existing markup overwhelming uses 'artist'. >http://microformats.org/wiki/audio-info-brainstorming#artist Although in classical music, the composer may be as-, or more-, prominent than the artist; likewise the conductor. Higher granularity would allow for such distinctions. Here too, we might learn from the Dublin Core "Simple + Qualified" model [1]. We could have several classes: contributor then: contributor-artist contributor-composer contributor-conductor contributor-engineer etc. and agents "may" entitled to treat all the latter as equivalent to the first, but "should" preserve the full values when exporting. In practise, the latter set could omit the "contributor-" stem, and agents would then treat it as implied. Some people might argue instead for a 'contributor-type' property, but it is common usage to simply imply the main contributor's role: * "The Joshua Tree" by U2, produced by Brian Eno and Daniel Lanois * Beethoven's fifth Symphony, conducted by Simon Rattle * Smetana's Ma Vlast, performed by the London Philharmonic Orchestra (note also the common usage of the verbs "produced", "conducted" and "performed" rather than the role-nouns of "producer", "conductor" and "performer". [1] A parallel might also be drawn with tel vs. tel-work, tel-cell, etc. -- Andy Mabbett From andy at pigsonthewing.org.uk Sun Feb 3 12:26:54 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 3 12:28:04 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A60E74.5080209@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> Message-ID: In message <47A60E74.5080209@digitalbazaar.com>, Manu Sporny writes >If only one contributor is listed, it is assumed that he/she/it is also >the creator of the hAudio. If multiple contributors are listed, it is >assumed that the first contributor is the creator, and all subsequent >contributors played supporting roles in the creation of the hAudio. That fails as soon as we want to mark up something like: Simon Rattle conducted the CBSO in a marvellous rendition of Beethoven's Fifth or: Simon Rattle conducted a marvellous rendition of Ma Vlast or: EMI are pleased to announce a new downloadable version of the Beatles' 'Sgt Pepper...' or: EMI are pleased to announce a new downloadable version of 'Sgt Pepper...' >Thus, it can be said: > >Not all contributors are creators. >Not all contributors are artists. That can certainly be said. However, it cannot be expressed in hAudio without requiring the publishers of such examples to re-order their content. It is a microformats "principle" to not do so. >Thus, we should not narrow the "who made it?" behind hAudio down to >those more narrow categories. Your conclusion is not supported by the forgoing claims. >> It doesn't seem to be based on established practice, as from the >> overview it looks like existing markup overwhelming uses 'artist'. >> http://microformats.org/wiki/audio-info-brainstorming#artist > >If we used artist, we would not have been able to mark up publishers, >composers, audio technicians, etc. If we used *only* 'artist', perhaps, but not if we used 'artist' *AND* 'composer' + 'technician'. -- Andy Mabbett From info at weborganics.co.uk Sun Feb 3 12:40:52 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun Feb 3 12:41:05 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> Message-ID: <1202071252.32654.15.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sun, 2008-02-03 at 19:46 +0000, Andy Mabbett wrote: > In message <2ang75-8r4.ln1@ophelia.g5n.co.uk>, Toby A Inkster > writes > > >The order of the space-delimited class attributes should be considered > >significant -- that is, in the content referred > >to by #baz is logically included as the last child of the > >element, but in , it is logically included as the > >first child. > > I don't understand why that's necessary. Can you elaborate, please? > > Meanwhile, my proposal is now on the wiki: > > You Know I don't think you actually have to "include" your data, you could perhaps just reference them eg: Martin McEvoy http://wherever.com/ parsers instead of replacing data can then just append their data? Thanks Martin McEvoy > From m at klml.de Sun Feb 3 12:43:11 2008 From: m at klml.de (Klaus Mueller) Date: Sun Feb 3 12:45:09 2008 Subject: [uf-discuss] mediawiki-mark-up-issues In-Reply-To: References: <47A0FB21.9030608@klml.de> Message-ID: <47A6275F.9030403@klml.de> Hi Andy, thank you for your answers. >> the overview: >> http://www.monacomedia.de/muenchenwiki/index.php/M%C3%BCnchen_Wiki:Mikroformat >> > > The hCalendar events on that page are invalid; they lack "summary" and > valid "dtstart" properties. They have no properties, it is a code sniplet for the templates, a real example is here: http://www.monacomedia.de/muenchenwiki/index.php/Januar_2008 >> an example: >> http://www.monacomedia.de/muenchenwiki/index.php/Bayerische_Staatsbibliothek >> > > The hCard on that page is invalid (it has no "fn" property, which > appears to be an error in the template. I think you will need to sue > some conditional statements, or provide different templates for > organisations and venues. > you are right, I should make seperate templates for persons and places. I saw I can use tel and fax inside "adr", but can i also use email inside a adr-element? A "real" example f?r hCard http://www.monacomedia.de/muenchenwiki/index.php/Stefan_Golsch >> is this useful for mediawiki-mark-up-issues? >> http://microformats.org/wiki/mediawiki-mark-up-issues > > Which particular issues do your templates address? You could easy use some microformats with mediawiki, only building some templates. merci & greetz klml -- Klaus Mueller Schwanthaler Str. 13 80336 M?nchen home: +49 89 973 961 49 mobile: +49 178 54 38 400 klml.de From andy at pigsonthewing.org.uk Sun Feb 3 11:33:27 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 3 13:04:50 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> Message-ID: In message , Toby A Inkster writes >> The order of the space-delimited class attributes should be considered >> significant -- that is, in the content referred >> to by #baz is logically included as the last child of the element, >> but in , it is logically included as the first >> child. >Wikied here: >http://microformats.org/wiki/include-pattern-strawman You might like to compare that with my proposal, not yet on the wiki, but outlined in this post: (aka ) et seq. -- Andy Mabbett From info at weborganics.co.uk Sun Feb 3 13:35:50 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun Feb 3 13:36:01 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: <1202071252.32654.15.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> <1202071252.32654.15.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1202074551.727.6.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sun, 2008-02-03 at 20:40 +0000, Martin McEvoy wrote: > Martin McEvoy > > http://wherever.com/ No :( too verbose anyway:
Martin McEvoy
WebOrganics
DarkstarServer
and you may have to actually use include to make it less so
DarkstarServer
which is not good, its almost like creating an empty

to create some space? Oh well Thanks Martin McEvoy From lists at hubmed.org Sun Feb 3 13:55:34 2008 From: lists at hubmed.org (Alf Eaton) Date: Sun Feb 3 14:01:52 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A60E74.5080209@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> Message-ID: <47A63856.2000103@hubmed.org> Manu Sporny wrote: > Alf Eaton wrote: >> I was looking at using haudio today, but stumbled on the 'contributor' >> field: is there a reason it's 'contributor' rather than 'creator', even >> for the main creator (artist, in music) of the piece of audio? > > We decided to not use "creator" because it would not be the proper > semantic word for say, a publisher, or a composer. Most of the examples > that we came across listed the publisher as well as the band that > created the musical piece (CD). However, calling the publisher a > "creator" would not be semantically correct. > > Dublin core makes this differentiation. There is a dc:creator field, > which is a narrower concept from dc:contributor. Microformats try to use > the most common subset of information among all examples. Some had > "artist", some had "publisher", some had "label", others had "band" - > these are all contributors. > > hAudio allows for listing multiple contributors. > > If only one contributor is listed, it is assumed that he/she/it is also > the creator of the hAudio. If multiple contributors are listed, it is > assumed that the first contributor is the creator, and all subsequent > contributors played supporting roles in the creation of the hAudio. How about this: * All "contributors" played a role in the creation of the audio. * If there's one or more "creators", those entities played a primary role. But then I'm struggling to think of actual examples where your rule wouldn't be enough (though having to list the main contributor at the start of the list might be one problem). It just feels wrong not to be able to explicitly mark the primary creator(s) when, as you say, sometimes you do want to do just that. What if there are two primary creators (composer and performer, say) and the rest are just auxiliary contributors? alf From info at weborganics.co.uk Sun Feb 3 15:01:08 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun Feb 3 15:01:20 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: <1202074551.727.6.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> <1202071252.32654.15.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1202074551.727.6.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1202079668.1375.11.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sun, 2008-02-03 at 21:35 +0000, Martin McEvoy wrote: > On Sun, 2008-02-03 at 20:40 +0000, Martin McEvoy wrote: > > Martin McEvoy > > > > http://wherever.com/ > > No :( too verbose anyway: .... A solution may be to remove our own "anti-patterns" such as using "id" and empty anchor text links altogether:
Martin McEvoy WebOrganics
all sibling hcards could then use the "include" as the Required "fn" when not explicitly stated.
DarkstarServer
Thanks Martin McEvoy From mail at tobyinkster.co.uk Sun Feb 3 22:53:43 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Feb 3 23:01:24 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> Message-ID: Andy Mabbett wrote: > Toby A Inkster writes: > >>The order of the space-delimited class attributes should be considered >>significant -- that is, in the content referred >>to by #baz is logically included as the last child of the element, >>but in , it is logically included as the first >>child. > > I don't understand why that's necessary. Can you elaborate, please? For addresses, the order of the included elements is probably not important. When it comes to, say, printing an envelope, we all know that the street address comes before the locality. Parsers can have this knowledge hard-coded. For other microformats and some proposed microformats, order may be important. For example, the ordered steps in the "method" part of a recipe. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 13:07.] The World in 2050? http://tobyinkster.co.uk/blog/2008/02/03/world-2050/ From mail at tobyinkster.co.uk Sun Feb 3 23:00:29 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Feb 3 23:05:11 2008 Subject: [uf-discuss] Re: xfn and biographies References: <0F667B0C-8A0D-4345-AF3B-D6D191BA3F38@eatyourgreens.org.uk> Message-ID: Jim O'Donnell wrote: > Has anyone done any work on simple microformat class names based on the > Dublin Core element set? If you're using rel attributes on and elements, then take a look at RFC 2731 . An example of a page making use of this RFC can be found in my signature. In particular, you may be interested in how I link from document to author: -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 13:12.] The World in 2050? http://tobyinkster.co.uk/blog/2008/02/03/world-2050/ From bhawkeslewis at googlemail.com Sun Feb 3 23:26:41 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Feb 3 23:26:42 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: References: <2ang75-8r4.ln1@ophelia.g5n.co.uk> Message-ID: <47A6BE31.7060709@googlemail.com> Toby A Inkster wrote: > For addresses, the order of the included elements is probably not > important. When it comes to, say, printing an envelope, we all know that > the street address comes before the locality. Parsers can have this > knowledge hard-coded. This is probably true, although note this will require them to be locale-aware as such rules don't necessarily hold fast in different territories. For example, it seems that in Chinese addresses written in Chinese the locality would come before the street address: http://www.upu.int/post_code/en/countries/CHN.pdf -- Benjamin Hawkes-Lewis From tantek at cs.stanford.edu Sun Feb 3 23:46:16 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Feb 3 23:44:45 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: Message-ID: On 2/3/08 4:34 AM, "Toby A Inkster" wrote: > Toby A Inkster wrote: > >> The order of the space-delimited class attributes should be considered >> significant -- that is, in the content referred >> to by #baz is logically included as the last child of the element, >> but in , it is logically included as the first >> child. >> >> I shall add to the Wiki momentarily... > > Wikied here: > http://microformats.org/wiki/include-pattern-strawman > > Also fleshed out to include an example where included data is placed in > the middle of its parent element rather than at the beginning or end. Two problems: 1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't. 2. inclusion of arbitrary data (#baz) in the class attribute is a documented anti-pattern. http://microformats.org/wiki/anti-patterns#data_in_class_attributes Tantek From msporny at digitalbazaar.com Mon Feb 4 08:16:38 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 08:16:43 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> Message-ID: <47A73A66.90508@digitalbazaar.com> Andy Mabbett wrote: > In message <47A60E74.5080209@digitalbazaar.com>, Manu Sporny > writes > >> If only one contributor is listed, it is assumed that he/she/it is also >> the creator of the hAudio. If multiple contributors are listed, it is >> assumed that the first contributor is the creator, and all subsequent >> contributors played supporting roles in the creation of the hAudio. > > That fails as soon as we want to mark up something like: > > Simon Rattle conducted the CBSO in a marvellous rendition of > Beethoven's Fifth Yes, the use of 'contributor' falls apart completely when we have markup like that... which is uncommon. You should have noted that markup such as that is an edge case. Look at the audio-info-examples and you will be lucky if you find 1 or 2 instances of the markup you describe above. My point is that it is easy to manufacture words that break hAudio - but much harder to find actual examples online that break it. If you have issues with this approach, you can always use hAudio RDFa, which does make the distinction between "dc:creator" and "dc:contributor". If you wanted to be even more specific, just include the Music Ontology vocabulary and mark it up using that. >> Thus, it can be said: >> >> Not all contributors are creators. >> Not all contributors are artists. > > That can certainly be said. However, it cannot be expressed in hAudio > without requiring the publishers of such examples to re-order their > content. It is a microformats "principle" to not do so. For the publishers that need to re-order their content to mark up hAudio, they are obviously stretching what hAudio uF can do, and should use hAudio RDFa. >> Thus, we should not narrow the "who made it?" behind hAudio down to >> those more narrow categories. > > Your conclusion is not supported by the forgoing claims. Then does doing this support my conclusion: *waves hands wildly in the air* =P More seriously: We don't have enough examples to split "contributor" into "label", "publisher", "creator", and "artist" - which is what the examples showed to be the most prominently displayed contributors across the 93+ sites that we analyzed for hAudio. >>> It doesn't seem to be based on established practice, as from the >>> overview it looks like existing markup overwhelming uses 'artist'. >>> http://microformats.org/wiki/audio-info-brainstorming#artist >> If we used artist, we would not have been able to mark up publishers, >> composers, audio technicians, etc. > > If we used *only* 'artist', perhaps, but not if we used 'artist' *AND* > 'composer' + 'technician'. There aren't enough examples that list the composer or the technician to make the argument for adding those into hAudio. You're more than welcome to go back through the audio-info-examples and re-analyze all of the sites to prove your point, though. -- manu From msporny at digitalbazaar.com Mon Feb 4 07:58:05 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 08:16:44 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <47A5E5E2.2010206@hubmed.org> Message-ID: <47A7360D.4060603@digitalbazaar.com> Andy Mabbett wrote: > It seems strange that the microformat does not distinguish between the > main "contributor" and others. It does - you list the main contributor first, if you care about that sort of thing. Otherwise, you can list them in any order. > Both the Beatles and Geoff Emerick > "contributed" to "Sgt. Pepper's Lonely Hearts Club Band", for instance: > > > > but one is clearly more significant than the other. Sure - but what about this one: http://music.yahoo.com/release/115057 Which one is more significant than the other - the label or the artist? Are "creators" more important than "contributors"? These questions are philosophical in nature - you can't assume that "creator" should be used to note the significance of a contribution. > There does seem to be a tendency in microformats, towards unduly low > granularity; I find that strange. Why do you find that strange? We're working with lowest common denominator here. When you do that, you get low granularity. > Although in classical music, the composer may be as-, or more-, > prominent than the artist; likewise the conductor. Higher granularity > would allow for such distinctions. Sure - now all you have to do is find enough examples online, (we'll need about 30 with the composer clearly denoted as well as the artist with the composer more prominently displayed than the artist) for us to make the argument for putting this feature into hAudio. -- manu From msporny at digitalbazaar.com Mon Feb 4 08:30:06 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 08:30:10 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A63856.2000103@hubmed.org> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> Message-ID: <47A73D8E.30406@digitalbazaar.com> Alf Eaton wrote: > How about this: > * All "contributors" played a role in the creation of the audio. > * If there's one or more "creators", those entities played a primary role. We looked at that approach, and found that we didn't have the examples to back up the argument that we should make the distinction between "creator" and "contributor" because there weren't enough examples that clearly listed anybody other than the creator, and because hCard already has a "role" field. If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the "role" property[1]. > But then I'm struggling to think of actual examples where your rule > wouldn't be enough (though having to list the main contributor at the > start of the list might be one problem). It just feels wrong not to be > able to explicitly mark the primary creator(s) when, as you say, > sometimes you do want to do just that. You can do this using "role" in hCard when describing the contributor. If this doesn't work for you, you can use hCard RDFa which does differentiate between the primary creator(s) and contributors. > What if there are two primary creators (composer and performer, say) and > the rest are just auxiliary contributors? You could mark up each primary creator's "role" using hCard to describe each creator. You could not specify the auxiliary contributors' roles, or you could specify them - it's up to you to determine how specific you want to be. Does that work for your needs? -- manu [1]http://microformats.org/wiki/haudio#Contributor From lists at hubmed.org Mon Feb 4 09:44:19 2008 From: lists at hubmed.org (Alf Eaton) Date: Mon Feb 4 09:45:49 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A73D8E.30406@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> Message-ID: <47A74EF3.2010203@hubmed.org> Manu Sporny wrote: > Alf Eaton wrote: >> How about this: >> * All "contributors" played a role in the creation of the audio. >> * If there's one or more "creators", those entities played a primary role. > > We looked at that approach, and found that we didn't have the examples > to back up the argument that we should make the distinction between > "creator" and "contributor" because there weren't enough examples that > clearly listed anybody other than the creator, and because hCard already > has a "role" field. > > If you really want to make the distinction between a publisher, a > drummer, a singer, a technician, and someone else, you can always use an > hCard and utilize the "role" property[1]. > >> But then I'm struggling to think of actual examples where your rule >> wouldn't be enough (though having to list the main contributor at the >> start of the list might be one problem). It just feels wrong not to be >> able to explicitly mark the primary creator(s) when, as you say, >> sometimes you do want to do just that. > > You can do this using "role" in hCard when describing the contributor. > If this doesn't work for you, you can use hCard RDFa which does > differentiate between the primary creator(s) and contributors. > >> What if there are two primary creators (composer and performer, say) and >> the rest are just auxiliary contributors? > > You could mark up each primary creator's "role" using hCard to describe > each creator. You could not specify the auxiliary contributors' roles, > or you could specify them - it's up to you to determine how specific you > want to be. > > Does that work for your needs? It would work, but so would a number of very complicated things. My needs are essentially very simple: Primal Scream - Screamadelica so Primal Scream - Screamadelica is simpler than Primal Scream - Screamadelica, hence I like it. If there really "weren't enough examples that clearly listed anybody other than the creator", doesn't that make things easier? alf From msporny at digitalbazaar.com Mon Feb 4 11:21:52 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 11:21:57 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A74EF3.2010203@hubmed.org> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A74EF3.2010203@hubmed.org> Message-ID: <47A765D0.6010406@digitalbazaar.com> Alf Eaton wrote: > It would work, but so would a number of very complicated things. My > needs are essentially very simple: > > Primal Scream - Screamadelica > > so > > Primal Scream - class="album">Screamadelica Why doesn't the following work for you, then?
Primal Scream - Screamadelica
Per the hAudio spec, you have just marked up an album called "Screamadelica", whose primary contributor (the artist) is "Primal Scream". The example above is valid hAudio markup - is your issue with the word "contributor" instead of "creator"? > If there really "weren't enough examples that clearly listed anybody > other than the creator", doesn't that make things easier? Sorry, that was badly worded on my part. What I meant to express was: There weren't enough examples that clearly showed that people were using the word "artist", "label", not mentioning the role, or using "publisher" more than the others. It was a mixed bag and what we saw at the end was the chance to support all of these by using "contributor" in the simple cases and contributor + hCard role in the complex cases. None of this seems to be an issue with what you're trying to mark up, though. If it is still an issue, could you please post some other data that you're attempting to markup where the hAudio spec doesn't let you mark it up in the way that you want to? -- manu From andy at pigsonthewing.org.uk Mon Feb 4 13:15:01 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 13:16:13 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A73A66.90508@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A73A66.90508@digitalbazaar.com> Message-ID: In message <47A73A66.90508@digitalbazaar.com>, Manu Sporny writes >Andy Mabbett wrote: >> In message <47A60E74.5080209@digitalbazaar.com>, Manu Sporny >> writes >> >>> If only one contributor is listed, it is assumed that he/she/it is also >>> the creator of the hAudio. If multiple contributors are listed, it is >>> assumed that the first contributor is the creator, and all subsequent >>> contributors played supporting roles in the creation of the hAudio. >> >> That fails as soon as we want to mark up something like: >> >> Simon Rattle conducted the CBSO in a marvellous rendition of >> Beethoven's Fifth > >Yes, the use of 'contributor' falls apart completely when we have markup >like that... which is uncommon. For some value of "uncommon". >You should have noted that markup such as that is an edge case. Look at >the audio-info-examples and you will be lucky if you find 1 or 2 >instances of the markup you describe above. Perhaps, but why assume that the limited number and types of examples are representative of all references to audio recordings? >My point is that it is easy to manufacture words that break hAudio - but >much harder to find actual examples online that break it. It's not necessary to "manufacture" examples - I've already provided real evidence, some weeks ago. >If you have issues with this approach, you can always use hAudio RDFa, >which does make the distinction between "dc:creator" and >"dc:contributor". If you wanted to be even more specific, just include >the Music Ontology vocabulary and mark it up using that. I could do, but I'd rather help to get hAudio right; and further microformats in general. >>> Thus, it can be said: >>> >>> Not all contributors are creators. >>> Not all contributors are artists. >> >> That can certainly be said. However, it cannot be expressed in hAudio >> without requiring the publishers of such examples to re-order their >> content. It is a microformats "principle" to not do so. > >For the publishers that need to re-order their content to mark up >hAudio, they are obviously stretching what hAudio uF can do [...] Again, not according to the example I gave a while ago. >We don't have enough examples to split "contributor" into "label", >"publisher", "creator", and "artist" - which is what the examples showed >to be the most prominently displayed contributors across the 93+ sites >that we analyzed for hAudio. Then we need more examples and realising that such examples may never be sufficiently exhaustive, should treat them accordingly. To paraphrase an old maxim: the process should be for the guidance of wise men and the blind obedience of fools >>>> It doesn't seem to be based on established practice, as from the >>>> overview it looks like existing markup overwhelming uses 'artist'. >>>> http://microformats.org/wiki/audio-info-brainstorming#artist >>> If we used artist, we would not have been able to mark up publishers, >>> composers, audio technicians, etc. >> >> If we used *only* 'artist', perhaps, but not if we used 'artist' *AND* >> 'composer' + 'technician'. > >There aren't enough examples that list the composer or the technician to >make the argument for adding those into hAudio. If there are insufficient examples of "composer" being listed, that itself is evidence that the examples are inadequate: likewise for conductors: and, (though I grant that technicians generally get less attention): Consider also how to indicate a reference to a song performed by its composer: Bob Dylan >You're more than welcome >to go back through the audio-info-examples and re-analyze all of the >sites to prove your point, though. Why would I, when they're clearly inadequate? -- Andy Mabbett From andy at pigsonthewing.org.uk Mon Feb 4 14:35:40 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 14:37:00 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A73D8E.30406@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> Message-ID: In message <47A73D8E.30406@digitalbazaar.com>, Manu Sporny writes >If you really want to make the distinction between a publisher, a >drummer, a singer, a technician, and someone else, you can always use >an hCard and utilize the "role" property That presumes that the roles are exposed in the page; they may be if or, say a producer, but often using the verb ("produced by..."), and frequently are not, We don't need to say that Beethoven is a composer, when saying "Beethoven's fifth". That's clear to a human (well, mist humans of any western education!) from context; but not to a machine. Before anyone cries "hidden metadata", how often to we explicitly say that "Mabbett" is my family name?, or that "21 High street" is a street address? -- Andy Mabbett From andy at pigsonthewing.org.uk Mon Feb 4 14:37:50 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 14:39:30 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A74EF3.2010203@hubmed.org> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A74EF3.2010203@hubmed.org> Message-ID: In message <47A74EF3.2010203@hubmed.org>, Alf Eaton writes >If there really "weren't enough examples that clearly listed anybody >other than the creator", doesn't that make things easier? All that makes easier for me is the confidence to say that the evidence is too limited. -- Andy Mabbett From andy at pigsonthewing.org.uk Mon Feb 4 14:39:52 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 14:41:33 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A765D0.6010406@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A74EF3.2010203@hubmed.org> <47A765D0.6010406@digitalbazaar.com> Message-ID: In message <47A765D0.6010406@digitalbazaar.com>, Manu Sporny writes >Why doesn't the following work for you, then? > >
> Primal Scream - > Screamadelica >
> >Per the hAudio spec, you have just marked up an album called >"Screamadelica", whose primary contributor (the artist) is "Primal Scream". > >The example above is valid hAudio markup I thought "fn" was required. -- Andy Mabbett From msporny at digitalbazaar.com Mon Feb 4 15:01:44 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 15:01:47 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A74EF3.2010203@hubmed.org> <47A765D0.6010406@digitalbazaar.com> Message-ID: <47A79958.3080306@digitalbazaar.com> Andy Mabbett wrote: > In message <47A765D0.6010406@digitalbazaar.com>, Manu Sporny > writes > >> Why doesn't the following work for you, then? >> >>
>> Primal Scream - >> Screamadelica >>
>> >> Per the hAudio spec, you have just marked up an album called >> "Screamadelica", whose primary contributor (the artist) is "Primal >> Scream". >> >> The example above is valid hAudio markup > > I thought "fn" was required. It isn't: http://microformats.org/wiki/haudio#Album You MUST use either FN or ALBUM, or both. In other words: If you ONLY use FN - you are talking about an audio recording. If you ONLY use ALBUM - you are talking about an audio album. If you use BOTH FN and ALBUM - you are talking about an audio recording from the specified audio album. -- manu From andy at pigsonthewing.org.uk Mon Feb 4 14:46:19 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 15:17:39 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A73A66.90508@digitalbazaar.com> Message-ID: In message , Andy Mabbett writes >If there are insufficient examples of "composer" being listed, that >itself is evidence that the examples are inadequate: More to consider here: (also an excellent place for genuinely free mp3s!) -- Andy Mabbett From guillaume at lebleu.org Mon Feb 4 15:48:39 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Mon Feb 4 15:53:50 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> Message-ID: <47A7A457.2090709@lebleu.org> Andy Mabbett wrote: > In message <47A73D8E.30406@digitalbazaar.com>, Manu Sporny > writes > >> If you really want to make the distinction between a publisher, a >> drummer, a singer, a technician, and someone else, you can always use >> an hCard and utilize the "role" property > > That presumes that the roles are exposed in the page; they may be if > or, say a producer, but often using the verb ("produced by..."), and > frequently are not, We don't need to say that Beethoven is a composer, > when saying "Beethoven's fifth". That's clear to a human (well, mist > humans of any western education!) from context; but not to a machine. > > Before anyone cries "hidden metadata", how often to we explicitly say > that "Mabbett" is my family name?, or that "21 High street" is a > street address? > I agree with others that these are edge cases for microformats. I don't think you are correct when you say that only a human can infer Beethoven--(composerOf)-->fifth, from "Beethoven's fifth". As far as I've seen in other more lucrative domains than music, a well-trained semantic software extractor working off sufficient content, plain old grammatically-correct english and music metadata would do that job with less sweat than an editor will take to write the content and mark it up in hAudio or something else (not to say to come up with the markup that works in these edge cases in the first place). Grammatically-correct english IS semantic markup, in a way. I think microformats' sweet spot is easing semantic extraction in cases where the level of structure is high, and the plain english context is low. The back of an album that lists tracks is such a case, its entry in Gracenote, a list of friends, electronic business cards, etc. are good examples as well. A plain english critics' review of an album on the other hand with lots of context, but little structure is a case that is economically much better handled using semantic analysis than with "$1M markup". I'm not saying that microformats should not try to make formats that work with plain old English or natural language (I've been trying myself), I'm just saying that we may consider the fact that the ROI will most likely be low and other technologies will compete better there, so we might just focus our time on where we have the biggest chance of straightforward adoption, then only look at solving the plain english cases, instead of trying to solve everything at once. Guillaume From andy at pigsonthewing.org.uk Mon Feb 4 15:58:21 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 15:59:47 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A79958.3080306@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A74EF3.2010203@hubmed.org> <47A765D0.6010406@digitalbazaar.com> <47A79958.3080306@digitalbazaar.com> Message-ID: In message <47A79958.3080306@digitalbazaar.com>, Manu Sporny writes >> I thought "fn" was required. > >It isn't: > >http://microformats.org/wiki/haudio#Album > >You MUST use either FN or ALBUM, or both. Thank you. I've updated the cheatsheet: to make that more clear. >If you ONLY use FN - you are talking about an audio recording. >If you ONLY use ALBUM - you are talking about an audio album. >If you use BOTH FN and ALBUM - you are talking about an audio recording >from the specified audio album. In that case, perhaps "track" rather than "title" is the more appropriate label to replace "FN"? -- Andy Mabbett From p at premasagar.com Tue Feb 5 00:13:06 2008 From: p at premasagar.com (Premasagar) Date: Tue Feb 5 00:13:15 2008 Subject: [uf-discuss] tools.microformatic.com upgraded In-Reply-To: <0E85A68B-A116-4875-A8B9-6E9E71D50C3A@allinthehead.com> References: <0E85A68B-A116-4875-A8B9-6E9E71D50C3A@allinthehead.com> Message-ID: <47A81A92.2040102@premasagar.com> Drew McLellan wrote: > Following some problems with response times on tools.microformatic.com > over the last 10 days, I've moved it too a new server with roughly > twice the CPU and RAM. > Should all be a lot faster now! > > My apologies to those affected by the recent slowness. > > http://tools.microformatic.com/ > > > drew. Thanks Drew! It's a very useful little service. Prem. -- p@premasagar.com http://premasagar.com | http://dharmafly.com From lists at hubmed.org Tue Feb 5 02:35:09 2008 From: lists at hubmed.org (Alf Eaton) Date: Tue Feb 5 02:36:32 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A765D0.6010406@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A74EF3.2010203@hubmed.org> <47A765D0.6010406@digitalbazaar.com> Message-ID: <47A83BDD.8090509@hubmed.org> Manu Sporny wrote: > Alf Eaton wrote: >> It would work, but so would a number of very complicated things. My >> needs are essentially very simple: >> >> Primal Scream - Screamadelica >> >> so >> >> Primal Scream - > class="album">Screamadelica > > Why doesn't the following work for you, then? > >
> Primal Scream - > Screamadelica >
> > Per the hAudio spec, you have just marked up an album called > "Screamadelica", whose primary contributor (the artist) is "Primal Scream". > > The example above is valid hAudio markup - is your issue with the word > "contributor" instead of "creator"? Basically, yes :-) And it's not a huge issue, I was just wondering if there was justification for it being that way - which there is, it seems. alf From mdagn at spraci.com Tue Feb 5 06:56:40 2008 From: mdagn at spraci.com (Michael MD) Date: Tue Feb 5 06:56:45 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A765D0.6010406@digitalbazaar.com> Message-ID: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> >Why doesn't the following work for you, then? > >
> Primal Scream - > Screamadelica >
That may be fine for someone who just wants to mark up some tracks they like on a personal blog ... but an artist or record store may want to be able to say who composed it, who performed it, who did studio production, who remixed it, who a guest instumentalist was, what label released it, and maybe even who distibutes it and want to be able to distinguish between them. From thom at ts0.com Tue Feb 5 07:47:03 2008 From: thom at ts0.com (Thom Shannon) Date: Tue Feb 5 07:47:09 2008 Subject: [uf-discuss] Apple Data Detectors Message-ID: <47A884F7.5040800@ts0.com> Not sure if anyone's mentioned this before but the new version of Apples Mail has functionality similar to what microformats is trying to enable (hCard and hCal) You can mouse over data in an email like addresses, phone numbers and dates, then add them to your address book/calendar. http://www.apple.com/business/videotips/?movie=maildatadetectors A few things spring to mind: a) Does it use microformats if they're present? - I just tested it, it put the postcode in the state field so I guess not b) Wouldn't it be nice to get hold of their pattern matching code! c) Interesting how they've done the interface, not too far from some mock-ups I saw for FF3, what can we learn from it? From andy at pigsonthewing.org.uk Tue Feb 5 07:54:54 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 5 07:56:04 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> References: <47A765D0.6010406@digitalbazaar.com> <200802051456.m15EueN69142@proxy.syd.comcen.com.au> Message-ID: In message <200802051456.m15EueN69142@proxy.syd.comcen.com.au>, Michael MD writes > >>Why doesn't the following work for you, then? >> >>
>> Primal Scream - >> Screamadelica >>
> > >That may be fine for someone who just wants to mark up some tracks they >like on a personal blog ... but an artist or record store may want to >be able to say who composed it, who performed it, who did studio >production, who remixed it, who a guest instumentalist was, what label >released it, and maybe even who distibutes it and want to be able to >distinguish between them. Not merely "may want to"; they do - see the Naxos examples I posted to the wiki in the last 24 hours, plus discography sites like: not to mention Wikipedia: Some of us radicals also think it's a good idea to use hCard... -- Andy Mabbett From info at weborganics.co.uk Tue Feb 5 07:57:50 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 5 07:58:00 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> Message-ID: <1202227070.9752.13.camel@weborganicscouk> On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: > >Why doesn't the following work for you, then? > > > >
> > Primal Scream - > > Screamadelica > >
> > > That may be fine for someone who just wants to mark up some tracks they like > on a personal blog ... but an artist or record store may want to be able to > say who composed it, who performed it, who did studio production, who > remixed it, who a guest instumentalist was, what label released it, and > maybe even who distibutes it and want to be able to distinguish between > them. Oh but you can...
Screamadelica Artist - Primal Scream Producer - Andrew Weatherall Vocals - Jah Wobble
The only thing I might add is vcard looks redundant? as the context describes audio, not buisness cards? Thanks Martin McEvoy > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From andy at pigsonthewing.org.uk Tue Feb 5 08:01:19 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 5 08:02:46 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A7A457.2090709@lebleu.org> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A7A457.2090709@lebleu.org> Message-ID: <2vXMfsJPhIqHFwSi@pigsonthewing.org.uk> In message <47A7A457.2090709@lebleu.org>, Guillaume Lebleu writes >Andy Mabbett wrote: >> In message <47A73D8E.30406@digitalbazaar.com>, Manu Sporny >> writes >> >>> If you really want to make the distinction between a publisher, a >>>drummer, a singer, a technician, and someone else, you can always use >>>an hCard and utilize the "role" property >> >> That presumes that the roles are exposed in the page; they may be if >>or, say a producer, but often using the verb ("produced by..."), and >>frequently are not, We don't need to say that Beethoven is a composer, >>when saying "Beethoven's fifth". That's clear to a human (well, mist >>humans of any western education!) from context; but not to a machine. >> >> Before anyone cries "hidden metadata", how often to we explicitly say >>that "Mabbett" is my family name?, or that "21 High street" is a >>street address? >> >I agree with others that these are edge cases for microformats. Everything is an edge case, depending on which point you're looking from. >I don't think you are correct when you say that only a human can infer >Beethoven--(composerOf)-->fifth, from "Beethoven's fifth". As far as >I've seen in other more lucrative domains than music, a well-trained >semantic software extractor working off sufficient content, plain old >grammatically-correct english and music metadata would do that job with >less sweat than an editor will take to write the content and mark it up >in hAudio or something else (not to say to come up with the markup that >works in these edge cases in the first place). Well, clearly I was simplifying. But how many of us have access to "a well-trained semantic software extractor", and what "music metadata" is widely used? By your argument, we wouldn't need microformats at all. >Grammatically-correct english IS semantic markup, in a way. For some value of "semantic". >I think microformats' sweet spot is easing semantic extraction in cases >where the level of structure is high, and the plain english context is >low. If that's where you want to concentrate your use of microformats, that's fine, but that's not how I see them, and I see nothing in any of the specs or other defining documentation which restricts them in that way. >The back of an album that lists tracks is such a case, its entry in >Gracenote, a list of friends, electronic business cards, etc. are good >examples as well. A plain english critics' review of an album on the >other hand with lots of context, but little structure is a case that is >economically much better handled using semantic analysis than with "$1M >markup". "economically much better" from whose perspective? >I'm not saying that microformats should not try to make formats that >work with plain old English or natural language (I've been trying >myself), I'm just saying that we may consider the fact that the ROI >will most likely be low and other technologies will compete better >there, so we might just focus our time on where we have the biggest >chance of straightforward adoption, then only look at solving the plain >english cases, instead of trying to solve everything at once. I think that's an opinion - a restrictive one at that - not shared by everyone here, certainly not by me, and not supported by past experience of developing and using microformats. -- Andy Mabbett From andy at pigsonthewing.org.uk Tue Feb 5 08:10:25 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 5 08:11:31 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A7360D.4060603@digitalbazaar.com> References: <47A5E5E2.2010206@hubmed.org> <47A7360D.4060603@digitalbazaar.com> Message-ID: In message <47A7360D.4060603@digitalbazaar.com>, Manu Sporny writes >> Both the Beatles and Geoff Emerick >> "contributed" to "Sgt. Pepper's Lonely Hearts Club Band", for instance: >> >> >> >> but one is clearly more significant than the other. > >Sure - but what about this one: > >http://music.yahoo.com/release/115057 > >Which one is more significant than the other - the label or the artist? From the point of view of the target audience of that page, the artist. >Are "creators" more important than "contributors"? These questions are >philosophical in nature - you can't assume that "creator" should be used >to note the significance of a contribution. Perhaps not - we need greater granularity. >> There does seem to be a tendency in microformats, towards unduly low >> granularity; I find that strange. > >Why do you find that strange? Because we're all interested in making human-readable data available to machines. There seems little point in not doing so as well or as thoroughly as is possible, for little extra effort. (There is a pojnt of diminishing returns, but in this case as in many others discussed here ion recent months, we're nowhere near it yet). >We're working with lowest common >denominator here. When you do that, you get low granularity. Quite. >> Although in classical music, the composer may be as-, or more-, >> prominent than the artist; likewise the conductor. Higher granularity >> would allow for such distinctions. > >Sure - now all you have to do is find enough examples online, (we'll >need about 30 with the composer clearly denoted as well as the artist >with the composer more prominently displayed than the artist) for us to >make the argument for putting this feature into hAudio. I don't *have* to do any such thing; though I happen to have already started doing so; and I certainly don't have to comply with some invented quantitative requirement (after all, it's well over a year since I attempted to do so for the taxonomic names of living things, and despite providing many millions, and having asked him numerous times, Tantek has yet to give a simple yes or no answer to my question as to whether that's sufficient). -- Andy Mabbett From mail at tobyinkster.co.uk Tue Feb 5 08:23:42 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Feb 5 08:25:10 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" References: Message-ID: Tantek =?ISO-8859-1?B?xw==?=elik wrote: > 1. class is an unordered set of values per HTML4. introducing ordering > is a non-starter both from a violation of HTML4 spec perspective and > likely requiring of rewriting HTML4 parsers to maintain an ordering > where they currently don't. A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered. It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word. As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order. And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained. I can't think of a single HTML parser that is only able to provide access to the class attribute as an unordered set. If any such parser exists, please enlighten me. > 2. inclusion of arbitrary data (#baz) in the class attribute is a > documented anti-pattern. > http://microformats.org/wiki/anti-patterns#data_in_class_attributes This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 6 days, 22:24.] The World in 2050? http://tobyinkster.co.uk/blog/2008/02/03/world-2050/ From andy at pigsonthewing.org.uk Tue Feb 5 08:41:38 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 5 08:43:07 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <1202227070.9752.13.camel@weborganicscouk> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> Message-ID: In message <1202227070.9752.13.camel@weborganicscouk>, Martin McEvoy writes >On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: >> >Why doesn't the following work for you, then? >> > >> >
>> > Primal Scream - >> > Screamadelica >> >
>> >> >> That may be fine for someone who just wants to mark up some tracks they like >> on a personal blog ... but an artist or record store may want to be able to >> say who composed it, who performed it, who did studio production, who >> remixed it, who a guest instumentalist was, what label released it, and >> maybe even who distibutes it and want to be able to distinguish between >> them. > >Oh but you can... > >
> Screamadelica > > > Artist - > Primal Scream > 1) that's not the model referred to in "Why doesn't the following work for you, then?", above. 2) Where is the evidence, in examples like that quoted at the top if this post, that people publish terms like "Artist" when referring to the key creator? > > Producer - > Andrew Weatherall > How does that cater for people who use "produced by" instead of "producer"? > > Vocals - > Jah Wobble > The role there is "singer" or "vocalist", not "vocals". >The only thing I might add is vcard looks redundant? as the context >describes audio, not buisness cards? hCard is not just for business cards. It's for "people, organisations or places". -- Andy Mabbett From rob at sanchothefat.com Tue Feb 5 10:39:51 2008 From: rob at sanchothefat.com (Robert O'Rourke) Date: Tue Feb 5 10:40:08 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> Message-ID: <47A8AD77.2070100@sanchothefat.com> Andy Mabbett wrote: > In message <1202227070.9752.13.camel@weborganicscouk>, Martin McEvoy > writes > >> On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: >>> >Why doesn't the following work for you, then? >>> > >>> >
>>> > Primal Scream - >>> > Screamadelica >>> >
>>> >>> >>> That may be fine for someone who just wants to mark up some tracks >>> they like >>> on a personal blog ... but an artist or record store may want to be >>> able to >>> say who composed it, who performed it, who did studio production, who >>> remixed it, who a guest instumentalist was, what label released it, and >>> maybe even who distibutes it and want to be able to distinguish between >>> them. >> >> Oh but you can... >> >>
>> Screamadelica >> >> >> Artist - >> Primal Scream >> > > 1) that's not the model referred to in "Why doesn't the following work > for you, then?", above. > > 2) Where is the evidence, in examples like that quoted at the top if > this post, that people publish terms like "Artist" when referring to > the key creator? From looking at a selection of ten online music shops and databases the 'key creator' is always implied by association. How about removing the 'contributor' class from the key creator's vcard? It would make sense to me to group contributors separately to the creator. The vcard attached to the hAudio would denote the original creator. For cover tracks you'd have something like: Original Artist - Primal Scream From msporny at digitalbazaar.com Tue Feb 5 10:18:16 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 5 10:53:52 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A83BDD.8090509@hubmed.org> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A74EF3.2010203@hubmed.org> <47A765D0.6010406@digitalbazaar.com> <47A83BDD.8090509@hubmed.org> Message-ID: <47A8A868.3060206@digitalbazaar.com> Alf Eaton wrote: >> The example above is valid hAudio markup - is your issue with the word >> "contributor" instead of "creator"? > > Basically, yes :-) And it's not a huge issue, I was just wondering if > there was justification for it being that way - which there is, it seems. We're also tracking this issue on the hAudio issues page now (Issue #D1): http://microformats.org/wiki/haudio-issues -- manu From info at weborganics.co.uk Tue Feb 5 11:54:51 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 5 11:55:02 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A8AD77.2070100@sanchothefat.com> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> Message-ID: <1202241291.9752.50.camel@weborganicscouk> Hello Robert On Tue, 2008-02-05 at 18:39 +0000, Robert O'Rourke wrote: > For cover tracks you'd have something like: > > > Original Artist - > Primal Scream > Here is the best action I have seen using roles, It may be useful to the discussion. from http://microformats.org/wiki/hcard-examples-in-wild-reviewed http://www.iowamilitaryveteransband.com/members/ their roles are the instruments that they play Roles are *NOT* defined in hAudio as such other than.. "The role attribute SHOULD be used to specify the contributor's responsibility related to the audio recording if hCard is utilized" http://microformats.org/wiki/haudio#Contributor the context comes from hcard "Information regarding the role of the object" http://microformats.org/wiki/existing-classes the "object" in most cases the person. whats good is, its user defined, we may be able to give sensible hints to what you put in there but really it's up to the publisher the choice is yours eg: "groupie", or "stage hand" could be fun!. "original artist", "band", "group", "quartet" are valid roles I would say so are "vocalist", "bassist", "drummer", "producer", "artist" for individuals If we had a "hPunchup" microformat you could have a role of "looser" ;) I AM worried that we should be using "title" instead of "role" in some cases... Thanks Martin McEvoy From guillaume at lebleu.org Tue Feb 5 12:02:07 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Tue Feb 5 12:02:11 2008 Subject: focus of microformats (was: Re: [uf-discuss] haudio contributor) In-Reply-To: <2vXMfsJPhIqHFwSi@pigsonthewing.org.uk> References: <47A5E5E2.2010206@hubmed.org> <47A60E74.5080209@digitalbazaar.com> <47A63856.2000103@hubmed.org> <47A73D8E.30406@digitalbazaar.com> <47A7A457.2090709@lebleu.org> <2vXMfsJPhIqHFwSi@pigsonthewing.org.uk> Message-ID: <47A8C0BF.2000709@lebleu.org> Andy Mabbett wrote: > > Everything is an edge case, depending on which point you're looking from. I'm conceding that I'm looking at these natural language examples from a particular perspective, the economic one, to decide what is an edge case or not, and that I'm just assuming that this economic perspective is the most important perspective to have when deciding where to focus the discussions. In particular, I'm looking at the following costs: - costs for the community to define a microformat that support these natural language, unstructured cases (this encompasses the include discussion). - costs for a human editor to understand the microformat and implement it. - costs for a software developer to implement a microformat parser. From what I have seen, these costs are high for the natural language examples in general, whether it's for hCard or hAudio. For other examples (structured content) these costs are low. The value is the same in both cases. Note that because these costs relate to unstructured content, they only apply to compound microformats which by nature imply structure, not elementary microformats. For instance, a microformat for a person's name (fn) is relatively easy to define, use and implement. Same thing for a money amount. A microformat for a person's complete contact information that works in all cases, not just the seminal blog's about box, has in comparison much higher costs of definition, use and implementation. A microformat for a resume, to the extent that a resume is highly structured is possible to define, use and implement. In comparison, a bio with the same content would most likely not be as easy. > > how many of us have access to "a well-trained semantic software > extractor", and what "music metadata" is widely used? It's not because I don't have something that others don't have it, and that I should ignore the fact that they have it in my decisions. Obviously, semantic extraction from the Web is of utmost importance for a lot of organizations, some with lots of resources, some with less, but all operating under the same economic rule: how can we lower the costs of understanding what people put on the Web with no/minimum costs/change of habits on their end. We all compete, and hopefully not a single one will win but some will be more successful for some classes of problems than others. Knowing what class of problems microformats are most likely to compete on is to me very important for the maximizing the returns on our time spent here. > > By your argument, we wouldn't need microformats at all. No. As I mentioned already, the costs listed above are the smallest in the case of structured content with little context. "Guillaume Lebleu. T(W): 415 408 5856" has less context and more structure than "My name is Guillaume Lebleu. My phone number at the office is 408-5856. My area code is 415.". The first example is a charm to microformat, the second one is less so. A semantic extractor will most likely do a poor job in first example and will do a better job at understanding the second example. As a result, it is my opinion that if microformats were officially focusing on structured content publishing (most known as blogging/social networking), we would have less discussions and probably more microformats. > > If that's where you want to concentrate your use of microformats, > that's fine, but that's not how I see them, and I see nothing in any > of the specs or other defining documentation which restricts them in > that way. There are no written rules as of today, and in theory we don't need such. But I've seen a lot of discussions and time spent on cases that don't make economic sense. The "it's on the Web, so it's relevant for microformats" was excellent to avoid the known pitfalls of standard organzation ("what if?") but also opened the can of worms in my opinion. It should in my opinion be: "it's elementary pieces of data or structured content on the Web, so it's relevant for microformats", or something similar. > I think that's an opinion - a restrictive one at that - not shared by > everyone here, certainly not by me, and not supported by past > experience of developing and using microformats. > Restriction is the negative name of focus. Focus is key to success. I've yet to see someone successful at "boiling the ocean". But I indeed don't know to what extent this opinion, or similar, is shared in this community. I only know you disagree with it. I'd be glad to see it put for a vote. Guillaume From info at weborganics.co.uk Tue Feb 5 12:05:09 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 5 12:05:19 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> Message-ID: <1202241909.9752.58.camel@weborganicscouk> On Tue, 2008-02-05 at 16:41 +0000, Andy Mabbett wrote: > In message <1202227070.9752.13.camel@weborganicscouk>, Martin McEvoy > writes > > >On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: > >> >Why doesn't the following work for you, then? > >> > > >> >
> >> > Primal Scream - > >> > Screamadelica > >> >
> >> > >> > >> That may be fine for someone who just wants to mark up some tracks they like > >> on a personal blog ... but an artist or record store may want to be able to > >> say who composed it, who performed it, who did studio production, who > >> remixed it, who a guest instumentalist was, what label released it, and > >> maybe even who distibutes it and want to be able to distinguish between > >> them. > > > >Oh but you can... > > > >
> > Screamadelica > > > > > > Artist - > > Primal Scream > > > > 1) that's not the model referred to in "Why doesn't the following work > for you, then?", above. "Roles" can be used to expand contributor into something a bit more precise > > 2) Where is the evidence, in examples like that quoted at the top if > this post, that people publish terms like "Artist" when referring to the > key creator? > > > > > Producer - > > Andrew Weatherall > > > > How does that cater for people who use "produced by" instead of > "producer"? > > > > > Vocals - > > Jah Wobble > > > > The role there is "singer" or "vocalist", not "vocals". Actually its "Bassist" on track 10 no less, sorry my fault ;) > > >The only thing I might add is vcard looks redundant? as the context > >describes audio, not buisness cards? > > hCard is not just for business cards. It's for "people, organisations or > places". Thank You. > From info at weborganics.co.uk Tue Feb 5 12:25:23 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 5 12:25:33 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <1202241291.9752.50.camel@weborganicscouk> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> <1202241291.9752.50.camel@weborganicscouk> Message-ID: <1202243123.9752.75.camel@weborganicscouk> On Tue, 2008-02-05 at 19:54 +0000, Martin McEvoy wrote: > "vocalist", "bassist", "drummer", "producer", "artist" for individual [...] I guess most of the above "roles" are actually "titles" their "jobs" so to speak. Nice learning curve I would say in that the definition of "role" is another grey area? Oh well just muddied the water more, some things do need a little clarification as far as microformats are concerned! PS: does anyone know WHY the entire rfc-2426 standard ported to hcard, It seems a lot? was there a "process" as such to say that it should?... http://microformats.org/wiki/hcard-cheatsheet Thanks Martin McEvoy From guillaume at lebleu.org Tue Feb 5 15:01:55 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Tue Feb 5 15:01:59 2008 Subject: [uf-discuss] Apple Data Detectors In-Reply-To: <47A884F7.5040800@ts0.com> References: <47A884F7.5040800@ts0.com> Message-ID: <47A8EAE3.1090101@lebleu.org> Thom Shannon wrote: > Not sure if anyone's mentioned this before but the new version of Apples > Mail has functionality similar to what microformats is trying to enable > (hCard and hCal) > > You can mouse over data in an email like addresses, phone numbers and > dates, then add them to your address book/calendar. > http://www.apple.com/business/videotips/?movie=maildatadetectors > > A few things spring to mind: > > a) Does it use microformats if they're present? - I just tested it, it > put the postcode in the state field so I guess not > > b) Wouldn't it be nice to get hold of their pattern matching code! > > c) Interesting how they've done the interface, not too far from some > mock-ups I saw for FF3, what can we learn from it? > Thom, you probably have found http://www.miramontes.com/writing/add-cacm/index.php, which describes ADD as it was introduced in 1998. The side column only mentions that the current implementation looks Livedoc/ADD-like. It was an interesting read to me. What I have been thinking more and more and what this tells me again is that the same way we talk of POSH and microformats, we could talk of plain text or plain old english formats, essentially standardizing how people write dates, addresses, etc on the Web or on their emails. Asking people to write "Tuesday, February 5, 2008" in this order, with the commas, etc. is very likely even simpler for normal people than writing Tuesday, February 5, 2008. Knowing that receivers will be able to do more with this just by writing it this way, like not forgetting your event, is a big value when comparing it to the additional costs. Even english writers can do this, not just Web developers. Of course, the issue is that this is currently an Apple-only plain-text microformats and implementing may be a bit more work than parsing a microformat (only guessing here). So cheap publishing costs, but possibly more expensive/not as widely available consumption mechanism. I wonder if this technology could not be used in a reverse way: detect formats as I'm typing (names, addresses, phone numbers, etc.) in plain english and convert them in microformats (cheap publishing costs, cheap consumption costs). The way I see it is that it would provide some code-autocompletion-like feature that makes a little calendar or contact list show up as I'm writing. For instance, if I start to type "Thanks Tho", "Tho" is recognized as being likely a person (following "Thanks" + I have two people in my contacts matching "Tho"), and I'm prompted to confirm whether I'm talking about Thom or Thomas. I select Thom and behind the seen the right microformat is added to my content for the convenience of those that will consume my content. Guillaume From ryan at theryanking.com Tue Feb 5 15:00:34 2008 From: ryan at theryanking.com (Ryan King) Date: Tue Feb 5 15:07:04 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: References: Message-ID: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> On Feb 5, 2008, at 8:23 AM, Toby A Inkster wrote: > Tantek =?ISO-8859-1?B?xw==?=elik wrote: > >> 1. class is an unordered set of values per HTML4. introducing >> ordering >> is a non-starter both from a violation of HTML4 spec perspective and >> likely requiring of rewriting HTML4 parsers to maintain an ordering >> where they currently don't. > > A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the > class > list is unordered. > > It does claim that it's a "set" of class names, and in mathematical > parlance sets are unordered by definition, and must not contain > duplicates, but it's unlikely that the framers of the HTML 4.01 spec > intended the world "set" to be interpreted in that way -- far more > likely > they were referring to the layman's definition of the word. Specs aren't generally written in layman's terms. -ryan From andy at pigsonthewing.org.uk Tue Feb 5 15:35:20 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 5 15:37:00 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A8AD77.2070100@sanchothefat.com> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> Message-ID: <$eKeDnT4KPqHFwA5@pigsonthewing.org.uk> In message <47A8AD77.2070100@sanchothefat.com>, Robert O'Rourke writes >How about removing the 'contributor' class from the key creator's >vcard? It would make sense to me to group contributors separately to >the creator. The vcard attached to the hAudio would denote the original >creator. That would still not distinguish between "creator" as performer (Elvis Presley); as composer (Mozart); or as both (Bob Dylan). -- Andy Mabbett From pmw57 at xtra.co.nz Tue Feb 5 16:13:53 2008 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Tue Feb 5 16:13:56 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> References: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> Message-ID: <18050cf90802051613o256923fdte550071bf5480fab@mail.gmail.com> On Feb 6, 2008 12:00 PM, Ryan King wrote: > Specs aren't generally written in layman's terms. If the ordering of class names were supposed to to have some special significance, there would be further information about such a specific order. In this case a lack of evidence points to no importance in the order of the class names. Attributes are unordered because if they were, it would make life a lot more difficult for those using them. Likewise for class names. Some browsers do impose their own ordering on the attributes, and other scripts may affect the ordering of class names too. As such any reliance on a particular order is liable to fall apart rather quickly. -- Paul Wilkins From karl at w3.org Tue Feb 5 17:40:17 2008 From: karl at w3.org (Karl Dubost) Date: Tue Feb 5 17:40:26 2008 Subject: [uf-discuss] Apple Data Detectors In-Reply-To: <47A8EAE3.1090101@lebleu.org> References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org> Message-ID: just FYI Le 6 f?vr. 2008 ? 08:01, Guillaume Lebleu a ?crit : > Asking people to write "Tuesday, February 5, 2008" in this order, > with the commas, etc. is very likely even simpler for normal people > than writing Tuesday, February > 5, 2008. I have tested in French, Japanese and English, and it works. http://lists.w3.org/Archives/Public/www-archive/2007Dec/0114 http://lists.w3.org/Archives/Public/www-archive/2007Dec/0115 In Japanese though, they do not handle era patterns which is commonly used in Japan. I filed a bug report about it. -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool From mdagn at spraci.com Tue Feb 5 20:58:43 2008 From: mdagn at spraci.com (Michael MD) Date: Tue Feb 5 20:58:45 2008 Subject: [uf-discuss] Apple Data Detectors References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org> Message-ID: <003801c8687c$f340c200$116bacca@COMCEN> > people write dates, addresses, etc on the Web or on their emails. Asking > people to write "Tuesday, February 5, 2008" in this order, with the > commas, etc. is very likely even simpler for normal people than writing you would *think* so - and it would certainly be nice .... but the behaviour or most people out in the real world does not suggest that this would be easy. Most freeform text dates I see out there are missing the year (how is a machine supposed to work out what year was intended?)... and a lot of them are in useless ambiguous formats like dd/mm/yyyy or mm/dd/yy - ) ... then there all those other variations... to many to list! I've experimented a bit with trying to parse freeform text dates ... the problem is as soon as its loose enough to pick up most of the common ways people write dates it then also starts to pick up a lot of other stuff as dates that were not intended to be dates at all! From zen at zenpsycho.com Tue Feb 5 21:42:07 2008 From: zen at zenpsycho.com (Breton Slivka) Date: Tue Feb 5 21:42:10 2008 Subject: [uf-discuss] Apple Data Detectors In-Reply-To: <003801c8687c$f340c200$116bacca@COMCEN> References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org> <003801c8687c$f340c200$116bacca@COMCEN> Message-ID: I think what was intended, was rather than try to write a parser that picks up most styles of natural language dates, as you suggest- Instead write a parser that only picks up one or two standard styles of dates. Much like the style guides that are used in academia for writing standard forms of citations, and other things. Decide on a freeform text format that you know a machine can pick up, and excludes ambiguous date formats. But you do raise a valid point here: Even if you do that, you invite the assumption from authors, that since it can pick up this format of date, or that format, then perhaps it will pick up THIS format as well. So authors will write badly formed versions of this freeform standard. There will be typos, too. All kinds of things can happen. But much of these bad things can be aleviated by one of the other suggestions in this thread: As-you-type validation. As soon as you type in "Feb" for instance, autocomplete style routines kick into action, helping the author write the date in exactly the right format. Then as they hit "publish" it becomes a microformat, proper, with markup and all. On Feb 6, 2008 3:58 PM, Michael MD wrote: > > people write dates, addresses, etc on the Web or on their emails. Asking > > people to write "Tuesday, February 5, 2008" in this order, with the > > commas, etc. is very likely even simpler for normal people than writing > > > you would *think* so - and it would certainly be nice .... but the behaviour > or most people out in the real world does not suggest that this would be > easy. > > Most freeform text dates I see out there are missing the year (how is a > machine supposed to work out what year was intended?)... > and a lot of them are in useless ambiguous formats like dd/mm/yyyy or > mm/dd/yy - ) ... then there all those other variations... to many to list! > > I've experimented a bit with trying to parse freeform text dates ... the > problem is as soon as its loose enough to pick up most of the common ways > people write dates it then also starts to pick up a lot of other stuff as > dates that were not intended to be dates at all! > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mdagn at spraci.com Wed Feb 6 01:20:22 2008 From: mdagn at spraci.com (Michael MD) Date: Wed Feb 6 01:20:24 2008 Subject: [uf-discuss] Apple Data Detectors References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org><003801c8687c$f340c200$116bacca@COMCEN> Message-ID: <00b401c868a1$807713d0$116bacca@COMCEN> > But much of these bad things can be aleviated by one of the other > suggestions in this thread: As-you-type validation. As soon as you > type in "Feb" for instance, autocomplete style routines kick into > action, helping the author write the date in exactly the right format. > Then as they hit "publish" it becomes a microformat, proper, with > markup and all. > certainly ... and such things can be good for forms on websites ... but I was trying get some useful data out of a whole lot of press releases people send me. (stuff that is normally just ignored because there is nobody with the spare time to re-enter it manually!) --- if only event promoters would mark up those html emails with hCalendar! ---- (and hCard/geo for venues/locations/cities/countries) :-) ...but of course we are unlikely to see much of that until the email and word processing software they are actually using has tools for adding such markup to their emails. From rob at sanchothefat.com Wed Feb 6 03:56:04 2008 From: rob at sanchothefat.com (Robert O'Rourke) Date: Wed Feb 6 03:56:14 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <$eKeDnT4KPqHFwA5@pigsonthewing.org.uk> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> <$eKeDnT4KPqHFwA5@pigsonthewing.org.uk> Message-ID: <47A9A054.80107@sanchothefat.com> Andy Mabbett wrote: > In message <47A8AD77.2070100@sanchothefat.com>, Robert O'Rourke > writes > >> How about removing the 'contributor' class from the key creator's >> vcard? It would make sense to me to group contributors separately to >> the creator. The vcard attached to the hAudio would denote the >> original creator. > > That would still not distinguish between "creator" as performer (Elvis > Presley); as composer (Mozart); or as both (Bob Dylan). > Ah yes, so would you say 'performer', 'creator' and 'composer' are roles and not different to being a contributor? It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. I know you had a problem with it but if the role 'artist' is vague in so far as 'performer', 'composer' etc.. are concerned then perhaps it would be useful for exactly that reason. What do you think? From rob at sanchothefat.com Wed Feb 6 04:29:12 2008 From: rob at sanchothefat.com (Robert O'Rourke) Date: Wed Feb 6 04:29:43 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <1202241291.9752.50.camel@weborganicscouk> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> <1202241291.9752.50.camel@weborganicscouk> Message-ID: <47A9A818.90804@sanchothefat.com> Martin McEvoy wrote: > Hello Robert > Hi Martin, nice meeting you the other day > On Tue, 2008-02-05 at 18:39 +0000, Robert O'Rourke wrote: > >> For cover tracks you'd have something like: >> >> >> Original Artist - >> Primal Scream >> >> > > Here is the best action I have seen using roles, It may be useful to the > discussion. > > from http://microformats.org/wiki/hcard-examples-in-wild-reviewed > > > http://www.iowamilitaryveteransband.com/members/ > > their roles are the instruments that they play > > Roles are *NOT* defined in hAudio as such other than.. > > "The role attribute SHOULD be used to specify the contributor's > responsibility related to the audio recording if hCard is utilized" > http://microformats.org/wiki/haudio#Contributor > > > the context comes from hcard > > "Information regarding the role of the object" > http://microformats.org/wiki/existing-classes > > the "object" in most cases the person. > > whats good is, its user defined, we may be able to give sensible hints > to what you put in there but really it's up to the publisher the choice > is yours eg: "groupie", or "stage hand" could be fun!. > > "original artist", "band", "group", "quartet" are valid roles I would > say > > so are > > "vocalist", "bassist", "drummer", "producer", "artist" for individuals > > If we had a "hPunchup" microformat you could have a role of "looser" ;) > Ha! and a vevent for every punch. Never thought of marking up a boxing match until now! > I AM worried that we should be using "title" instead of "role" in some > cases... > That depends if you look at a piece of music as having "jobs" associated with it. Is a piece of music some work that people were employed to create or only a creative endeavour?. It can be either, but as far as hAudio is concerned I would say "role" is most appropriate. Thoughts? > Thanks > > Martin McEvoy > > Cheers, Rob From info at weborganics.co.uk Wed Feb 6 05:29:49 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed Feb 6 05:30:08 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A9A818.90804@sanchothefat.com> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> <1202241291.9752.50.camel@weborganicscouk> <47A9A818.90804@sanchothefat.com> Message-ID: <1202304589.15850.19.camel@weborganicscouk> On Wed, 2008-02-06 at 12:29 +0000, Robert O'Rourke wrote: > Martin McEvoy wrote: > > Hello Robert > > > > Hi Martin, nice meeting you the other day Well met too its surprising the places that you meet people ;) > > > On Tue, 2008-02-05 at 18:39 +0000, Robert O'Rourke wrote: > > > >> For cover tracks you'd have something like: > >> > >> > >> Original Artist - > >> Primal Scream > >> > >> > > > > Here is the best action I have seen using roles, It may be useful to the > > discussion. > > > > from http://microformats.org/wiki/hcard-examples-in-wild-reviewed > > > > > > http://www.iowamilitaryveteransband.com/members/ > > > > their roles are the instruments that they play > > > > Roles are *NOT* defined in hAudio as such other than.. > > > > "The role attribute SHOULD be used to specify the contributor's > > responsibility related to the audio recording if hCard is utilized" > > http://microformats.org/wiki/haudio#Contributor > > > > > > the context comes from hcard > > > > "Information regarding the role of the object" > > http://microformats.org/wiki/existing-classes > > > > the "object" in most cases the person. > > > > whats good is, its user defined, we may be able to give sensible hints > > to what you put in there but really it's up to the publisher the choice > > is yours eg: "groupie", or "stage hand" could be fun!. > > > > "original artist", "band", "group", "quartet" are valid roles I would > > say > > > > so are > > > > "vocalist", "bassist", "drummer", "producer", "artist" for individuals > > > > If we had a "hPunchup" microformat you could have a role of "looser" ;) > > > > Ha! and a vevent for every punch. Never thought of marking up a boxing > match until now! It could be reused in hArgument? ...chuckle.... > > > I AM worried that we should be using "title" instead of "role" in some > > cases... > > > > That depends if you look at a piece of music as having "jobs" associated > with it. Is a piece of music some work that people were employed to > create or only a creative endeavour?. In the case of manufactured "bands" I would say that all involved are employed and have Job Titles... as do professional musicians maybe. > It can be either, but as far as > hAudio is concerned I would say "role" is most appropriate. Thoughts? I agree Roles are more important than their job titles as the two may not be related or have any context in the making of a piece of audio. I think the problem with the above is quite often in audio roles and job titles are quite often the same.. Manu explained the differences quite nicley to me.. A role is "what you do", where a title is "what your official title is at the organization". Role is hardly ever used in hcard in the "real world",and as a result not much info, I think maybe more information about "role" can be added to the hAudio wiki, perhaps even some good recommendations? Thanks Martin McEvoy > > > Thanks > > > > Martin McEvoy > > > > > > Cheers, > Rob From rob at sanchothefat.com Wed Feb 6 07:06:37 2008 From: rob at sanchothefat.com (Robert O'Rourke) Date: Wed Feb 6 07:07:15 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <1202304589.15850.19.camel@weborganicscouk> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> <1202241291.9752.50.camel@weborganicscouk> <47A9A818.90804@sanchothefat.com> <1202304589.15850.19.camel@weborganicscouk> Message-ID: <47A9CCFD.50908@sanchothefat.com> Martin McEvoy wrote: > On Wed, 2008-02-06 at 12:29 +0000, Robert O'Rourke wrote: > >> Martin McEvoy wrote: >> >>> I AM worried that we should be using "title" instead of "role" in some >>> cases... >>> >>> >> That depends if you look at a piece of music as having "jobs" associated >> with it. Is a piece of music some work that people were employed to >> create or only a creative endeavour?. >> > > In the case of manufactured "bands" I would say that all involved are > employed and have Job Titles... as do professional musicians maybe. > > >> It can be either, but as far as >> hAudio is concerned I would say "role" is most appropriate. Thoughts? >> > > I agree Roles are more important than their job titles as the two may > not be related or have any context in the making of a piece of audio. > > I think the problem with the above is quite often in audio roles and job > titles are quite often the same.. > > Manu explained the differences quite nicley to me.. > > A role is "what you do", where a title is "what your > official title is at the organization". > In that case in relation to hAudio "role" is defnitely more appropriate. Each individual's "title" is an arbritary thing - say when two people who fulfil the same roles at two different organisations have different "title"s. Everyone involved with a recording had a "role" to play but not necessarily an official "title". As a side note, is "title" only really used if "org" has been indicated? And are groups/bands considered to be an organisation? Solo artists wouldn't have any particular "org" except maybe the record label, in which case their "title" would be Artist. A musician with no record label or contract has no employer and therefore no official "title" so the use of "role" would be better suited to the majority of cases. > Role is hardly ever used in hcard in the "real world",and as a result > not much info, I think maybe more information about "role" can be added > to the hAudio wiki, perhaps even some good recommendations? > > That would be good to see, there isn't a whole lot of detail about the use of role in hcard on the wiki. > Thanks > > Martin McEvoy > > From mail at tobyinkster.co.uk Wed Feb 6 07:27:14 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Feb 6 09:05:15 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" References: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> Message-ID: Ryan King wrote: > Toby A Inkster wrote: > >> It does claim that it's a "set" of class names, and in mathematical >> parlance sets are unordered by definition, and must not contain >> duplicates, but it's unlikely that the framers of the HTML 4.01 spec >> intended the world "set" to be interpreted in that way -- far more >> likely they were referring to the layman's definition of the word. > > Specs aren't generally written in layman's terms. What I meant was that the vast majority of the words used in most specifications are not explicitly defined, nor are other normative references provided giving a definition of them. This is fair enough. You don't want to read through an enormous glossary at the end of a specification defining words such as "first", "down" and "the". When a word is not explicitly defined in the specification itself, or in a reference, one should assume that the normal everyday meaning of the word is implied. I seem to remember reading somewhere that of all the entries in the Oxford English Dictionary, the word "set" has the longest, spanning several pages. In the context used in the HTML 4.01 spec, I find it unlikely that they were specifically referring to the mathematical usage of the word "set", unless they were attempting to be deliberately obscure. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 21:25.] Looking Ahead to Perl 6 http://tobyinkster.co.uk/blog/2008/02/05/perl6/ From mail at tobyinkster.co.uk Wed Feb 6 07:36:25 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Feb 6 09:05:17 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" References: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> <18050cf90802051613o256923fdte550071bf5480fab@mail.gmail.com> Message-ID: Paul Wilkins wrote: > If the ordering of class names were supposed to to have some special > significance, there would be further information about such a specific > order. In this case a lack of evidence points to no importance in the > order of the class names. If the ordering of paragraphs were supposed to have some special significance, there would be further information about such a specific order. In this case a lack of evidence points to no importance in the order of paragraphs. Thus the following HTML documents may be rendered identically by a conforming browser, right? Document one

one

two

Document two

two

one

The order of the paragraphs doesn't have a "special significance", yet the paragraphs do have an inherent order. Similarly, the order of class names within a class attribute don't have a special significance attached to them by the HTML spec, but they do still have an inherent order. -- Toby A Inkster BSc (Hons) ARCS [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 7 days, 21:47.] Looking Ahead to Perl 6 http://tobyinkster.co.uk/blog/2008/02/05/perl6/ From msporny at digitalbazaar.com Wed Feb 6 09:35:10 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Feb 6 10:23:53 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A9A054.80107@sanchothefat.com> References: <200802051456.m15EueN69142@proxy.syd.comcen.com.au> <1202227070.9752.13.camel@weborganicscouk> <47A8AD77.2070100@sanchothefat.com> <$eKeDnT4KPqHFwA5@pigsonthewing.org.uk> <47A9A054.80107@sanchothefat.com> Message-ID: <47A9EFCE.5090407@digitalbazaar.com> Robert O'Rourke wrote: > Ah yes, so would you say 'performer', 'creator' and 'composer' are roles > and not different to being a contributor? Yes, that is why 'contributor' was picked, rather than 'performer', 'creator', or 'composer'. :) > It would be useful to have a > more blanket term for instances where one person has multiple roles of > that kind. You can always specify multiple 'role's in hCard to state that the person had more than one role. > I know you had a problem with it but if the role 'artist' is > vague in so far as 'performer', 'composer' etc.. are concerned then > perhaps it would be useful for exactly that reason. What do you think? I've got no problem adding more "contributor types" as convenience classes for "composer", "performer", "publisher", "label", etc. However, like all things Microformats - they've got to be backed up by examples. The issue isn't "wouldn't these be really cool to have", but rather "we need to demonstrate that there