) could contain some content that was marked up with one microformat, and another blocklevel element could contain content marked up with another entirely different microformat. The fact that they shared the same page isn't a problem. A parser could easily identify child relationships within the HTML and extrapolate. Granted this wouldn't be so easy if two microformats were muddled together on the same page. And if they were then maybe there are two questions to ask. 1/ Is the microformat in need of some additional elements?, and 2/ Is the author of the page trying to do too much. could it be laid out differently? Simple is better afterall. Tim On 09/12/06, Mike Schinkel wrote: > Ryan King wrote: > > > How can I disambiguate when two Microformats collide? > > > Let me give a concrete example (one I will be working > > > on in the future): > > > > First profile wins. This had previously been clarified in > > HTML5, until Hixie decided to remove the profile attribute > > from HTML5. > > Please tell me if I misunderstand, but I think that clearly identifies the > problem I've been trying to address: naming clashes on a scare resource. If > what I think you said is correct, that would require someone to use one or > the other, but not both. That approach to web architecture is clearly not > acceptable, don't you agree? > > -Mike Schinkel > http://www.mikeschinkel.com/blogs/ > http://www.welldesignedurls.org/ > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Tim Hodson informationtakesover.co.uk www.timhodson.co.uk From andy at pigsonthewing.org.uk Sat Dec 9 03:47:47 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 03:48:58 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> Message-ID: In message <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com>, Tim Hodson writes >A parser could easily identify child relationships within >the HTML and extrapolate. > >Granted this wouldn't be so easy if two microformats were muddled >together on the same page. AIUI the concerns are about using the same class-name for two different attributes. Say, the title of a book in a citation, vs. a job title in an hCard. Since a citation may include the author's hCard, it is thought that there might be a conflict:

Running an ISP for Idiots

Internet Expert [1]

There is a danger that "Internet Expert" might be recorded as the title of the book (especially if the other title attribute is not present) Several possible solutions are available to us: 1 Declare that, if the attribute is inside a microformat (in this case hCard), then it always applies to that uF, but not the parent uF (in this case the citation) 2 Uniquely name the first attribute as, say, class="book-title" (compare to some of the proposed class names in the 'species' proposal, which use this method to avoid other clashes). 3 Use an additional wrapper around the hCard on an additional class on the hCard), to indicate that anything within that wrapper does not apply to the parent. My preference is for option 2 - with hindsight, I would have named all the classes in hCard as, say, "vcard-title". [1] I actually knew of someone who has this as their job title ;-) -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sat Dec 9 03:25:38 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 04:01:05 2006 Subject: [uf-discuss] Adapting existing links as tags In-Reply-To: <+FP1o$m9vzZFFwxl@pigsonthewing.org.uk> References: <+FP1o$m9vzZFFwxl@pigsonthewing.org.uk> Message-ID: In message <+FP1o$m9vzZFFwxl@pigsonthewing.org.uk>, Andy Mabbett writes > >I currently have several instances of pages in a sub-directory, such >as: > > http://www.westmidlandbirdclub.com/staffs/tittesworth/index.htm > http://www.westmidlandbirdclub.com/staffs/tittesworth/latest.ht >m > http://www.westmidlandbirdclub.com/staffs/tittesworth/latest- >2006.htm > http://www.westmidlandbirdclub.com/staffs/tittesworth/latest- >2005.htm > etc. > >Where the root URL of that sub-directory may be suitable as a tag. > > >All of the pages apart from the index file link to the latter, thus: > > Tittesworth > >usually more than once from each page, occasionally with other linking >text ("Tittesworth Reservoir"). > > >I could, presumably, change the links to: > > Tittesworth > >Are there any disadvantages to doing so (in terms of search engine >ranking, for example)? Should I do so on each such link, or just once >per page? Can anyone advise, please? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From hodson.tim at googlemail.com Sat Dec 9 04:27:57 2006 From: hodson.tim at googlemail.com (Tim Hodson) Date: Sat Dec 9 04:28:33 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> Message-ID: <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> On 09/12/06, Andy Mabbett wrote: >

> > Running an ISP for Idiots > >

> > Internet Expert [1] > >

> > There is a danger that "Internet Expert" might be recorded as the title > of the book (especially if the other title attribute is not present) > > Several possible solutions are available to us: > > 1 Declare that, if the attribute is inside a microformat (in this > case hCard), then it always applies to that uF, but not the > parent uF (in this case the citation) Surely 1 is the most logical? The fact that the hcard title is NOT in the parent citation block would surely mean that I could make the sensible assumption that the title attribute for the hcard is NOT the same as the title attribute of the citation. It would be up to me as author to clearly express what I meant by using correctly nesting tags. > > 2 Uniquely name the first attribute as, say, class="book-title" > (compare to some of the proposed class names in the 'species' > proposal, which use this method to avoid other clashes). The citation may not be a book :) > > 3 Use an additional wrapper around the hCard on an additional > class on the hCard), to indicate that anything within that > wrapper does not apply to the parent. As for 3, this is already done in the example given. The wrappers are named hcard and citation, which brings us back to option 1. > > My preference is for option 2 - with hindsight, I would have named all > the classes in hCard as, say, "vcard-title". > > Naming all the classes with a prefix is unnecessary if you take the view that a microformat is a small set of attributes for distinct pieces of information. As far as I know (and I haven't read every microformat spec) there is almost always a root attribute which defines what we are talking about - vcard, vevent, xoxo, the exceptions are the rel/rev attributes which are defined using profiles and can only sensibly have one meaning in a page. best... -- Tim Hodson informationtakesover.co.uk www.timhodson.co.uk selfdescription.org From andy at pigsonthewing.org.uk Sat Dec 9 04:29:34 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 04:31:02 2006 Subject: [uf-discuss] [admin] mailing list policies reminder In-Reply-To: <228C4B9E-A3FB-424E-85E6-7F737C60A269@technorati.com> References: <3DXXpJwALgOFFw4Q@pigsonthewing.org.uk> <16E9D226-1A8B-4857-930A-E7413926135E@technorati.com> <228C4B9E-A3FB-424E-85E6-7F737C60A269@technorati.com> Message-ID: In message <228C4B9E-A3FB-424E-85E6-7F737C60A269@technorati.com>, Ryan King writes >On Dec 8, 2006, at 3:06 PM, Andy Mabbett wrote: >> In message <16E9D226-1A8B-4857-930A-E7413926135E@technorati.com>, Ryan >> King writes You've ignored the key part of my post, and responded only to a secondary matter. >> >>>> and why were these ignored: >>> >>> Mostly because Tantek and I haven't had a chance to talk about it >>>and >>> decide what we want to do. Like I said, updating the policies is a >>> work in progress. We're open to input, but can't react immediately >> >> You wrote that over a month ago. Any progress? > >No. I *know* it's been more than a month. I'm ok with that. Sending >email like this is not going make it get done any sooner. I was under no illusion that my *question* would make anything happen; it was merely that - a question. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sat Dec 9 04:50:10 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 04:51:37 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> Message-ID: In message <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com>, Tim Hodson writes >> Several possible solutions are available to us: >> >> 1 Declare that, if the attribute is inside a microformat (in this >> case hCard), then it always applies to that uF, but not the >> parent uF (in this case the citation) > >Surely 1 is the most logical? Not necessarily >The fact that the hcard title is NOT in >the parent citation block would surely mean that I could make the >sensible assumption that the title attribute for the hcard is NOT the >same as the title attribute of the citation. It would be up to me as >author to clearly express what I meant by using correctly nesting >tags. There may be occasions when applying a class to a property in nested uF, for use by both inner and outer uFs is sensible. >> >> 2 Uniquely name the first attribute as, say, class="book-title" >> (compare to some of the proposed class names in the 'species' >> proposal, which use this method to avoid other clashes). > >The citation may not be a book :) Hence "say". >> 3 Use an additional wrapper around the hCard on an additional >> class on the hCard), to indicate that anything within that >> wrapper does not apply to the parent. > >As for 3, this is already done in the example given. The wrappers are >named hcard and citation Not so, because they don't currently carry that connotation. >> >> My preference is for option 2 - with hindsight, I would have named all >> the classes in hCard as, say, "vcard-title". >> >> >Naming all the classes with a prefix is unnecessary if you take the >view that a microformat is a small set of attributes for distinct >pieces of information. Your latter consideration does not imply nor justify the former conclusion. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From davidjanes at blogmatrix.com Sat Dec 9 05:20:36 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 05:20:39 2006 Subject: [uf-discuss] Unambiguous class names Message-ID: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> I was just looking at a discussion about "citation" and came across this example.

Running an ISP for Idiots

Internet Expert

Questions: 1. Is citation really considering using "title" for the title of a book? 2. Are not class names supposed to have a single meaning across _all_ microformats? I remember this from hAtom discussions, but ... 3. Is this documented somewhere or is it something that everyone is supposed to know (or am I just wrong)? 4. If my assumption is correct, should I note it in a few pages; in particular, process [1], existing-classes [2] and class-design-pattern [3]? Regards, etc... [1] http://microformats.org/wiki/process [2] http://microformats.org/wiki/class-names [3] http://microformats.org/wiki/class-design-pattern -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From davidjanes at blogmatrix.com Sat Dec 9 05:40:37 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 05:40:40 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> Message-ID: <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> The preceeding discussion about which class names apply to which microformatted object ties into the conversation we were having nine months ago (or so) about opacity; much is documented here [1]. My recent thinking has been that the following rules may work: An "outer" microformat should - never look for attributes inside nested microformats (particularly hCard, hCalendar, hAtom and xFolk) - never look for attributes inside BLOCKQUOTE or Q - "unless explicitly defined to be otherwise" This is still _theoretical_ and would need to be backed up by the usual process related work, especially to see how it would impact existing and proposed microformats. Note also my latest narrowing of scope for an "item" microformat [2] which would make this less of an open-ended statement. Regards, etc... David [1] http://microformats.org/wiki/mfo-examples [2] http://microformats.org/wiki/item From davidjanes at blogmatrix.com Sat Dec 9 05:43:32 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 05:43:34 2006 Subject: [uf-discuss] [admin] mailing list policies reminder In-Reply-To: References: Message-ID: <21e523c20612090543g6c48c78apd9dbb437e186c440@mail.gmail.com> On 10/20/06, Ryan King wrote: > This is a just a friendly reminder for everyone to read our mailing > list policies - http://microformats.org/mailinglists-policies/ . The > reason for the reminder is that this list has grown, a lot > and many of the policies are meant to help everyone deal with and > minimize overload. How about URLs should be placed in footnotes [1]. Because this is 72-character wide text only mailing list, I'm finding often that I need to reconstruct URLs that are getting split over multiple lines. This rarely happens when URLs are placed in footnotes. Regards, etc... [1] Like this. From andy at pigsonthewing.org.uk Sat Dec 9 06:43:30 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 06:44:44 2006 Subject: [uf-discuss] [admin] mailing list policies reminder In-Reply-To: <21e523c20612090543g6c48c78apd9dbb437e186c440@mail.gmail.com> References: <21e523c20612090543g6c48c78apd9dbb437e186c440@mail.gmail.com> Message-ID: >How about URLs should be placed in footnotes [1]. Because this is >72-character wide text only mailing list, I'm finding often that I >need to reconstruct URLs that are getting split over multiple lines. >This rarely happens when URLs are placed in footnotes. I prefer not to do so, but place each on a new line, and usually provide a "tinyURL" for longer examples. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sat Dec 9 06:45:16 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 06:46:46 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> Message-ID: In message <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com>, David Janes writes >My recent thinking has been that the following rules may work: > >An "outer" microformat should >- never look for attributes inside nested microformats (particularly >hCard, hCalendar, hAtom and xFolk) You immediately hit problems with adr and geo inside hCard. >- never look for attributes inside BLOCKQUOTE or Q Why not? >- "unless explicitly defined to be otherwise" How would that be done? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sat Dec 9 06:49:15 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 06:50:51 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> Message-ID: In message <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com>, David Janes writes >2. Are not class names supposed to have a single meaning across _all_ >microformats? Even if they are, care still needs to be taken, where the class name is likely to occur, in other contexts, such as "title", "var", "bin" "class" etc. I again refer you to discussion on this point in the 'species' discussions. Of course, there may be language issues, too. Suppose it came to light that, say, "vcard" was Elbonian for "headline", and thus widely used by newspaper sites in Elbonia? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From brian.suda at gmail.com Sat Dec 9 07:01:18 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 07:01:20 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> Message-ID: <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> On 12/9/06, David Janes wrote: > I was just looking at a discussion about "citation" and came across > this example. --- do you have a URL where you found this example? > Questions: > > 1. Is citation really considering using "title" for the title of a book? --- no, this is probably a very old example. > 2. Are not class names supposed to have a single meaning across _all_ > microformats? I remember this from hAtom discussions, but ... --- yes, that is why much of what was in that example is incorrect > 3. Is this documented somewhere or is it something that everyone is > supposed to know (or am I just wrong)? --- is what documented? the fact that property values are the same across all microformats? or the values for the citation format? > 4. If my assumption is correct, should I note it in a few pages; --- i'm not sure what your assumption is? the citation format is still being mashed out - so the property values should not be taken as final. -- brian suda http://suda.co.uk From brian.suda at gmail.com Sat Dec 9 07:07:57 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 07:08:01 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> Message-ID: <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> On 12/9/06, David Janes wrote: > My recent thinking has been that the following rules may work: > > An "outer" microformat should > - never look for attributes inside nested microformats (particularly > hCard, hCalendar, hAtom and xFolk) --- i would also disagree with this because then you creating dependancies across ALL microformats, now and forever. If i create a VALID hCard 1.0 parser... in 2 years when hFooBar hits the web, my VALID 1.0 parser is no longer valid - other microformats could obsolete existing standards. Microformats are meant as building blocks and they should be able to be using independantly and together... otherwise everytime someone marked-up an hCalendar with an hCard for the venue, your hCalendar location would be empty. It's not a bug, it's a feature. -- brian suda http://suda.co.uk From davidjanes at blogmatrix.com Sat Dec 9 07:10:54 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 07:10:58 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> Message-ID: <21e523c20612090710v3b969094u97991199c11f7d57@mail.gmail.com> On 12/9/06, Brian Suda wrote: > On 12/9/06, David Janes wrote: > --- no, this is probably a very old example. > > > 2. Are not class names supposed to have a single meaning across _all_ > > microformats? I remember this from hAtom discussions, but ... > > --- yes, that is why much of what was in that example is incorrect > > > 3. Is this documented somewhere or is it something that everyone is > > supposed to know (or am I just wrong)? > > --- is what documented? the fact that property values are the same > across all microformats? or the values for the citation format? The latter. I though that "but" and ellipses from point 2 leading into point 3 made this clear. > > 4. If my assumption is correct, should I note it in a few pages; > > --- i'm not sure what your assumption is? the citation format is still > being mashed out - so the property values should not be taken as > final. As per the previous point regarding property values across all microformats. Regards, etc... David From brian.suda at gmail.com Sat Dec 9 07:18:22 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 07:18:26 2006 Subject: [uf-discuss] [implied hCards] Examples and wiki pages In-Reply-To: <2F5EE7F8-49CC-4009-AD30-7D45856E209C@ryancannon.com> References: <2F5EE7F8-49CC-4009-AD30-7D45856E209C@ryancannon.com> Message-ID: <21e770780612090718t509e7d67od52775ef2cf17e68@mail.gmail.com> On 12/8/06, Ryan Cannon wrote: > Greetings, > > In lieu of working on my finals I decided to start a few > wiki pages in reponse to Ryan King's call for research: --- have had a look through some of the pages, i don't assume you are finished, but i disagree with several of the points you have brought-up... we've had LONG threads previously about how additional semantics "bloat" html... while this might be true on some aspects you examples conveniently ignore things. For example: John Doe quickly becomes: John Doe The first example of an 'a' element would STILL require some sort of 'block-level' element for the page to be valid, so when you claim that the second instance is 500% more mark-up[1] that is not true, because you are not comparing apples-to-apples. With the implied-brainstorming page you never mention 'sort-string' so you are adding more mark-up to distort the output because the second example would actually produce MORE metadata in the vcard than your smaller implied first example. Semantics aren't free, we can add simple 'implied rules' but i would ask that we do so for one of two reasons? Either #1 you are trying to save bytes (which IMHO is not a good reason) or #2 you are trying to make publishing easier... so if we are going to work under the assumption of #2 lets, try to avoid the whole "HTML Bloat" discussion. -brian [1] - http://microformats.org/wiki/hcard-implied -- brian suda http://suda.co.uk From davidjanes at blogmatrix.com Sat Dec 9 07:28:28 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 07:28:31 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> Message-ID: <21e523c20612090728q9d549e5y59e4cb62e3f0e7f5@mail.gmail.com> On 12/9/06, Brian Suda wrote: > On 12/9/06, David Janes wrote: > > My recent thinking has been that the following rules may work: > > > > An "outer" microformat should > > - never look for attributes inside nested microformats (particularly > > hCard, hCalendar, hAtom and xFolk) > > --- i would also disagree with this because then you creating > dependancies across ALL microformats, now and forever. If i create a > VALID hCard 1.0 parser... in 2 years when hFooBar hits the web, my > VALID 1.0 parser is no longer valid - other microformats could > obsolete existing standards. Microformats are meant as building blocks > and they should be able to be using independantly and together... > otherwise everytime someone marked-up an hCalendar with an hCard for > the venue, your hCalendar location would be empty. It's not a bug, > it's a feature. How would someone marking up a hCalendar with a hCard make the location empty under those rules? The hCard is part of the hCalendar, both as part of the spec [1] and implicitly because it's there. Ignoring the fact that it's part of the spec, my point still holds: the _attributes_ of the hCard associate with the hCard and the hCard as a _whole_ then is associated with the hCalendar. Now, to understand your hFooBar example, consider two possibities: hFooBar is embedded inside of (say) hCalendar, or hCalendar is used inside of hFooBar. If hFooBar is written to reuse class names from hCalendar, your 1.0 parser is going to be confused (interpret the microformat incorrectly) in the embedded case _no matter what_. In the enclosing case (i.e. hFooBar encloses hCalendar), it makes no difference because your 1.0 parser does not see hFooBar. If hFooBar does not reuse class names, the your 1.0 parser is fine in both cases. Regards, etc... [1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents From brian.suda at gmail.com Sat Dec 9 07:32:25 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 07:32:28 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e523c20612090710v3b969094u97991199c11f7d57@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> <21e523c20612090710v3b969094u97991199c11f7d57@mail.gmail.com> Message-ID: <21e770780612090732g64b23645i81818b4ffe78d568@mail.gmail.com> On 12/9/06, David Janes wrote: > > > 3. Is this documented somewhere or is it something that everyone is > > > supposed to know (or am I just wrong)? > > > > --- is what documented? the fact that property values are the same > > across all microformats? or the values for the citation format? > > The latter. I though that "but" and ellipses from point 2 leading into > point 3 made this clear. --- sorry, i missed that. But i think i am still confused :) it's too early for me. In regards to latter (the citation microformats), the best documentation at the moment is here[1], but that is purely a brainstormed-straw-proposal, there are several things wrong with it and much it is still trying to be flushed out or is out-right incorrect - so don't consider it anywhere ready to be a draft - and therefore any of those properties shouldn't be spread around the rest of the wiki because they are more than like to be reduced/added/changed. > > > 4. If my assumption is correct, should I note it in a few pages; > > > > --- i'm not sure what your assumption is? the citation format is still > > being mashed out - so the property values should not be taken as > > final. > > As per the previous point regarding property values across all microformats. well, i certainly wouldn't add anything here: http://microformats.org/wiki/class-names This just talks about the class-design-patter http://microformats.org/wiki/class-design-pattern so i don't think that would be the best place to say that properties are universal across all formats. I'm not sure about how or where to add a "no namespace, so all property names are universal" discussion to the process page? http://microformats.org/wiki/process#Moving_from_Stage_to_Stage I'll leave that up to others to discuss where that best belongs - i thought we had a page(s) that talked about it, maybe they just need to be linked-to or made more prominent? -brian [1] - http://microformats.org/wiki/citation-brainstorming#Brian.27s_Straw_format -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Sat Dec 9 07:36:55 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 07:37:59 2006 Subject: [uf-discuss] [implied hCards] Examples and wiki pages In-Reply-To: <21e770780612090718t509e7d67od52775ef2cf17e68@mail.gmail.com> References: <2F5EE7F8-49CC-4009-AD30-7D45856E209C@ryancannon.com> <21e770780612090718t509e7d67od52775ef2cf17e68@mail.gmail.com> Message-ID: In message <21e770780612090718t509e7d67od52775ef2cf17e68@mail.gmail.com>, Brian Suda writes >For example: > >John Doe > >quickly becomes: > > > >John > >Doe > > > > >The first example of an 'a' element would STILL require some sort of >'block-level' element for the page to be valid True, but consider:

John Doe and Fred Smith.

(other points not disputed) -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From davidjanes at blogmatrix.com Sat Dec 9 07:48:27 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 07:48:32 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e770780612090732g64b23645i81818b4ffe78d568@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> <21e523c20612090710v3b969094u97991199c11f7d57@mail.gmail.com> <21e770780612090732g64b23645i81818b4ffe78d568@mail.gmail.com> Message-ID: <21e523c20612090748l2b06a954g9b47f6ae6566c7dc@mail.gmail.com> On 12/9/06, Brian Suda wrote: > On 12/9/06, David Janes wrote: > > > > 3. Is this documented somewhere or is it something that everyone is > > > > supposed to know (or am I just wrong)? > > > > > > --- is what documented? the fact that property values are the same > > > across all microformats? or the values for the citation format? > > > > The latter. I though that "but" and ellipses from point 2 leading into > > point 3 made this clear. > > --- sorry, i missed that. But i think i am still confused :) it's too > early for me. In regards to latter (the citation microformats), the > best documentation at the moment is here[1], but that is purely a > brainstormed-straw-proposal, there are several things wrong with it > and much it is still trying to be flushed out or is out-right > incorrect - so don't consider it anywhere ready to be a draft - and > therefore any of those properties shouldn't be spread around the rest > of the wiki because they are more than like to be > reduced/added/changed. Sorry, now it's _my_ bad. I meant the former (all microformats). Reseting the conversation to it's most basic: Is this a true or false statement? class names should have an unambiguous meaning across all microformats. Regards, etc... David From brian.suda at gmail.com Sat Dec 9 07:53:12 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 07:53:17 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e523c20612090728q9d549e5y59e4cb62e3f0e7f5@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> <21e523c20612090728q9d549e5y59e4cb62e3f0e7f5@mail.gmail.com> Message-ID: <21e770780612090753y76abbc40i51163e2ca0a451@mail.gmail.com> On 12/9/06, David Janes wrote: > How would someone marking up a hCalendar with a hCard make the > location empty under those rules? The hCard is part of the hCalendar, > both as part of the spec [1] and implicitly because it's there. You wrote earlier: An "outer" microformat should - never look for attributes inside nested microformats (particularly hCard, hCalendar, hAtom and xFolk) --- sorry, i took your: NEVER to mean NEVER-EVER and not NEVER, except when it is part of the spec. i still think/feel that excluding embeded microformats inside other microformats is a bad idea. The whole point of NOT having namespaces is that the property values that we put into class/rel/rev have the same consistent meaning across all formats and therefore SHOULD be considered even when nested because it IS the same meaning. As it stands, hCard does NOT have any rules for other microformats to be nested inside of it... So if i were to do something like:

Brian Suda

My Birthday

Jan 1st

According to the "Never look inside other microformats when parsing the outermost format" the "bday" value would never be picked-up by the hCard parser. Also, if/when hFoobar came-out, if "to be a valid parser you can't parse inside other formats" it would HAVE to know NOT to parse inside hFooBar and how would it know not to do that unless, when each new format is minted, all previous formats must also update? that doesn't make sense to do. I think that the other nested formats should be transparent and any parser can look inside any other format - that's why we choose property values that apply across the whole microformats spectrum. Does that make sense? or are we both arguing (and agreeing) about the same thing and just not realising it? -brian -- brian suda http://suda.co.uk From brian.suda at gmail.com Sat Dec 9 07:55:04 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 07:55:07 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e523c20612090748l2b06a954g9b47f6ae6566c7dc@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> <21e523c20612090710v3b969094u97991199c11f7d57@mail.gmail.com> <21e770780612090732g64b23645i81818b4ffe78d568@mail.gmail.com> <21e523c20612090748l2b06a954g9b47f6ae6566c7dc@mail.gmail.com> Message-ID: <21e770780612090755h3ac56cdaxc7f08864d05110a6@mail.gmail.com> On 12/9/06, David Janes wrote: > Is this a true or false statement? class names should have an > unambiguous meaning across all microformats. true. -- brian suda http://suda.co.uk From davidjanes at blogmatrix.com Sat Dec 9 07:55:15 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 07:55:18 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> Message-ID: <21e523c20612090755i15e0bdedi6f921e3200da00d2@mail.gmail.com> > > >- never look for attributes inside BLOCKQUOTE or Q > > Why not? Because their definitions in the HTML spec [1] say that these are for pulling in data from elsewhere. From this one concludes that it's likely that this data is not necessarily going to be marked up in a way consistent with the current page. > > >- "unless explicitly defined to be otherwise" > > How would that be done? When writing a new microformat, one says "we look inside X Y and Z for A B and C" Regards, etc... [1] http://www.w3.org/TR/REC-html40/struct/text.html#edef-BLOCKQUOTE From davidjanes at blogmatrix.com Sat Dec 9 08:17:33 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 08:17:36 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e770780612090753y76abbc40i51163e2ca0a451@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> <21e523c20612090728q9d549e5y59e4cb62e3f0e7f5@mail.gmail.com> <21e770780612090753y76abbc40i51163e2ca0a451@mail.gmail.com> Message-ID: <21e523c20612090817p1e7cc307n265ddb264a18ff15@mail.gmail.com> On 12/9/06, Brian Suda wrote: > i still think/feel that excluding embeded microformats inside other > microformats is a bad idea. The whole point of NOT having namespaces > is that the property values that we put into class/rel/rev have the > same consistent meaning across all formats and therefore SHOULD be > considered even when nested because it IS the same meaning. > > As it stands, hCard does NOT have any rules for other microformats to > be nested inside of it... So if i were to do something like: >

> Brian Suda >

My Birthday

> Jan 1st >

> > According to the "Never look inside other microformats when parsing > the outermost format" the "bday" value would never be picked-up by the > hCard parser. Also, if/when hFoobar came-out, if "to be a valid parser > you can't parse inside other formats" it would HAVE to know NOT to > parse inside hFooBar and how would it know not to do that unless, when > each new format is minted, all previous formats must also update? that > doesn't make sense to do. > > I think that the other nested formats should be transparent and any > parser can look inside any other format - that's why we choose > property values that apply across the whole microformats spectrum. > > Does that make sense? or are we both arguing (and agreeing) about the > same thing and just not realising it? We're not talking about the same thing but I think the case you're making here is pretty strong. The issue that I've been trying to solve in my mind (and I'm sure we're all on the same page here) is given an attribute A nested in micrformats M, N and P (from inner to outer), is "what does A belong to". If the answer is "all of them" then there seems to seems to be a potential conflict "consistent meaning" and "same meaning". Consider this nesting:

...

8 December 2006

9 December 2006

In this example, I'm reusing "published" to mean to "the date of publication of a microformatted object"; in one case, a blog entry and in the other case, the page itself. This reuses the "published" class from hAtom to a new microformat for describing the publication date of the page (some research has happened on this in the past). If we ask the parser for "give me the publication date of the page", then obviously it has the sort out which to use. We could define a whole new class for describing the publication date of the page, but then we have multiple classes meaning more or less the same thing. I don't have a happy solution for this and maybe it just comes down to "work it out case by case". However, I potentially see it to be very useful to reuse things like "fn" in nested microformats. I'm still happy with the BLOCKQUOTE/Q rules. Regards, etc... David From davidjanes at blogmatrix.com Sat Dec 9 08:20:13 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 08:20:16 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e770780612090755h3ac56cdaxc7f08864d05110a6@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> <21e523c20612090710v3b969094u97991199c11f7d57@mail.gmail.com> <21e770780612090732g64b23645i81818b4ffe78d568@mail.gmail.com> <21e523c20612090748l2b06a954g9b47f6ae6566c7dc@mail.gmail.com> <21e770780612090755h3ac56cdaxc7f08864d05110a6@mail.gmail.com> Message-ID: <21e523c20612090820l7e01ef99rf440313e3f78fffb@mail.gmail.com> Cool. Second question :-): but this isn't explicitly documented anywhere, correct? Regards, etc... David On 12/9/06, Brian Suda wrote: > On 12/9/06, David Janes wrote: > > Is this a true or false statement? class names should have an > > unambiguous meaning across all microformats. > > true. From brian.suda at gmail.com Sat Dec 9 08:35:50 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 08:35:54 2006 Subject: [uf-discuss] Nested Microformats Message-ID: <21e770780612090835t5ecc57a0oae8738537ffaacbf@mail.gmail.com> On 12/9/06, David Janes wrote: > The issue that I've been trying to solve in my mind (and I'm sure > we're all on the same page here) is given an attribute A nested in > micrformats M, N and P (from inner to outer), is "what does A belong > to". If the answer is "all of them" then there seems to seems to be a > potential conflict "consistent meaning" and "same meaning". > > Consider this nesting: > > >

> ... >

8 December 2006

9 December 2006

> --- correct, the one rule we do have for some of these issues is the "singleton property" where "published" will only be extracted/decoded from the first instance. So, if you have the page level "published" before the hentry one, then everything would work out fine. The first instance of published (the page level one) would be associated with the whole page and any subsequent "published" values would be ignored - now when parsing just hentry, since the parser would "start" looking for microformatted data "below"/"nested-in" the hentry instance, the "first instance" of "published" is outside the hentry and therefore would NOT be the first instance in relation to the hentry and the first instance of the nested "published" would be used for the hentry published date. (i hope that makes sense, i re-read it and i think it is clear - if not i can write-out a full example.) > In this example, I'm reusing "published" to mean to "the date of > publication of a microformatted object"; in one case, a blog entry and > in the other case, the page itself. This reuses the "published" class > from hAtom to a new microformat for describing the publication date of > the page (some research has happened on this in the past). If we ask > the parser for "give me the publication date of the page", then > obviously it has the sort out which to use. We could define a whole > new class for describing the publication date of the page, but then we > have multiple classes meaning more or less the same thing. --- yes, for better or worse, sometime we have created several properties which sometime mean the same thing, but with different names. in hAtom we have published and updated, with hCard we have REV and with hCalendar we have last-updated. So we SORT OF have 4 values with similar semantics. If this is a issue we could start a discussion about collapsing some of this data, or we could just not worry about it until we get to real-world issues (which is what i would prefer). We could ALSO make new parsing rules. If we do the proper research and find that all the pages we find that publish a "last-updated" timestamp are at the bottom, then it is not inconcievable that the rule for parsing last-page-update-date-time is the "last instance", now that too has its pro's and con's... > I don't have a happy solution for this and maybe it just comes down to > "work it out case by case". However, I potentially see it to be very > useful to reuse things like "fn" in nested microformats. --- There was a discussion ALONG time ago for an MSO, value. Which (i think) stood for "microformats something/simple object" which basically, was a "don't look in here" (if i remember correctly) it never really went anywhere because the "only use the first instance" solved all of the known issues, but i'll let someone who knows more about MSO elaborate about it. -brian -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Sat Dec 9 08:36:27 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 08:37:58 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e523c20612090755i15e0bdedi6f921e3200da00d2@mail.gmail.com> References: <00ae01c71b54$4263fb80$0702a8c0@Guides.local> <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> <21e523c20612090755i15e0bdedi6f921e3200da00d2@mail.gmail.com> Message-ID: <29F3GBxLYueFFw7J@pigsonthewing.org.uk> In message <21e523c20612090755i15e0bdedi6f921e3200da00d2@mail.gmail.com>, David Janes writes >> >- never look for attributes inside BLOCKQUOTE or Q >> >> Why not? > >Because their definitions in the HTML spec [1] say that these are for >pulling in data from elsewhere. From this one concludes that it's >likely that this data is not necessarily going to be marked up in a >way consistent with the current page. Consider:

John Doe said: My new address will be 1, High Street, Anytown

>> >- "unless explicitly defined to be otherwise" >> >> How would that be done? > >When writing a new microformat, one says "we look inside X Y and Z for >A B and C" And for existing uFs? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From brian.suda at gmail.com Sat Dec 9 08:44:05 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 08:44:08 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e523c20612090820l7e01ef99rf440313e3f78fffb@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> <21e523c20612090710v3b969094u97991199c11f7d57@mail.gmail.com> <21e770780612090732g64b23645i81818b4ffe78d568@mail.gmail.com> <21e523c20612090748l2b06a954g9b47f6ae6566c7dc@mail.gmail.com> <21e770780612090755h3ac56cdaxc7f08864d05110a6@mail.gmail.com> <21e523c20612090820l7e01ef99rf440313e3f78fffb@mail.gmail.com> Message-ID: <21e770780612090844k24e931cdyde2cadbad8084c4e@mail.gmail.com> On 12/9/06, David Janes wrote: > Second question :-): but this isn't explicitly documented anywhere, correct? --- i thought there was some substantical documentation - maybe it is not under the topic/name i thought it was/should be. The best thing i found was on the Main_page of the wiki with the link title of "class names defined across all microformats" http://microformats.org/wiki/Main_Page#Design_Patterns Then on that page is simply the list of values, their definition and which formats they are associated with (http://microformats.org/wiki/existing-classes) I would certainly take abit of time and dig around the wiki before you create/edit a page because i really thought there was something and we shouldn't duplicate the work - but if you do find it, then it should be made more visible. Anyone else have any suggestions about how to proceed? it is a wiki, it is probably better to get something down, we can always move it around and edit it - just be sure to try and search to see something doesn't already exist. -brian -- brian suda http://suda.co.uk From elias at torrez.us Sat Dec 9 08:45:43 2006 From: elias at torrez.us (Elias Torres) Date: Sat Dec 9 08:45:47 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e523c20612090817p1e7cc307n265ddb264a18ff15@mail.gmail.com> References: <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> <21e523c20612090728q9d549e5y59e4cb62e3f0e7f5@mail.gmail.com> <21e770780612090753y76abbc40i51163e2ca0a451@mail.gmail.com> <21e523c20612090817p1e7cc307n265ddb264a18ff15@mail.gmail.com> Message-ID: <905f7c910612090845o16710330sb19d998d0f33b6d5@mail.gmail.com> On 12/9/06, David Janes wrote: > On 12/9/06, Brian Suda wrote: > [snip] > > We're not talking about the same thing but I think the case you're > making here is pretty strong. > > The issue that I've been trying to solve in my mind (and I'm sure > we're all on the same page here) is given an attribute A nested in > micrformats M, N and P (from inner to outer), is "what does A belong > to". If the answer is "all of them" then there seems to seems to be a > potential conflict "consistent meaning" and "same meaning". > I'm trying to stay out of this because of I'm being consumed by other commitments, but I'm really pleased to see a very healthy ongoing conversation on the subject on this list. I think I really like the way that David is stating the issue and am patiently hoping to see the uf community taking this issue up further and watching for an outcome. As an aside, I'm going to refocus my "semantic html" efforts from worrying too much about the new attributes (e.g. RDFa: about, property, etc) and worrying about mechanisms to resolve cases such as the one posted by David. However, more importantly, I need to find an important enough instance of the so-called problem that needs us to resolve the "general microformat(s)" case instead of hoping that if we build it, they will come. -Elias From brian.suda at gmail.com Sat Dec 9 08:51:11 2006 From: brian.suda at gmail.com (Brian Suda) Date: Sat Dec 9 08:51:15 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <905f7c910612090845o16710330sb19d998d0f33b6d5@mail.gmail.com> References: <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> <21e523c20612090728q9d549e5y59e4cb62e3f0e7f5@mail.gmail.com> <21e770780612090753y76abbc40i51163e2ca0a451@mail.gmail.com> <21e523c20612090817p1e7cc307n265ddb264a18ff15@mail.gmail.com> <905f7c910612090845o16710330sb19d998d0f33b6d5@mail.gmail.com> Message-ID: <21e770780612090851k303027cco844a62a4c052017b@mail.gmail.com> Thanks Elias for weighing in, i was getting abit worried that people might have been "putting words in your mouth", it is glad to know you are on the list to clear-up any potential confusions. -brian On 12/9/06, Elias Torres wrote: > On 12/9/06, David Janes wrote: > > On 12/9/06, Brian Suda wrote: > > > [snip] > > > > We're not talking about the same thing but I think the case you're > > making here is pretty strong. > > > > The issue that I've been trying to solve in my mind (and I'm sure > > we're all on the same page here) is given an attribute A nested in > > micrformats M, N and P (from inner to outer), is "what does A belong > > to". If the answer is "all of them" then there seems to seems to be a > > potential conflict "consistent meaning" and "same meaning". > > > > I'm trying to stay out of this because of I'm being consumed by other > commitments, but I'm really pleased to see a very healthy ongoing > conversation on the subject on this list. I think I really like the > way that David is stating the issue and am patiently hoping to see the > uf community taking this issue up further and watching for an outcome. > > As an aside, I'm going to refocus my "semantic html" efforts from > worrying too much about the new attributes (e.g. RDFa: about, > property, etc) and worrying about mechanisms to resolve cases such as > the one posted by David. However, more importantly, I need to find an > important enough instance of the so-called problem that needs us to > resolve the "general microformat(s)" case instead of hoping that if we > build it, they will come. > > -Elias > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- brian suda http://suda.co.uk From scott at randomchaos.com Sat Dec 9 09:40:39 2006 From: scott at randomchaos.com (Scott Reynen) Date: Sat Dec 9 09:40:50 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <905f7c910612090845o16710330sb19d998d0f33b6d5@mail.gmail.com> References: <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <14596d040612090427k4b72dahce9cf826b0e3cf71@mail.gmail.com> <21e523c20612090540s6b7bc14ak229ebff4786c2e9d@mail.gmail.com> <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> <21e523c20612090728q9d549e5y59e4cb62e3f0e7f5@mail.gmail.com> <21e770780612090753y76abbc40i51163e2ca0a451@mail.gmail.com> <21e523c20612090817p1e7cc307n265ddb264a18ff15@mail.gmail.com> <905f7c910612090845o16710330sb19d998d0f33b6d5@mail.gmail.com> Message-ID: <5912EDEF-4CE8-438B-B04D-DFB973CDDD1D@randomchaos.com> On Dec 9, 2006, at 10:45 AM, Elias Torres wrote: > However, more importantly, I need to find an > important enough instance of the so-called problem that needs us to > resolve the "general microformat(s)" case instead of hoping that if we > build it, they will come. Exactly. That's my primary concern with trying to solve this problem right now: building a solution around hypothetical publishing makes the solution more likely to fail when real publishing shows up. I think it would be good if more publishers were adding their own non- microformat semantics to their HTML to see how multiple experiments actually conflict and how those conflicts are most easily resolved before we formalize the process. Peace, Scott From andy at pigsonthewing.org.uk Sat Dec 9 10:10:53 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 10:12:16 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> References: <21e523c20612090520x23d8896coe0dfe684d141ecb0@mail.gmail.com> <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com> Message-ID: In message <21e770780612090701s313622c6t8588bd5d34191313@mail.gmail.com>, Brian Suda writes >On 12/9/06, David Janes wrote: >> I was just looking at a discussion about "citation" and came across >> this example. > >--- do you have a URL where you found this example? It comes from this mailing list post: -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sat Dec 9 11:04:39 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 11:06:01 2006 Subject: [uf-discuss] New wiki page summarily deleted Message-ID: I spent some time today, creating a 'wiki' page about unAPI, documenting the microformat proposed there , in a neutral way - not to support it, but to enable others to see and discuss it and, if appropriate, refute or reject the proposal. I have not yet had a response to my invitation to unAPI's authors to view the page and to comment there. Tantek has just deleted the new page, with no discussion or warning, declaring it "not a microformat" and "offtopic" (sic). So much for "community". -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From tantek at cs.stanford.edu Sat Dec 9 11:34:31 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sat Dec 9 11:34:34 2006 Subject: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <5912EDEF-4CE8-438B-B04D-DFB973CDDD1D@randomchaos.com> Message-ID: On 12/9/06 9:40 AM, "Scott Reynen" wrote: > On Dec 9, 2006, at 10:45 AM, Elias Torres wrote: > >> However, more importantly, I need to find an >> important enough instance of the so-called problem that needs us to >> resolve the "general microformat(s)" case instead of hoping that if we >> build it, they will come. > > Exactly. That's my primary concern with trying to solve this problem > right now: building a solution around hypothetical publishing makes > the solution more likely to fail when real publishing shows up. This is the tip of the iceberg of the problems with this thread. I am ending this thread of >50 messages now and am hoping to use it as both a learning experience and example of what to avoid in order to improve the signal to noise ratio on this list. In no particular order: 1. Parsing is OFF-TOPIC for microformats-discuss. Such discussions belong in microformats-dev. See the mailing-lists page on the wiki where this has been documented for quite some time: And then - if you are not actually working on (i.e. coding) a parser, then please don't post until you are. Theoretical worries are not a priority. 2. Use real world examples for discussions. Throughout this thread there have been numerous arguments based on strictly theoretical examples. The problem is we can waste ALL our time from now until forever discussing/worrying about theoretical examples and get nothing done. Theoretical examples are the equivalent to a DOS attack on actually getting things done. I for one prefer to get things done and leave the theoretical examples for the PhD authors of the future (no offense to PhD authors). I've updated: http://microformats.org/wiki/mailing-lists#general_guidelines 3. Prefixing (e.g. "vcard-") has already been considered and rejected for microformats in general. There have been deliberate exceptions made for one microformat (hAtom). I'm not going to spend the time re-arguing this now - I have added an item to my to-do list on the wiki to better document this. 4. Better "Subject" lines please. When you fork a thread or focus on a specific subject, please update the Subject in the email. The vast majority of the emails with subject "Comments from IBM/Lotus rep about Microformats)" should have had some other subject line specific to the topic being discussed. This is already documented in the mailing list polices, which I request everyone on this list please go re-read: http://microformats.org/mailinglists-policies/ Thanks everyone - let's all work together to improve the signal-to-noise ratio on this list. Tantek From tantek at cs.stanford.edu Sat Dec 9 11:46:31 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sat Dec 9 11:46:32 2006 Subject: how-to-play, community, tone (was Re: [uf-discuss] New wiki page summarily deleted) In-Reply-To: Message-ID: On 12/9/06 11:04 AM, "Andy Mabbett" wrote: > > I spent some time today, creating a 'wiki' page about unAPI, documenting > the microformat proposed there , To be clear, it is not a microformat. It is not based on real world publishing examples, it does not follow the process etc. It is a proposal for use of semantic class names. Nothing more. > in a neutral > way - not to support it, but to enable others to see and discuss it and, > if appropriate, refute or reject the proposal. > > I have not yet had a response to my invitation to unAPI's authors to > view the page and to comment there. > > Tantek has just deleted the new page, with no discussion or warning, > declaring it "not a microformat" and "offtopic" (sic). As it did not follow the process, it does not belong on the microformats wiki. See: http://microformats.org/wiki/how-to-play The community has been a bit lax on focusing on "real world" discussions, both in the mailing lists and on the wiki, and it is about time we refocus the discussion on real world examples which are likely to benefit the most real world publisher first. > So much for "community". Andy, while I appreciate your frustration, I kindly request that you refrain from making snarky commentary such as that sentence on the list. Another area that we (I in particular) have been lax with is helping maintain the general tone and demeanor of this list. One thing I really like about the microformats community is that it tends to be a lot nicer, more polite, more respectful, and just overall welcoming than many other standards lists. However, that is a fragile state, and unless we are vigilant about keeping such a good tone, I am afraid we will lose it. Many of us (myself included) may stray from time to time and make snarky commentary and I ask everyone on the list to kindly call folks out on it (as above) with the assumption that everyone *does* want to keep a good tone of discussion here. For worse offenses, i.e. if you feel like someone is being personally/verbally abusive on the list, I encourage you to respond to the individual privately calling them on it, and cc myself and Ryan King so that we can keep privately track of complaints. I think in general we can self-regulate, but I am now open to removing people who are consistently abusive from the list if necessary. I really don't want it to come to that, but I would rather remove an individual or two from the list than have the community continue to lose its comfortable/good/healthy tone of discussion. Thanks, Tantek From tantek at cs.stanford.edu Sat Dec 9 11:50:31 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sat Dec 9 11:50:33 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e770780612090844k24e931cdyde2cadbad8084c4e@mail.gmail.com> Message-ID: On 12/9/06 8:44 AM, "Brian Suda" wrote: > On 12/9/06, David Janes wrote: > >> Second question :-): but this isn't explicitly documented anywhere, correct? > > --- i thought there was some substantical documentation - maybe it is > not under the topic/name i thought it was/should be. > This page goes into it in some detail: http://microformats.org/wiki/naming-principles but I do need to spend more time adding more to it: http://microformats.org/wiki/to-do#introduction_.2F_community Thanks, Tantek From davidjanes at blogmatrix.com Sat Dec 9 11:57:53 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 9 11:57:56 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: References: <21e770780612090844k24e931cdyde2cadbad8084c4e@mail.gmail.com> Message-ID: <21e523c20612091157q713e400ase15db4929c4d0b41@mail.gmail.com> On 12/9/06, Tantek ?elik wrote: > On 12/9/06 8:44 AM, "Brian Suda" wrote: > > --- i thought there was some substantical documentation - maybe it is > > not under the topic/name i thought it was/should be. > > > > This page goes into it in some detail: > > http://microformats.org/wiki/naming-principles > > but I do need to spend more time adding more to it: > > http://microformats.org/wiki/to-do#introduction_.2F_community Ah, thank you. I may seed a few reference to this in appropriate places as no 'big' pages links to this [1]. Regards, etc... [1] http://microformats.org/wiki?title=Special:Whatlinkshere&target=naming-principles From tantek at cs.stanford.edu Sat Dec 9 12:04:40 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sat Dec 9 12:04:43 2006 Subject: [uf-discuss] Unambiguous class names In-Reply-To: <21e523c20612091157q713e400ase15db4929c4d0b41@mail.gmail.com> Message-ID: On 12/9/06 11:57 AM, "David Janes" wrote: > On 12/9/06, Tantek ?elik wrote: >> On 12/9/06 8:44 AM, "Brian Suda" wrote: >>> --- i thought there was some substantical documentation - maybe it is >>> not under the topic/name i thought it was/should be. >>> >> >> This page goes into it in some detail: >> >> http://microformats.org/wiki/naming-principles >> >> but I do need to spend more time adding more to it: >> >> http://microformats.org/wiki/to-do#introduction_.2F_community > > Ah, thank you. I may seed a few reference to this in appropriate > places as no 'big' pages links to this [1]. > > Regards, etc... > > [1] > http://microformats.org/wiki?title=Special:Whatlinkshere&target=naming-princip > les David that would be greatly appreciated. Thanks for helping make this information more findable/accessible. Tantek From andy at pigsonthewing.org.uk Sat Dec 9 12:11:17 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 12:12:54 2006 Subject: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: References: <5912EDEF-4CE8-438B-B04D-DFB973CDDD1D@randomchaos.com> Message-ID: In message , Tantek ?elik writes >I am ending this thread of >50 messages now That's interesting - with what authority do you "declare end of thread". Isn't this supposed to be a community, and isn't that or the community to do? If there is an autocracy (or some other non-community based management system) here, then surely it should be openly and honestly documented? >Parsing is OFF-TOPIC for microformats-discuss. Such discussions belong >in microformats-dev. See the mailing-lists page on the wiki where this has >been documented for quite some time: [...] >And then - if you are not actually working on (i.e. coding) a parser, then >please don't post until you are. So, parsing should only be discussed by people who are actively writing parsers? And someone proposing a microformat should not comment on how it is intended to be parsed? And someone using uFs in their mark-up, perhaps for the first time, should not ask questions about, nor comment on, how they are being parsed? If so, that would have made this conversation: "illegal", resulting in the loss of the benefits gained form it. It would also prohibit the discussion of most use-cases, and would prohibit a proponent from answering questions about their proposed microformat. Also prohibited would be the reporting of bugs in parsers: >Theoretical worries are not a priority. They may not be *your* priority, but few inventions or advancements could have been made, without some consideration of theoretical matters. >2. Use real world examples for discussions. Throughout this thread there >have been numerous arguments based on strictly theoretical examples. > >The problem is we can waste ALL our time from now until forever >discussing/worrying about theoretical examples and get nothing done. Your implication, that all theoretical examples result in time wasting, is unfounded. >Theoretical examples are the equivalent to a DOS attack on actually getting >things done. Such hyperbole! >3. Prefixing (e.g. "vcard-") has already been considered and rejected for >microformats in general. There have been deliberate exceptions made for one >microformat (hAtom). I'm not going to spend the time re-arguing this now - >I have added an item to my to-do list on the wiki to better document this. Thank you for making clear that it's currently not (well) documented. Are we to understand also, that every decision, once made, even if ill-documented, is irrevocable? Or should we deduce that, if deliberate exceptions can be made in one case, it is perfectly reasonable to suggest that deliberate exceptions be made in another? Put another way: how are we to resolve the clear inconsistency in your third point? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sat Dec 9 12:33:49 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 12:35:15 2006 Subject: how-to-play, community, tone (was Re: [uf-discuss] New wiki page summarily deleted) In-Reply-To: References: Message-ID: In message , Tantek ?elik writes >On 12/9/06 11:04 AM, "Andy Mabbett" wrote: > >> >> I spent some time today, creating a 'wiki' page about unAPI, documenting >> the microformat proposed there , > >To be clear, it is not a microformat. That rather depends on which of the many definitions you use. For instance, if the admittedly woolly: Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. would arguably include it. > It is not based on real world >publishing examples, it does not follow the process etc. The "process" is addressed to people who "wanna (sic) develop a new microformat". Since I was not intending to do any such thing, how is that relevant to my actions? And what of all the other pages on the wiki which do not meet the *suggested* course of actions on that page? >It is a proposal for use of semantic class names. Nothing more. Aren't all microformats ("rel" excepted)? >> Tantek has just deleted the new page, with no discussion or warning, >> declaring it "not a microformat" and "offtopic" (sic). > >As it did not follow the process, it does not belong on the microformats >wiki. You clearly think not, I disagree. If, as you seem to feel, you "outrank" "ordinary" participants such as me, then the manner in which such precedence is decided needs to be made transparent (or at least apparent). Nonetheless, instead of deleting the page within a few hours of its creation (ion a weekend at that) you could, have discussed the matter with the "community" first; edited thp ge (this is supposedly a wiki) to indicate your views on its ineligibility, or moved tit to a page with a different title. > See: http://microformats.org/wiki/how-to-play "Please only create pages directly relating to microformats on this wiki" seems to be the only relevant clause on that page. I don't see how it precludes my actions, which described a microformat proposal at the external page cited. >The community has been a bit lax on focusing on "real world" discussions, >both in the mailing lists and on the wiki, and it is about time we refocus >the discussion on real world examples which are likely to benefit the most >real world publisher first. I'm sure that the community would have benefited from having its attention drawn to such an external proposal; from having the opportunity to make up its individual and collective minds as to its merits or otherwise, and from participating ion that process. >> So much for "community". > >Andy, while I appreciate your frustration, Are you sure that you do? > I kindly request that you refrain >from making snarky commentary such as that sentence on the list. I stand by it, and refute your judgmental accusation. My dictionary gives "snarky" (which is, I believe, an Americanism) as "irritable, crotchety, impertinent, critical". It was only the latter, and justifiably so. Your actions showed a clear disregard for the community which it is claimed manages the "process". I challenge you to allow that community to operate without such consultation-free intervention. [...] >I think in general we can self-regulate, but I am now open to removing >people who are consistently abusive from the list if necessary. Are you threatening me? Is that how you respond to criticism of your apparently high- handed actions? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From tantek at cs.stanford.edu Sat Dec 9 12:36:56 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sat Dec 9 12:36:59 2006 Subject: admins, prefix exceptions (was Re: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)) In-Reply-To: Message-ID: On 12/9/06 12:11 PM, "Andy Mabbett" wrote: > In message , Tantek ?elik > writes > >> I am ending this thread of >50 messages now > > That's interesting - with what authority do you "declare end of thread". > Isn't this supposed to be a community, and isn't that or the community > to do? > > If there is an autocracy (or some other non-community based management > system) here, then surely it should be openly and honestly documented? I am an admin on this list/site as is Ryan King. >> 3. Prefixing (e.g. "vcard-") has already been considered and rejected for >> microformats in general. There have been deliberate exceptions made for one >> microformat (hAtom). I'm not going to spend the time re-arguing this now - >> I have added an item to my to-do list on the wiki to better document this. > > Thank you for making clear that it's currently not (well) documented. > > Are we to understand also, that every decision, once made, even if > ill-documented, is irrevocable? No. > Or should we deduce that, if deliberate exceptions can be made in one > case, it is perfectly reasonable to suggest that deliberate exceptions > be made in another? Yes exceptions can be made but only with exceptionally good reasons. In the case of hAtom, you can read through the archives for the reasoning in depth, but in summary: since we were reusing the semantics of the IETF Atom standard, we very much wanted to reuse the vocabulary as well to minimize confusion and mean precisely the same semantics as defined in the Atom RFC 4287, and thus a few of the hAtom properties appear to be prefixed (entry-title, entry-content, entry-summary) in order to literally reuse those terms from the RFC (title, content, summary). Perhaps that would be a good hatom-faq entry. Thanks, Tantek From andy at pigsonthewing.org.uk Sat Dec 9 12:44:28 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 12:46:23 2006 Subject: admins, prefix exceptions (was Re: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)) In-Reply-To: References: Message-ID: In message , Tantek ?elik writes >>> I am ending this thread of >50 messages now >> >> That's interesting - with what authority do you "declare end of thread". >> Isn't this supposed to be a community, and isn't that or the community >> to do? >> >> If there is an autocracy (or some other non-community based management >> system) here, then surely it should be openly and honestly documented? > >I am an admin on this list/site as is Ryan King. I know. That doesn't address my point. > Your refusal to address my concerns and answer questions on the administration of *this list*, and its use by the community, is duly noted. >microformats> "microformats" is not a sentient entity, it cannot have a view on such matters. >>> 3. Prefixing (e.g. "vcard-") has already been considered and rejected for >>> microformats in general. There have been deliberate exceptions made for one >>> microformat (hAtom). I'm not going to spend the time re-arguing this now - >>> I have added an item to my to-do list on the wiki to better document this. >> >> Thank you for making clear that it's currently not (well) documented. >> >> Are we to understand also, that every decision, once made, even if >> ill-documented, is irrevocable? > >No. > > >> Or should we deduce that, if deliberate exceptions can be made in one >> case, it is perfectly reasonable to suggest that deliberate exceptions >> be made in another? > >Yes exceptions can be made but only with exceptionally good reasons. So it's perfectly acceptable to make such a suggestion. Good. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Sat Dec 9 12:54:43 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 9 12:56:07 2006 Subject: false claim regarding relevance of topics on this list (was: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)) In-Reply-To: References: <5912EDEF-4CE8-438B-B04D-DFB973CDDD1D@randomchaos.com> Message-ID: In message , Tantek ?elik writes >1. Parsing is OFF-TOPIC for microformats-discuss. Furthermore, your assertion is not supported by: A mailing list for general discussion of microformats nor: This is a public list for discussion of microformats. Unmoderated, open subscription. nor: This is an open and public list for anyone interested in microformats. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From lucas.gonze at gmail.com Sat Dec 9 15:35:57 2006 From: lucas.gonze at gmail.com (Lucas Gonze) Date: Sat Dec 9 15:36:00 2006 Subject: how-to-play, community, tone (was Re: [uf-discuss] New wiki page summarily deleted) In-Reply-To: References: Message-ID: On 12/9/06, Andy Mabbett wrote: > In message , Tantek ?elik > writes > >I think in general we can self-regulate, but I am now open to removing > >people who are consistently abusive from the list if necessary. > > Are you threatening me? Is that how you respond to criticism of your > apparently high- handed actions? Yes, Tantek was threatening you. That's typical of life on microformats.org. He is an aggressive and controlling guy, and the main other characters, the people who call themselves "moderators", follow his lead. You have to accept being pushed around by these guys if you want to work on microformats. The conclusion I personally draw is that this intellectual work probably contains many flaws because it is conducted in an environment that prevents authentic discourse. From lists at allinthehead.com Sat Dec 9 17:48:20 2006 From: lists at allinthehead.com (Drew McLellan) Date: Sat Dec 9 17:48:27 2006 Subject: how-to-play, community, tone (was Re: [uf-discuss] New wiki page summarily deleted) In-Reply-To: References: Message-ID: On 9 Dec 2006, at 23:35, Lucas Gonze wrote: > On 12/9/06, Andy Mabbett wrote: >> In message , Tantek ?elik >> writes >> >I think in general we can self-regulate, but I am now open to >> removing >> >people who are consistently abusive from the list if necessary. >> >> Are you threatening me? Is that how you respond to criticism of your >> apparently high- handed actions? > > Yes, Tantek was threatening you. That's typical of life on > microformats.org. He is an aggressive and controlling guy, and the > main other characters, the people who call themselves "moderators", > follow his lead. You have to accept being pushed around by these guys > if you want to work on microformats. > > The conclusion I personally draw is that this intellectual work > probably contains many flaws because it is conducted in an environment > that prevents authentic discourse. Was that sarcasm? Those statements don't ring true from my perspective. Even if that's how you feel, I'm not sure how the above moves us forward or does anything other than make needless personal attacks. drew. From chris.messina at gmail.com Sat Dec 9 18:22:21 2006 From: chris.messina at gmail.com (Chris Messina) Date: Sat Dec 9 18:22:25 2006 Subject: how-to-play, community, tone (was Re: [uf-discuss] New wiki page summarily deleted) In-Reply-To: References: Message-ID: <1bc4603e0612091822j5c7d7615k64a68f217607aa18@mail.gmail.com> On 12/9/06, Lucas Gonze wrote: > On 12/9/06, Andy Mabbett wrote: > > In message , Tantek ?elik > > writes > > >I think in general we can self-regulate, but I am now open to removing > > >people who are consistently abusive from the list if necessary. > > > > Are you threatening me? Is that how you respond to criticism of your > > apparently high- handed actions? > > Yes, Tantek was threatening you. That's typical of life on > microformats.org. He is an aggressive and controlling guy, and the > main other characters, the people who call themselves "moderators", > follow his lead. You have to accept being pushed around by these guys > if you want to work on microformats. Tantek is not a "controlling" guy other than when there are clearly explained and regularly enforced principles that anyone could enforce, just as Tantek does, in order to keep the list on target and not spiraling out into multiple "theoretical endpoints" as many standards lists have historically done. We also have set and agreed to a mandate that, unlike other standards-creating bodies, isn't about addressing every possible use-case we can dream up, but only ones that are found in popular use with plenty of a priori implementations *in the wild*. If anything, the standards we espouse are simply the codification, and conversion in to HTML, of existing human behavior, which makes us more anthropologists than technologists (who are given to invention). If Tantek seems controlling or heavy handed, it is because few others have exhibited such a consistent dedication to the open process and principles of our community. If it weren't for his tireless enforcement of these guidelines, this community would have lost focus a long time ago, developing a number of formats and specifications that would never have seen adoption or implementation beyond a small, marginal few, relegating the bulk of our work to the scrapheap of standards history. If we need hard decisions to be made from time to time in order to advance our collective efforts and to continue promoting the widespread adoption we've seen in the past year, so be it. And, should those decisions be made, I would be happy to defer to those who share and communicate the vision of microformats; who espouse the principles that we've chosen to operate under; who contribute code, build implementations and write documentation; those who are active in positively contributing to the list, supporting those who are new as well as those who have been here for a long time; and those who do not pretend to speak for the community when in reality they only speak for themselves. I, for one, do not want to see the politicization of this list and want to reiterate that on the whole, the members of this list are an intelligent, forward-thinking and open-minded fervent group of folks looking to codify the building blocks of the future of the open web. And anything that distracts us from that bigger picture is a threat to our work and should be addressed in a way consistent with our values, our historical behavior and in the interest of the list itself. Chris -- Chris Messina Citizen Provocateur & Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private From mikeschinkel at gmail.com Sat Dec 9 20:58:52 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sat Dec 9 20:58:55 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> Message-ID: <00d501c71c17$e39d7080$0702a8c0@Guides.local> > Forgive me if I have missed something, but could a parser not > understand multiple formats if the HTML used was also > meaningful? For example a blocklevel element (say a

) > could contain some content that was marked up with one > microformat, and another blocklevel element could contain > content marked up with another entirely different > microformat. The fact that they shared the same page isn't a > problem. A parser could easily identify child relationships > within the HTML and extrapolate. A.) Possible, but that would require putting lots of intelligence into parsers, which is generally considered A Bad Thing(tm) w.r.t. web architecture goals. B.) But if the two microformats markup similar content then probably not possible. > Granted this wouldn't be so easy if two microformats were > muddled together on the same page. And if they were then > maybe there are two questions to ask. 1/ Is the microformat > in need of some additional elements?, and 2/ Is the author of > the page trying to do too much. > could it be laid out differently? The biggest problem is when two (lowercase) microformats get developed by authors having no knowledge of the other, and then each microformats gets adopted by different constituents. Finally, the content of a website is a crossover for both constiuents creating a conflict between the microformats. For example, lets say that two microformats one for business news and the other for the car industry were independently created at roughly the same time. Both includie markup for identifying a company; the subject of a news story and the manufacturer of automobiles, respectively. Since they are both trying to mark up the same data, there's a good chance they will use some of the same terminology but they may use it in conflicting ways. Now let's assume a site that provides auto news comes along, and ideally needs to use both the news and the car industry microformats. Unfortuantely they will have to choose only one because the two microformats conflict. I view creating an architecture that is likely to creat conflicts like this as A Very Bad Thing(tm), especially when it would be so easy to resolve at this point in Microformats' evolution. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From bewest at gmail.com Sat Dec 9 22:23:58 2006 From: bewest at gmail.com (Benjamin West) Date: Sat Dec 9 22:24:00 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <00d501c71c17$e39d7080$0702a8c0@Guides.local> References: <14596d040612090133u144da4det108f8fbf8bd27ae4@mail.gmail.com> <00d501c71c17$e39d7080$0702a8c0@Guides.local> Message-ID: <8ad71be30612092223u33771c78gd9d481be03249227@mail.gmail.com> > The biggest problem is when two (lowercase) microformats get developed by > authors having no knowledge of the other, and then each microformats gets > adopted by different constituents. I'm not quite sure what you mean here. Is there a difference between lowercase microformats and uppercase microformats? Ben From siegfried at rorkvell.de Sun Dec 10 01:51:30 2006 From: siegfried at rorkvell.de (Siegfried Gipp) Date: Sun Dec 10 01:51:20 2006 Subject: [uf-discuss] proposals Message-ID: <200612101051.30357.siegfried@rorkvell.de> Hi, i just have set up 2 more pages. I'm currently working on data mining in the web and so stumbled over the w3c Annotea Bookmarks. So one page is about the relation between microformats xfolk and Annotea Bookmarks: http://www.rorkvell.de/tech/xfolkmapping The other one is a proposal on how to structure distributed information. It currently only contains 2 attribute values: subtopicOf and sameAs. The first is from the Annotea Bookmarks spec, the other from the owl spec: http://www.rorkvell.de/tech/topics For both pages i'd be interested in feedback. Siegfried From costello at mitre.org Sun Dec 10 05:12:52 2006 From: costello at mitre.org (Costello, Roger L.) Date: Sun Dec 10 05:08:22 2006 Subject: [uf-discuss] Is no longer valid? Message-ID: Hi Folks, Last week I validated (using the W3C validator) an HTML file that specifies the hCard profile: Today when I validated the same file the validator says it's not valid: there is no attribute "profile". What happened? Is there no longer a profile attribute on the body element? /Roger From siegfried at rorkvell.de Sun Dec 10 05:32:01 2006 From: siegfried at rorkvell.de (Siegfried Gipp) Date: Sun Dec 10 05:31:51 2006 Subject: [uf-discuss] Is no longer valid? In-Reply-To: References: Message-ID: <200612101432.01981.siegfried@rorkvell.de> Am Sonntag, 10. Dezember 2006 14:12 schrieb Costello, Roger L.: > Hi Folks, > > Last week I validated (using the W3C validator) an HTML file that > specifies the hCard profile: > > > > Today when I validated the same file the validator says it's not valid: > > there is no attribute "profile". > > What happened? Is there no longer a profile attribute on the body > element? As far as i know the "profile" was never an attribute of , but of From rbach at rbach.priv.at Sun Dec 10 05:43:00 2006 From: rbach at rbach.priv.at (Robert Bachmann) Date: Sun Dec 10 05:42:07 2006 Subject: [uf-discuss] Is no longer valid? In-Reply-To: <200612101432.01981.siegfried@rorkvell.de> References: <200612101432.01981.siegfried@rorkvell.de> Message-ID: <457C0EE4.4090208@rbach.priv.at> Siegfried Gipp wrote: > Am Sonntag, 10. Dezember 2006 14:12 schrieb Costello, Roger L.: >> Hi Folks, >> >> Last week I validated (using the W3C validator) an HTML file that >> specifies the hCard profile: >> >> >> >> Today when I validated the same file the validator says it's not valid: >> >> there is no attribute "profile". >> >> What happened? Is there no longer a profile attribute on the body >> element? > > As far as i know the "profile" was never an attribute of , but of The profile attribute belongs to [1] [1] http://www.w3.org/TR/html401/struct/global.html#adef-profile -- Robert Bachmann (OpenPGP KeyID: 0x4A5CCF10) From bdarcus.lists at gmail.com Sun Dec 10 08:21:17 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Sun Dec 10 08:21:22 2006 Subject: class="hack"? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <88ECA9C0-0B68-48A1-A49B-8F704266FC66@opendarwin.org> References: <005101c71860$c22b1980$0702a8c0@Guides.local> <901C2E10-DBAB-43A5-B03D-6602032CFA85@randomchaos.com> <5DC6CEDD-85D4-4D7D-8916-B30973D262CE@technorati.com> <88ECA9C0-0B68-48A1-A49B-8F704266FC66@opendarwin.org> Message-ID: On 12/8/06, Dr. Ernie Prabhakar wrote: > Um, maybe I'm not quite understanding what you mean by "model". Are > you saying that there's no way to create a generic parser that > transforms the microformatted data into a normalized form? Not exactly. More importantly, that there's no extension model, so that people are reliant, in effect, on this community to make the data that is important to them visible. > What you may not realize (I didn't at first either) is that > microformats.org is -- by *definition* -- optimizing for a world > there are only a "handful" of discrete microformats. Thus, there is > no point in worrying about the general case; there are only special > cases, and a relatively small number of those. But I think that what I've seen on this list is that this is a myth. Every week, it seems, someone asks for a new microformat. Bruce From jason at sixtwothree.org Sun Dec 10 14:08:30 2006 From: jason at sixtwothree.org (Jason Garber) Date: Sun Dec 10 14:08:34 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? Message-ID: <457C855E.1010708@sixtwothree.org> Hi everyone, I'm pretty new to the mailing list, so apologies if this has already been covered. According to the XFN spec, rel="muse" is a link to someone who inspires you, and is listed as being a "romantic" relationship. I was wondering if it is always implied as a romantic relationship, since one could certainly find someone else inspiring without being romantically involved/interested. I did a cursory search for anyone/anything that covered this, but couldn't find anything more specific. Does anyone have any input on this? Thanks for your help! Jason Garber jason@sixtwothree.org From microformats at 200ok.com.au Sun Dec 10 14:39:37 2006 From: microformats at 200ok.com.au (Ben Buchanan) Date: Sun Dec 10 14:39:41 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <457C855E.1010708@sixtwothree.org> References: <457C855E.1010708@sixtwothree.org> Message-ID: <6ca82b0f0612101439h3180c477lcbc5fae2783c8cf8@mail.gmail.com> Hi there, > Hi everyone, I'm pretty new to the mailing list, so apologies if this > has already been covered. Not that I've seen, so I guess ditto ;) > According to the XFN spec, rel="muse" is a link to someone who inspires > you, and is listed as being a "romantic" relationship. I was wondering > if it is always implied as a romantic relationship, since one could > certainly find someone else inspiring without being romantically > involved/interested. I tend to agree; certainly a quick dictionary check[1] does not say anything about the relationship being romantic in the same sense as other XFN classifications. Probably the neatest definition is "the goddess or the power regarded as inspiring a poet, artist, thinker, or the like". The defining aspect of the relationship is inspiration. I'm not really very well versed in classical mythology (thanks "modern history only" high school); but despite the often-romantic connotations of a relationship between goddess and mortal I think the muse relationship still does not *require* a romantic link. Those with more knowledge in the area can correct me if I'm wrong :) All that said, the actual definition at http://www.gmpg.org/xfn/11 still works: "Someone who brings you inspiration." So, it's really just that it's a bit misleading to include it in the "romantic" category. cheers, Ben [1] http://dictionary.reference.com/browse/muse -- --- --- The future has arrived; it's just not --- evenly distributed. - William Gibson From fberriman at gmail.com Sun Dec 10 15:42:10 2006 From: fberriman at gmail.com (Frances Berriman) Date: Sun Dec 10 15:42:14 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <457C855E.1010708@sixtwothree.org> References: <457C855E.1010708@sixtwothree.org> Message-ID: On 10/12/06, Jason Garber wrote: > Hi everyone, I'm pretty new to the mailing list, so apologies if this > has already been covered. > > According to the XFN spec, rel="muse" is a link to someone who inspires > you, and is listed as being a "romantic" relationship. I was wondering > if it is always implied as a romantic relationship, since one could > certainly find someone else inspiring without being romantically > involved/interested. > > I did a cursory search for anyone/anything that covered this, but > couldn't find anything more specific. Does anyone have any input on > this? Thanks for your help! > > Jason Garber > jason@sixtwothree.org Hey Jason! I actually discussed this with Tantek offlist a while ago, just in passing, as I was curious about this also. I think the decision made (by examining uses in the wild) was that muse shouldn't be purely romantic, as yes - many people mean it in a platonic way. I think it's something that the XFN documentation could do with clarifying. Having it understood as purely romantic is much too restrictive, imho. So - use it as you see fit. Frances -- Frances Berriman http://fberriman.com From bewest at gmail.com Sun Dec 10 16:05:24 2006 From: bewest at gmail.com (Benjamin West) Date: Sun Dec 10 16:05:28 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <6ca82b0f0612101439h3180c477lcbc5fae2783c8cf8@mail.gmail.com> References: <457C855E.1010708@sixtwothree.org> <6ca82b0f0612101439h3180c477lcbc5fae2783c8cf8@mail.gmail.com> Message-ID: <8ad71be30612101605v26eb2bc3waf36185122ecf055@mail.gmail.com> > > I was wondering if it is always implied as a romantic relationship, since one could > > certainly find someone else inspiring without being romantically > > involved/interested. I wasn't aware that muse has any connection to "romantic" unless by "romantic" you mean "of Roman influence" in the same way you might use "hellenic" to mean "Greek influence." In fact the etymology of "music" comes from "muse": "music is the art of the Muses". At that time "music" connoted a much larger subset of "the arts" than our understanding of rhythm, harmony, and melody, along with the other elements of music that we currently define it to be. In ancient Greece, "music" could refer to poetry, dance, recitation, music, instruments, and even certain scientific endeavors such as math and science. It was frequently set as equal partners against athletics. Education was often divided along these two broad lines, eg "educated in music and gymnastics" would encompass much of what we would consider to be education in elementary school, or perhaps a liberal arts curriculum. On a side note: music was a highly symbolic term to encompass many abstract concepts, as opposed to concrete/practical activities such as gymnastics, or concrete techniques to manipulate the world in which we live. (To the extent that it would also include math and philosophy to some degree.) What many would currently consider music today would not have much in common with the music of ancient Greece; heterophony was the main strategy for organizing voices, along with drone techniques, and pitch organization would have been so drastically different (although they, like all known musics, did at least organize around the octave), that most modern listeners would likely not recognize it as music. Suffice to say: "muse" would be apropriate for any categorization of a relationship characterized by a strong influence transmitted from one party to another. Ben PS I /knew/ that music degree would come in handy somehow! On 12/10/06, Ben Buchanan wrote: > Hi there, > > > Hi everyone, I'm pretty new to the mailing list, so apologies if this > > has already been covered. > > Not that I've seen, so I guess ditto ;) > > > According to the XFN spec, rel="muse" is a link to someone who inspires > > you, and is listed as being a "romantic" relationship. I was wondering > > if it is always implied as a romantic relationship, since one could > > certainly find someone else inspiring without being romantically > > involved/interested. > > I tend to agree; certainly a quick dictionary check[1] does not say > anything about the relationship being romantic in the same sense as > other XFN classifications. > > Probably the neatest definition is "the goddess or the power regarded > as inspiring a poet, artist, thinker, or the like". The defining > aspect of the relationship is inspiration. > > I'm not really very well versed in classical mythology (thanks "modern > history only" high school); but despite the often-romantic > connotations of a relationship between goddess and mortal I think the > muse relationship still does not *require* a romantic link. Those with > more knowledge in the area can correct me if I'm wrong :) > > All that said, the actual definition at http://www.gmpg.org/xfn/11 > still works: "Someone who brings you inspiration." So, it's really > just that it's a bit misleading to include it in the "romantic" > category. > > cheers, > > Ben > > [1] http://dictionary.reference.com/browse/muse > > -- > --- > --- The future has arrived; it's just not > --- evenly distributed. - William Gibson > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From tantek at cs.stanford.edu Sun Dec 10 16:24:21 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Dec 10 16:24:21 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: Message-ID: On 12/10/06 3:42 PM, "Frances Berriman" wrote: > On 10/12/06, Jason Garber wrote: >> Hi everyone, I'm pretty new to the mailing list, so apologies if this >> has already been covered. >> >> According to the XFN spec, rel="muse" is a link to someone who inspires >> you, and is listed as being a "romantic" relationship. I was wondering >> if it is always implied as a romantic relationship, since one could >> certainly find someone else inspiring without being romantically >> involved/interested. >> >> I did a cursory search for anyone/anything that covered this, but >> couldn't find anything more specific. Does anyone have any input on >> this? Thanks for your help! >> >> Jason Garber >> jason@sixtwothree.org > > Hey Jason! > > I actually discussed this with Tantek offlist a while ago, just in > passing, as I was curious about this also. I think the decision made > (by examining uses in the wild) was that muse shouldn't be purely > romantic, as yes - many people mean it in a platonic way. I think > it's something that the XFN documentation could do with clarifying. > Having it understood as purely romantic is much too restrictive, imho. > So - use it as you see fit. Certainly "muse" was not intended to only be purely romantic in the literal "romantic relationship" sense (though it is clear how that could easily be misconstrued), and of course that meaning is included. The categorization as "romantic" is in a broader sense, similar to romanticism [1] as in enabling the elevation of: "the achievements of what it [Romanticism] perceived as misunderstood heroic individuals and artists that altered society." or romance the genre [2] [1] http://en.wikipedia.org/wiki/Romanticism [2] http://en.wikipedia.org/wiki/Romance_%28genre%29 That the first specific section in [1] is on music only echoes what Ben West wrote as well. Is this worthy of an xfn-faq entry? Tantek From horsepigcow at gmail.com Sun Dec 10 16:31:23 2006 From: horsepigcow at gmail.com (Tara Hunt) Date: Sun Dec 10 16:31:26 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: References: Message-ID: <310024cb0612101631l6c494c6epfd153ec1c062712d@mail.gmail.com> Interesting anecdote about this...rel="muse" actually caused a bit of a tiff between Chris and I about 6 months back, as he had a bunch of women marked up as this...since it was under 'romantic', he agreed to change them to 'colleague' and 'friend'. :) So, there you go...it causes riffs in relationships and misunderstandings. LOL Tara On 12/10/06, Tantek ?elik wrote: > On 12/10/06 3:42 PM, "Frances Berriman" wrote: > > > On 10/12/06, Jason Garber wrote: > >> Hi everyone, I'm pretty new to the mailing list, so apologies if this > >> has already been covered. > >> > >> According to the XFN spec, rel="muse" is a link to someone who inspires > >> you, and is listed as being a "romantic" relationship. I was wondering > >> if it is always implied as a romantic relationship, since one could > >> certainly find someone else inspiring without being romantically > >> involved/interested. > >> > >> I did a cursory search for anyone/anything that covered this, but > >> couldn't find anything more specific. Does anyone have any input on > >> this? Thanks for your help! > >> > >> Jason Garber > >> jason@sixtwothree.org > > > > Hey Jason! > > > > I actually discussed this with Tantek offlist a while ago, just in > > passing, as I was curious about this also. I think the decision made > > (by examining uses in the wild) was that muse shouldn't be purely > > romantic, as yes - many people mean it in a platonic way. I think > > it's something that the XFN documentation could do with clarifying. > > Having it understood as purely romantic is much too restrictive, imho. > > So - use it as you see fit. > > Certainly "muse" was not intended to only be purely romantic in the literal > "romantic relationship" sense (though it is clear how that could easily be > misconstrued), and of course that meaning is included. > > The categorization as "romantic" is in a broader sense, similar to > romanticism [1] as in enabling the elevation of: > > "the achievements of what it [Romanticism] perceived as misunderstood heroic > individuals and artists that altered society." > > or romance the genre [2] > > [1] http://en.wikipedia.org/wiki/Romanticism > [2] http://en.wikipedia.org/wiki/Romance_%28genre%29 > > That the first specific section in [1] is on music only echoes what Ben West > wrote as well. > > Is this worthy of an xfn-faq entry? > > Tantek > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- tara 'miss rogue' hunt agent provocateur Citizen Agency (www.citizenagency.com) blog: www.horsepigcow.com phone: 415-694-1951 fax: 415-727-5335 From bewest at gmail.com Sun Dec 10 16:52:06 2006 From: bewest at gmail.com (Benjamin West) Date: Sun Dec 10 16:52:09 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: References: Message-ID: <8ad71be30612101652m1d8dcc55i22aecda50abdd960@mail.gmail.com> > Certainly "muse" was not intended to only be purely romantic in the literal > "romantic relationship" sense (though it is clear how that could easily be > misconstrued), and of course that meaning is included. > > The categorization as "romantic" is in a broader sense, similar to > romanticism [1] as in enabling the elevation of: > > "the achievements of what it [Romanticism] perceived as misunderstood heroic > individuals and artists that altered society." > > or romance the genre [2] > > [1] http://en.wikipedia.org/wiki/Romanticism > [2] http://en.wikipedia.org/wiki/Romance_%28genre%29 > > That the first specific section in [1] is on music only echoes what Ben West > wrote as well. > > Is this worthy of an xfn-faq entry? > > Tantek Ah, that's interesting, I was just thinking "the historical period would kind of fit", but even so I feel this is a bit of a stretch! I'm not so sure muse should be grouped with "crush, date, and sweetheart." I actually think muse is more apropriate under Identity than anything else. The Greeks had a play on words that roughly meant "control the rhymes of a nation, and you can control their laws." The idea was that music (or "the muses") had an "ethos" that could have a profound impact on the composition of the person. The people that inspire us often have a profound impact on how we see ourselves, and how we identify with others. From tantek at cs.stanford.edu Sun Dec 10 17:04:06 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Dec 10 17:04:05 2006 Subject: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <310024cb0612101631l6c494c6epfd153ec1c062712d@mail.gmail.com> Message-ID: Aside - this entire thread particularly warms my heart - it's been a while since we've had a serious but light-hearted topic, and clearly the time had come. Jason Garber, welcome to the list, and thanks for a much appreciated bit of levity on a weekend afternoon. On 12/10/06 4:31 PM, "Tara Hunt" wrote: > Interesting anecdote about this...rel="muse" actually caused a bit of > a tiff between Chris and I about 6 months back, as he had a bunch of > women marked up as this...since it was under 'romantic', he agreed to > change them to 'colleague' and 'friend'. Given the variety / diversity of relationships (romantic and otherwise) and the broad spectrum of exclusivity/openness boundaries among people, it's good to clearly communicate about such matters. Tara, since you brought up the topic, did you ask him to change the rel="muse" relationships that Chris had for men as well? This brings up another question in the usage of XFN. The public nature. XFN has always implicitly been designed and used in purely "public" contexts - e.g. the set of relationships was very much filtered by what was found publicly in the wild (before we even had the microformats principles), and what we thought people would feel comfortable expressing publicly. The "romantic" relationships certainly engendered the most debate/discussion among the XFN creators, "crush" and "muse" in particular. While there are a few sites that have publicly searchable indexes of XFN relationships, I don't know of any that provide stats on what XFN relationships are used the most/least (even the Google markup study [1] doesn't mention XFN values). For example how many rel="crush" links are there? > :) So, there you go...it causes riffs in relationships and > misunderstandings. LOL I think I have to pass the buck to communication when it comes to riffs/misunderstandings in relationships. A public admittance to someone being someone else's muse just seems like open honesty IMHO. Thanks, Tantek [1] http://code.google.com/webstats/index.html From chris.messina at gmail.com Sun Dec 10 18:01:26 2006 From: chris.messina at gmail.com (Chris Messina) Date: Sun Dec 10 18:01:29 2006 Subject: class="hack"? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: References: <005101c71860$c22b1980$0702a8c0@Guides.local> <5DC6CEDD-85D4-4D7D-8916-B30973D262CE@technorati.com> <88ECA9C0-0B68-48A1-A49B-8F704266FC66@opendarwin.org> Message-ID: <1bc4603e0612101801q33686907hf1fa494efa4cc2a6@mail.gmail.com> On 12/10/06, Bruce D'Arcus wrote: > On 12/8/06, Dr. Ernie Prabhakar wrote: > > > Um, maybe I'm not quite understanding what you mean by "model". Are > > you saying that there's no way to create a generic parser that > > transforms the microformatted data into a normalized form? > > Not exactly. More importantly, that there's no extension model, so > that people are reliant, in effect, on this community to make the data > that is important to them visible. The extension model is as transparent as any -- you must go through the same iterative process that it takes to make a microformat. In terms of one-off extensions that will have narrow-spread usage, you can simply add more classes or rel values as to your wont. No one's going to stop you. In fact, I've taken to using rel=client on my blogroll simply to make up for an absence that I see in XFN. This may not be very satisfying, but I could care less if anyone actually adopts that value... it's useful for me in describing the relationship. > > What you may not realize (I didn't at first either) is that > > microformats.org is -- by *definition* -- optimizing for a world > > there are only a "handful" of discrete microformats. Thus, there is > > no point in worrying about the general case; there are only special > > cases, and a relatively small number of those. > > But I think that what I've seen on this list is that this is a myth. > Every week, it seems, someone asks for a new microformat. Yes, but how often is a new microformat actually "created" or "launched"? It's extremely rare for good reason. The goal of this community is not to necessary act as a filter, but to adhere to a process for coming to some kind of consensus on a small number of formats that can be embedded in ordinary web pages. We look at widespread existing behavior and help massage that behavior in such a way so that we can help computers understand that data better. We're not competitive with RDF or any other attempts at composing a Generalized Schema of Reality. Indeed, our purview of reality is so narrow as to, in some cases, fluster those who want their pet format codified or blessed by the community. But, if anything, it's the defense against horizontal drift that makes the microformats community so strong and so much more likely to succeed over the long term. Think of microformats as a magnifying glass that's really good at boiling rain drops one at a time. That should help put our potentiality in perspective. That's not, in any way, intended to prevent or defer others from developing their own semantic XHTML class names or of executing on the same community process. In fact, I strongly encourage such work; but, in terms of web-wide adoption, it's unlikely that *any* but the most widely discoverable behaviors will end up ever being turned into "sanctioned" formats by the community. Or, so says I. ;) Chris -- Chris Messina Citizen Provocateur & Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private From chris.messina at gmail.com Sun Dec 10 18:08:14 2006 From: chris.messina at gmail.com (Chris Messina) Date: Sun Dec 10 18:08:18 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <310024cb0612101631l6c494c6epfd153ec1c062712d@mail.gmail.com> References: <310024cb0612101631l6c494c6epfd153ec1c062712d@mail.gmail.com> Message-ID: <1bc4603e0612101808s46b052das14d1b0dbc3d47157@mail.gmail.com> And despite my attempts to explain, as you all have, the origins of the "romantic" sense of the term, Tara never gave me the benefit of the doubt, hence the semantic change. ;) So yes, Tantek, a FAQ entry would certainly be appreciated. Chris On 12/10/06, Tara Hunt wrote: > Interesting anecdote about this...rel="muse" actually caused a bit of > a tiff between Chris and I about 6 months back, as he had a bunch of > women marked up as this...since it was under 'romantic', he agreed to > change them to 'colleague' and 'friend'. > > :) So, there you go...it causes riffs in relationships and > misunderstandings. LOL > > Tara > > On 12/10/06, Tantek ?elik wrote: > > On 12/10/06 3:42 PM, "Frances Berriman" wrote: > > > > > On 10/12/06, Jason Garber wrote: > > >> Hi everyone, I'm pretty new to the mailing list, so apologies if this > > >> has already been covered. > > >> > > >> According to the XFN spec, rel="muse" is a link to someone who inspires > > >> you, and is listed as being a "romantic" relationship. I was wondering > > >> if it is always implied as a romantic relationship, since one could > > >> certainly find someone else inspiring without being romantically > > >> involved/interested. > > >> > > >> I did a cursory search for anyone/anything that covered this, but > > >> couldn't find anything more specific. Does anyone have any input on > > >> this? Thanks for your help! > > >> > > >> Jason Garber > > >> jason@sixtwothree.org > > > > > > Hey Jason! > > > > > > I actually discussed this with Tantek offlist a while ago, just in > > > passing, as I was curious about this also. I think the decision made > > > (by examining uses in the wild) was that muse shouldn't be purely > > > romantic, as yes - many people mean it in a platonic way. I think > > > it's something that the XFN documentation could do with clarifying. > > > Having it understood as purely romantic is much too restrictive, imho. > > > So - use it as you see fit. > > > > Certainly "muse" was not intended to only be purely romantic in the literal > > "romantic relationship" sense (though it is clear how that could easily be > > misconstrued), and of course that meaning is included. > > > > The categorization as "romantic" is in a broader sense, similar to > > romanticism [1] as in enabling the elevation of: > > > > "the achievements of what it [Romanticism] perceived as misunderstood heroic > > individuals and artists that altered society." > > > > or romance the genre [2] > > > > [1] http://en.wikipedia.org/wiki/Romanticism > > [2] http://en.wikipedia.org/wiki/Romance_%28genre%29 > > > > That the first specific section in [1] is on music only echoes what Ben West > > wrote as well. > > > > Is this worthy of an xfn-faq entry? > > > > Tantek > > > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss > > > > > > -- > tara 'miss rogue' hunt > agent provocateur > Citizen Agency (www.citizenagency.com) > blog: www.horsepigcow.com > phone: 415-694-1951 > fax: 415-727-5335 > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Chris Messina Citizen Provocateur & Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable [X] ask first [ ] private From karl at w3.org Sun Dec 10 18:11:06 2006 From: karl at w3.org (Karl Dubost) Date: Sun Dec 10 18:11:32 2006 Subject: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: References: Message-ID: <75A5D481-1402-4207-A2EF-2F1822C6A765@w3.org> Le 11 d?c. 2006 ? 10:04, Tantek ?elik a ?crit : >> :) So, there you go...it causes riffs in relationships and >> misunderstandings. LOL > > I think I have to pass the buck to communication when it comes to > riffs/misunderstandings in relationships. A public admittance to > someone > being someone else's muse just seems like open honesty IMHO. but the world is not "open honesty" ;) it is made of complexity, of long walks in forest, of double meanings, of opacity, the richness of our world lies specifically in this. Binary statement of life destroys the poetry and the social nature of humans. Do not forget that lies are necessary in a social group (think about caring for others for example). It is part of the glue as much as "honesty". and yes thanks tara and all for other topics. Though Tara has just breached a private discussion with her husband in public, I hope he doesn't mind ;) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From tantek at cs.stanford.edu Sun Dec 10 18:52:11 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Dec 10 18:52:20 2006 Subject: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <75A5D481-1402-4207-A2EF-2F1822C6A765@w3.org> Message-ID: On 12/10/06 6:11 PM, "Karl Dubost" wrote: > Le 11 d?c. 2006 ? 10:04, Tantek ?elik a ?crit : >>> :) So, there you go...it causes riffs in relationships and >>> misunderstandings. LOL >> >> I think I have to pass the buck to communication when it comes to >> riffs/misunderstandings in relationships. A public admittance to >> someone >> being someone else's muse just seems like open honesty IMHO. > > but the world is not "open honesty" ;) I would differ only slightly from your statement - the world is not *just* "open honesty" though it does contain some. as does the Web. and it is this existing open honesty on the Web (existing real world publishing behaviors) that microformats seek to represent and communicate. > it is made of complexity, of > long walks in forest, of double meanings, of opacity, the richness of > our world lies specifically in this. indeed. and this is one of the reasons why microformats do not try to alter people's publishing behavior in an unnatural way - and ask of them to make openly honest what is not already so - unlike "a priori" formats efforts which seek to change behavior as such with metadata etc. that they "wish" people would simply magically start publishing. > Binary statement of life > destroys the poetry and the social nature of humans. But it is exactly such binary statements in aggregate (digital data formats) which have done more to communicate and propagate without loss of fidelity poetry, music, movies etc. in recent history. > Do not forget that lies are necessary in a social group (think about > caring for others for example). It is part of the glue as much as > "honesty". I tend to question how much are any specific lies necessary as you say, as rationalizations such as this are the frequent apologies of those who have not yet chosen to challenge the assumptions given them by the contexts which appear to make such lies necessary. But that is merely a matter of opinion and so I choose to simply agree to disagree with you rather than seriously offer any debate. However, in science, I'm not sure there is any need, nor any room for, lies. And science forms the basis of our work here. Thanks, Tantek From tantek at cs.stanford.edu Sun Dec 10 18:54:11 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Dec 10 18:54:09 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <1bc4603e0612101808s46b052das14d1b0dbc3d47157@mail.gmail.com> Message-ID: On 12/10/06 6:08 PM, "Chris Messina" wrote: > And despite my attempts to explain, as you all have, the origins of > the "romantic" sense of the term, Tara never gave me the benefit of > the doubt, hence the semantic change. ;) > > So yes, Tantek, a FAQ entry would certainly be appreciated. It is done. http://microformats.org/wiki/xfn-faq#Why_is_muse_in_the_romantic_category Thanks, Tantek From jason at sixtwothree.org Sun Dec 10 20:29:58 2006 From: jason at sixtwothree.org (Jason Garber) Date: Sun Dec 10 20:30:10 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: References: Message-ID: <457CDEC6.9050204@sixtwothree.org> Tantek ?elik wrote: > Aside - this entire thread particularly warms my heart - it's been a while > since we've had a serious but light-hearted topic, and clearly the time had > come. > > Jason Garber, welcome to the list, and thanks for a much appreciated bit of > levity on a weekend afternoon. Anytime! It's good to see everyone responding so quickly and generously to something that had been bugging me for a few days. > It is done. > > http://microformats.org/wiki/xfn-faq#Why_is_muse_in_the_romantic_category Thanks also for adding this to the wiki, I imagine I'm not the only person to have wondered about rel="muse". Jason jason@sixtwothree.org From kmarks at technorati.com Sun Dec 10 23:41:06 2006 From: kmarks at technorati.com (Kevin Marks) Date: Sun Dec 10 23:41:13 2006 Subject: [uf-discuss] rel="muse" implies romantic relationship? In-Reply-To: <1bc4603e0612101808s46b052das14d1b0dbc3d47157@mail.gmail.com> References: <310024cb0612101631l6c494c6epfd153ec1c062712d@mail.gmail.com> <1bc4603e0612101808s46b052das14d1b0dbc3d47157@mail.gmail.com> Message-ID: <8101ba5855a76bf7e5d815e484ff060d@technorati.com> On Dec 10, 2006, at 6:08 PM, Chris Messina wrote: > And despite my attempts to explain, as you all have, the origins of > the "romantic" sense of the term, Tara never gave me the benefit of > the doubt, hence the semantic change. ;) > > So yes, Tantek, a FAQ entry would certainly be appreciated. Have a look at the Albert Brooks movie 'The Muse' http://www.imdb.com/title/tt0164108/ it explains the concept (and the misunderstandings) rather amusingly, if you'll excuse the pun. From fberriman at gmail.com Mon Dec 11 02:05:49 2006 From: fberriman at gmail.com (Frances Berriman) Date: Mon Dec 11 02:05:54 2006 Subject: [uf-discuss] Mars & Moon news stories In-Reply-To: References: Message-ID: On 07/12/06, Andy Mabbett wrote: > > Both Mars and the Moon have been in the news this week: > > * water on mars: > > > > > > * Mars landers photographed: > > > > > > > "The complete image is centered at 22.3 degrees > latitude, 312.1 degrees East longitude." > > * Moon base proposed: > > > > > and in each case specific locations are referred to. > > Where are we, with the 'Mars': > > > > and 'Luna': > > > > proposals? The plans for the Lunar base are certainly exciting. Discussing specific areas of the moon will become much more common place over the next decade, I'm sure! How sci-fi. (I'm genuinely interested in this, btw, this isn't sarcasm on any level.) Re: status of proposals - back atch'ya! You appear to be the major contributor to both of these proposals, so where are you with them? What specific problems are causing hold-ups, if any? F -- Frances Berriman http://fberriman.com From andy at pigsonthewing.org.uk Mon Dec 11 10:34:01 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Dec 11 10:37:20 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links Message-ID: The problem of misaligned section-edit links is caused by using tags for headers, instead of the proper wiki markup ("=", "==" etc.). I changed one page to fix that explaining so in my edit summary: and Tantek almost immediately reverted it, reintroducing the misaligned linking; and adding an "instruction" not to do so to: -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Mon Dec 11 10:47:52 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Dec 11 10:49:09 2006 Subject: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: References: <75A5D481-1402-4207-A2EF-2F1822C6A765@w3.org> Message-ID: In message , Tantek ?elik writes >Subject: Re: XFN usage stats and Re: [uf-discuss] rel="muse" >implies romantic relationship? Did you perhaps forget to change that? >microformats do not try to alter people's publishing behavior in an >unnatural way - and ask of them to make openly honest what is not >already so - unlike "a priori" formats efforts which seek to change >behavior as such with metadata etc. that they "wish" people would >simply magically start publishing. Perhaps you missed this comment: in which a poster describes how he rejected hResume because it sought to change his publishing behaviour. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Mon Dec 11 11:00:22 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Dec 11 11:01:54 2006 Subject: [uf-discuss] Mars & Moon news stories In-Reply-To: References: Message-ID: In message , Frances Berriman writes >On 07/12/06, Andy Mabbett wrote: >> >> Both Mars and the Moon have been in the news this week: >> Where are we, with the 'Mars': >> >> >> >> and 'Luna': >> >> >> >> proposals? >back atch'ya! You appear to be the major >contributor to both of these proposals, so where are you with them? I've done everything I think I can (please let me know if I've missed something) and am waiting for some response from "the community". >What specific problems are causing hold-ups, if any? So far as I can see, the issues are: * should these be subsets of "geo" (i.e. add an extra class to geo, indicating which body is being referred to); or stand-alone (I'm happy either way; using the former may produce nonsensical results in existing parsers; this might be deemed of little concern). * should there be a class to indicate the mapping convention being used, or should the uF specify a default (as, I believe, is done with geo)? (Of course, there could be a "default unless otherwise stated", meeting both needs). * lack of involvement from the relevant space scientists, not least as addressed in discussion (and apparent rejection by this community - or is the jury still out?) of the potential use of a dedicated mailing list. * naming issues (if any remain, I think they are relatively trivial and easily resolvable). Do you think a "straw man" might be due? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From davidjanes at blogmatrix.com Mon Dec 11 11:23:05 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Dec 11 11:23:33 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: References: Message-ID: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> This policy makes it easier to have a page header without piling up everything under section "1.". It gets ugly if it's done more than once on a page though. Regards, etc.... David On 12/11/06, Andy Mabbett wrote: > > The problem of misaligned section-edit links is caused by > using tags for headers, instead of the proper wiki markup ("=", > "==" etc.). > > I changed one page to fix that explaining so in my edit summary: > > > > and Tantek almost immediately reverted it, reintroducing the misaligned > linking; and adding an "instruction" not to do so to: > > > > -- > Andy Mabbett > * Say "NO!" to compulsory ID Cards: > * Free Our Data: > * Are you using Microformats, yet: ? > _______________________________________________ > 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.onamine.com http://blogmatrix.blogmatrix.com From tjameswhite at yahoo.com Mon Dec 11 11:45:15 2006 From: tjameswhite at yahoo.com (Tim White) Date: Mon Dec 11 11:45:18 2006 Subject: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) Message-ID: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> > From Any Mabbett >Perhaps you missed this comment: > > > >in which a poster describes how he rejected hResume because it sought to >change his publishing behaviour. To address the poster's concerns,

is a block-level element, not inline, and it is suggested but not mandated. Likewise, skills are optional, as are linking them. At least that's how I read the spec. Anyone see it differently? (I've also added my answers to the wiki page.) ~ Tim tjameswhite.com/blog ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. From tjameswhite at yahoo.com Mon Dec 11 11:46:54 2006 From: tjameswhite at yahoo.com (Tim White) Date: Mon Dec 11 11:46:56 2006 Subject: [uf-discuss] Wiki-spam Message-ID: <20061211194655.33587.qmail@web30801.mail.mud.yahoo.com> Just notice that the How-to-edit help page [1] has some, um, colorful content at the moment. Someone want to revert that? [1] http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page ~ Tim tjameswhite.com ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited From tjameswhite at yahoo.com Mon Dec 11 11:53:32 2006 From: tjameswhite at yahoo.com (Tim White) Date: Mon Dec 11 11:53:34 2006 Subject: [uf-discuss] RE: Wiki-spam Message-ID: <20061211195332.22745.qmail@web30804.mail.mud.yahoo.com> Ignore my last message -- didn't notice that I had been bounced to Wikipedia. FYI: it's been fixed over there already. ~ Tim tjameswhite.com ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From andy at pigsonthewing.org.uk Mon Dec 11 12:00:57 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Dec 11 12:01:07 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> References: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> Message-ID: In message <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com>, David Janes writes >On 12/11/06, Andy Mabbett wrote: >> >> The problem of misaligned section-edit links is caused by >> using tags for headers, instead of the proper wiki markup ("=", >> "==" etc.). [Please don't top-post] >This policy makes it easier to have a page header without piling up >everything under section "1.". What is that a problem? It doesn't seem to bother Wikipedia's many users. And is the damage it does to usability worth putting up with, for a marginal, if any, improvement in appearance? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Mon Dec 11 12:01:06 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Dec 11 12:02:25 2006 Subject: [uf-discuss] Mars & Moon news stories In-Reply-To: References: Message-ID: In message , Andy Mabbett writes >Do you think a "straw man" might be due? I've made one, anyway: since the issues to be decided appear finite and easy to list. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From supercanadian at gmail.com Mon Dec 11 12:27:21 2006 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Mon Dec 11 12:27:24 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> References: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> Message-ID: <84ce626f0612111227k59996227pe9c707af4eda0490@mail.gmail.com> Hello, Why not use __NOTOC__ ? See ya On 12/11/06, David Janes wrote: > This policy makes it easier to have a page header without piling up > everything under section "1.". It gets ugly if it's done more than > once on a page though. > > Regards, etc.... > David > > On 12/11/06, Andy Mabbett wrote: > > > > The problem of misaligned section-edit links is caused by > > using tags for headers, instead of the proper wiki markup ("=", > > "==" etc.). > > > > I changed one page to fix that explaining so in my edit summary: > > > > > > > > and Tantek almost immediately reverted it, reintroducing the misaligned > > linking; and adding an "instruction" not to do so to: > > > > > > -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From davidjanes at blogmatrix.com Mon Dec 11 12:33:12 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Dec 11 12:33:16 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: <84ce626f0612111227k59996227pe9c707af4eda0490@mail.gmail.com> References: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> <84ce626f0612111227k59996227pe9c707af4eda0490@mail.gmail.com> Message-ID: <21e523c20612111233n78eda05fof2c6f136f75718d@mail.gmail.com> On 12/11/06, Charles Iliya Krempeaux wrote: > Hello, > > Why not use __NOTOC__ ? Start a wiki page, keep it in edit mode (i.e. don't save) and play with it. The current practice has its downfalls but seems to work esthetically well, with the downside that you have to click one down to edit. Regards, etc... From tantek at cs.stanford.edu Mon Dec 11 12:33:16 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Dec 11 12:33:17 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: <84ce626f0612111227k59996227pe9c707af4eda0490@mail.gmail.com> Message-ID: On 12/11/06 12:27 PM, "Charles Iliya Krempeaux" wrote: > Hello, > > Why not use __NOTOC__ ? I believe __NOTOC__ simply blocks the TOC from appearing at all, unless I'm mistaken. Charles, could you elaborate on how you would use __NOTOC__ to solve this problem of heading noise in TOCs? Thanks, Tantek From supercanadian at gmail.com Mon Dec 11 12:40:51 2006 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Mon Dec 11 12:40:56 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: References: <84ce626f0612111227k59996227pe9c707af4eda0490@mail.gmail.com> Message-ID: <84ce626f0612111240t22950c46j9a2539bae6a068cf@mail.gmail.com> Hello Tantek, You're correct, __NOTOC__ just blocks the TOC from appearing. Re-reading what was originally posted I can see that it won't help with this particular problem. See ya On 12/11/06, Tantek ?elik wrote: > On 12/11/06 12:27 PM, "Charles Iliya Krempeaux" > wrote: > > > Hello, > > > > Why not use __NOTOC__ ? > > I believe __NOTOC__ simply blocks the TOC from appearing at all, unless I'm > mistaken. > > Charles, could you elaborate on how you would use __NOTOC__ to solve this > problem of heading noise in TOCs? > > Thanks, > > Tantek -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From scott at randomchaos.com Mon Dec 11 14:25:36 2006 From: scott at randomchaos.com (Scott Reynen) Date: Mon Dec 11 14:26:00 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: <21e523c20612111233n78eda05fof2c6f136f75718d@mail.gmail.com> References: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> <84ce626f0612111227k59996227pe9c707af4eda0490@mail.gmail.com> <21e523c20612111233n78eda05fof2c6f136f75718d@mail.gmail.com> Message-ID: <0EB3B518-3579-4531-8A09-370E9A1ECFAC@randomchaos.com> On Dec 11, 2006, at 2:33 PM, David Janes wrote: > Start a wiki page, keep it in edit mode (i.e. don't save) and play > with it. The current practice has its downfalls but seems to work > esthetically well, with the downside that you have to click one down > to edit. I just realized that this thread is discussing one of my pet peeves. I can't believe I almost missed the opportunity to rant about how annoying it is to click on an edit link and have it open the wrong section. But even more annoying than that: when the links get pushed down, the last sections end up with no working edit links at all, so you have to guess at the section number if you want to edit those sections. So I'll put my vote in for avoiding whatever causes this to happen. Peace, Scott From andy at pigsonthewing.org.uk Mon Dec 11 14:42:31 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Dec 11 14:44:08 2006 Subject: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> References: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> Message-ID: In message <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com>, Tim White writes >>Perhaps you missed this comment: >> >> >> >>in which a poster describes how he rejected hResume because it sought to >>change his publishing behaviour. >skills are optional, as are linking them. *all* microformats are optional; that's hardy the point. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From ryan at technorati.com Mon Dec 11 14:58:29 2006 From: ryan at technorati.com (Ryan King) Date: Mon Dec 11 14:58:33 2006 Subject: [uf-discuss] Wiki-spam In-Reply-To: <20061211194655.33587.qmail@web30801.mail.mud.yahoo.com> References: <20061211194655.33587.qmail@web30801.mail.mud.yahoo.com> Message-ID: <0170C283-981B-4DED-B99E-BB7633AC4F62@technorati.com> On Dec 11, 2006, at 11:46 AM, Tim White wrote: > Just notice that the How-to-edit help page [1] has some, um, > colorful content at the moment. Someone want to revert that? > > [1] http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page This isn't a wikipedia mailing list. -ryan From ryan at technorati.com Mon Dec 11 15:01:07 2006 From: ryan at technorati.com (Ryan King) Date: Mon Dec 11 15:01:12 2006 Subject: [uf-discuss] Solution to wiki problem with misaligned section-edit links In-Reply-To: <0EB3B518-3579-4531-8A09-370E9A1ECFAC@randomchaos.com> References: <21e523c20612111123wb4a49cek99a515a8d5199bbe@mail.gmail.com> <84ce626f0612111227k59996227pe9c707af4eda0490@mail.gmail.com> <21e523c20612111233n78eda05fof2c6f136f75718d@mail.gmail.com> <0EB3B518-3579-4531-8A09-370E9A1ECFAC@randomchaos.com> Message-ID: On Dec 11, 2006, at 2:25 PM, Scott Reynen wrote: > On Dec 11, 2006, at 2:33 PM, David Janes wrote: > >> Start a wiki page, keep it in edit mode (i.e. don't save) and play >> with it. The current practice has its downfalls but seems to work >> esthetically well, with the downside that you have to click one down >> to edit. > > I just realized that this thread is discussing one of my pet > peeves. I can't believe I almost missed the opportunity to rant > about how annoying it is to click on an edit link and have it open > the wrong section. But even more annoying than that: when the > links get pushed down, the last sections end up with no working > edit links at all, so you have to guess at the section number if > you want to edit those sections. So I'll put my vote in for > avoiding whatever causes this to happen. How about we fix MediaWiki instead? (or maybe see if an upgrade is in order?). -ryan From mikeschinkel at gmail.com Mon Dec 11 18:34:18 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 18:34:35 2006 Subject: XFN usage stats and Re: [uf-discuss] rel="muse" implies romanticrelationship? In-Reply-To: Message-ID: <00ac01c71d96$06018010$0702a8c0@Guides.local> Sorry that I'm coming in a bit late on this, but in looking at rel="muse" it's the only thing in the Microformat that is even close to applicable in a wide variety of cases yet I am completely uncomfortable using it except for in a few rare cases. OTOH, I could use any of the following if attached to "professional": Respect, admire, impressed by,awed, revere, worship, idolize, iconize. If would be nice if there was a way to extend professional respect and admiration. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From mikeschinkel at gmail.com Mon Dec 11 18:59:59 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 19:00:03 2006 Subject: class="hack"? Re: [uf-discuss] Comments from IBM/Lotus rep aboutMicroformats In-Reply-To: <1bc4603e0612101801q33686907hf1fa494efa4cc2a6@mail.gmail.com> Message-ID: <00b401c71d99$9ca1f510$0702a8c0@Guides.local> Chris Messina wrote: > The goal of this community is not to necessary act as a > filter, but to adhere to a process for coming to some kind of > consensus on a small number of formats that can be embedded > in ordinary web pages. We look at widespread existing > behavior and help massage that behavior in such a way so that > we can help computers understand that data better. Chris, are you aware that Ian Hickson and Lachan Hunt on the WHATWG list are prescribing microformats as the generalized extension mechanism for HTML (whenever anyone asks for a more generic extension mechanism?) -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From bewest at gmail.com Mon Dec 11 19:52:05 2006 From: bewest at gmail.com (Benjamin West) Date: Mon Dec 11 19:52:09 2006 Subject: class="hack"? Re: [uf-discuss] Comments from IBM/Lotus rep aboutMicroformats In-Reply-To: <00b401c71d99$9ca1f510$0702a8c0@Guides.local> References: <1bc4603e0612101801q33686907hf1fa494efa4cc2a6@mail.gmail.com> <00b401c71d99$9ca1f510$0702a8c0@Guides.local> Message-ID: <8ad71be30612111952t1b1a334bnac2a11f3a673af90@mail.gmail.com> On 12/11/06, Mike Schinkel wrote: > Chris, are you aware that Ian Hickson and Lachan Hunt on the WHATWG list are > prescribing microformats as the generalized extension mechanism for HTML > (whenever anyone asks for a more generic extension mechanism?) > Mike, this isn't quite true. What's being prescribed are the techniques. Techniques using mechanisms already available in HTML. These are the same techniques that Microformateers apply to well defined problems to create a microformat. But just because microformats are a notable use case for these techniques doesn't mean that anything using those techniques is a microformat. What has been confirmed on the WHATWG list are the techniques available to extend HTML. Ben From mikeschinkel at gmail.com Mon Dec 11 20:02:23 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 20:09:16 2006 Subject: class="hack"? Re: [uf-discuss] Comments from IBM/Lotus repaboutMicroformats In-Reply-To: <8ad71be30612111952t1b1a334bnac2a11f3a673af90@mail.gmail.com> Message-ID: <00c401c71da2$546aeeb0$0702a8c0@Guides.local> Benjamin West wrote: > Mike, this isn't quite true. What's being prescribed are the > techniques. Techniques using mechanisms already available in HTML. > These are the same techniques that Microformateers apply to > well defined problems to create a microformat. But just > because microformats are a notable use case for these > techniques doesn't mean that anything using those techniques > is a microformat. What has been confirmed on the WHATWG list > are the techniques available to extend HTML. Why do these discussions have to be so circular?!? Okay, fine, I'll agree with your clarification because your point is really irrelevent to my concern. But I'll this time use your clarification to point out yet again that without a disambiguation process we'll have Balkanization of these "techniques." I don't care what we call them: "techniques" or "Microformats" or anything else for that matter. All I care is that we get a simple disambiguation strategy included in the recommendation. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From mikeschinkel at gmail.com Mon Dec 11 20:17:50 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 20:17:57 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <21e770780612090707v7d74fa5bw84ed35f6b92be424@mail.gmail.com> Message-ID: <00c601c71da4$7eed2020$0702a8c0@Guides.local> Brian Suda wrote: > Microformats are meant as building blocks and they should be > able to be using independantly and together... If that is true, how can it be achieved without a disambiguation conventions to keep official Microformats from conflicting with similar "techniques." Or is it the view of the Microformat community that Microformats will keep it's house clean and, because Microformats are the "anointed" ones that it just "sucks to be the other guy?" -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ P.S. Actually it will just suck to be the guy who need to use both an "official" Microformat and another one that is just a "technique?" From mikeschinkel at gmail.com Mon Dec 11 20:28:12 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 20:28:15 2006 Subject: [admin] Declaring end of thread (was Re: [uf-discuss] Commentsfrom IBM/Lotus rep about Microformats) In-Reply-To: Message-ID: <00cb01c71da5$efc9af10$0702a8c0@Guides.local> Tantek ?elik wrote: > 3. Prefixing (e.g. "vcard-") has already been considered and > rejected for microformats in general. There have been > deliberate exceptions made for one microformat (hAtom). I'm > not going to spend the time re-arguing this now - I have > added an item to my to-do list on the wiki to better document this. First, I didn't see this until a just little earlier today when I cleaned out my Google spam box (6000+ spam messages and then all of your emails, for some reason.) Second and last, my comment to you based on your position RE:prefixes is that it is just begging to have the Microformat community splintered for lack of a viable solution to a real problem. Maybe prefixes aren't the answer, but I haven't heard an alternate presented. Respectfully, -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From mikeschinkel at gmail.com Mon Dec 11 20:33:15 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 20:33:19 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <8ad71be30612092223u33771c78gd9d481be03249227@mail.gmail.com> Message-ID: <00cc01c71da6$a454b560$0702a8c0@Guides.local> Benjamin West wrote: > I'm not quite sure what you mean here. Is there a difference > between lowercase microformats and uppercase microformats? lowercase microformats = unofficial semantic markup embedded in HTML uppercase microformats = "Official" Microformat -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From mikeschinkel at gmail.com Mon Dec 11 20:12:38 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 20:38:30 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: Message-ID: <00c501c71da3$c34719c0$0702a8c0@Guides.local> Bruce D'Arcus wrote: > In a world in which one CAN consider adding alternative > attributes (HTML 5, etc.), it makes no sense to me one would > simply say "no." [I'm cross posting to uf-discuss and whatwg because Bruce's comment was made on uf-discuss but I've made the same point on WHATWG.] Bruce, I agree with you completely. But Ian Hickson has said that AFAHK that there was no cry for additional attributes on the uf-discuss list, And Ian also said he saw no need for them after I requested to get several attributes added to the list of attributes applicable to all elements, i.e. abbr, href, name, rel, rev, scope, size, src, type, and value. I hadn't had the chance to ask the uf-discuss list about this, so now is a perfect time. What about adding additional standard attributes to all elements. Would it be helpful? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From bewest at gmail.com Mon Dec 11 20:45:41 2006 From: bewest at gmail.com (Benjamin West) Date: Mon Dec 11 20:45:44 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <00cc01c71da6$a454b560$0702a8c0@Guides.local> References: <8ad71be30612092223u33771c78gd9d481be03249227@mail.gmail.com> <00cc01c71da6$a454b560$0702a8c0@Guides.local> Message-ID: <8ad71be30612112045j351b948eq1a30eeb0fda45a24@mail.gmail.com> On 12/11/06, Mike Schinkel wrote: > Benjamin West wrote: > > I'm not quite sure what you mean here. Is there a difference > > between lowercase microformats and uppercase microformats? > > lowercase microformats = unofficial semantic markup embedded in HTML > uppercase microformats = "Official" Microformat > That's the first I've heard of this usage. I think what I'm hearing (and agree with) is a need for a term that describes the product of semantic markup techniques in a general way. Lots of people are already doing this, and don't need any official body to bless them. Microformats (any casing) would be a subset of these products that are blessed by pervasive use across the web. I'm hesitant to pick out such a name, lest I choose badly (eg AJAX). I'm happy to let the market pick that name (eg I don't think anyone should deliberately pick it out.), but at the same time, I'm hesitant to let the term microformats be applied to general applications of general techniques. Does that reverberate at all with you, Mike, or anyone else? From ryan at ryancannon.com Mon Dec 11 21:17:52 2006 From: ryan at ryancannon.com (Ryan Cannon) Date: Mon Dec 11 21:17:58 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <200612120443.kBC4hJlN021646@microformats.org> References: <200612120443.kBC4hJlN021646@microformats.org> Message-ID: On Dec 11, 2006, at 11:43 PM, mikeschinkel@gmail.com wrote: > Brian Suda wrote: >> Microformats are meant as building blocks and they should be >> able to be using independantly and together... > > If that is true, how can it be achieved without a disambiguation > conventions > to keep official Microformats from conflicting with similar > "techniques." > > Or is it the view of the Microformat community that Microformats > will keep > it's house clean and, because Microformats are the "anointed" ones > that it > just "sucks to be the other guy?" Since Microformats (capital-M) are based on research of current practice, I think it's probably more helpful to think of techniques as proto- Microformats. If the community is slow to develop a format that makes sense, we often encourage authors to develop their own systems, which then can inform how a format will function in the wild. This is where documentation and the oft-belabored "process" becomes powerful. Although it can be annoying for early-adopters and people who need solutions now, it creates strong formats once the issues are solidified. -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com From mikeschinkel at gmail.com Mon Dec 11 21:29:25 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 21:29:28 2006 Subject: [uf-discuss] Disambiguation Conventions? (was Comments from IBM/Lotus rep about Microformats) In-Reply-To: Message-ID: <00db01c71dae$7ccaf7e0$0702a8c0@Guides.local> Ryan Cannon wrote: > If the community is slow to develop a format that makes > sense, we often encourage authors to develop their own > systems, which then can inform how a format will function in > the wild. This is where documentation and the oft-belabored > "process" becomes powerful. Although it can be annoying for > early-adopters and people who need solutions now, it creates > strong formats once the issues are solidified. Arrgghhh! (he says, frustrated that people address the tangent to his issue, but don't/won't address his actual issue!) So I repeat: How then can we achieve a disambiguation conventions to keep official Microformats from conflicting with "proto- Microformats?" -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From mikeschinkel at gmail.com Mon Dec 11 21:29:25 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Dec 11 21:29:30 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <8ad71be30612112045j351b948eq1a30eeb0fda45a24@mail.gmail.com> Message-ID: <00dc01c71dae$7e249470$0702a8c0@Guides.local> Benjamin West wrote: > That's the first I've heard of this usage. I think what I'm > hearing (and agree with) is a need for a term that describes > the product of semantic markup techniques in a general way. It's my usage. It seemed natural as I've heard the term uppercase/lowercase used to distinguish between official and unofficial in other areas in the past. > Lots of people are already doing this, and don't need any > official body to bless them. Agreed. I just see the need to give those people a way to disambiguate between themselves and Microformats. I've said the same here as well as on WHATWG. But I'm not gaining any success to date. People are saying it is a hypothetical problem while ignoring that I am saying it is an actual problem in my usage. > Microformats (any casing) would be a subset of these products > that are blessed by pervasive use across the web. I'm > hesitant to pick out such a name, lest I choose badly (eg > AJAX). I'm happy to let the market pick that name (eg I > don't think anyone should deliberately pick it out.), but at > the same time, I'm hesitant to let the term microformats be > applied to general applications of general techniques. > > Does that reverberate at all with you, Mike, or anyone else? That's exactly what I see going on here and discuss on WHATWG, so yes. Ian Hickson called it "Keywords in the HTML extension mechanism" and I reverted to calling it "semantic markup embedded in HTML." Maybe we could call it SemMarE? (yeah, I suck a making up names too. ;-) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From howcome at opera.com Mon Dec 11 22:20:03 2006 From: howcome at opera.com (=?iso-8859-1?Q?H=E5kon?= Wium Lie) Date: Mon Dec 11 22:20:07 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <00cc01c71da6$a454b560$0702a8c0@Guides.local> References: <8ad71be30612092223u33771c78gd9d481be03249227@mail.gmail.com> <00cc01c71da6$a454b560$0702a8c0@Guides.local> Message-ID: <17790.18963.434124.875426@gargle.gargle.HOWL> Also sprach Mike Schinkel: > > I'm not quite sure what you mean here. Is there a difference > > between lowercase microformats and uppercase microformats? > > lowercase microformats = unofficial semantic markup embedded in HTML > uppercase microformats = "Official" Microformat This makes sense to me. Preventing people from using the term "microformat" for their own set of class names is an uphill battle; the term "microformat" is simply too attractive. Besides, people should be encouraged to play. Most private sets will quickly die a natural death and do no harm. Those who survive in the wild deserve the capital M. -h&kon H?kon Wium Lie CTO ??e?? howcome@opera.com http://people.opera.com/howcome From brian.suda at gmail.com Thu Dec 7 12:50:20 2006 From: brian.suda at gmail.com (brian suda) Date: Tue Dec 12 01:54:20 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <043901c71a3e$4c7e7940$0702a8c0@Guides.local> References: <043901c71a3e$4c7e7940$0702a8c0@Guides.local> Message-ID: <45787E8C.2050203@gmail.com> Mike Schinkel wrote: > If it is not a scarce resource, please tell me what would happen if I > decided to start marking up documents, as an example, using the class > "directory" and "license", for purposes other than rel-directory and > re-license? How could my markup and those Microformats co-exist in the same > HTML document? > --- This hasn't been a problem yet, but we do have mechanisms to prevent problems in this space. It is possible for me to start creating a CSS style called 'vcard', but a parser would know that this is a style and not semantics because of the lack of a profile URI. Eventually, as microformats become more popular, the profile URI is used to disambiguate random styles with intended semantic values. So far this isn't a problem, and to save time and effort we are focusing on the more important things. (IMHO) i would like to see more profile attributes, but i am not too worried - we'll cross that bridge when we need too, but there is a system in place to solve these problems - microformats are not "squatting" on terms. -brian From mmurphy at municorps.org Tue Dec 12 05:38:26 2006 From: mmurphy at municorps.org (Mark Murphy) Date: Tue Dec 12 05:38:29 2006 Subject: [uf-discuss] Microformats: working group vs. meme Message-ID: <457EB0D2.20609@municorps.org> Mike Schinkel wrote: > I don't care what we call them: "techniques" or "Microformats" or > anything else for that matter. All I care is that we get a simple > disambiguation strategy included in the recommendation. Two cents from the peanut gallery... I think what Mr. Schinkel and Mr. Mabbett are running into is the apparent schism between microformats-as-working-group and microformats-as-meme. Microformats.org specifies a process plus a scope delimiter ("paving the cow paths") which are perfectly reasonable for a working group. In fact, in many ways, they're exemplary. However, they are more or less orthogonal to the microformats meme as expressed on the microformats.org home page: "Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards." After all, one can use the microformats.org design techniques and not pave a cow path. The fact that people are doing this, and are expressly tipping their cap to microformats.org, suggests that there's a meme taking root, and people are trying to apply the "microformats" label to that meme. So, when Mr. Mabbett added unAPI references to the wiki, he was (presumably) doing so to document a use of the meme; that page was then deleted (presumably) because it wasn't documenting an action of the working group. From my extremely humble vantage point, I can see three main paths for microformats.org to choose from: -- Embrace microformats-as-meme. That implies that the working group (i.e., those that follow the process outlined on the wiki) is defining "official microformats" or some such, and that there also are resources available to folk to discuss and link to things that follow microformats-as-meme but are not within the working group's scope. This could be as simple as a separate mailing list and wiki (or set of pages on the existing wiki). -- Limit microformats.org to only those things that follow the process. In this case, somebody will eventually try to fork the meme, as there will be those who want to do microformats-esque things that don't fit the working group, and those microformats-esque things need a name that's cleaner than "microformats-esque". -- A hybrid: microformats.org helps orchestrate the forking of the meme. Basically, work with those doing microformats-esque work to come up with an alternative term and site for the meme, then point people to the meme when they come up with ideas that fit the meme but not the process or scope of microformats.org. Forgive me if I spoke out of turn or have incorrectly identified the intentions of anyone... Mark Murphy mmurphy@municorps.org From scott at randomchaos.com Tue Dec 12 07:48:20 2006 From: scott at randomchaos.com (Scott Reynen) Date: Tue Dec 12 07:48:36 2006 Subject: [uf-discuss] extending HTML & extending semantics In-Reply-To: <00c501c71da3$c34719c0$0702a8c0@Guides.local> References: <00c501c71da3$c34719c0$0702a8c0@Guides.local> Message-ID: On Dec 11, 2006, Mike Schinkel wrote: > Maybe prefixes aren't the > answer, but I haven't heard an alternate presented. You're presenting an alternative right here: > What about adding additional standard attributes to all > elements. Would it be helpful? This is a question WHATWG needs to answer, preferably without referencing microformats. We're using the same HTML as everyone else. > So I repeat: How then can we achieve a disambiguation conventions > to keep > official Microformats from conflicting with "proto- Microformats?" Assuming you mean disambiguation beyond the "different names for different formats in the same document" solution profile URIs offer, the answer is: We can't; WHATWG can. I think it was a mistake to move this discussion from WHATWG to here, as it's a WHATWG issue (extending HTML for semantics) and not a microformats issue (extending semantics with HTML). Peace, Scott From tantek at cs.stanford.edu Tue Dec 12 08:17:17 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue Dec 12 08:17:13 2006 Subject: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <8ad71be30612112045j351b948eq1a30eeb0fda45a24@mail.gmail.com> Message-ID: Mike, Ben, a gentle reminder, please update the subject line when the subject changes :) On 12/11/06 8:45 PM, "Benjamin West" wrote: > On 12/11/06, Mike Schinkel wrote: >> Benjamin West wrote: >>> I'm not quite sure what you mean here. Is there a difference >>> between lowercase microformats and uppercase microformats? >> >> lowercase microformats = unofficial semantic markup embedded in HTML >> uppercase microformats = "Official" Microformat >> > That's the first I've heard of this usage. Same here. > I think what I'm hearing > (and agree with) is a need for a term that describes the product of > semantic markup techniques in a general way. Lots of people are > already doing this, and don't need any official body to bless them. semantic XHTML (OR semantic HTML) This is well-used well-adopted pre-existing term and there is no need to invent a new term to mean the same thing. > Microformats (any casing) would be a subset of these products that are > blessed by pervasive use across the web. I'm hesitant to pick out > such a name, lest I choose badly (eg AJAX). I'm happy to let the > market pick that name (eg I don't think anyone should deliberately > pick it out.), but at the same time, I'm hesitant to let the term > microformats be applied to general applications of general techniques. I'm frankly not ok with this. This is one of the reasons why I have avoided capitalizing the term "microformats" everywhere it is used. There is no "capital" variant. There is just "microformats", as has been defined. And just as "squares" are "quadrilaterals" with additional constraints, microformats are semantic (X)HTML with additional constraints. In particular, the difference between the specific semantic XHTML technique that is "using semantic class names, ids, rel/rev values" and a "microformat" Is that *anyone* can make up semantic class names, id, rel/rev values, for any reason in any way, and in fact, modern web designers and information architects were doing so *long* before microformats was even coined as a term. Indeed, it was precisely this pre-existing behavior that inspired me to first even dare to propose microformats as a refinement thereof. A "microformat" is such because it is a use of semantic class names, etc. that IN PARTICULAR: 1. Are designed according to microformat principles [1] 2. Follow the microformats process [2] [1] http://microformats.org/wiki/microformats#the_microformats_principles [2] http://microformats.org/wiki/process Without those, all you have is semantic XHTML. I have on my to-do list to better document the principles, more thoroughly, etc., as well as update the process per what we have learned the past six months or so. Perhaps this holiday season I will have to spend some time catching up on this given the extent of this thread. http://microformats.org/wiki/to-do#introduction_.2F_community I will note that for now, much deeper explanations of the principles are actually presented in the numerous podcasts about microformats that have been published: http://microformats.org/wiki/podcasts I encourage everyone who has participated in this thread to listen to them. Thanks, Tantek From tantek at cs.stanford.edu Tue Dec 12 09:17:22 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue Dec 12 09:17:21 2006 Subject: the term microformat and encouraging people to play (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <17790.18963.434124.875426@gargle.gargle.HOWL> Message-ID: On 12/11/06 10:20 PM, "H?kon Wium Lie" wrote: Thanks for chiming in H?kon - your opinion is always appreciated. > Also sprach Mike Schinkel: > >>> I'm not quite sure what you mean here. Is there a difference >>> between lowercase microformats and uppercase microformats? >> >> lowercase microformats = unofficial semantic markup embedded in HTML >> uppercase microformats = "Official" Microformat > > This makes sense to me. Preventing people from using the term > "microformat" for their own set of class names is an uphill battle; It is perhaps, but it is quite similar to the battle that W3C has fought with use of the term "HTML", which, as we both know, was subverted by various vendors etc. during the Browser Wars of the 1990s to mean *their* variant of HTML. Through the hard work of W3C, and advocate organizations like the Web Standards Project (WaSP), that subversion was largely successfully fought and overcome, and popular notion accepts that HTML is what W3C has defines it to be (HTML 4.01, XHTML 1.0). Just as with that uphill battle which was eventually won (except for a few web designers stuck in 1990s-think who think HTML means "what works in IE", ahem, *which* IE? :), it is worth fighting this battle to ensure that microformats keeps its meaning above and beyond "semantic (X)HTML". (Sidenote: ironically, W3C squandered this long fought for victory of what is HTML with the sadness that is XHTML 2.0 which itself inspired/forced the creation of WHATWG and HTML5 efforts, as well as microformats, but that's another thread that an entire other mailing list is handling as you and I both know.) > the term "microformat" is simply too attractive. It's interesting, because I couldn't have predicted this. There was an even earlier term "microcontent" which hinted at some of the same use cases, which however, unfortunately didn't have a precise definition (nor any definition really) that anyone used consistently (everyone used it to mean their pet thing), and thus because its meaning was never clear, its usage became quite diluted and worthless. One of the reasons that I explicitly set about documenting the microformats principles and process very early on in the evolution of microformats was to avoid what happened with "microcontent". This isn't finished. We must continue to insist on a reasonably precise meaningful definition or else the concept itself will become meaningless (or perhaps worse, subverted by major vendors (though the names might be different this time around) as was attempted with HTML). > Besides, people > should be encouraged to play. Agreed - with some clear criticisms when they play for the wrong reasons, or in a bad way. For example there are people who invent their own "microformats" (as they incorrectly call them) who can't even be bothered to publish valid XHTML. If you cannot follow existing standards, how can you possibly expect *anyone* to follow yours? There are also people that are under the mistaken assumption that a microformat they create is for their personal use. I'm not naming names. The point of a standard format is interoperability *between* *different* parties. I'll take that a step further and say that if at least *two* other people (whom you are unrelated to etc.) are not interested in sharing information with each other (i.e. not just you) via your "microformat" proposal besides you, then stop - you have no microformat. Just document (i.e. blog) your own personal use of semantic (X)HTML in the hopes that if someone comes along later and wants to do something similar, they *may* mimic your work. > Most private sets will quickly die a > natural death and do no harm. Those who survive in the wild deserve > the capital M. See previous email from me on "microformats vs. semantic XHTML" first. I strongly encourage people to experiment and document their uses of semantic XHTML. In fact, if you read popular modern web designer blogs, they have been doing this (not just *talking* about it) for *years*. [1] If you want to participate in helping *others* interoperate (not just yourself) and believe you have found a common publishing behavior on the web that can benefit from greater interoperability, then by all means, follow the microformats principles and process and develop a microformat to do so. And those of you that *do* wish to develop microformats, I strongly recommend you subscribe to and read popular modern web designer blogs, as they are the ones who have the most experience with semantic XHTML (far more than anyone in the XML/RDF communities), and they are who you should be reading to understand where microformats came from and how to improve the fidelity of your web publishing in general. [1] Thanks, Tantek [1] In no particular order here are a few (and apologies in advance to those I know I am forgetting this early Tuesday morning with this hastily created list mostly off the top of my mind, and make sure your site validates ;) http://zeldman.com/ http://www.whatdoiknow.org/ http://www.veen.com/jeff/index.html http://www.themaninblue.com/ http://www.stuffandnonsense.co.uk/ http://www.hicksdesign.co.uk/journal/ http://www.cameronmoll.com/ http://www.andybudd.com/ http://www.7nights.com/asterisk/ http://westciv.typepad.com/dog_or_higher/ http://webstandards.org/ http://veerle.duoh.com/ http://stopdesign.com/ http://simplebits.com/ http://simon.incutio.com/ http://sidesh0w.com/ http://molly.com/ http://mezzoblue.com/ http://meyerweb.com/ http://jessey.net/ http://jasonsantamaria.com/ http://edgeofmyseat.com/writing.php http://clagnut.com/ http://brainstormsandraves.com/ http://allinthehead.com/ http://adactio.com/ From ssriram at gmail.com Tue Dec 12 10:40:18 2006 From: ssriram at gmail.com (S. Sriram) Date: Tue Dec 12 10:40:24 2006 Subject: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats) References: Message-ID: <00ec01c71e1c$f9a0a1c0$0367c33f@sitsam> From: "Tantek ? elik" > >> the term "microformat" is simply too attractive. > > It's interesting, because I couldn't have predicted this. There was an > even > earlier term "microcontent" which hinted at some of the same use cases, > which however, unfortunately didn't have a precise definition (nor any > definition really) that anyone used consistently (everyone used it to mean > their pet thing), and thus because its meaning was never clear, its usage > became quite diluted and worthless. > > One of the reasons that I explicitly set about documenting the > microformats > principles and process very early on in the evolution of microformats was > to > avoid what happened with "microcontent". This isn't finished. > > We must continue to insist on a reasonably precise meaningful definition > or > else the concept itself will become meaningless (or perhaps worse, > subverted > by major vendors (though the names might be different this time around) as > was attempted with HTML). > What you have is a 'classic branding problem' i.e. using the category name for the brand name, which is why there are discussions about lower/upper case M mf.org v mf etc. A good book on the subject is Al Ries, Origin of Brands where he outlines numerous examples to support the theory that people think 'first' in 'need' second in 'categories' and than in brands which is why you need two names (category & brand) (As in I'm thirsty (need), I want a beer(category), Give me a Bud Light(brand)) (and all of this happens in the space of a nanosecond) some good examples of categories/brands are: 'energy drink' - red bull 'search' - google 'books online' - amazon some bad examples of categories/brands are: [1] 'video warehouse' - Videowarehouse' (Q.Which is the closest video warehouse? -A. Blockbuster of course) (read pg 251) 'palm computers' - Palm (I don't want to hear music on my laptop, but on a palmtop - so get an iPod) (read pg 232, 233) What ufs(.org) has done is bring about a new category i.e. microformats into the collective mindspace, similar to Palm computers. Without a brand name to go with the category microformats, What will happen, is the Darwinian like splintering of categories into sub categories as in iPod, Zune, BlackBerry etc. [1] For those who don't have the book read pages 232/ 233 using Amazons's search inside feature (keyword: palm computer) at http://www.amazon.com/gp/reader/B00073HH7Y/ref=sib_dp_pt/103-5203347-8643834# S. Sriram From mikes at opera.com Tue Dec 12 11:09:13 2006 From: mikes at opera.com (Michael(tm) Smith) Date: Tue Dec 12 11:09:25 2006 Subject: [uf-discuss] microformats at XTech 2007 (proposals due by December 15) Message-ID: <20061212190910.GD4497@malware> microformats are among the list of suggested topics for XTech 2007 (15-18 May 2007 in Paris, theme: "The Ubiquitous Web"): http://xtech.expectnation.com/event/1/public/content/tracks Proposals for presentations and tutorials at XTech 2007 are due by December 15 (this Friday). http://xtech.expectnation.com/event/1/public/cfp To submit a proposal for either a tutorial or a presentation, you supply a short description (25 words or so) along with an abstract (250 words or so). If you want examples, see the schedule from this year's XTech (which includes the short descriptions and abstracts): http://2006.xtech.org/schedule -- Michael(tm) Smith Opera Software, Tokyo xmpp:smith@sideshowbarker.net From siegfried at rorkvell.de Tue Dec 12 11:13:38 2006 From: siegfried at rorkvell.de (Siegfried Gipp) Date: Tue Dec 12 11:13:19 2006 Subject: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> References: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> Message-ID: <200612122013.38210.siegfried@rorkvell.de> Am Montag, 11. Dezember 2006 20:45 schrieb Tim White: > To address the poster's concerns,

is a block-level element, not > inline, and it is suggested but not mandated. Likewise, skills are > optional, as are linking them. > > At least that's how I read the spec. Anyone see it differently? (I've also > added my answers to the wiki page.) I do read the same. And in fact, not microformats.org suggested

, but the w3c. Microformats is about a vocabulary for some attributes, not about elements. From tantek at cs.stanford.edu Tue Dec 12 11:16:18 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue Dec 12 11:16:19 2006 Subject: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <00ec01c71e1c$f9a0a1c0$0367c33f@sitsam> Message-ID: On 12/12/06 10:40 AM, "S. Sriram" wrote: > What ufs(.org) has done is bring about a new category i.e. microformats > into the collective mindspace, similar to Palm computers. > > Without a brand name to go with the category microformats, > What will happen, is the Darwinian like splintering of categories into sub > categories as in iPod, Zune, BlackBerry etc. The term nor site microformats(.org) did not bring about a new category. The category pre-existed: semantic (X)HTML. "microformats" is the specific "brand" (your term) of semantic (X)HTML that follows the microformats principles and process. You could say that RDFa is another "brand" of semantic (X)HTML that follows its own principles. Tantek From siegfried at rorkvell.de Tue Dec 12 11:19:48 2006 From: siegfried at rorkvell.de (Siegfried Gipp) Date: Tue Dec 12 11:19:29 2006 Subject: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: References: Message-ID: <200612122019.48213.siegfried@rorkvell.de> Am Dienstag, 12. Dezember 2006 17:17 schrieb Tantek ?elik: > >> lowercase microformats = unofficial semantic markup embedded in HTML > >> uppercase microformats = "Official" Microformat There is no such thing as "lowercase microformats". I think that came from the socalled "lowercase semantic web" vs. the "uppercase semantic web". The first is the grassroots movement we all know as microformats, which is not highly official and, most of all, does take a small step approach to semantic web, i.e. not defining a new file format, just adding to an existing format. The socalled "uppercase semantic web" on the other hand is the rdf and owl effort of the w3c, which offers much more, but is hell complicated and defines two completely new file formats. From tantek at cs.stanford.edu Tue Dec 12 11:26:18 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue Dec 12 11:26:16 2006 Subject: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <200612122019.48213.siegfried@rorkvell.de> Message-ID: On 12/12/06 11:19 AM, "Siegfried Gipp" wrote: > Am Dienstag, 12. Dezember 2006 17:17 schrieb Tantek ?elik: > >>>> lowercase microformats = unofficial semantic markup embedded in HTML >>>> uppercase microformats = "Official" Microformat > > There is no such thing as "lowercase microformats". I think that came from the > socalled "lowercase semantic web" vs. the "uppercase semantic web". The first > is the grassroots movement we all know as microformats, which is not highly > official and, most of all, does take a small step approach to semantic web, > i.e. not defining a new file format, just adding to an existing format. The > socalled "uppercase semantic web" on the other hand is the rdf and owl effort > of the w3c, which offers much more, but is hell complicated and defines two > completely new file formats. Well said Siegfried. It's important to remember that bit of history. Thanks, Tantek From joe at andrieu.net Tue Dec 12 11:28:37 2006 From: joe at andrieu.net (Joe Andrieu) Date: Tue Dec 12 11:28:33 2006 Subject: [uf-discuss] Disambiguation Conventions? (was Comments fromIBM/Lotus rep about Microformats) In-Reply-To: <00db01c71dae$7ccaf7e0$0702a8c0@Guides.local> Message-ID: <005701c71e23$b9ae6050$0201a8c0@andrieuhome> > Mike Schinkel wrote: > > Ryan Cannon wrote: > > If the community is slow to develop a format that makes > > sense, we often encourage authors to develop their own > > systems, which then can inform how a format will function in > > the wild. This is where documentation and the oft-belabored > > "process" becomes powerful. Although it can be annoying for > > early-adopters and people who need solutions now, it creates > > strong formats once the issues are solidified. > > Arrgghhh! (he says, frustrated that people address the > tangent to his issue, but don't/won't address his actual issue!) > > So I repeat: How then can we achieve a disambiguation > conventions to keep official Microformats from conflicting > with "proto- Microformats?" Mike, Microformats has no mechanism in place to disambiguate, either amongst its own uFs or between its own and other "non-official" microformats. Tantek wrote: > A "microformat" is such because it is a use of semantic class > names, etc. that IN PARTICULAR: > > 1. Are designed according to microformat principles [1] > > 2. Follow the microformats process [2] > > [1] > http://microformats.org/wiki/microformats#the_microformats_principles > > [2] http://microformats.org/wiki/process Although the process says to use the microformats wiki and mailing list, there is no "official" blessing as both of these media are either unmoderated or "community" moderated. Any user could make recommendations and edits. A team of antagonistic users could hijack it completely. There really is never an "official" version of any given microformat, although there have been statements that eventually their will be when shepharded through a standards body. The only real authority is the autocratic role played by Ryan and Tantek. For example, since it was initially stabilized hCard has been changed to include "place" in its semantics, yet we have no way to let parsers know that the "new" hCards may not be people, companies, or organizations, but instead may also be places. vCards were for /contactable/ entities. hCards changed the semantics to include "locatable" things because the address capability of existing hCards made that convenient. Yet, there is no versioning to disambiguate between these two. That means that once a standards body blesses any particular microformat, it will be locked in stone. I for one think hPlace (or something) should be a separate uF, based on the location-related fields in hCard. Similarly, there is no mechanism to distinguish class names in one hcard from names in another, so we are forced to make sure that the entire namespace is flat and hopefully unique enough from random semantic HTML in the wild. If it looks like a duck and quacks like a duck, you really can't tell if it is a duck, but the parsers will try to treat it like a duck anyhow, even when it is simply semantic HTML that happens to have the same class names as a microformat. The initial concept, as I understand it, was that divergent, namespace-enabled variants are bad. That instead, a community-forged single namespace based on consensus is better. I agree with the intent of the latter. It is good to have a shared tongue. However, I think that goal is compatible with the existence of namespaces (or other disambiguation). Just as having an international language of commerce and science is good (English serves this purpose today), it is also entirely compatible with a world where people are allowed to speak other languages, especially when knowing which language they are using helps you clarify their meaning. I, for one, think we need a mechanism to disambiguate, but I didn't have much success with my early arguments. Apparently I hit a lot of hot-buttons and got shouted down (some of my suggestions were somewhat tangential to this particular point and probably deserved getting shouted down). The idea of disambiguatable namespaces stirs up exhortations against a "Babel"-like profusion of uFs, which apparently would be the end of the world and somehow inherently prevent the forging of the consensus uF namespace. I don't buy that argument, but it is the one that has held sway here since the creation of microformats. That's ok. Microformats are still cool. I just don't think they scale well, which is apparently by design. -j -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 From joe at andrieu.net Tue Dec 12 11:38:29 2006 From: joe at andrieu.net (Joe Andrieu) Date: Tue Dec 12 11:38:27 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <45787E8C.2050203@gmail.com> Message-ID: <005a01c71e25$1a93de30$0201a8c0@andrieuhome> brian suda wrote > It is possible for me to start creating a CSS style called > 'vcard', but a parser would know that this is a style and not > semantics because of the lack of a profile URI. Eventually, > as microformats become more popular, the profile URI is used > to disambiguate random styles with intended semantic values. Brian, As I understand it profile URIs are not required. If so, the parser cannot distinguish between wild semantic HTML and an hCard. Or did I miss a change somehwere? -j -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 From andy at pigsonthewing.org.uk Tue Dec 12 12:27:41 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 12:28:47 2006 Subject: Misc (was: [uf-discuss] Disambiguation Conventions? (was Comments fromIBM/Lotus rep about Microformats)) In-Reply-To: <005701c71e23$b9ae6050$0201a8c0@andrieuhome> References: <00db01c71dae$7ccaf7e0$0702a8c0@Guides.local> <005701c71e23$b9ae6050$0201a8c0@andrieuhome> Message-ID: In message <005701c71e23$b9ae6050$0201a8c0@andrieuhome>, Joe Andrieu writes >Although the process says to use the microformats wiki and mailing >list, there is no "official" blessing as both of these media are either >unmoderated or "community" moderated. It appears that neither is the case, but they seem to be moderated, in effect, by a small group - a clique, or, if you will, a cabal. That /may/ be acceptable, but if it is the case, it should be made explicit. >Any user could make recommendations and edits. But only the above few have the power to revert, then impose their preferred versions by use of blocking and banning. Unlike most people's experience of wikis, such as Wikipedia, there are no (or at least, no explicitly clear-) checks and balances, and no method for ensuring community consensus. [...] >There really is never an "official" version of any given microformat, >although there have been statements that eventually their will be when >shepharded through a standards body. I wonder if such a body would expect what is presented to them or would require an *openly* (and openly documented) democratic and consultative process? > The only real authority is the autocratic role played by Ryan and >Tantek. (!) Which seems to contradict your previous comments, above (and to support mine). >For example, since it was initially stabilized hCard has been changed >to include "place" in its semantics, yet we have no way to let parsers >know that the "new" hCards may not be people, companies, or >organizations, but instead may also be places. This interests me. It's not apparent from the 'wiki' that that's a more recent development. Please can you site links for the relevant discussion? [...] >If it looks like a duck and quacks like a duck, you really can't tell >if it is a duck, but the parsers will try to treat it like a duck >anyhow, even when it is simply semantic HTML that happens to have the >same class names as a microformat. In that respect, class="vcard" is unlikely to exist outside of the hCard microformat (in English, at least - for all I know, vcard could be a word or abbreviation, in some language, for "contact"). But we're in danger of discussing parsing, and isn't that, er, forbidden on this, ahem, unmoderated list? [...] >Microformats are still cool. I just don't think they scale well, which >is apparently by design. In many things, and especially IT specifications, "apparently by design" is dangerous; designed behaviours should be made explicit (or perhaps I should say "expressed honestly"?) -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue Dec 12 12:35:15 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 12:36:55 2006 Subject: [uf-discuss] Microformats: working group vs. meme In-Reply-To: <457EB0D2.20609@municorps.org> References: <457EB0D2.20609@municorps.org> Message-ID: In message <457EB0D2.20609@municorps.org>, Mark Murphy writes >I think what Mr. Schinkel and Mr. Mabbett are running into is the >apparent schism between microformats-as-working-group and >microformats-as-meme. Perhaps, though that hasn't troubled me much, so far. >Microformats.org specifies a process plus a scope delimiter ("paving >the cow paths") which are perfectly reasonable for a working group. In >fact, in many ways, they're exemplary. However, they are more or less >orthogonal to the microformats meme as expressed on the >microformats.org home page: > >"Designed for humans first and machines second, microformats are a set >of simple, open data formats built upon existing and widely adopted >standards." I've never liked that wording, which is vague to the point of being unhelpful. Far better definitions have been provided by members of "the community". [...] >when Mr. Mabbett added unAPI references to the wiki, he was >(presumably) doing so to document a use of the meme; Perhaps - I was certainly doing it allow the community to see what was happening, to debate it, document it and influence it, in an open and equitable manner. >that page was then deleted (presumably) because it wasn't documenting >an action of the working group. Nowhere on the "how to play" page, at the time of my action, was that expressed as a requirement. There are several pages on the wiki now, which do not do so. [...] >-- Limit microformats.org to only those things that follow the process. >In this case, somebody will eventually try to fork the meme, as there >will be those who want to do microformats-esque things that don't fit >the working group, and those microformats-esque things need a name >that's cleaner than "microformats-esque". Even if that path is chosen, documenting, debating and, if necessary , refuting (or even adopting and encompassing) the work of others, such as the initiative I descried, need not be excluded. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From ssriram at gmail.com Tue Dec 12 13:18:29 2006 From: ssriram at gmail.com (S. Sriram) Date: Tue Dec 12 13:18:33 2006 Subject: the term microformat and encouraging people to play (wasRe:[uf-discuss] Comments from IBM/Lotus rep about Microformats) References: Message-ID: <012801c71e33$129860d0$0367c33f@sitsam> From: "Tantek ? elik" > > The term nor site microformats(.org) did not bring about a new category. > > The category pre-existed: semantic (X)HTML. > > "microformats" is the specific "brand" (your term) of semantic (X)HTML > that > follows the microformats principles and process. > > You could say that RDFa is another "brand" of semantic (X)HTML that > follows > its own principles. > Unfortunately, the use of a 'generic' term such as microformats turns it into a 'category', because categories are created by (all the others out there) others and inspired by products. Rather than us extending this debate, I might suggest that you file this away as the reason for the confusion. Solutions are entirely upto you and if you need further reading, besides al ries I might suggest you could also see seth godin's comments on podcasting & rss http://sethgodin.typepad.com/seths_blog/2006/06/being_brave_wit.html S. Sriram From joe at andrieu.net Tue Dec 12 13:46:50 2006 From: joe at andrieu.net (Joe Andrieu) Date: Tue Dec 12 13:46:46 2006 Subject: Misc (was: [uf-discuss] Disambiguation Conventions? (was CommentsfromIBM/Lotus rep about Microformats)) In-Reply-To: Message-ID: <006e01c71e37$08d7e670$0201a8c0@andrieuhome> Andy Mabbett wrote: > In message <005701c71e23$b9ae6050$0201a8c0@andrieuhome>, Joe > Andrieu writes > > > The only real authority is the autocratic role played by Ryan and > >Tantek. > > (!) Which seems to contradict your previous comments, above > (and to support mine). It only contradicts to the point that Ryan and Tantek prevent the wiki and email from operating in a fluid manner. For the most part, our dictators have been pretty reasonable at trying to keep things functional and on topic. Sincerely, I thank all the founding peerage who brought this effort into being. It's amazing what has become of the effort and how useful the output has been. I've mentioned before that as we grow, we will find more and more challenges are best addressed by how we enculturate newcomers. (I don't know if enculturate is a real word, but it fits.) In fact, there is a significant gap in the organizational development behind microformats and the needs of a community of this size. For small groups, social norms and the moral authority of the founders can be an incredibly successful cohesive force. As those groups grow, they inevitably face problems of social scale. Clay Shirky talked about this very eloquently in "A Group Is Its Own Worst Enemy", a speech at ETech, April, 2003.[1] I highly encourage people who care about the growth of microformats to read it. [1] http://www.shirky.com/writings/group_enemy.html This group has done a lot of amazing stuff. But for at least the last six months its been seeing more and more signs of social frustration. Read the article. -j -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 From andy at pigsonthewing.org.uk Tue Dec 12 14:01:02 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 14:02:27 2006 Subject: Profiles was: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <45787E8C.2050203@gmail.com> References: <043901c71a3e$4c7e7940$0702a8c0@Guides.local> <45787E8C.2050203@gmail.com> Message-ID: In message <45787E8C.2050203@gmail.com>, brian suda writes >It is possible for me to start creating a CSS style called 'vcard', but >a parser would know that this is a style and not semantics because of >the lack of a profile URI. Eventually, as microformats become more >popular, the profile URI is used to disambiguate random styles with >intended semantic values. How many of the current examples-in-the wild use a relevant profile? Where, on the Wiki, and in the many on-line tutors, is the use of a profile mandated, or even recommended? Profiles aren't even mentioned on your own cheat-sheet! -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue Dec 12 14:05:53 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 14:07:30 2006 Subject: professional relations (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: <00ac01c71d96$06018010$0702a8c0@Guides.local> References: <00ac01c71d96$06018010$0702a8c0@Guides.local> Message-ID: In message <00ac01c71d96$06018010$0702a8c0@Guides.local>, Mike Schinkel writes >OTOH, I could use any of the following if attached to "professional": >Respect, admire, impressed by,awed, revere, worship, idolize, iconize. >If would be nice if there was a way to extend professional respect and >admiration. Not to mention: mentor, mentee, trainer, trainee, -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From scott at randomchaos.com Tue Dec 12 14:09:08 2006 From: scott at randomchaos.com (Scott Reynen) Date: Tue Dec 12 14:09:22 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <005a01c71e25$1a93de30$0201a8c0@andrieuhome> References: <005a01c71e25$1a93de30$0201a8c0@andrieuhome> Message-ID: <73AC9398-BED2-44DA-B8BF-B12A2EB7BBF5@randomchaos.com> On Dec 12, 2006, at 1:38 PM, Joe Andrieu wrote: > brian suda wrote >> It is possible for me to start creating a CSS style called >> 'vcard', but a parser would know that this is a style and not >> semantics because of the lack of a profile URI. Eventually, >> as microformats become more popular, the profile URI is used >> to disambiguate random styles with intended semantic values. > > Brian, > > As I understand it profile URIs are not required. > > If so, the parser cannot distinguish between wild semantic HTML and an > hCard. Profile URIs are not required for publishers, but parsers are free to ignore HTML without profile URIs, and I think it's reasonable to expect them to start doing that if name conflict becomes more than a hypothetical problem. This mirrors how natural language works. Until there is some need for clarification, we assume everyone knows what we mean. Then there is a need for clarification, we clarify. No one goes around defining every word before they use it, and I don't think we can expect publishers to behave differently with HTML symbols. We could require profile URIs, but that won't make anyone use them. OI think only a practical need for disambiguation will do that. Peace, Scott From bewest at gmail.com Tue Dec 12 14:14:58 2006 From: bewest at gmail.com (Benjamin West) Date: Tue Dec 12 14:15:01 2006 Subject: Misc (was: [uf-discuss] Disambiguation Conventions? (was CommentsfromIBM/Lotus rep about Microformats)) In-Reply-To: <006e01c71e37$08d7e670$0201a8c0@andrieuhome> References: <006e01c71e37$08d7e670$0201a8c0@andrieuhome> Message-ID: <8ad71be30612121414v3c717ea2je7336ea99cad3bd7@mail.gmail.com> > For the most part, our > dictators have been pretty reasonable at trying to keep things > functional and on topic. > Joe, nicely said, and I agree with much of it. However, I thought I would just point out that the the group of administrators does no't consist of just Ryan and Tantek. The administrators of the forum, wiki, and IRC channel are now a wordwide group of volunteers. This is a recent, relatively quiet change, and done to address some of the things you mentioned. Ben PS: Kevin Marks has always been an administrator, but is frequently overlooked. From andy at pigsonthewing.org.uk Tue Dec 12 14:20:56 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 14:22:43 2006 Subject: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: References: <8ad71be30612112045j351b948eq1a30eeb0fda45a24@mail.gmail.com> Message-ID: <$aUFfxeItyfFFwQB@pigsonthewing.org.uk> In message , Tantek ?elik writes >A "microformat" is such because it is a use of semantic class names, >etc. that IN PARTICULAR: > >1. Are designed according to microformat principles [1] > >2. Follow the microformats process [2] Of all the definitions of microformats in circulation, including that on the main uFs web page, I believe that I have yet to see one which makes those stipulations. >Without those, all you have is semantic XHTML. That's one opinion. Another, for example, would be that any set of classes (and rels, or whatever), used by a number of people, with various parsers and aggregators, and marked up examples in the wild, constitute a de facto microformat. The fact that the only such examples at present came about through the current 'wiki'/ mailing list/ 'community' does not preclude it from happening, elsewhere, in the future. >I have on my to-do list to better document the principles, more >thoroughly, etc., as well as update the process per what we have >learned the past six months or so. When you do, will the proposed changes be posted here or on the wiki, for discussion by the 'community', or will they be, in effect, imposed? >I will note that for now, much deeper explanations of the principles >are actually presented in the numerous podcasts about microformats that >have been published: > >http://microformats.org/wiki/podcasts > >I encourage everyone who has participated in this thread to listen to >them. Where are their text transcriptions? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue Dec 12 14:29:02 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 14:32:42 2006 Subject: Upper and lower case microformats (was: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <00cc01c71da6$a454b560$0702a8c0@Guides.local> References: <8ad71be30612092223u33771c78gd9d481be03249227@mail.gmail.com> <00cc01c71da6$a454b560$0702a8c0@Guides.local> Message-ID: In message <00cc01c71da6$a454b560$0702a8c0@Guides.local>, Mike Schinkel writes >lowercase microformats = unofficial semantic markup embedded in HTML >uppercase microformats = "Official" Microformat Does: "HTML is good. Microformats are wonderful" refer to the former, or the latter? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue Dec 12 14:35:50 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 14:37:21 2006 Subject: [uf-discuss] More reverts on the 'wiki' Message-ID: I added what I thought was some helpful guidance to the 'wiki' page about this mailing list, a few hours ago: Once again, Tantek reverted it quite quickly, with no explanation other than: Reverted edit of AndyMabbett, changed back to last version by Tantek which was not fully honest, since he actually reverted another, earlier edit by me at the same time. I'm confident that I didn't breach any of the then-current guidelines for the 'wiki'; if I did, please feel free to point out which. He then added a note about the guidelines being intended to increase signal-to-noise ratio, so I re-added my comment, with an additional clause pointing out how my suggestion would itself help to increase signal-to-noise ratio. He reverted this again, almost immediately: with the same edit summary as above, then added the instruction: If you have suggestions for general guidelines, please post them to the microformats-discuss list so that the list-admins may consider your suggestions. (Note that's "list-admins may consider" not "the community may consider". Note also that none of Tantek's recent additions to these guidelines has been offered up for discussion on the mailing list.) Are the "community" happy for extra restrictions to be added to the 'wiki' in this unilateral way? Or is the "community's" ownership of work on microformats and its 'wiki' a myth? As I said a couple of days ago: If there is an autocracy (or some other non-community based management system) here, then surely it should be openly and honestly documented? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From drernie at opendarwin.org Tue Dec 12 14:48:47 2006 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Tue Dec 12 14:48:48 2006 Subject: [uf-discuss] More reverts on the 'wiki' In-Reply-To: References: Message-ID: <3A08BECF-7E66-4D20-8F17-3EF69DF9FFD6@opendarwin.org> Hi Andy, On Dec 12, 2006, at 2:35 PM, Andy Mabbett wrote: > Are the "community" happy for extra restrictions to be added to the > 'wiki' in this unilateral way? Or is the "community's" ownership of > work > on microformats and its 'wiki' a myth? Speaking for myself, I am grateful for Tantek's leadership (as well as that of Ryan and Kevin). I don't always agree with his decisions, but having run various mailing lists myself over the years I know how difficult the task is, and so far I haven't really seen anything I consider completely inappropriate -- including the examples you cite. I'm able to do what I need to do, and I've learned to live within the boundaries that Tantek and the others have established. If I ever want to do something beyond those boundaries, I think it only fair that I do the hard work of creating my *own* community. -- Ernie P. From mikeschinkel at gmail.com Tue Dec 12 14:52:25 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Tue Dec 12 14:52:28 2006 Subject: [uf-discuss] Regarding Profile URIs and Disambiguation (was Comments from IBM/Lotus rep about Microformats) In-Reply-To: <45787E8C.2050203@gmail.com> Message-ID: <016801c71e40$31cb8470$0702a8c0@Guides.local> brian suda wrote: > It is possible for me to start creating a CSS style called > 'vcard', but a parser would know that this is a style and not > semantics because of the lack of a profile URI. Eventually, > as microformats become more popular, the profile URI is used > to disambiguate random styles with intended semantic values. Thanks for the reply. Someone previously mentioned to me on this list that Profile URIs were a solution. Yet when I asked about them I interpreted the answer that I got back to indicate they allowed a specific microformat to be identified, but not to have two or more to be explicitly disambiguated. Since I apparently misunderstood how Profile URIs work, can you please mark up my example, repeated below [1], to indicate how a Profile URI might be used to disambiguate my example? I would definitely appreciate it. > So far this isn't a problem, and to save time and effort we > are focusing on the more important things. I do appreciate the need to prioritize; I can really empathize with that. However, please understand that I am working on a project where disambiguation IS a problem (a major problem, actually.) > microformats are not "squatting" on terms. Forgive me if I used a term that came across as distasteful; that was not my intention. Nonetheless microformats do make use of a scare resource, that being the HTML "class" attribute and a few other attributes. Hence there is an inherent likelihood of name clashes that can render an HTML content author unable to use two conflicting microformats in the same document unless of course Profile URI resolves those ambiguities. I do look forward to your clarification on Profile URIs. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] Looking at ADR, here is an example:

665 3rd St.

Suite 207

San Francisco, CA 94107

U.S.A.

Now let's say I want to use something called "RegionData" where Regions are heirarchical:

665 3rd St.; Suite 207

San Francisco, CA 94107

U.S.A.

Now, someone needs to use both:

665 3rd St.

Suite 207

San Francisco, CA 94107

U.S.A.

How to disambiguate with Profile URI? (Please make the assumption that the developer of region-data knew nothing of vcard when region-data was published.) From scott at randomchaos.com Tue Dec 12 15:43:14 2006 From: scott at randomchaos.com (Scott Reynen) Date: Tue Dec 12 15:43:27 2006 Subject: [uf-discuss] Regarding Profile URIs and Disambiguation (was Comments from IBM/Lotus rep about Microformats) In-Reply-To: <016801c71e40$31cb8470$0702a8c0@Guides.local> References: <016801c71e40$31cb8470$0702a8c0@Guides.local> Message-ID: <838ABC98-D040-4B2D-B08D-AD962EAFE31E@randomchaos.com> On Dec 12, 2006, at 4:52 PM, Mike Schinkel wrote: >

665 3rd St.

Suite 207

> San > Francisco, > CA > > 94107 >

title="child-of-continent">U.S.A.

> > How to disambiguate with Profile URI? (Please make the assumption > that the > developer of region-data knew nothing of vcard when region-data was > published.) As I've said before, I don't think this kind of same name, same document, different meaning conflict is solved by profile URIs (because they don't have namespaces). But I also think it's both a rare and a bad practice to use one symbol to communicate two different ideas in a single context. Nonetheless, in the interest of ending this discussion, here's what you can do to solve this problem whenever you encounter it: 1) add profiles for both vcard and region-data, e.g.: 2) add prefixes to all your region-data tags when you decide to add the conflicting hCard names, e.g.: San 3) designate that prefix in a meta tag, e.g.: (where * indicates no prefix for hcard) 4) convince developers of region-data parsers to look for prefixes Note this won't require any changes to hCard. Now you can go crazy with your double entendre markup and this list can move on with developing microformats to solve specific problems. Sound good? Peace, Scott From jude at dotcode.com Tue Dec 12 15:47:56 2006 From: jude at dotcode.com (Jude Robinson) Date: Tue Dec 12 15:48:01 2006 Subject: Profiles was: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: References: <043901c71a3e$4c7e7940$0702a8c0@Guides.local> <45787E8C.2050203@gmail.com> Message-ID: <457F3FAC.5020502@dotcode.com> Andy Mabbett wrote: > > Where, on the Wiki [...] is the use of a > profile mandated, or even recommended? http://microformats.org/wiki/xmdp-faq From angus at pobox.com Tue Dec 12 15:49:14 2006 From: angus at pobox.com (Angus McIntyre) Date: Tue Dec 12 15:49:17 2006 Subject: professional relations (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: References: <00ac01c71d96$06018010$0702a8c0@Guides.local> Message-ID: <4370.66.17.182.210.1165967354.squirrel@webmail.nomadcode.com> On Tue, December 12, 2006 5:05 pm, Andy Mabbett wrote: > In message <00ac01c71d96$06018010$0702a8c0@Guides.local>, Mike Schinkel > writes > >>OTOH, I could use any of the following if attached to "professional": >>Respect, admire, impressed by,awed, revere, worship, idolize, iconize. >>If would be nice if there was a way to extend professional respect and >>admiration. > > Not to mention: mentor, mentee, trainer, trainee, I wonder if idolizing someone is in some way analogous to a VoteLinks vote-for. If we start encoding not only hierarchical relations but expressions of approval/disapproval, you have the possibility to write some extremely career-limiting XFN expressions. ... and ... are two that might not do you any good in the workplace ... Angus From andy at pigsonthewing.org.uk Tue Dec 12 15:55:45 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 15:57:21 2006 Subject: Profiles was: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: <457F3FAC.5020502@dotcode.com> References: <043901c71a3e$4c7e7940$0702a8c0@Guides.local> <45787E8C.2050203@gmail.com> <457F3FAC.5020502@dotcode.com> Message-ID: In message <457F3FAC.5020502@dotcode.com>, Jude Robinson writes >Andy Mabbett wrote: >> Where, on the Wiki [...] is the use of a >> profile mandated, or even recommended? > >http://microformats.org/wiki/xmdp-faq Well, that's nice and accessible, and clearly flagged for newbie uF-users, isn't it? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue Dec 12 16:00:26 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 12 16:12:16 2006 Subject: unwise personal relationships (was: professional relations (was: XFN usage stats and Re:[uf-discuss] rel="muse" implies romantic relationship?)) In-Reply-To: <4370.66.17.182.210.1165967354.squirrel@webmail.nomadcode.com> References: <00ac01c71d96$06018010$0702a8c0@Guides.local> <4370.66.17.182.210.1165967354.squirrel@webmail.nomadcode.com> Message-ID: In message <4370.66.17.182.210.1165967354.squirrel@webmail.nomadcode.com>, Angus McIntyre writes >If we start encoding not only hierarchical relations but expressions of >approval/disapproval, you have the possibility to write some extremely >career-limiting XFN expressions. > > ... > >and > > ... > >are two that might not do you any good in the workplace ... I should think that: ... might cause some trouble, too! ;-) -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From microformats at 200ok.com.au Tue Dec 12 20:35:49 2006 From: microformats at 200ok.com.au (Ben Buchanan) Date: Tue Dec 12 20:35:53 2006 Subject: unwise personal relationships (was: professional relations (was: XFN usage stats and Re:[uf-discuss] rel="muse" implies romantic relationship?)) In-Reply-To: References: <00ac01c71d96$06018010$0702a8c0@Guides.local> <4370.66.17.182.210.1165967354.squirrel@webmail.nomadcode.com> Message-ID: <6ca82b0f0612122035i4a060ed1xab61cddb653c3a2b@mail.gmail.com> > I should think that: > ... > might cause some trouble, too! ;-) It would probably have a reciprocal: ... ;) -- --- --- The future has arrived; it's just not --- evenly distributed. - William Gibson From joe at andrieu.net Tue Dec 12 23:28:04 2006 From: joe at andrieu.net (Joe Andrieu) Date: Tue Dec 12 23:28:00 2006 Subject: Misc (was: [uf-discuss] Disambiguation Conventions? (wasCommentsfromIBM/Lotus rep about Microformats)) In-Reply-To: <8ad71be30612121414v3c717ea2je7336ea99cad3bd7@mail.gmail.com> Message-ID: <001501c71e88$3b650450$0201a8c0@andrieuhome> Benjamin West wrote: > Joe, nicely said, and I agree with much of it. However, I > thought I would just point out that the the group of > administrators does no't consist of just Ryan and Tantek. The > administrators of the forum, wiki, and IRC channel are now a > wordwide group of volunteers. This is a recent, relatively > quiet change, and done to address some of the things you mentioned. > > > Ben > > PS: Kevin Marks has always been an administrator, but is > frequently overlooked. Thanks, Ben. I'm glad to hear of the development. I've been through the growing pains of more than one community-based non-profit and it can be a delicate situation. And as someone who has his hands too full right now to do more than shout out a few (hopefully) helpful comments now and then, I particularly appreciate those of you who have stepped up to contribute on a more meaningful level. Thanks for the pick up on Kevin, also. I didn't mean to leave him out; rather, I was simply echoing Tantek's response to Andy: Tantek wrote: >Andy wrote: >> If there is an autocracy (or some other non-community based management >> system) here, then surely it should be openly and honestly documented? > >I am an admin on this list/site as is Ryan King. I've been in situations where the hand over from autocratic founders to community/democracy/mob rule happened way too soon. Given your comment Ben, I'd say perhaps microformats isn't as far behind the curve as I thought. One of Clay Shirky's [1] observations is that once a group grows beyond its consensus cultural norms, it needs a mechanism for the body politic to formally define and modify how it makes decisions, in part so that those norms can evolve with the community. Microformats has avoided formalizing such mechanisms, but I believe they will eventually become necessary to transfer from the autocracy through the cabal to a true community representative governance. I know a lot of folks don't want to think about that, but Shirky makes compelling arguments that well-crafted governance is better than the collapse of a dictatorship grown beyond its moral authority. To reach that well-crafted governance will take effort and time. I believe it would be effort invested wisely, especially if we take the time to openly evaluate and consider different alternatives, rather than rushing in to a solution in the face of a crisis or arbitrarily without community input. Not that there is a crisis, just that taking our time to figure out a fair, effective, and lightweight governance mechanism will, IMNSHO, pay long term dividends. And the work itself--figuring it out sooner rather than later--can provide balm for those who would like to see the end result of a more democratic system and are currently frustrated when our benevolent dictators seem more heavy handed than one might desire. Actually, we are seeing this happen as we speak in the Identity community, where at least two new non-profits are forming from previously ad-hoc collaboration: OpenID[1] and Identity Commons[2] are formalizing into non-profit corporate entities. It is a cool thing to see some concrete, legal bodies forming out of that wellspring of community effort. If I may be so bold to say so, perhaps something similar lies somewhere in microformats' future. A second pitch for Shirky[1]: It's an easy read and might provide productive food for thought. Cheers, -j [1] http://www.shirky.com/writings/group_enemy.html [2] http://openid.net/ [3] http://www.identitycommons.net/ -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 From joe at andrieu.net Tue Dec 12 23:40:19 2006 From: joe at andrieu.net (Joe Andrieu) Date: Tue Dec 12 23:41:16 2006 Subject: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats] In-Reply-To: <73AC9398-BED2-44DA-B8BF-B12A2EB7BBF5@randomchaos.com> Message-ID: <001601c71e8a$15fcd600$0201a8c0@andrieuhome> Scott Reynen wrote: > On Dec 12, 2006, at 1:38 PM, Joe Andrieu wrote: > > As I understand it profile URIs are not required. > > > > If so, the parser cannot distinguish between wild semantic > HTML and an > > hCard. > > Profile URIs are not required for publishers, but parsers are > free to > ignore HTML without profile URIs, and I think it's reasonable to > expect them to start doing that if name conflict becomes more than a > hypothetical problem. This mirrors how natural language works. > Until there is some need for clarification, we assume everyone knows > what we mean. Then there is a need for clarification, we clarify. > No one goes around defining every word before they use it, and I > don't think we can expect publishers to behave differently with HTML > symbols. We could require profile URIs, but that won't make anyone > use them. OI think only a practical need for disambiguation will do > that. Making people use them is not the same as clarifying in a spec what should be done, must be done, and what is optional. If we are specifying that parsers can ignore non-profiled semantic HTML that looks like microformats, we are essentially saying parsers can ignore non-profiled microformats, since you can't tell the difference. Which means that URI profiles are /effectively/ required if you want to be assured that standards-compliant parsers will pick them up your microformats. Yea! I think profiles are great. So, why not formalize the requirement? If authors write non-compliant code (without the profile), *GASP*--who would ever do that?--then they will have reason to understand why the parsers ignore it. Just like if they write non-compliant HTML, they can understand why it doesn't work. (Ahem, we'll ignore the issue of non-compliant browsers). However, without the profile requirement, authors have no reason to expect that parsers won't pick up their "standards-compliant" microformats. 100% compliant code should work with 100% compliant parsers. That seems self-evident. Does it make sense to allow compliant parsers to ignore compliant microformats? -j -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 From fberriman at gmail.com Wed Dec 13 00:47:48 2006 From: fberriman at gmail.com (Frances Berriman) Date: Wed Dec 13 00:47:52 2006 Subject: professional relations (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: <4370.66.17.182.210.1165967354.squirrel@webmail.nomadcode.com> References: <00ac01c71d96$06018010$0702a8c0@Guides.local> <4370.66.17.182.210.1165967354.squirrel@webmail.nomadcode.com> Message-ID: On 12/12/06, Angus McIntyre wrote: > On Tue, December 12, 2006 5:05 pm, Andy Mabbett wrote: > > In message <00ac01c71d96$06018010$0702a8c0@Guides.local>, Mike Schinkel > > writes > > > >>OTOH, I could use any of the following if attached to "professional": > >>Respect, admire, impressed by,awed, revere, worship, idolize, iconize. > >>If would be nice if there was a way to extend professional respect and > >>admiration. > > > > Not to mention: mentor, mentee, trainer, trainee, > > I wonder if idolizing someone is in some way analogous to a VoteLinks > vote-for. > > If we start encoding not only hierarchical relations but expressions of > approval/disapproval, you have the possibility to write some extremely > career-limiting XFN expressions. > > ... > > and > > ... > > are two that might not do you any good in the workplace ... > > Angus I agree. It's an amusing situation, but possibly a bit personal! Adding additional attribute values seems a bit like splitting hairs to me. What exists at the moment is a generalised, but for the most part adequate list of types that describe in a loose terms (so as not to be restrictive) just about any relationship a person is likely to have. There are probably merits to adding a couple more, but I'm not sure adding every single explicit type of relationship has any extra value. Infact, adding too many additional terms starts to water down the effect and would no doubt make creating useful maps of information from these relationships difficult. F -- Frances Berriman http://fberriman.com From mail at ciaranmcnulty.com Wed Dec 13 01:11:21 2006 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Wed Dec 13 01:11:24 2006 Subject: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> References: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> Message-ID: On 12/11/06, Tim White wrote: > To address the poster's concerns,

is a block-level element, not inline, This would seem to contradict that? http://www.w3.org/TR/html4/struct/global.html#h-7.5.6 I've stayed away from using

on some of my pages precisely because of this, so I'd be delighted to find I'd read it wrong! -Ciaran McNulty From mail at ciaranmcnulty.com Wed Dec 13 01:17:37 2006 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Wed Dec 13 01:17:44 2006 Subject: professional relations (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: References: <00ac01c71d96$06018010$0702a8c0@Guides.local> Message-ID: On 12/12/06, Andy Mabbett wrote: > Not to mention: mentor, mentee, trainer, trainee, I would suspect that mentor, trainer would suffice, with then @rev="mentor" and @rev="trainer" providing the reciprocal relationships. This would also help in that parsers could 'trust' @rev relationships less than @rel (which I believe has been mooted in the vote-for discussions), because the statement 'this person is my mentor' is pretty irrefutable but saying 'this person is my mentee' probably needs a bit of extra vertification. I can think of a few people I'd like to link to with @rev="object-of-lust", otherwise ;-) -Ciaran McNulty From siegfried at rorkvell.de Wed Dec 13 01:30:39 2006 From: siegfried at rorkvell.de (Siegfried Gipp) Date: Wed Dec 13 01:30:28 2006 Subject: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: References: Message-ID: <200612131030.39523.siegfried@rorkvell.de> Am Dienstag, 12. Dezember 2006 20:16 schrieb Tantek ?elik: > "microformats" is the specific "brand" (your term) of semantic (X)HTML that > follows the microformats principles and process. > > You could say that RDFa is another "brand" of semantic (X)HTML that follows > its own principles. Just to be complete: Simply to use the html elements for what they where designed for is at least the first step to semantic (x)html. Even more important than microformats and RDFa. If used properly, any single bit of html markup _is_ semantic markup. And, last not least, the rdf and owl effords of the w3c is semantic web, too, although it has nothing to do with (x)html. But well, the web is not identical to (x)html! regards Siegfried From siegfried at rorkvell.de Wed Dec 13 01:33:33 2006 From: siegfried at rorkvell.de (Siegfried Gipp) Date: Wed Dec 13 01:33:11 2006 Subject: Upper and lower case microformats (was: [uf-discuss] Comments from IBM/Lotus rep about Microformats) In-Reply-To: References: <8ad71be30612092223u33771c78gd9d481be03249227@mail.gmail.com> <00cc01c71da6$a454b560$0702a8c0@Guides.local> Message-ID: <200612131033.33350.siegfried@rorkvell.de> Am Dienstag, 12. Dezember 2006 23:29 schrieb Andy Mabbett: > In message <00cc01c71da6$a454b560$0702a8c0@Guides.local>, Mike Schinkel > writes > > >lowercase microformats = unofficial semantic markup embedded in HTML > >uppercase microformats = "Official" Microformat > > Does: > > "HTML is good. Microformats are wonderful" > > refer to the former, or the latter? Although this statement is correct, it does neither refer to the former nor to the latter, because both are nonsense :) regards Siegfried From siegfried at rorkvell.de Wed Dec 13 01:37:26 2006 From: siegfried at rorkvell.de (Siegfried Gipp) Date: Wed Dec 13 01:37:05 2006 Subject: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: References: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com> Message-ID: <200612131037.27095.siegfried@rorkvell.de> Am Mittwoch, 13. Dezember 2006 10:11 schrieb Ciaran McNulty: > On 12/11/06, Tim White wrote: > > To address the poster's concerns,

is a block-level element, not > > inline, > > This would seem to contradict that? > http://www.w3.org/TR/html4/struct/global.html#h-7.5.6 > > I've stayed away from using

on some of my pages precisely > because of this, so I'd be delighted to find I'd read it wrong! > > -Ciaran McNulty

is an element designed to contain contact information. So if you want to include contact information use

. That is indepenent of using hCard or not.

is a html element, specified by the w3c, hCard is an attribute vocabulary, designed by microformats. You can pretty well use both together. In fact, microformats is designed in that way: To be used together with html. regards Siegfried From mail at ciaranmcnulty.com Wed Dec 13 02:06:21 2006 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Wed Dec 13 02:06:25 2006 Subject: Microformats *do* seek to change behaviour (was: XFN usage stats and Re: [uf-discuss] rel="muse" implies romantic relationship?) In-Reply-To: <200612131037.27095.siegfried@rorkvell.de> References: <20061211194515.33116.qmail@web30801.mail.mud.yahoo.com>

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion > agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion >agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion > agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Theridion agrifoliae Levi, 1957

Employees

Microformats FAQ

<div> and >span> semantics

Microformats FAQ

<div> and >span> semantics

Microformats FAQ

<div> and >span> semantics

Is he really?