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 are enough of these on the web to justify adding more terms to hAudio". -- manu From andy at pigsonthewing.org.uk Wed Feb 6 12:11:14 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 6 12:43:00 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: In message <47A9A054.80107@sanchothefat.com>, Robert O'Rourke writes > would you say 'performer', 'creator' and 'composer' are roles and not >different to being a contributor? They are all contributors, but they are sub-sets of the set of contributors (and hence are more granular). >It would be useful to have a more blanket term for instances where one >person has multiple roles of that kind. Why would it? How is: Bob Dylan more useful than: Bob Dylan The only time I can see the former class name being more useful is where the finer granularity is unknown or unavailable. -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Feb 6 12:20:26 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 6 12:49:18 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A9CCFD.50908@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> <1202304589.15850.19.camel@weborganicscouk> <47A9CCFD.50908@sanchothefat.com> Message-ID: In message <47A9CCFD.50908@sanchothefat.com>, Robert O'Rourke writes >And are groups/bands considered to be an organisation? Yes: Pink Floyd not least because the alternative: Pink Floyd would be "optimised" (sic) to have a given name of "Pink" and a family name of "Floyd". -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Feb 6 12:17:46 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 6 12:49:19 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: In message <1202304589.15850.19.camel@weborganicscouk>, Martin McEvoy writes >Role is hardly ever used in hcard in the "real world" I use it. In fact: might include the first ever hCard with a role of "Lighthouse keeper"! -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Feb 6 12:24:59 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 6 12:49:19 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A9EFCE.5090407@digitalbazaar.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> <47A9EFCE.5090407@digitalbazaar.com> Message-ID: <3CCcEVabehqHFwgZ@pigsonthewing.org.uk> In message <47A9EFCE.5090407@digitalbazaar.com>, Manu Sporny writes >> 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. One cannot "always" specify such things, because the page content (e.g. "Beethoven's Fifth") does not always spell out such terms. >> 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 are enough of these on the web to >justify adding more terms to hAudio". Like I said a day or two ago: "for the guidance of wise men and..." -- Andy Mabbett From walter at psybernet.co.nz Wed Feb 6 13:38:15 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Wed Feb 6 13:48:25 2008 Subject: [uf-discuss] Microformats, how are they used? Message-ID: <47AA28C7.7060101@psybernet.co.nz> Hi, New to Microformats and this list. I am trying to get my head around Microformats for an art project I have in mind, and am following the "process" and Poshifying my site. I have added a few new tags, rel="spouse", rel="colleague" on my WordPress blog I am curious how these get used. I have installed Operator and Tail Export on Firefox, I can't see anything show up other than on the source file. With hReview, I have one that is seen by Operator and Tail View (with some errors indicated), yet I wonder why I one would mark up reviews in this way. I can see some uses The source file is more human readable with meaning CSS can be used more effectively hCard can be imported to Outlook I am hoping to aggregate some items in a particular way, first I want to learn more and see examples of Microformats put to use. Warm wishes, Walter From guillaume at lebleu.org Wed Feb 6 10:34:40 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Wed Feb 6 13:57:48 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47A9CCFD.50908@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> <1202304589.15850.19.camel@weborganicscouk> <47A9CCFD.50908@sanchothefat.com> Message-ID: <47A9FDC0.3090209@lebleu.org> Robert O'Rourke wrote: > Martin McEvoy wrote: >> >> >> 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". >> I concur. I would add that title has a social function that role does not have. A title is inherently something issued by an entity (author, organization, etc.) to another entity (work of art, employee) "because it can", i.e. because the author owned that right b/c he created the art work, or the organization owned that right b/c it offered the job. It typically follows social codes known to the organization/community where it will be used. In the case of a title issued by a U.S. business organization, it uses the "VP of ...", "SVP of ...", "director", etc. to communicates clearly the rights/responsibilities/roles of the person within the organization. In other words, a title plays a social role in an organization/society. As a result, titles are more important in large, stratified organizations/societies. A role/occupation does not play such a role. It merely describes. Of course the two are related: you would not give someone a role and give them an unrelated title. In the context of a band, I'd say that a band does not really fit the profile of that stratified, large organization, and the notion of title is not really relevant in this context. It may be though in the case of a record company. Guillaume From pmw57 at xtra.co.nz Wed Feb 6 11:50:14 2008 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Wed Feb 6 14:25:48 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: References: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> <18050cf90802051613o256923fdte550071bf5480fab@mail.gmail.com> Message-ID: <18050cf90802061150v1bc08db4uaa44aeaf0d217daa@mail.gmail.com> On Feb 7, 2008 4:36 AM, Toby A Inkster wrote: > 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. There is an inherent order, but that order can not be relied upon to convey any useful information. -- Paul Wilkins From msporny at digitalbazaar.com Wed Feb 6 13:55:50 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Feb 6 15:53:52 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <3CCcEVabehqHFwgZ@pigsonthewing.org.uk> 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> <47A9EFCE.5090407@digitalbazaar.com> <3CCcEVabehqHFwgZ@pigsonthewing.org.uk> Message-ID: <47AA2CE6.8090505@digitalbazaar.com> Andy Mabbett wrote: > In message <47A9EFCE.5090407@digitalbazaar.com>, Manu Sporny > writes > >>> 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. > > One cannot "always" specify such things, because the page content (e.g. > "Beethoven's Fifth") does not always spell out such terms. Right, point taken. >>> 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 are enough of these on the web to >> justify adding more terms to hAudio". > > Like I said a day or two ago: "for the guidance of wise men and..." Alright, wise-guy =P - put the terms that you would like included on the haudio-issues wiki and let's start tracking them. -- manu From guillaume at lebleu.org Wed Feb 6 16:13:28 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Wed Feb 6 16:16:48 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: 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> <47A9CCFD.50908@sanchothefat.com> Message-ID: <47AA4D28.9040009@lebleu.org> Andy Mabbett wrote: > In message <47A9CCFD.50908@sanchothefat.com>, Robert O'Rourke > writes > > >> And are groups/bands considered to be an organisation? >> > > Yes: > > Pink Floyd > > not least because the alternative: > > Pink Floyd > > would be "optimised" (sic) to have a given name of "Pink" and a family > name of "Floyd". > > I don't disagree that groups/bands should be considered organisations. That said, I don't think the reason offered here is a strong one. The issue described is directly related to FN's (over?)reuse beyond its original vCard scope of person names, to cover any name. [Not only has this led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address] Guillaume From markwhite28 at comcast.net Wed Feb 6 23:40:40 2008 From: markwhite28 at comcast.net (Robert Mark White) Date: Wed Feb 6 23:41:47 2008 Subject: [uf-discuss] Auto Discovery of XFN Message-ID: <000f01c8695c$bda2cd10$6500a8c0@Bilbo> I have a homepage that I use as my OpenId URL. I have the url of my homepage delegated to a OpenId provider. In the header of that homepage I have setup some auto discovery links in html. I believe this aids in the discovery of my information. I really do want a portable social network but I hope to bypass the need to "scrape" my information off of a social web site by providing a link as to where the information I want to provide is already. For example, For purely humorous and historical purposes I have the link below. The link below I use for auto discovery of my foaf file. I know this link works as the Semantic Radar add on in Foxfire finds foaf files all over the net for me. The link below I use for auto discovery of my avatar/pavatar. The link below is the link I use for my vCard/hCard. I am only guessing but I am pretty sure that the link about is correct one. I also have a page on my website with my xfn links but I am unable to figure out the correct information for the auto discovery of it. Can someone please enlighten me as to the correct values for this type link above? Sincerely yours, mark From andy at pigsonthewing.org.uk Thu Feb 7 01:02:37 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 01:04:00 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47AA4D28.9040009@lebleu.org> 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> <47A9CCFD.50908@sanchothefat.com> <47AA4D28.9040009@lebleu.org> Message-ID: In message <47AA4D28.9040009@lebleu.org>, Guillaume Lebleu writes >> not least because the alternative: >> >> Pink Floyd >> >> would be "optimised" (sic) to have a given name of "Pink" and a family >> name of "Floyd". >> >> >I don't disagree that groups/bands should be considered organisations. > >That said, I don't think the reason offered here is a strong one. Neither do I; that's why I said "not least". -- Andy Mabbett From Michael.Smethurst at bbc.co.uk Thu Feb 7 01:55:30 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Feb 7 03:24:24 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47AA4D28.9040009@lebleu.org> Message-ID: On 7/2/08 00:13, "Guillaume Lebleu" wrote: > I don't disagree that groups/bands should be considered organisations. This takes me back several months (June 2007) to a thread about whether both music:groups and music:artists_singular should be marked up as organisations: http://www.mail-archive.com/microformats-discuss@microformats.org/msg07887.h tml At the time Scott Reynen suggested: If it's just a generic contact that you know nothing about, I'd say just use fn, as adding org is potentially incorrect information. But if you know it's a music act, I think it makes sense to consider even an individual performer's name to be an organization name in that context. I'd say there's a difference, for example, between Norah Jones the person, who would be Norah Jones, and Norah Jones the musical act, which would be Norah Jones. > > That said, I don't think the reason offered here is a strong one. The > issue described is directly related to FN's (over?)reuse beyond its > original vCard scope of person names, to cover any name. Agreed. The problem also arises with artists like Eminem, Madonna, Prince. How is fn optimisation supposed to work here? > > [Not only has this led to the fn/title debate, but it seems some > implementors are confused between following the vCard semantics (FN only > for person names) or the hCard ones (FN for any name). See. > http://cinematreasures.org/theater/365/, which uses an empty FN, > resulting in their vCard not being detected by Operator, only the address] > > Guillaume > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From andy at pigsonthewing.org.uk Thu Feb 7 03:44:41 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 03:49:11 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification Message-ID: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> The change made recently, to the hCard spec: affects not only hCard but also other microformats; it has implications for both current parsers and published microformats, but seems to have been made without prior notification or debate. Note, for example, that it precludes an event's hCalendar and the event organiser's hCard from sharing the URL in a single "A" element. I propose that the change be undone; and not reintroduced until the implications are more fully understood and widely agreed. -- Andy Mabbett ** via webmail ** From andy at pigsonthewing.org.uk Thu Feb 7 03:59:02 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 03:59:06 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <47AA4D28.9040009@lebleu.org> Message-ID: <10364.80.249.57.38.1202385542.squirrel@www.gradwell.com> On Thu, February 7, 2008 09:55, Michael Smethurst wrote: > This takes me back several months (June 2007) to a thread about whether > both music:groups and music:artists_singular should be marked up as > organisations: > http://www.mail-archive.com/microformats-discuss@microformats.org/msg07887.html Please use the canonical archives when citing mailing list posts; we can't know that third-arty archives are accurate or comprehensive, or that they will always be available. that post is: > At the time Scott Reynen suggested: > > If it's just a generic contact that you know nothing about, I'd say just > use fn, as adding org is potentially incorrect information. But if you > know it's a music act, I think it makes sense to consider even an > individual performer's name to be an organization name in that context. > I'd say there's > a difference, for example, between Norah Jones the person, who would be > Norah Jones, and Norah Jones the musical act, > which would be Norah Jones. That strikes me as no more sensible now than it did then. If I cite her, as "Norah Jones said", am I referring to her as a person, or an organisation? Would her hCard's date of both refer to the day she left her mother's womb, or the day the supposed "organisation" was founded? Does Mozart become an organisation if I refer to his symphonies, but not if I refer to his marriage? Do Winston Churchill or Ghandi suddenly become organisations if we refer to a recording of one of their speeches, but not one of their books? > ...with artists like Eminem, Madonna, Prince. > How is fn optimisation supposed to work here? Exactly as it does at present. Those are both formatted names and nicknames (and remain nicknames, if you also include the fn of "Marshall Bruce Mathers III", "Madonna Louise Ciccone Ritchie " or "Prince Rogers Nelson"). -- Andy Mabbett ** via webmail ** From info at weborganics.co.uk Thu Feb 7 05:05:02 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 7 05:05:18 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: Message-ID: <1202389502.23006.18.camel@weborganicscouk> On Thu, 2008-02-07 at 09:55 +0000, Michael Smethurst wrote: > Agreed. The problem also arises with artists like Eminem, Madonna, > Prince. > How is fn optimisation supposed to work here? As we find a lot in music your above examples are people and Organizations. How it appears, I would guess is how you define it eg: [a] "Buy the Single Like a Virgin by Madonna" Madonna is the Organization, with Producers Artists Songwriters etc.. associated with it, "fn org" seems appropriate usage? [b] "I Like Madonna's vocals on Like a Virgin" You would be talking about Madonna the person in the above statement so just "fn" would be used. Thanks Martin McEvoy From thom at ts0.com Thu Feb 7 05:10:35 2008 From: thom at ts0.com (Thom Shannon) Date: Thu Feb 7 05:10:42 2008 Subject: [uf-discuss] Auto Discovery of XFN In-Reply-To: <000f01c8695c$bda2cd10$6500a8c0@Bilbo> References: <000f01c8695c$bda2cd10$6500a8c0@Bilbo> Message-ID: <47AB034B.8000004@ts0.com> > Can someone please enlighten me as to the correct values for this type link > above? It depends on the implementation but basically you want to link to another page and say that it is also you, using rel="me". The easiest way to get your xfn links links detected by Googles Social Graph API is to just add them in the page. If you look on my blog (which is also my openid) http://www.ts0.com/ you'll see XFN links to a few of my friends, but also links to my profile pages on other sites with rel="me". The SG API then knows all those profiles are me too and finds all my friends from them. From Michael.Smethurst at bbc.co.uk Thu Feb 7 06:33:47 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Feb 7 06:33:51 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <10364.80.249.57.38.1202385542.squirrel@www.gradwell.com> Message-ID: On 7/2/08 11:59, "Andy Mabbett" wrote: > On Thu, February 7, 2008 09:55, Michael Smethurst wrote: > >> This takes me back several months (June 2007) to a thread about whether >> both music:groups and music:artists_singular should be marked up as >> organisations: > >> http://www.mail-archive.com/microformats-discuss@microformats.org/msg07887.ht >> ml > > Please use the canonical archives when citing mailing list posts; we can't > know that third-arty archives are accurate or comprehensive, or that they > will always be available. Many, many apologies > > that post is: > > > ml> > >> At the time Scott Reynen suggested: >> >> If it's just a generic contact that you know nothing about, I'd say just >> use fn, as adding org is potentially incorrect information. But if you >> know it's a music act, I think it makes sense to consider even an >> individual performer's name to be an organization name in that context. >> I'd say there's >> a difference, for example, between Norah Jones the person, who would be >> Norah Jones, and Norah Jones the musical act, >> which would be Norah Jones. > > That strikes me as no more sensible now than it did then. If I cite her, > as "Norah Jones said", am I referring to her as a person, or an > organisation? > > Would her hCard's date of both refer to the day she left her mother's > womb, or the day the supposed "organisation" was founded? > > Does Mozart become an organisation if I refer to his symphonies, but not > if I refer to his marriage? > > Do Winston Churchill or Ghandi suddenly become organisations if we refer > to a recording of one of their speeches, but not one of their books? I didn't say I supported this view. I just brought it back up cos it seemed relevant > >> ...with artists like Eminem, Madonna, Prince. >> How is fn optimisation supposed to work here? > > Exactly as it does at present. Those are both formatted names and > nicknames (and remain nicknames, if you also include the fn of "Marshall > Bruce Mathers III", "Madonna Louise Ciccone Ritchie " or "Prince Rogers > Nelson"). Not sure I follow. The hcard wiki page says nickname optimisation happens when " "FN" and "ORG" are not the same, and the value of the "FN" property is exactly one word. What would: Madonna Louise Ciccone Ritchie Result in? Also what about artists like Plastic Bertram? I assume that's not a given + family name combination http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From thom at ts0.com Thu Feb 7 07:14:57 2008 From: thom at ts0.com (Thom Shannon) Date: Thu Feb 7 07:15:09 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> Message-ID: <47AB2071.9020706@ts0.com> perhaps there was prior discussion and agreement that was just a long time ago? Have you searched the archives or asked Tantek directly? Andy Mabbett wrote: > The change made recently, to the hCard spec: > > > > affects not only hCard but also other microformats; it has implications > for both current parsers and published microformats, but seems to have > been made without prior notification or debate. > > Note, for example, that it precludes an event's hCalendar and the event > organiser's hCard from sharing the URL in a single "A" element. > > I propose that the change be undone; and not reintroduced until the > implications are more fully understood and widely agreed. > > From guillaume at lebleu.org Thu Feb 7 07:46:27 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Thu Feb 7 07:46:32 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: 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> <47A9CCFD.50908@sanchothefat.com> <47AA4D28.9040009@lebleu.org> Message-ID: <47AB27D3.30608@lebleu.org> Andy Mabbett wrote: > In message <47AA4D28.9040009@lebleu.org>, Guillaume Lebleu > writes > >>> not least because the alternative: >>> >>> Pink Floyd >>> >>> would be "optimised" (sic) to have a given name of "Pink" and a family >>> name of "Floyd". >>> >>> >> I don't disagree that groups/bands should be considered organisations. >> >> That said, I don't think the reason offered here is a strong one. > > Neither do I; that's why I said "not least". > Sorry if I misinterpreted: I'm not a native english speaker. Doesn't "not least because [reason]" means that [reason] is not the least reason, i.e. a strong one? Guillaume From andy at pigsonthewing.org.uk Thu Feb 7 08:45:17 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 08:50:45 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <47AB27D3.30608@lebleu.org> 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> <47A9CCFD.50908@sanchothefat.com> <47AA4D28.9040009@lebleu.org> <47AB27D3.30608@lebleu.org> Message-ID: <34384.80.249.57.38.1202402717.squirrel@www.gradwell.com> On Thu, February 7, 2008 15:46, Guillaume Lebleu wrote: > Sorry if I misinterpreted: I'm not a native english speaker. > Doesn't "not least because [reason]" means that [reason] is not the > least reason, i.e. a strong one? Literally, yes, but in colloquial use it can mean "not the weakest, but far from the strongest, reason". Apologies for causing confusion. -- Andy Mabbett ** via webmail ** From andy at pigsonthewing.org.uk Thu Feb 7 07:30:11 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 09:02:17 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <10364.80.249.57.38.1202385542.squirrel@www.gradwell.com> Message-ID: <48277.80.249.57.38.1202398211.squirrel@www.gradwell.com> On Thu, February 7, 2008 14:33, Michael Smethurst wrote: >>> At the time Scott Reynen suggested: >>> >>> If it's just a generic contact that you know nothing about, I'd say >>> just use fn, as adding org is potentially incorrect information. But >>> if you know it's a music act, I think it makes sense to consider even >>> an individual performer's name to be an organization name in that >>> context. I'd say there's >>> a difference, for example, between Norah Jones the person, who would >>> be Norah Jones, and Norah Jones the musical >>> act, which would be Norah Jones. >> >> That strikes me as no more sensible now than it did then. If I cite >> her, as "Norah Jones said", am I referring to her as a person, or an >> organisation? >> >> Would her hCard's date of both refer to the day she left her mother's >> womb, or the day the supposed "organisation" was founded? >> >> Does Mozart become an organisation if I refer to his symphonies, but >> not if I refer to his marriage? >> >> Do Winston Churchill or Ghandi suddenly become organisations if we >> refer to a recording of one of their speeches, but not one of their >> books? > > I didn't say I supported this view. I just brought it back up cos it > seemed relevant Noted; my response was not addressed to or directed at you personally. >>> ...with artists like Eminem, Madonna, Prince. >>> How is fn optimisation supposed to work here? >> Exactly as it does at present. Those are both formatted names and >> nicknames (and remain nicknames, if you also include the fn of "Marshall >> Bruce Mathers III", "Madonna Louise Ciccone Ritchie " or "Prince >> Rogers >> Nelson"). > Not sure I follow. The hcard wiki page says nickname optimisation > happens when " "FN" and "ORG" are not the same, and the value of the "FN" > property is exactly one word. What would: Madonna Louise > Ciccone Ritchie > Result in? No nickname; unlike the more comprehensive: Madonna Louise Ciccone Ritchie > Also what about artists like Plastic Bertram? I assume that's not a given > + > family name combination It would be,; however I suggest that marked up such as: Plastic Bertram should be exempted from that optimisation rule - good call. I'll wiki it. -- Andy Mabbett ** via webmail ** From scott at randomchaos.com Thu Feb 7 07:37:39 2008 From: scott at randomchaos.com (Scott Reynen) Date: Thu Feb 7 09:42:59 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <10364.80.249.57.38.1202385542.squirrel@www.gradwell.com> References: <47AA4D28.9040009@lebleu.org> <10364.80.249.57.38.1202385542.squirrel@www.gradwell.com> Message-ID: <5B21A6BB-CDE9-4D76-9A40-F1B1D9C9E8D4@randomchaos.com> On Feb 7, 2008, at 4:59 AM, Andy Mabbett wrote: >> If it's just a generic contact that you know nothing about, I'd say >> just >> use fn, as adding org is potentially incorrect information. But if >> you >> know it's a music act, I think it makes sense to consider even an >> individual performer's name to be an organization name in that >> context. >> I'd say there's >> a difference, for example, between Norah Jones the person, who >> would be >> Norah Jones, and Norah Jones the musical act, >> which would be Norah Jones. > > That strikes me as no more sensible now than it did then. If I cite > her, > as "Norah Jones said", am I referring to her as a person, or an > organisation? Note I started that suggestion with "if it's just a generic contact that you know nothing about..." So in that context, there's no possible answer to your questions. I wasn't suggesting we treat all musicians as organizations when we *do* know they're individuals, just that our default assumption of musical acts is that they're organizations. You're of course welcome to publish under different assumptions; I wasn't suggesting we should all standardize on this. Peace, Scott From mircury at gmail.com Thu Feb 7 09:43:49 2008 From: mircury at gmail.com (Brandon Richards) Date: Thu Feb 7 09:50:32 2008 Subject: [uf-discuss] hentry? Message-ID: I've been thinking about how to create a standard structure to format a post within a publishing system and I was looking for a microformat and was wondering if the hentry as used on posts on microformats.org is a proposed spec and if there are any other examples? Would this be important in portability for different doc types when the ability to 'save as' already exists? Nevertheless, here is an example of what I've been toying with based upon some borrowed code from microformats.org, but I'm not sure if I'm re-inventing the wheel or if this is even needed.

Thoughts? -- Brandon Neil Richards mailto:mircury@gmail.com From andy at pigsonthewing.org.uk Thu Feb 7 10:03:43 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 10:03:46 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <5B21A6BB-CDE9-4D76-9A40-F1B1D9C9E8D4@randomchaos.com> References: <47AA4D28.9040009@lebleu.org> <10364.80.249.57.38.1202385542.squirrel@www.gradwell.com> <5B21A6BB-CDE9-4D76-9A40-F1B1D9C9E8D4@randomchaos.com> Message-ID: <7320.80.249.57.38.1202407423.squirrel@www.gradwell.com> On Thu, February 7, 2008 15:37, Scott Reynen wrote: > On Feb 7, 2008, at 4:59 AM, Andy Mabbett wrote: > > >>> If it's just a generic contact that you know nothing about, I'd say >>> just use fn, as adding org is potentially incorrect information. But if >>> you know it's a music act, I think it makes sense to consider even an >>> individual performer's name to be an organization name in that >>> context. I'd say there's >>> a difference, for example, between Norah Jones the person, who would be >>> Norah Jones, and Norah Jones the musical >>> act, which would be Norah Jones. >> >> That strikes me as no more sensible now than it did then. If I cite >> her, as "Norah Jones said", am I referring to her as a person, or an >> organisation? > > Note I started that suggestion with "if it's just a generic contact > that you know nothing about..." Which you then followed with "But if you know it's a music act" > So in that context, there's no possible > answer to your questions. I wasn't suggesting we treat all musicians as > organizations when we *do* know they're individuals, just that our default > assumption of musical acts is that they're organizations. If you mean that in the context of "a musical act, where the publisher doesn't know whether that's a person or a group", then I agree that that would be the better default (in that no third, more ambiguous, distinction is yet available); but I don't think that that is how others are representing your suggestion. -- Andy Mabbett ** via webmail ** From msporny at digitalbazaar.com Thu Feb 7 10:08:17 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Feb 7 10:08:21 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: <47AB2071.9020706@ts0.com> References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> <47AB2071.9020706@ts0.com> Message-ID: <47AB4911.5020809@digitalbazaar.com> Thom Shannon wrote: > perhaps there was prior discussion and agreement that was just a long > time ago? Have you searched the archives or asked Tantek directly? Here's the IRC log regarding the change to the wiki: http://rbach.priv.at/Microformats/IRC/2008-02-07#T010220 I agree with the change - I don't agree with not running it past the microformats-new list. It seems like a fairly far-reaching change/update. It invalidates the need for "mfo" in hcard, doesn't it? If it were applied to the rest of Microformats, it would invalidate the need for "mfo" entirely. There are logs - so it would be wrong to say the decision was made in private, it was done on IRC, without notification to microformats-new. -- manu From davidjanes at blogmatrix.com Thu Feb 7 09:56:40 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Feb 7 10:59:12 2008 Subject: [uf-discuss] hentry? In-Reply-To: References: Message-ID: <21e523c20802070956j4d342b71pb900863445c3603a@mail.gmail.com> Q1. yes Q2. yes Q3. don't know Here's the spec: http://microformats.org/wiki/hatom Regards, etc... On Feb 7, 2008 12:43 PM, Brandon Richards wrote: > I've been thinking about how to create a standard structure to format > a post within a publishing system and I was looking for a microformat > and was wondering if the hentry as used on posts on microformats.org > is a proposed spec and if there are any other examples? Would this be > important in portability for different doc types when the ability to > 'save as' already exists? Nevertheless, here is an example of what > I've been toying with based upon some borrowed code from > microformats.org, but I'm not sure if I'm re-inventing the wheel or if > this is even needed. -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From tantek at cs.stanford.edu Thu Feb 7 11:53:01 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Thu Feb 7 11:51:21 2008 Subject: [uf-discuss] hCard AGENT example parsing implications explained (was re: change ...) In-Reply-To: <47AB2071.9020706@ts0.com> Message-ID: On 2/7/08 7:14 AM, "Thom Shannon" wrote: > perhaps there was prior discussion and agreement that was just a long > time ago? Have you searched the archives or asked Tantek directly? Yes, this is from a long time ago, may even predate microformats.org. It's not a change except in making it more clear. The hCard AGENT Example has demonstrated this requirement for a long time. Thanks, Tantek From hober0 at gmail.com Thu Feb 7 11:53:33 2008 From: hober0 at gmail.com (Edward O'Connor) Date: Thu Feb 7 11:53:44 2008 Subject: [uf-discuss] Re: hentry? References: Message-ID: Brandon wrote: > and was wondering if the hentry as used on posts on microformats.org > is a proposed spec and if there are any other examples? Would this be http://microformats.org/wiki/hatom -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From andy at pigsonthewing.org.uk Thu Feb 7 12:21:05 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 12:22:40 2008 Subject: [uf-discuss] hCard issue: is "n" optional or mandatory. Message-ID: The hCard spec says: The 'n' property is OPTIONAL if any implied 'n' optimization rules are in effect. suggesting that it is mandatory otherwise, while the cheatsheet: lists it as: OPTIONAL, but MUST NOT occur more than once The later also says of 'adr': # At least one child-property MUST be present in adr. # If an adr-child (e.g street-address) is present it will ONLY be considered part of the adr data IF it is inside an adr. but makes no such stipulations for 'n' and its children. I certainly never use "n" for places: Birmingham and parsers (Operator, Tails, Tails Export, X2V) seem to have no problem with them - other than trying to optimise place names into given-, family- and nick- names; an issue I've raised previously: (aka: ) (aka ) and which is awaiting acceptance or otherwise of my proposed solution. There are also difficulties using n-children where the make-up of the 'fn' is not known in advance; consider a database of low-granularity names with properties like: John Smith-Brown Mary Anne Jones Ai Ki Chi so sites like Wikipedia use: [name of indeterminate structure] which again causes no problems to parsers. Should the spec be reworded? -- Andy Mabbett From scott at randomchaos.com Thu Feb 7 10:49:02 2008 From: scott at randomchaos.com (Scott Reynen) Date: Thu Feb 7 12:46:19 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: <47AB4911.5020809@digitalbazaar.com> References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> <47AB2071.9020706@ts0.com> <47AB4911.5020809@digitalbazaar.com> Message-ID: On Feb 7, 2008, at 11:08 AM, Manu Sporny wrote: > It invalidates the need for "mfo" in hcard, doesn't it? > If it were applied to the rest of Microformats, it would invalidate > the > need for "mfo" entirely. Not exactly. As said in IRC: # [02:17:12] just to quickly clarify, the opacity parsing rule applies to microformat X with regards to nested instances of X # [02:17:34] (as opposed to nested instances of any, even future, microformat) That "nested instances of any, even future, microformat" is what MFO [1] would cover, but probably never will because piecemeal solutions like this eliminate the various problems MFO would solve all at once. On the topic of whether this should have had wider discussion, I thought it was well established long ago that the properties of an AGENT hCard are not inherited by the container hCard, so I don't see anything really changing here. Was anyone publishing agent hCards and expecting the properties to also apply to the container? That seems very counter-intuitive to me. [1] http://microformats.org/wiki/mfo Peace, Scott From mircury at gmail.com Thu Feb 7 12:47:09 2008 From: mircury at gmail.com (Brandon Richards) Date: Thu Feb 7 13:14:37 2008 Subject: [uf-discuss] Re: hentry? In-Reply-To: References: Message-ID: Ok so hatom, but I suppose what I'm missing is the multiple pages of content that belong to the same entry. For portability sake, how do the other pages of content get linked or associated without having to actually include all of the content within one page? Sorry this just isn't clear to me. * an Entry MAY have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry Many web logs split content into multiple sections with a "Read More" link and JavaScript tricks. This is also needed in cases where Entry Titles are coded in-line and are considered part of the content. Thanks! -- Brandon Neil Richards > > and was wondering if the hentry as used on posts on microformats.org > > is a proposed spec and if there are any other examples? Would this be > > http://microformats.org/wiki/hatom From julian.rickards at ontario.ca Thu Feb 7 13:19:45 2008 From: julian.rickards at ontario.ca (Rickards, Julian (NDM)) Date: Thu Feb 7 13:20:50 2008 Subject: [uf-discuss] Fragment identifiers in hCard links Message-ID: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> Hi: I have multiple hCards on one page (http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp ). I created a unique ID for each
so that the link beside each one (http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=http: //www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst ) allows the visitor to add specific vcards to their address book. I tried this before (several months ago) and it seemed to work but I can't get this process to work again. I tried using a # in the URI but the link only downloads the first hCard on the page. When I checked my code, I noticed that I had used %23 in place of # so I presume that this was in response to a suggestion but when I use %23, Suda's server response with "No vCards found". Any help? Jules ------------------------------ Julian Rickards Geoscience Data Conversion Technician Provincial Recording Office Willet Green Miller Building, Level A3 933 Ramsey Lake Road Sudbury, ON P3E 6B5 E-mail: julian.rickards@ontario.ca Phone: (705) 670-5861, Fax: (705) 670-5681 Toll-free: 1-888-415-9845 ext. 5861 From tantek at cs.stanford.edu Thu Feb 7 13:44:08 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Thu Feb 7 13:42:25 2008 Subject: [uf-discuss] [admin] please keep hAudio discussions on microformats-new Message-ID: Since hAudio is still much more of a "new" microformat in development rather than a current microformat that people are simply asking about how to use, please keep discussions about it on the microformats-new list. Thanks, Tantek From tantek at cs.stanford.edu Thu Feb 7 12:04:50 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Thu Feb 7 13:42:27 2008 Subject: [uf-discuss] need for mfo / encapsulation / forward-compatible parsing (was re: changes...) In-Reply-To: <47AB4911.5020809@digitalbazaar.com> Message-ID: On 2/7/08 10:08 AM, "Manu Sporny" wrote: > It invalidates the need for "mfo" in hcard, doesn't it? > If it were applied to the rest of Microformats, it would invalidate the > need for "mfo" entirely. This is one of the reasons "mfo" has not progressed much further than the examples given in mfo-examples - it hasn't been necessary in practice. However, mfo may be needed for current parsers to be able to properly encapsulate new microformats that come along (this is often referred to as forward-compatible parsing), in the same way that they can explicitly do so with the limited set of existing microformats. As this topic is more related to parsing, I think the -dev list (on the To line) may be the more appropriate place to discuss it, while hopefully sympathetically taking into consideration the additional authoring cost/requirement of adding "mfo" (or whatever we come up with) as an additional class name to new compound microformats' root elements, e.g. class="mfo hunknown". Tantek From Michael.Smethurst at bbc.co.uk Thu Feb 7 09:21:55 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Feb 7 13:53:48 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: <48277.80.249.57.38.1202398211.squirrel@www.gradwell.com> Message-ID: On 7/2/08 15:30, "Andy Mabbett" wrote: > On Thu, February 7, 2008 14:33, Michael Smethurst wrote: > >> Not sure I follow. The hcard wiki page says nickname optimisation >> happens when " "FN" and "ORG" are not the same, and the value of the "FN" >> property is exactly one word. What would: Madonna Louise >> Ciccone Ritchie >> Result in? > > No nickname; unlike the more comprehensive: > > Madonna Louise Ciccone > Ritchie The problem for my work is I'm taking artist names out of musicbrainz. Musicbrainz does differentiate between artists singular and groups but the name field is a single string. So there's no differentiation between: Madonna Louise Ciccone Ritchie Madonna Ciccone Madonna Plastic Bertram So I can use: Madonna Louise Ciccone Ritchie And treat all artist names as nicknames or Madonna Louise Ciccone Ritchie And treat all artists as organisations Both of which seem wrong It's a commonish problem I've found with ufs. If you're handcrafting html they can be made to work fine - if you're generating pages dynamically from a db it gets trickier http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From andy at pigsonthewing.org.uk Thu Feb 7 11:59:31 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 14:31:08 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: <47AB4911.5020809@digitalbazaar.com> References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> <47AB2071.9020706@ts0.com> <47AB4911.5020809@digitalbazaar.com> Message-ID: In message <47AB4911.5020809@digitalbazaar.com>, Manu Sporny writes >Thom Shannon wrote: >> perhaps there was prior discussion and agreement that was just a long >> time ago? Have you searched the archives or asked Tantek directly? > >Here's the IRC log regarding the change to the wiki: > >http://rbach.priv.at/Microformats/IRC/2008-02-07#T010220 I don't consider that to be adequate period of discussion; and I don't consider that forum alone to be an adequate forum for discussion of such a major issue. What would happen if I implemented one of my outstanding - and nowhere near as harmful - proposals in that way? Why has it not been reverted yet? If I had any faith that this was truly an open community, I would do so myself. >I agree with the change I agree with the general principle behind the change. I don't agree with the method of implementation, or with changing the spec in a way which has such wide- reaching implications, and backwards-compatibility issues, with out doing adequate research, and giving ample warning, first. I don't agree with making the change wholesale rather than examining the implications in each type of use, And I don't agree with changing the way several microformats work, by amending the parsing-rules page for one of them. >- I don't agree with not running it past the >microformats-new list. It's not just about new microformats, but also existing microformats; it should be discussed here, too. >It seems like a fairly far-reaching >change/update. It invalidates the need for "mfo" in hcard, doesn't it? >If it were applied to the rest of Microformats, it would invalidate the >need for "mfo" entirely. It also break some previously-valid implementations. >There are logs - so it would be wrong to say the decision was made in >private, it was done on IRC, without notification to microformats-new. Who said it was made in private? -- Andy Mabbett From andy at pigsonthewing.org.uk Thu Feb 7 12:00:40 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 14:31:10 2008 Subject: [uf-discuss] hentry? In-Reply-To: References: Message-ID: In message , Brandon Richards writes >I've been thinking about how to create a standard structure to format a >post within a publishing system and I was looking for a microformat That would be hAtom: though you seem to suggest greater granularity. -- Andy Mabbett From andy at pigsonthewing.org.uk Thu Feb 7 14:02:09 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 14:31:12 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: References: <47AB2071.9020706@ts0.com> Message-ID: In message , Tantek ?elik writes >On 2/7/08 7:14 AM, "Thom Shannon" wrote: > >> perhaps there was prior discussion and agreement that was just a long >> time ago? Have you searched the archives or asked Tantek directly? > >Yes, this is from a long time ago, may even predate microformats.org. Cite ? >It's not a change except in making it more clear. Of course it's a change - look at the behaviour of current publishers and parsers. >The hCard AGENT Example has demonstrated this requirement for a long >time. Demonstration of a requirement is not demonstration of an existing standard. -- Andy Mabbett From andy at pigsonthewing.org.uk Thu Feb 7 14:03:28 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 14:31:12 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> <47AB2071.9020706@ts0.com> <47AB4911.5020809@digitalbazaar.com> Message-ID: In message , Scott Reynen writes >On the topic of whether this should have had wider discussion, I >thought it was well established long ago that the properties of an >AGENT hCard are not inherited by the container hCard, so I don't see >anything really changing here. The change made today does not refer only to Agent; nor even only to hCard. -- Andy Mabbett From ryan at theryanking.com Thu Feb 7 14:31:19 2008 From: ryan at theryanking.com (Ryan King) Date: Thu Feb 7 14:31:25 2008 Subject: [uf-discuss] Fragment identifiers in hCard links In-Reply-To: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> References: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> Message-ID: <59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com> On Feb 7, 2008, at 1:19 PM, Rickards, Julian (NDM) wrote: > Hi: > > I have multiple hCards on one page > (http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp > contact_e.asp> > ). I created a unique ID for each
so that the link > beside each one > (http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=http > : > //www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst > uri=http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp#devosst >> ) allows the visitor to add specific vcards to their address book. I > tried this before (several months ago) and it seemed to work but I > can't > get this process to work again. I tried using a # in the URI but the > link only downloads the first hCard on the page. When I checked my > code, > I noticed that I had used %23 in place of # so I presume that this was > in response to a suggestion but when I use %23, Suda's server response > with "No vCards found". Please make sure your page is at least well-formed: http://validator.w3.org/check?uri=http%3A//www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst -ryan From scott at randomchaos.com Thu Feb 7 15:24:25 2008 From: scott at randomchaos.com (Scott Reynen) Date: Thu Feb 7 15:48:19 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> <47AB2071.9020706@ts0.com> <47AB4911.5020809@digitalbazaar.com> Message-ID: <69FE1D70-C3F3-4920-B196-6A91BA7FF683@randomchaos.com> On Feb 7, 2008, at 3:03 PM, Andy Mabbett wrote: >> On the topic of whether this should have had wider discussion, I >> thought it was well established long ago that the properties of an >> AGENT hCard are not inherited by the container hCard, so I don't >> see anything really changing here. > > The change made today does not refer only to Agent; nor even only to > hCard. I don't understand why you think that. Everything I'm reading on the change page you linked seems to be specific to hCards within other hCards, and the only relationship defined for such nesting is AGENT. I agree major changes should be discussed more than this was, but I still don't see how this is a change at all, much less major. Peace, Scott From andy at pigsonthewing.org.uk Thu Feb 7 16:11:54 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 16:49:33 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: <69FE1D70-C3F3-4920-B196-6A91BA7FF683@randomchaos.com> References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> <47AB2071.9020706@ts0.com> <47AB4911.5020809@digitalbazaar.com> <69FE1D70-C3F3-4920-B196-6A91BA7FF683@randomchaos.com> Message-ID: In message <69FE1D70-C3F3-4920-B196-6A91BA7FF683@randomchaos.com>, Scott Reynen writes >On Feb 7, 2008, at 3:03 PM, Andy Mabbett wrote: > >>> On the topic of whether this should have had wider discussion, I >>>thought it was well established long ago that the properties of an >>>AGENT hCard are not inherited by the container hCard, so I don't >>>see anything really changing here. >> >> The change made today does not refer only to Agent; nor even only to >>hCard. > >I don't understand why you think that. Everything I'm reading on the >change page you linked seems to be specific to hCards within other >hCards, and the only relationship defined for such nesting is AGENT. >I agree major changes should be discussed more than this was, but I >still don't see how this is a change at all, much less major. (aka ) added: Similarly, parsers should treat nested [[hCalendar]], [[hReview]], [[hResume]] [[xFolk]] in the same way, properties inside them {{must}} only apply to the nested microformat, not to the containing microformat. All references below to "inside the hCard", "within the contents of the hCard", and similar phrasing {{must}} be interpreted with taking this nesting rule into account. -- Andy Mabbett From scott at randomchaos.com Thu Feb 7 15:09:02 2008 From: scott at randomchaos.com (Scott Reynen) Date: Thu Feb 7 17:11:48 2008 Subject: [uf-discuss] Re: hentry? In-Reply-To: References: Message-ID: On Feb 7, 2008, at 1:47 PM, Brandon Richards wrote: > For portability sake, how do > the other pages of content get linked or associated without having to > actually include all of the content within one page? rel="next" and rel="prev" [1] can be used to describe these kind of relationships between documents, but I don't know if any hAtom tools currently look for that. [1] http://www.w3.org/TR/html401/struct/links.html#h-12.1.2 Peace, Scott From walter at psybernet.co.nz Thu Feb 7 18:14:20 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Thu Feb 7 18:54:32 2008 Subject: [uf-discuss] Using hCard to publish a member list Message-ID: <47ABBAFC.6060003@psybernet.co.nz> Hi, I have the task of putting an organisation's member list online. (about 400) it is currently in an Access database. There are several views people want - by region, status, certification etc. One common view is by region and status. I can make a file of all members and mark it up by hCard (or hResume?). Is there some way to get sliced and diced views of that list? An easy way for me to publish several lists or to have a list generator of some sort for viewers? Walter From scott at randomchaos.com Thu Feb 7 22:55:39 2008 From: scott at randomchaos.com (Scott Reynen) Date: Thu Feb 7 22:55:47 2008 Subject: [uf-discuss] Major change to microformat specs without prior discussion or notification In-Reply-To: References: <2472.80.249.57.38.1202384681.squirrel@www.gradwell.com> <47AB2071.9020706@ts0.com> <47AB4911.5020809@digitalbazaar.com> <69FE1D70-C3F3-4920-B196-6A91BA7FF683@randomchaos.com> Message-ID: <62C35185-B07F-40DF-A36D-AB3C1DEE08E7@randomchaos.com> On Feb 7, 2008, at 5:11 PM, Andy Mabbett wrote: > added: > > Similarly, parsers should treat nested [[hCalendar]], > [[hReview]], [[hResume]] [[xFolk]] in the same way, properties > inside them {{must}} only apply to the nested microformat, not > to the containing microformat. > > All references below to "inside the hCard", "within the > contents > of the hCard", and similar phrasing {{must}} be interpreted > with > taking this nesting rule into account. Aha, I totally missed that part when looking at the change log twice. I'm not clear on the intended scope of this rule, but it's certainly broader than I mistakenly suggested earlier. Peace, Scott From davidjanes at blogmatrix.com Thu Feb 7 23:46:19 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Feb 7 23:46:21 2008 Subject: [uf-discuss] Re: hentry? In-Reply-To: References: Message-ID: <21e523c20802072346y67f50650pe934d5fe4126f9e1@mail.gmail.com> This would be a lot more clearer if you showed an example on the web. Regards, etc... On Feb 7, 2008 3:47 PM, Brandon Richards wrote: > Ok so hatom, but I suppose what I'm missing is the multiple pages of > content that belong to the same entry. For portability sake, how do > the other pages of content get linked or associated without having to > actually include all of the content within one page? Sorry this just > isn't clear to me. > > * an Entry MAY have 0 or more Entry Content elements. The "logical > Entry Content" of an Entry is the concatenation, in order of > appearance, of all the Entry Contents within the Entry > Many web logs split content into multiple sections with a "Read More" > link and JavaScript tricks. This is also needed in cases where Entry > Titles are coded in-line and are considered part of the content. > > Thanks! > -- > Brandon Neil Richards > > > > > and was wondering if the hentry as used on posts on microformats.org > > > is a proposed spec and if there are any other examples? Would this be > > > > http://microformats.org/wiki/hatom > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From andy at pigsonthewing.org.uk Fri Feb 8 00:52:09 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 8 00:53:46 2008 Subject: [uf-discuss] haudio contributor In-Reply-To: References: <48277.80.249.57.38.1202398211.squirrel@www.gradwell.com> Message-ID: In message , Michael Smethurst writes >The problem for my work is I'm taking artist names out of musicbrainz. >Musicbrainz does differentiate between artists singular and groups but >the name field is a single string. >I can use: > >Madonna Louise Ciccone Ritchie > >And treat all artist names as nicknames > >or > >Madonna Louise Ciccone Ritchie > >And treat all artists as organisations > >Both of which seem wrong > >It's a commonish problem I've found with ufs. If you're handcrafting >html they can be made to work fine - if you're generating pages >dynamically from a db it gets trickier I found the same problem on Wikipedia with addresses and names. -- Andy Mabbett From mail at tobyinkster.co.uk Fri Feb 8 03:30:51 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Feb 8 04:01:23 2008 Subject: [uf-discuss] Re: Auto Discovery of XFN References: <000f01c8695c$bda2cd10$6500a8c0@Bilbo> Message-ID: Robert Mark White wrote: > The link below is the link I use for my vCard/hCard. type="text/directory" title="vCard" href="http://example.com/vcard.html" > /> I'm not sure where you've found rel="media". I don't know of any specification that recommends it. One or more of the following seem more appropriate: * rel="me" (from XFN) * rel="contact" (from HTML5 drafts) * rel="author" (from HTML5 drafts) * rel="DC.creator" (using Dublin Core + RFC 2731) * rev="made" (commonly used) These can be combined, e.g.: Personally, for linking to contact info, I just use: -- 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 9 days, 17:33.] The Great IE8 Meta Tag Debacle http://tobyinkster.co.uk/blog/2008/02/06/ie-8-meta-tag/ From mail at tobyinkster.co.uk Fri Feb 8 02:58:44 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Feb 8 04:01:24 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" References: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> <18050cf90802051613o256923fdte550071bf5480fab@mail.gmail.com> <18050cf90802061150v1bc08db4uaa44aeaf0d217daa@mail.gmail.com> Message-ID: <48pt75-n3k.ln1@ophelia.g5n.co.uk> Paul Wilkins wrote: > Toby A Inkster wrote: > >> 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. > > There is an inherent order, but that order can not be relied upon to > convey any useful information. An inherent order is all that is needed by my include pattern. It uses the inherent order of class names to emulate the inherent order of child nodes. Such that this:

x

is considered equivalent to the following using current existing include- pattern:

x

Both examples take advantage of inherent rather than explicit order. In the first case the inherent order of class names is used; and in the second, the inherent order of child nodes. However, my suggested format is less verbose, creates no "dummy elements" in the DOM and is likely to cause fewer accessibility problems. -- 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 9 days, 17:08.] The Great IE8 Meta Tag Debacle http://tobyinkster.co.uk/blog/2008/02/06/ie-8-meta-tag/ From mail at tobyinkster.co.uk Fri Feb 8 04:34:05 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Feb 8 05:01:22 2008 Subject: [uf-discuss] Re: Microformats, how are they used? References: <47AA28C7.7060101@psybernet.co.nz> Message-ID: Walter Logeman wrote: > I have added a few new tags, rel="spouse", rel="colleague" on my > WordPress blog I am curious how these get used. I have installed > Operator and Tail Export on Firefox, I can't see anything show up other > than on the source file. XFN isn't implemented particularly widely in client-side tools. Mostly because there's a limit to how useful the data is to browsers. If your browser knows that Joe Blogs is colleagues with John Citizen, then how does that help you? What can the browser *do* with that knowledge? However XFN is implemented in a few server-side places. For example, certain social networks are able to import lists of friends, family and colleagues from XFN-enabled web pages. -- 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 9 days, 17:53.] The Great IE8 Meta Tag Debacle http://tobyinkster.co.uk/blog/2008/02/06/ie-8-meta-tag/ From mail at tobyinkster.co.uk Fri Feb 8 04:45:00 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Feb 8 05:05:09 2008 Subject: [uf-discuss] Re: Apple Data Detectors References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org> Message-ID: Guillaume Lebleu wrote: > 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. One problem with that is that it will find matches on people who aren't even intending to use your plain-old-english format. They may happen to be including "Tuesday, February 5, 2008" on their pages with a different intended meaning. 2008 could refer to eight minutes past eight PM in military time -- unlikely, but possible. And as you move away from dates, phone numbers and postcodes which have relatively parseable formats, towards locations, people's names and job titles and so on, the likelihood of false matches increases. The use of explicit tags to mark up information do make microformats slightly harder to use, yes. But the key is that they also make microformats much easier to explicitly not use. -- 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 9 days, 18:55.] The Great IE8 Meta Tag Debacle http://tobyinkster.co.uk/blog/2008/02/06/ie-8-meta-tag/ From thom at ts0.com Fri Feb 8 05:47:14 2008 From: thom at ts0.com (Thom Shannon) Date: Fri Feb 8 05:47:21 2008 Subject: [uf-discuss] XFN advocacy email Message-ID: <47AC5D62.8020304@ts0.com> Hi, I just added an advocacy email to the wiki. It would be great if more sites would publish XFN now google have launched their SG API. http://microformats.org/wiki/advocacy-email-samples#Add_XFN_to_social_network_profiles Please have a look over it and suggest any changes. Then send it out to all your fave networks not already publishing XFN (there's a lot of them). From davidjanes at blogmatrix.com Fri Feb 8 06:02:52 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Feb 8 06:02:57 2008 Subject: [uf-discuss] Microformats, how are they used? In-Reply-To: <47AA28C7.7060101@psybernet.co.nz> References: <47AA28C7.7060101@psybernet.co.nz> Message-ID: <21e523c20802080602g31ce40d0gf3406b6da2b06404@mail.gmail.com> You picked the right week to answer this question. The Google Social Graph API [1] provides a method of finding the graph of URIs based on XFN relationships. There's basically only one call, one that returns graph results. Items get into the graph via the normal Google spidering process. Regards, etc... [1] http://code.google.com/apis/socialgraph/docs/ On Feb 6, 2008 4:38 PM, Walter Logeman wrote: > Hi, > > New to Microformats and this list. > > I am trying to get my head around Microformats for an art project I > have in mind, and am following the "process" and Poshifying my site. > > I have added a few new tags, rel="spouse", rel="colleague" on my > WordPress blog I am curious how these get used. I have installed > Operator and Tail Export on Firefox, I can't see anything show up > other than on the source file. -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From guillaume at lebleu.org Fri Feb 8 08:53:59 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Fri Feb 8 08:54:05 2008 Subject: [uf-discuss] Re: Apple Data Detectors In-Reply-To: References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org> Message-ID: <47AC8927.8010906@lebleu.org> Toby, Here is an implementation of what I described in my previous post by Yahoo. http://shortcuts.yahoo.com/ They offer a Wordpress plugin that detects objects from plain old english patterns as you write your blog post, then asks you for disambiguation and whether you want to link to it (to their content obviously). I've not reviewed it yet, so don't know if they use uf. Guillaume From info at weborganics.co.uk Fri Feb 8 07:21:32 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Fri Feb 8 09:15:02 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: <48pt75-n3k.ln1@ophelia.g5n.co.uk> References: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> <18050cf90802051613o256923fdte550071bf5480fab@mail.gmail.com> <18050cf90802061150v1bc08db4uaa44aeaf0d217daa@mail.gmail.com> <48pt75-n3k.ln1@ophelia.g5n.co.uk> Message-ID: <1202484092.4097.18.camel@weborganicscouk> Hello Toby On Fri, 2008-02-08 at 10:58 +0000, Toby A Inkster wrote: > Such that this: > >

> x >

> > is considered equivalent to the following using current existing > include- > pattern: > >

> > x > >

you know instead of trying to "mimic" the current include pattern or "stuffing" a class try something new and a bit more "microformaty"... eg: we could use class "data" as a container for what we want to include. Foo then use an empty span with the class "include data" anywhere you would like the "data" to appear.... the result could turn out much like this: Foo Pretty easy on the mind I would say. Thanks Martin McEvoy From guillaume at lebleu.org Fri Feb 8 09:01:47 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Fri Feb 8 09:15:59 2008 Subject: [uf-discuss] Using hCard to publish a member list In-Reply-To: <47ABBAFC.6060003@psybernet.co.nz> References: <47ABBAFC.6060003@psybernet.co.nz> Message-ID: <47AC8AFB.80404@lebleu.org> Walter Logeman wrote: > Is there some way to get sliced and diced views of that list? An easy > way for me to publish several lists or to have a list generator of > some sort for viewers? Walt, not sure if the following will address all your requirements, but it is a start: I would use an HTML table with one hCard in each row. Then, I would use http://www.kryogenix.org/code/browser/sorttable/ to make each column sorttable. Guillaume From guillaume at lebleu.org Fri Feb 8 08:40:26 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Fri Feb 8 10:07:43 2008 Subject: [uf-discuss] Re: Apple Data Detectors In-Reply-To: References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org> Message-ID: <47AC85FA.2040507@lebleu.org> Toby A Inkster wrote: > Guillaume Lebleu wrote: > > >> 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. >> > > One problem with that is that it will find matches on people who aren't > even intending to use your plain-old-english format. They may happen to be > including "Tuesday, February 5, 2008" on their pages with a different > intended meaning. 2008 could refer to eight minutes past eight PM in > military time -- unlikely, but possible. And as you move away from dates, > phone numbers and postcodes which have relatively parseable formats, > towards locations, people's names and job titles and so on, the likelihood > of false matches increases. > > The use of explicit tags to mark up information do make microformats > slightly harder to use, yes. But the key is that they also make > microformats much easier to explicitly not use. > > Toby, I understand the challenge of disambiguation and the value microformats bring in terms of easier parser implementation and more reliable information consumption experience. The challenge for average people writing microformats can't be underestimated though. I strongly believe that the time where disambiguation costs are the lowest are at publishing time, but this is also the time where you are focused on the english content, not the microformats. This is why in the second part of the post you cited, I suggested the use of Apple Data Detectors' like functionality, not to detect objects in plain old english (POE) in published content, but to detect objects in POE at the time they are written and ask for the user for disambiguation at the same time, in a way that the underlying microformat markup is generated, but without the user having to know the syntax. I'm thinking of this particularly in the context of writing a blog post: writing 1 hCards just to say "My friend Joe" is way too much for normal people. On the other end, if, as I type this, I get an intellisense-like list of my contacts that I can select from, then I can just select Joe from the list and have the microformat markup added for me (just like Wordpress adds a lot of markup that isn't in the visual editor or like Wiki converts simplified markup into HTML markup). Guillaume From brian.suda at gmail.com Fri Feb 8 10:54:04 2008 From: brian.suda at gmail.com (Brian Suda) Date: Fri Feb 8 11:00:29 2008 Subject: [uf-discuss] NLP was Apple Data Detectors Message-ID: <21e770780802081054y77541270v66dcd930645b4680@mail.gmail.com> 2008/2/8, Guillaume Lebleu : > I understand the challenge of disambiguation and the value microformats > bring in terms of easier parser implementation and more reliable > information consumption experience. --- without the explicit additional mark-up declaring something to be of a certain type, we are left with just Natural Language Processing (NLP = http://en.wikipedia.org/wiki/Natural_language_processing) This is a dangerous and slippery slope, NLP sounds like a great idea but has never attained the hype proceeding it. NLP is language specific, so while it might be great that Apple Data Detectors work in English, the NLP for all language makes the code explode quickly. Microformats, while requiring extra mark-up, can accommodate for ISO dates in any language. Geonames has a service that attempts to find places and give them Geo Coordinates. You can judge for yourself how well NLP can or can not correctly extract data. http://www.geonames.org/rss-to-georss-converter.html I Want Sandy attempts to parse dates and times, but usually needs some help or a well structured format. http://iwantsandy.com/ while not impossible todo, you end-up writing in a way that isn't natural. > The challenge for average people > writing microformats can't be underestimated though. I strongly believe > that the time where disambiguation costs are the lowest are at > publishing time, but this is also the time where you are focused on the > english content, not the microformats. The dangers of these are that you are attempting to "have your cake and eat it too". There will always be an effort on someone's part to explain this data. AI is not, and probably won't get there any time soon, so microformats are the lightest-weight way to add the information needed to help machines without over burdening the publisher. The ideal solution would be for somesort of plugin in the CMS so you can simply highlight areas and push a button and it will add the microformatted information, or (like Microsoft Writer) have a hCalendar Plugin, so you fill out the forms and it puts it all inline with the mark-up for you. Both of these efforts lighten the load on the publisher while keeping the mark-up to remove ambiguities. -brian -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Fri Feb 8 12:59:38 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 8 13:01:06 2008 Subject: [uf-discuss] Re: Microformats, how are they used? In-Reply-To: References: <47AA28C7.7060101@psybernet.co.nz> Message-ID: <807+Zr36KMrHFw7z@pigsonthewing.org.uk> In message , Toby A Inkster writes >XFN isn't implemented particularly widely in client-side tools. How widely is it implemented (in client side tools that is) would you say, in comparison to Dublin Core? I note, for instance that the ' rel="DC.creator" ' in your website: is recognised by the Dublin Core Viewer extension for Firefox: -- Andy Mabbett From andy at pigsonthewing.org.uk Fri Feb 8 13:32:42 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 8 13:34:17 2008 Subject: [uf-discuss] A further possible solution to the "abbr" accessibility issue In-Reply-To: References: Message-ID: In message , Andy Mabbett writes >Early in December, I made the following suggestion, but in a separate, >and unclearly-titled thread. > >I'm reposting it here, in a new thread, in the hope that it will >warrant discussion: [prefix changed to "data"] > title="data:20070912T16:03:00+01:00"> > 4.03pm > A further advantage of this method has just occurred to me; it could use plain-language *and* machine values in one title, thus: 4.03pm and we could even exempt parentheses: 4.03pm -- Andy Mabbett From walter at psybernet.co.nz Fri Feb 8 15:36:58 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Fri Feb 8 15:47:11 2008 Subject: [uf-discuss] Using hCard to publish a member list In-Reply-To: <47AC8AFB.80404@lebleu.org> References: <47ABBAFC.6060003@psybernet.co.nz> <47AC8AFB.80404@lebleu.org> Message-ID: <47ACE79A.3000002@psybernet.co.nz> Guillaume > Walt, not sure if the following will address all your requirements, but > it is a start: I would use an HTML table with one hCard in each row. > Then, I would use http://www.kryogenix.org/code/browser/sorttable/ to > make each column sorttable. I will follow this through! Looks good. Walter From guillaume at lebleu.org Fri Feb 8 17:04:50 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Fri Feb 8 17:04:56 2008 Subject: [uf-discuss] Editor integration (was: NLP was Apple Data Detectors) In-Reply-To: <21e770780802081054y77541270v66dcd930645b4680@mail.gmail.com> References: <21e770780802081054y77541270v66dcd930645b4680@mail.gmail.com> Message-ID: <47ACFC32.3050307@lebleu.org> Brian Suda wrote: > The ideal solution would be for somesort of plugin in the CMS so you > can simply highlight areas and push a button and it will add the > microformatted information Do you or anyone know of any microformats integration work with TinyMCE or any insight into why it hasn't happened yet? Seems like there has been some talk about this on this list back in 2006. http://microformats.org/discuss/mail/microformats-discuss/2006-March/003298.html TIA, Guillaume From faaborg at mozilla.com Fri Feb 8 17:47:27 2008 From: faaborg at mozilla.com (Alex Faaborg) Date: Fri Feb 8 19:27:59 2008 Subject: [uf-discuss] Re: Apple Data Detectors In-Reply-To: <47AC85FA.2040507@lebleu.org> References: <47A884F7.5040800@ts0.com> <47A8EAE3.1090101@lebleu.org> <47AC85FA.2040507@lebleu.org> Message-ID: <4AD0EB3A-592D-4AA7-89A8-032E092E3762@mozilla.com> > On the other end, if, as I type this, I get an intellisense-like > list of my contacts that I can select from, then I can just select > Joe from the list and have the microformat markup added for me I've been thinking a lot about how a Web browser could help end users author microformatted content in blogs and wikis, and I think we need to consider the user's goals and motivations. I can't imagine people associating a contact in their address book with Joe as they casually mention him in a blog post just because they have an appreciation for the beauty of structured data. However, if their goal is closely aligned with the goal of their readers, then I can see users going to the extra effort. For instance, let's say you want to review something, and because you want your vote to count and other people to be able to take advantage of your review once it gets aggregated, I can see users going to the extra effort of filling out a form like the hReview creator (http://microformats.org/code/hreview/creator) to get information into the structure of an hReview. The same goes for people who want to promote an event: since their motivation is for people to attend, they make it easy for users to add the event to their calendar. We already see this type of behavior in applications like Outlook or Zimbra, where people create events for other people, so they are easy to accept. Microformats allow to take that interaction out of closed systems, and apply it to HTML emails, blog posts, wikis, etc. I'm all for building systems that attempt to infer structure from natural language, because like we see in Apple's 1998 article, and now in Mail.app, these types of systems can be really useful when they work. But I also don't think we should discount situations where the user may actually have a clear motivation for creating structured data by filling out a form. In case anyone is interested in reading more about Data Detectors, you might find this paper interesting. It catalogs all of the research done throughout the late 90s, and discusses a prototype system that leverages large knowledge bases like Stanford's TAP and MIT's ConceptNet to disambiguate natural language and provide structure to unstructured text: http://alumni.media.mit.edu/~faaborg/files/thesis/draft/complete/CHI06_goalOrientedWebBrowser.pdf -Alex On Feb 8, 2008, at 8:40 AM, Guillaume Lebleu wrote: > Toby A Inkster wrote: >> Guillaume Lebleu wrote: >> >> >>> 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>> abbr>. >>> >> >> One problem with that is that it will find matches on people who >> aren't even intending to use your plain-old-english format. They >> may happen to be including "Tuesday, February 5, 2008" on their >> pages with a different intended meaning. 2008 could refer to eight >> minutes past eight PM in military time -- unlikely, but possible. >> And as you move away from dates, phone numbers and postcodes which >> have relatively parseable formats, towards locations, people's >> names and job titles and so on, the likelihood of false matches >> increases. >> >> The use of explicit tags to mark up information do make >> microformats slightly harder to use, yes. But the key is that they >> also make microformats much easier to explicitly not use. >> >> > Toby, > I understand the challenge of disambiguation and the value > microformats bring in terms of easier parser implementation and more > reliable information consumption experience. The challenge for > average people writing microformats can't be underestimated though. > I strongly believe that the time where disambiguation costs are the > lowest are at publishing time, but this is also the time where you > are focused on the english content, not the microformats. This is > why in the second part of the post you cited, I suggested the use of > Apple Data Detectors' like functionality, not to detect objects in > plain old english (POE) in published content, but to detect objects > in POE at the time they are written and ask for the user for > disambiguation at the same time, in a way that the underlying > microformat markup is generated, but without the user having to know > the syntax. I'm thinking of this particularly in the context of > writing a blog post: writing 1 hCards just to say "My friend Joe" is > way too much for normal people. On the other end, if, as I type > this, I get an intellisense-like list of my contacts that I can > select from, then I can just select Joe from the list and have the > microformat markup added for me (just like Wordpress adds a lot of > markup that isn't in the visual editor or like Wiki converts > simplified markup into HTML markup). > Guillaume > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From info at weborganics.co.uk Sat Feb 9 05:55:52 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 9 05:56:12 2008 Subject: [uf-discuss] Re: Possible alternative methods for "include" In-Reply-To: <1202484092.4097.18.camel@weborganicscouk> References: <1314851D-44BE-460D-B330-484761DD0131@theryanking.com> <18050cf90802051613o256923fdte550071bf5480fab@mail.gmail.com> <18050cf90802061150v1bc08db4uaa44aeaf0d217daa@mail.gmail.com> <48pt75-n3k.ln1@ophelia.g5n.co.uk> <1202484092.4097.18.camel@weborganicscouk> Message-ID: <1202565352.11869.2.camel@weborganicscouk> On Fri, 2008-02-08 at 15:21 +0000, Martin McEvoy wrote: > eg: we could use class "data" as a container for what we want to > include. > > > > Foo > > > The above example was not very clear was it?, so a proposal can be found here: http://microformats.org/wiki/include-pattern-strawman#Use_a_Class_Create_method Thanks Martin McEvoy From thom at ts0.com Sat Feb 9 10:22:54 2008 From: thom at ts0.com (Thom Shannon) Date: Sat Feb 9 10:23:00 2008 Subject: [uf-discuss] microformats and privacy Message-ID: <47ADEF7E.3030108@ts0.com> What is the response to the privacy argument? As a carefree technophile I'm happy publishing personal info on the web. But when you're trying to convince a major social network to add semantics that makes their users personal information easier to harvest and possibly abuse. Is there any answer? http://www.flickr.com/groups/flickrideas/discuss/72157603869809336/ From supercanadian at gmail.com Sat Feb 9 10:42:47 2008 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Sat Feb 9 10:42:50 2008 Subject: [uf-discuss] microformats and privacy In-Reply-To: <47ADEF7E.3030108@ts0.com> References: <47ADEF7E.3030108@ts0.com> Message-ID: <84ce626f0802091042o3b1619a9jc08540e8215115a0@mail.gmail.com> Obviously.... doesn't publish any information to the web that you want private. For example.... facebook asks you for your phone number... so it can show it to others... but you don't have to give it that info! Microformats will help "expose" the information you are willing to put out there. (If you want something private... then don't "give it out".) -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Motorsport Videos http://TireBiterZ.com/ Vlog Razor... Vlogging News... http://vlograzor.com/ On Feb 9, 2008 10:22 AM, Thom Shannon wrote: > What is the response to the privacy argument? As a carefree technophile > I'm happy publishing personal info on the web. But when you're trying to > convince a major social network to add semantics that makes their users > personal information easier to harvest and possibly abuse. Is there any > answer? > > http://www.flickr.com/groups/flickrideas/discuss/72157603869809336/ From csarven at gmail.com Sat Feb 9 11:15:39 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Feb 9 11:15:41 2008 Subject: [uf-discuss] A further possible solution to the "abbr" accessibility issue In-Reply-To: References: Message-ID: On 2/8/08, Andy Mabbett wrote: > In message , Andy Mabbett > writes > > >Early in December, I made the following suggestion, but in a separate, > >and unclearly-titled thread. > > > >I'm reposting it here, in a new thread, in the hope that it will > >warrant discussion: > > [prefix changed to "data"] > > > > title="data:20070912T16:03:00+01:00"> > > 4.03pm > > > > A further advantage of this method has just occurred to me; it could use > plain-language *and* machine values in one title, thus: > > title="we start at three minutes > past four - data: 2007-09-12T16:03:00+01:00"> > 4.03pm > > > and we could even exempt parentheses: > > title="we start at three minutes > past 4 (data: 2007-09-12T16:03:00+01:00)"> > 4.03pm > > > -- > Andy Mabbett I wonder if this will be heavy for the parsers when both "plain-language *and* machine values" are mixed i.e., knowing the scope of the regex to differentiate between the two. -Sarven From csarven at gmail.com Sat Feb 9 13:02:19 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Feb 9 13:02:28 2008 Subject: [uf-discuss] hKit and include-pattern scope Message-ID: Isn't the importation of data from external resources using hKit face similar issues as in include-pattern? re: http://microformats.org/wiki?title=include-pattern-faq&diff=0&oldid=25623 -Sarven From guillaume at lebleu.org Sat Feb 9 14:11:33 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Sat Feb 9 14:11:37 2008 Subject: [uf-discuss] microformats and privacy In-Reply-To: <47ADEF7E.3030108@ts0.com> References: <47ADEF7E.3030108@ts0.com> Message-ID: <47AE2515.3070800@lebleu.org> Thom Shannon wrote: > What is the response to the privacy argument? As a carefree > technophile I'm happy publishing personal info on the web. But when > you're trying to convince a major social network to add semantics that > makes their users personal information easier to harvest and possibly > abuse. Is there any answer? > Thom, Last year, I brought up the idea of something I named "hprivacy" and presented a very primitive hprivacy html proxy filter prototype with three groups: pro, family, friends and public. See http://microformats.org/discuss/mail/microformats-discuss/2007-April/009264.html This is a tiny prototype that is not integrated with a tagged social graph, so for now, I simulate the filtering by passing the group in the URL. But you'll get the idea. Some links have moved: http://lebleu.org/projects/hprivacy/index.php (what the public sees) http://lebleu.org/projects/hprivacy/index.php?group=family (what a family member would see) http://lebleu.org/projects/hprivacy/index.php?group=friends http://lebleu.org/projects/hprivacy/index.php?group=pro See the markup: http://lebleu.org/projects/hprivacy/hcard.html (obviously, in real implementation, this would be pulled from a non-public folder) There didn't seem to be much interest on this list. Maybe because it's not so much about data formats and/or because it's about marking up content that is not public to anyone (microformats seems to have a bias toward public content). Let me know what you think. Also, someone helped me design a cool logo: http://hprivacy.org Guillaume From andy at pigsonthewing.org.uk Sat Feb 9 17:43:12 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Feb 9 17:44:54 2008 Subject: [uf-discuss] A further possible solution to the "abbr" accessibility issue In-Reply-To: References: Message-ID: <1wp84PCwalrHFwqp@pigsonthewing.org.uk> In message , Sarven Capadisli writes >> A further advantage of this method has just occurred to me; it could use >> plain-language *and* machine values in one title, thus: >> >> > title="we start at three minutes >> past four - data: 2007-09-12T16:03:00+01:00"> >> 4.03pm >> >> >> and we could even exempt parentheses: >> >> > title="we start at three minutes >> past 4 (data: 2007-09-12T16:03:00+01:00)"> >> 4.03pm >> >I wonder if this will be heavy for the parsers when both >"plain-language *and* machine values" are mixed i.e., knowing the scope >of the regex to differentiate between the two. 'Everything after "data:" excluding leading white space and a trailing close-parenthesis, if any' shouldn't be to difficult to code. -- Andy Mabbett From thom at ts0.com Sun Feb 10 05:55:57 2008 From: thom at ts0.com (Thom Shannon) Date: Sun Feb 10 05:56:03 2008 Subject: [uf-discuss] microformats and privacy In-Reply-To: <47AE2515.3070800@lebleu.org> References: <47ADEF7E.3030108@ts0.com> <47AE2515.3070800@lebleu.org> Message-ID: <47AF026D.4050309@ts0.com> > > Last year, I brought up the idea of something I named "hprivacy" Nice idea, if there was some way to integrate it with oAuth so you could give the proxy permission to access that data in a standard way that could work really well. The only problem is it would take a fair bit of work for the publisher to implement, but I don't think there's any obvious way around that. From mdagn at spraci.com Mon Feb 11 06:08:23 2008 From: mdagn at spraci.com (Michael MD) Date: Mon Feb 11 06:08:45 2008 Subject: [uf-discuss] Editor integration (was: NLP was Apple DataDetectors) In-Reply-To: <47ACFC32.3050307@lebleu.org> Message-ID: <200802111408.m1BE8cN56772@proxy.syd.comcen.com.au> > Do you or anyone know of any microformats integration work with TinyMCE > or any insight into why it hasn't happened yet? Seems like there has > been some talk about this on this list back in 2006. I did have a go at something like this a couple of years ago but at the time my javascript skills were not really up to it and I didn't really understand the way plugins work in it. .. but despite the messy code I had it partially working - The idea was to have forms for creating hcalendar events and hcards and a tails-like sidebar showing any vevents and hcards found in the document with editing options. It was way too slow to be of much use in the real world and there were other problems that would need more thought so I ended up shelving it hoping that some day I might think of a better way to do it. From julian.rickards at ontario.ca Mon Feb 11 06:33:36 2008 From: julian.rickards at ontario.ca (Rickards, Julian (NDM)) Date: Mon Feb 11 06:48:00 2008 Subject: [uf-discuss] Fragment identifiers in hCard links In-Reply-To: <59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com> References: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> <59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com> Message-ID: <51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> > -----Original Message----- > On Feb 7, 2008, at 1:19 PM, Rickards, Julian (NDM) wrote: > > Hi: > > > > I have multiple hCards on one page > > (http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp > > > contact_e.asp> > > ). I created a unique ID for each
so > that the link > > beside each one > > > (http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=htt > > p > > : > > //www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst > > > ntact.php? > > > uri=http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp#devos > > st > >> ) allows the visitor to add specific vcards to their > address book. I > > tried this before (several months ago) and it seemed to work but I > > can't get this process to work again. I tried using a # in > the URI but > > the link only downloads the first hCard on the page. When I > checked my > > code, I noticed that I had used %23 in place of # so I presume that > > this was in response to a suggestion but when I use %23, > Suda's server > > response with "No vCards found". > > Please make sure your page is at least well-formed: > > http://validator.w3.org/check?uri=http%3A//www.mndm.gov.on.ca/ mndm/mines/lands/pro/contact_e.asp%23devosst Ryan: I fixed the page and now it is valid. However, that doesn't change the result. Having done a bit of testing, it appears that in the URI link where I use a fragment identifier (which would normally use the # as in index.html#fragment), I have tried both # and %23 (where that comes from, I don't know) but neither work properly. When I use #, only the first contact is downloaded no matter which contact link I click. However, when I use %23 in the URI, the only response I get is "No vCards found" which is obviously not true because the hCard code meets the specs. Maybe Brian Suda has changed the code on his server because a test page of mine that used to work doesn't work any longer. Does anyone have any ideas as to how to put multiple hCards on one page and have individual links download individual vCards to the client's address book? Jules From scott at randomchaos.com Mon Feb 11 08:21:25 2008 From: scott at randomchaos.com (Scott Reynen) Date: Mon Feb 11 09:27:59 2008 Subject: [uf-discuss] Fragment identifiers in hCard links In-Reply-To: <51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> References: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> <59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com> <51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> Message-ID: <49154686-0789-4977-A418-0BDDE06B0078@randomchaos.com> On Feb 11, 2008, at 7:33 AM, Rickards, Julian (NDM) wrote: > I fixed the page and now it is valid. However, that doesn't change the > result. Having done a bit of testing, it appears that in the URI link > where I use a fragment identifier (which would normally use the # as > in > index.html#fragment), I have tried both # and %23 (where that comes > from, I don't know) but neither work properly. "%23" is the URL encoding of the "#" character. This character needs to be encoded to be sent to the server because a plain "#" begins a fragment identifier, which is handled by the browser after the server returns a page, so the server never sees it. Technically everything in a query string should be URL encoded, but the "#" character is the only one that really matters. > Does anyone have any ideas as to how to put multiple hCards on one > page > and have individual links download individual vCards to the client's > address book? It looks like what you're doing is correct, so I'd suggest waiting for Brian to comment on why it isn't working with X2V. It seems to work on Technorati's version of X2V: http://technorati.com/contact/http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst Peace, Scott From julian.rickards at ontario.ca Mon Feb 11 09:37:05 2008 From: julian.rickards at ontario.ca (Rickards, Julian (NDM)) Date: Mon Feb 11 09:38:13 2008 Subject: [uf-discuss] Fragment identifiers in hCard links In-Reply-To: <49154686-0789-4977-A418-0BDDE06B0078@randomchaos.com> References: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca><59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com><51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> <49154686-0789-4977-A418-0BDDE06B0078@randomchaos.com> Message-ID: <51B031AA62FB5C4CBA75E88D752287F201A63604@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> > -----Original Message----- > From: microformats-discuss-bounces@microformats.org > [mailto:microformats-discuss-bounces@microformats.org] On > Behalf Of Scott Reynen > Sent: February 11, 2008 11:21 AM > To: Microformats Discuss > Subject: Re: [uf-discuss] Fragment identifiers in hCard links > > On Feb 11, 2008, at 7:33 AM, Rickards, Julian (NDM) wrote: > > > I fixed the page and now it is valid. However, that doesn't > change the > > result. Having done a bit of testing, it appears that in > the URI link > > where I use a fragment identifier (which would normally use > the # as > > in index.html#fragment), I have tried both # and %23 (where > that comes > > from, I don't know) but neither work properly. > > "%23" is the URL encoding of the "#" character. This > character needs to be encoded to be sent to the server > because a plain "#" begins a fragment identifier, which is > handled by the browser after the server returns a page, so > the server never sees it. Technically everything in a query > string should be URL encoded, but the "#" character is the > only one that really matters. > > > Does anyone have any ideas as to how to put multiple hCards on one > > page and have individual links download individual vCards to the > > client's address book? > > It looks like what you're doing is correct, so I'd suggest > waiting for Brian to comment on why it isn't working with > X2V. It seems to work on Technorati's version of X2V: > > http://technorati.com/contact/http://www.mndm.gov.on.ca/mndm/m > ines/lands/pro/contact_e.asp%23devosst > > Peace, > Scott Thanks Scott. I am quite willing to use Technorati instead of X2V so will change the links. Jules From ryan at theryanking.com Mon Feb 11 10:04:57 2008 From: ryan at theryanking.com (Ryan King) Date: Mon Feb 11 10:05:10 2008 Subject: [uf-discuss] Fragment identifiers in hCard links In-Reply-To: <51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> References: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> <59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com> <51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> Message-ID: <91234CDF-5BEE-478B-8144-2A3DB99DA135@theryanking.com> On Feb 11, 2008, at 6:33 AM, Rickards, Julian (NDM) wrote: >> -----Original Message----- >> Please make sure your page is at least well-formed: >> >> http://validator.w3.org/check?uri=http%3A//www.mndm.gov.on.ca/ > mndm/mines/lands/pro/contact_e.asp%23devosst > > Ryan: > > I fixed the page and now it is valid. However, that doesn't change the > result. Having done a bit of testing, it appears that in the URI link > where I use a fragment identifier (which would normally use the # as > in > index.html#fragment), I have tried both # and %23 (where that comes > from, I don't know) '%23' is the url-encoded version of '#'. > but neither work properly. When I use #, only the > first contact is downloaded no matter which contact link I click. > However, when I use %23 in the URI, the only response I get is "No > vCards found" which is obviously not true because the hCard code meets > the specs. > > Maybe Brian Suda has changed the code on his server because a test > page > of mine that used to work doesn't work any longer. > > Does anyone have any ideas as to how to put multiple hCards on one > page > and have individual links download individual vCards to the client's > address book? You're doing it correctly, it appears to be a problem with X2V. Please document this issue on http://microformats.org/wiki/xfn-issues . -ryan From brian.suda at gmail.com Mon Feb 11 10:16:10 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 11 10:22:43 2008 Subject: [uf-discuss] Fragment identifiers in hCard links In-Reply-To: <49154686-0789-4977-A418-0BDDE06B0078@randomchaos.com> References: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> <59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com> <51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> <49154686-0789-4977-A418-0BDDE06B0078@randomchaos.com> Message-ID: <21e770780802111016v1f98aac1j24e4a73bb5150d1@mail.gmail.com> 2008/2/11, Scott Reynen : > It looks like what you're doing is correct, so I'd suggest waiting for > Brian to comment on why it isn't working with X2V. --- i had a look into this, and you are doing everything correctly. I have updated my code and the URL seems to work for me now: http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst I am not sure exactly where the issue is, but i fixed it. It boils down to cURL trying to fetch the URL with the fragment. Your server was returning an empty file, so i couldn't apply the XSLT to it. I changed cURL to fetch URLs without fragment identifiers, so this won't break anyone else's requests. I am not sure if this is an issue with cURL not correctly handling the URL or the server rejecting the cURL request. Eitherway, it is fixed for me, i hope for you as well. -brian -- brian suda http://suda.co.uk From julian.rickards at ontario.ca Mon Feb 11 11:08:05 2008 From: julian.rickards at ontario.ca (Rickards, Julian (NDM)) Date: Mon Feb 11 11:08:11 2008 Subject: [uf-discuss] Fragment identifiers in hCard links In-Reply-To: <21e770780802111016v1f98aac1j24e4a73bb5150d1@mail.gmail.com> References: <51B031AA62FB5C4CBA75E88D752287F201A633D9@CTSPITDCEMMVX03.cihs.ad.gov.on.ca><59F690D8-1527-470E-BD9D-2484509E818E@theryanking.com><51B031AA62FB5C4CBA75E88D752287F201A63573@CTSPITDCEMMVX03.cihs.ad.gov.on.ca><49154686-0789-4977-A418-0BDDE06B0078@randomchaos.com> <21e770780802111016v1f98aac1j24e4a73bb5150d1@mail.gmail.com> Message-ID: <51B031AA62FB5C4CBA75E88D752287F201A63636@CTSPITDCEMMVX03.cihs.ad.gov.on.ca> > -----Original Message----- > Either way, it is fixed for me, i hope for you as well. Yes, it is fixed now and working perfectly. Thanks, Jules From lists at ben-ward.co.uk Mon Feb 11 19:05:29 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Mon Feb 11 19:05:36 2008 Subject: [uf-discuss] Include Pattern Update Message-ID: <7E39909B-361A-4205-BABA-5643757F0E53@ben-ward.co.uk> Hey everyone, Following the research we did at Yahoo! last month, I've updated the include-pattern documentation to clarify, based on evidence, the accessibility issues raised. I've been through the documentation in full, and the following summarises the changes for those not wishing to analyse the Wiki diff. http://microformats.org/wiki/include-pattern ? Restored requirement for the hyperlink include pattern to include inner-text ? Changed the hyperlink pattern example to use hReview, not hResume, as the requirement for inner-text is not compatible with the needs of hResume. ? Added clear accessibility guidance to the hyperlink include pattern ? Clarified the language around use of CSS to improve the user experience around the include pattern, to make it clearer they are enhancements. This is a mark-up spec, and cannot depend on CSS. ? Directed scenarios that require content-less includes to the OBJECT pattern ? Removed statements of opinion and discussion. This is supposed to be documentation for the pattern, it should be concise and precise and should not contain tangential remarks. In future, areas of uncertainty should be documented only on the -issues or -feedback page (http://microformats.org/wiki/include-pattern-issues and http:// microformats.org/wiki/include-pattern-feedback repsectively). It's really, really, important that the documentation remains clear. ? Updated the ?Thanks? section to acknowledge the work my co-worker Mike Davies did in researching empty-hyperlink accessibility. ? Added explicit point that other microformat class names on the include element are discarded, and that all microformat classes should be on the target of an include, not the include element itself. Closes Mike Kaply's open issue. Please not that this update does not in any way concern of reflect recent discussions about specifying another include pattern (http:// microformats.org/wiki/include-pattern-strawman). This just brings us up-to-date with current research and knowledge. Regards, Ben From singpolyma at gmail.com Tue Feb 12 16:17:05 2008 From: singpolyma at gmail.com (Stephen Paul Weber) Date: Tue Feb 12 16:17:08 2008 Subject: [uf-discuss] hAtom - link to comments Message-ID: <6991f8e00802121617i3f23db77he156b5fbc19debc8@mail.gmail.com> It seems pretty common to have a link on the post archive/recent posts to the URL where comments actually are displayed (usually a fragment on the post permalink). Wordpress blogs and Blogger blogs almost universally have this (which probably hits the 80/20 right there...). Has there been much discussion on how to mark this up? I use rel=comment myself, but that's not remotely standard. Thoughts? From supercanadian at gmail.com Tue Feb 12 16:34:06 2008 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Tue Feb 12 16:40:11 2008 Subject: [uf-discuss] hAtom - link to comments In-Reply-To: <6991f8e00802121617i3f23db77he156b5fbc19debc8@mail.gmail.com> References: <6991f8e00802121617i3f23db77he156b5fbc19debc8@mail.gmail.com> Message-ID: <84ce626f0802121634o4f1e5403h6ea353e78a3b14a1@mail.gmail.com> Hello, On Feb 12, 2008 4:17 PM, Stephen Paul Weber wrote: [...] > rel=comment [...] > Thoughts? This has come up before... http://microformats.org/discuss/mail/microformats-discuss/2006-July/004776.html http://microformats.org/discuss/mail/microformats-discuss/2006-January/002894.html I don't think I ever got around to adding it to the wiki though. But yeah... seems like an adequate solution. I still use it regularly (where it is appropriate). See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Motorsport Videos http://TireBiterZ.com/ Vlog Razor... Vlogging News... http://vlograzor.com/ From andy at pigsonthewing.org.uk Wed Feb 13 01:22:37 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 13 01:24:29 2008 Subject: [uf-discuss] hAtom - link to comments In-Reply-To: <6991f8e00802121617i3f23db77he156b5fbc19debc8@mail.gmail.com> References: <6991f8e00802121617i3f23db77he156b5fbc19debc8@mail.gmail.com> Message-ID: In message <6991f8e00802121617i3f23db77he156b5fbc19debc8@mail.gmail.com>, Stephen Paul Weber writes >I use rel=comment myself, but that's not remotely standard. Please add that to: -- Andy Mabbett From mail at tobyinkster.co.uk Fri Feb 15 09:42:10 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Feb 15 10:01:20 2008 Subject: [uf-discuss] Perl microformat parsing Message-ID: Dear all, For the last week or so, I've been writing the beginnings of what I plan to be a GUI browser in Perl (probably using an embedded Gecko rendering engine, or WebKit if the Perl bindings get sorted out eventually). The browser will have a heavy emphasis on metadata, with information *about* the page being displayed prominently beside the page. Anyway, I've not started work on the GUI and have just been working on the (X)HTML parsing and metadata scraping and thought I'd share my results with you so far. The code is capable of parsing the following Microformats: * hCard (except categories) * geo * adr * hCalendar (except categories) * (include pattern) * (abbr pattern) Additionally it supports certain proposed extensions to microformats: my proposed alternative include pattern; Andy Mabbett's proposed "data:" prefix for abbr titles; and the "body" and "reference-frame" components to geo. It will also scrape non-microformat metadata from: * HTTP headers * TITLE element * META elements * LINK elements * eRDF * Role and understands metadata namespaces introduced through RFC 2731 compliant LINK elements. Currently it's terminal based, takes a single URL specified as a command line parameter, requests and parses the document, and dumps out the parsed data in a kinda readable format. Download alpha 1 here: http://examples.tobyinkster.co.uk/cognition-0.1-alpha1.pl It needs a bunch of Perl modules, but they're all in CPAN. I welcome feedback (either on this list, or directly to my e-mail address) on any problems you find with its parsing. I especially appreciate your feedback supplied as a patch! Also any ideas for future direction are welcome. -- 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 16 days, 23:44.] Mince & Dumplings http://tobyinkster.co.uk/blog/2008/02/10/mince-dumplings/ From john at westciv.com Sat Feb 16 15:36:13 2008 From: john at westciv.com (John Allsopp) Date: Sat Feb 16 15:45:26 2008 Subject: [uf-discuss] opencalais Message-ID: <6F13CD43-540B-4941-B88E-0F9F19888864@westciv.com> A little discussion is ensuing at the OpenCalais developer forums re the merits of supporting microformatted output in that system. Please feel free to join in! http://www.opencalais.com/forum/read/14259 j John Allsopp style master :: css editor :: http://westciv.com/style_master about me :: http://johnfallsopp.com Web Directions Conferences :: http://webdirections.org My Microformats book :: http://microformatique.com/book From andy at pigsonthewing.org.uk Sun Feb 17 02:47:20 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 17 03:22:01 2008 Subject: [uf-discuss] "alt" attributes; redux Message-ID: On Twitter, the markup: microformats is rendered by Operator as an XFN with: "undefined (contact)" because the "alt" attribute is not parsed. I've no doubt that other parsers do something similar (rel-lint seems to barf on them). Where several such graphic links exist, this results in a list of contacts: "undefined (contact)" "undefined (contact)" "undefined (contact)" "undefined (contact)" each of which refers to someone or something different; they are thus of little use to human or machine consumers. As I have pointed out previously, this is contrary to the intentions of the writers of the HTML specification: alt = text [CS] For user agents that cannot display images, forms, or applets, this attribute specifies alternate text [...] Several non-textual elements [...] let authors specify alternate text to serve as content when the element cannot be rendered normally. The alt attribute should be parsed, and the above example rendered as: "microformats (contact)" This applies to all microformat properties, where the content is expected to be text. -- Andy Mabbett From mail at tobyinkster.co.uk Mon Feb 18 05:43:11 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Feb 18 05:43:18 2008 Subject: [uf-discuss] rel="contact" Message-ID: <44376AE6-7C20-480C-962B-7630BC6708BA@tobyinkster.co.uk> The XFN 1.1 meaning of rel="contact" conflicts with the proposed semantics of rel="contact" in HTML 5. XFN 1.1 : | contact: Someone you know how to get in touch with. Often symmetric. HTML 5 : | contact: Gives a link to contact information for the current document. -- Toby A Inkster From andy at pigsonthewing.org.uk Mon Feb 18 06:05:53 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 18 06:05:56 2008 Subject: [uf-discuss] rel='contact' In-Reply-To: <44376AE6-7C20-480C-962B-7630BC6708BA@tobyinkster.co.uk> References: <44376AE6-7C20-480C-962B-7630BC6708BA@tobyinkster.co.uk> Message-ID: <13419.80.249.57.38.1203343553.squirrel@www.gradwell.com> On Mon, February 18, 2008 13:43, Toby A Inkster wrote: > The XFN 1.1 meaning of rel="contact" conflicts with the proposed > semantics of rel="contact" in HTML 5. > > XFN 1.1 : > | contact: Someone you know how to get in touch with. Often symmetric. > > > HTML 5 : > | contact: Gives a link to contact information for the current document. Anecdotally; I see lots of pages with links marked "contact xxx", where "xxx" is "us", "me" or the name of the organisation owning the page concerned (Google finds about 3,590,000,000 for "contact us"). Per the "process", where is the evidence that people use(d; pre-XFN) "contact" when linking to people who are their contacts (in the noun sense)? -- Andy Mabbett ** via webmail ** From thom at ts0.com Mon Feb 18 09:11:58 2008 From: thom at ts0.com (Thom Shannon) Date: Mon Feb 18 09:12:03 2008 Subject: [uf-discuss] "alt" attributes; redux In-Reply-To: References: Message-ID: <47B9BC5E.5020107@ts0.com> Andy Mabbett wrote: > As I have pointed out previously, this is contrary to the intentions of > the writers of the HTML specification: looks like a bug, I suggest submitting it to the author, http://www.kaply.com/weblog/operator/ From andy at pigsonthewing.org.uk Mon Feb 18 11:06:00 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 18 11:07:15 2008 Subject: [uf-discuss] "alt" attributes; redux In-Reply-To: <47B9BC5E.5020107@ts0.com> References: <47B9BC5E.5020107@ts0.com> Message-ID: In message <47B9BC5E.5020107@ts0.com>, Thom Shannon writes >Andy Mabbett wrote: [alt attribute ignored in some cases] >> As I have pointed out previously, this is contrary to the intentions of >> the writers of the HTML specification: >looks like a bug It's not; it's been discussed here before. >, I suggest submitting it to the author, >http://www.kaply.com/weblog/operator/ It's not just in Operator; as I said in my original post, rel-lint for one has the same problem. -- Andy Mabbett From ryan at theryanking.com Mon Feb 18 11:56:28 2008 From: ryan at theryanking.com (Ryan King) Date: Mon Feb 18 11:56:39 2008 Subject: [uf-discuss] rel="contact" In-Reply-To: <44376AE6-7C20-480C-962B-7630BC6708BA@tobyinkster.co.uk> References: <44376AE6-7C20-480C-962B-7630BC6708BA@tobyinkster.co.uk> Message-ID: On Feb 18, 2008, at 5:43 AM, Toby A Inkster wrote: > The XFN 1.1 meaning of rel="contact" conflicts with the proposed > semantics of rel="contact" in HTML 5. > > XFN 1.1 : > | contact: Someone you know how to get in touch with. Often symmetric. > > HTML 5 : > | contact: Gives a link to contact information for the current > document. I've given this feedback to the HTML-WG already. Ian Hickson, one of the editors, has said he'll address it in HTML5. -ryan From thom at ts0.com Mon Feb 18 15:40:08 2008 From: thom at ts0.com (Thom Shannon) Date: Mon Feb 18 15:40:16 2008 Subject: [uf-discuss] "alt" attributes; redux In-Reply-To: References: <47B9BC5E.5020107@ts0.com> Message-ID: <47BA1758.6080007@ts0.com> Andy Mabbett wrote: > It's not just in Operator; as I said in my original post, rel-lint for > one has the same problem. > Then surely it's just a common bug? If the specs say it should be so then it's an oversight on the developers part and someone should kindly let them know. From gareth at morethanseven.net Mon Feb 18 15:51:52 2008 From: gareth at morethanseven.net (gareth rushgrove) Date: Mon Feb 18 15:51:54 2008 Subject: [uf-discuss] Microformats for Write APIs Message-ID: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> Hi Guys [this post reposted to discuss after a brief outing on dev - http://microformats.org/discuss/mail/microformats-dev/2008-February/000447.html] A post to this list [ok, I got the wrong list first time round] seemed in order after a few discussions at SemanticCamp over the weekend. At this stage this is basically a pre-idea, floated to see if their is any general interest. The idea of using Microformats as a replacement for a seperate API layer has been mooted for a while*. But in general this has been a discussion about Read APIs (ie. asking for data) as apposed to Write APIs (ie. adding data). I'm interested in the idea of using microformats to auto-discover Write API functions. So a simple case might be: 1. Point a parser at a blog post page 2. Parser establishes that a form exists 3. Parser works out the method (GET, POST, PUT, DELETE, etc.) 4. Parser works out the form parameters, their input types and whether or not they are required 5. Parser can produce API docs So for instance taking Flickr as an example. Flickr allows comments on Photos from the photo page. eg. http://www.flickr.com/photos/garethr/2275608910/ Flickr also allows you to add comments via the API. http://www.flickr.com/services/api/flickr.photos.comments.addComment.html Standardisation might be interesting here as well. For instance back to blog comments. Comments from within aggregators would likely be simpler where comment form definitions can be established programmatically. Let me know what you think about the general idea. Gareth * http://allinthehead.com/retro/301/can-your-website-be-your-api -- Gareth Rushgrove garethrushgrove.com morethanseven.net getjobsin.com isitbirthday.com From andy at pigsonthewing.org.uk Mon Feb 18 15:59:24 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 18 16:01:09 2008 Subject: [uf-discuss] "alt" attributes; redux In-Reply-To: <47BA1758.6080007@ts0.com> References: <47B9BC5E.5020107@ts0.com> <47BA1758.6080007@ts0.com> Message-ID: <4SIbZwKcvhuHFwgq@pigsonthewing.org.uk> In message <47BA1758.6080007@ts0.com>, Thom Shannon writes > >Andy Mabbett wrote: >> It's not just in Operator; as I said in my original post, rel-lint >>for one has the same problem. >> >Then surely it's just a common bug? If the specs say it should be so >then it's an oversight on the developers part and someone should kindly >let them know. They don't; that's the problem. -- Andy Mabbett From ernest.prabhakar at gmail.com Mon Feb 18 17:02:04 2008 From: ernest.prabhakar at gmail.com (Ernest Prabhakar) Date: Mon Feb 18 17:02:07 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> Message-ID: <72A4937E-FBDB-4775-93FF-20E700EFCF46@gmail.com> Hi Gareth, On Feb 18, 2008, at 3:51 PM, gareth rushgrove wrote: >> The idea of using Microformats as a replacement for a seperate API >> layer has been mooted for a while*. But in general this has been a >> discussion about Read APIs (ie. asking for data) as apposed to Write >> APIs (ie. adding data). >> >> I'm interested in the idea of using microformats to auto-discover >> Write API functions. So a simple case might be: Sounds like you want hAtomPub :-) http://tools.ietf.org/html/rfc5023 -- Ernie P. > > > [this post reposted to discuss after a brief outing on dev - > http://microformats.org/discuss/mail/microformats-dev/2008-February/000447.html > ] > > A post to this list [ok, I got the wrong list first time round] seemed > in order after a few discussions at SemanticCamp over the weekend. At > this stage this is basically a > pre-idea, floated to see if their is any general interest. > > The idea of using Microformats as a replacement for a seperate API > layer has been mooted for a while*. But in general this has been a > discussion about Read APIs (ie. asking for data) as apposed to Write > APIs (ie. adding data). > > I'm interested in the idea of using microformats to auto-discover > Write API functions. So a simple case might be: > > 1. Point a parser at a blog post page > 2. Parser establishes that a form exists > 3. Parser works out the method (GET, POST, PUT, DELETE, etc.) > 4. Parser works out the form parameters, their input types and whether > or not they are required > 5. Parser can produce API docs > > So for instance taking Flickr as an example. Flickr allows comments on > Photos from the photo page. eg. > http://www.flickr.com/photos/garethr/2275608910/ > > Flickr also allows you to add comments via the API. > http://www.flickr.com/services/api/flickr.photos.comments.addComment.html > > Standardisation might be interesting here as well. For instance back > to blog comments. Comments from within aggregators would likely be > simpler where comment form definitions can be established > programmatically. > > Let me know what you think about the general idea. > > Gareth > > * http://allinthehead.com/retro/301/can-your-website-be-your-api > > -- > Gareth Rushgrove > garethrushgrove.com > morethanseven.net > getjobsin.com > isitbirthday.com > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From mdagn at spraci.com Mon Feb 18 18:47:31 2008 From: mdagn at spraci.com (Michael MD) Date: Mon Feb 18 18:47:36 2008 Subject: [uf-discuss] Microformats for Write APIs References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> Message-ID: <000801c872a1$c6d7ed40$116bacca@COMCEN> > Standardisation might be interesting here as well. For instance back > to blog comments. Comments from within aggregators would likely be > simpler where comment form definitions can be established > programmatically. The problem is that comment spammers would love that too! (similar issue as with email in hCard or even a mailto... good in theory but people are probably going to avoid using it because of fear that it will be used for spam!) From philip.tellis at gmail.com Mon Feb 18 22:09:19 2008 From: philip.tellis at gmail.com (Philip Tellis) Date: Mon Feb 18 22:09:24 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <000801c872a1$c6d7ed40$116bacca@COMCEN> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> <000801c872a1$c6d7ed40$116bacca@COMCEN> Message-ID: <2e95f9b80802182209q70fefd82g11b72da634344d98@mail.gmail.com> On 18/02/2008, Michael MD wrote: > The problem is that comment spammers would love that too! spammers are going to find ways to get at their targets no matter what you do to stop them. The only good way to fight spam is through pattern and content analysis (including IP and ISP blacklisting). We shouldn't block all legitimate uses of an application just because it could (and very likely would) be misused by a few. From uf-discuss at cilux.org Tue Feb 19 00:51:33 2008 From: uf-discuss at cilux.org (Duncan Cragg) Date: Tue Feb 19 00:51:37 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> Message-ID: <47BA9895.8080303@cilux.org> Gareth Rushgrove wrote: > The idea of using Microformats as a replacement for a separate API > layer has been mooted for a while*. But in general this has been a > discussion about Read APIs (ie. asking for data) as apposed to Write > APIs (ie. adding data). > > * http://allinthehead.com/retro/301/can-your-website-be-your-api > I found a post that predates this, and also talks about write APIs: http://duncan-cragg.org/blog/post/microformats-challenge-web-feeds-and-web-apis/ =0) (I've no doubt that someone can beat that, with an article from 1773 or something.) There's also some controversial, Microformat-related content in my latest post, for those who like a nice heated discussion: http://duncan-cragg.org/blog/post/content-types-and-uris-rest-dialogues/ > I'm interested in the idea of using microformats to auto-discover > Write API functions. > My approach - in the first article, in the REST Dialogues and in the Micro Web (http://the-u-web.org) - is that a standardised content type determines what it takes back as a POST. This is either explicit - 'here's a form you can use to talk to me!' - or implicit - 'I'm an Atom feed - go try APPing me!' (I'd suggest hAtom sticks to just POST, not the full APP PUT/DELETE, mind. Define hAPP, maybe? ) In the Micro Web, the idea is to recognise a comprehensive range of standardised JSON types and offer the user GUI functions to write back. Or, rather, to 'suggest back' - the server will often ignore the suggestion, e.g. if the user is not authorised. A JSON Atom feed would automatically offer the blog owner the new blog post form, and offer the general public the comment form, all generated in Javascript, not by the server, triggered by recognising the JSON type. If the script doesn't recognise the content type at all, it may still offer the user to directly edit the JSON fields and submit that back. I'm putting this out for general interest amongst fellow semantic webbers (smallcase), not to ruffle feathers. I'm sure this is the wrong list or off-topic or something - please don't tell me off. =0) Cheers! Duncan Cragg From gareth at morethanseven.net Tue Feb 19 02:55:09 2008 From: gareth at morethanseven.net (gareth rushgrove) Date: Tue Feb 19 02:55:13 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <2e95f9b80802182209q70fefd82g11b72da634344d98@mail.gmail.com> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> <000801c872a1$c6d7ed40$116bacca@COMCEN> <2e95f9b80802182209q70fefd82g11b72da634344d98@mail.gmail.com> Message-ID: <9011f7c70802190255k6e168931y1520b93ed39cab70@mail.gmail.com> On 2/19/08, Philip Tellis wrote: > On 18/02/2008, Michael MD wrote: > > > The problem is that comment spammers would love that too! > > spammers are going to find ways to get at their targets no matter what > you do to stop them. The only good way to fight spam is through > pattern and content analysis (including IP and ISP blacklisting). > > We shouldn't block all legitimate uses of an application just because > it could (and very likely would) be misused by a few. Yeah. It's the same argument for/against microformats in general. What I'm thinking about is the case were you already are looking to expose an API for people to use - and making it easier to use. In the same way as hCard makes an email address that you already had on the page easier to use. G > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Gareth Rushgrove garethrushgrove.com morethanseven.net getjobsin.com isitbirthday.com From gareth at morethanseven.net Tue Feb 19 02:57:31 2008 From: gareth at morethanseven.net (gareth rushgrove) Date: Tue Feb 19 02:57:34 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <72A4937E-FBDB-4775-93FF-20E700EFCF46@gmail.com> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> <72A4937E-FBDB-4775-93FF-20E700EFCF46@gmail.com> Message-ID: <9011f7c70802190257p4f65ccccnfed2317cb4a5437b@mail.gmail.com> On 2/19/08, Ernest Prabhakar wrote: > Hi Gareth, > > On Feb 18, 2008, at 3:51 PM, gareth rushgrove wrote: > >> > >> I'm interested in the idea of using microformats to auto-discover > >> Write API functions. So a simple case might be: > > Sounds like you want hAtomPub :-) > > http://tools.ietf.org/html/rfc5023 To some extent (and hAtom would be one of a few starting points I would think) but in some ways that's too restrictive. Not everyone is going to use APP and their isn't too much adoption as yet. But their are lots of forms out their that expose API like properties. Gareth > > -- Ernie P. > > > > > > > [this post reposted to discuss after a brief outing on dev - > > http://microformats.org/discuss/mail/microformats-dev/2008-February/000447.html > > ] > > > > A post to this list [ok, I got the wrong list first time round] seemed > > in order after a few discussions at SemanticCamp over the weekend. At > > this stage this is basically a > > pre-idea, floated to see if their is any general interest. > > > > The idea of using Microformats as a replacement for a seperate API > > layer has been mooted for a while*. But in general this has been a > > discussion about Read APIs (ie. asking for data) as apposed to Write > > APIs (ie. adding data). > > > > I'm interested in the idea of using microformats to auto-discover > > Write API functions. So a simple case might be: > > > > 1. Point a parser at a blog post page > > 2. Parser establishes that a form exists > > 3. Parser works out the method (GET, POST, PUT, DELETE, etc.) > > 4. Parser works out the form parameters, their input types and whether > > or not they are required > > 5. Parser can produce API docs > > > > So for instance taking Flickr as an example. Flickr allows comments on > > Photos from the photo page. eg. > > http://www.flickr.com/photos/garethr/2275608910/ > > > > Flickr also allows you to add comments via the API. > > http://www.flickr.com/services/api/flickr.photos.comments.addComment.html > > > > Standardisation might be interesting here as well. For instance back > > to blog comments. Comments from within aggregators would likely be > > simpler where comment form definitions can be established > > programmatically. > > > > Let me know what you think about the general idea. > > > > Gareth > > > > * http://allinthehead.com/retro/301/can-your-website-be-your-api > > > > -- > > Gareth Rushgrove > > garethrushgrove.com > > morethanseven.net > > getjobsin.com > > isitbirthday.com > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Gareth Rushgrove garethrushgrove.com morethanseven.net getjobsin.com isitbirthday.com From thom at ts0.com Tue Feb 19 08:04:39 2008 From: thom at ts0.com (Thom Shannon) Date: Tue Feb 19 08:04:45 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <000801c872a1$c6d7ed40$116bacca@COMCEN> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> <000801c872a1$c6d7ed40$116bacca@COMCEN> Message-ID: <47BAFE17.1030009@ts0.com> >> Standardisation might be interesting here as well. For instance back >> to blog comments. Comments from within aggregators would likely be >> simpler where comment form definitions can be established >> programmatically. > > The problem is that comment spammers would love that too! You could always add some standards for including captchas (both visual and auditory) and also include form auth tokens (used to stop cross site posting attacks) which would be tricky to implement considering the way this functionality would be used. There's OpenID to consider too. From jpanzer at acm.org Tue Feb 19 09:25:25 2008 From: jpanzer at acm.org (John Panzer) Date: Tue Feb 19 09:21:46 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <47BAFE17.1030009@ts0.com> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> <000801c872a1$c6d7ed40$116bacca@COMCEN> <47BAFE17.1030009@ts0.com> Message-ID: <47BB1105.2000606@acm.org> Thom Shannon wrote: > >>> Standardisation might be interesting here as well. For instance back >>> to blog comments. Comments from within aggregators would likely be >>> simpler where comment form definitions can be established >>> programmatically. >> >> The problem is that comment spammers would love that too! > You could always add some standards for including captchas (both > visual and auditory) and also include form auth tokens (used to stop > cross site posting attacks) which would be tricky to implement > considering the way this functionality would be used. There's OpenID > to consider too. Keeping comments from fragmenting is a worthwhile goal. Large hosted blog site already have this problem of being targets for comment spammers, and use the countermeasures above as well as others, so perhaps they'd be interested in standardizing this. OAuth could help with cross site posting, though it would require a trip through the target site's UI. (Disclosure: I work on Blogger.) John From gareth at morethanseven.net Tue Feb 19 11:22:59 2008 From: gareth at morethanseven.net (gareth rushgrove) Date: Tue Feb 19 11:23:01 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <47BB1105.2000606@acm.org> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> <000801c872a1$c6d7ed40$116bacca@COMCEN> <47BAFE17.1030009@ts0.com> <47BB1105.2000606@acm.org> Message-ID: <9011f7c70802191122v458f4945t7b915956cffce3fd@mail.gmail.com> Their seems to be a little interest in the idea anyhow. On 2/19/08, John Panzer wrote: > Thom Shannon wrote: > > > >>> Standardisation might be interesting here as well. For instance back > >>> to blog comments. Comments from within aggregators would likely be > >>> simpler where comment form definitions can be established > >>> programmatically. > >> > Keeping comments from fragmenting is a worthwhile goal. Is the best approach here to look at web wide general forms that are also (or could be) represented by an API or is it best to look specifically at comments (for instance) whether an API for commenting is present or not? I'm going to try and collate some examples and the like together when I get a chance, starting with the likes of APP, Wordpress, Flickr, Blogger and the like. Is the best bet to use the microformats wiki in the first instance or to do this elsewhere until any sort of way forward is proposed and generally agreed upon? Gareth -- Gareth Rushgrove garethrushgrove.com morethanseven.net getjobsin.com isitbirthday.com From scott at randomchaos.com Tue Feb 19 12:28:39 2008 From: scott at randomchaos.com (Scott Reynen) Date: Tue Feb 19 12:28:43 2008 Subject: [uf-discuss] Microformats for Write APIs In-Reply-To: <9011f7c70802191122v458f4945t7b915956cffce3fd@mail.gmail.com> References: <9011f7c70802181551u23160152n79cad96b93361047@mail.gmail.com> <000801c872a1$c6d7ed40$116bacca@COMCEN> <47BAFE17.1030009@ts0.com> <47BB1105.2000606@acm.org> <9011f7c70802191122v458f4945t7b915956cffce3fd@mail.gmail.com> Message-ID: <3A11A56A-D19E-44A8-A090-510AE5EBB914@randomchaos.com> On Feb 19, 2008, at 12:22 PM, gareth rushgrove wrote: > Their seems to be a little interest in the idea anyhow. > > On 2/19/08, John Panzer wrote: >> Thom Shannon wrote: >>> >>>>> Standardisation might be interesting here as well. For instance >>>>> back >>>>> to blog comments. Comments from within aggregators would likely be >>>>> simpler where comment form definitions can be established >>>>> programmatically. >>>> > >> Keeping comments from fragmenting is a worthwhile goal. > > Is the best approach here to look at web wide general forms that are > also (or could be) represented by an API or is it best to look > specifically at comments (for instance) whether an API for commenting > is present or not? > > I'm going to try and collate some examples and the like together when > I get a chance, starting with the likes of APP, Wordpress, Flickr, > Blogger and the like. Is the best bet to use the microformats wiki in > the first instance or to do this elsewhere until any sort of way > forward is proposed and generally agreed upon? The wiki is a good place to document research. Even if we don't end up heading down a given path, it's still useful to have a record of why we didn't. Assuming you've already taken the first step of the process [1] and added microformats to your own site(s) to get a feel for how they work, I'd suggest creating a wiki page at comment-form- examples and documenting which fields are most common among various comment forms. And while I hate to tell you to move this discussion yet again, this is starting to seem more like something that belongs on the microformats-new list, so I'm cross-posting it there. [1] http://microformats.org/wiki/process Peace, Scott From mail at tobyinkster.co.uk Wed Feb 20 01:27:58 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Feb 20 01:59:13 2008 Subject: [uf-discuss] XOXO Implementations Message-ID: Many -- in fact, most! -- of the links to "simple examples" and "implementations" on the XOXO specification do not conform to XOXO. e.g. http://diveintomark.org/public/2004/01/xo-embeddable.xo http://odeo.com/profile/RyanKing/xoxo http://homepage.mac.com/ctholland/thelab/outlines/ They do not include class="xoxo" on the root list element. The specification says: The root element of a simple well-formed XML XOXO page is either an ol or ul with class name of "xoxo". If this class name is not really a requirement of XOXO, then the specification is misleading and should be changed. If the class name *is* a requirement, then can these examples be removed and replaced with conforming examples? -- 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 21 days, 15:35.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From mail at tobyinkster.co.uk Wed Feb 20 10:25:18 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Feb 20 10:25:42 2008 Subject: [uf-discuss] Re: Perl microformat parsing References: Message-ID: Toby A Inkster wrote: > For the last week or so, I've been writing the beginnings of what I plan > to be a GUI browser in Perl (probably using an embedded Gecko rendering > engine, or WebKit if the Perl bindings get sorted out eventually). The > browser will have a heavy emphasis on metadata, with information *about* > the page being displayed prominently beside the page. > > Anyway, I've not started work on the GUI and have just been working on > the (X)HTML parsing and metadata scraping and thought I'd share my > results with you so far. An updated version is here: http://buzzword.org.uk/cognition/cognition-0.1-alpha2.txt In recognition that not everyone has Perl installed, and all the right CPAN modules, here's a web-based front-end for the parser: http://buzzword.org.uk/cognition/cognition-0.1-alpha2.pl It supports the following microformats: * hCard * geo (plus extensions: body, reference-frame, altitude) * adr * hCalendar * rel-tag * rel-license * XOXO * figure (experimental, based on current brainstorming) It supports the official include pattern, plus my own suggested include pattern (using class names beginning with a hash sign). It supports the ABBR pattern, plus Andy Mabbett's proposed "data:"-in-title-attribute pattern (bug fixed on that -- thanks Andy). It builds up a document structure based on heading levels, and also includes XOXO lists, figures, and "semantic tables" (any table with either a summary attribute or element) in the structure. It will also scrape non-microformat metadata from: * HTTP headers * TITLE element * META elements * LINK elements * eRDF * Role and understands metadata namespaces introduced through RFC 2731 compliant LINK elements, and xmlns:FOO attributes. If you have Perl on your system, I recommend downloading the Perl script and installing the needed modules from CPAN. The script is tested and working on Linux and Mac OS X. If you don't have Perl, then the web interface should give you a good idea of its parsing results. I welcome feedback (either on this list, or directly to my e-mail address) on any problems you find with its parsing. I especially appreciate your feedback supplied as a patch! Also any ideas for future direction are welcome. -- 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 22 days, 29 min.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From andy at pigsonthewing.org.uk Wed Feb 20 15:56:45 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 20 16:08:18 2008 Subject: [uf-discuss] Fwd: [UKUUG-Announce] Call for Participation - OpenTech 2008 Message-ID: Perhaps someone would like to attend, and talk about microformats? >---------- Forwarded message ---------- >From: Jane Morrison >Date: Feb 20, 2008 9:56 AM >Subject: [UKUUG-Announce] Call for Participation - OpenTech 2008 >To: announce@ukuug.org > >OpenTech is an informal, low-cost one-day grassroots event that we put >on every couple of years for people in the UK to get together and talk >about digital technology, its impacts on society and - newly added >this year - the environment. In previous years we heard from the >founder of the Internet Archive and the man behind BitTorrent, saw the >launch of TheyWorkForYou.com, and triggered the creation of the Open >Rights Group. We also had a presentation from a chap who'd made a >semi-reliable clock out of an old PC and a prawn sandwich, so it's not >all serious stuff. > >We're accepting proposals for talks between today and the 31st March, >The full details are below, and there's more information on our >website (http://www.ukuug.org/events/opentech2008/). > > > > Call for Participation - OpenTech 2008 > > Saturday 5 July 2008, London, UK > > Presented by UKUUG in association with mySociety + Open Rights Group > http://www.ukuug.org/events/opentech2008/ > > > *What is OpenTech 2008?* > A low-cost, one-day grassroots conference with a wide range of > sessions covering digital technology, society and > the environment > > > *What do we need?* > Proposals from people who want to give a > presentation, run a panel, organise a workshop, or > run a demo of something new and interesting > > Publicity - please blog this announcement, write a > newspaper article, forward to mailing lists, and > tell your friends! > > > *What topics do we hope to cover?* > - Mashups, open data and security > - Future of media distribution > - Low-carbon and low-impact living > - New adventures in hardware hacking > - Politics 2.0 > - Long term thinking on big problems and massive opportunities > > - If you've got an interesting proposal that doesn't fit into any of > the categories above, please send it in anyway! > > > *How do I submit a proposal?" > Please use the form on http://www.ukuug.org/events/opentech2008/ > The deadline for submissions is midnight on Sunday 30 March 2008 > > > *Can I buy or reserve a ticket to the event?* > Register at http://www.ukuug.org/events/opentech2008/list > and we'll email you nearer the time with more information > > > *Any other questions?* > > If you have any other questions, or want to make us > an offer we can't refuse, please visit > http://www.ukuug.org/events/opentech2008/ for more > information and contact details of the event > organisers > > > OpenTech 2008 organisers (Ben Lamb, Etienne Pollard, Sam Smith) > http://www.ukuug.org/events/opentech2008/ >-- >UKUUG Secretariat >PO Box 37 >Buntingford >Herts SG9 9UQ >Tel: 01763 273475 >Fax: 01763 273255 >office@ukuug.org >www.ukuug.org > >A Company Limited by Guarantee > >Registered Office: >The Manor House >Buntingford >Herts SG9 9AB > >Reg. No. 2506680 > >_______________________________________________ >Announce mailing list >Announce@lists.ukuug.org >http://lists.ukuug.org/mailman/listinfo/announce -- Andy Mabbett From roBman at MobileOnlineBusiness.com.au Wed Feb 20 16:05:41 2008 From: roBman at MobileOnlineBusiness.com.au (Rob Manson) Date: Wed Feb 20 16:24:47 2008 Subject: [uf-discuss] Re: Perl microformat parsing In-Reply-To: References: Message-ID: <1203552341.3042.557.camel@robslap> Hey Toby, the parser is failing on a lot of the pages on the microformats wiki - seemed like a logical place to point it at to test it 8). e.g. not well-formed (invalid token) at line 8, column 2478, byte 3581 at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/XML/Parser.pm line 187 This is because most of the wiki pages include specials like nbsp's. Here's a patch to prove that this is the problem using a quick and dirty regex fix: 848d847 < $html =~ s/\ \;//igm; I tried it on both a simple hcard like http://microformats.org/wiki/User:RobManson and the full hcard page (which is veeeeery slow to parse) http://microformats.org/wiki/hcard and the patch fixes it. A more thorough fix would probably be based upon the notes in 8.3 and 8.4 on the following link. http://perl-xml.sourceforge.net/faq/#not_well_formed Hope that's useful 8) roBman On Wed, 2008-02-20 at 18:25 +0000, Toby A Inkster wrote: > Toby A Inkster wrote: > > > For the last week or so, I've been writing the beginnings of what I plan > > to be a GUI browser in Perl (probably using an embedded Gecko rendering > > engine, or WebKit if the Perl bindings get sorted out eventually). The > > browser will have a heavy emphasis on metadata, with information *about* > > the page being displayed prominently beside the page. > > > > Anyway, I've not started work on the GUI and have just been working on > > the (X)HTML parsing and metadata scraping and thought I'd share my > > results with you so far. > > An updated version is here: > > http://buzzword.org.uk/cognition/cognition-0.1-alpha2.txt > > In recognition that not everyone has Perl installed, and all the right > CPAN modules, here's a web-based front-end for the parser: > > http://buzzword.org.uk/cognition/cognition-0.1-alpha2.pl > > It supports the following microformats: > > * hCard > * geo (plus extensions: body, reference-frame, altitude) > * adr > * hCalendar > * rel-tag > * rel-license > * XOXO > * figure (experimental, based on current brainstorming) > > It supports the official include pattern, plus my own suggested include > pattern (using class names beginning with a hash sign). It supports the > ABBR pattern, plus Andy Mabbett's proposed "data:"-in-title-attribute > pattern (bug fixed on that -- thanks Andy). > > It builds up a document structure based on heading levels, and also > includes XOXO lists, figures, and "semantic tables" (any table with either > a summary attribute or element) in the structure. > > It will also scrape non-microformat metadata from: > > * HTTP headers > * TITLE element > * META elements > * LINK elements > * eRDF > * Role > > and understands metadata namespaces introduced through RFC 2731 compliant > LINK elements, and xmlns:FOO attributes. > > If you have Perl on your system, I recommend downloading the Perl script > and installing the needed modules from CPAN. The script is tested and > working on Linux and Mac OS X. If you don't have Perl, then the web > interface should give you a good idea of its parsing results. > > I welcome feedback (either on this list, or directly to my e-mail address) > on any problems you find with its parsing. I especially appreciate your > feedback supplied as a patch! > > Also any ideas for future direction are welcome. > From mail at tobyinkster.co.uk Thu Feb 21 02:14:00 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Feb 21 03:01:23 2008 Subject: [uf-discuss] Re: Perl microformat parsing References: <1203552341.3042.557.camel@robslap> Message-ID: <8gvv85-5o6.ln1@ophelia.g5n.co.uk> Rob Manson wrote: > Here's a patch to prove that this is the problem using a quick and dirty > regex fix: > > 848d847 > < $html =~ s/\ \;//igm; > > I tried it on both a simple hcard like > http://microformats.org/wiki/User:RobManson and the full hcard page > (which is veeeeery slow to parse) http://microformats.org/wiki/hcard and > the patch fixes it. Thanks for your hint. The XML::Parser module is able to fetch DTDs and use them, so should be able to handle expansion of named entities by itself -- the only problem was that I had disabled it, partly to cut down on bandwidth usage, but also because I thought it would break too many pages to validate them. Anyway, I've re-enabled it and this seems to have fixed more pages than it's broken. I'm guessing that XML::Parser does not validate based on the DTD -- it just uses them to expand entities. With regards to speed, that's because I'm using LWP::RobotUA instead of LWP::UserAgent. This downloads the robots.txt (and honours it) and also enforces a delay between each request. The delay is 1 minute by default though I set it to 10 seconds -- or at least I thought I did, but I was trying to set it in the LWP::RobotUA constructor function, which it seems does not work. The delay is now set to 5 seconds and works. This has made it significantly faster. New version (0.1-alpha2.1): Online: http://buzzword.org.uk/cognition/cognition-0.1-alpha2.1.pl Download: http://buzzword.org.uk/cognition/cognition-0.1-alpha2.1.txt This successfully parses both the pages you mentioned above. Thanks again, -- 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 22 days, 16:20.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From jeremy at adactio.com Thu Feb 21 04:03:03 2008 From: jeremy at adactio.com (Jeremy Keith) Date: Thu Feb 21 04:03:07 2008 Subject: [uf-discuss] Fwd: [UKUUG-Announce] Call for Participation - OpenTech 2008 In-Reply-To: References: Message-ID: <1816E5BC-D691-4A12-B6AD-D5E26C95B9EC@adactio.com> Andy Mabbett wrote: > Perhaps someone would like to attend, and talk about microformats? This looks like a good event and I'm pretty sure I'll be around at that time so I've submitted a proposal for a quick microformats talk. http://www.ukuug.org/events/opentech2008/ Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From msporny at digitalbazaar.com Thu Feb 21 06:39:08 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Feb 21 07:49:12 2008 Subject: [uf-discuss] Sparqlbot - kinda like the computer on Star Trek Message-ID: <47BD8D0C.5040004@digitalbazaar.com> This has to be the coolest semantic web related thing I've seen this year. Sparqlbot lets you load semantic data from various URLs and perform SPARQL queries on them via IRC using natural language. It understands hCard, there is an example of it being used in Twitter - neat proof of concept. The end result is something that resembles the ship computer from Star Trek. ---------------------------------------------------------------------------------- * Now talking on #sparqlbot, on irc.freenode.net * Topic for #sparqlbot is: sparqlbot noise, see http://semsol.org/semcamp/sparqlbot for commands * Topic for #sparqlbot set by bengee at Wed Feb 20 12:04:32 2008 * #sparqlbot :[freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg sparqlbot, load http://rss.slashdot.org/Slashdot/slashdot 221 triples loaded in 4.78 seconds sparqlbot, news about RIAA Leaked RIAA Training Video (http://yro.slashdot.org/article.pl?sid=08/02/20/2317202&from=rss) hey manu. that was quick ;) :) try the geo stuff or picture as well yeah, wanted to try it out :) how do you use the geo stuff? omp, I'll show % Geonames-based location on Google map sparqlbot, geo-load Vienna 35 triples loaded in 1.53 seconds so instead of Vienna you can use any name of a city, etc sparqlbot, where is Vienna Vienna is at 48.2084877601653, 16.3720750808716, view on map: http://maps.google.com/maps?q=48.2084877601653,16.3720750808716 wow that's awesome. it goes to Geonames, searches for 'Vienna' and the lat/long is put into map next: Person % FOAF-based person's geo-home (location on Google map) sparqlbot, load http://sw-app.org/mic.xhtml 41 triples loaded in 1.93 seconds note: that's RDFa ;) sparqlbot, mhausenblas's geo-home http://sw-app.org/mic.xhtml#i geo-home is at 47.064, 15.453, view on map: http://maps.google.com/maps?q=47.064,15.453 mhausenblas is my foaf:nick * msporny's jaw is on the floor. you can also pull in from Twitter (has hCard) so, it understands hCard using GRDDL? yeah. bengee did really a great job with the bot!!! no doubt! not sure about how the ?F is pulled in - bengee? via ARC extractors and thanks :) just updated the command UI do you have a demo of hCard being used? I'm going to send this out to the uF community. the hcards from twitter work got an example? it's added as foaf:name hmm, but needs foaf:nick, too great! thankx bengee. wouldn't be URI be better for the author? so, no pure hcard command yet I think I added both, for now :9 dc:creator was simpler :) * TedThibodeauJr (n=Thud@ws2.openlinksw.com) has joined #sparqlbot sparqlbot, load http://twitter.com/Scobleizer ah, damn you ;) :) 1132 triples loaded in 20.3 seconds YES! sparqlbot, smush OK :( What does smush do? It sounds like all my triples are gone... sparqlbot, Scobleizer's contacts bengee, I found Mr Messina, missrogue, Scott Beale, Evan Williams, Jack Dorsey, Biz Stone, sara, Krissy, Philip Kaplan, veen, Jason Shellen, Sacca, Scott Fegette, Matt Galligan, Jerry Richardson, danah, Brian Walsh, Clint G, Jim Williams, Paul Morriss, Colin Schl????ter, Ian Hay, Wayne Sutton, nanek, Ross, caroline, Hunter, Eric Alba, Brad Barrish, necrodome, Mack D. Male, Nitin, om, Jason, Narendra, steve epstein, Dave McClure, Brad Davis S smush consolidates bnodes so that you can do xfn queries (like the one above) by name bengee - this is the coolest thing I've seen this year. heh, thx sparqlbot, faq microformats bengee, see http://www.w3.org/2001/sw/SW-FAQ#relmf what I say all the time!!!!! bengee IS cool :) % Geonames-based pictures from flickr sparqlbot, geo-load Rome 103 triples loaded in 3.71 seconds sparqlbot, pictures from Rome pictures from Rome at 41.9, 12.4833333, view via flickrwrappr: http://www4.wiwiss.fu-berlin.de/flickrwrappr/page/photosDepictingLocation/41.9/12.4833333/10000 -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: RDFa Basics in 8 minutes (video) http://blog.digitalbazaar.com/2008/01/07/rdfa-basics/ From andy at pigsonthewing.org.uk Thu Feb 21 11:14:19 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 21 11:15:38 2008 Subject: [uf-discuss] Wiki warning precludes quoted evidence Message-ID: <0XMIYlrL2cvHFwZQ@pigsonthewing.org.uk> Editing screens on the microformats wiki currently include the warning: Do not copy text from other websites without a public domain -compatible license. It will be deleted. This would preclude the gathering if evidence required by the "process" (and is probably not what is meant anyway). It should be re-worded to allow the fair-use quoting of other websites. -- Andy Mabbett From csarven at gmail.com Fri Feb 22 09:52:33 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Fri Feb 22 09:52:35 2008 Subject: [uf-discuss] Fictional or intangible entities in hCard Message-ID: Can hCard be used for fictional or intangible entities? Is this addressed anywhere? Examples: * Purple unicorn * Heaven Main Lobby * Hypercube * Dream character -Sarven From takatsugu.shigeta at gmail.com Fri Feb 22 10:39:30 2008 From: takatsugu.shigeta at gmail.com (Takatsugu Shigeta) Date: Fri Feb 22 10:39:36 2008 Subject: [uf-discuss] Re: Perl microformat parsing In-Reply-To: <8gvv85-5o6.ln1@ophelia.g5n.co.uk> References: <1203552341.3042.557.camel@robslap> <8gvv85-5o6.ln1@ophelia.g5n.co.uk> Message-ID: Hi Toby, If you want to scrape only web pages, I would like to recommend the following CPAN module. Web::Scraper http://search.cpan.org/dist/Web-Scraper/ == sample code == #!/usr/bin/perl use strict; use warnings; use Data::Dumper; use URI; use Web::Scraper; my $url = 'http://diveintomark.org/projects/greasemonkey/hcard/tests/2-4-2-vcard.xhtml'; my $fn = scraper { process '.vcard .fn', 'fn[]' => 'TEXT'; process '.vcard .tel', 'tel[]' => 'TEXT'; process '.vcard .title', 'title[]' => 'TEXT'; result 'fn', 'tel', 'title'; }->scrape(URI->new($url)); print Dumper $fn; == sample output == $ perl hcard.pl $VAR1 = { 'tel' => [ '+1-919-555-7878' ], 'title' => [ 'Area Administrator, Assistant' ], 'fn' => [ 'Joe Friday' ] }; Thanks. -- shigeta On Thu, Feb 21, 2008 at 7:14 PM, Toby A Inkster wrote: > Rob Manson wrote: > > > Here's a patch to prove that this is the problem using a quick and dirty > > regex fix: > > > > 848d847 > > < $html =~ s/\ \;//igm; > > > > I tried it on both a simple hcard like > > http://microformats.org/wiki/User:RobManson and the full hcard page > > (which is veeeeery slow to parse) http://microformats.org/wiki/hcard and > > the patch fixes it. > > Thanks for your hint. The XML::Parser module is able to fetch DTDs and use > them, so should be able to handle expansion of named entities by itself -- > the only problem was that I had disabled it, partly to cut down on > bandwidth usage, but also because I thought it would break too many pages > to validate them. Anyway, I've re-enabled it and this seems to have fixed > more pages than it's broken. I'm guessing that XML::Parser does not > validate based on the DTD -- it just uses them to expand entities. > > With regards to speed, that's because I'm using LWP::RobotUA instead of > LWP::UserAgent. This downloads the robots.txt (and honours it) and also > enforces a delay between each request. The delay is 1 minute by default > though I set it to 10 seconds -- or at least I thought I did, but I was > trying to set it in the LWP::RobotUA constructor function, which it seems > does not work. The delay is now set to 5 seconds and works. This has made > it significantly faster. > > New version (0.1-alpha2.1): > > Online: http://buzzword.org.uk/cognition/cognition-0.1-alpha2.1.pl > Download: http://buzzword.org.uk/cognition/cognition-0.1-alpha2.1.txt > > This successfully parses both the pages you mentioned above. > > Thanks again, > > > -- > 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 22 days, 16:20.] > > > Bottled Water > http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ > > _______________________________________________ > > > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From ckstjohn at gmail.com Fri Feb 22 11:06:36 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Fri Feb 22 11:06:38 2008 Subject: [uf-discuss] Fictional or intangible entities in hCard In-Reply-To: <8ba906450802221043v34f58654g4592f8cce2603fe@mail.gmail.com> References: <8ba906450802221043v34f58654g4592f8cce2603fe@mail.gmail.com> Message-ID: <8ba906450802221106g54d106b1g517d3687dbd7cca1@mail.gmail.com> On Fri, Feb 22, 2008 at 1:43 PM, Christopher St John wrote: > On Fri, Feb 22, 2008 at 12:52 PM, Sarven Capadisli wrote: > > Can hCard be used for fictional or intangible entities? Is this > > addressed anywhere? > > > > Examples: > > * Purple unicorn > > * Heaven Main Lobby > > * Hypercube > > * Dream character > > > On a more serious note: http://getsemantic.com/wiki/Non-human_profiles note that that's not the official microformats wiki. -- Christopher St. John http://artofsystems.blogspot.com From ckstjohn at gmail.com Fri Feb 22 10:43:24 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Fri Feb 22 12:36:57 2008 Subject: [uf-discuss] Fictional or intangible entities in hCard In-Reply-To: References: Message-ID: <8ba906450802221043v34f58654g4592f8cce2603fe@mail.gmail.com> On Fri, Feb 22, 2008 at 12:52 PM, Sarven Capadisli wrote: > Can hCard be used for fictional or intangible entities? Is this > addressed anywhere? > > Examples: > * Purple unicorn > * Heaven Main Lobby > * Hypercube > * Dream character > Purple Unicorn : No. Heaven Main Lobby : Yes. Hypercube: Yes. Dream character: Yes. In fact, any fictional or intangible entity can be used as long as the "fictional or intangible" bit is set. Except unicorns. hCard may not under any circumstances be used to to represent unicorns, even if the "fictional or intangible" bit is set to true. Note that setting the "fictional or intangible" bit incorrectly can have serious consequences, ref "Thor" or "God of the Old Testament". -cks -- Christopher St. John http://artofsystems.blogspot.com From mdagn at spraci.com Sat Feb 23 01:39:01 2008 From: mdagn at spraci.com (Michael MD) Date: Sat Feb 23 01:39:05 2008 Subject: [uf-discuss] Re: Perl microformat parsing In-Reply-To: Message-ID: <200802230939.m1N9d1N56130@proxy.syd.comcen.com.au> >Web::Scraper >http://search.cpan.org/dist/Web-Scraper/ Interesting ... didn't know about that one... I had a go at a perl parser for microformats a couple of years ago: Test version here http://www.spraci.com/cgi-bin/microformats.cgi I tried to keep dependencies down to a minimum for this. It has its own tagsoup parser - no html or xml parsing libraries needed! (can be used in places where people can't compile anything non-perl) It won't die if there is a curly quote or other strange entity in there and it will even cope with the occasional unquoted parameter. (unclosed tags will still cause trouble but there IS a limit to how liberal something like this can be!) It tried to make it handle include-pattern too (seems to work but probably needs more testing) ... still a work in progress though... The code needs cleaning up (still rather messy - certainly nowhere near a suitable standard for releasing on CPAN), the parsing rules need more work, and I still haven't fully decided on the format of its output. The plan was to one day (when I'm at least reasonably happy with the code!) to put the source code up somewhere for people to download. From miyagawa at gmail.com Sat Feb 23 02:46:40 2008 From: miyagawa at gmail.com (Tatsuhiko Miyagawa) Date: Sat Feb 23 02:46:43 2008 Subject: [uf-discuss] Re: Perl microformat parsing In-Reply-To: References: <1203552341.3042.557.camel@robslap> <8gvv85-5o6.ln1@ophelia.g5n.co.uk> Message-ID: <693254b90802230246l68da0aefxaa1243a5064d1f0a@mail.gmail.com> On 2/22/08, Takatsugu Shigeta wrote: > my $url = 'http://diveintomark.org/projects/greasemonkey/hcard/tests/2-4-2-vcard.xhtml'; > > my $fn = scraper { > process '.vcard .fn', 'fn[]' => 'TEXT'; > process '.vcard .tel', 'tel[]' => 'TEXT'; > process '.vcard .title', 'title[]' => 'TEXT'; > result 'fn', 'tel', 'title'; > }->scrape(URI->new($url)); For a better nested output, use strict; use Web::Scraper; use URI; my $uri = URI->new("http://diveintomark.org/projects/greasemonkey/hcard/tests/2-4-2-vcard.xhtml"); my $scraper = scraper { process ".vcard", "vcards[]" => scraper { process ".email", email => '@href'; process ".fn", fullname => "TEXT"; process ".tel", tel => "TEXT"; process ".title", title => "TEXT"; }; }; my $result = $scraper->scrape($uri); __END__ $VAR1 = { 'vcards' => [ { 'email' => bless( do{\(my $o = 'mailto:jfriday@host.com')}, 'URI::mailto' ), 'tel' => '+1-919-555-7878', 'fullname' => 'Joe Friday', 'title' => 'Area Administrator, Assistant' }, ] }; Well, you get this vard twice because it has nester .vcard but I guess that's fine :) Thanks, -- Tatsuhiko Miyagawa From mail at tobyinkster.co.uk Sat Feb 23 06:50:12 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Feb 23 07:01:23 2008 Subject: [uf-discuss] Re: Perl microformat parsing References: <1203552341.3042.557.camel@robslap> <8gvv85-5o6.ln1@ophelia.g5n.co.uk> Message-ID: <4eo595-fvc.ln1@ophelia.g5n.co.uk> Takatsugu Shigeta wrote: > Web::Scraper > http://search.cpan.org/dist/Web-Scraper/ This looks like a handy module for some purposes, but it's not sufficient for fully parsing microformats: 1. It doesn't seem to support the rel attribute on links, so it will fall down when looking for rel-tag (which is used for encoding categories in hcard). 2. For images, the alt text should normally be returned (except for a few properties like photo and logo in hcard), but this module doesn't read alt text. [ It seems that my code kicks Operator's ass in this dept ;-) ] 3. The module won't handle nested hcards properly. Nested hcards are sometimes used for the "agent" property, and sometimes just to be damn annoying. Probably other reasons too, but I can't be bothered to think them all through. These three ought to be enough to deter people from using it for serious parsing though. To parse microformats properly you need DOM, or something of similar sophistication. For what it's worth, for alpha3 of my code I've switched to XML::LibXML, which is an alternative to XML::DOM. It copes much better with parsing random HTML off the web, and has namespace support should I decide I need it for anything. A preview of what I've already got working for alpha3: - Partial support for RDFa. (All the important bits.) - Support for CURIEs. - Internally store all parsed data as RDF triples. Ability to dump parsed metadata (including microformats) as valid RDF. (The web interface offers a choice of Perl object dump or formatted RDF.) - tag URIs and geo URIs There are still a few things that I want to take care of before I release alpha3 publicly. One thing that I'm quite looking forward to getting working is to more fully unite metadata from different sources, so say for example there is an hcard like this:
Toby Inkster
And somewhere else on the page I have some RDFa: Joe Bloggs Then it will know that my hCard was created by Joe Bloggs. Not quite there yet, but nearly. -- 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 24 days, 20:42.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From danielbaird at gmail.com Sat Feb 23 15:43:16 2008 From: danielbaird at gmail.com (Daniel Baird) Date: Sat Feb 23 15:43:18 2008 Subject: [uf-discuss] To-do items? Message-ID: Hi list, Is there an existing microformat, or proposal, for representing items on a to do list? I haven't found anything so far but it's hard to know if I'm missing the One True Search Phrase :) There's a mostly-stalled effort to allow swapping GTD data between GTD tools, and I'm wondering if it'd be easiest to use a uf rather than a fullon XML export file. Cheers ;Daniel -- Daniel Baird i neeber olok at ym kyebord wen i tpey From mark at markng.me.uk Sat Feb 23 16:30:13 2008 From: mark at markng.me.uk (Mark Ng) Date: Sat Feb 23 16:30:16 2008 Subject: [uf-discuss] To-do items? In-Reply-To: References: Message-ID: Hi Daniel, On 23/02/2008, Daniel Baird wrote: > Hi list, > > Is there an existing microformat, or proposal, for representing items > on a to do list? I haven't found anything so far but it's hard to > know if I'm missing the One True Search Phrase :) So far as I understand it (though I'm very far from an authority on this subject, and haven't actually seen an implementation of this) - hCalendar is a one-to-one mapping of iCalendar (RFC 2445). iCalendar allows for VTODO entries. http://microformats.org/wiki/hcalendar-examples#4.6.2_To-do_Component in the wiki does actually mention this usage, but has (ironically) a TODO where the implementation is. > > There's a mostly-stalled effort to allow swapping GTD data between GTD > tools, and I'm wondering if it'd be easiest to use a uf rather than a > fullon XML export file. From mail at tobyinkster.co.uk Sun Feb 24 09:46:36 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Feb 24 10:01:23 2008 Subject: [uf-discuss] Re: To-do items? References: Message-ID: Mark Ng wrote: > So far as I understand it (though I'm very far from an authority on this > subject, and haven't actually seen an implementation of this) - > hCalendar is a one-to-one mapping of iCalendar (RFC 2445). iCalendar > allows for VTODO entries. > http://microformats.org/wiki/hcalendar-examples#4.6.2_To-do_Component in > the wiki does actually mention this usage, but has (ironically) a TODO > where the implementation is. The hcalendar spec itself seems to suggest that "vcalendar" and "vevent" are the only possible root class names and doesn't make any reference to VTODO, VFREEBUSY, etc. They are not included on the cheatsheet either. However in the introduction it does claim to be a 1:1 representation of iCalendar in HTML. I suppose that this apparent contradiction can be resolved if we assume that VTODO and other iCalendar components may be used, but must not be employed as root class names. (a "vevent" class can be used outside a "vcalendar" class, and this implies that the page itself is a VCALENDAR.) That having said, the hcalendar-issues page suggests that VALARM, VJOURNAL and VTIMEZONE should not be used. Some of these issues were raised over two years ago, but there has been no progress on them on the spec itself. But that is just an example of the guesswork and interpretation needed to implement the hCalendar spec. The spec is incredibly vague and even notes its own incompleteness on some topics. It contains some blatant contradictions with the iCalendar spec which it normatively references -- such as stating that dtstart and summary are required children of a vcalendar, when according to the source specification they are required children of a *vevent* and are not allowed directly inside a vcalendar. In its current state it should not have progressed beyond a draft status. -- 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 25 days, 23:20.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From ryan at theryanking.com Sun Feb 24 13:13:00 2008 From: ryan at theryanking.com (Ryan King) Date: Sun Feb 24 14:14:57 2008 Subject: [uf-discuss] Re: To-do items? In-Reply-To: References: Message-ID: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> On Feb 24, 2008, at 9:46 AM, Toby A Inkster wrote: > Mark Ng wrote: > >> So far as I understand it (though I'm very far from an authority on >> this >> subject, and haven't actually seen an implementation of this) - >> hCalendar is a one-to-one mapping of iCalendar (RFC 2445). iCalendar >> allows for VTODO entries. >> http://microformats.org/wiki/hcalendar-examples#4.6.2_To- >> do_Component in >> the wiki does actually mention this usage, but has (ironically) a >> TODO >> where the implementation is. > > The hcalendar spec itself seems to suggest that "vcalendar" and > "vevent" > are the only possible root class names and doesn't make any > reference to > VTODO, VFREEBUSY, etc. They are not included on the cheatsheet either. > However in the introduction it does claim to be a 1:1 representation > of > iCalendar in HTML. I suppose that this apparent contradiction can be > resolved if we assume that VTODO and other iCalendar components may be > used, but must not be employed as root class names. (a "vevent" > class can > be used outside a "vcalendar" class, and this implies that the page > itself > is a VCALENDAR.) It can be resolved by saying that no one has gotten around to specifying how the other iCalendar objects would work in hCalendar. -ryan From bbtommorris at gmail.com Sun Feb 24 17:40:00 2008 From: bbtommorris at gmail.com (Tom Morris) Date: Sun Feb 24 17:40:05 2008 Subject: [uf-discuss] Re: To-do items? In-Reply-To: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> References: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> Message-ID: On Sun, Feb 24, 2008 at 9:13 PM, Ryan King wrote: > It can be resolved by saying that no one has gotten around to > specifying how the other iCalendar objects would work in hCalendar. > It would seem sensible to perhaps implement any to-do list format using that ever-useful (X)HTML structure, the list. It would be quite simple to do - have the tasks as the outer-most children in the list, with the parent nodes representing higher and higher level 'projects' (in GTD speak) or just collections of tasks. Obviously, ol and ul could signify whether the tasks are ordered (and should therefore be done sequentially) or unordered (any order is fine). For due dates, one could use a the abbr-datetime pattern. Also, tags and maybe hCard could be reused to represent GTD-style contexts and collaborators, contacts or 'waiting for'. Do to-do lists really require anything extravagantly more complex than a list structure? I'm not sure they do. There are some possible use cases for a to-do list format. Off the top of my head, it could be implemented in things like bug trackers (Bugzilla, Trac etc.) so that software developers could have their tools (text editors and IDEs like TextMate, NetBeans and emacs) pull in action items, a sort of RSS-style task aggregation and distribution and so on as well as complementing hCalendar in Outlook and iCal-style PIMs. I think that the success of tools like TaskPaper on the Mac point to the need for simple solutions. If this gets picked up, it'll be interesting to see what the Microformats community come up with - I've been doing a little bit of GTD noodling with the command line and the RDF stack. -- Tom Morris http://tommorris.org/ From brian.suda at gmail.com Mon Feb 25 03:53:04 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 25 03:53:07 2008 Subject: [uf-discuss] Re: To-do items? In-Reply-To: References: Message-ID: <21e770780802250353k768a0588g97c5736363ce9ea5@mail.gmail.com> 2008/2/24, Toby A Inkster : > But that is just an example of the guesswork and interpretation needed to > implement the hCalendar spec. The spec is incredibly vague and even notes > its own incompleteness on some topics. --- Lets not through the baby out with the Bath water. The hCalendar spec is modeled off of the iCalendar spec and rather than spend years matching every last useless item, it is better to get things out there and iterate on them. If there is a big enough push and need for the other 4-5 items to be mapped from iCalendar to hCalendar, then we can examine those as they appear. The wiki could use some clean-up and better wording about exactly what 1:1 means. There is an ICAL-BASIC which is in progress which cuts out most of the un-used and un-supported "features" at one point hCalendar was to be modeled off of that, but ICAL-BASIC is not finished. There has been work on a Task Microformats which is also modeled after the VTODO http://microformats.org/wiki/task-formats The best course of action is to take examples from the wild and use VTODO as a boiler plate, cut out the cruft, then it can be folded back in. No need to drag a working format down to get edge-cases worked it from the start. > It contains some blatant > contradictions with the iCalendar spec which it normatively references -- > such as stating that dtstart and summary are required children of a > vcalendar, when according to the source specification they are required > children of a *vevent* and are not allowed directly inside a vcalendar. --- can you be more specific, i can't find the reference "dtstart and summary are required children of a vcalendar". Some of these quirks are also issues with consuming applications such as Outlook requiring DTSTAMP which is actually optional. -brian -- brian suda http://suda.co.uk From mail at tobyinkster.co.uk Mon Feb 25 09:03:36 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Feb 25 11:10:23 2008 Subject: [uf-discuss] Re: To-do items? References: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> Message-ID: <809b95-u5u.ln1@ophelia.g5n.co.uk> Ryan King wrote: > It can be resolved by saying that no one has gotten around to specifying > how the other iCalendar objects would work in hCalendar. So as not to be perceived as one of those people who complains about things rather than doing something to correct them, I've started mapping out VTODO, VALARM, VFREEBUSY and the remaining parts of VEVENT on a sub- page of my user page, here: http://microformats.org/wiki/User:TobyInk/hcalendar-1.1 The aim being not to change the existing hCalendar, but to document the parts which the current spec glosses over. So far I've added class names for all the properties in iCalendar except for those properties used only by the VTIMEZONE and VJOURNAL components. (The hcalendar-brainstorming page has comments from Tantek (IIRC) advising against using those two components. VTIMEZONE, he says, is horrible -- I agree wholeheartedly. hAtom should be used over VJOURNAL -- I'm ambivalent about this as hAtom is still a draft whereas hCalendar is at least nominally a specification, but as it saves work, I'm leaving it out for now too.) There are various other non-property bits and bobs from iCalendar that need documenting too -- I'll work on them over the next day or two. If the authors of hcalendar want to copy across parts or the whole of my work across to the main spec, then they are free to do so, though I'd appreciate being added to the credits. If not, I'll keep working on my draft regardless, in the hope that it will form a useful *informative* rather than *normative* document for people implementing authoring tools and parsers. -- 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 26 days, 23:02.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From mail at tobyinkster.co.uk Mon Feb 25 09:35:11 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Feb 25 11:10:24 2008 Subject: [uf-discuss] rel -vs- rev Message-ID: The following is part of the rel FAQ | However, given that the 'rev' attribute has been more often misused by | authors than properly used (Google Code: Web Authoring Statistics: Link | Relationships ) | is it even a good idea to use rev at all? | | The short answer is unfortunately "no". Use of "rev" SHOULD be avoided. | | However, VoteLinks' use of rev has been grandfathered since it was such | an early use. No future microformats should be developed that use 'rev', | and any use of 'rev' (apart from the "grand-fathered" case of VoteLinks) | is deprecated in microformats. This seems to me to have been an entirely arbitrary decision. Apart from the cited Google study, was there any other justification given for this? Looking at the cited Google study it shows that, of the top twenty relationships used on the web, only one of them uses "rev" at all, and appears to do so correctly! The quoted rel="made" at position #21 in the survey is *assumed* to be an incorrect usage, though one can easily imagine plausible uses for such a construct. (e.g. a web designer's portfolio, linking to various sites that he's made.) So this study does not seem to show a significant degree of incorrect usage of rev. Besides which, there are millions of pages out there that incorrectly use the alt="" attribute to produce tooltips, whether or not the contents are suitable as alternative text. Just because there are so many examples of abuse of the attribute, it doesn't make sense to avoid using it for its correct purpose. In fact, quite the opposite -- when an attribute is frequently misused, we ought to be using it correctly whenever possible, and encouraging others to do so as well. rev, though not used particularly frequently is a very useful attribute. As an example, there is currently a debate on the xfn-brainstorming wiki page about what value of rel to use to link to "someone of whom you are a fan". Suggestions include: * rel="source" * rel="leader" * rel="influencer" * rel="idol" * rel="subscription" Surely, a simple rev="fan" is far more elegant solution? I think that rev offers great utility to microformats, and shouldn't be dismissed out of hand -- and certainly not based on the current evidence on the wiki! Ask not what you can do for your rev, as what your rev can do for you! -- 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 26 days, 23:23.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From ryan at theryanking.com Mon Feb 25 12:43:02 2008 From: ryan at theryanking.com (Ryan King) Date: Mon Feb 25 13:08:19 2008 Subject: [uf-discuss] rel -vs- rev In-Reply-To: References: Message-ID: On Feb 25, 2008, at 9:35 AM, Toby A Inkster wrote: > The following is part of the rel FAQ > > > | However, given that the 'rev' attribute has been more often > misused by > | authors than properly used (Google Code: Web Authoring Statistics: > Link > | Relationships linkrels.html>) > | is it even a good idea to use rev at all? > | > | The short answer is unfortunately "no". Use of "rev" SHOULD be > avoided. > | > | However, VoteLinks' use of rev has been grandfathered since it was > such > | an early use. No future microformats should be developed that use > 'rev', > | and any use of 'rev' (apart from the "grand-fathered" case of > VoteLinks) > | is deprecated in microformats. > > This seems to me to have been an entirely arbitrary decision. Apart > from > the cited Google study, was there any other justification given for > this? I don't think 'arbitrary' is a good characterization of the decision. Besides the Google study, there are no other formal studies that I know of, but plenty of anecdotal experience that demonstrates that rel- vs-rev is confusing for authors. In addition to this evidence, the current draft of HTML5 does not include rev (by design), so in the interest of building microformats on top of existing standards (HTML4) in a future-compatible way (HTML5) we should avoid using @rev. Additionally, experience with VoteLinks indicated that authors didn't understand or even know about @rev. > Looking at the cited Google study it shows that, of the top twenty > relationships used on the web, only one of them uses "rev" at all, and > appears to do so correctly! The quoted rel="made" at position #21 in > the > survey is *assumed* to be an incorrect usage, though one can easily > imagine plausible uses for such a construct. (e.g. a web designer's > portfolio, linking to various sites that he's made.) So this study > does > not seem to show a significant degree of incorrect usage of rev. > > Besides which, there are millions of pages out there that > incorrectly use > the alt="" attribute to produce tooltips, whether or not the > contents are > suitable as alternative text. Just because there are so many > examples of > abuse of the attribute, it doesn't make sense to avoid using it for > its > correct purpose. In fact, quite the opposite -- when an attribute is > frequently misused, we ought to be using it correctly whenever > possible, > and encouraging others to do so as well. Usage of @alt is irrelevant here. @alt isn't used for structured data, @rev is. > rev, though not used particularly frequently is a very useful > attribute. > As an example, there is currently a debate on the xfn-brainstorming > wiki > page about what value of rel to use to link to "someone of whom you > are a > fan". Suggestions include: > > * rel="source" > * rel="leader" > * rel="influencer" > * rel="idol" > * rel="subscription" > > Surely, a simple rev="fan" is far more elegant solution? Unfortunately the World Wide Web is a messy place, and elegance isn't always an option. > I think that rev offers great utility to microformats, and shouldn't > be > dismissed out of hand -- and certainly not based on the current > evidence > on the wiki! Ask not what you can do for your rev, as what your rev > can do > for you! Your characterization of the decision as "out of hand" doesn't account for the several years of discussion that went into it. -ryan From Scott at randomchaos.com Mon Feb 25 13:08:03 2008 From: Scott at randomchaos.com (Scott Reynen) Date: Mon Feb 25 13:30:36 2008 Subject: [uf-discuss] Re: To-do items? In-Reply-To: <809b95-u5u.ln1@ophelia.g5n.co.uk> References: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> <809b95-u5u.ln1@ophelia.g5n.co.uk> Message-ID: <9CE07017-B5F6-4093-9B6C-E139A5E6EB89@randomchaos.com> On Feb 25, 2008, at 10:03 AM, Toby A Inkster wrote: > So as not to be perceived as one of those people who complains about > things rather than doing something to correct them, I've started > mapping > out VTODO, VALARM, VFREEBUSY and the remaining parts of VEVENT on a > sub- > page of my user page I appreciate you being proactive here, but can you please move your proposal to hcalendar-brainstorming [1]? The description of that page says "This page is for trying out and documenting ways of using hCalendar which may involve more details than currently in the specification," which sounds like exactly what you're doing. We're intentionally trying to minimize use of User: pages to emphasize community rather than personal projects. To that end, the how-to-play guidelines [2] say 'Do not create new "User:" links by hand.' I hate to create more work for you, and I doubt this was your intention, but I really think User: pages are uninviting to the wider participation we need to be encouraging. [1] http://microformats.org/wiki/hcalendar-brainstorming [2] http://microformats.org/wiki/how-to-play#Guidelines Peace, Scott From andy at pigsonthewing.org.uk Mon Feb 25 13:49:49 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 25 13:51:39 2008 Subject: [uf-discuss] rel -vs- rev In-Reply-To: References: Message-ID: In message , Ryan King writes >I don't think 'arbitrary' is a good characterization of the decision. [...] >Your characterization of the decision as "out of hand" doesn't account >for the several years of discussion that went into it. But if that discussion isn't adequately documented, or the decision isn't adequately explained, it's a reasonable, indeed likely, conclusion for a relative newcomer to arrive at, surely? -- Andy Mabbett From andy at pigsonthewing.org.uk Mon Feb 25 13:54:44 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 25 13:56:08 2008 Subject: [uf-discuss] Re: To-do items? In-Reply-To: <9CE07017-B5F6-4093-9B6C-E139A5E6EB89@randomchaos.com> References: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> <809b95-u5u.ln1@ophelia.g5n.co.uk> <9CE07017-B5F6-4093-9B6C-E139A5E6EB89@randomchaos.com> Message-ID: In message <9CE07017-B5F6-4093-9B6C-E139A5E6EB89@randomchaos.com>, Scott Reynen writes > We're intentionally trying to minimize use of User: pages to >emphasize community rather than personal projects. We are? That's the first time I've seen that suggested, in over two years here. Reducing the number of unsigned opinions and first-person comments in the documentation would probably be much more productive, in that regard. >To that end, the how-to-play guidelines say 'Do not create new "User:" >links by hand.' That refers to a different, and very specific behaviour. -- Andy Mabbett From scott at randomchaos.com Mon Feb 25 15:11:50 2008 From: scott at randomchaos.com (Scott Reynen) Date: Mon Feb 25 15:11:54 2008 Subject: [uf-discuss] Re: To-do items? In-Reply-To: References: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> <809b95-u5u.ln1@ophelia.g5n.co.uk> <9CE07017-B5F6-4093-9B6C-E139A5E6EB89@randomchaos.com> Message-ID: <80AEA1B9-29B8-419A-8DA7-F0215BEBFCCD@randomchaos.com> On Feb 25, 2008, at 2:54 PM, Andy Mabbett wrote: >> We're intentionally trying to minimize use of User: pages to >> emphasize community rather than personal projects. > > We are? That's the first time I've seen that suggested, in over two > years here. Yeah, I probably didn't state that very well. Nonetheless, I still think it's best to put brainstorming on the relevant brainstorming page. I trust Toby can evaluate that suggestion in the interest of helping this community collaborate, the spirit in which it was offered. Peace, Scott From mail at tobyinkster.co.uk Tue Feb 26 02:24:06 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Feb 26 03:01:25 2008 Subject: [uf-discuss] Re: To-do items? References: <8225FB5B-F5DB-4B5E-A93A-ECCD5812BA83@theryanking.com> <809b95-u5u.ln1@ophelia.g5n.co.uk> <9CE07017-B5F6-4093-9B6C-E139A5E6EB89@randomchaos.com> <80AEA1B9-29B8-419A-8DA7-F0215BEBFCCD@randomchaos.com> Message-ID: <6v5d95-u5u.ln1@ophelia.g5n.co.uk> Scott Reynen wrote: > I trust Toby can evaluate that suggestion in the interest of helping > this community collaborate, the spirit in which it was offered. Indeed, I do, and I'd like my work to ultimately go onto brainstorming, but I want to use my own space (as much as space on a wiki can ever truly be my "own") first to crystallise my thoughts before letting other people play with them. There's also the issue that the *-brainstorming pages tend to be fairly unstructured, and I'm trying to keep my ramblings organised in a more spec- structured way. -- 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 27 days, 16:37.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From mail at tobyinkster.co.uk Tue Feb 26 02:18:07 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Feb 26 03:05:07 2008 Subject: [uf-discuss] Re: rel -vs- rev References: Message-ID: Ryan King wrote: > In addition to this evidence, the current draft of HTML5 does not > include rev (by design), so in the interest of building microformats on > top of existing standards (HTML4) in a future-compatible way (HTML5) we > should avoid using @rev. Nor does HTML 5 include , yet the current recommended way of linking to XMDP profiles is through that attribute; ditto the "compact" attribute on any type of list, which is used by XOXO; and I've already mentioned the collision between the HTML 5 and XFN definitions of rel="contact". > Your characterization of the decision as "out of hand" doesn't account > for the several years of discussion that went into it. If there are other justifications then fair enough, but these are not documented on the wiki, nor easily findable by Googling through the microformats-discuss archives. -- 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 27 days, 15:43.] Bottled Water http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/ From go at omnia-computing.de Wed Feb 27 03:37:58 2008 From: go at omnia-computing.de (Gordon Oheim) Date: Wed Feb 27 03:41:03 2008 Subject: [uf-discuss] RFC on hCardMapper script Message-ID: <000101c87935$7a224816$5a518853@omniacomputing.de> Hello Group, I have assembled a small script that maps hCards onto form fields. The reason for this was a client job, where I wanted to simplify filling out a contact form. The script uses PrototypeJS and Scriptaculous for the dialogues and the mofo parser on the serverside to fetch remote hCards. I have assembled a demo page at lib.omnia-computing.de/hcardmapper. The script is released under the MIT license, in case anyone wants to use or refine it. Cheers, Gordon From mail at ciaranmcnulty.com Wed Feb 27 06:40:43 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Wed Feb 27 07:41:36 2008 Subject: [uf-discuss] RFC on hCardMapper script In-Reply-To: <000101c87935$7a224816$5a518853@omniacomputing.de> References: <000101c87935$7a224816$5a518853@omniacomputing.de> Message-ID: On Wed, Feb 27, 2008 at 11:37 AM, Gordon Oheim wrote: > I have assembled a small script that maps hCards onto form fields. The reason for this was a client job, where I wanted to simplify filling out a contact form. The script uses PrototypeJS and Scriptaculous for the dialogues and the mofo parser on the serverside to fetch remote hCards. Very impressive, Gordon! One small comment: It doesn't appear to pick up my 'website' in the case where there are multiple URL in one hCard. I believe your best strategy would be to pick the first HTTP url. -Ciaran McNulty From go at omnia-computing.de Wed Feb 27 14:12:31 2008 From: go at omnia-computing.de (Gordon Oheim) Date: Wed Feb 27 15:31:38 2008 Subject: AW: Re: [uf-discuss] RFC on hCardMapper script Message-ID: <000201c8798e$1f747c46$5a518853@omniacomputing.de> Thank you, Ciaran. I have updated the script so it picks up the first occurence of a property in any case of multiple occurences. Thanks for the hint. Cheers, GordonOn Wed, Feb 27, 2008 at 11:37 AM, Gordon Oheim wrote: > I have assembled a small script that maps hCards onto form fields. The reason for this was a client job, where I wanted to simplify filling out a contact form. The script uses PrototypeJS and Scriptaculous for the dialogues and the mofo parser on the serverside to fetch remote hCards. Very impressive, Gordon! One small comment: It doesn't appear to pick up my 'website' in the case where there are multiple URL in one hCard. I believe your best strategy would be to pick the first HTTP url. -Ciaran McNulty _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From andy at pigsonthewing.org.uk Wed Feb 27 13:32:21 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 27 16:04:00 2008 Subject: [uf-discuss] RFC on hCardMapper script In-Reply-To: <000101c87935$7a224816$5a518853@omniacomputing.de> References: <000101c87935$7a224816$5a518853@omniacomputing.de> Message-ID: In message <000101c87935$7a224816$5a518853@omniacomputing.de>, Gordon Oheim writes >I have assembled a small script that maps hCards onto form fields. The >reason for this was a client job, where I wanted to simplify filling >out a contact form. The script uses PrototypeJS and Scriptaculous for >the dialogues and the mofo parser on the serverside to fetch remote >hCards. > >I have assembled a demo page at lib.omnia-computing.de/hcardmapper. If you use the "http://" prefix, you'll make a clickable link in many mail clients: That 's a pretty neat service (the first of its kind, I think), but publishers should be wary of sing something that relies on Javascript for important functions; server side scripting is better - though I suppose users without Javascript do have the option of manual data entry. Also, a bug (or at least a sub-optimal behaviour): when a fragment URL is entered, such as: then all the hCards on the page are returned in the selection box, even though there is only one at that address. Please add your service to eth iki, not elast at: <> -- Andy Mabbett From andy at pigsonthewing.org.uk Thu Feb 28 01:22:47 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 28 01:34:10 2008 Subject: [uf-discuss] RFC on hCardMapper script In-Reply-To: References: <000101c87935$7a224816$5a518853@omniacomputing.de> Message-ID: In message , Andy Mabbett writes >Please add your service to eth iki, not elast at: > > <> Sorry; please ignore that fragment, which I meant to remove. I already added it at: -- Andy Mabbett From info at weborganics.co.uk Thu Feb 28 05:51:41 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 28 05:51:53 2008 Subject: [uf-discuss] Foaf Mo Music recommendations extracted from Microformats. Message-ID: <1204206701.946.7.camel@weborganicscouk> Hello All I have managed to hack together a way of embedding foaf music recommendations in html using the Microformats hAudio [1] and hCard [2] with a little basic XSL run through the W3C Online XSLT 2.0 Service [3] the concept of which seems like an amazingly useful thing to do. The hAudio markup represents the concept of a mo:Track and hCard markup with a single ID represents the concept of a foaf:person There are two other important propeties that are needed for the transformation a link with rel="index" which is the base url and links with rel="bookmark" which are links to the actual music recommendations I am not so good at explaining things so, the demos: Source Document: http://darkstarserver.co.uk/ Extracted FOAF: http://xml.mfd-consult.dk/foaf/explorer/?foaf=http%3A%2F%2Fdarkstarserver.co.uk%2FFOAF%2F%3Fid%3Dhttp%3A%2F%2Fdarkstarserver.co.uk%2Fnode%2F9 GRDDL output: http://sparql.captsolo.net/browser/browser.py?url=http%3A%2F%2Fwww.w3.org%2F2007%2F08%2Fgrddl%2F%3FdocAddr%3Dhttp%3A%2F%2Fdarkstarserver.co.uk%2F%26output%3Drdfxml As this is basically an extension of hAudioRSS the XSL is available to download from: http://esw.w3.org/topic/hAudioRSS Comments, ideas on how I may be able to improve the semantics, or any input, criticism is more than welcome Reposted here: http://groups.google.com/group/music-ontology-specification-group/browse_thread/thread/8dd6d5a70e9a9f55 Thanks For your time Martin McEvoy [1] http://microformats.org/wiki/haudio [2] http://microformats.org/wiki/hcard [3] http://www.w3.org/2005/08/online_xslt/ From gordon at onlinehome.de Thu Feb 28 11:09:33 2008 From: gordon at onlinehome.de (Gordon) Date: Thu Feb 28 11:09:38 2008 Subject: [uf-discuss] RFC on hCardMapper script In-Reply-To: References: <000101c87935$7a224816$5a518853@omniacomputing.de> Message-ID: <47C706ED.1050104@onlinehome.de> Andy Mabbett schrieb: > In message , Andy Mabbett > writes > > >> Please add your service to eth iki, not elast at: >> >> <> >> > > Sorry; please ignore that fragment, which I meant to remove. I already > added it at: > > > > Thanks for your reply, Andy. You are right about the fragment. The mofo parser I use on the serverside ignores fragments, so this is nothing to fix in the hCardMapper script. But I agree this could be improved. I've noticed similar behavior at the technorati script to make hCards into vCards and it bugged me there too. Thanks for adding the hCardMapper to the wiki. Much appreciated. Cheers, Gordon From ciprian.amariei at gmail.com Thu Feb 28 19:49:31 2008 From: ciprian.amariei at gmail.com (Ciprian Amariei) Date: Thu Feb 28 19:49:35 2008 Subject: [uf-discuss] RFC on hCardMapper script In-Reply-To: <000101c87935$7a224816$5a518853@omniacomputing.de> References: <000101c87935$7a224816$5a518853@omniacomputing.de> Message-ID: <5d44a0c10802281949tf3a3076p8115446d627d9bbd@mail.gmail.com> Nice work, Gordon! It does not seem to get values from structures like this (from http://www.atest.ro/contact ): Cheers, Ciprian Amariei On Wed, Feb 27, 2008 at 1:37 PM, Gordon Oheim wrote: > Hello Group, > > I have assembled a small script that maps hCards onto form fields. The reason for this was a client job, where I wanted to simplify filling out a contact form. The script uses PrototypeJS and Scriptaculous for the dialogues and the mofo parser on the serverside to fetch remote hCards. > > I have assembled a demo page at lib.omnia-computing.de/hcardmapper. The script is released under the MIT license, in case anyone wants to use or refine it. > > Cheers, Gordon > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From gordon at onlinehome.de Fri Feb 29 02:30:15 2008 From: gordon at onlinehome.de (Gordon) Date: Fri Feb 29 02:42:49 2008 Subject: [uf-discuss] RFC on hCardMapper script In-Reply-To: <5d44a0c10802281949tf3a3076p8115446d627d9bbd@mail.gmail.com> References: <000101c87935$7a224816$5a518853@omniacomputing.de> <5d44a0c10802281949tf3a3076p8115446d627d9bbd@mail.gmail.com> Message-ID: <47C7DEB7.2060503@onlinehome.de> Ciprian Amariei schrieb: > Nice work, Gordon! > > It does not seem to get values from structures like this (from > http://www.atest.ro/contact ): > > > Cheers, > Ciprian Amariei > Thank you, Ciprian. I did not take into account someone would provide a property value without a type. This is fixed now. Thanks for pointing this out. If you try your url again, the eMail should show up in the proper input field. Cheers, Gordon From thom at ts0.com Fri Feb 29 04:36:07 2008 From: thom at ts0.com (Thom Shannon) Date: Fri Feb 29 10:16:15 2008 Subject: [uf-discuss] using title on anchor, eg event location Message-ID: <47C7FC37.6080601@ts0.com> Hi, Should parsers use the title of an anchor for the value of a location property on hCard, or does that title pattern only apply to explicit abbreviations? (using abbr). Thinking about it now the latter does make sense, it's probably wrong to infer that the title is more important than the tags contents. eg. http://www.ts0.com/2008/02/liverpool-net-user-group.asp