[uf-discuss] added hReview-aggregate and rel-author as drafts, archived a few others, uf2 for new ufs
New drafts, archived drafts/spec, and new microformats in general. 1. New drafts. Since both: * hReview-aggregate * rel-author have shown fairly broad publishing support, and are consumed by popular/mainstream sites/applications (e.g. search engines), I've added them as Drafts per the microformats process[1]. http://microformats.org/wiki/#Drafts 2. Archived drafts/spec In addition, I created a new section Archived (Ben Ward's suggestion) to collect microformats that haven't really taken off, that is appear to lack any major publishing/consuming support and have moved the following there: http://microformats.org/wiki/#Archived * hAudio * rel-directory * rel-enclosure * robots exclusion * VoteLinks * xFolk If anyone knows of major publishing support or major consuming support for any of these, please add links to such sites/applications to the spec pages' respective Examples in the Wild *-examples-in-wild or Implementation *-implementations sections/pages respectively and we can reconsider accordingly, or perhaps they'll be used as informative data/research in the development of future microformats. For more on this see: http://microformats.org/wiki/process#related_issues_questions_regarding_document_stages 3. new microformats in general - let's use microformats2 syntax only. While the subtopic of new microformats in general may be more appropriate for microformats-new (and perhaps we can fork it there if discussion appears substantial), I thought it made sense to introduce this within the broader context of microformat spec transitions (forward/backward) in general and thus it's here. Since microformats2 has been stable for quite some time now and we're starting to see publishing on individual and organization sites [2], for all the advantages[3] provided by microformats2 over classic microformats, at this point I think it makes the most sense to develop any new microformats using microformat2 syntax *only*, and that includes any exploratory discussions in progress[4]. As an example of this I'm restarting the citation microformat effort[5], with a simplified proposal using microformats2 syntax, based on an in-person brainstorm of a serendipitous meeting of web-citation-interested-parties during the recent IndieWebCamp 2012.[6] I'll follow-up with that on the microformats-new list when I've posted a new proposal to the wiki. Thanks, Tantek [1] http://microformats.org/wiki/process#Moving_from_Stage_to_Stage [2] http://microformats.org/wiki/uf2#Examples_in_the_wild [3] http://microformats.org/wiki/uf2#ADVANTAGES [4] http://microformats.org/wiki/exploratory-discussions [5] http://microformats.org/wiki/citation [6] http://indiewebcamp.com/2012/Academic_Citations_Web ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [microformats-2] e-* values and the JSON serialization
On Thu, Dec 15, 2011 at 10:41, Edward O'Connor hob...@gmail.com wrote: Hi, The Microformats 2 page doesn't yet contain a definition of the JSON serialization algorithm. When it does get written down, the algorithm should specify that e-* properties (whose value is the DOM descendents of the element) get serialized using the Serializing HTML Fragments algorithm in the HTML spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments Excellent suggestion. I've added it as part of the special parsing required for e-* properties here: http://microformats.org/wiki/microformats-2#naming_conventions_for_generic_parsing Thanks, Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Curriculum Vitae (resumé) schema
That's quite a good list of resources Dan! Specifically, you mentioned: As usual, the Microformats community have already been quite active in researching this topic; you should check out http://microformats.org/wiki/resume-formats and if you prefer to keep notes in their (public domain licensed) wiki, that's great; just drop in a link from the W3C page. Or add to both. I'd like to reiterate that invitation to everyone, please feel free to add any known/previous formats for resumes to existing public domain microformats research on the subject, and use existing research as you see fit - that's what it's there for as a community resource: http://microformats.org/wiki/resume-formats But there's one big link that Dan surprisingly missed: hResume http://microformats.org/wiki/hresume Developed using aforementioned research in combination with research on actual resume publishing practices on the web. Two key things here: 1. hResume is the most published resume format on the web (for several years now) http://microformats.org/wiki/hresume-examples-in-wild from over 10 million resumes on LinkedIn - all marked up with hResume to numerous long tail examples, tons of individuals who've posted their resumes online with hResume. If you're looking at writing a resume search or similar application, that's a good place to start. 2. hResume is also well implemented, with numerous generating and parsing/consuming applications/sites. E.g the Guardian's jobs/resume aggregator site imports hResumes: http://jobs.guardian.co.uk/profile/ More listed here: http://microformats.org/wiki/hresume#Implementations Take a look and see if hResume works for your Curriculum Vitae (resumé) schema purposes, if it doesn't please send feedback about what problems/issues you run into so that it can be improved accordingly. As this is already a vocabulary (and format) in wide usage, I'm cc-ing microformats-discuss for feedback/iteration. Feel free to join irc://irc.freenode.net/microformats for more real-time follow-up/discussion. Thanks, Tantek 2011/10/7 Dan Brickley dan...@danbri.org: +Cc: Uldis, who worked on this topic a while back 2011/10/7 George Katsanos gkatsa...@gmail.com: Dear all, Wouldn't it be possible to have a schema template (type?) for semantically describing CV's? It would also be a good opportunity for the job recruiting market to adopt this standard as currently the situation is chaotic between different file formats. There has been a little discussion of this already, e.g. http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/b7b6f259bd726047/f991c2097fd08667?lnk=gstq=CV#f991c2097fd08667 Let's break this into two parts. First, what's out there in terms of existing vocabularies, standards and data. Secondly, whether the Schema.org project (or others) decide to pick this up and include directly. Can I persuade you to help test out our new tooling by getting set up with a W3C account (http://www.w3.org/Help/Account/) and doing some background research in the Wiki? Just make a page near http://www.w3.org/wiki/WebSchemas and link it (we should sort out a category structure at some point...). Some related work: * http://en.wikipedia.org/wiki/Description_of_a_Career (designed to be compatible with the European curriculum (Europass) ) http://schemapedia.com/schemas/doac * http://rdfs.org/resume-rdf/ http://www.w3.org/2001/sw/Europe/events/foaf-galway/papers/pp/extending_foaf_with_resume/ * Europass / CV, http://europass.cedefop.europa.eu/europass/home/vernav/Europass+Documents/Europass+CV.csp http://myeurocv.com/ As usual, the Microformats community have already been quite active in researching this topic; you should check out http://microformats.org/wiki/resume-formats and if you prefer to keep notes in their (public domain licensed) wiki, that's great; just drop in a link from the W3C page. Or add to both. The hardest problem here will be scoping. We will want some way of describing topics of people's expertise, without including a giant enumeration of all skill areas. A few brief points: SKOS I'd encourage the use of SKOS here, since the library world have already created a collaborative map of most of these topics, via thesauri and subject classification schemes, most of which are now being shared in RDF via SKOS. So for example, see http://www.w3.org/2001/sw/wiki/SKOS/Datasets or http://thedatahub.org/dataset?tags=format-skos to see a high level overview of the SKOS datasets that are out there. In SKOS, we already have the Library of Congress assigning the URI http://id.loc.gov/authorities/sh85086421#concept to the notion of Model Theory. So if someone (e.g. Pat Hayes) wanted to record such expertise in their CV/resume, ideally we could re-use such a list of topics (and some would build nice auto-completion tooling to support data entry). LRMI http://wiki.creativecommons.org/LRMI The Learning Resource Metadata
Re: [uf-discuss] schema.org, microformats.org, hRecipe
2011/7/1 thomas lörtsch tho...@stray.net: Tantek, since you already contributed to this thread, would you care to comment on my original question? Or can you point me to a wiki page where it is answered already? Ok will do. Besides browsing through the microformats.org site I also fulltext-searched it for Google but couldn't find anything relevant wrt my initial question (see the first mail in this thread). Which is odd. Indeed. PS: And can you elaborate (or point me to a wiki page) how email archives on the web are NOT discoverable? See above where you wrote: fulltext-searched it for Google but couldn't find anything relevant wrt my initial question (see the first mail in this thread). Which is odd. Your statement demonstrates my point about how email archives on the web are NOT discoverable. Now, as to your specific questions: 2011/6/29 thomas lörtsch tho...@stray.net: Hi all, I don't want to discuss the schema.org effort in general here, although there surely is a lot to discuss about it. I've got about a half-dozen or so blog posts in progress strongly critiquing and debunking schema.org as an effort - there are so many things wrong with it that it's taking me a while to collect / itemize them all. I'm also trying to focus my longer analyses on what to do right rather than what schema.org has done wrong. E.g.: http://tantek.com/2011/168/b1/practices-good-open-web-standards-development If you want to discuss/critique schema.org in particular, check out: irc://irc.freenode.net/schema where the minutes for the SemTech meetup were taken. My question is how collaboration between Google.com and microformats.org is organized, where it's taking place, In short: on the wiki, irc channel, and a little on the *-discuss and *-new mailing lists, like with anybody else. who is involved. The SemTech transcript mentioned both hReview-aggregate and hRecipe as you quoted. If you google for both of those: hReview-aggregate - first result: http://microformats.org/wiki/hreview-aggregate which says right at the top: Editor Kavi Goel, Google. and: Authors/Contributers (alphabetical) ... Othar Hansson, Google hRecipe - first result: http://microformats.org/wiki/hrecipe Searching that page for Google you quickly find: Google. Launched 24th February, 2011, Recipe View search results from Google are powered by hRecipe marked-up snippets. where Recipe View links to: http://www.google.com/landing/recipes/ which doesn't say who specifically is involved. Googling for: hrecipe google 3rd result is: http://microformats.org/2011/02/24/google-launches-microformat-powered-recipe-search wherein the 2nd link is: http://googleblog.blogspot.com/2011/02/slice-and-dice-your-recipe-search.html which if you read to the end of the post is: Posted by Kavi Goel, Product Manager I'm sure there is and has always been some informal exchange, Actually I personally try to minimize informal person-to-person exchanges regarding microformats as they doesn't scale well for the community. Kavi has contacted me personally in the past and I've done my best to direct him to ask his questions etc. on the IRC channel and document his research / requirements / brainstorms publicly on the wiki, emphasizing that it's ok to have incomplete/partial work on the wiki while figuring things out. since people happen to know each other, meet at confernces or other events etc, Those are all true of course. However even in those cases, it's best to have those discussion in open areas such as the IRC channel or the wiki for everyone's benefit. and of course that's fine with me. That's generous of you, however I do think it is reasonable to request that folks in the microformats community prefer community forums (IRC, wiki, mailing list if necessary) to private one-on-one or small group interactions (with perhaps the one exception of just wanting to bounce crazy/uncertain/raw ideas off of friends to sanity-check them before sharing more widely/publicly). I was wondering though when I read the following statement in a transcript of the Schema.org BOF at SemTech 2011 http://www.w3.org/2011/06/semtech-bof-notes.html: [...] Kevin Marks: Microformats says have a discussion first. You did that with hRecipe, so I'm surprsed to see you didnt go through that here. That'a the difference in phsilophy Tantek Çelik: Google (Kavi in particular!) successfully worked with the open community on both hReview-aggregate and hRecipe - openly. [...] Kevin Marks: hRecipe was a great example of how Google can do this. [...] This sounds like quite some conversations, discussions and thorough work. Now I wonder: how specifically did that great and successfull work with the open community go? Where did it take place? On the wiki (as documented above) and mailing lists. A simple microformats.org site-specific search of Kavi Goel gives you plenty: http://www.google.com/search?q=site
Re: [uf-discuss] schema.org, microformats.org, hRecipe
The point is to capture specific issues rather than have a discussion - a discussion where nothing is recorded on the wiki is nearly worthless and may as well have not happened. If it doesn't get captured on a discoverable URL, it might as well not exist (and no, email archives are NOT discoverable). I don't remember anyone asking for anything like itemscope in microformats. This list or IRC (preferably) is a good place to start with questions, but if there is an answer it should be captured by the author in an FAQ either specific to a microformat *-faq page, or in general on: http://microformats.org/wiki/faq If there is a specific known issue to report for a specific microformat, add it to the *-issues page for that microformat. If there is a specific known issue that applies to several microformats (eg class microformats) add it to: http://microformats.org/wiki/issues The goal is to *minimize* thrash / going in circles on email (a common problem in standards related communities), and instead to capture and grow our collective knowledge and understanding on the wiki. Thanks, Tantek -Original Message- From: thomas lörtsch tho...@stray.net Sender: microformats-discuss-boun...@microformats.org Date: Thu, 30 Jun 2011 16:24:40 To: Microformats Discussmicroformats-discuss@microformats.org Reply-To: Microformats Discuss microformats-discuss@microformats.org Subject: Re: [uf-discuss] schema.org, microformats.org, hRecipe On Jun 29, 2011, at 5:05 PM, Stephen Paul Weber wrote: I remember the itemscope thing coming up. Consensus seemed to be that is solved by root class names, but that was so long ago I forget. I assume that people created wiki pages documenting this? If not, why not? Microformats.org is a wiki first, and the mailing lists and IRC just facilitate the wiki. IMHO, if it's not documented on the wiki, then it's just a discussion. Well, just a discussion wouldn't be a bad start. Or do you suggest that I open a wiki page on my question? Thomas °|´ in pursuit of the gestalt of it all / ^^^ ___ 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
Document your work discoverably on the web or don't bother. Was Re: [uf-discuss] schema.org, microformats.org, hRecipe
Derrick, If something was brought up on a regular basis by newcomers, provide the URLs, otherwise we are right to dismiss your assertion. No one was driven out. We've had to ban a few trolls for negative behaviors for fixed periods of time, but haven't had to do any such thing for over a year (maybe 2) now. If you had actual parsing uses-cases for such a feature as well as publishing use-cases, at what URL did you document them? If you consider requiring documentation on the web/wiki and being rigorous as elitism of uf.org then, yes, you're not going to be very productive. And you're right, developing microformats is not for everyone - only those that are willing to document their work and be scientific in their methods. If you consider science to be a cabal, then you're not going to find much sympathy and should take your name-calling elsewhere. Document your work on discoverable URLs (preferably on the wiki) or don't bother complaining. Tantek -Original Message- From: Derrick Pallas derr...@pallas.us Sender: microformats-discuss-boun...@microformats.org Date: Wed, 29 Jun 2011 07:33:52 To: Microformats Discussmicroformats-discuss@microformats.org Reply-To: Microformats Discuss microformats-discuss@microformats.org Subject: Re: [uf-discuss] schema.org, microformats.org, hRecipe Notice that they have an itemscope in HTML5, something many people talked about on microformats.org for years. A few years ago it was brought up on a regular basis by newcomers, about twice a year; said newcomers were then driven out of the community. So there was discussion, just not very nice nor very productive. When I worked for Alexa, I had actual parsing uses-cases for such a feature as well as publishing use-cases and I was one of those newcomers, not the first and not the last. Not everyone tried to follow the process but I did, to the same end. After everything, the elitism of uf.org turned me off to the whole effort. That's not to say uf.org isn't full of nice, intelligent people — it is — just that I decided not to waste my time trying to be in the cabal. And this email is not intended to beat a dead horse, just to share my own experiences. ~D On 6/29/2011 2:55 AM, thomas lörtsch wrote: Hi all, I don't want to discuss the schema.org effort in general here, although there surely is a lot to discuss about it. My question is how collaboration between Google.com and microformats.org is organized, where it's taking place, who is involved. I'm sure there is and has always been some informal exchange, since people happen to know each other, meet at confernces or other events etc, and of course that's fine with me. I was wondering though when I read the following statement in a transcript of the Schema.org BOF at SemTech 2011http://www.w3.org/2011/06/semtech-bof-notes.html: [...] Kevin Marks: Microformats says have a discussion first. You did that with hRecipe, so I'm surprsed to see you didnt go through that here. That'a the difference in phsilophy Tantek Çelik: Google (Kavi in particular!) successfully worked with the open community on both hReview-aggregate and hRecipe - openly. [...] Kevin Marks: hRecipe was a great example of how Google can do this. [...] This sounds like quite some conversations, discussions and thorough work. Now I wonder: how specifically did that great and successfull work with the open community go? Where did it take place? Who was involved? And what exactly was worked out? I won't hesitate to admit that I wasn't a very good editor of hRecipe since summer 2009 but I still am the editor as indicated on the hRecipe wikipage. I wasn't contacted by anyone regarding Rich Snippets, Schema.org or any other Google activity. Also I couldn't find any mention on the mailinglists or on the wiki. So, please: what's going on, what did I miss? Or how is this open? Since Schema.org now promotes a recipe vocabulary that is slightly different from hRecipe and also more elaborated I would like to discuss what to do about that: maybe analyze the differences, observe uptake, then align hRecipe where appropriate etc. But before I start to work on that I'd like to understand what happened until now. Cheers, Thomas Lörtsch °|´ in pursuit of the gestalt of it all / ^^^ ___ 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] input microformats for auto-filling forms
On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber singpol...@singpolyma.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Somebody claiming to be Glenn Jones wrote: http://microformats.org/wiki/hcard-input-brainstorming We should confine the definitions of microformat to classname and rel attributes. Strongly disagree. As I understand it, µformats are about defining vocabularies and how those vocabularies can be best encoded using existing HTML semantics. Restricting to class and rel is short-sighted. microformats are both about a scientific process for researching and defining vocabularies, AND the simplest/easiest/most-robust syntax for using those vocabularies. To date experience has shown that class and rel microformats make the most sense. In the early days there were thoughts about also using id attributes for vocabulary but those have been discarded as impractical. For example, in this case, while having class=fn may be beneficial (if you want to parse the form as a microformat) using name=fn is more semantically correct if what you want to do is autofill or similar. name=fn also has the advantage of already doing a lot for you in terms of autofill in most major browsers (who key off the name attribute for their autofill). Of course web authors should use the name attribute when it is semantically correct to do so. However, the challenge is that the name attribute can only accept a *single* value (similar to id). Whereas one of the aspects of class and rel that made them work so well with existing web pages and their markup is that both class and rel contain a space separated *set* of values. Thus it makes sense to prefer (restrict if you will) our use and recommendation of microformats to class and rel, rather than forcing authors to pick one value for name. This is probably worthy of writing up as an FAQ as I've seen this question arise before and I also *did* consider (and reject without bothering to write it down) using the name attribute like this. Here is the existing parsing brainstorming regarding treating input elements specially: http://microformats.org/wiki/hcard-parsing-brainstorming#input_element_handling input type=vcard Interesting, but invalid and does not have a good fallback mechanism. It might make more sense to have something more abstract and connected to the user interface of the platform, e.g. input type=contact -- brings up a contact/addressbook application picker and then under the hood, define the API for accessing that data in terms of the hCard microformat vocabulary. Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] input microformats for auto-filling forms
On Fri, Feb 18, 2011 at 13:28, Stephen Paul Weber singpol...@singpolyma.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Somebody claiming to be Tantek Çelik wrote: On Tue, Feb 15, 2011 at 12:49, Stephen Paul Weber singpol...@singpolyma.net wrote: Somebody claiming to be Glenn Jones wrote: http://microformats.org/wiki/hcard-input-brainstorming As I understand it, µformats are about defining vocabularies and how those vocabularies can be best encoded using existing HTML semantics. Restricting to class and rel is short-sighted. microformats are both about a scientific process for researching and defining vocabularies, AND the simplest/easiest/most-robust syntax for using those vocabularies. To date experience has shown that class and rel microformats make the most sense. In general I would agree that is true. class and rel have very nice semantics that fit with most of what has been attempted with µformats so far. I'm just saying there's a difference between most-robust syntax and never anything but class and rel Agreed. I think the point is that for practical purposes it makes sense to just stick to class/rel discussions, unless there is a specific significant advantage to using something else (more than just what if - which is a theoretical discussion not worth the time). For example, XOXO is a µformat (albeit a very simple one) that does not make extensive use of class or rel, XOXO is certainly an odd one out of the bunch. I'm not sure how much explicit (vs. implicit) use it is getting in practice, what (if any) applications have been built that consume and do anything interesting with it. If you know of any specific sites that explicitly publish it for a particular end-user benefit, or specific sites that explicitly consume XOXO for some end-user feature, please document them: http://microformats.org/wiki/xoxo-examples-in-wild http://microformats.org/wiki/xoxo-implementations also XMDP XMDP is not really a microformat - rather, it's more like supporting technology for adding machine referencable definitions and URLs for vocabulary terms. No one publishes actual content (what microformats are really for) marked up with XMDP. I designed XMDP purely to provide a way to map newly created XFN rel values to precise URIs that a system based on URIs (e.g. RDF) could reason with. In practice I'm not sure how much URI-based reasoning is happening on the public web (applications I've seen all just treat the XFN rel values as tokens). For more on this see: http://microformats.org/wiki/xmdp-origins using name=fn is more semantically correct if what you want to do is autofill or similar. name=fn also has the advantage of already doing a lot for you in terms of autofill in most major browsers (who key off the name attribute for their autofill). However, the challenge is that the name attribute can only accept a *single* value (similar to id). That's a good point. Are there common cases where a form input is usefully multiple attributes? (A real question, I honestly don't know if that's common). Yes, specifically the web developers is *already using a name* in their web form implementation, and then if we ask them to add *another* name for microformats purposes. But this is not possible since inputs can only take one name value. Same problem as id. It makes them both not particularly practical for microformats vocabularies. Thus it makes sense to prefer (restrict if you will) our use and recommendation of microformats to class and rel, rather than forcing authors to pick one value for name. While this seems somewhat reasonable, as suggested on the wiki page we are discussin there are still 2 problems with the suggested use of classnames: 1) Does nothing useful under existing UAs The does nothing useful under existing UAs is just stop energy and not a valid argument. Of course technology that hasn't been developed yet does nothing in existing UAs. It would be odd if it did. (whereas name would make good autocomplete work). Citation needed. If you want to research existing input/name formats that implementations might be using, please document them on the wiki so we can understand what might work. Perhaps on a page like: http://microformats.org/wiki/input-name-formats 2) Breaks parser expectations (a parser will see the hCard classes, for example, and try to parse an hCard. So parsers will get blank or filled-with-placeholder hCards from form pages). In practice this is not a problem, we iterate on microformats parsing, and parsers update. E.g. with the very successful (and necessary) value-class-pattern. Unless you can provide a specific scenario (what page, what parser, what specific bad user experience), I'm calling theoretical on this (thus undeserving of further discussion). If you know of specific real-world issues with parsing input elements for microformats, especially in the context of hCard, please note
[uf-discuss] moving drafts forward - process-brainstorming: draft, specification, standard
It's been noted[1][2] that no drafts are making it to specification, and in short there are two reasons for this: 1. Lack of steps in the process[3] for how a draft should proceed to specification and what each of those mean (other than the summary on the Main Page[4]), including lack of documentation of implicit assumptions such as that all outstanding issues must be resolved on a draft (and any patterns it depends on) before we can in good conscience make it a specification. As the editor/maintainer of the process, I accept full personal responsibility for this. 2. Blocking issues. During the development of various drafts we encountered a few blocker cross-microformat issues (e.g. accessibility, internationalization) which were potentially doing harm. Since then, those cross-microformat issues have been resolved[5], and we've been incorporating those resolutions into the specifications (e.g. hCard, hCalendar) as well as into resolutions of spec-specific issues. I've been working the past few weeks on addressing #1 above. Having had the experience of confronting and overcoming these cross-microformat issues, as well as close experience with the document stages in W3C and IETF (and what works / is pragmatically useful vs what is mostly just bureaucratic), I've developed the following minimal process brainstorm: http://microformats.org/wiki/process-brainstorming Summary: three defined document stages: * draft: consensus among brainstorm proposals, experimental, it's ready for trial on the public web. * specification: all outstanding issues resolved, stable, 1+ real world publisher(s)+consumer(s), it's ready to depend on. * standard: (new) test suite and 2+ interoperable real world publisher(s)+consumer(s) for each feature, errata only, what the market has accepted. These are strictly summaries - please see http://microformats.org/wiki/process-brainstorming for more precise preconditions, actions, definitions, stability, and example steps to take. Please raise any *major* problems you note directly in an Issues section on the process brainstorming page. Assuming no major problems are found (minor are ok to fix in iterations) in the next few days, I plan on incorporating this brainstorm into the process itself[3] and starting to take various current/mature specifications and drafts forward to exercise these new steps / definitions to see how well they work in practice. In short: I believe we can quickly get many specifications to the new level of standard (e.g. hCard, hCalendar) after perhaps some trimming of unused properties, as well as several drafts to specification (e.g. hReview, hAtom) with an iteration that incorporates issue resolutions having especially to do with the cross-microformat issues noted above. Thanks, Tantek [1] http://en.wikipedia.org/wiki/Microformat#Evaluation_of_microformats [2] http://lists.w3.org/Archives/Public/public-html/2010Dec/0089.html [3] http://microformats.org/wiki/process [4] http://microformats.org/wiki/Main_Page#Specifications [5] http://microformats.org/wiki/value-class-pattern -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] The wiki has been spammed
On Sat, Jan 29, 2011 at 19:07, Alexandre Patry a...@nlpfu.com wrote: Hi, I just wanted to inform you that your wiki (at least http://microformats.org/wiki/Main_Page) has been spammed. Thanks for the heads-up Alexandre - should be all cleaned up now. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: country-name expected values
On Sun, Oct 24, 2010 at 22:00, David Recordon record...@gmail.com wrote: This is a good question. Was hoping the answer was an easy vCard spec'd X but it seems that neither vCard or hCard actually define country-name. Tantek, thoughts? country-name in vCard, and in hCard reflects what people visibly publish on the web. In this case, the actual full names of countries, or abbreviations thereof, e.g. USA United States United States of America Canada England UK United Kingdom etc. for further questions regarding hCard, please feel free to follow-up on the microformats discuss list (cc'd). http://microformats.org/mailman/listinfo/microformats-discuss/ Thanks, Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] 2 billion hCards! gathering material for a microformats.org turns 5 blog post
Toby, On Wed, Jul 7, 2010 at 4:28 PM, Toby Inkster t...@g5n.co.uk wrote: On Wed, 7 Jul 2010 08:24:52 -0700 Tantek Çelik tan...@cs.stanford.edu wrote: snip academic discussion of fb: being a URL scheme or not The page at http://wordpress.org/ does actually contain 3 triples i evaluated as RDFa 1.0, though they're each the result of RDFa grandfathering in certain HTML 4/XHTML 1 semantics. No, it might contain 3 RDF triples - but they're not RDF*a*. It contains three attributes which are described by the XHTML+RDFaspec, and which, when processed according to the RDFa spec, each produce an triple. Just because a page can be parsed/converted into another format does not mean it contains that format. The page at http://wordpress.org/ doesn't need to be converted to RDFa. It is RDFa. (It doesn't use an RDFa DTD, though many seem to believe that judging an XML document's type by its DTD is a layering violation.) It would need to be converted if you wanted RDF/XML, Turtle or JSON. But it doesn't need to be converted to RDFa; it is RDFa. These assertions of is RDFa on grandfathered formats/syntaxes are deceptive because it's essentially claiming implied credit/branding for something that had nothing to do with RDFa. E.g. if some future version of XHTML+RDFa spec describes how to process microformats (given the trend the RDFa specs to grandfather in more and more syntax - it's reasonable to predict that this happen), then you can make the same claim there, that all use of microformats are RDFa, which then dilutes the phrase is RDFa to the point of meaninglessness. Such a conflation of reclassifying previously non-RDFa markup as RDFa is, as I said, clouding a definition at best, and deceptive/dishonest at worst. It still just conversion of a *previous* syntax, defined *outside* and *predating* RDFa. Another analogy: you could make a new spec called BrandXSemantics (BXS) that defined processing of all syntaxes like meta tags, microformats, RDFa, microdata etc. that claimed that all such syntaxes were BXS, but such a claim is of little utility and would merely serve to artificially inflate claims about BXS being more popular that microformats or RDFa or microdata - this is essentially what this kind of grandfathering in RDFa is doing. Claiming It is RDFa is also deceptive from the point of view of developer behavior, which is illustrated by your next point. Saying so is deceptively mis-using the word contains at best, and playing semantic games at worst. Just because a page has hAtom does not mean it contains Atom. No, it contains hAtom and can possibly be converted to Atom (atom:id concerns notwithstanding). The page at http://wordpress.org/ contains RDFa and can be converted to RDF/XML. The question of comparison is deliberately chosen to illuminate what are developers actually coding? What syntax? Not what can you infer, parse as, or convert to. In the case of http://wordpress.org/, they have coded RDFa. Thanks to the fact that RDFa grandfathered in some semantics from earlier versions of (X)HTML, they may not have been *knowingly* doing so. Claiming some code is RDFa that clearly was not *knowingly* written/intended as such points out the key flaw - if you're talking about what are developers adopting, then their intent, and what they are explicitly choosing to do is what matters. Thus comparisons like Google's Rich Snippets adoption table make sense to contrast developer adoption of different format approaches. The question how many pages contain RDFa? is only meaningful if certain qualifications are added... Does broken RDFa count? broken RDFa counts, but only to demonstrate the difficulty of coding RDFa, not instances of RDF(a). one of the reasons that Google found so little RDFa is may be because much of it was broken. this is one of the common problems with namespaces in data. Do twitter's 100 million plus broken hCards demonstrate the difficulty of coding microformats? If there are problems with Twitter's hCards, please document the specific problems on the respective issues page that way we can better verify the problem report(s), investigate possible causes, and suggest fixes to Twitter as well. I've added a placeholder section for this: http://microformats.org/wiki/hcard-supporting-user-profiles-issues#Twitter I imagine that the reason Google found so little RDFa is because they were only counting RDFa that used their own RDFa vocabulary, and neglecting to count *all* RDFa. Without more information on their testing process I can't verify that though. My understanding of RDF(a) advocates is that one of the design principles of RDF(a) is its infinite extensibility and philosophy of encouraging everyone to make up their own vocabulary (which is often contrasted with microformats opposite design principle of deliberate re-use of shared vocabularies for better interoperability and communication). Google using their own RDFa
Re: [uf-discuss] 2 billion hCards! gathering material for a microformats.org turns 5 blog post
Jeremy, Well, this isn't huge in terms of numbers but it's something that makes my day to day work a whole lot smoother: 37 Signals have added hCards to Basecamp: http://answers.37signals.com/basecamp/556-any-chance-of-adding-hcards This is great news! In the few times I've used Basecamp I remember being quite frustrated by the lack of hCard support and simple person info portability. Great to see that 37 Signals has added hCards. Peter, On Tue, Jul 6, 2010 at 1:27 AM, Peter Mika pm...@yahoo-inc.com wrote: Hi Ed, The comparison to the number of people online is misleading, because the microformat stats quoted (both the Google and Yahoo figures) include duplicate counting. One of my illustrative examples is news.stanford.edu, where the microformat annotation is in the template, and thus every single page has exactly the same microformat markup, i.e. the address of Stanford University. On the other hand, there are also numerous pages with multiple hCards per page. Directory listings, friends lists, about pages for companies listing their executives etc. The wiki has many such examples already: http://microformats.org/wiki/hcard-examples-in-wild There are certainly: * multiple pages with the same hCard. * pages with multiple hCards. This was my experience with the microformats indexer we built at Technorati back in the day. It's hard to know how these average out. You have to write a bunch more code (e.g. really good deduping etc.) to figure it out. Lacking that we should cite *pages* with hCards rather than total hCards for the Search Monkey stat to be more accurate. The second point to make is that RDFa usage is underreported by [1]. Compare searchmonkey:com.yahoo.page.rdf.rdfa with searchmonkey:com.yahoo.page.uf.hcard These indicate that there are 2.7B pages with RDFa I think this may be an errant number based on the way that Search Monkey normalizes things internally to RDFa (because of an unfortunate premature architectural decision that they then became stuck with - as it was related to me by Paul Tarjan). OR (and this deserves a little analysis) Those pages don't actually all (if any?) contain RDFa. Look at the first page of results. E.g. Wordpress.org results don't have any RDFa. View source and the only thing even remotely resembling you see is: meta property=fb:page_id content=... - which is simply use of an invalid property attribute (in XHTML 1.0). The qname fb: is not defined anywhere. This is not RDFa, this is simply a meta tag using a new (invalid) syntax. That is, using property instead of the standard HTML 4.01 name attribute: meta name=fb:page_id content=... Similarly with CNN.com, download.cnet.com, online.wsj.com. OTOH, www.vistaprint.ca, digg.com, www.joomlart.com, www.webmd.com don't even have property attributes. Who knows why they're listed in that result page. No evidence of any RDFa on those pages. www.metacafe.com does appear to define an og qname and use it in a property attribute. And that's it for the first page of results for that query searchmonkey:com.yahoo.page.rdf.rdfa - Only 1 out of 10 of at least the first page of results actually had any RDFa - and that one was invisible meta data at that. It does not appear that that query actually returns pages with rdfa, for the most part not in any valid sense, nor in any sense of the intent of marking up existing visible content with additional attributes. Perhaps a challenge could be posed - how many results of that query do you have to look through before you find a legitimate marking up visible data instance of RDFa? In 4 pages of results (40) I only found 2 - and both were on the Creative Commons site - not a big surprise given that Ben Adida is both co-chair of RDFa WG and works for Creative Commons. But no others. It seems that RDFa usage is grossly exaggerated (by at least a factor of 20) by the Yahoo Search Monkey searchmonkey:com.yahoo.page.rdf.rdfa query. compared to 2B pages with hCard. There are many caveats to these numbers, but they are more or less on equal footing. They're not even close (at least an order of magnitude difference), as the above debunking of the RDFa results demonstrates. Ed, Ed Summers wrote: On Sat, Jul 3, 2010 at 10:18 PM, Tantek Çelik tan...@cs.stanford.edu wrote: Some additional recent news: * microformats has 94% marketshare compared to alternatives (e.g. RDFa) according to Google (announced at the Semantic Technology conference) - http://www.readwriteweb.com/archives/google_semantic_web_push_rich_snippets_usage_grow.php - http://www.readwriteweb.com/images/richsnippets_june10b.jpg Was it clear if Google's stats were comparing all microformat usage with usage of only their particular rich snippet vocabulary [1]? I'd be surprised if it was *all* RDFa vocabulary use, since that would mean that Google are indexing all RDFa on the web. John Breslin asked a similar question in the comments on that RWW post
Re: [uf-discuss] 2 billion hCards! gathering material for a microformats.org turns 5 blog post
On Wed, Jul 7, 2010 at 4:43 AM, Toby Inkster m...@tobyinkster.co.uk wrote: On Wed, 7 Jul 2010 02:25:38 -0700 Tantek Çelik tan...@cs.stanford.edu wrote: E.g. Wordpress.org results don't have any RDFa. View source and the only thing even remotely resembling you see is: meta property=fb:page_id content=... - which is simply use of an invalid property attribute (in XHTML 1.0). The qname fb: is not defined anywhere. In the current RDFa 1.1 drafts, this is allowed, though its meaning is not likely what the authors of this page intended. In 1.1, prefixes which are not bound to anything are assumed to be absolute URIs. So it's another form of invalid syntax then, since fb: is not a defined protocol. The page at http://wordpress.org/ does actually contain 3 triples if evaluated as RDFa 1.0, though they're each the result of RDFa grandfathering in certain HTML 4/XHTML 1 semantics. No, it might contain 3 RDF triples - but they're not RDF*a*. Just because a page can be parsed/converted into another format does not mean it contains that format. Saying so is deceptively mis-using the word contains at best, and playing semantic games at worst. Just because a page has hAtom does not mean it contains Atom. Just because a page has microdata does not mean it contains JSON (though an exceptionally precise direct conversion is defined). etc. Similarly to microdata, as we define more precise parsing rules for microformats, we'll have direct conversions to JSON and RDF triples as well. This does not mean that all pages with microformats contain JSON or RDF. The question of comparison is deliberately chosen to illuminate what are developers actually coding? What syntax? Not what can you infer, parse as, or convert to. Because as you know with the parsers you've written, you can convert syntaxes to nearly any implied format - it tells you nothing about usage. The question how many pages contain RDFa? is only meaningful if certain qualifications are added... Does broken RDFa count? broken RDFa counts, but only to demonstrate the difficulty of coding RDFa, not instances of RDF(a). one of the reasons that Google found so little RDFa is may be because much of it was broken. this is one of the common problems with namespaces in data. Do grandfathered rel/rev values count? c. rel/rev syntax and values work without RDFa - they're not RDFa, despite RDFa's attempt to subsume them (and even errantly claim/imply credit in the spec, e.g. rel-license). In fact, how many pages questions about the Web are not especially meaningful. Say Google added an hCard to its search result pages, replacing its current logo with something like this: span class=vcard a href=/ class=url img class=logo fn org alt=Google src=... / /a /span Are the search results for foo and bar different pages? What about the search results for 1001 and 1002? Because if they are, that's over a hundred billion hCards online. 1. theoretical strawman[1] 2. google.com/robots.txt prevents this from counting in any search Tantek [1] http://en.wikipedia.org/wiki/Straw_man -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] 2 billion hCards! gathering material for a microformats.org turns 5 blog post
According to Yahoo! Search Monkey, there are now over 2 billion hCards on the web: http://search.yahoo.com/search?p=searchmonkey%3Acom.yahoo.page.uf.hcard This is perhaps due to a few fairly large recent deployments: * BrightKite.com - all venues and user profiles have hCard (millions) * Gravatar - all profiles now have hCards (millions) - used on WordPress.com etc. Some additional recent news: * microformats has 94% marketshare compared to alternatives (e.g. RDFa) according to Google (announced at the Semantic Technology conference) - http://www.readwriteweb.com/archives/google_semantic_web_push_rich_snippets_usage_grow.php - http://www.readwriteweb.com/images/richsnippets_june10b.jpg I'm collecting these into material for microformats.org turns 5 blog post - additional suggestions welcome! http://microformats.org/wiki/microformats-turns-5 -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Level of rel=contact
On Tue, Apr 6, 2010 at 5:02 PM, Sarven Capadisli i...@csarven.ca wrote: On Tue, 2010-04-06 at 22:48 +, Brian Suda wrote: On Tue, Apr 6, 2010 at 9:23 PM, Sarven Capadisli i...@csarven.ca wrote: I'm thinking that rel=contact is generally attributed to someone that we have at least a lowest form of friendship with. [...] It is not. The reason we added contact in XFN 1.1 was to indicate literally just what it says - that you have some sort of contact info about the person - this could be just a URL or email address for example. You can't assume any other semantics. It doesn't imply anything positive or negative. Thus you cannot conclude at least a lowest form of friendship - you cannot conclude anything about friendship from rel=contact. If you want to imply a lowest form of friendship, then rel=acquaintance is what you're looking for: http://gmpg.org/xfn/11#acquaintance acquaintance Someone who you have exchanged greetings and not much (if any) more — maybe a short conversation or two. Often symmetric. Additionally, if the user doesn't have control over the declaration of such relationship, wouldn't it be more meaningful and safer to exclude this bit of information in the output? --- You lost me on exclude this, exclude what exactly? My bad. My reference was to the example. Again, this is precisely one of the reasons why contact does not imply anything about friendship, so that you don't have to worry about excluding it due to an imagined implication. The example I had in mind was 'Subscribers list' at http://identi.ca/csarven --- if you are subscribing to someone, then it probably at minimum meets the definition of: someone that we have at least a lowest form of friendship I don't think you can make that assumption. subscription != friendship. You might be subscribing to an automated summary aggregate feed for example. For things like subscribing e.g. Identi.ca or Twitter followers or followings, there's been quite a bit of brainstorming over the past few years: http://microformats.org/wiki/xfn-brainstorming#fans_and_followers which appears to have converged on: rel=follower (for indicating someone who is a follower of yours) rel=following (for indicating someone who you are following) On such services that also permit direct messaging - these URLs also serve as a form of contact information, and thus rel=contact could also be used: rel=follower contact rel=following contact Since direct messaging is not necessarily symmetric (neither is rel contact), it might make sense for such a service to label a link to another profile as a contact only if you do actually have the ability to contact (dm) them - though that might also be asking too much of the semantic of contact (since has contact info and can contact are two different things.) Are you suggesting it isn't and we should exclude it? No, I'll clarify. What I was trying to say was that, if I have a profile page where it lists a bunch of people that are subscribed to me, I wouldn't necessarily call them my contact since I don't really know them. Hence, in my example at http://identi.ca/csarven , rel=contact should be removed from Subscribers list. I agree that rev=contact makes more sense here, but, I'm focused on the incorrect use of rel=contact. Why is it incorrect? It's only incorrect based on the assumptions you've presented about what rel=contact means - which is basically a straw-man. rel=contact is/should be reserved for people that meets the basic requirement of that lowest form of friendship. Why? We already have rel=acquaintance for that semantic. Would it help to add any of this discussion to the FAQ? http://microformats.org/wiki/xfn-faq Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [ANN] any23 v0.2 released
On Fri, Feb 19, 2010 at 1:59 AM, Davide Palmisano palmis...@fbk.eu wrote: Dear all, we are proud to announce a new release of any23 -- Anything to Triples. http://developers.any23.org/ Davide, congratulations on your release! Any23 is a Java library that parses RDF from a variety of Web document formats. The currently supported input formats are RDFa, RDF/XML, Turtle, N3, N-Triples, and a number of Microformats. Any23 is an Open Source project originated from the code created within the Sindice project and now used both inside sindice and in related projects e.g. Sig.Ma Any23 comes with a handy command-line tool for parsing RDF and converting between formats. We have also set up a demo service where you can try any23 online and use a REST API to convert between different RDF formats, similar in spirit to triplr.org: http://any23.org/ The major new features in this release are: * Redesigned Java API - Input from string, stream, file, or URI - Allow choosing which extractors to use - Report origin of triples (document/extractor) to client processors - Various processors/serializers for extracted triples * Added flexible command-line tool for easy testing * Vastly improved website and documentation * Media type and encoding detection via Apache Tika * Switched RDF library from Jena to Sesame * Added Maven build * Better RDF extraction from Microformats This is great to hear. Tom Morris has already kindly added any23 to the parsers page: http://microformats.org/wiki/parsers Could you list the specific microformats that are parsed by any23? And even better, feel free to add any23 to the *-implementations pages of the microformats that it supports, e.g. if it supports hCard, add it to: http://microformats.org/wiki/hcard-implementations#Open_Source The following people have contributed to this release: Michele Mostarda and Davide Pamisano (FBK, Trento, Italy, Web of Data Unit (WED) ); Richard Cyganiak and Jürgen Umbrich (DERI, NUI Galway, Ireland); Michele Catasta (EPFL, Lausanne, Switzerland), Giovanni Tummarello All the best, Davide Palmisano on behalf of the contributors Thanks again for all your excellent work and for contributing to bettering the interoperability of semantic data on the web. Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo shorthand in anchor
On Fri, Jan 15, 2010 at 6:01 AM, Sarven Capadisli i...@csarven.ca wrote: I've noted my observations on your observations http://microformats.org/wiki/index.php?title=geo-brainstormingdiff=41657oldid=41586 Thanks Sarven, you raised some good questions - I've followed up on the wiki as well. I see two things there: 1. changing the problem i.e., intended visible readable text content In general we should seek to make content more visible when possible. 2. 45.5140800 and -73.6111000 as text values is no more human readable and listenable than as 45.5140800;-73.6111000 title value. But that's not the exact comparison of the renderings, leaving out the key difference, the labels: lat:45.5140800; long:-73.6111000 which is then more readable/listenable/understandable than a pair of semicolon separated numbers. it may not be perfect, but it is an improvement. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] geo shorthand in anchor
On Thu, Dec 31, 2009 at 3:30 AM, Sarven Capadisli i...@csarven.ca wrote: On Wed, 2009-12-30 at 22:30 +, Brian Suda wrote: On Wed, Dec 30, 2009 at 10:09 PM, Sarven Capadisli i...@csarven.ca wrote: AFAIK: The StatusNet platform as of version 0.9RC1 e.g., http://identi.ca/notice/17811123 Potentially, publicly documented sites at http://status.net/wiki/ListOfServers on update. --- great, can you add/start a page on the wiki to document these? that way we can find common formats and any emerging syntaxes. -brian Added to http://microformats.org/wiki/geo-brainstorming#latitude_longitude_shorthand_and_geo_link for now. Sarven thanks very much for documenting that on the wiki - that page is a good place to capture existing publishing patterns regarding geo information. I left it out of http://microformats.org/wiki/geo-examples-in-wild and http://microformats.org/wiki/geo-examples thinking that only the acknowledged representations should be listed there. Am I right? Yes that's right. The examples-in-wild pages are for documenting uses of existing microformats on real world web pages. One quick bit of feedback on this thread (which I'll also note on the wiki next to the examples added) - use of the title attribute for semicolon separated lat-long may not be the user-friendliest thing to do. Given microformats experience with various uses of the the title attribute - a good rule of thumb is to check to make sure that the content you are putting into the title attribute is both reasonably human readable and listenable. Thanks, Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up properties which reused pre-existing microformat
On Mon, Dec 14, 2009 at 12:27 PM, Glenn Jones glenn.jo...@madgex.com wrote: One of the problems I am see a lot with hResume is now properties which reused pre-existing microformat are mark-up. A good example is education in hResume which is hCalendar, I believe it should be mark-up like so: p class=education vevent span class=summaryBighton Univ/span (span class=dtstart1985/span - span class=dtend1988/span) /p Yes. This is an example of the common modular use of a microformat to provide additional structure to the property value of another microformat. The education property is a hCalendar and as such the same class attribute should carry both education and vevent. I have built my parser to look for this type of pattern, but quite a few authors on the web are using mark-up like this div class=education p class=vevent span class=summaryBighton Univ/span (span class=dtstart1985/span - span class=dtend1988/span) /p /div Could you provide URLs to a few of the quite a few authors that you've found doing this, perhaps in the Examples In The Wild section? http://microformats.org/wiki/hresume#Examples_in_the_wild If it's a common errant pattern, we should document it as step one of deciding what to do next. Breaking apart the education and vevent into separate element class attributes. Correct if I am wrong but only the first pattern should be supported by parsers. That's correct, per the hResume schema and field details: http://microformats.org/wiki/hresume#Schema education. optional One or more hcalendar events with the class name 'education', with an embedded hCard indicating the name of school, address of school etc. note the distinction between ... events *with* the class name 'education' and an *embedded* hCard indicating ... The example given in the spec demonstrates an hCalendar event with the class name 'education': http://microformats.org/wiki/hresume#Education ol class=vcalendar li class=education vevent a class=url summary href=http://example.edu/;Preston High School/a (abbr class=dtstart title=2001-01-242001/abbr - abbr class=dtend title=2005-05-252005/abbr) /li Either I need to update my parser or the wiki needs some good pointers on how properties which reused pre-existing microformat are mark-up. The above description and example are from the hResume spec on the wiki - if you have ideas for either improving those examples or more illustrative examples that would have helped, certainly add suggestions to the feedback page! http://microformats.org/wiki/hresume-feedback Thanks Glenn, Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hreview-aggregate -- votes vs reviews
On Tue, Nov 10, 2009 at 11:53 PM, Kavi Goel k...@google.com wrote: Hi all, I have replaced the stub page for hReview-aggregate with a draft spec describing the microformat that was decided on early this year. ... http://microformats.org/wiki/hreview-aggregate Hi Kavi, I've reviewed the hreview-aggregate page and it is an excellent first draft. Thanks very much for writing this up. I have also updated the brainstorming page with a proposal to address one of the issues raised -- that users can leave a rating without writing a review. The current hreview-aggregate draft has a single property called count that is used to specify the number of reviews for a particular product or service. However, many sites have some number of votes (where users specify a numerical rating or a thumbs up/thumbs down vote) contributing to an average rating and a smaller number of full user reviews. The brainstorming page is here: http://microformats.org/wiki/aggregate-review-brainstorming Do you have documentation of real-world examples of sites that separately publish number of votes/ratings and reviews? We should collect URLs to those examples in the aggregate-review-examples page to make sure we are modeling/brainstorming/proposing something that is designed specifically for what is actually published today. http://microformats.org/wiki/aggregate-review-examples Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: H2VX.com is feature complete. was Re: [uf-discuss] Concerning the Technorati pipes
On Mon, Nov 2, 2009 at 2:59 AM, Mark Norman Francis n...@cackhanded.net wrote: I'm considering H2VX.com feature complete at this point and will make only minor incremental changes/fixes as reported. I like the what are microformats? link that appears on hover, but it appears to be mouse-accessible only. I can't tab to reveal it or access it, except by turning CSS off first. Norm, good point. Could you add this as an issue to: http://microformats.org/wiki/h2vx#issues and feel free to suggest ways to improve it (I'm thinking using :focus might help, but figure you may have better suggestions). Also, a short 'about' page would be worthwhile IMO, especially for adding to the homepage. Agreed. I collected it to http://microformats.org/wiki/h2vx#feedback On Mon, Nov 2, 2009 at 2:16 PM, Martin McEvoy mar...@weborganics.co.uk wrote: Martin McEvoy wrote: Martin McEvoy wrote: Tantek Çelik wrote: If folks write new XSLTs to handles more conversions, we can certainly take a look at setting them up (e.g. an hNews or hAtom + value-class-pattern to Atom or RSS converter). Transformr [1] has implemented an hAtom + value-title [2] to RSS2 converter You can point your hAtom page at http://transformr.co.uk/rss2/your url. some examples: http://transformr.co.uk/rss2/http://microformats.org/tidy=no Is this implementation available as open source? If not, could you consider releasing it? Sorry I forgot to add that it is also possible to extract a RSS2 enclosures (a podcast) by simply adding a rel-enclosure[1] to hAtom. example: a rel=enclosure type=audio/mpeg href=...today's podcast/a. If you also wish to extract the required length attribute of a RSS2 enclosure you can pass that along with the type specifier example: a rel=enclosure type=type=audio/mpeg;length=22334669 href=...today's podcast/a. The length is the size of the file in bytes. [1] http://microformats.org/wiki/rel-enclosure :) This is excellent - and it would be great to document some of these examples. Could you add your documentation of the Transformr to the wiki? e.g. perhaps at: http://microformats.org/wiki/transformr Finally, to follow-up on the remaining open point from my previous email: Re: 1. TR Ops contacted. I'm going to ask the folks at Technorati to simply redirect technorati.com/contacts and /events to h2vx.com/vcf and /ics respectively as I'm sure that a simple redirect directive is more likely to survive any future site changes. This is now done. h2vx.com is now handling all feeds.technorati.com, technorati.com/contacts, and technorati.com/events requests. Obviously this has raised the load a bit, and I've added some robots blocking to help prioritize human requests (robots should be indexing HTML+microformats directly, rather than vcf or ics). Again, if you experience any problems with H2VX, please raise them here: http://microformats.org/wiki/h2vx#issues Thanks, Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
H2VX.com is feature complete. was Re: [uf-discuss] Concerning the Technorati pipes
Quick update: H2VX.com is up, serving vCards and iCalendars, and also has new browser buttons (AKA favelets/bookmarklets) that submit the current page to it to be converted. Details: Re: 1. TR Ops contacted. I still have no update from Technorati. Now that H2VX has an updated UI and converter, I'm going to ask the folks at Technorati to simply redirect technorati.com/contacts and /events to h2vx.com/vcf and /ics respectively as I'm sure that a simple redirect directive is more likely to survive any future site changes. I'm certainly open to alternative suggestions. 2. H2VX. I've been thinking for a while that we need more than one production open conversion service and thus just picked up h2vx.com (not setup yet) to host another deploy of Brian Suda's excellent open source X2V XSLT files for generating vcf and ics (at least for now, I can add rss and atom converters for hAtom later, perhaps when the spec has been updated with required value class pattern date time support per: http://microformats.org/wiki/value-class-pattern#hAtom_updated_implied_d ate ) As noted, H2VX.com conversion of hCards and hCalendar events is now up and running. I've setup a separate Twitter for H2VX status updates for those you using H2VX.com links on your sites for conversions. http://twitter.com/h2vx Please add any feedback or issues to: http://microformats.org/wiki/h2vx I'm considering H2VX.com feature complete at this point and will make only minor incremental changes/fixes as reported. If folks write new XSLTs to handles more conversions, we can certainly take a look at setting them up (e.g. an hNews or hAtom + value-class-pattern to Atom or RSS converter). Re: 3. X2V setup docs. I've taken copious notes on what was needed to setup X2V, as well as written a bunch of new PHP and javascript to do so with an improved UI. As time permits I'll add these to: http://microformats.org/wiki/x2v#install However for now, I'm going to return to closing resolved hCard and hCalendar issues and writing up the hCard and hCalendar 1.0.1 updates - which are already a month later than I wanted them to be. If anyone urgently needs/wants to setup another X2V instance, let me know, and perhaps we can work through the details on IRC (http://microformats.org/wiki/irc). On Mon, Oct 19, 2009 at 9:20 AM, Ted Drake tdr...@yahoo-inc.com wrote: Tantek This sounds like something Google App Engines may be able to host. I'm not familiar with that package, but it would be worth investigating. It would be nice to setup an X2V instance on Google App Engines, but AFAIK Google App Engines does not yet support XSLT. Thanks, Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hRecipe on FoodNetwork.com
On Mon, Oct 5, 2009 at 8:33 AM, Mark Wunsch m...@markwunsch.com wrote: Hello Microformaters, I'm really pleased to announce that FoodNetwork.com has recently rolled out hRecipe on its recipes! We've been observing the development of hRecipe and thank Thomas Loertsch, et al. for the great work in detailing the specification. We hope our implementation helps move the draft to a full-fledged standard. Mark, this is great news! And every real world example use of a microformat certainly helps both demonstrate its usefulness, and discover the challenges encountered when a draft proposal is implemented with real content. Please feel free to add your experiences here: http://microformats.org/wiki/hrecipe-issues by either adding to existing issues, or opening new issues for any problems you encountered. I'll also add my thanks to Thomas and everyone else who has contributed to hRecipe. You can now view recipes from the likes of Food Network Kitchens, Alton Brown, Bobby Flay, Giada De Laurentiis, Paula Deen, Rachael Ray, Mario Batali, Emeril Lagasse, and more in a wonderful machine-readable form. It is the goal of Scripps Networks Interactive (NASDAQ: SNI) to be the world's largest distributor of hRecipe marked recipes before the end of Q2 2010 when we roll out the spec on http://www.recipezaar.com. This too is great news. I noticed that the reviews of recipes are also marked up with hReview (and reviewers with hCard). Anxious to hear comments, feedback, and anything we can do to help the microformats community. Great work! Do you have an estimate for how many recipes are now on Foodnetwork.com? I have added Foodnetwork.com to the list of recipe sites in the wild that support hRecipe: http://microformats.org/wiki/hrecipe#Examples_in_the_wild Thanks again for your excellent work Mark! Tantek http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats.org hacked!
On Mon, Sep 7, 2009 at 4:32 AM, Toby Inksterm...@tobyinkster.co.uk wrote: Seems to have fallen victim to the current WordPress security problem. Thanks for the heads-up Toby. Ben Ward had already updated our WordPress install to 2.8.4 a couple of days ago, so I'm not sure if the attack still got through, or if what you were seeing were remnants of an attack before upgrade. I've cleaned up the permalinks problem as discussed here: http://www.journeyetc.com/uncategorized/wordpress-permalink-rss-problems/ and double-checked the list of users/admins for anything out of place. If you see any other remaining signs of the current WordPress security problem, please feel free to send specifics to me or Ben Ward. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] outstanding hCard and hCalendar issues resolved (except dtend which needs your opinion!)
All outstanding hCard and hCalendar issues have been resolved (except for dtend). If over the past several years you raised an issue on the wiki regarding hCard and/or hCalendar, or if you work on an hCard/hCalendar implementation, please take a look at: * http://microformats.org/wiki/hcard-issues-resolved * http://microformats.org/wiki/hcalendar-issues-resolved And review resolutions to see if you find anything you disagree with or anything left unresolved. Please make comments inline on issues and issue resolutions on the wiki. One issue in particular I want to draw your attention to: I have chosen to keep the dtend inconsistency issue *open* because I have changed my mind about what I think is the best resolution for it (based on additional evidence collected this year), and very much want authors and developers to review this issue, and add both their own research/evidence and opinions towards the goal of making the best decision for the community: http://microformats.org/wiki/dtend-issue I am incorporating the resolutions as follows: * Minor, informative, and clarifying brainstorming and resolutions will be applied to the existing hCard and hCalendar pages (often informative examples and FAQs) * Minor, normative changes and brainstorming that likely affect implementations will be made to 1.0.1 versions of hCard and hCalendar ** e.g. requiring implementation of the value-class-pattern. * Major changes and additions e.g. in brainstorming will be added to version 1.1 *drafts* for hCard and hCalendar ** e.g. beginning incorporation of stable draft vCard 4.0 properties into hCard 1.1 ** I'll likely track and collect 1.1 additions first on respective *-brainstorming pages before actually writing up v1.1 drafts. Note that since hCard and hCalendar are or contain building blocks used by nearly every other compound microformat, it is highly likely that many of these resolutions and fixes will make their way into iterations of most other microformats (such as hReview, hAtom, hResume, etc.) thus if you're an editor of a microformat, you should review the resolutions as well. Thanks, Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
updating hAtom (was Re: [uf-discuss] Progress on hAtom?) and a quick note on hNews
On Wed, Jul 1, 2009 at 10:59 AM, Simondud...@gmx.de wrote: I just wondered if there is any progress on hAtom. There are many open questions on the issues page, but nothing really happend since version 0.1. Hi Simon, apologies for the delay - been a bit busy with organizing microformatsDevCamp[1]. First all, thanks very much for adding to the notes on hAtom issues and proposed resolutions: http://microformats.org/wiki/hatom-issues This is precisely one of the first things we need to do to update hAtom: * proposed resolutions to all outstanding issues with at least some amount of consensus. Next we will need to take a look at any hAtom brainstorming that has occurred since hAtom 0.1 and consider each brainstorm to see if it makes sense to include in hAtom 0.2 or not. Finally, we'll need an editor (hopefully David Janes, but he's agreed to let me co-edit in the event he is too busy to do so) to incorporate these changes in 0.2. I'm currently taking similar steps to updating hCard/hCalendar/hReview, and hAtom would be next on my list. You (as well as everyone else here) can very much help out with this process by reviewing the issues and resolutions of each of those specs (for hAtom, take a look at hCard issues and resolutions too, as they may affect hAtom as well). Join the IRC channel as well - where often times it is much easier to get quick questions about issues or specs answered, and to make faster progress. http://microformats.org/wiki/irc Thanks, Tantek P.S. I've been taking a look at the related AP proposal/work on hNews - and I think there is a lot there that makes sense. We should definitely consider hNews as part of hAtom brainstorming to considered for incorporation into hAtom 0.2. [1] http://microformats.org/wiki/events/2009-07-25-dev-camp ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What does the 'h' in microformats mean?
On 09.07.09 10:15, Martin McEvoy mar...@weborganics.co.uk wrote: Hello all I wander if anyone can tell me what the 'h' in microformats means? I have always thought 'h' was for 'hypertext' but could it mean 'hypermedia' or even 'html' It's in the microformats FAQ :) http://microformats.org/wiki/faq#Q._What_is_the_.27h.27_for.2C_in_front_of_Calendar_and_Card.3F As the inventor+namer of hCalendar and hCard[1] (the first use of the lowercase 'h' prefix convention), I can tell you that the 'h' stands for the HTML version of, in those cases, of iCalendar and vCard respectively. Sometime after the fact (at least a few years ago, before it came up again in this thread), someone else posited (maybe Rohit?) that the h looked like an upside down greek letter mu µ which is used in scientific notation to mean micro - but that was purely a coincidence. Tantek [1] http://tantek.com/log/2004/09.html#d30t1725 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mixing vocabularies
Replies to Thomas and Bob inline: On Tue, Jun 30, 2009 at 3:43 AM, Thomas Loertschloertsch.tho...@guj.de wrote: I'll try to copy (more of) the referenced conventions inline and make the page more self-contained. But that isn't always as easy as it sounds: e.g. author is reused from hAtom which itself states that an Entry Author element MUST be encoded in an hCard, which - if I got it right - leads to the following construct: div class=hrecipe p class=author vcard fnHans Wurst/p That's not exactly self-containing and standalone. But searchmonkey would know how to parse it, right? Currently Searchmonkey (and any other hCard parser should treat that hCard as invalid). Per the hCard FAQ you cannot combine vcard and fn classnames on the same element: http://microformats.org/wiki/hcard-faq#Can_you_mix_properties_and_the_root_class_name However, as this question / implied proposal has come up many times, and microformats does have the design principle of starting and making solutions as simple as possible, I've added a root only shorthand syntax proposal to hCard brainstorming for hCard 1.0.1 that would allow specifying an hCard with only the root class name. http://microformats.org/wiki/hcard-brainstorming#root_only_shorthand_syntax E.g.: p class=vcardHans Wurst/p Which would then imply the one required property fn, which could then be used to imply additional property values. In short, this would allow the following (slightly simpler) markup for the above example: div class=hrecipe p class=author vcardHans Wurst/p For more details of how ROSS would work, or to note issues or suggest improvements, please do not reply inline in email, and instead see and add to: http://microformats.org/wiki/hcard-brainstorming#root_only_shorthand_syntax On Fri, Jul 3, 2009 at 7:50 AM, Bob Douglasbd-...@sbcglobal.net wrote: Hi, I'm still getting oriented to the list, apologies for the late response, length, and any glaring naiveness. Would post on the wiki, but not familiar enough yet to understand where it would fit. Hello and welcome Bob. Here is a brief guide to where at least some content belongs/fits on the wiki: http://microformats.org/wiki/put-it-on-the-wiki#where_to_put_what_on_the_wiki This has been a helpful thread, but seems more guidance on handling mixed context may be a looming issue on MediaWiki/Wikipedia type sites - especially for users who will be introduced to microformats through Operator (Firefox), Oomph (IE), or similar browser add-ons. Two usage problems are: A. Corruption (or significant alteration) of results over time as different editors insert microformat producing templates into wiki pages or add microformats to existing (mw-)templates. B. Significant differences in behavior due to the core rules applied in emerging microformat browser tools. Here are two examples from current (30JUN2009) Wikipedia articles: 1. Two vcards/vevents on a page (http://en.wikipedia.org/wiki/Einstein) Thank you for providing a URL to a real world example. The Einstein bio page contains two (un-nested) infoboxes that both declare vcard and vevent classes on the table as : table class=infobox vcard vevent td class=fn summaryAlbert Einstein /table table class=infobox biography vcard vevent td class=fn summaryAlbert Einstein /table Oomph returns the resulting two contacts and two events - none of which are valid (missing the required n and dtstart values). In particular the hCards seem to be fine (n is implied from fn, works in Operator), and thus if you are seeing a problem with Oomph, it may be a bug in Oomph. I just created an oomph-issues page and summarized this problem - it could probably use more details to help track down the problem: http://microformats.org/wiki/oomph-issues Detector returns a single valid contact I'm unfamiliar with the Detector microformats implementation - could you add it to: http://microformats.org/wiki/implementations by extracting the n values (family-name, given-name) per the spec from the single space delimited fn string. Sounds like it is behaving correctly. Luck in this case as most other bio pages include a middle name or initial. One or more example URLs for pages like that would help with refining the resolutions to related hCard issues (when an fn includes a middle name or initial and there is no n property). Can't tell from this example if Detector is ignoring or merging the duplicate vcard with identical fn/n values. (Anybody know the logic?) However, it does ignore the invalid events. Here are the complete contents Detector produces for the Einstein page: BEGIN:VCARD PRODID:-//kaply.com//Operator 0.8//EN Ah - is Detector another name for the Operator Firefox extension? http://microformats.org/wiki/operator SOURCE:http://en.wikipedia.org/wiki/Einstein NAME:Albert Einstein - Wikipedia, the free encyclopedia VERSION:3.0
Re: [uf-discuss] mixing vocabularies
On Sun, Jun 28, 2009 at 2:38 PM, Peter Mikapm...@yahoo-inc.com wrote: Hmmm what happened to designing for the 80/20 case? Indeed, that and other issues (see below) Dan Brickley wrote: On 27/6/09 01:40, Peter Mika wrote: Hmm... what could possibly be the purpose of an hCard inside an ingredient? how about contact details for suppliers and manufacturers of rare or special ingredients? either for health reasons or for super-fancy cookery? Dan While it seems reasonable that someone might theoretically publish a recipe which explicitly mentions a specific supplier or manufacturer (for whatever reason), as provided above, this is a theoretical example, and thus would benefit from citing one or more real world examples per: http://microformats.org/wiki/mailing-lists#Use_real_world_examples Please also feel free to document the theoretical example on the hRecipe brainstorming page, and note explicitly that it is a *theoretical example* so that it can be considered accordingly: http://microformats.org/wiki/hrecipe-brainstorming Tom Morris wrote: Well, I'd use ... [previous formats/vocabularies] Please add previous formats or vocabularies that relate to a type of content to the respective *-formats page, e.g. in this instance, http://microformats.org/wiki/recipe-formats per http://microformats.org/wiki/put-it-on-the-wiki#previous_formats_and_vocabularies Thanks, Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Wanted: a pattern indicating a subsidiary-parent-company relationship
On Sun, Jun 14, 2009 at 11:44 PM, Mirko Gustonymirko.gust...@gmail.com wrote: Hello, does anyone know if there is a pattern for describing a subsidiary company to parent company relationship? Hi Mirko, I don't know of any patterns currently, but you're certainly asking in the right place. I need to mark up the following: on the website for company B Ltd. I want to sho that it's a subsidiary of A Inc. p Part of a href=http://www.a-inc.com/;A Inc./a /p Could you provide a URL to the website for company B? [1] I tried to find something for this, but all I found was XFN which is just for human beings. Maybe a solution can be based upon it? I've captured this area as business to business relationships on the XFN brainstorming page, along with POSH suggestions: http://microformats.org/wiki/xfn-brainstorming#business_to_business Thanks, Tantek [1] http://microformats.org/wiki/mailing-lists#Use_real_world_examples -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Any bettter way to do an include in hreview?
On Wed, Jun 3, 2009 at 8:05 PM, Elli Albek e...@sustainlane.com wrote: Hi Tantek. Link to a page with reviews: http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8 You can also look at Yelp. Similar page content. Thanks for the real world URL example - that helps a lot. I've collected the example you gave and another similar example from Yelp on the container-brainstorming page: http://microformats.org/wiki/container-brainstorming#examples I encourage you to add any other similar examples that you think may help illustrate the problem and provide variants to test with any possible/proposed solution. Two things we want: 1. Remove repetition 2. Add review aggregates without more repetition Agreed on both counts. Generally I would like to stop using microformat_detail, and not restructure the HTML. The microformats spec can makes it easier to support variety of page structures without includes/hidden blocks by having other association rules. In general one of the goals of microformats is to have minimal if any markup impact upon the HTML of otherwise well-formed (hopefully valid) pages, by only adding a few class names and perhaps rel values. Sometimes additional elements are necessary for wrapping discrete pieces of content. We very much try to avoid duplicating content - one of the big advantages of microformats over alternatives such as using XML or other side-files to duplicate the content, or inline HTML comments to duplicate the content. A few suggestions that will make implementation simpler for different HTML trees: I think there are definitely some good options worth exploring in your suggestions, and I encourage you to add your markup suggestions to the wiki (with perhaps one new subsection per each alternative you suggested) so that they are not lost in the email archives, and so that others may review and build upon them: http://microformats.org/wiki/container-brainstorming#markup_proposals Another suggestion: Collapse trees. If microformats are already flexible in what they allow as parent child, you might as well consider a rule that allows you to collapse an entire tree of microformats: a class=item hcard fn url href=...name/a The collapsing of properties with a root node actually presents more problems, especially in the context of microformats that contain other microformats (e.g. an hCard location in an hCalendar event). http://microformats.org/wiki/hcard-faq#Can_you_mix_properties_and_the_root_class_name That being said, your general suggestion of collapse trees is one that I very much agree with, and am looking at doing so in some cases in hCard to help resolve some of the issues raised (e.g. the fact that n is a grouping property for the sub-properties of given-name, family-name etc.). More in http://tr.im/hcardri Thanks, Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Any bettter way to do an include in hreview?
On Fri, May 29, 2009 at 7:23 PM, Elli Albek e...@sustainlane.com wrote: Hi, We have the typical page with one business information on top and many reviews for that business on the page. Hi Elli, Could you provide a URL[1] to one of your typical pages with one business information on top and many reviews for that business on the page? A complete page/document example with actual content will make it much easier to understand how to mark it up as semantically as possible while avoiding as much as possible the introduction of duplicate information and extraneous markup. Thanks, Tantek [1] http://microformats.org/wiki/mailing-lists#Use_URLs_to_examples ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Congrats to Kavi and team on their microformats implementation! Follow-up on examples
Kavi and team, Well done with your implementation of microformats as part of Google's new rich snippets feature in search results! I encourage you to add an entry to the following wiki pages linking to your implementation description page: http://microformats.org/wiki/implementations http://microformats.org/wiki/search-engines And I also encourage anyone who has published hCard, hReview, hCalendar, or hAtom (e.g. those of you that have added your sites to the respective examples-in-wild pages [1] to submit their sites using Google's form: http://www.google.com/support/webmasters/bin/request.py?contact_type=rich_snippets_feedback I've also found microformats examples on the Google Webmasters forum and wanted to bring them to the attention of the microformats community: http://google.com/support/webmasters/bin/answer.py?answer=146645 http://google.com/support/webmasters/bin/answer.py?answer=146646 http://google.com/support/webmasters/bin/answer.py?answer=146750 http://google.com/support/webmasters/bin/answer.py?answer=146861 http://google.com/support/webmasters/bin/answer.py?answer=146897 Kavi, if there are additional pages in the Webmasters forum that show microformats examples, please feel free to reply and note them. It may be useful to create a wiki page (perhaps linked from your entries on the above-mentioned wiki pages) that links to all the google.com microformats example pages. I encourage everyone to take a look at the microformats examples on the above google.com pages and provide feedback (either here, or preferably on a wiki page) including any suggested markup improvements. Thanks! Tantek [1] Everyone who has added microformats to their pages should be sure their site(s)/page(s) are listed in the respective examples in the wild page on the wiki, e.g.: http://microformats.org/wiki/hcard-examples-in-wild http://microformats.org/wiki/hreview-examples-in-wild http://microformats.org/wiki/hcalendar-examples-in-wild -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Is this illegal? 1) dtends for yyyy or yyyy-mm. 2) Wikipedia vevents for birth and death.
On Thu, Feb 19, 2009 at 8:56 PM, JMesserly swarm...@gmail.com wrote: I dropped a word- I meant to write I will interpret lack of further responses to the two inquiries as acknowledgment that the techniques described are regarded as acceptable in the microformats community. JMesserly, that may not be a reliable conclusion as: 1. The microformats wiki is definitive, the email lists are only informative. http://microformats.org/wiki/mailing-lists#Use_the_wiki_to_share_state_instead_of_email http://microformats.org/wiki/wiki-better-than-email 2. Absence of objections should not be considered approval http://microformats.org/wiki/logical-flaws#Absence_of_objections_is_not_approval I did not intend to pre-empt anyone's further comments and in fact would like to hear any additional opinions one way or the other. I think there are still many ways of looking at the one event vs multiple events question, and thus you will likely see several comparably valid interpretations. Perhaps consider adding an instance of the examples you have with markup to the hCalendar examples page (maybe in a new section) http://microformats.org/wiki/hcalendar-examples And from there further discussion/iteration can occur. In addition, I have logged a summary of the original issues/question of is dtends for or -mm ok here: http://microformats.org/wiki/hcalendar-issues#2009 Please feel free to add more details/links of your question/issue there as well to make sure we capture it properly. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCard slowing adoption of microformats?
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 [EMAIL PROTECTED] Date: Sun, 23 Nov 2008 20:47:31 To: [EMAIL PROTECTED]; Microformats Discussmicroformats-discuss@microformats.org 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/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Incorrect mention of the address element for hAtom entry author in the Wiki
On Tue, Nov 11, 2008 at 11:26 AM, David Janes [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2008 at 2:14 PM, Sarven Capadisli [EMAIL PROTECTED] wrote: hAtom Entry Author states an Entry Author element should be encoded in an address element [1]. This is misleading and in most cases an incorrect use of address 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] address ... 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. address 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/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
value excerption pattern brainstorming general appeal for issues (was Re: [uf-discuss] Appeal for Issues: Empty spans in value-excerption-pattern)
On Thu, Nov 6, 2008 at 1:53 AM, Ben Ward [EMAIL PROTECTED] 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 object 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/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcard: additional additional names
On Thu, Aug 14, 2008 at 7:48 AM, Martin McEvoy [EMAIL PROTECTED] wrote: Hello Michael Michael Smethurst wrote: On 14/8/08 12:32, Brian Suda [EMAIL PROTECTED] wrote: 2008/8/14, Michael Smethurst [EMAIL PROTECTED]: span class=family-name-prefixvan/span ... I've asked around and the label Onomastic prefix has been suggested: http://www.listservicedirect.com/ethnic_religious.html But again it doesn't seem to differentiate between attached and detached prefixes So I'll stick with family-name-prefix for now (it's easier to spell for one) unless anyone has a better idea *family-name-preposition* is probably more accurate to what you are trying to describe von in dutch simply means of or from, O as in O'Donnell, in Irish means descendant of or grandson of (in Gaelic Ua), Mc and Mac are again Irish meaning son of, and Fitz as in FitzGerald is an Irish hash of the french fils de which also means son of. What I am trying to say is any of these prefixes simply mean of and shouldn't really be considered part of their family name although they mostly are, think Van Gough would you know who I meant if I just said Gough? Best wishes Martin McEvoy Jim O'Donnell (and others), This is the most knowledgable discussion I've seen yet of any extension / decomposition of family-name. As we're not (currently) adding any properties to hCard beyond what is in vCard, there isn't a format solution for this. However, we are *documenting* possible extensions to vCard properties here in the hopes that suggestions with sufficient merit may make it into an update of vCard (which we could then add to hCard) : http://microformats.org/wiki/vcard-suggestions I encourage you to add your suggestion of a family-name prefix or preposition etc. to that page, perhaps in the new sub-properties section: http://microformats.org/wiki/vcard-suggestions#Suggestions_for_New_Sub-properties In the meantime, the POSH approach is a good one. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-ecolabel
On Thu, Aug 14, 2008 at 5:52 PM, Martin McEvoy [EMAIL PROTECTED] wrote: Hello all http://microformats.org/wiki/Main_Page#Drafts rel-ecolabel http://microformats.org/wiki/rel-ecolabel - for indicating ecolabelled products/services/companies I didnt know there was such a thing! when did this get to Draft? I dont remember any discussion about ecolabels? can someone point me to the discussion please I have been a bit slow on this one. I didn't see any discussion either, and the proposer who added it to the drafts section clearly failed to read the introduction or how-to-play or process or anything else above where they added it on the Main_Page. Moved to a new section in exploratory discussions (along with a few others, more to follow I'm sure). http://microformats.org/wiki/exploratory-discussions#failed_to_follow_process Tantek -- http://tantek.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hCalendar for events in a table format
On 3/5/08 2:17 AM, Brian Suda [EMAIL PROTECTED] wrote: 2008/3/5, Toby A Inkster [EMAIL PROTECTED]: That would be contrary to Tantek's guidelines on the Wiki: | If the element is a table data cell td, then: | | 1. parse its headers attribute as a space separated set of local IDs | | 2. find the td and th elements referenced by those IDs (call them | header cells) and consider them part of the element being parsed | as follows: | | 1. Treat the header cells as children of the element, ordered by |the order of ids in its headers attribute, immediately |following the last child node (text or element) or the |element. (The basic idea is that the content from those |header cells is used to construct the VEVENT, but secondary |to (AFTER) the content in the data cell itself, so that the |data cell can customize/override part of the data in the |header, e.g. if the header cell included both start time and |location, and the event was being held at a different |location). | | 2. Parse the axis attribute of a header cell as a comma- |separated list of categories. These categories must be used |in addition to (and before) any class names on that header |cell for determining whether it is a property of the VEVENT. --- correct, then we should further discuss this on the dev-list and correct the wiki as needed. Given Benjamin's message about the axis attribute: http://microformats.org/discuss/mail/microformats-discuss/2008-March/011679 .html and the fact that we've never needed to use the axis attribute in a realworld tabular event example, nor has that step been implemented, I've removed the Parse the 'axis'... step. http://microformats.org/wiki/hcalendar-brainstorming#Tabular_event_calendars Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hCalendar for events in a table format
On 3/5/08 5:02 AM, Toby A Inkster [EMAIL PROTECTED] wrote: However, implied headers like this while lowering the barrier to entry for authors, would considerably raise the barrier for parsers -- mostly because of colspan and rowspan, which would be an absolute pain to handle. Speaking from the experience of working on a browser rendering engine which *did* have to handle colspan and rowspan, I can certainly state that requiring a microformats parser to perform a table layout (effectively what it takes to support colspan and rowspan) would *drastically* raise the effort necessary and would introduce numerous opportunities for subtle bugs and incompatibilities. I think it would be reasonable to adopt a design principle of *not* requiring microformat parsers to perform a table layout, even if it can be used to make inferring semantics easier. Although microformats' general principle is to place the burden of effort onto parsers, implied headers via the scope attribute may shift the effort *too* far in that direction. What do others think? Yes, very much so too far in that direction. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar for events in a table format
On 3/4/08 11:02 AM, Bob Jonkman [EMAIL PROTECTED] wrote: Is there an example of hCalendar in a table? The example link for Web Essentials 05 Session program on http://microformats.org/wiki/hcalendar-brainstorming is rotten (the domain we05.com has expired). In short, my question is: Do I make each table cell an individual VEVENT? an individual VCALEDAR item? How do I deal with repeated data without hiding text? I want to add microformats to http://sobac.com/brainshare/ The table has a thead section, but no th cells. Bob, take a look at: http://microformats.org/wiki/hcalendar-examples-in-wild#conference_schedules I will also attempt to recover the lost we05.com Web Essentials 05 Session program example from archives and see if I can post it somewhere and then add a link to it from that conference schedules section. FAQ added: http://microformats.org/wiki/hcalendar-faq#Is_there_an_example_of_hCalendar _in_a_table Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hCard AGENT example parsing implications explained (was re: change ...)
On 2/7/08 7:14 AM, Thom Shannon [EMAIL PROTECTED] wrote: perhaps there was prior discussion and agreement that was just a long time ago? Have you searched the archives or asked Tantek directly? Yes, this is from a long time ago, may even predate microformats.org. It's not a change except in making it more clear. The hCard AGENT Example has demonstrated this requirement for a long time. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] need for mfo / encapsulation / forward-compatible parsing (was re: changes...)
On 2/7/08 10:08 AM, Manu Sporny [EMAIL PROTECTED] wrote: It invalidates the need for mfo in hcard, doesn't it? If it were applied to the rest of Microformats, it would invalidate the need for mfo entirely. This is one of the reasons mfo has not progressed much further than the examples given in mfo-examples - it hasn't been necessary in practice. However, mfo may be needed for current parsers to be able to properly encapsulate new microformats that come along (this is often referred to as forward-compatible parsing), in the same way that they can explicitly do so with the limited set of existing microformats. As this topic is more related to parsing, I think the -dev list (on the To line) may be the more appropriate place to discuss it, while hopefully sympathetically taking into consideration the additional authoring cost/requirement of adding mfo (or whatever we come up with) as an additional class name to new compound microformats' root elements, e.g. class=mfo hunknown. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] [admin] please keep hAudio discussions on microformats-new
Since hAudio is still much more of a new microformat in development rather than a current microformat that people are simply asking about how to use, please keep discussions about it on the microformats-new list. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Possible alternative methods for include
On 2/3/08 4:34 AM, Toby A Inkster [EMAIL PROTECTED] wrote: Toby A Inkster wrote: The order of the space-delimited class attributes should be considered significant -- that is, in foo class=bar #baz the content referred to by #baz is logically included as the last child of the foo element, but in foo class=#baz bar, it is logically included as the first child. I shall add to the Wiki momentarily... Wikied here: http://microformats.org/wiki/include-pattern-strawman Also fleshed out to include an example where included data is placed in the middle of its parent element rather than at the beginning or end. Two problems: 1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't. 2. inclusion of arbitrary data (#baz) in the class attribute is a documented anti-pattern. http://microformats.org/wiki/anti-patterns#data_in_class_attributes Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Digg joins DataPortability Project (Microformats mentioned)
On 1/29/08 6:24 PM, Manu Sporny [EMAIL PROTECTED] wrote: Digg has joined the DataPortability[1] Project: http://blog.digg.com/?p=108 From the piece: Just this week, we added MicroID, a Microformat that lets you prove to other services that you own your Digg user profile. Since when was MicroID a Microformat? Reading through the spec, it does some very non-microformatty things: span class=score microid-mailto+http:sha1:ca94387152e8ea62fee73c45c4bae79e545434855/span Manu you are correct, MicroID is *not* a microformat. It did not follow the process, and violates numerous microformats principles. It can however be described as an attempt to represent some meaning in semantic HTML (although storing such potentially arbitrary data values in the class attribute is an anti-pattern). Thus it is at best a poshformat and I will list it there. http://microformats.org/wiki/poshformats It's great that they're doing the whole data portability thing, but looks like they're not quite sure about the details yet? Anyone know anybody at Digg that could shed some light on where they're going with all of this? Previous to the PR about DataPortability, Digg had already implemented a bunch of microformats support like XFN rel=me. I expect Digg to continue to implement microformats support independent of any PR efforts / announcements. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Dublin Core as a microformat (was: Re: xfn and biographies)
On 1/30/08 4:16 PM, Ben Ward [EMAIL PROTECTED] wrote: Is that the only problem we'd be trying to solve in making a Dublin Core microformat? Simply taking an existing format (like Dublin core) and reusing its vocabulary as class names is insufficient to make a microformat. microformats are based first and foremost on existing *content* publishing behaviors, not first on existing *markup*, nor first on existing *formats*. Only after existing *content* publishing behaviors are documented and implied schema are thus determined does it make sense to document previous attempts at formats for that type of content, and look at re-using *some* of their vocabulary that maps to the implied schema determined by the documented content publishing patterns. Since this has come up a few times in the past (there seem to be lots of folks that want to repurpose a previous format, no matter the actual utility or use cases, into HTML, now that microformats has demonstrated the usefulness of doing so), I've written up a process FAQ entry on this, and expanded further upon it there. http://microformats.org/wiki/process-faq#Can_a_microformat_be_class_names_f rom_another_format_vocabulary Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/8/08 6:47 AM, Christopher St John [EMAIL PROTECTED] wrote: On Jan 7, 2008 8:14 PM, Tantek Çelik [EMAIL PROTECTED] wrote: The distinction of properties, values, types, schema etc. are well documented computer science terms. Actually, in knowledge representation terms they're usually not. To get around the what's meta problem people generally just pick a level that seems reasonable to the problem at hand and go ahead knowing that other choices might have been equally valid. (Computer geeks can think Java Reflection or the Lisp MOP. When is a type actually data? Just don't go there :-) ) In HTML for example, the sematic level of the various tags varies quite a bit: p is very generic, cite very specific, so denying the question isn't helpful to those trying to write a new format (or understand the logic behind existing formats) I generally agree that the discussion of meta-levels can be unproductive, but there are choices to be made. A better answer to the question about data in class attributes might be: Yes, it's data, and there are some fairly deep questions about what is appropriate and what is not. We tried to cut through the Gordian knot by simply avoiding the deep questions. When possible, names are just stolen from existing standards (hCard). Otherwise, authors have just used intuition to make some reasonable choices. There is no hard and fast rule. Different microformats have very different sorts of stuff in the class attribute (just compare xoxo to hReview), the key is to make the stuff appropriate to the task at hand. If you want to author a new microformat, you're going to need to make some choices and experience has shown the community (and lots of research) will help you with the appropriateness of your vocabulary and its 'semantic level'. There are also guidelines on the wiki that have proven useful in other efforts. Long discussions of the what counts as meta often end badly, so don't worry about it too much. Instead, concentrate on existing practice and trust the community to help with judgement calls. This is a much better answer. Christopher, perhaps you could consider adding this to the FAQ in answer to to Katrina's question: What sort of meta-data is acceptable and what others aren't?[1] http://microformats.org/wiki/faq [1] http://microformats.org/discuss/mail/microformats-discuss/2008-January/01127 8.html One way to learn more about such distinctions is to pick up a book or two on computer science and data structure and learn about them. I don't personally mind a little heat in my technical discussions, but this is exactly the sort of remark Andy was banned for, and it's unfair to hit a person who can't hit back. Hitting back is still hitting. It doesn't make it right. Instead, the right thing to do is to simply call it out (as you did). and... On 1/8/08 12:08 AM, Andy Mabbett [EMAIL PROTECTED] wrote: One way to learn more about such distinctions is to pick up a book or two on computer science and data structure and learn about them. Yes; they told me that a few years before they awarded me my degree in the subject. My bad for making the assumption that you didn't have a computer science degree (unfortunately another example of the logical flaw previously noted). Your snarky comment, against your own policy, also adds little to the debate. Though not intended as snarky, upon re-reading I can see how it could have been interpreted that way. Thus, apologies, comment retracted. Based on this feedback I will refrain from posting on microformats mailing lists and making wiki edits (other than admin duties of blocking/reverting spammers) for 24 hours. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/8/08 12:08 AM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes properties!=values. types/schema are not just as much data. You seem to be making unsubstantiated assertions and arbitrary distinctions. Please stop making the assumption of lack of foundation logical flaw. I made no logical flaw. You posted assertions; and made no attempt to substantiate them. The logical flaw is the *assumption* that your statement made that there was no (or appeared to be no) foundation/substantiantion for my assertion. You can't know that, therefore the assumption is invalid. Such invalid assumptions do not contribute to debate, and are not helpful. As I said, rather than assuming a lack of substantiation, simply ask for it, as the guidelines indicate. http://microformats.org/wiki/mailing-list#Avoid_logical_flaws http://microformats.org/wiki/logical-flaws#Assumptions_of_lack_of_foundatio n_or_justification Posting URLs of your own assertions on the wiki as though they were evidence contributed little to the debate. Those are not my assertions, but merely documentation of a logical flaw. If you dispute that logical flaw, please indicate *why* you think that logical flaw is itself flawed, perhaps in a nested list item, on the wiki. Consider: street- vs. extended- address sub-properties of adr property given- vs. additional- name sub-properties of n property work- vs. home- tel *values* for 'type' sub-property of tel property. Arbitrary distinctions. Not arbitrary, but based on distinctions made in vCard, hence I cited: These distinctions come from RFC 2426 as well as http://microformats.org/wiki/hcard-design-methodology Read both carefully to understand these distinctions better. I'm fully aware of both the source and meaning of those terms. Then I suggest re-reading RFC2426 to better understand the source of the distinctions, rather than categorizing them as arbitrary. theoretical example deleted The examples were not theoretical, but real (though surname changed out of courtesy to the person concerned. Please provide a URL to a public resource on the Web to substantiate the assertion that they are real for the purposes of microformats. Hence why microformats focus on real world examples on the web that are also *common*. And people *commonly* publish what are clearly and unambiguously (to humans, but not, without the additional mark-up of a microformat, to machines) home or work telephone numbers, without saying as much on the page. Same thing. needs real world example URL. please document on hcard-issues. http://tinyurl.com/2w4r3v Thank you. Please document on hcard-issues. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/7/08 11:52 AM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], ryan [EMAIL PROTECTED] writes On Jan 6, 2008, at 12:30 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Katrina [EMAIL PROTECTED] writes I want to specify a work-related telephone number, but I just want to label it 'Phone:'. The closest I can find to do this is the abbr, however, work is not an abbreviation of 'phone'. eg. abbr class=type title=workPhone/abbr Q2. Would it be possible to do something like this, instead? span class=type title=workPhone/span We could - if there is sufficient support - adapt the recently- proposed sub-microformat pattern, so that: foo class=tel-work555/a becomes parsed as a work-type 'phone number. I don't think we want to do this, because it puts human-readable data (work) in a spot that's no longer visible. Except that, as the OP stated, that it's a work number is clear from the context. In any case, how is that different from: abbr class=dtstart title=2008-01-077 Jan/abbr where 2008 is hidden? title attribute is displayed in tool-tips and thus is at least semi-visible and thus human verifiable. class attribute is not. http://microformats.org/wiki/faq#Q._Should_human_readable_data_go_into_clas s_names.3F Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/7/08 2:42 PM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes In any case, how is that different from: abbr class=dtstart title=2008-01-077 Jan/abbr where 2008 is hidden? title attribute is displayed in tool-tips in some, but far from all, browsers. http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 Values of the title attribute may be rendered by user agents in a variety of ways. Nothing about tool-tips there. Nonetheless what browsers do implement is a fact. http://microformats.org/wiki/faq#Q._Should_human_readable_data_go_into_class _names.3F Perhaps you might wait for resolution of such issues before imposing your own view on the wiki. Data in the class attribute is a known anti-pattern. Not a new issue. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/7/08 3:46 PM, Andy Mabbett [EMAIL PROTECTED] wrote: Data in the class attribute is a known anti-pattern. extended-address, street-address, locality, region - all just as much data in class attributes. properties!=values. types/schema are not just as much data. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/7/08 4:01 PM, Katrina [EMAIL PROTECTED] wrote: Tantek Çelik wrote: On 1/7/08 2:42 PM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes In any case, how is that different from: abbr class=dtstart title=2008-01-077 Jan/abbr where 2008 is hidden? title attribute is displayed in tool-tips in some, but far from all, browsers. http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 Values of the title attribute may be rendered by user agents in a variety of ways. Data in the class attribute is a known anti-pattern. Not a new issue. I admit I am new to microformats, however, I have always understood class attributes to hold a type of data: meta-data. They describe what sort of data that particular element holds. Hi Katrina, what sort of data is what a type is, and a type is very distinct from data itself. E.g. integer is a type. -1,0,1 are examples of data of that type. So if you have a list of books, instead of giving it a class attribute of red or blue, it should be labeled books. Or more pertinent to the microformats, class=vcard. vcard is meta-data saying that this particular element holds a vcard. It is a very specific kind of meta-data that is a type. Similar to how the p tag is saying this particular element holds a paragraph. Reading this: http://microformats.org/wiki/anti-patterns#data_in_class_attributes I just don't seem to understand how the Microformats community decides what sort of meta-data is acceptable and what others aren't? In general, the term meta-data tends to be more confusing than illuminating, it means too many different things to different people, and thus we try to avoid its use in discussions. microformats simply extend the typing/schema information that HTML itself has. Where HTML has a limited vocabulary to markup what data/content is paragraphs, blockquotes etc. microformats extends that limited vocabulary, also in a limited way, to markup what data/content is people, organizations etc. I also thought that Microformats were to take human data and translate that into machine-readable. Not quite. Mostly microformats just markup existing data in the page so that machines can find it and know what type of data it is. In some instances a machine-readable instance of the data is necessary, but those are both the minority and minimized if at all possible. In order to do so, context needs to be translated to make it machine readable. If you come across a business selling something, as a human, you can determine that it is work related, and it doesn't need to be labeled 'work'. However, a machine cannot make that distinction and needs to be explicitly told. How does the Microformats community then allow people normal contextual communication but also specifies the contextual data for machines? The broader problem of arbitrarily extracting meaning from any human prose is an Artificial Intelligence problem far beyond that of microformats, and is deliberately not a goal. Hence why microformats focus on real world examples on the web that are also *common*. Surely the way to do that is through meta-data? See above. The term meta-data is too heavily overloaded to be really useful in a discussion. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/7/08 4:46 PM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes On 1/7/08 3:46 PM, Andy Mabbett [EMAIL PROTECTED] wrote: Data in the class attribute is a known anti-pattern. extended-address, street-address, locality, region - all just as much data in class attributes. properties!=values. types/schema are not just as much data. You seem to be making unsubstantiated assertions and arbitrary distinctions. Please stop making the assumption of lack of foundation logical flaw. http://microformats.org/wiki/mailing-list#Avoid_logical_flaws http://microformats.org/wiki/logical-flaws#Assumptions_of_lack_of_foundatio n_or_justification The distinction of properties, values, types, schema etc. are well documented computer science terms. Rather than asserting unsubstantiated assertions and arbitrary distinctions, if you don't understand such distinctions, ask. One way to learn more about such distinctions is to pick up a book or two on computer science and data structure and learn about them. Consider: street- vs. extended- address sub-properties of adr property given- vs. additional- name sub-properties of n property work- vs. home- tel *values* for 'type' sub-property of tel property. These distinctions come from RFC 2426 as well as http://microformats.org/wiki/hcard-design-methodology Read both carefully to understand these distinctions better. On 1/7/08 4:59 PM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Mostly microformats just markup existing data in the page so that machines can find it and know what type of data it is. theoretical example deleted The given and additional names are not indicated on the page; not even by context. Please provide the real world example URL for the page mentioned, otherwise it is pointless to argue about it. http://microformats.org/wiki/mailing-list#Use_real_world_examples And add it to http://microformats.org/wiki/hcard-issues Hence why microformats focus on real world examples on the web that are also *common*. And people *commonly* publish what are clearly and unambiguously (to humans, but not, without the additional mark-up of a microformat, to machines) home or work telephone numbers, without saying as much on the page. Same thing. needs real world example URL. please document on hcard-issues. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/7/08 5:19 PM, Guillaume Lebleu [EMAIL PROTECTED] wrote: to avoid the meta discussion and go back to Kat's specific problem (she wants to specify a phone as work but without the content containing work or any of its abbreviations), maybe something that would work would be to have an implied 'work' tel type when a fn and an org that are both present and a tel type is not present. I believe we could have an implied 'voice' type in this case as well. Sorry in advance if this idea has already been proposed/discussed. Hi Guillaume, voice in fact is already default value of the type sub-property for tel: http://microformats.org/wiki/hcard#adr_tel_email_types Perhaps you could document your brainstorm for implied 'work' tel type when fn and org are present (and the same? is this for organization hCards only?) on the hCard brainstorming page? http://microformats.org/wiki/hcard-brainstorming Citations of URLs of real world examples that demonstrate this use case would help in consideration. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: url and tel
On 1/6/08 9:37 PM, Paul Wilkins [EMAIL PROTECTED] wrote: On Jan 7, 2008 9:54 AM, Andy Mabbett [EMAIL PROTECTED] wrote: Nor should you replace 31 Dec 2007 with 2008-01-01, as is currently done in: abbr class=dtend title=2008-01-0131 Dec 2007/abbr I can't understand how anyone ever thought that acceptable. We're going to have to work through this then, because events that end at a certain time do not get pushed forward by a day. With dtend,if the time isn't known it's presumed to be midnight at the very start of the day. abbr class=dtend title=2008-01-01T00:00:0031 Dec 2007/abbr Right. Note that this is an already documented hCalendar issue: http://microformats.org/wiki/hcalendar-issues#dtend-date-plus1 Please add any follow-up there rather than in email. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] web programmers vs web designers and microformats
On 1/4/08 3:59 AM, David Janes [EMAIL PROTECTED] wrote: Let me quote here something from a friend (who's had a fair bit of success in small startups over the last few years) in response to my question why he wasn't using XFN + hCard for a project: | The biggest problem with microformats is that nobody gets it. | If I tell a programmer its an XML vocabulary, then he says gotch ya. | If I tell a programmer its microformats, then he says micro what? | There's a lot of interest in microformats because its cool, but few are | implementing them because of the learning curve. While we're not actively avoiding targeting programmers, they're (deliberately) not the primary audience for microformats. Web designers and web authors (including folks who edit the PHP and other templates out there that generate most of the page views on the web) outnumber web programmers by 1000x (or more), and they definitely get the use of semantic HTML (aka POSH)[1] and semantic class names. From them the response is more like: | I just use *these* class names instead of making up my own? That's easy. span class='vcard'span class='fn'David Janes/span/span is a pretty damned hard sell. The fact that hCard is *the* #1 format for publishing information about a person on the Web would seem to refute that. http://microformats.org/wiki/hcard-supporting-user-profiles One thing to keep in mind, there are (still) going to be lots of specific communities of folks that are not convinced by microformats (hardcore XML programmers are the most notable example I've encountered). That's ok. There is no need to convince *everyone* of microformats. Just as in the development of microformats, 80/20 applies to the sell as well. If someone is not convinced to use microformats, tell them no problem, and check back with them in 6 months to a year when microformats support on the Web and in applications has increased that much more. Eventually they'll get it. Aside from that, perhaps some of the web programmers who are on this list could write up how they were convinced on a wiki page like? http://microformats.org/wiki/for-web-programmers Tantek [1] http://microformats.org/wiki/POSH - this is a good litmus test for web programmers you speak with. If they haven't heard of semantic HTML, start them with a POSH education before bothering with teaching them microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
natural language hCards (was Re: [uf-discuss] web programmers vs web designers and microformats)
On 1/4/08 2:23 PM, David Janes [EMAIL PROTECTED] wrote: On Jan 4, 2008 2:45 PM, Tantek Çelik [EMAIL PROTECTED] wrote: The fact that hCard is *the* #1 format for publishing information about a person on the Web would seem to refute that. http://microformats.org/wiki/hcard-supporting-user-profiles Profiles is not the problem that Andy Ryan C. are talking about: they're talking about using hCard in casual references to people and places on the web. For example, on your blog, you've coded: | My friend a href=http://juliettemelton.com/;Julie/a and I thought this up when discussing | end of year rituals, and threw it together quickly and roughly in a matter of days (like the first BarCamp). | We invited a bunch of people (also coarsely brainstormed, certainly not comprehensive), a few of | whom were actually available to attend, and shared an incredible two days of reflection | (what emdid/em you do) and projection (what are you emgoing to/em do). Ah ok, this is what Jeremy Keith refers to as natural language hCards, wherein you simply markup inline references to people accordingly. He's got some really good examples of this, including mixes of nicknames etc. Brief section on this in hcard-authoring: http://microformats.org/wiki/hcard-authoring#Natural_language_hCard which references Jeremy's post on the subject: http://adactio.com/journal/1122/ I've just added a bit more to that section based on Jeremy's real world markup of Malarkey in his blog post to illustrate further. They're suggesting that you're much more likely to provide semantic information about Julie if you were willing to do the simple operating of adding (for example) 'class='vcard' to the A tag. That being said, good point, I should markup Julie as such in that blog post. Updated. What really gets people to use more markup in blog posts though, is the little creator/style buttons that often line up just above the top of a blog post editing textarea for creating links, lists etc. What we need is a person button (perhaps with an icon similar to the icon next to your username when you are logged into the microformats wiki) which simply inserts the markup for you, or better yet, lets you pick someone from your address book, and then inserts an inline hCard with their name, URL (and perhaps even XFN relationship to them) for you. That little bit of extra markup pales in comparison to the typical prose of a blog post. Perhaps we could ask various blogging tool makers to add such a feature. Similarly for events. I've noted this in the plugins / web-apps sections of hCard advocacy: http://microformats.org/wiki/hcard-advocacy#WYSIWYG_buttons Regards, etc... Thanks again as always David, you've raised and clarified good points. Tantek On 1/4/08 2:50 PM, Kevin Marks [EMAIL PROTECTED] wrote: In semantic HTML, the right way to do this would be to use cite around the name: citeJulie/cite so doing cite class=hcard a href=http://juliettemelton.com/; class=url uid fn rel=friendJulie/a/cite which has an implied nickname, and adds the XFN for my friend I'm not really quoting or citing Julie for saying something, so I'm not sure that cite is appropriate in this case. However, the markup I ended up using is close to what you suggested. Here it is with white-space added for readability: span class=vcard abbr class=fn title=Juliette Melton a class=url nickname rel=friend href=http://juliettemelton.com/; Julie/a /abbr /span I've added this example to the hcard-authoring natural language hCard section as well. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Montreal CodeFest 2008: Microformats
On 1/4/08 2:50 PM, David Janes [EMAIL PROTECTED] wrote: Jebus ... 14 hours notice. Would have loved to been there :-( Regards, etc... On 1/4/08, Evan Prodromou [EMAIL PROTECTED] wrote: I don't know if it's come up before, but CodeFest 2008 in Montreal is concentrating on µF's. Our previous CodeFest in 2007 concentrated on OpenID, and we added support for the standard to 6 Open Source projects. So, pretty likely we'll see some good code come out of this weekend. If you're interested in participating on-line or in person, see: http://wiki.facil.qc.ca/CodeFest2008 -Evan Evan this sounds very promising! Is there some way to remotely participate? Via IRC etc.? I see that it's been added to the events page: http://microformats.org/wiki/events Could you create a separate page for it on the wiki and add in details, perhaps even a list of which open source projects people are working on, so that some of us could offer suggestions remotely? I encourage you to ask the CodeFest 2008 participants to make liberal use of the #microformat IRC channel as well. Thanks! Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
On 12/15/07 4:39 PM, Martin McEvoy [EMAIL PROTECTED] wrote: OK Paul, lets try and put that in the real world, My client has a music store with around 500 pages of content and around 10 to 20 items of hAudio on each page, My client want's their pages to validate and be accessible.. no problem i say, semantic markup... and SEO, semantic markup... we can sprinkle some hAudio magic in there I say .. great my client says because they trust me im good at my job, I do the job, my boss looks at my work and says what are all these empty anchors about... pause right there... any SEO worth his salt will know anchor text links that go nowhere, will A, reduce the quality of out going links from your site so reducing PR (Page Rank) and B, more than likley get you banned from google because it will think you are trying to spam it you know what my boss will sayyou are sacked. so no thank you Paul although your idea is workable, its still a hack, and in the real world never likely to be used. Martin, thanks for this reality-check. You've provided some good reasons for why empty hyperlinks are an anti-pattern, and given that that's two this week, and that we have a few existing anti-patterns documented on the wiki, I've drafted this wiki page accordingly. http://microformats.org/wiki/anti-patterns In particular I've documented part of what you noted above in this section: http://microformats.org/wiki/anti-patterns#empty_hyperlinks I encourage you to expand upon it with any additional details / references. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Precise Expansion Patterns (was: Re: [uf-discuss] Hcalendar in bbc.co.uk/programmes)
On 12/14/07 3:55 PM, Martin McEvoy [EMAIL PROTECTED] wrote: On Fri, 2007-12-14 at 23:18 +, Martin McEvoy wrote: I do NOT however believe that machine data should be displayed in a people area such as @title, I think machine data can be stored elsewhere in a document such as in the head in a list of link's or meta's This is an anti-pattern. Disconnecting data (or meta-data, whatever you prefer to call it) from its context inevitably leads to corruption, and loss of fidelity. Meta keywords rotted for example. One person writes the template with the head and link and meta, and another puts the content in the page, etc. etc. No but seriously, with my web designer hat on if you are concerned about accessibility issues or abuse of the abbr pattern this is something worth thinking about. abbr title=PT3M23Sspan title=three minutes twenty three seconds 3m 23s /span/abbr title distraction. I don't think there is any abuse of the abbr design pattern in the above example and it keeps machine data out of peoples faces. Thanks Martin, this is an excellent example. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] using microschema
On 11/24/07 9:25 PM, Tatsuya Noyori [EMAIL PROTECTED] wrote: I would like to suggest microschema to improve interoperability of microformats. Hi Tatsuya, There are two general areas of problems that your suggestion. The first is, what is the real world interoperability problem that you are trying to solve? Do you have test cases that have been demonstrated to fail in specific implementations? Do you have analysis that demonstrates that such problems stem from a lack of an explicit typed schema? Lacking that, it is not logical to conclude that a schema (micro or otherwise) would help improve interoperability. The second problem is that in practice, explicit schemas do not represent all (often not even most) of the semantics of a specific format. For example, the HTML4 DTDs contain a mere fraction of the constraints and semantics expressed by the HTML4 specification. A validator that only checks the rules expressed in the HTML DTD will fail to check numerous assertions and requirements made in the specification itself. This is the schema incompleteness problem. In short, having a set of rules from a framework (such as those expressed by a schema like a DTD) is not only in practice insufficient, but serves to give a false sense of completeness of description. Thus with microformats we eschew trying to solve the general schema problem (others are trying much harder for much longer on that problem - e.g. XML Schema etc., and failing in practice - i.e. usage on the Web) for simple dictionaries instead. There has been some value demonstrated in some scenarios (e.g. reading microformats into an RDF store, either directly or thru a GRDDL transform) to at least disambiguate the use of vocabulary, and back the terms used with URLs. Thus we have XMDP (XHTML Meta Data Profiles) which is sufficient to define terms and provide a URL for each. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Complete n00b: adr microformat
On 11/19/07 4:14 PM, Brian Suda [EMAIL PROTECTED] wrote: 2007/11/19, Toby A Inkster [EMAIL PROTECTED]: div class=localitySurrey Hills, Sydney/div div span class=regionabbr title=New South WalesNSW/abbr/span span class=postal-code2010/span /div Hopefully the title on the abbr should not trigger the abbr-design- pattern, because NSW is more appropriate for printing on address labels. How do existing implementations handle the above example? --- implementations SHOULD not trigger the abbr-design-pattern because the class=region is on a span, which doesn't carry the additional semantics. Since there is no additional classes on the abbr element, the REGION should be just NSW I think it is safe to say MUST instead of SHOULD in the above paragraph, given that in following hCard parsing, no other interpretation is possible. http://microformats.org/wiki/hcard-parsing Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OBJECT Pattern Page Updated
On 11/6/07 12:22 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: Ben Ward [EMAIL PROTECTED] This is a big edit, but the page was not in a good state and this needed doing. I ask that people take a little time to read the new version, compare it to the old and raise any remaining issues. The hyperlink example shows that a href=#j class=includeBen Ward/a is replaced by span class=fn n id=j span class=given-nameJames/span span class=family-nameLevine/span /span The text that follows states that the hyperlink can require repeating a small piece of information (such as a person's name in an hCard) If the names in the examples were consistent, they would help to reinforce the stated requirement. The names (ben ward and james levine) should be consistant with each other. Indeed. In addition, the whole reason the include-pattern was developed was to NOT to have to repeat such text in the content of the document. Thus I've changed it to use the 'title' attribute instead, which is simultaneously a less invasive / content-affecting requirement on the author, and still available to assistive technologies (same citation in the section, Clark, 2007). http://microformats.org/wiki/include-pattern#accessibility It may also be a good idea to use more meaningful id names in both the hyperlink and obect examples, so that those who implement this pattern are encouraged to use good id naming schemes too. We don't want to encourage bad behaviour. That's reasonable. Updated. Further down there is OBJECT elements referencing fragments of the same document erroneously cause the browser to make additional HTTP requests. For scenarios where HTTP requests are a sensitive performance measure, this makes the hyperlink pattern inappropriate. If the object element cause additional HTTP requests, shouldn't this make the object pattern inappropriate, and not the hyperlink one? Good catch. Please have another read: http://microformats.org/wiki/include-pattern Thanks! Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OBJECT Pattern Page Updated
On 11/6/07 8:34 AM, Ben Ward [EMAIL PROTECTED] wrote: Hi everyone, Following on somewhat from the messages last month regarding the OBJECT pattern I've updated the Wiki page (http://microformats.org/ wiki/include-pattern) quite substantially. Ben, this is a *tremendous* update, thanks very much and well done. I have fully reviewed it and the previous version and I only found one section in particular that I believe needed some additional non-trivial edits. The hyperlink pattern now acknowledges the assistive technology implications and actively encourages inclusion of inner text in hyperlinks. I've added RFC2119 language (should) to that section, and noted that a citation is required for the assistive technology implication assertion. Far too often (in this forum and other forums) I have seen accessibility requirements / practices spoken authoritatively as dogma, without any citations to clear text explaining why, and due to what *specific* assistive technologies (perhaps specific versions as well) are affected, and as a result, the conversation around accessibility often descends into religious debate. When that happens, there is no room left for intelligent scientific discourse, and the level of discussion drops down to You have to do XYZ because I said so because I'm an accessibility expert and you're not. This is not helpful for progress and understanding, neither among web authors, nor frankly for accessibility itself. We need to call out such accessibility dogmatism whenever it occurs, and ask for scientific backing. Because only with scientific backing can we actually explore nuances with new situations, new user agents etc. and re-evaluate the accessibility rules of thumb that are often asserted as absolute, and evolve them accordingly. I recommend that *everyone* concerned with accessibility even a little (which hopefully means everyone) read this presentation by Joe Clarke which debunks a lot of common accessibility dogma: When accessibility is not your problem http://joeclark.org/appearances/atmedia2007/ I've noted a quote from part of that presentation regarding link text in the include-pattern page. http://microformats.org/wiki/include-pattern#Accessibility_concerns Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Complete n00b: adr microformat
On 11/6/07 7:57 PM, Francois Lafortune [EMAIL PROTECTED] wrote: A1. I would propose locality for the suburb maybe and if you must specify city AND suburb in different tags then I dont see anything wrong with that, they are both class names and from the xhtml standpoint they can be re-used. Or, you could stick the suburb in with the city (which I think goes better with some microformat parsers) separated by a coma unless you really need to have them in separate tags. I don't see anything wrong with that but I'm no guru. locality is used for city in common vCard implementations. you could put suburb in extended-address if you wanted to. A2.1. it is OK to have colons in spans but the colons would be included by some parsers as being part of the content. putting your colon outside the span wont add an extra space if node right. Correct. A2.2 AKA: Personal Vendetta I hate the way microformats are going through that whole adolescence phase and bringing back major disease like acute divitus and severe spanitis, My personal take on this would be something the likes of: address dl class=adr dt class=workStreet Address/dt dd class=street-address111 some street/dd dd class=extended-addresssuite 101/dd dtCity/dt dd class=localityCooltown/dd dd class=localitySuburbia/dd dtPostal Code/dt dd class=postal-codeH0H 0H0/dd dtRegion/dt dd class=regionOG/dd dtCountry/dt dd class=country-nameCanada/dd /dl dl class=tel dt class=type title=faxFax:/dt dd class=value+1-111-111-/dd dt class=type title=workWork:/dt dd class=value+2-222-222-/dd /dl /address we have markup language people... dont be affraid to use it! be afraid to use it incorrectly however, as the above use of address does. address does not mean address. this is a common mistake. http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards http://microformats.org/wiki/hcard-faq#Why_is_adr_property_necessary homework assignment for incorrectly suggesting use of the address element and emotionally so (hate the way microformats are going through that whole adolescence): Please (re)read the HTML 4.01 specification from beginning to end. http://w3.org/TR/html401 Then follow-up with reading POSH resources: http://microformats.org/wiki/posh Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Complete n00b: adr microformat
On 11/6/07 7:20 PM, Katrina [EMAIL PROTECTED] wrote: Gday, I would like to ask a few questions about the adr microformat and I really hope I am in the correct place. I am so sorry if I am not. I am trying to learn about microformats, and so far so good. Q1. I have an address I would like to mark up as an adr. Now the problem that I think I am having with this address is that it has a country, a state, a city, a suburb, a postcode, and a street address. As far as I know, adr only has region and locality. Possible markup example: div class=adrdiv class=workStreet Address/div div class=street-address/div div class=locality/div -- suburb? div class=postal-code/div div class=region/div -- state? div class=country-name/div /div If locality equates to suburb, It doesn't. locality equates to city. this has been true in common vCard implementations for many years. Q2. As far as I am aware, good typography insists that colons are flush against the word they succeed, and are also styled in the same manner. Is it OK to have colons in the spans? There is no need to put the colons in the spans in order to have them flush against the word they succeed. inline markup must not add extra space or interrupt the typography (e.g. cause a line/word break) unless styled to do so. For example: div class=telspan class=type title=faxFax:/span span class=value+60 3 7880 7978/span/div Instead: div class=telspan class=typeFax/span: span class=value+60 3 7880 7978/span/div Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [admin] Notice of community ban
On 10/18/07 8:03 PM, Steve Robillard [EMAIL PROTECTED] wrote: I don't believe anyone else has been banned, but rather that Andy has been banned multiple times, and it appears to have had little effect. It did actually help for a while last time, as Andy's emails and behavior were certainly civil for a while (he was last banned for a week back in July). Unfortunately though, for whatever reason, his behavior lapsed, which then dragged (drug?) the tone down in the lists, to the point where many people were made to feel unmotivated to participate. As for the transparency of the process do the admins vote before taking this action or is it a single admin's decision (let me be clear I am not saying that the action was taken without just cause or unwarranted). The admins could do a better job of documenting some of this, and to be clear, every time there has been a banning, it has been by consensus decision (no objections) from the admins, of which there are quite a few at this point. There have been a few times that the admins have considered / discussed banning someone but whenever there has even been one objection from any admin, no banning has taken place. Thus it is a very serious decision, and certainly not taken lightly. As for unusual, I guess that is part of what prompted my post, it is no longer unusual, but rather a matter of how long before it repeats. It's a good question. A lot of us try to be optimists about human nature and thus keep hoping for the best. This despite the fact that in this case, this individual has for example been banned from at least one other wiki-centric community, e.g. Wikipedia, for a year (for a second time). I will personally commit to (as I think the other admins will, though I am not speaking for them) improving the documentation of who the admins are, and the minimal processes that the admins follow, because, one of our objectives is to keep the process/admin/overhead down to a minimum both for the admins and the community as a whole. Thanks, Tantek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Rodgers Sent: Thursday, October 18, 2007 9:56 PM To: Microformats Discuss Subject: Re: [uf-discuss] [admin] Notice of community ban Has this happened to anyone else? I don't recall in all the time I have been lurking that anyone else has been banned (perhaps others are less persistant?). How could transparency be achieved? Vote on a ban? It is hard to say how to manage things so everyone is happy. I am happy with how things are managed and who is doing it. Thanks Drew for the post on what has happened. Lets hope these decisions remain unusual ones. Jesse On 10/18/07, Steve Robillard [EMAIL PROTECTED] wrote: It seems we have been here before, and it seems we are making no progress on the 2 issues presented: Andy's behavior and making the banning process more transparent. Is it time to examine the process to address both of these issues - especially in light of the fact that banning Andy does not seem to be working? Just my 2cents Thanks, Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew McLellan Sent: Thursday, October 18, 2007 4:24 PM To: Microformats Discuss Subject: [uf-discuss] [admin] Notice of community ban This is an email regarding Andy Mabbett's recent and persistent negative conduct within the microformats community. Namely: * Unpleasant and overly-aggressive communication with members of the community on both [mf-new] and in private email * Engaging in wiki edit wars * Excessive argumentativeness for the sake of debate These are traits he has been warned about before, and for which has been previously banned. They are in clear contradiction with the be nice guideline: http://microformats.org/wiki/mailing-lists#Be_nice This behaviour continues to be harmful to the community, and therefore, the admins have concluded there is no other option than to issue Andy with a further 30 day ban from community participation. With regret, Andy Mabbett, is banned from community participation for a period of 30 days from today. Sincerely, Drew McLellan, on behalf of the microformats admins ___ 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org
Re: [uf-discuss] Optimus microformats parser
On 9/20/07 4:47 AM, Andy Mabbett [EMAIL PROTECTED] wrote: Ack, of course not - I have it configured as a pseudo-newsgroup in my combined news mail client. Sorry. Nonetheless, the character is not rendering properly, here, at least - though it does render properly at: http://microformats.org/discuss/mail/microformats-discuss/2007-September/0107 10.html Consider checking the UTF-8 compliance of your combined news mail client, as Dmitry Baranovskiy's message headers properly stated: Content-Type: text/plain; charset=UTF-8 And then simply included the UTF-8 mu (or micro symbol) character inline in the message. Thanks, Tantek P.S. Well done Dmitry Baranovskiy! I'm still playing with Optimus a bunch more before following up with specific feedback. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard: title or role
On Sep 20, 2007 12:22 PM, Dimitri Glazkov [EMAIL PROTECTED] wrote: On 9/20/07, Andy Mabbett [EMAIL PROTECTED] wrote: In hCard, should a job title like Head of Marketing be classed as title or role, or both? What's the difference? Off the top of my head: role = executive title = Head of Marketing No? (resorting, please bottom-post! thanks! :) On 9/20/07 12:55 PM, Kevin Marks [EMAIL PROTECTED] wrote: from vcard: 3.5.1 TITLE Type Definition Type name: TITLE Type purpose: To specify the job title, functional position or function of the object the vCard represents. Type example: TITLE:Director\, Research and Development 3.5.2 ROLE Type Definition Type name: ROLE Type purpose: To specify information concerning the role, occupation, or business category of the object the vCard represents. Type special notes: This type is based on the X.520 Business Category explanatory attribute. This property is included as an organizational type to avoid confusion with the semantics of the TITLE type and incorrect usage of that type when the semantics of this type is intended. Type example: ROLE:Programmer So Head of Marketing is a Title, Marketing is a Role, I'd say. Agreed with one minor change. Marketing is an area. From the example in RFC2426, it appears that the role is a noun that describes the person with respect to that area. E.g. TITLE:Head of Marketing ROLE:Marketer or perhaps TITLE:Head of Marketing ROLE:Manager Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats presentation
On 9/12/07 7:07 AM, Thom Shannon [EMAIL PROTECTED] wrote: I recently gave a presentation at GeekUp Liverpool, I've posted the talk up [1] and added a link on the wiki. It was a fairly simple talk and I tried to focus on why you'd want to publish microformats, how they're going to be used in the future with the next generation of browsers and smarter web applications etc. It may be of use to some people. [1] http://www.ts0.com/2007/09/microformats-whats-point.asp Excellent presentation Thom! Well done. Feel free to also create an events page as indicated here: http://microformats.org/wiki/events to document attendees, photographs etc. In addition, please consider licensing the contents under a Creative Commons license (perhaps by Attribution 3.0) so that other members of the community can easily re-use your good work. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] barcamp brighton
On 9/9/07 7:11 AM, Thom Shannon [EMAIL PROTECTED] wrote: Do any of the uf guys at brighton right now have some uf stickers? can i please beg for some? :) Thom, find me, I may have a few remaining (as well as a few folded pocket cheat sheets). Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and title attribute parsing
Re-routing parsing issue to microformats-dev. On 9/7/07 7:36 PM, Mike Kaply [EMAIL PROTECTED] wrote: See: http://kidachi.kazuhi.to/blog/archives/002343.html I was disappointed with his comment - he means that Operator won't catch title attribute of span element in hCalendar as far as the community doesn't get one concrete conclusion. (BTW Tails and Tails Export can find my hCalendar as I expected.) Is this true? Tails and Tails export find title on non abbr elements? This is a longstanding bug in Tails. The title attribute has *never* semantically meant anything on anything but the abbr element in microformats parsing (e.g. see hCard parsing)[1]. Last time I checked, Tails incorrectly looks at the title attribute on all elements instead of just on abbr - I think at this point it is due to lack of maintenance than anything else. An innocent mistake that was just never corrected. If this is the case, it would mean an old version of X2V does this since that's what they use X2V has properly supported abbr title (and not title attribute in general) for quite some time. Tails must use its own implementation or perhaps it uses a *really* old version of X2V? Tantek [1] http://microformats.org/wiki/hcard-parsing ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Third option?: Need for plain-language intros for each microformat
On 9/7/07 8:25 AM, Ernest Prabhakar [EMAIL PROTECTED] wrote: Hi all, On Sep 7, 2007, at 7:00 AM, Eric A. Meyer wrote: or 2) leave the specs where they are and create new -intro pages. I've seen [...] no one object to #2. Then you haven't been paying full attention. For those of us who indeed haven't been paying full attention to this particular thread (guilty), a citation or three regarding objections to #2 would be greatly helpful. 3. Let me propose what may or may not be a third option: a) Leave the specs where are. b) Add a good solid introductory paragraph at the top of the spec. c) Link from there to an in-depth -intro page This may just be a variant of #2, but I think it addresses Andy's objections. If not, perhaps he would be kind enough to summarize them again. Ernie, I believe this is essentially what has been proposed for #2, per: http://microformats.org/discuss/mail/microformats-discuss/2007-August/01057 5.html * brief plain-language intro at the top (say for example, something that a non-technical person like a member of the general media/press could read and understand) same as your b) AFAIK. * followed by links to more plain-language resources similar to your c), which I also agree with. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats UI in Firefox 3
On 9/2/07 4:07 AM, Jamie Knight [EMAIL PROTECTED] wrote: hiya, I am not so sure that introducing an extra div / element is the way forward as it is requiring even more of the authors. I tend to agree with Jamie's assessment. I was under the impression that part of the idea behind microformats was that the tools were to do the donkey work of the process. Certainly one way to put it. ;) Yes one of the goals of microformats is to be a bit more publisher-centric in design rather than parser-centric. That doesn't mean that we try to make things completely no work at all for publishers, because clearly we ask a little of them, but it does mean that we ask less of them than most other standards efforts, which ask publishers to learn new languages etc. See the principles for more on this: http://microformats.org/wiki/principles I know this isn't wonderfully helpful, as i am not suggesting an alternative (thats for far greater minds than my own) to me the thought of adding a div to my page is alot more of an ask than a few semantic class names. I feel that other may feel the same way. It is not only quite a lot to ask publishers to add another div to their pages, but actually undesirable from an overall user experience standpoint. *Publishers* of data can't know beforehand all the ways *users* of that data will want to use it. Hence we ask publishers to mark up data semantically, which enables *general* re-use. Rather than asking them to mark up data semantically and with verbs for *specific* re-uses. just a few thoughts, ^licks^ Jamie Lion Thanks Jamie Lion. In addition, I found this thread *very* difficult to follow, as at some points it seemed like there were implicit proposals for a taxonomy of possible user actions (a really bad idea to try to solve such a huge problem at this point) or perhaps even a microformat itself for possible user actions for which I've seen no research done etc. As far as discussing microformats user interface in browsers in general, please take a look at: http://microformats.org/wiki/user-interface#Browser_Integration Please consider adding concrete user interface ideas/screenshots, proposals, and even challenges/issues there so that we may have a better record of the latest version of a proposal along with critical analysis etc. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCite status and next steps
On 8/31/07 1:17 PM, Jason Calabrese [EMAIL PROTECTED] wrote: I'm going to be using hCite in 1 of the products that I work on. Since it will be only used interally for now I'm not going to wait for it to become a recommended specification. I do plan to stay current though. It looks like there are 3 primary issues now. 1) Identifiers 2) Types/Formats 3) Nesting We're going use the uid class with nested type/id elements for identifiers. For my use the type/format and citation nesting aren't needed so I'm going to ignore them for now. Are there any other open issues? What is being done to resolve the issues? Let me know how I can help. Hi Jason, Since the citation microformat is still very much underdevelopment, I'm redirecting your query to the microformats-new mailing list, where formats in progress are discussed. Please sign up on microformats-new. http://microformats.org/wiki/mailing-lists#microformats-new Thanks much! Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Need for plain-language intros for each microformat
Replying to several messages in this thread in one reply: On 8/29/07 9:05 AM, Andy Mabbett [EMAIL PROTECTED] wrote: On Wed, August 29, 2007 16:40, Brian Suda wrote: On 8/29/07, Manu Sporny [EMAIL PROTECTED] wrote: [Manu's post hasn't arrived here, yet; I think my ISP has server trouble.] Andy Mabbett wrote: I think it's time we moved the specs to *-spec or *-specification, and used the root page for each microformat, such as the above, for a plain-language introduction, taking care to avoid jargon as much as possible. --- moving the specs would break links from all over the web and in dead tree books that say you can view the hCard spec at ... Cool URIs don't change. It is probably a better idea create new pages about each format and point people to those instead and link the specs to them. The URI would still work, and a link to the spec could be included above the fold. Syntactically the URI would still work, however, semantically it would have been broken, that is, it is bad to not only change URIs so that they 404 and just plain don't work, but it is also bad to change the *meaning* of that URI. As Brian pointed out, the URLs for hCard, hCalendar, hReview etc. all *mean* the *specification*. Changing that is bad. However... On 8/29/07 9:05 AM, Andy Mabbett [EMAIL PROTECTED] wrote: On Wed, August 29, 2007 16:40, Brian Suda wrote: ... I've pointed somebody to a uF specification page to give them an overview ... The simple answer would be to create another overview page and point interested people there. When you want to learn more about HTML, do you look at the w3c spec or do you look else where? http://www.w3.org/html/ is not a spec http://www.w3.org/TR/html401/, while it is a spec, has plain-language intro and begins with links to more plain-language resources. Compared to our root pages, those are exemplary models of usability. Rather, let's state this as a positive goal: Microformats spec pages should be at least as usable as W3C spec pages. In my experience with web designers and developers, the common feedback I have heard (and seen, on blog posts etc.) is that W3C specs are opaque and very difficult to read. That being said, I'm not necessarily disputing Andy's comparative evaluation. I think we can and should set the bar higher - being as usable as W3C specs is not good enough. As such, some of the specifics listed would be a good start: * brief plain-language intro at the top (say for example, something that a non-technical person like a member of the general media/press could read and understand) * followed by links to more plain-language resources Adding to my to-do list now... I realised after my initial post that I created http://microformats.org/wiki/hcalendar-intro some time ago. I think this is a good pattern to replicate, as it is something that can be immediately started, and it will make it easier to keep informative (non-normative) introductory material from bloating up too much the normative specification (the parts with all the RFC2119 goodness). Microformats are all about bottom-up, we don´t need a central silo for all things microformats. It is OK to have discussions, definitions about formats NOT on our wiki. The microformats wiki is where people come to learn about microformats. We should serve them. You're both right. We should both be enabling, encouraging discussions about microformats anywhere on the Web, as well as providing a useful resource ourselves for people to come learn about microformats. On 8/29/07 8:51 AM, Ciaran McNulty [EMAIL PROTECTED] wrote: On 8/29/07, Brian Suda [EMAIL PROTECTED] wrote: --- moving the specs would break links from all over the web and in dead tree books that say you can view the hCard spec at ... Cool URIs don't change. It is probably a better idea create new pages about each format and point people to those instead and link the specs to them. I agree that moving the specs could be confusing, I'd propose either: ... or, preferably b) Adding a *-intro page and a small island at the top of the existing spec pages that says 'This is a specification, for a quick introduction to * see *-intro' or something a bit more user-friendly. I think the idea of *-intro pages is a very good one. On 8/29/07 10:40 AM, Angus McIntyre [EMAIL PROTECTED] wrote: As well as a syntactic example, examples of use would be useful. For instance, I still have no idea when I might want to use XOXO. Some simple examples right upfront would probably do a lot to help users figure out whether a particular microformat is for them or not. Angus, these are excellent specific suggestions for improvement as well, that I agree with. I've added them to my to do list for a few specifications, I expect to learn from the process of adding that material how to generalize it to microformats specifications in general. If others have specific suggestions for
Re: [uf-discuss] Re: Microformats in Google Maps
On 8/2/07 8:34 AM, Toby A Inkster [EMAIL PROTECTED] wrote: Andy Mabbett wrote: http://microformats.org/wiki/hcard-brainstorming#implied_adr_subproperties which strikes me as unworkable, being overly complex and not suitable for internationalisation (not just in non-English speaking countries, but outside the USA) I'm with Andy on this one. To be clear, I wanted to document it as a brainstorm to be critiqued, with severe doubts myself, from the second paragraph in that section, which I wrote: This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way. In general, the documentation of such strawman thoughts and criticisms of such is just good science. Not every brainstorm should be taken as a proposal that is intended to be adopted. div xml:lang=fr Please add examples that show problems with it to the section with the brainstorm rather than the emails list. And no need to try to be comprehensive about showing problems with it, one or two examples will do for now, given the doubts expressed from the origin. I recently had to write some code to transfer almost 500,000 addresses from a loosely formatted list to one which had separate fields for house name, address, town, county, country and postcode. Because these were almost entirely UK addresses, and I had a big database of all UK postal town and corresponding postcodes, I was able to get about 95% accuracy -- but that involved hundreds of lines of code. To cover a useful number of countries would require tens of thousands of lines of code. This is a useful datapoint. Note that it doesn't prove difficulty (in that someone else may be able to write simpler/more efficient code, or not), but any such implementation experience is useful to capture. Requiring the use of heuristics to parse address data raises the barrier to entry for implementing hCard astronomically. Perhaps not astronomically, but I agree with your sentiment. ;) Andy's suggestion of defaulting to extended-address is better, though given the semantics of extended-address, which appears to be for flat numbers, I'd prefer to default to street-address. I'd prefer neither. I think there would be too much semantic dilution (or artificial semantic precision) by doing so (putting things that don't have a certain semantic into a field that implies that semantic). How about: Where adr has content not enclosed in any explicit sub- properties, parsers MAY attempt to heuristically determine the address parts and, if appropriate, MAY ask the user to manually separate the address. Failing that, parsers MUST assume this content to be the street-address. I'm not even sure about permitting the heuristic part. I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty): http://microformats.org/wiki/hcard-brainstorming#adr_without_children_FAQ Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Discussion of public domain declaration template usage
On 7/25/07 2:29 AM, Andy Mabbett [EMAIL PROTECTED] wrote:
I made this edit in the light of Manu's well- intentioned, but misguided,
request that changes be made to the template:
http://microformats.org/discuss/mail/microformats-discuss/2007-July/010238.ht
ml
To be clear, such changes are NOT going to be made to the template.
Here's why:
The text of the template was taken from Wikipedia, deliberately, as-is in
order to be clearly consistent with the Public Domain Declaration there.
That's the safest thing to do for a number of reasons (consistency, not
introducing unintended changes etc.).
We are essentially saying we believe that Wikipedia has done the right thing
with respect to their public domain declaration and are joining that in that
respect.
Anybody wanting to change that should take it up upstream as it were, take
the debate to the Wikipedia's public domain declaration. We don't want the
debate about public domain wording here. Any further issue with that can be
taken up with Rohit per the instructions on his user page.
I would STRONGLY advise anyone thinking of placing their contributions
into the public domain to subst the template (or use their own wording),
This is NOT the method of inclusion of the template used by Wikipedia, and
thus it is NOT recommended on that basis.
This is also a REALLY BAD IDEA due to the fact that if any subtle changes of
wording of public domain declaration occur across people's user pages, then
it becomes much harder to determine if they are consistent or not to place
pages which people have jointly edited into the public domain.
It is best for the community for everyone to use *one* public domain
declaration, period. And if that declaration needs to be corrected due to a
typo etc., it is better that *everyone* get those fixes and stay consistent.
Frankly Andy, due to your use of the {{subst}} method, you have now added
additional time cost to determining if any page *you* edit in particular is
consistently in the public domain or not with respect to all other public
domain contributors.
I'd like you to please reconsider and use the direct template inclusion form
on your user page for the good of community.
rather than calling template which may be changed in future, to a form of
wording with which they do not agree;
See the above. Such changes, of *any form* from what the text said in
Wikipedia is undesirable for any reason, whether everyone agrees or not.
In addition, you can bet that if anyone *does* change it, there will be
sufficient people watching to raise red flags and point that out.
The *only* type of wording changes I can see occurring are if Wikipedia
changes *their* public domain declaration wording, it is likely that we may
and will follow suit, to stay in sync and consistent as it were.
Tantek's justification for the edit was that he was reverting to the form
of wording used by Wikipedia. As has become clear, Wikipedia and this
'wiki' are run on very different lines, with the former having far more
openness and accountability. Wikipedia uses subst on other templates;
and anyone who chooses may subst thir PD template.
Wikipedia uses the direct template inclusion on the Public Domain
Declaration {{ }} and thus we will recommend that as well. We're not using
other templates from Wikipedia at this point so what they do on other
templates is irrelevant.
Tantek
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Discussion of public domain declaration template usage
On 7/25/07 4:21 PM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes On 7/25/07 2:29 AM, Andy Mabbett [EMAIL PROTECTED] wrote: I made this edit in the light of Manu's well- intentioned, but misguided, request that changes be made to the template: http://microformats.org/discuss/mail/microformats-discuss/2007-July/01 0238.ht ml To be clear, such changes are NOT going to be made to the template. I'm not prepared to take your word for that; not least because you might not be here at some point in the intermediate future. Then you may take it as a word from the admins who will carry on even if I am not here. Here's why: The text of the template was taken from Wikipedia, deliberately, as-is in order to be clearly consistent with the Public Domain Declaration there. That's the safest thing to do for a number of reasons (consistency, not introducing unintended changes etc.). Copying a template from Wikipedia is no guarantee that it won't change. The wording on the Wikipedia template could be - and has been - changed at any point. Given history, it is unlikely, yet the possibility of Wikipedia changing it was addressed further in my message. Not only that, but if you read Wikipedia's copyright statements, I think you'll find that you have no right to put a page containing a template, lifted wholesale from Wikipedia, into the public domain; you'd be breaching the copyright belong to the original author(s) if you didn't attach a GDFL licence. Except in the case of the Public Domain Declaration itself which does both refer to and cover itself and therefore put itself in the public domain. Rohit and I looked quite closely at this. We are essentially saying we believe that Wikipedia has done the right thing with respect to their public domain declaration and are joining that in that respect. Legally, that's meaningless. AFAIK, you are not a lawyer, therefore, with all due respect, your use of the Legally, ... qualifier does not add any semantics. As far as whether the public domain declaration is meaningless, I, Rohit, and everyone else who has included the public domain template clearly do not think it is meaningless. If you do think that's meaningless, that's your opinion. We'll just have to choose to disagree. Anybody wanting to change that should take it up upstream as it were, take the debate to the Wikipedia's public domain declaration. That would have no bearing on rights over material on this 'wiki'. As admins we're saying we have no need to reinvent the public domain declaration language on Wikipedia that *numerous* Wikipedia users/authors have already signed up for, and that such debates should occur there, not here. As you seem to prefer the discussion forums on Wikipedia, I would think you would find this preferable as well. We don't want the debate about public domain wording here. Any further issue with that can be taken up with Rohit per the instructions on his user page. That experiment with open governance was short-lived; it's just five days since Rohit opened discussion on the matter, on this list. Rohit opened discussion with the usage yes. Nitpicking the wording, which came from Wikipedia, is inappropriate for this forum. If you want to discuss Wikipedia's public domain declaration wording, do so in the proper forums there. This is also a REALLY BAD IDEA due to the fact that if any subtle changes of wording of public domain declaration occur across people's user pages, then it becomes much harder to determine if they are consistent or not to place pages which people have jointly edited into the public domain. So changes might be made to the template, after all? See above about typos, etc. and updates from Wikipedia. Just this morning I made a non-wording markup-only change just to remove a few invalid attributes but which did not change the wording. That sort of thing. It is best for the community for everyone to use *one* public domain declaration, period. That assertion is completely without foundation or justification. Actually your assertion that That assertion is completely without foundation or justification. is itself without foundation or justification, as you don't and can't know from what foundation or justification I could be speaking. If you don't know the foundation or justification for someone's statement, don't assume it doesn't exist, rather, ask for it, e.g. What is the foundation or justification for that assertion? in this particular case, I am basing the assertion on attending a Creative Commons meetup on November 3rd, 2005 and listening to Lawrence Lessig [1] (who is a lawyer) discuss the problems of open content on the web using the many different and often only slightly incompatible licenses, including but not limited to GFDL, Creative Commons etc., and that he himself is working on a license interoperability
[uf-discuss] Mediawiki accesskey shortcut usage instructions
On 7/25/07 2:29 AM, Andy Mabbett [EMAIL PROTECTED] wrote: In the same edit, Tantek restored instructions, such as use CTRL S to save, which I'd removed, which are OS and browser specific, on the basis that they help some people. Actually, ctrl-s/alt-s help *the vast majority of people* who use Windows or Mac for that matter, as the modern browsers on those systems all support the respective ACCESSKEYs, as do most browsers on linux systems as well. 90+% easily in terms of total marketshare etc. If you'd like to suggest improvements for how to word these efficiency enhancing shortcut tips, it would be great to hear them, but summarily removing them when clearly they were intended to help was a bit rude. All the usability guidance I've ever read on the subject, cautions against giving such advice, which is akin to saying to get coffee, turn left, then second right, then the kitchen is first left. This will help everyone in the office where I work, but probably won't apply to many other people reading this. The analogy is false as the coffee directions apply to perhaps 1% of the people on this list, but the Mediawiki accesskey shortcuts apply to 99% of the people on this list. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Voluntary Public Domain declarations now enabled on the wiki
On 7/20/07 4:35 PM, Andy Mabbett [EMAIL PROTECTED] wrote: I applaud him for doing so; but, at the time of writing, copyright in both hCalendar and hCard is still claimed, in part, by Technorati, Inc., by virtue of their being one of the three listed authors, Technorati is not listed as an author, but merely my (and a few others') affiliation at the time of authoring the spec(s). However, I can very much see how that could be misinterpreted so I have edited the affiliation text of the specifications of which I am an author/editor/contributor to be in the style used by W3C specifications: Author (Affiliation[s]), ... (Interestingly, Tantek says he's released the Geo and Adr specs into the public domain, but Technorati are credited as either co-author or his employer (the designation is not clear) - have they relinquished their rights?) I have clarified the affiliation per the above stylistic edit, and yes, all the work I have done on microformats when employed by Technorati was done very much in and for the community and I have taken the extra step of releasing my work into the public domain to be even more explicit. I continue to encourage all microformats community members to release their contributions to the Public Domain. Doing so without waiting for any other particular conditions demonstrates a strong commitment to contributing to the public good and sets a good example for others as well. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: hCard history and extensions (was Re: [uf-discuss] Date of Death in hCard)
On 6/30/07 7:11 AM, Jeremy Keith [EMAIL PROTECTED] wrote: I don't believe that hCard needs to be extended to accommodate a date of death field. I think that we already have a microformat to deal with this use case; it just doesn't happen to be hCard. The dtend field in hCalendar seems like the perfect fit for this. Microformats are intended to be embeddable within one another: an hCalendar within an hCard (or visa-versa, depending on how you look at it) allows for all the desired information to be marked up: p class=hcard vevent Minor correction (s/hcard/vcard in the class attribute) p class=vcard vevent span class=fn summaryCharles Darwin/span was born on abbr title=1809-02-12 class=dtstart bdayFebruary 12, 1809/abbr and died on abbr title=1882-04-19 class=dtendApril 19,1882/ abbr. /p Otherwise, this is an excellent idea Jeremy. Perhaps you could add it to http://microformats.org/wiki/hcard-brainstorming as a suggested use of hCard with hCalendar? Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] abbr and accessibility - a work around.
On 6/25/07 12:39 PM, James Craig [EMAIL PROTECTED] wrote: Apologies for not responding sooner. I've been working on a test case script for all of the possibilities listed on the assistive- technology-abbr-results pages, but side work always falls behind work work. snip http://microformats.org/wiki/assistive-technology-abbr-results James, Thanks for the update, and I can certainly understand/appreciate the challenge of balancing various sources of work. Your work on documenting the different possibilities, your scientific observations/hypotheses about the possibilities, and a test case script for them is very much appreciated (I'm sure by many, whether explicitly acknowledged or not). Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Hidden metadata no microformats
On 7/3/07 11:23 AM, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Patrick H. Lauke [EMAIL PROTECTED] writes Paul Wilkins wrote: You could try the FAQ. http://microformats.org/wiki/faq Where it says: Q. Given that Google now looks at hidden content as potential spam, will invisible microformats be considered spam? A. It is advisable not to hide information in your site, regardless of whether it is microformated or not. Microformats provide a mechanism for marking up visible content. Any mechanism for embedding invisible or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data. FUD. Not FUD but based on examples publicly discussed and commented on by search engine company representatives (Google, Yahoo, Technorati, etc.). It would be reasonable (and certainly better for us) to have citations since these generalizations are based on events documented on the broader web. Will Google attempt to parse the complex interplay of CSS and (X)HTML for each page to determine if content is somehow hidden? No. Currently, the way it works is that somebody reports a page to Google, and their team investigates it (cfr the case of BMW in Germany a while ago). There's human judgement involved, and not an automated hidden = spam algorithm. Are you an employee for Google speaking authoritatively on Google's behalf? I've updated the FAQ to reflect that. I've reverted this assertion from the FAQ since AFAIK Patrick is not a Google employee nor speaking for Google. I've still seen no citation for any *prohibition* of hidden data in microformats... There is no prohibition per se, it is simply suboptimal behavior. Perhaps analogous to how there is no prohibition of putting aluminum cans in the garbage which is suboptimal compared to recycling them. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: hCard history and extensions (was Re: [uf-discuss] Date of Death in hCard)
On 6/28/07 11:27 AM, Benjamin West [EMAIL PROTECTED] wrote: On 6/28/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes For some of these I see quite a bit of utility (e.g. gender is often used in social network searches - an actual application in common use), whereas others seem to be merely driven by sense of semantic publishing completeness (e.g. date of death) and not by existing applications. On the contrary; you have been presented with evidence *and* use cases for date-of-death more than once; not least in the first post in this thread. Andy, I'm not sure which evidence you are referring to. All I noticed was a a sum of google search results. We've previously discussed using search engine hits as evidence. Can you reiterate which URIs were surveyed along with an analysis of the markup used? It would go a long way towards providing evidence for this feature. How are people currently publishing dates of death? Who is doing it? Are there common authorship patterns? And note I said: an actual *application* in common use, e.g. people adding contacts from the web into their address book is such an application. As opposed to semantic publishing completeness, that is, I grant that some people are publishing some date of death information, but other than marking it up, what do you do with the information? What *applications* are there? E.g. for gender the widely used application is people search. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats for normal people, like my mum
On 6/28/07 5:28 PM, Alex Faaborg [EMAIL PROTECTED] wrote: Probably none of us here is the right ones to decide something like this... Fair enough, several other people have made this point as well. We are always open to feedback about microformat detection in Firefox 3, so if anyone has any comments, please feel free to post them to this list or email me directly. FF3 perhaps shouldn't call it something The menu which contacts, addresses and locations are listed under will need some form of name. Also, journalists will probably want a feature name in press briefings and when they make product comparison tables, etc. We aren't likely to call it SuperHyperMetaMagic, but we are going to need to call it something. Perhaps that is right way to capture this issue then, as a *user-interface* issue. Alex, go ahead and add a description and labeling of this issue to: http://microformats.org/wiki/user-interface along with the evidence/needs you cited (e.g. number/source of journalists that have requested a name for microformats features in order to talk about them). Everybody can choose their own name and it will - by the power of web 2.0 which microformat is very much a part of - become a good word in the end. Mozilla's user experience team is going to continue brainstorming the best way to expose microformat detection to end users, along with the rest of the mozilla community. I'll post updates to this list from time to time, and it will be interesting to see what interfaces and names other people come up with as well. I'd definitely suggest adding thoughts and ideas to the 'user-interface' page on the microformats wiki so that these issues (and brainstorms) raised here on the list aren't lost to the pile of email. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] wysiwyg editors and microformats
On 6/25/07 10:39 AM, Christian Heilmann [EMAIL PROTECTED] wrote: conversions of events to ics files with the technorati converter gave me files Outlook didn't understand. I know this is Outlook's fault, but to sell the idea of Microformats to people in charge of IT companies right now, we have to find a way to make this work in the current setups of those people which are Outlook and Windows. Which version of Outlook and Windows were you using? AFAIK this is now fixed in Outlook 2007, consider upgrading if your preferred calendar application is Outlook. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] include-pattern parsing
redirecting parsing assertion to microformats-dev per mailing-list guidelines. On 6/20/07 8:17 PM, Michael MD [EMAIL PROTECTED] wrote: Is the object tag to be used instead for the include pattern? given no, not given, not without a URL to documentation. the complexity it adds to non-browser-based parsers what specific complexities have you encountered in your development of a non-browser-based parser and have you documented them on the wiki (say on the include-pattern-issues page)? Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Work-of-art/Tim Gambell
On 6/8/07 2:21 AM, Toby A Inkster [EMAIL PROTECTED] wrote: Ted Drake wrote: Could the Dublin core be converted into a microformat. In short no, however, it could be converted to POSH. Dublin Core is one of many citation-like previous formats, and thus best serves as source research for the citation microformat[1]. Tantek [1] http://microformats.org/wiki/citation ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hListing and hReview
On 6/4/07 7:59 AM, Taylor Cowan [EMAIL PROTECTED] wrote: hReview and the proposed hListing are very similar, sharing structure and properties. They both use item and it seems logical that they should work exactly the same in that area...but they are just different enough to cause parsing issues. From the hReview page, it states that fn must be a child http://microformats.org/wiki/hreview Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g. class=item vcard). However, when using item info subproperties (fn, url, photo), they MUST be nested inside the item element. Yes, that was one of the clarifications that went into hReview 0.3. However, on the hListing proposal, item and fn are used in an example like this: span class=item fnParking space/span If we can make them agree it sure is easier to write pasers, in this case you merely take an exising hReview parser and add/change a few property names. The hListing proposal forked from an earlier version of hReview and that's why it allows that. The hListing proposal needs to be updated with the same rule(s) as hReview. Since there are already public examples of that on edgeio I wonder if the restriction in hReview should be relaxed regarding (fn, url, photo) as child nodes. We should actually go the other direction, update hListing with the help of the Edgeio folks. It is important that microformats iterate and evolve properly, without being burdened by inertia of early implementations. We had a similar discussion a while ago about xFolk. It also seems that a second identifier within the same @class attribute is really a child anyway. span class=item fnParking space/span == itemfnParking space/fn/item This assumes that class name order is relevant which is false. The class attribute is a space separated *set* of class names. Thus span class=item fnParking space/span == span class=fn itemParking space/span Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uF Tools for Internet Explorer?
On 5/9/07 10:53 AM, John Beales [EMAIL PROTECTED] wrote: What we need to investigate is something like operator that works in page for microformats. I have thought about this, but it's not high on my list. Mike I'm going to try to see about making a favelet for IE that uses Brian Suda's XSL, or Technorati's implementation or something, (when I actually get going I'll E-mail those of you responsible asking permission - don't worry). It's a bit of a stop-gap but hopefully it can start letting IE users at least see the value of an hCard. See favelets here for the Technorati Contacts and Events Feeds services: http://technorati.com/contacts/ http://technorati.com/events/ Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uF Tools for Internet Explorer?
On 5/9/07 11:17 AM, Brian Suda [EMAIL PROTECTED] wrote: On 5/9/07, John Beales [EMAIL PROTECTED] wrote: What we need to investigate is something like operator that works in page for microformats. I have thought about this, but it's not high on my list. Mike I'm going to try to see about making a favelet for IE that uses Brian Suda's XSL, or Technorati's implementation or something, (when I actually get going I'll E-mail those of you responsible asking permission - don't worry). It's a bit of a stop-gap but hopefully it can start letting IE users at least see the value of an hCard. --- the microformats wiki has a list of existing bookmarklets[1], if you create any new ones, please be sure to add them to the list. -brian [1] - http://microformats.org/wiki/bookmarklets Thanks Brian. Aforementioned bookmarklet/favelets added to that page. In addition I created a page for internet-explorer-extensions to parallel the one for firefox and linked to it from the implementations page to hopefully make it easier to discover/find. http://microformats.org/wiki/internet-explorer-extensions http://microformats.org/wiki/implementations Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Live Clipboard (was Re: [uf-discuss] uF Tools for Internet Explorer?)
On 5/8/07 6:08 PM, Michael MD [EMAIL PROTECTED] wrote: I think this was the page mentioned a while back http://spaces.live.com/editorial/rayozzie/demo/liveclip/liveclipsample/clipboa rdexample.html Added to implementations page. http://microformats.org/wiki/implementations#Live_Clipboard Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uF Tools for Internet Explorer?
On 5/8/07 2:39 PM, John Beales [EMAIL PROTECTED] wrote: We have Operator Tails for Firefox, but the majority of users out there are still using IE, and if they could use something, even a bookmarklet, to export hCards from web pages Those certainly exist. it would make evangelizing a whole lot easier. Understandably! Maybe I just missed them in the wiki. If so a link would be great. Thanks! They weren't very easy to find. I've added this page which now links to them: http://microformats.org/wiki/internet-explorer-extensions If/when you come across additional tools for Internet Explorer, please add them to that page. Thanks! Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/3/07 7:10 PM, Patrick H. Lauke [EMAIL PROTECTED] wrote: But to bring it back to the original argument, the routine extraction does not necessarily have to equate to data visible in, say, a tooltip. The routine extraction may well be mediated via some machine interpretation. May is insufficient in this case, as such machine mediated interpretation is a theoretical (or certainly not available to many people) and thus insufficient. The tooltip is the only practical semi-visible method available currently. This could change in the future, but XHTML 2.0 might also be adopted in the future. Such theoreticals are not useful to solving our problems now. If you have a deployed practical semi-visibility alternative to the tooltip, I'm very much interested to hear it. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
(apologies for top posting but this is in response to Al's entire message, not to any specific point in particular) Al, VERY well written. That's perhaps the clearest explanation I have seen of why it is important to have visible information, even somewhat visible rather than invisible. May I quote what you wrote in part or in full on microformats wiki? Thanks, Tantek On 5/3/07 6:18 PM, Al Gilman [EMAIL PROTECTED] wrote: At 12:24 AM +0100 4 05 2007, Patrick H. Lauke wrote: Tantek Çelik wrote: 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. For the sake of argument, though: assuming that those human eyes/ears use a microformat-consuming tool/extension/etc, this can still happen. If I have a page with, say, contact details marked as a hcard, and human users export it to Outlook, they'll be able to see (and ensure) whether or not the generated vcard details in the add to address book dialog match the page's visible details or not. After all, isn't that what microformats are there for? Being consumed by machines that can make something useful with them? Almost. They are there so that people and machines can share info. If the machineable info is not routinely passing through the consciousness of the communicating principals (that is, people), then it must be expected that the machine and the person will frequently have different values for the same datum. Not a good thing. The old saw is, out of sight, out of mind. In this case it is use it or lose it (it's validity) for data. Microformats are to eliminate the mumbo-jumbo quality of the data the machines deal with; rather to give them the same many-eyeballs 'bazaar' checking support as the virally-maintained meanings of plain English (Chinese, Arabic or what have you...). That's a little overstated, but the devil is in the details. If in some community of communication, the data is routinely extracted into view often enough so that bad data tend to get weeded out, then the storage or transmission form doesn't have to be directly comprehensible by people. But one of the virtues of markup languages is just how much of the info is directly under the quality control of people; expressed in as little-encoded form as can be gotten away with. Al ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote: Copied the entire email below for context. Tantek, if you post this to the wiki, please note it as opinion and give a link to the thread. Marking this as fact would misrepresent the views of the Microformats group as a whole. I disagree - Al's explanation provides good reasons *in general* why visible data works (and why invisible does not work), and so far, all that has been thrown up against his statements are a bunch of theoreticals, mostly centered around the tools will solve the problem fallacy that so many have fallen for historically (i.e. look at so many metadata like efforts before microformats that have failed miserably depending on such fallacies). Al's statements are well reasoned conclusions, not opinions. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
