From james at atomless.com Mon Nov 3 07:16:35 2008 From: james at atomless.com (James Tindall) Date: Mon Nov 3 07:17:40 2008 Subject: [uf-discuss] permatime using microformats Message-ID: <490F15D3.4030603@atomless.com> Hello all, Any of you seen http://permatime.com/ ? Apart from taking the confusion out of sharing points in time accross timezones, it also turns out to be a very handy way of generating an hcalendar event. One of the co-creators also comes up with a very nice plain english (what and why) explanation of microformats in this blog post: http://blog.kohlhofer.com/ James From loertsch.thomas at guj.de Wed Nov 5 04:50:46 2008 From: loertsch.thomas at guj.de (Thomas Loertsch) Date: Wed Nov 5 04:50:58 2008 Subject: [uf-discuss] hRecipe #2 Message-ID: Hi, I've incorporated some comments from the wiki into my proposal from october 08 on hrecipe brainstorming. I'd really appreciate feedback from everybody since we'll soon implement the format on our site. Though it's not a major problem to change templates at a later state it still would be nice to take this chance to reach consensus on some more topics - maybe :-) Cheers, Thomas . Thomas L?rtsch Living at Home Multi Media GmbH Redaktion Online .. Stubbenhuk 5 20459 Hamburg ... eMail: loertsch.thomas@guj.de From lists at ben-ward.co.uk Thu Nov 6 01:53:23 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Thu Nov 6 01:53:44 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern Message-ID: Hi everyone. So, a few months ago I was working on the ongoing value-excerption- pattern specification. Then I moved to San Francisco and my work went a little stagnant, but I'm trying to pick it up again. The value-excerption-pattern is an attempt to fully spec the class="value" behaviour from "tel" in hCard, which has since been supported globally in some parsers for a while, and has proved somewhat useful. In addition to fully spec'ing the behaviour for parsing class="value" elements for visible data, I've been working on additional specification to handle inclusion of machine-centric data alongside human forms (http://microformats.org/wiki/machine-data). It's this machine-centic portion that I'm trying to nail down at the moment, since it would provide an in-demand solution for various recurring complaints (abbr-pattern dependencies, for example). Also, note that recent brainstorming regarding patterns dervice from the semantics of the element and value excerption has shown that current, in-use browsers (Microsoft Internet Explorer and Apple's Safari 2) do not handle object acceptably for inline content (http://microformats.org/wiki/value-excerption-pattern-brainstorming#object_param_handling ). So we're definitely stuck with needing to spec this pattern using generic mark-up. (http://microformats.org/wiki/value-excerption-pattern-brainstorming#object_param_handling ) Since it's been a while, this mail serves to summarise the current state of this spec and proposed resolutions to open issues. PLEASE, if you have additional issues to raise, add them to the wiki page (http://microformats.org/wiki/value-excerption-pattern-issues#Parsing_title_from_Empty_value_Elements ) Couple of Examples: ---------------------------- 11:25pm, August 27th 2008

Mobile 415-123-4567

Purpose ----------- This pattern allows you to embed fixed format content ? such as the telephone type enumeration and parser-required data formats ? alongside the visible format of the publisher's choice. Responses to Issues so Far -------------------------------------- 1. DRY Violation worse than current ABBR-pattern. DRY is a problem when data is repeated in a document and risks one copy of the data not being maintained in sync with another. Maintenance of the document results in broken data. Resolution: To address this, the empty-span part of the value excerption pattern will specify that the empty-span MUST be the first, non-whitespace-text-node child of the property element. Thus, this will parse: 4th November But this will fail: On 4th November 2008 Barack Obama was elected the first African American president of the United States of American. He was really pleased about it. The first pattern keeps the code distance small between the data form (class=value) and the property name (class=dtstart). It disallows the machine-data portion from being separated from the property. Furthermore, the spec should encourage conformance checking tools to attempt to verify the machine date form against the human form and warn the user if they data does not match. 2. Violating the principal of visible data Resolution: Microformats maintain a principal of marking up visible data. However, we have exceptional circumstances where the data required for parsing is not the data that publishers wish to display. Whilst parsers are a lower priority than publishers, the cost and complexity of parsing unstructured dates, or translated terms, is accepted as too high. Therefore it is necessary to violate DRY to include explicit representations for machines. Currently authors may use CSS to hide the machine-form of dates. Microformats exists only in the HTML layer, and must not depend on CSS to meet publisher requirements. The specification may also restrict this part of the pattern to certain properties where a machine-data form is required, as a means to discourage abuse. 3. Broken parsers drop empty elements There are some broken but widespread HTML parsers which discard empty elements, resulting in the empty-span-value element being removed from documents (e.g. HTMLTIdy). HTMLTidy is easily patched not to do this, but may already exist in publishing platforms. Resolution: Without numbers, we don't know how many publishing systems would be affected but this. It's a problem for which the only resolution is to use a completely different pattern. As such, this proposal must put legacy broken parsers down as an accepted loss. CMS's locked to old versions of HTML Tidy would not be able to use this pattern without modification. So, there aren't many issues against this part of the pattern, and the rules for it are coming together. There's likely some feeling about matters of taste as to how to achieve this function. This is my favoured version, but a lot of the issues resolved here would apply equally to other patterns too, so I'd appreciate further input to see if this pattern can be thoroughly specified. Please, if you have problems to raise with this proposal, add them to the -issues page on the wiki at: http://microformats.org/wiki/value-excerption-pattern-issues#Parsing_title_from_Empty_value_Elements Thank you, Ben From robertc at gmail.com Fri Nov 7 07:09:44 2008 From: robertc at gmail.com (Rob Crowther) Date: Fri Nov 7 07:15:20 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: References: Message-ID: <3ce2ebd20811070709t74f2257m409e0caefb9abd@mail.gmail.com> 2008/11/6 Ben Ward : > Thus, this will parse: > > 4th > November > > But this will fail: > > On 4th November 2008 Barack Obama was elected the > first African American president of the United States of American. He was > really pleased about it. > > I'm not sure I understand the benefit here - will this also parse? Barack Obama was elected the first African American president of the United States of American, and he was really pleased about it, on 4th November 2008 Rob From andr3.pt at gmail.com Fri Nov 7 08:38:39 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Fri Nov 7 08:38:42 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: References: Message-ID: Hi Ben, Thanks for bringing this up. We need to tackle this, once and for all. So guys, pitch in and let's try to keep discussion open and towards a solution. On Thu, Nov 6, 2008 at 9:53 AM, Ben Ward wrote: > 2. Violating the principal of visible data > > Resolution: Microformats maintain a principal of marking up visible data. > However, we have exceptional circumstances where the data required for > parsing is not the data that publishers wish to display. Whilst parsers are > a lower priority than publishers, the cost and complexity of parsing > unstructured dates, or translated terms, is accepted as too high. Therefore > it is necessary to violate DRY to include explicit representations for > machines. +1 Empty spans is quite different than empty links (anorexic links, banned by posh principles)... > > Currently authors may use CSS to hide the machine-form of dates. > Microformats exists only in the HTML layer, and must not depend on CSS to > meet publisher requirements. > > The specification may also restrict this part of the pattern to certain > properties where a machine-data form is required, as a means to discourage > abuse. > > 3. Broken parsers drop empty elements > About this, I can only think of one little issue, something that we are bound to run into down the road. The WYSIWYG editors for easier authoring of microformatted content. There still aren't many out there, but I think most editors at the moment wouldn't show these empty spans, thus not allowing the user to change its value. One could argue that when someone actually extends an editor to support creating of microformats, it would be aware of these empty spans and render them in a visible fashion, but we need to take into account the general distributions out there of those editors. I've added this issue to the wiki and I hope I can test some of them soon. Anyone has some insight about this? > So, there aren't many issues against this part of the pattern, and the rules > for it are coming together. There's likely some feeling about matters of > taste as to how to achieve this function. This is my favoured version, but a > lot of the issues resolved here would apply equally to other patterns too, > so I'd appreciate further input to see if this pattern can be thoroughly > specified. I can see this option being adopted by people who are concerned about accessibility, while others might just go ahead and use the regular-problem-maker-of-a-pattern the datetime design pattern, preferring simplicity over accessibility. Right? -- Andr? Lu?s From scott at randomchaos.com Fri Nov 7 08:15:37 2008 From: scott at randomchaos.com (Scott Reynen) Date: Fri Nov 7 08:47:06 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: <3ce2ebd20811070709t74f2257m409e0caefb9abd@mail.gmail.com> References: <3ce2ebd20811070709t74f2257m409e0caefb9abd@mail.gmail.com> Message-ID: <4921D75F-2818-4E30-9CB3-8E66F7A2AE02@randomchaos.com> On [Nov 7], at [ Nov 7] 8:09 , Rob Crowther wrote: >> Thus, this will parse: >> >> > span>4th >> November >> >> But this will fail: >> >> On 4th November 2008 Barack Obama was elected >> the >> first African American president of the United States of American. >> He was >> really pleased about it. > span> >> >> > I'm not sure I understand the benefit here As Ben wrote: > DRY is a problem when data is repeated in a document and risks one > copy of the data not being maintained in sync with another. The benefit is to minimize this problem. > will this also parse? > > Barack > Obama was elected the > first African American president of the United States of American, > and he was > really pleased about it, on 4th November 2008 > Not as a valid dtstart value, no. The title attribute is only parsed when the value element is empty, so that would parse with an invalid dtstart value containing the entire sentence. See: http://microformats.org/wiki/value-excerption-pattern-issues#Parsing_title_from_Empty_value_Elements Peace, Scott From tantek at cs.stanford.edu Fri Nov 7 10:30:08 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Fri Nov 7 10:30:12 2008 Subject: value excerption pattern brainstorming general appeal for issues (was Re: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern) Message-ID: <60cb038a0811071030t482731denb79243a8645342d3@mail.gmail.com> On Thu, Nov 6, 2008 at 1:53 AM, Ben Ward wrote: > Hi everyone. > > The value-excerption-pattern is an attempt to fully spec the class="value" > behaviour from "tel" in hCard, which has since been supported globally in > some parsers for a while, and has proved somewhat useful. In addition to > fully spec'ing the behaviour for parsing class="value" elements for visible > data, I've been working on additional specification to handle inclusion of > machine-centric data alongside human forms > (http://microformats.org/wiki/machine-data). > > It's this machine-centic portion that I'm trying to nail down at the moment, > since it would provide an in-demand solution for various recurring > complaints (abbr-pattern dependencies, for example). > > Also, note that recent brainstorming regarding patterns dervice from the > semantics of the element and value excerption has shown that > current, in-use browsers (Microsoft Internet Explorer and Apple's Safari 2) > do not handle object acceptably for inline content > (http://microformats.org/wiki/value-excerption-pattern-brainstorming#object_param_handling). > So we're definitely stuck with needing to spec this pattern using generic > mark-up. > (http://microformats.org/wiki/value-excerption-pattern-brainstorming#object_param_handling) I agree, gathering feedback on both existing value excerption pattern behavior and new value excerption handling brainstorms/proposals, and resolving issues, is a very important next step in improving nearly all class-based microformats. One document organizational point: We should move all brainstormed/proposed additions to the value excerption pattern to the brainstorming page: http://microformats.org/wiki/value-excerption-pattern-brainstorming And then evaluate them all for inclusion in an iteration of the value excerption pattern itself, rather than evaluate them just one at a time. > Since it's been a while, this mail serves to summarise the current state of > this spec and proposed resolutions to open issues. PLEASE, if you have > additional issues to raise, add them to the wiki page > (http://microformats.org/wiki/value-excerption-pattern-issues#Parsing_title_from_Empty_value_Elements) Since this is an *addition* to current value excerption behavior, I think the documentation of the addition should first be moved to: http://microformats.org/wiki/value-excerption-pattern-brainstorming And then issues documented with the proposal inline there. Thanks, Tantek -- http://tantek.com/ From robertc at gmail.com Fri Nov 7 11:40:54 2008 From: robertc at gmail.com (Rob Crowther) Date: Fri Nov 7 11:40:58 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: <4921D75F-2818-4E30-9CB3-8E66F7A2AE02@randomchaos.com> References: <3ce2ebd20811070709t74f2257m409e0caefb9abd@mail.gmail.com> <4921D75F-2818-4E30-9CB3-8E66F7A2AE02@randomchaos.com> Message-ID: <3ce2ebd20811071140p3092e9e6rce1d8b692d2b2b99@mail.gmail.com> 2008/11/7 Scott Reynen : > Not as a valid dtstart value, no. The title attribute is only parsed when > the value element is empty, so that would parse with an invalid dtstart > value containing the entire sentence. See: > Sorry, I mucked up my copy and pasting, this is what I meant: Barack Obama was elected the first African American president of the United States of American, and he was really pleased about it, on 4th November 2008 Basically I'm not clear how forcing the empty element to be the first thing guarantees that it will then be close to the plain text date. Forcing it to be anywhere would seem to guarantee there are situations where it can't be close to where the plain text date is if the original example is valid, because it's easy enough to have that sentence the other way around. Rob From andr3.pt at gmail.com Fri Nov 7 12:13:26 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Fri Nov 7 12:20:52 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: <3ce2ebd20811071140p3092e9e6rce1d8b692d2b2b99@mail.gmail.com> References: <3ce2ebd20811070709t74f2257m409e0caefb9abd@mail.gmail.com> <4921D75F-2818-4E30-9CB3-8E66F7A2AE02@randomchaos.com> <3ce2ebd20811071140p3092e9e6rce1d8b692d2b2b99@mail.gmail.com> Message-ID: Rob, >From the top of my head:

Barack Obama was elected the first African American president of the United States of American, and he was really pleased about it, on 4th November 2008

(sorry, I'm in a rush. ;)) -- Andr? Lu?s On Fri, Nov 7, 2008 at 7:40 PM, Rob Crowther wrote: > 2008/11/7 Scott Reynen : >> Not as a valid dtstart value, no. The title attribute is only parsed when >> the value element is empty, so that would parse with an invalid dtstart >> value containing the entire sentence. See: >> > Sorry, I mucked up my copy and pasting, this is what I meant: > > > Barack Obama was elected the first African American president of the > United States of American, and he was really pleased about it, on 4th > November 2008 > > Basically I'm not clear how forcing the empty element to be the first > thing guarantees that it will then be close to the plain text date. > Forcing it to be anywhere would seem to guarantee there are situations > where it can't be close to where the plain text date is if the > original example is valid, because it's easy enough to have that > sentence the other way around. > > Rob > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From lists at ben-ward.co.uk Fri Nov 7 12:29:26 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Fri Nov 7 12:29:31 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: <3ce2ebd20811071140p3092e9e6rce1d8b692d2b2b99@mail.gmail.com> References: <3ce2ebd20811070709t74f2257m409e0caefb9abd@mail.gmail.com> <4921D75F-2818-4E30-9CB3-8E66F7A2AE02@randomchaos.com> <3ce2ebd20811071140p3092e9e6rce1d8b692d2b2b99@mail.gmail.com> Message-ID: <1D68EC4D-ABAB-4A50-9EC9-19DD067D2419@ben-ward.co.uk> Hi Rob, On 7 Nov 2008, at 11:40, Rob Crowther wrote: > > Barack Obama was elected the first African American president of the > United States of American, and he was really pleased about it, on 4th > November 2008 > > Basically I'm not clear how forcing the empty element to be the first > thing guarantees that it will then be close to the plain text date. > Forcing it to be anywhere would seem to guarantee there are situations > where it can't be close to where the plain text date is if the > original example is valid, because it's easy enough to have that > sentence the other way around. Requiring the machine data to be the first child element is not to force it to be close the human form (which is in an indeterminable position in the structure), but instead to force it to be close to the *property declaration*. The idea is that when you read the mark-up, you read the machine-data value right next to the property name; a visually clearer association that will make it easily to see and maintain the value when working the code. Visual developer aids (such as CSS rules to display the @title attribute of elements with class=value during development) will cause the value to be displayed at the beginning of property blocks, again promoting a stronger visual association. It means that the machine-data value doesn't get lost within a block of content, it's there right at the start, and that attempts to alleviate the violation of DRY. I most cases, I expect patterns will be simple, and end up containing just the machine value and displayed form with no additional content. By forcing the machine-data to the front though, it remains consistent no matter now much content is contained in the display form. B From lists at ben-ward.co.uk Fri Nov 7 13:04:31 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Fri Nov 7 13:04:35 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: References: Message-ID: Hi Andr?, On 7 Nov 2008, at 08:38, Andr? Lu?s wrote: > I can see this option being adopted by people who are concerned about > accessibility, while others might just go ahead and use the > regular-problem-maker-of-a-pattern the datetime design pattern, > preferring simplicity over accessibility. Right? Well, first up, all web developers are supposed to be concerned about accessibility, otherwise they're not doing their job properly. I'll avoid digressing into that, though! All optimisation patterns in microformats are valid for some purposes. Using an ABBR for country names is completely the Right Thing To Do, whilst for a timestamp it may not be. As with many methods in HTML, a degree of author interpretation of semantics will always take place, and authors will implement what makes sense to them. There has to be an acceptance that valid HTML4 does not allow for embedding alternate-form content, so we're trying to build something that fits as logically and gracefully as we can. For me, the ?machine- data? value being a child of the property (a sibling of the display form) makes total structural sense. An advantage of this pattern is that it is based entirely around neutral mark-up (span), although there is also no need to restrict it to any one element (you can use if you like, or if you want; we and our parsers shouldn't and don't care). Using the @title attribute of this value element when the user does not want the value to be displayed is a little cludgy, but justified by the fact that it is not rendered in any browser (although that behaviour is a specification grey-area). Despite a stretch over the traditional use of title, @title is still associated with the class=value element. I think they have a valid and appropriate relationship; I read it as ?the title of the value is 2008-11-07?. It's not as strong a relationship as the inner-text, but it's not nonsense, either. There is also a viewpoint that @title should only be for human consumable data. I agree and subscribe to this viewpoint. But in this mark-up pattern, the @title of an empty element is never exposed to ANY human in any way ? that has been tested by the lovely James Craig of Apple, who has confirmed that empty s do not get exposed to screen readers (although empty elements can). Thus, I think the benefits and grace of the structure justify that exception. This is also the line of exception I would make when writing coding standards. Ben From scott at randomchaos.com Fri Nov 7 12:48:19 2008 From: scott at randomchaos.com (Scott Reynen) Date: Fri Nov 7 13:13:44 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: <3ce2ebd20811071140p3092e9e6rce1d8b692d2b2b99@mail.gmail.com> References: <3ce2ebd20811070709t74f2257m409e0caefb9abd@mail.gmail.com> <4921D75F-2818-4E30-9CB3-8E66F7A2AE02@randomchaos.com> <3ce2ebd20811071140p3092e9e6rce1d8b692d2b2b99@mail.gmail.com> Message-ID: <8E183FA4-05E9-4417-B460-089FE39DDD24@randomchaos.com> On [Nov 7], at [ Nov 7] 12:40 , Rob Crowther wrote: > 2008/11/7 Scott Reynen : >> Not as a valid dtstart value, no. The title attribute is only >> parsed when >> the value element is empty, so that would parse with an invalid >> dtstart >> value containing the entire sentence. See: >> > Sorry, I mucked up my copy and pasting, this is what I meant: > > > Barack Obama was elected the first African American president of the > United States of American, and he was really pleased about it, on 4th > November 2008 > > Basically I'm not clear how forcing the empty element to be the first > thing guarantees that it will then be close to the plain text date. > Forcing it to be anywhere would seem to guarantee there are situations > where it can't be close to where the plain text date is if the > original example is valid, because it's easy enough to have that > sentence the other way around. It only minimizes drift in the context of good markup, i.e. classes surrounding only the content they actually describe. In the context of bad markup, such as your example where "Barack Obama" is improperly labeled as "dtstart", this doesn't really help. But it doesn't really hurt either. The root of the markup drift here has nothing to do with the "value" class and everything to do with the "dtstart" class. The above should (and in most cases easily could) be: > Barack Obama was elected the first African American president of the > United States of American, and he was really pleased about it, on > span>4th > November 2008 Peace, Scott From lists at isofarro.uklinux.net Sun Nov 9 09:32:49 2008 From: lists at isofarro.uklinux.net (Isofarro) Date: Sun Nov 9 09:33:11 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: References: Message-ID: <49171EC1.70007@isofarro.uklinux.net> Andr? Lu?s wrote: > I can see this option being adopted by people who are concerned about > accessibility, while others might just go ahead and use the > regular-problem-maker-of-a-pattern the datetime design pattern, > preferring simplicity over accessibility. Right? There are three possible configurations in a screen reader for handling title attributes on elements: 1.) Ignore the title attribute and read the inner text 2.) Read the title attribute instead of the inner text 3.) Read the title attribute as well as the inner text The choice between these options is user choice - the user opts for the one that proves more useful over time. In the situation where an empty span is used, with a class of value and machine data in the title attribute, this is read out where the screen reader is configured to use 2.) and 3.) Where a value-classed span is used and a human friendly wording is used as inner text, then in case 2.) the machine formatted data is read out, but not the human-readable version, and in case 3.) the machine formatted data is read out before or after the human friendly data. So the accessibility barriers that are created are: 1.) machine-formatted data is being read out to screen reader users 2.) machine-formatted data is being read out, and its human digestible format isn't. Both cases result in content that is more difficult to understand, but case 2 is actually worse - it replaces human readable content with machine readable content. Both introduce accessibility barriers, just one does more damage than the other. With this in mind, from an accessibility perspective, any microformat pattern which results in machine-formatted or human-unfriendly content in an area that is supposed to be human consumable is going to create one barrier or the other, depending on screen reader configuration. So the logical approach to protecting the accessibility of the page in these cases is not to use any microformat that specifies adding machine data into a human-visible region of the page. From csarven at gmail.com Tue Nov 11 11:14:25 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Tue Nov 11 11:14:28 2008 Subject: [uf-discuss] Incorrect mention of the address element for hAtom entry author in the Wiki Message-ID: hAtom Entry Author states "an Entry Author element should be encoded in an
element" [1]. This is misleading and in most cases an incorrect use of
for an Entry Author [2]. I propose we remove this clause from the Wiki. [1] http://microformats.org/wiki/hatom#Entry_Author [2] http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards -Sarven From davidjanes at blogmatrix.com Tue Nov 11 11:26:13 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Nov 11 11:26:16 2008 Subject: [uf-discuss] Incorrect mention of the address element for hAtom entry author in the Wiki In-Reply-To: References: Message-ID: <21e523c20811111126h47965140va1e17fc3cc970eba@mail.gmail.com> On Tue, Nov 11, 2008 at 2:14 PM, Sarven Capadisli wrote: > hAtom Entry Author states "an Entry Author element should be encoded > in an
element" [1]. This is misleading and in most cases an > incorrect use of
for an Entry Author [2]. > > I propose we remove this clause from the Wiki. > > [1] http://microformats.org/wiki/hatom#Entry_Author > [2] http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards > >From your point [2] "
... suppl[ies] contact information for a document or a major part of a document". An hAtom Entry defines such a major part of a document. Regards, etc... David -- David Janes Mercenary Programmer http://code.davidjanes.com From tantek at cs.stanford.edu Tue Nov 11 11:38:25 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Tue Nov 11 11:38:29 2008 Subject: [uf-discuss] Incorrect mention of the address element for hAtom entry author in the Wiki In-Reply-To: <21e523c20811111126h47965140va1e17fc3cc970eba@mail.gmail.com> References: <21e523c20811111126h47965140va1e17fc3cc970eba@mail.gmail.com> Message-ID: <60cb038a0811111138w2e3356fcr6ef9cdfbc202b6c9@mail.gmail.com> On Tue, Nov 11, 2008 at 11:26 AM, David Janes wrote: > On Tue, Nov 11, 2008 at 2:14 PM, Sarven Capadisli wrote: >> hAtom Entry Author states "an Entry Author element should be encoded >> in an
element" [1]. This is misleading and in most cases an >> incorrect use of
for an Entry Author [2]. >> >> I propose we remove this clause from the Wiki. >> >> [1] http://microformats.org/wiki/hatom#Entry_Author >> [2] http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards Agreed, and originally raised 2008-06-07: http://microformats.org/wiki/hatom-issues#misuse_of_address_element Please document new issues against microformats (specs, drafts, brainstorms) on the respective issues wiki page, and add (dis)agreement +1(-1) with your name and reasons accordingly. > >From your point [2] "
... suppl[ies] contact information for > a document or a major part of a document". An hAtom Entry defines such > a major part of a document. author of is not necessarily the same as contact for.
means contact for whereas the author semantic comes from Atom which means author. RFC 4287 section 4.2.1. The "atom:author" Element. Tantek -- http://tantek.com/ From lists at ben-ward.co.uk Tue Nov 11 15:27:25 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Tue Nov 11 15:27:37 2008 Subject: [uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16) Message-ID: Hi everyone, An update to the microformats wiki is finally ready to go live (updating to the new build of mediawiki, plus some new theming features and plug-ins). I got delayed quite a bit due to my moving out to San Francisco, but all being well I'll be running the update on the afternoon of Sunday 16th. This process will take a few hours. The wiki will be read-only throughout the process, and there will be brief downtime whilst the installation is swapped over. If this is going to cause a problem for anybody, please shout out! Regards, Ben From danbri at danbri.org Tue Nov 11 15:42:00 2008 From: danbri at danbri.org (Dan Brickley) Date: Tue Nov 11 15:42:08 2008 Subject: [uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16) In-Reply-To: References: Message-ID: <491A1848.2080507@danbri.org> Ben Ward wrote: > Hi everyone, > > An update to the microformats wiki is finally ready to go live (updating > to the new build of mediawiki, plus some new theming features and > plug-ins). Good luck with the switchover! Any chance of openid for logins in the new version? cheers, Dan -- http://danbri.org/ From lists at ben-ward.co.uk Tue Nov 11 16:19:24 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Tue Nov 11 16:19:31 2008 Subject: [uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16) In-Reply-To: <491A1848.2080507@danbri.org> References: <491A1848.2080507@danbri.org> Message-ID: <0B61D203-EFE7-425B-B679-95CB0E485CBE@ben-ward.co.uk> On 11 Nov 2008, at 15:42, Dan Brickley wrote: > Ben Ward wrote: >> Hi everyone, >> An update to the microformats wiki is finally ready to go live >> (updating to the new build of mediawiki, plus some new theming >> features and plug-ins). > > Good luck with the switchover! Any chance of openid for logins in > the new version? Adding OpenID support was something I was really keen to do, and has been a long running requested feature. However, the current state of the OpenID extension for MediaWiki is overkill for us. The plug-in that's available transforms the wiki into a full on OpenID _provider_, and we don't want the maintenance/responsibility cost of doing that. We just want login support. So the task has been deferred pending someone writing a super-simple OpenIDLogin plugin, or dedicating longer to the existing extension and getting it installed properly. It might not take that long to do the latter, but it's a more substantial installation than other extensions, so I'm preferring to get the current work released with a view to adding it later. Given the way in which microformats.org is spread across multiple platforms (the wordpress blog, mediawiki, various API kits hosted on Google and elsewhere), I'm certainly very keen to have OpenID as a feature on everything we do. New features are approximately listed on the microformats todo list here: http://microformats.org/wiki/todo#Wiki_2.0 and will be documented more thoroughly on the wiki itself when we do the upgrade. B From tantek at cs.stanford.edu Wed Nov 12 16:29:09 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Nov 12 16:29:54 2008 Subject: [uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16) In-Reply-To: References: Message-ID: <1254682311-1226536189-cardhu_decombobulator_blackberry.rim.net-430668621-@bxe346.bisx.prod.on.blackberry> This is great news Ben! Perhaps you could put the approximate time range of when the upgrade will be performed into an event on the wiki and the homepage? Thanks! Tantek -----Original Message----- From: Ben Ward Date: Tue, 11 Nov 2008 15:27:25 To: Microformats Discuss Subject: [uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16) Hi everyone, An update to the microformats wiki is finally ready to go live (updating to the new build of mediawiki, plus some new theming features and plug-ins). I got delayed quite a bit due to my moving out to San Francisco, but all being well I'll be running the update on the afternoon of Sunday 16th. This process will take a few hours. The wiki will be read-only throughout the process, and there will be brief downtime whilst the installation is swapped over. If this is going to cause a problem for anybody, please shout out! Regards, Ben _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From tom at tommorris.org Thu Nov 13 13:47:17 2008 From: tom at tommorris.org (Tom Morris) Date: Thu Nov 13 13:47:22 2008 Subject: [uf-discuss] Wiki upgrade/downtime this Sunday (2008-11-16) In-Reply-To: <0B61D203-EFE7-425B-B679-95CB0E485CBE@ben-ward.co.uk> References: <491A1848.2080507@danbri.org> <0B61D203-EFE7-425B-B679-95CB0E485CBE@ben-ward.co.uk> Message-ID: On Wed, Nov 12, 2008 at 12:19 AM, Ben Ward wrote: > On 11 Nov 2008, at 15:42, Dan Brickley wrote: >> Good luck with the switchover! Any chance of openid for logins in the new >> version? > > Adding OpenID support was something I was really keen to do, and has been a > long running requested feature. However, the current state of the OpenID > extension for MediaWiki is overkill for us. The plug-in that's available > transforms the wiki into a full on OpenID _provider_, and we don't want the > maintenance/responsibility cost of doing that. We just want login support. > Strange. I've got the OpenID plugin running on the MediaWiki install on getsemantic. It's unreliable, but it doesn't turn the site into being an OpenID provider, AFAIK. When I've next got a minute, I'll dig through the installed version and extract the relevant files. OpenID support on the wiki would definitely be practicing the openness we preach. -- Tom Morris http://tommorris.org/ From mart at degeneration.co.uk Sat Nov 15 14:14:00 2008 From: mart at degeneration.co.uk (Martin Atkins) Date: Sat Nov 15 14:43:16 2008 Subject: [uf-discuss] Going from XFN to hCard Message-ID: <491F49A8.6070905@degeneration.co.uk> Hi folks, I currently use XFN to link my various pages together and hCard to mark up my contact information on some of them. One thing I've not been able to find information on is how to identify a particular hcard on a page as being the one that's about the person the page represents. For example, http://martin.atkins.me.uk/ represents me and has an hCard of my personal information on it. I'd like a way to say that this hCard represents the same person as the URL. Is there existing practice for this? Thanks, Martin From tantek at cs.stanford.edu Sat Nov 15 14:59:44 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Sat Nov 15 15:25:35 2008 Subject: [uf-discuss] Going from XFN to hCard In-Reply-To: <491F49A8.6070905@degeneration.co.uk> References: <491F49A8.6070905@degeneration.co.uk> Message-ID: <827682884-1226790033-cardhu_decombobulator_blackberry.rim.net-1668318406-@bxe346.bisx.prod.on.blackberry> http://microformats.org/wiki/representative-hcard -----Original Message----- From: Martin Atkins Date: Sat, 15 Nov 2008 14:14:00 To: Subject: [uf-discuss] Going from XFN to hCard Hi folks, I currently use XFN to link my various pages together and hCard to mark up my contact information on some of them. One thing I've not been able to find information on is how to identify a particular hcard on a page as being the one that's about the person the page represents. For example, http://martin.atkins.me.uk/ represents me and has an hCard of my personal information on it. I'd like a way to say that this hCard represents the same person as the URL. Is there existing practice for this? Thanks, Martin _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From mart at degeneration.co.uk Sat Nov 15 19:27:35 2008 From: mart at degeneration.co.uk (Martin Atkins) Date: Sat Nov 15 19:27:38 2008 Subject: [uf-discuss] Going from XFN to hCard In-Reply-To: <827682884-1226790033-cardhu_decombobulator_blackberry.rim.net-1668318406-@bxe346.bisx.prod.on.blackberry> References: <491F49A8.6070905@degeneration.co.uk> <827682884-1226790033-cardhu_decombobulator_blackberry.rim.net-1668318406-@bxe346.bisx.prod.on.blackberry> Message-ID: <491F9327.5080703@degeneration.co.uk> Tantek Celik wrote: > http://microformats.org/wiki/representative-hcard > Thanks for the pointer. The representative-hcard-authoring page shows how to create an hCard that links to the page it represents. I've posted on the representative-hcard-brainstorming page a complimentary proposal for the opposite link from the page to the hCard. I'll also include it below... ------------------ First add an id attribute to the element that carries the "vcard" class. Then either publish this in the HEAD section of the page: or publish this in the BODY of the page: Contact Information Borrows the semantics of XFN's "me" relationship, saying "this element represents the same person as this page". Allows the page to link to the hcard rather than the other way around. Can in theory be used to say that an hcard on a completely different page is the representative hcard for this page. Could be useful to avoid duplicating information if, for example, the site already has a "Contact Me" page: Contact Me The above doesn't necessarily imply that contact.html itself represents the same person as this page. contact.html might itself be about contacting several different people or departments. If the hcard is indeed on a different page, it can reciprocate the link by linking back from within the hCard, ideally within the hCard "url" field. If the hCard is on the page it represents, this reciprocal link is implied. rel="me" should not be included on this link unless the page containing the hcard represents the same person as the target of the link, to avoid confusing XFN-only (i.e. non-hCard) parsers. ------------------ Thanks, Martin From lists at ben-ward.co.uk Sun Nov 16 17:39:15 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Sun Nov 16 17:40:38 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: <49171EC1.70007@isofarro.uklinux.net> References: <49171EC1.70007@isofarro.uklinux.net> Message-ID: Hi Mike, On 9 Nov 2008, at 09:32, Isofarro wrote: > Where a value-classed span is used and a human friendly wording is > used as inner text, then in case 2.) the machine formatted data is > read out, but not the human-readable version, and in case 3.) the > machine formatted data is read out before or after the human > friendly data. > > So the accessibility barriers that are created are: > > 1.) machine-formatted data is being read out to screen reader users > 2.) machine-formatted data is being read out, and its human > digestible format isn't. > > Both cases result in content that is more difficult to understand, > but case 2 is actually worse - it replaces human readable content > with machine readable content. Both introduce accessibility > barriers, just one does more damage than the other. So, I believe I'm reading this right that you're describing a value- classed + inner text + title situation all on the same element, and *not* where you have the value-classed element as an empty sibling of the human form (which is what the current proposal specifies)? > With this in mind, from an accessibility perspective, any > microformat pattern which results in machine-formatted or human- > unfriendly content in an area that is supposed to be human > consumable is going to create one barrier or the other, depending on > screen reader configuration. So the logical approach to protecting > the accessibility of the page in these cases is not to use any > microformat that specifies adding machine data into a human-visible > region of the page. Again for clarity, could you confirm whether the proposed pattern falls into your definition of introducing machine-data into a human- visible region of the page, given that the empty elements are ignored in the page rendering. e.g, in hAtom: 16th November 2008, 7:30am Thanks, Ben From andr3.pt at gmail.com Sun Nov 16 19:11:33 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Sun Nov 16 19:11:37 2008 Subject: [uf-discuss] Yet another XFN demo Message-ID: Hi everyone, Just wanted to share a little demo I put together for a talk I gave last week at SAPO Codebits (http://codebits.sapo.pt/) in Lisbon which btw, is heavily inspired in Yahoo! Hackday... It's basically an XFN crawler that puts the nodes into a dynamic graph (using the great JIT) which you can recenter by clicking on the people's names and start over from a new url by clicking on the url you want. http://workshop.andr3.net/xfnexplorer/ I demo-ed it at the event and some people really grasped the magnitude of microformats when they saw how much of the social graph around them it was able to discover. It's not very efficient, so it might take some time...but hey, it's fun! ;) If you have some feedback or suggestions, let me know. I'm using Dmitry's Optimus behind it, so if you can think of cool visualizations for other formats, please share... it might be easy to put together. Cheers, -- Andr? Lu?s From lists at ben-ward.co.uk Mon Nov 17 02:47:30 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Mon Nov 17 02:47:56 2008 Subject: [uf-discuss] Wiki 2.0 is alive! Message-ID: Hi everyone, As promised, the wiki had some downtime this evening as I ran a fairly large upgrade of MediaWiki and the design of the microformats wiki. It's been quite a long time coming, and a lot of work, but I hope people appreciate the improvement. The new features of the wiki are documented on the wiki itself[1], along with an issues page[2]. You can also get a drive-by idea of what kind of improvements I've made by visiting the frontpage[3], the hCard page[4] and the hAtom page[5]. Feedback is welcome as always, either here, on the aforementioned issues page or on the associated blog entry[6]. 1. http://microformats.org/wiki/wiki-2 2. http://microformats.org/wiki/wiki-2-issues 3. http://microformats.org/wiki/ 4. http://microformats.org/wiki/hcard 5. http://microformats.org/wiki/hatom 6. http://microformats.org/blog/2008/11/17/wiki/ Thanks for your patience with the upgrade. Ben From davidjanes at blogmatrix.com Mon Nov 17 04:10:57 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Nov 17 04:19:10 2008 Subject: [uf-discuss] Wiki 2.0 is alive! In-Reply-To: References: Message-ID: <21e523c20811170410o4ec8a7a6kf30466747ad075d4@mail.gmail.com> And it looks mighty slick! Good job On Mon, Nov 17, 2008 at 5:47 AM, Ben Ward wrote: > Hi everyone, > > As promised, the wiki had some downtime this evening as I ran a fairly large > upgrade of MediaWiki and the design of the microformats wiki. > > It's been quite a long time coming, and a lot of work, but I hope people > appreciate the improvement. > > The new features of the wiki are documented on the wiki itself[1], along > with an issues page[2]. You can also get a drive-by idea of what kind of > improvements I've made by visiting the frontpage[3], the hCard page[4] and > the hAtom page[5]. > > Feedback is welcome as always, either here, on the aforementioned issues > page or on the associated blog entry[6]. > > 1. http://microformats.org/wiki/wiki-2 > 2. http://microformats.org/wiki/wiki-2-issues > 3. http://microformats.org/wiki/ > 4. http://microformats.org/wiki/hcard > 5. http://microformats.org/wiki/hatom > 6. http://microformats.org/blog/2008/11/17/wiki/ > > Thanks for your patience with the upgrade. > > Ben > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Mon Nov 17 04:11:59 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 17 04:19:52 2008 Subject: [uf-discuss] Wiki 2.0 is alive! In-Reply-To: References: Message-ID: <49215F8F.2050205@weborganics.co.uk> Hello Ben, Ben Ward wrote: > Hi everyone, > > As promised, the wiki had some downtime this evening as I ran a fairly > large upgrade of MediaWiki and the design of the microformats wiki. > > It's been quite a long time coming, and a lot of work, but I hope > people appreciate the improvement. I do Its Great! a huge improvement... > > The new features of the wiki are documented on the wiki itself[1], > along with an issues page[2]. You can also get a drive-by idea of what > kind of improvements I've made by visiting the frontpage[3], the hCard > page[4] and the hAtom page[5]. > > Feedback is welcome as always, either here, on the aforementioned > issues page or on the associated blog entry[6]. > > 1. http://microformats.org/wiki/wiki-2 > 2. http://microformats.org/wiki/wiki-2-issues > 3. http://microformats.org/wiki/ > 4. http://microformats.org/wiki/hcard > 5. http://microformats.org/wiki/hatom > 6. http://microformats.org/blog/2008/11/17/wiki/ > > Thanks for your patience with the upgrade. Thank you :-) > > Ben > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss -- Martin McEvoy http://weborganics.co.uk/ From fberriman at gmail.com Mon Nov 17 04:08:00 2008 From: fberriman at gmail.com (Frances Berriman) Date: Mon Nov 17 04:40:54 2008 Subject: [uf-discuss] Wiki 2.0 is alive! In-Reply-To: References: Message-ID: It looks great, Ben :) A vast improvement. Thanks for the hard work! F 2008/11/17 Ben Ward : > Hi everyone, > > As promised, the wiki had some downtime this evening as I ran a fairly large > upgrade of MediaWiki and the design of the microformats wiki. > > It's been quite a long time coming, and a lot of work, but I hope people > appreciate the improvement. > > The new features of the wiki are documented on the wiki itself[1], along > with an issues page[2]. You can also get a drive-by idea of what kind of > improvements I've made by visiting the frontpage[3], the hCard page[4] and > the hAtom page[5]. > > Feedback is welcome as always, either here, on the aforementioned issues > page or on the associated blog entry[6]. > > 1. http://microformats.org/wiki/wiki-2 > 2. http://microformats.org/wiki/wiki-2-issues > 3. http://microformats.org/wiki/ > 4. http://microformats.org/wiki/hcard > 5. http://microformats.org/wiki/hatom > 6. http://microformats.org/blog/2008/11/17/wiki/ > > Thanks for your patience with the upgrade. > > Ben > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Frances Berriman http://fberriman.com From csarven at gmail.com Mon Nov 17 05:54:04 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Mon Nov 17 05:54:07 2008 Subject: [uf-discuss] Wiki 2.0 is alive! In-Reply-To: References: Message-ID: On Mon, Nov 17, 2008 at 5:47 AM, Ben Ward wrote: > Hi everyone, > > As promised, the wiki had some downtime this evening as I ran a fairly large > upgrade of MediaWiki and the design of the microformats wiki. > > It's been quite a long time coming, and a lot of work, but I hope people > appreciate the improvement. > > The new features of the wiki are documented on the wiki itself[1], along > with an issues page[2]. You can also get a drive-by idea of what kind of > improvements I've made by visiting the frontpage[3], the hCard page[4] and > the hAtom page[5]. > > Feedback is welcome as always, either here, on the aforementioned issues > page or on the associated blog entry[6]. > > 1. http://microformats.org/wiki/wiki-2 > 2. http://microformats.org/wiki/wiki-2-issues > 3. http://microformats.org/wiki/ > 4. http://microformats.org/wiki/hcard > 5. http://microformats.org/wiki/hatom > 6. http://microformats.org/blog/2008/11/17/wiki/ > > Thanks for your patience with the upgrade. > > Ben This is awesome! Thanks Ben. Off I go click around. -Sarven From davidjanes at blogmatrix.com Mon Nov 17 14:15:28 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Nov 17 14:20:43 2008 Subject: [uf-discuss] Wiki issues - no login required? Message-ID: <21e523c20811171415x6e8ef280t8c4ad41872828209@mail.gmail.com> Is the Wiki supposed to be no login required? Just noticed that I can edit pages without being logged in. -- David Janes Mercenary Programmer http://code.davidjanes.com From lists at ben-ward.co.uk Mon Nov 17 14:43:26 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Mon Nov 17 14:43:31 2008 Subject: [uf-discuss] Wiki issues - no login required? In-Reply-To: <21e523c20811171415x6e8ef280t8c4ad41872828209@mail.gmail.com> References: <21e523c20811171415x6e8ef280t8c4ad41872828209@mail.gmail.com> Message-ID: <1F811A22-4676-491A-98CA-7F6DD4DEA5B4@ben-ward.co.uk> Hi David, On 17 Nov 2008, at 14:15, David Janes wrote: > Is the Wiki supposed to be no login required? Just noticed that I can > edit pages without being logged in. The setting used to enforce that seemed to have changed between MediaWiki versions, thanks very much for catching this! I've disabled anonymous login rights again. Hopefully we'll get spammed a little less now! Ben From martin at weborganics.co.uk Mon Nov 17 19:06:54 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 17 19:07:03 2008 Subject: [uf-discuss] Lets talk about rev? Message-ID: <4922314E.2080909@weborganics.co.uk> Hello I was going to post this to uf new but the topic is not new. I would like to ask "please" can we (the community) start talking about rev microformats again please, I know that rev is "grandfathered" in new Microformats because most of the time the average author gets it wrong (according to google anyway), but really microformats developers are becoming a breed of forward thinking savvy developers, that are not just interested in Microformats Many are interested in expressing semantics in wild and wonderful ways, they know how rev and rel works...... and I am over dramatizing sorry to the point.... You will all no doubt seen many blogs with links in the sidebar to places or projects, applications, websites, music...etc that they have been involved with? Say I made an application and I put a link to it somewhere on my homepage as a way of saying this Is a great app that I made go check it out, how do I build that link, I would like to add something explicit like this TranFormr would mean.. made another good example of where a rev link would be useful Is when you post an article on your own blog as a response or reply to another post on someone else's blog, rev would be ideal in this case because you could mark up your post like this... real world example found here: http://nfegen.wordpress.com/2008/03/28/micrordformats/

I read an interesting post recently, ?So how about using RDFa in Microformats??....

by adding rev-reply to the above link... ?So how about using RDFa in Microformats?? the author would be saying... is a reply to Nice I think, kind of like a pingback? there are probably a lot more examples I could make but I think I have done enough to make my point. Thanks -- Martin McEvoy http://weborganics.co.uk/ From tantek at cs.stanford.edu Mon Nov 17 20:48:06 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Mon Nov 17 20:48:58 2008 Subject: [uf-discuss] Lets talk about rev? In-Reply-To: <4922314E.2080909@weborganics.co.uk> References: <4922314E.2080909@weborganics.co.uk> Message-ID: <2114021324-1226983732-cardhu_decombobulator_blackberry.rim.net-2112668596-@bxe346.bisx.prod.on.blackberry> Martin: > they know how rev and rel works...... There has been no evidence shown to demonstrate this. On the contrary, the overwhelming evidence (anecdotal and quantitative by the Google/Hixie markup study) has demonstrated the opposite: they don't know how rev works. If you want to argue for use of rev in general and/or present evidence for it, I suggest doing so at a lower level, that is in the HTML5 community (since it is an HTML attribute you are asking for general use of), either on the whatwg list or the w3c public-html list. Tantek -----Original Message----- From: Martin McEvoy Date: Tue, 18 Nov 2008 03:06:54 To: Microformats Discuss Subject: [uf-discuss] Lets talk about rev? Hello I was going to post this to uf new but the topic is not new. I would like to ask "please" can we (the community) start talking about rev microformats again please, I know that rev is "grandfathered" in new Microformats because most of the time the average author gets it wrong (according to google anyway), but really microformats developers are becoming a breed of forward thinking savvy developers, that are not just interested in Microformats Many are interested in expressing semantics in wild and wonderful ways, they know how rev and rel works...... and I am over dramatizing sorry to the point.... You will all no doubt seen many blogs with links in the sidebar to places or projects, applications, websites, music...etc that they have been involved with? Say I made an application and I put a link to it somewhere on my homepage as a way of saying this Is a great app that I made go check it out, how do I build that link, I would like to add something explicit like this TranFormr would mean.. made another good example of where a rev link would be useful Is when you post an article on your own blog as a response or reply to another post on someone else's blog, rev would be ideal in this case because you could mark up your post like this... real world example found here: http://nfegen.wordpress.com/2008/03/28/micrordformats/

I read an interesting post recently, ?So how about using RDFa in Microformats??....

by adding rev-reply to the above link... ?So how about using RDFa in Microformats?? the author would be saying... is a reply to Nice I think, kind of like a pingback? there are probably a lot more examples I could make but I think I have done enough to make my point. Thanks -- Martin McEvoy http://weborganics.co.uk/ _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From mdagn at spraci.com Mon Nov 17 20:52:24 2008 From: mdagn at spraci.com (Michael MD) Date: Mon Nov 17 20:54:11 2008 Subject: [uf-discuss] Lets talk about rev? References: <4922314E.2080909@weborganics.co.uk> Message-ID: <002401c94939$73f0e360$116bacca@COMCEN> >I would like to ask "please" can we (the community) start talking about >rev microformats again please, I know that rev is "grandfathered" in new >Microformats because most of the time the average author gets it wrong ... html5 doesn't have the rev attribute ... From martin at weborganics.co.uk Tue Nov 18 01:36:20 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Nov 18 01:36:30 2008 Subject: [uf-discuss] Lets talk about rev? In-Reply-To: <2114021324-1226983732-cardhu_decombobulator_blackberry.rim.net-2112668596-@bxe346.bisx.prod.on.blackberry> References: <4922314E.2080909@weborganics.co.uk> <2114021324-1226983732-cardhu_decombobulator_blackberry.rim.net-2112668596-@bxe346.bisx.prod.on.blackberry> Message-ID: <49228C94.2080002@weborganics.co.uk> Tantek Celik wrote: > Martin: > > >> they know how rev and rel works...... >> > > There has been no evidence shown to demonstrate this. > ? > On the contrary, the overwhelming evidence (anecdotal and quantitative by the Google/Hixie markup study) has demonstrated the opposite: they don't know how rev works. > Yes I have seen the evidence... :-( > If you want to argue for use of rev in general and/or present evidence for it, I suggest doing so at a lower level, that is in the HTML5 community (since it is an HTML attribute you are asking for general use of), either on the whatwg list or the w3c public-html list. > Thank you I will, I will drop the whatwg later on today.. > Tantek > > -----Original Message----- > From: Martin McEvoy > > Date: Tue, 18 Nov 2008 03:06:54 > To: Microformats Discuss > Subject: [uf-discuss] Lets talk about rev? > > > Hello > > I was going to post this to uf new but the topic is not new. > > I would like to ask "please" can we (the community) start talking about > rev microformats again please, I know that rev is "grandfathered" in new > Microformats because most of the time the average author gets it wrong > (according to google anyway), but really microformats developers are > becoming a breed of forward thinking savvy developers, that are not just > interested in Microformats Many are interested in expressing semantics > in wild and wonderful ways, they know how rev and rel works...... and I > am over dramatizing sorry to the point.... > > You will all no doubt seen many blogs with links in the sidebar to > places or projects, applications, websites, music...etc that they have > been involved with? > > Say I made an application and I put a link to it somewhere on my > homepage as a way of saying this Is a great app that I made go check it > out, how do I build that link, I would like to add something explicit > like this > > TranFormr > > would mean.. > > made > > another good example of where a rev link would be useful Is when you > post an article on your own blog as a response or reply to another post > on someone else's blog, rev would be ideal in this case because you > could mark up your post like this... real world example found here: > http://nfegen.wordpress.com/2008/03/28/micrordformats/ > >

I read an interesting post recently, href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html" > title="Link to Mark Birbeck blog post">?So how about using RDFa in > Microformats??....

> > by adding rev-reply to the above link... > > href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html" > title="Link to Mark Birbeck blog post">?So how about using RDFa in > Microformats?? > > the author would be saying... > > is a reply to > > > Nice I think, kind of like a pingback? there are probably a lot more > examples I could make but I think I have done enough to make my point. > > > Thanks > > -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Tue Nov 18 01:37:33 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Nov 18 01:37:41 2008 Subject: [uf-discuss] Lets talk about rev? In-Reply-To: <002401c94939$73f0e360$116bacca@COMCEN> References: <4922314E.2080909@weborganics.co.uk> <002401c94939$73f0e360$116bacca@COMCEN> Message-ID: <49228CDD.9050100@weborganics.co.uk> Michael MD wrote: >> I would like to ask "please" can we (the community) start talking >> about rev microformats again please, I know that rev is >> "grandfathered" in new Microformats because most of the time the >> average author gets it wrong > > ... html5 doesn't have the rev attribute ... I didnt know that fool me for not checking, that's quite sad really Thanks > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss -- Martin McEvoy http://weborganics.co.uk/ From jason.karns at gmail.com Tue Nov 18 05:21:01 2008 From: jason.karns at gmail.com (Jason Karns) Date: Tue Nov 18 05:21:04 2008 Subject: [uf-discuss] Lets talk about rev? In-Reply-To: <49228CDD.9050100@weborganics.co.uk> References: <4922314E.2080909@weborganics.co.uk> <002401c94939$73f0e360$116bacca@COMCEN> <49228CDD.9050100@weborganics.co.uk> Message-ID: <1005d65f0811180521t64f5524h81e09398fb51c49b@mail.gmail.com> I agree with Martin that it's sad we are unable to take advantage of this attribute where possible. The whole idea of completely ignoring a tiny piece of semantic markup simply because it's often mis-used in the wild seems misguided to me. If we (as users of web standards, not the microformat community) were to use markup as used in the wild, we would still be stuck with font tags and tables. The difference is that we know better and can inform others of its proper use. I see a striking resemblance to the use of the address element. It is quite often mis-used in the wild to markup any contact information whatsoever not being limited to contact info for the page. But with regards to this element, the community has simply taken the stance of informing its proper use, not ignoring it completely. Why not the same with @rev? ~Jason From scott at randomchaos.com Tue Nov 18 06:26:18 2008 From: scott at randomchaos.com (Scott Reynen) Date: Tue Nov 18 06:26:35 2008 Subject: [uf-discuss] Lets talk about rev? In-Reply-To: <1005d65f0811180521t64f5524h81e09398fb51c49b@mail.gmail.com> References: <4922314E.2080909@weborganics.co.uk> <002401c94939$73f0e360$116bacca@COMCEN> <49228CDD.9050100@weborganics.co.uk> <1005d65f0811180521t64f5524h81e09398fb51c49b@mail.gmail.com> Message-ID: <01AF7B7B-1CD0-4121-BDA6-54D6533C1D00@randomchaos.com> On [Nov 18], at [ Nov 18] 6:21 , Jason Karns wrote: > I agree with Martin that it's sad we are unable to take advantage of > this attribute where possible. Fortunately, this isn't really a problem in practice. One of the notable characteristics of rev is that it carries the same meaning as rel, only with reverse directionality. This allows us to express anything with one that we could otherwise express with the other, by reversing the directionality of the value. In some cases, this reversal is simple to do, e.g. rev="son" carries pretty much the exact same meaning as rel="father". In other cases, it will require more thought, but I don't believe there's any case where it's impossible; language is rich. So we're not really losing anything here. We can't do rev="reply", but we can still do rel="prompted" (i.e. that URL prompted this reply) or something similar to indicate the same meaning. Peace, Scott From james at atomless.com Wed Nov 19 03:06:47 2008 From: james at atomless.com (James Tindall) Date: Wed Nov 19 03:07:07 2008 Subject: [uf-discuss] rel="byme" Message-ID: <4923F347.1090301@atomless.com> I use the xfn rel="me" to link from my personal site to sites that I maintain and that represent me in some way but is there a microformat I should use to link to a site I have built for a client? =james.tindall From brian.suda at gmail.com Wed Nov 19 03:39:25 2008 From: brian.suda at gmail.com (Brian Suda) Date: Wed Nov 19 03:39:29 2008 Subject: [uf-discuss] rel="byme" In-Reply-To: <4923F347.1090301@atomless.com> References: <4923F347.1090301@atomless.com> Message-ID: <21e770780811190339n4177fca3n662654247ac60117@mail.gmail.com> On Wed, Nov 19, 2008 at 11:06 AM, James Tindall wrote: > I use the xfn rel="me" to link from my personal site to sites that I > maintain and that represent me in some way but is there a microformat I > should use to link to a site I have built for a client? I can't seem to find a reference, but i remember a value called "made" from somewhere. It is not part of the core link types in HTML http://www.w3.org/TR/REC-html40/types.html#type-links WHAT-WG has a few additional values for HTML5 http://www.whatwg.org/specs/web-apps/current-work/#linkTypes There is also a Wiki where they are extending REL values: http://wiki.whatwg.org/wiki/RelExtensions See if there is anything on those 3 resources that could be of use. -brian -- brian suda http://suda.co.uk From supercanadian at gmail.com Wed Nov 19 08:25:48 2008 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Wed Nov 19 08:33:00 2008 Subject: [uf-discuss] rel="byme" In-Reply-To: <4923F347.1090301@atomless.com> References: <4923F347.1090301@atomless.com> Message-ID: <84ce626f0811190825m72f4a46fy8b989aabf1814d7e@mail.gmail.com> Hello, On Wed, Nov 19, 2008 at 3:06 AM, James Tindall wrote: > I use the xfn rel="me" to link from my personal site to sites that I > maintain and that represent me in some way but is there a microformat I > should use to link to a site I have built for a client? There's rev-author, that many people use... In addition to the rel-made that Brian mentioned. Semantic wise, rev-author and rel-made would be equivalent. (And rel-author and rev-made would be equivalent.) -- Charles Iliya Krempeaux, B.Sc. http://changelog.ca/ From mail at tobyinkster.co.uk Thu Nov 20 07:11:18 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Nov 20 07:11:51 2008 Subject: [uf-discuss] rel="byme" Message-ID: Brian Suda wrote: > James Tindall wrote: > > > I use the xfn rel="me" to link from my personal site to sites that I > > maintain and that represent me in some way but is there a > microformat I > > should use to link to a site I have built for a client? > > I can't seem to find a reference, but i remember a value called "made" > from somewhere. > > It is not part of the core link types in HTML > http://www.w3.org/TR/REC-html40/types.html#type-links It's in the HTML 3.2 spec. > WHAT-WG has a few additional values for HTML5 > http://www.whatwg.org/specs/web-apps/current-work/#linkTypes As does the XHTML 2.0 draft: http://www.w3.org/TR/xhtml2/mod- metaAttributes.html#adef_metaAttributes_rel Whatsmore, RDFa allows you to use terms from various non-W3C vocabularies such as Dublin Core (which has dc:creator and dc:contributor) and FOAF (which has foaf:made and foaf:maker). If you treat a website as being a "project", then the Description of a Project (DOAP) vocabulary might be handy too, as it has doap:developer, doap:maintainer, doap:documenter, doap:translator, doap:tester and doap:helper. At http://buzzword.org.uk/cognition/ I use RDFa to indicate that the dc:creator, doap:maintainer, doap:developer, foaf:maker and doap:documenter of the project is me; that the dc:creator, author and foaf:maker of the page itself is me; and that I foaf:made and made both the project and the page. I also use the hCard microformat in conjunction with
to indicate that I am the contact person for the page. -- Toby A Inkster From martin at weborganics.co.uk Fri Nov 21 06:07:35 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 21 06:08:03 2008 Subject: [uf-discuss] rel="byme" In-Reply-To: <4923F347.1090301@atomless.com> References: <4923F347.1090301@atomless.com> Message-ID: <4926C0A7.9050208@weborganics.co.uk> Hello James James Tindall wrote: > I use the xfn rel="me" to link from my personal site to sites that I > maintain and that represent me in some way but is there a microformat > I should use to link to a site I have built for a client? No microformat as such, but you can sprinkle them with a bit of POSH On your homepage: Some Website would say: made On other sites (not your own): Atomless would say the SAME thing as rev: made The last thing I may add to all that is @rev is depreciated in Microformats and HTML5, but if you mark up your pages in XHTML or HTML4 you are still good to go Best wishes -- Martin McEvoy http://weborganics.co.uk/ From mart at degeneration.co.uk Fri Nov 21 23:26:59 2008 From: mart at degeneration.co.uk (Martin Atkins) Date: Fri Nov 21 23:27:03 2008 Subject: [uf-discuss] rel="byme" In-Reply-To: <4926C0A7.9050208@weborganics.co.uk> References: <4923F347.1090301@atomless.com> <4926C0A7.9050208@weborganics.co.uk> Message-ID: <4927B443.3020206@degeneration.co.uk> Martin McEvoy wrote: > > On your homepage: Some > Website > [snip] > > The last thing I may add to all that is @rev is depreciated in > Microformats and HTML5, but if you mark up your pages in XHTML or HTML4 > you are still good to go > Per a recent discussion on the HTML WG list, the recommendation is to use rel="author" instead of rev="made". From mephtu at gmail.com Sat Nov 22 01:15:41 2008 From: mephtu at gmail.com (Samuel Richter) Date: Sat Nov 22 01:15:52 2008 Subject: [uf-discuss] Google Code microformat? Message-ID: <772a8cc20811220115x79836b33t5a76366a1f17aa60@mail.gmail.com> Please excuse me if this is not the appropriate mailing list or if this has already been discussed (the archives have no search feature.) It seems that Google Code is using some sort of microformat in their project feeds. I happened to look at the Atom source for a given project's update feed and saw this. Any one want to confirm/comment on this? -Sam From mail at tobyinkster.co.uk Sat Nov 22 01:59:55 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Nov 22 02:00:34 2008 Subject: [uf-discuss] Google Code microformat? Message-ID: <0D4E77B4-B2C9-4AB9-AA65-1C5B3FE5A98F@tobyinkster.co.uk> If you're talking about their use of class="ot-logmessage" etc, then no, that isn't a Microformat[1]. It looks to me like the reason those particular classes are present in the project updates Atom feed is that the feed is generated by the same code that generates the project updates HTML file, where these classes seems to be mainly present as hooks for CSS and Javascript. If you're looking for a way to markup feeds, then use hAtom[2]. If you're looking for a way to markup software projects, then perhaps you should look at hDOAP[3]. ____ 1. http://microformats.org/wiki/Category:Specifications http://microformats.org/wiki/Category:Draft_Specifications 2. http://microformats.org/wiki/hAtom 3. http://purl.org/stuff/hdoap/profile -- Toby A Inkster From mephtu at gmail.com Sat Nov 22 06:13:10 2008 From: mephtu at gmail.com (Samuel Richter) Date: Sat Nov 22 06:13:12 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? Message-ID: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> I read some blog posts this morning on microformats and a common concern (and I feel a legitimate one) is the "scraping of hCard's from web sites for future generations of spammers." I believe that fear, if left unaddressed, will kill the microformat effort. Has there been any discussion of this? From martin at weborganics.co.uk Sat Nov 22 06:10:43 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 22 06:17:39 2008 Subject: [uf-discuss] rel="byme" In-Reply-To: <4927B443.3020206@degeneration.co.uk> References: <4923F347.1090301@atomless.com> <4926C0A7.9050208@weborganics.co.uk> <4927B443.3020206@degeneration.co.uk> Message-ID: <492812E3.5060906@weborganics.co.uk> Martin Atkins wrote: > Martin McEvoy wrote: >> >> On your homepage: Some >> Website >> > [snip] >> >> The last thing I may add to all that is @rev is depreciated in >> Microformats and HTML5, but if you mark up your pages in XHTML or >> HTML4 you are still good to go >> > > Per a recent discussion on the HTML WG list, the recommendation is to > use rel="author" instead of rev="made". Do you use HTML5 on your clients websites? I looked at your website and it was XHTML STRICT in which case you can use rev=made without any problems, I also have also been informed (from various sources), that @rev may make a comeback in HTML5 eventually, so really I don't see any harm in using rev=made (for at least the next four years anyway), lastly the reason why @rev was dropped by the HTML WG was because people were not (on the whole) using it correctly, so I am taking the opportunity t inform people HOW to use it Correctly as the concept is not too difficult is it? > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss -- Martin McEvoy http://weborganics.co.uk/ From mephtu at gmail.com Sat Nov 22 06:09:09 2008 From: mephtu at gmail.com (Samuel Richter) Date: Sat Nov 22 06:36:28 2008 Subject: [uf-discuss] Google Code microformat? In-Reply-To: <0D4E77B4-B2C9-4AB9-AA65-1C5B3FE5A98F@tobyinkster.co.uk> References: <0D4E77B4-B2C9-4AB9-AA65-1C5B3FE5A98F@tobyinkster.co.uk> Message-ID: <772a8cc20811220609l3b3225b5sc246184d4725bdb3@mail.gmail.com> It seems to me that both hAtom and hDOAP present limitations of a sort when it comes to providing feeds for software updates. On the one hand with hAtom, you have a generic microformat with no way of identifying any content beyond it merely being feed content and with hDOAP, you have no mechanism for providing update information. Do you see the gap I'm trying to show? -Sam On Sat, Nov 22, 2008 at 4:59 AM, Toby A Inkster wrote: > If you're talking about their use of class="ot-logmessage" etc, then no, > that isn't a Microformat[1]. > > It looks to me like the reason those particular classes are present in the > project updates Atom feed is that the feed is generated by the same code > that generates the project updates HTML file, where these classes seems to > be mainly present as hooks for CSS and Javascript. > > If you're looking for a way to markup feeds, then use hAtom[2]. If you're > looking for a way to markup software projects, then perhaps you should look > at hDOAP[3]. > > ____ > 1. http://microformats.org/wiki/Category:Specifications > http://microformats.org/wiki/Category:Draft_Specifications > 2. http://microformats.org/wiki/hAtom > 3. http://purl.org/stuff/hdoap/profile > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From andr3.pt at gmail.com Sat Nov 22 06:44:48 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Sat Nov 22 06:44:52 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> Message-ID: Samuel, Yes, it's a recurring concern, however, microformats don't deal with authorization. That's stuff for other protocols (openid, oauth). What they do is markup existing data, stuff that you're already publishing. Now, you can establish a scenario where public hcards only markup a small amount of information (fn, url, country...) but, if on your website you have a social network, you can reveal more data to your friends. ie, if one of your friends is logged in and visits your profile, your data is far more detailed: (fn, email, full address, date of birth, etc). Or you can use a whitelist of openids that can access your full details. The point is... microformats allow you to represent data in recognizable fashion. How you decide how many information to publish, is out of the scope of microformats. At least, this is how I see it and how it's been discussed here before. Please, correct me, anyone, if I'm wrong. Cheers, Andr? Lu?s On Sat, Nov 22, 2008 at 2:13 PM, Samuel Richter wrote: > I read some blog posts this morning on microformats and a common > concern (and I feel a legitimate one) is the "scraping of hCard's from > web sites for future generations of spammers." I believe that fear, > if left unaddressed, will kill the microformat effort. Has there been > any discussion of this? > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From davidjanes at blogmatrix.com Sat Nov 22 06:45:29 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 22 06:45:31 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> Message-ID: <21e523c20811220645w3aaf3f28vc9e8433db841c234@mail.gmail.com> On Sat, Nov 22, 2008 at 9:13 AM, Samuel Richter wrote: > > I read some blog posts this morning on microformats and a common > concern (and I feel a legitimate one) is the "scraping of hCard's from > web sites for future generations of spammers." I believe that fear, > if left unaddressed, will kill the microformat effort. Has there been > any discussion of this? You weren't going to fill us in on the URLs, were you? -- David Janes Mercenary Programmer http://code.davidjanes.com From davidjanes at blogmatrix.com Sat Nov 22 06:55:51 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 22 06:55:55 2008 Subject: [uf-discuss] Google Code microformat? In-Reply-To: <772a8cc20811220609l3b3225b5sc246184d4725bdb3@mail.gmail.com> References: <0D4E77B4-B2C9-4AB9-AA65-1C5B3FE5A98F@tobyinkster.co.uk> <772a8cc20811220609l3b3225b5sc246184d4725bdb3@mail.gmail.com> Message-ID: <21e523c20811220655r2aae6416xc0fa616da97d4d3e@mail.gmail.com> On Sat, Nov 22, 2008 at 9:09 AM, Samuel Richter wrote: > It seems to me that both hAtom and hDOAP present limitations of a sort > when it comes to providing feeds for software updates. On the one > hand with hAtom, you have a generic microformat with no way of > identifying any content beyond it merely being feed content and with > hDOAP, you have no mechanism for providing update information. Do you > see the gap I'm trying to show? It's rather difficult to discuss this in the abstract, without a real world example to pin it against. The utility of the markup is often as much defined by _it's use_ and _it's user_ as anything: if you know that http://projects.example.com lists has project information that's marked up in hAtom, then that's very different than if you don't care about projects or that page. Note that hAtom's purpose is not to provide "feeds" for anything: it's a way of semantically marking up certain types of data on pages. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Sat Nov 22 07:23:02 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 22 07:23:21 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> Message-ID: <492823D6.4050607@weborganics.co.uk> Hello Samuel Samuel Richter wrote: > I read some blog posts this morning on microformats and a common > concern (and I feel a legitimate one) is the "scraping of hCard's from > web sites for future generations of spammers." I believe that fear, > if left unaddressed, will kill the microformat effort. Has there been > any discussion of this? > The point about microformats is they allow you to mark up things that already exist, microformats document current usage patterns. People, organizations, buisnesses publish their e-mail addresses all the time, much more than they publish hcards, so really the problem isn't the humble hcard or microformats its how emails are published, that all aside If you don't want people on the web to be able to scrape your email address don't publish it. Best wishes -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Sat Nov 22 07:35:22 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 22 07:35:29 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <492823D6.4050607@weborganics.co.uk> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> <492823D6.4050607@weborganics.co.uk> Message-ID: <492826BA.9090508@weborganics.co.uk> Martin McEvoy wrote: > Hello Samuel > Samuel Richter wrote: >> I read some blog posts this morning on microformats and a common >> concern (and I feel a legitimate one) is the "scraping of hCard's from >> web sites for future generations of spammers." I believe that fear, >> if left unaddressed, will kill the microformat effort. Has there been >> any discussion of this? >> > The point about microformats is they allow you to mark up things that > already exist, microformats document current usage patterns. > > People, organizations, buisnesses publish their e-mail addresses all > the time, much more than they publish hcards, so really the problem > isn't the humble hcard or microformats its how emails are published, > that all aside If you don't want people on the web to be able to > scrape your email address don't publish it. > There was a discussion about hCard and Spam here: http://microformats.org/discuss/mail/microformats-discuss/2005-July/000382.html that you may find informative. -- Martin McEvoy http://weborganics.co.uk/ From scott at randomchaos.com Sat Nov 22 10:19:31 2008 From: scott at randomchaos.com (Scott Reynen) Date: Sat Nov 22 10:19:40 2008 Subject: [uf-discuss] Google Code microformat? In-Reply-To: <772a8cc20811220609l3b3225b5sc246184d4725bdb3@mail.gmail.com> References: <0D4E77B4-B2C9-4AB9-AA65-1C5B3FE5A98F@tobyinkster.co.uk> <772a8cc20811220609l3b3225b5sc246184d4725bdb3@mail.gmail.com> Message-ID: <298E0B80-6B37-4522-8002-D4D9EE417CCD@randomchaos.com> On [Nov 22], at [ Nov 22] 7:09 , Samuel Richter wrote: > It seems to me that both hAtom and hDOAP present limitations of a sort > when it comes to providing feeds for software updates. On the one > hand with hAtom, you have a generic microformat with no way of > identifying any content beyond it merely being feed content and with > hDOAP, you have no mechanism for providing update information. Do you > see the gap I'm trying to show? Microformats are made to be modular. Using both together would seem to remove the gap you've described. But as David said, because this is all very abstract, it's hard to tell if this would actually meet your needs. Peace, Scott From danbri at danbri.org Sun Nov 23 10:59:58 2008 From: danbri at danbri.org (Dan Brickley) Date: Sun Nov 23 11:00:04 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> Message-ID: <4929A82E.7010107@danbri.org> Samuel Richter wrote: > I read some blog posts this morning on microformats and a common > concern (and I feel a legitimate one) is the "scraping of hCard's from > web sites for future generations of spammers." I believe that fear, > if left unaddressed, will kill the microformat effort. Has there been > any discussion of this? This is certainly a problem we have encountered with FOAF, which shares a lot of characteristics with microformats. For example, the FOAF feeds on tribe.net were taken down, 'cos users didn't like having their data re-aggregated and published elsewhere (such as on explode.us). In this scenerio the user doesn't even need spammable info in their FOAF or hCard to be upset, they just don't want the suprise of seeing their data appear elsewhere without warning. My take is that we need to create incentives that benefit users, such as the ability to say 'sure, re-post my stuff, but on the condition of x', for some plausible 'x'. Such as 'post this chunk of banner-ad html a fair % of the time too, perhaps. cheers, Dan -- http://danbri.org/ From tantek at cs.stanford.edu Sun Nov 23 11:15:30 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Sun Nov 23 11:16:10 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <4929A82E.7010107@danbri.org> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com><4929A82E.7010107@danbri.org> Message-ID: <1913139024-1227467764-cardhu_decombobulator_blackberry.rim.net-2101159177-@bxe346.bisx.prod.on.blackberry> This is also a classic visible data (eg on HTML pages) vs invisible data (eg at URLs not linked to or at least not easily viewable in browsers in random/rare(r) XML formats) probem. The more visible the data, the less likely users will be surprised by having data they may have thought was private (because they didn't see it on the web) be scraped, aggregated, indexed, republished. When data *is* visible that users don't feel comfortable publishing, they take steps to remove or make it private. Hence we discourage publishing of invisible data. It's user unfriendly, and leads to far more frequent violations of user expectations. Tantek -----Original Message----- From: Dan Brickley Date: Sun, 23 Nov 2008 19:59:58 To: Microformats Discuss Subject: Re: [uf-discuss] hCard slowing adoption of microformats? Samuel Richter wrote: > I read some blog posts this morning on microformats and a common > concern (and I feel a legitimate one) is the "scraping of hCard's from > web sites for future generations of spammers." I believe that fear, > if left unaddressed, will kill the microformat effort. Has there been > any discussion of this? This is certainly a problem we have encountered with FOAF, which shares a lot of characteristics with microformats. For example, the FOAF feeds on tribe.net were taken down, 'cos users didn't like having their data re-aggregated and published elsewhere (such as on explode.us). In this scenerio the user doesn't even need spammable info in their FOAF or hCard to be upset, they just don't want the suprise of seeing their data appear elsewhere without warning. My take is that we need to create incentives that benefit users, such as the ability to say 'sure, re-post my stuff, but on the condition of x', for some plausible 'x'. Such as 'post this chunk of banner-ad html a fair % of the time too, perhaps. cheers, Dan -- http://danbri.org/ _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From danbri at danbri.org Sun Nov 23 11:47:31 2008 From: danbri at danbri.org (Dan Brickley) Date: Sun Nov 23 11:47:37 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <1913139024-1227467764-cardhu_decombobulator_blackberry.rim.net-2101159177-@bxe346.bisx.prod.on.blackberry> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com><4929A82E.7010107@danbri.org> <1913139024-1227467764-cardhu_decombobulator_blackberry.rim.net-2101159177-@bxe346.bisx.prod.on.blackberry> Message-ID: <4929B353.3080706@danbri.org> Hi Tantek, Tantek Celik wrote: > This is also a classic visible data (eg on HTML pages) vs invisible data (eg at URLs not linked to or at least not easily viewable in browsers in random/rare(r) XML formats) probem. > > The more visible the data, the less likely users will be surprised by having data they may have thought was private (because they didn't see it on the web) be scraped, aggregated, indexed, republished. > > When data *is* visible that users don't feel comfortable publishing, they take steps to remove or make it private. > > Hence we discourage publishing of invisible data. It's user unfriendly, and leads to far more frequent violations of user expectations. I generally agree. We discourage people from exposing anything in FOAF that isn't otherwise available in textual form in public HTML. While it seems (I never got the details confirmed before it was switched off) that Tribe may have exposed more in the RDF/XML than in the HTML, from reading through the many user comments it was the wholesale-ness of the thing that really upset people. It looked like their entire profile *and* those of their buddies had been copied/cloned. This could have equally well have been accomplished through use of curl/wget and some scraping tools, and most users wouldn't have been any the wiser, or any the happier. You can make your own mind up here, http://brainstorm.tribe.net/thread/34fb1a79-351d-4251-8318-829623c1c9cb The initial post is pretty indicative of the tone, "Can someone please tell me why my bio and all of my tribe friends are listed on a site I have never been to or heard of? I didn't think this was Tribes style. I feel cheated and betrayed. If I wanted my profile to be farmed out, I would join Facebook." Short of keeping all public profile data buried inside hard-to-parse GIFs, any markup describing profiles and linking to buddies is at risk of being 'exploited' in just this way. I think the main reason we haven't seen many complaints (about FOAF or hCard+XFN) is not the visible/invisible issue, but simply that there aren't many sites who have taken a "download the entire set of people descriptions and re-assemble them on another site" approach. Thankfully. cheers, Dan -- http://danbri.org/ From mail at tobyinkster.co.uk Mon Nov 24 01:57:47 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Nov 24 01:58:07 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? Message-ID: <3FB91874-F8C8-4B30-89ED-AE97A9EA9CD1@tobyinkster.co.uk> People might be interested in the FOAF+SSL discussions happening on the foaf-protocols mailing list at http://lists.foaf-project.org. The basic idea is to have a public profile and a private profile; the public profile contains a link to the private profile, which resides on an HTTPS server; access to the private profile is granted only after authentication using an SSL client certificate; the client certificate itself contains a link to the client's public profile; data in the client's public profile can be used by the server to determine access rights to the server private profile. The "FOAF" part of the name comes from the client's public profile, which needs to be written in RDF using FOAF+extensions. This doesn't necessarily mean RDF/XML - RDFa could be used, or hCard+GRDDL. If this is something that makes you think "awesome!", then sign up to the foaf-protocols mailing list. -- Toby A Inkster From gerald at vanbeta.com Wed Nov 26 11:09:17 2008 From: gerald at vanbeta.com (Gerald Bauer) Date: Wed Nov 26 11:09:21 2008 Subject: [uf-discuss] Monthly Microformats Meetup in Vancouver, B.C - Wed, Nov/26 @ WorkSpace Message-ID: <1f058eab0811261109q57b5834q938acf0f4d64bc47@mail.gmail.com> Hello, If you're in the Vancouver-area in British Columbia in Western Canada you're invited to join us for Vancouver's 2nd (and now monthly) Semantic Web meetup. I volunteered to prepare a short segment on adding semantics to business cards and contact info (using hCard, XFN, FOAF and friends). More details @ http://upcoming.yahoo.com/event/1317700 Free and open to all. Cheers. -- Gerald Bauer - Internet Professional - http://geraldbauer.ca From mephtu at gmail.com Fri Nov 28 13:25:32 2008 From: mephtu at gmail.com (Samuel Richter) Date: Fri Nov 28 13:25:35 2008 Subject: [uf-discuss] Google Code microformat? In-Reply-To: <21e523c20811220655r2aae6416xc0fa616da97d4d3e@mail.gmail.com> References: <0D4E77B4-B2C9-4AB9-AA65-1C5B3FE5A98F@tobyinkster.co.uk> <772a8cc20811220609l3b3225b5sc246184d4725bdb3@mail.gmail.com> <21e523c20811220655r2aae6416xc0fa616da97d4d3e@mail.gmail.com> Message-ID: <772a8cc20811281325s644f3d82hd4774a04e881869e@mail.gmail.com> Dude, you are giving me a headache. On Sat, Nov 22, 2008 at 9:55 AM, David Janes wrote: > On Sat, Nov 22, 2008 at 9:09 AM, Samuel Richter wrote: >> It seems to me that both hAtom and hDOAP present limitations of a sort >> when it comes to providing feeds for software updates. On the one >> hand with hAtom, you have a generic microformat with no way of >> identifying any content beyond it merely being feed content and with >> hDOAP, you have no mechanism for providing update information. Do you >> see the gap I'm trying to show? > > It's rather difficult to discuss this in the abstract, without a real > world example to pin it against. > > The utility of the markup is often as much defined by _it's use_ and > _it's user_ as anything: if you know that http://projects.example.com > lists has project information that's marked up in hAtom, then that's > very different than if you don't care about projects or that page. > > Note that hAtom's purpose is not to provide "feeds" for anything: it's > a way of semantically marking up certain types of data on pages. > > Regards, etc... > > -- > David Janes > Mercenary Programmer > http://code.davidjanes.com > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mephtu at gmail.com Fri Nov 28 13:26:47 2008 From: mephtu at gmail.com (Samuel Richter) Date: Fri Nov 28 13:26:51 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> Message-ID: <772a8cc20811281326i21b712f6qc33a0f5aa45f32b7@mail.gmail.com> Elegant. On Sat, Nov 22, 2008 at 9:44 AM, Andr? Lu?s wrote: > Samuel, > > Yes, it's a recurring concern, however, microformats don't deal with > authorization. That's stuff for other protocols (openid, oauth). What > they do is markup existing data, stuff that you're already publishing. > > Now, you can establish a scenario where public hcards only markup a > small amount of information (fn, url, country...) but, if on your > website you have a social network, you can reveal more data to your > friends. ie, if one of your friends is logged in and visits your > profile, your data is far more detailed: (fn, email, full address, > date of birth, etc). > > Or you can use a whitelist of openids that can access your full details. > > The point is... microformats allow you to represent data in > recognizable fashion. How you decide how many information to publish, > is out of the scope of microformats. > > At least, this is how I see it and how it's been discussed here > before. Please, correct me, anyone, if I'm wrong. > > Cheers, > Andr? Lu?s > > On Sat, Nov 22, 2008 at 2:13 PM, Samuel Richter wrote: >> I read some blog posts this morning on microformats and a common >> concern (and I feel a legitimate one) is the "scraping of hCard's from >> web sites for future generations of spammers." I believe that fear, >> if left unaddressed, will kill the microformat effort. Has there been >> any discussion of this? >> _______________________________________________ >> microformats-discuss mailing list >> microformats-discuss@microformats.org >> http://microformats.org/mailman/listinfo/microformats-discuss >> > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mephtu at gmail.com Fri Nov 28 13:37:00 2008 From: mephtu at gmail.com (Samuel Richter) Date: Fri Nov 28 13:37:04 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <4929A82E.7010107@danbri.org> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> <4929A82E.7010107@danbri.org> Message-ID: <772a8cc20811281337r5fdf12doc540c815ad7d132a@mail.gmail.com> I'm thinking about how a mechanism that will enforce the integrity of the "friendship chain" on something like FOAF could be implemented. Obviously it happens that someone whom you thought to be a friend turns out to exploit the friend network. It seems to pose a new spin on the issue of trust and the internet which hasn't been considered much and may not be limited to the domain of FOAF. This is beyond me at the moment but, it seems an eager university computer science department somewhere might want to tackle it. -Sam On Sun, Nov 23, 2008 at 1:59 PM, Dan Brickley wrote: > Samuel Richter wrote: >> >> I read some blog posts this morning on microformats and a common >> concern (and I feel a legitimate one) is the "scraping of hCard's from >> web sites for future generations of spammers." I believe that fear, >> if left unaddressed, will kill the microformat effort. Has there been >> any discussion of this? > > This is certainly a problem we have encountered with FOAF, which shares a > lot of characteristics with microformats. For example, the FOAF feeds on > tribe.net were taken down, 'cos users didn't like having their data > re-aggregated and published elsewhere (such as on explode.us). In this > scenerio the user doesn't even need spammable info in their FOAF or hCard to > be upset, they just don't want the suprise of seeing their data appear > elsewhere without warning. > > My take is that we need to create incentives that benefit users, such as the > ability to say 'sure, re-post my stuff, but on the condition of x', for some > plausible 'x'. Such as 'post this chunk of banner-ad html a fair % of the > time too, perhaps. > > cheers, > > Dan > > -- > http://danbri.org/ > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mephtu at gmail.com Fri Nov 28 13:48:38 2008 From: mephtu at gmail.com (Samuel Richter) Date: Fri Nov 28 13:48:42 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <21e523c20811220645w3aaf3f28vc9e8433db841c234@mail.gmail.com> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> <21e523c20811220645w3aaf3f28vc9e8433db841c234@mail.gmail.com> Message-ID: <772a8cc20811281348g171a235cxa1ee5b772a9c8e19@mail.gmail.com> How's this...? Using gmail, I happened to spy a list of supported links, here's one of them: Custom Web Scraping Data Extraction & Mining Service Buy up to 20,000 Records for $75.00 RightHandMarketingManagement.com This reinforces the seriousness of the issue in my mind. If hCards are used as indiscriminately as the data in these websites, it would just pipeline the same information to companies of this ilk. -Sam On Sat, Nov 22, 2008 at 9:45 AM, David Janes wrote: > On Sat, Nov 22, 2008 at 9:13 AM, Samuel Richter wrote: >> >> I read some blog posts this morning on microformats and a common >> concern (and I feel a legitimate one) is the "scraping of hCard's from >> web sites for future generations of spammers." I believe that fear, >> if left unaddressed, will kill the microformat effort. Has there been >> any discussion of this? > > You weren't going to fill us in on the URLs, were you? > > > > -- > David Janes > Mercenary Programmer > http://code.davidjanes.com > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From tantek at cs.stanford.edu Fri Nov 28 14:58:15 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Fri Nov 28 14:58:59 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <772a8cc20811281348g171a235cxa1ee5b772a9c8e19@mail.gmail.com> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com><21e523c20811220645w3aaf3f28vc9e8433db841c234@mail.gmail.com><772a8cc20811281348g171a235cxa1ee5b772a9c8e19@mail.gmail.com> Message-ID: <1925086809-1227913130-cardhu_decombobulator_blackberry.rim.net-1730898643-@bxe346.bisx.prod.on.blackberry> Such companies are already going to far greater extents to scrape anything resembling contact information (without really caring about false positives etc since as your quotes point out quantity is their game) from text, HTML etc on the web using text entity recognizers etc. As long as you only markup already public information with hCard (or any other microformat), the effect is negligible on such companies, while it enables and benefits users and developers of user-centric apps, thus providing a net positive effect. Tantek -----Original Message----- From: "Samuel Richter" Date: Fri, 28 Nov 2008 16:48:38 To: Microformats Discuss Subject: Re: [uf-discuss] hCard slowing adoption of microformats? How's this...? Using gmail, I happened to spy a list of supported links, here's one of them: Custom Web Scraping Data Extraction & Mining Service Buy up to 20,000 Records for $75.00 RightHandMarketingManagement.com This reinforces the seriousness of the issue in my mind. If hCards are used as indiscriminately as the data in these websites, it would just pipeline the same information to companies of this ilk. -Sam On Sat, Nov 22, 2008 at 9:45 AM, David Janes wrote: > On Sat, Nov 22, 2008 at 9:13 AM, Samuel Richter wrote: >> >> I read some blog posts this morning on microformats and a common >> concern (and I feel a legitimate one) is the "scraping of hCard's from >> web sites for future generations of spammers." I believe that fear, >> if left unaddressed, will kill the microformat effort. Has there been >> any discussion of this? > > You weren't going to fill us in on the URLs, were you? > > > > -- > David Janes > Mercenary Programmer > http://code.davidjanes.com > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From tantek at cs.stanford.edu Fri Nov 28 16:11:07 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Fri Nov 28 16:11:09 2008 Subject: [uf-discuss] hCard slowing adoption of microformats? In-Reply-To: <1440382721-1227470634-cardhu_decombobulator_blackberry.rim.net-462950338-@bxe346.bisx.prod.on.blackberry> References: <772a8cc20811220613h53afc49bx8d735858c7335aef@mail.gmail.com> <4929A82E.7010107@danbri.org> <1913139024-1227467764-cardhu_decombobulator_blackberry.rim.net-2101159177-@bxe346.bisx.prod.on.blackberry> <4929B353.3080706@danbri.org> <1440382721-1227470634-cardhu_decombobulator_blackberry.rim.net-462950338-@bxe346.bisx.prod.on.blackberry> Message-ID: <60cb038a0811281611v2d2e890dk153ba7db68e26d86@mail.gmail.com> Originally sent as a private reply, though I had intended it for the list. ---------- Forwarded message ---------- Date: Sun, Nov 23, 2008 at 12:03 PM Subject: Re: [uf-discuss] hCard slowing adoption of microformats? Dan, I do know of several instances (since corrected so I won't name names) of sites w 1000s to millions of users publishing birthdays, emails, and emailhashes (which can be used to perform unintended identity consolidation) in their FOAF files (while not on visible profile pages). The problem is that web pages are typically designed by web designers who take a very strong user-centric (privacy, expectations etc) perspective, whereas abstract format files are written by programmers, and to them such files look like a form to be filled out from a database query, so they happily do so, empirically often without considering user perspectives. Thus another tendency for such invisible data (and invisible data formats) to induce leakage of private data from databases, simply by how their design itself influences the population that supports/publishes/programs them. Republishing is a challenge for all data on the web, but users understand copy & paste of visible text on the web. They're surprised when private details become public. There is also "quantity surprise" effect when people see 1000s of pieces of text being copy/pasted/indexed, and currently the Google SG API is providing an interesting test of that expectation wrt XFN. So far the anecdotal surprises about SGAPI have been far more "wow cool" than "yikes creepy". We'll see what happens when we see web-wide hCard fielded search (more than just raw search as Y! Searchmonkey supports). Tantek -----Original Message----- From: Dan Brickley Date: Sun, 23 Nov 2008 20:47:31 To: ; Microformats Discuss Subject: Re: [uf-discuss] hCard slowing adoption of microformats? Hi Tantek, Tantek Celik wrote: > This is also a classic visible data (eg on HTML pages) vs invisible data (eg at URLs not linked to or at least not easily viewable in browsers in random/rare(r) XML formats) probem. > > The more visible the data, the less likely users will be surprised by having data they may have thought was private (because they didn't see it on the web) be scraped, aggregated, indexed, republished. > > When data *is* visible that users don't feel comfortable publishing, they take steps to remove or make it private. > > Hence we discourage publishing of invisible data. It's user unfriendly, and leads to far more frequent violations of user expectations. I generally agree. We discourage people from exposing anything in FOAF that isn't otherwise available in textual form in public HTML. While it seems (I never got the details confirmed before it was switched off) that Tribe may have exposed more in the RDF/XML than in the HTML, from reading through the many user comments it was the wholesale-ness of the thing that really upset people. It looked like their entire profile *and* those of their buddies had been copied/cloned. This could have equally well have been accomplished through use of curl/wget and some scraping tools, and most users wouldn't have been any the wiser, or any the happier. You can make your own mind up here, http://brainstorm.tribe.net/thread/34fb1a79-351d-4251-8318-829623c1c9cb The initial post is pretty indicative of the tone, "Can someone please tell me why my bio and all of my tribe friends are listed on a site I have never been to or heard of? I didn't think this was Tribes style. I feel cheated and betrayed. If I wanted my profile to be farmed out, I would join Facebook." Short of keeping all public profile data buried inside hard-to-parse GIFs, any markup describing profiles and linking to buddies is at risk of being 'exploited' in just this way. I think the main reason we haven't seen many complaints (about FOAF or hCard+XFN) is not the visible/invisible issue, but simply that there aren't many sites who have taken a "download the entire set of people descriptions and re-assemble them on another site" approach. Thankfully. cheers, Dan -- http://danbri.org/ From lists at isofarro.uklinux.net Sun Nov 30 10:41:02 2008 From: lists at isofarro.uklinux.net (Isofarro) Date: Sun Nov 30 10:41:40 2008 Subject: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern In-Reply-To: References: <49171EC1.70007@isofarro.uklinux.net> Message-ID: <4932DE3E.6020609@isofarro.uklinux.net> Ben Ward wrote: > Hi Mike, > > On 9 Nov 2008, at 09:32, Isofarro wrote: > >> Where a value-classed span is used and a human friendly wording is >> used as inner text, then in case 2.) the machine formatted data is >> read out, but not the human-readable version, and in case 3.) the >> machine formatted data is read out before or after the human friendly >> data. >> >> So the accessibility barriers that are created are: >> >> 1.) machine-formatted data is being read out to screen reader users >> 2.) machine-formatted data is being read out, and its human digestible >> format isn't. >> >> Both cases result in content that is more difficult to understand, but >> case 2 is actually worse - it replaces human readable content with >> machine readable content. Both introduce accessibility barriers, just >> one does more damage than the other. > > So, I believe I'm reading this right that you're describing a > value-classed + inner text + title situation all on the same element, > and *not* where you have the value-classed element as an empty sibling > of the human form (which is what the current proposal specifies)? I'm describing these cases: Human friendly content and The first, in many cases where the title is configured to be read by a screen reader, will replace the "Human friendly content", and in other cases be read before or after the "Human friendly content". The second case, machine formatted data in many configurations will be injected into the reading order of a screen reader. >> With this in mind, from an accessibility perspective, any microformat >> pattern which results in machine-formatted or human-unfriendly content >> in an area that is supposed to be human consumable is going to create >> one barrier or the other, depending on screen reader configuration. So >> the logical approach to protecting the accessibility of the page in >> these cases is not to use any microformat that specifies adding >> machine data into a human-visible region of the page. > > > Again for clarity, could you confirm whether the proposed pattern falls > into your definition of introducing machine-data into a human-visible > region of the page, given that the empty elements are ignored in the > page rendering. > > e.g, in hAtom: > > title="20081116T073000+0800">16th November 2008, 7:30am Falls into the definition - there's machine data in the title attribute, so there is a definite chance of those characters being read out in a screen reader. Mike.