Re: [uf-discuss] MediaWiki plugin
On Jan 7, 2009, at 7:09 PM, Bob Jonkman wrote: On 5 Jan 2009, at 12:05, Martin McEvoy wrote: It looks to me like the wiki is being spammed by a bot or bots [...] I stopped it by changing the form names to to something gibberish, nothing standard wpTextbox1 would be come ZifG5ut nonsense basically, a good Idea is to change the form names regularly, then you can encode the submit, preview and show pages buttons in Java script and insert them using a function This seems like a contrary thing to do for an organization that advocates POSHness. Shouldn't form names be semantically meaningful, like any other markup? And Javascrippling a form excludes anyone who intentionally disables scripting for security, never mind those folks who need to browse with a text-based browser for accessibility issues (I know of no text-based Javascript browsers). I'm not saying that form obfuscation isn't effective to combat spam, but that's not our dogfood. I think we'd all be more than willing to hear suggestions for spam fighting methods that are equally effective. Or, at least, an offer to police the recent updates page. :) -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=nsfw
On May 6, 2008, at 1:24 PM, Gordon Oheim wrote: Hi all, I was just reading a blog about bad use of Photoshop that linked to not-safe-for-work sites every now and then. Made me wonder if we could use a microformat that indicates non-suitable for work links and the likes? I could imagine a FF plugin that recognizes page elements tagged as nsfw and changes their display to none or something like that when you are at work. Could also use nsfc (for children). Google could crawl this and protect my unborn kids. What do you think? Useful? As Charles also mentioned, there's been discussion of this on the mailing list before. The short story is this: everyone's work is different (I've actually had work were I *had* to look at at stuff which would be NSFW for most), so it wouldn't be very useful to try an encode a single standard. If you still want to capture the semantic of I think this is NSFW you could use xFolk or hReview and tag the link as 'nsfw'. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Github.com add rel=me
On Mar 24, 2008, at 2:09 PM, Tom Morris wrote: Github is a service for users of the Git distributed version control system, and provides hosting for open source and commercial software projects. I've been using it for a while. A while back they allowed people to add their profile details, which appeared as an hCard. They now use rel=me! I sent this ticket in to their issue tracker: http://logicalawesome.lighthouseapp.com/projects/8570/tickets/31-add-rel-me-to-links-from-profile-to-homepage-blog Here's my profile: http://github.com/tommorris Unfortunately, they also put nofollow on those links, which makes them ignored[1]. -ryan 1. http://microformats.org/wiki/xfn-clarifications#me_nofollow_interaction ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A (big) problem with XFN: identity of source andtarget not findable
On Mar 20, 2008, at 8:27 AM, Costello, Roger L. wrote: Thanks Ryan! Representative hCard -- nice! I'm glad you like it. On a meta point, I'd like to suggest that before people post to this list saying this is broken that you first do some research on the wiki and elsewhere. There's a good chance that if the problem you've run into is worth tackling, someone else has already at least started tackling it. Also, when you fail to find any work on a point, please still don't email the list saying this is broken, try I think this is broken, but that may just be because I couldn't find it on the wiki. :) A PLEA TO INFLUENCE THE SOCIAL NETWORKS Are there people on this list who can influence: - Flickr, - Last.fm, - Ma.gnolia, - MetaFilter, and - Twitter to use a representative hCard to identify the person that the web page is talking about? Once again, we already have space on the wiki for working on this: http://microformats.org/wiki/advocacy Please document any sites which should be targets of advocacy there. And feel free to do any advocacy of previously documented targets. -ryan PS - On another meta note, if you find that you're writing multi-page, informative emails to this list, you should probably be putting the information on the wiki instead. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Has the cowpath for these XFN values faded away: friend, co-worker, muse, etc?
On Mar 18, 2008, at 9:18 AM, Costello, Roger L. wrote: Chris Messina wrote[1]: ... you'll find that, by and large, the majority of XFN links on the web are using either rel-contact or rel-me. I have been looking at various social networks for the last week, and Chris' statement is consistent with what I have seen - most web pages just use contact or me. This puzzles me. Microformats are about paving existing cowpaths. Historical note: XFN was created several years before the word microformats was coined, the microformats process was created, etc. I presume the authors of XFN saw a clear cowpath for not only contact and me, but for all the other XFN values, such as friend, co-worker, muse, etc. Has the cowpath for these later values disappeared, and thus are no longer needed? There's not a lot of value in taking other relationship types out of XFN. It'd make the spec smaller, but would lead to people who encounter those edges cases asking for re-inclusion. So, in a way, whether values besides 'contact' and 'me' are valuable, it doesn't matter that much at this point, there are more important things to work on. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] A (big) problem with XFN: identity of source and target not findable
This is not a big problem, its mostly solved with [1] -ryan 1. http://microformats.org/wiki/representative-hcard On Mar 18, 2008, at 5:31 AM, Costello, Roger L. wrote: Hi Folks, Flickr uses XFN. Here is a sample Flickr page that uses XFN: http://www.flickr.com/people/tantek/ At the browser menu select View Page Source. Then search for rel= Here's an example usage of XFN within that Flickr page: a href=/photos/[EMAIL PROTECTED]/ rel=contact img src=http://farm3.static.flickr.com/2146/buddyicons/[EMAIL PROTECTED] 12 [EMAIL PROTECTED] alt=Jolene_A width=48 height=48 /br / Jolene_A /a Notice the use of XFN: rel=contact Metafilter also uses XFN. Here is a sample page that uses XFN: http://www.metafilter.com/usercontacts/292 Here's an example usage of XFN within that page: a href=/user/10411 rel=colleague target=_self40 Watt/a Notice the use of XFN: rel=colleague Now, suppose that I wanted to create a spider application which crawls all social networks that use XFN. Most likely, I would want the spider to collect: 1. Who is the source? That is, who is the individual using XFN to state a relationship? 2. What is the relationship? This is, of course, obtained easily from the value of the rel attribute on the link. 3. Who is the target? That is, who is the other individual in the relationship? Examine the above snippets of code. Does 1. and 3. pop out at you? That is, do you know who are the individuals that are the source and target of the relationship? That information can be found on the Flickr and Metafilter sites, but each site does it *differently*. So, the problem with XFN can be stated as this: While XFN does a great job of providing a set of relationship values (friend, contact, co-worker, etc), it provides no means for the automated discovery of the individuals that are the source and target of the relationship. Without information about the source and target individuals, the relationship information is not very useful. You might argue: Well, the XFN *should* be embedded within an hCard, then you can discover who the source individual is. And the target page should contain an hCard, then you can discover who the target individual is. And I agree that is Best Practice. Unfortunately, this is not mandated and consequently many people don't do it. For example, Flickr and Metafilter don't do it. Nor do any of the other social networks do it. Conversely, consider FOAF. Advogato is a social network that uses FOAF. Here an example FOAF on that network: http://www.advogato.org/person/connolly/foaf.rdf At the browser menu select View Page Source to see the actual FOAF document. Notice that the individual who is the source of the relationship is clearly listed at the top of the document: foaf:nameDan Connolly/foaf:name And the individual who is the target of the relationship is clearly identified: foaf:knows foaf:Person rdf:about=http://www.advogato.org/person/jtauber/foaf.rdf#me; foaf:nickjtauber/foaf:nick rdfs:seeAlso rdf:resource=http://www.advogato.org/person/jtauber/foaf.rdf/ /foaf:Person /foaf:knows The downside of FOAF is the only built-in relationship is knows, e.g. Dan Connolly knows James Tauber. That is, FOAF doesn't possess the richness of expression in terms of relationships. (I know, there are extensions of FOAF to express more than knows, but as far as I can tell, no social network is using those extensions) The upside of FOAF is that all three pieces of information are available to a spider application: 1. The source individual (e.g. Dan Connolly) 2. The relationship (knows) 3. The target individual (e.g. James Tauber) I don't see any solution to the problem with XFN. As far as I can see, social networks using XFN cannot be processed by spiders. Only social networks that use FOAF can be processed by spiders. Bummer. Hopefully, I am missing something. I really like the simplicity of XFN and its rich set of relationships. /Roger ___ 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] Social Networks that use XFN and Social Networks that use FOAF
On Mar 18, 2008, at 11:38 AM, Costello, Roger L. wrote: Hi Folks, Below is a list of social networks that use XFN (special thanks to David Janes). Following that is a list of social networks that use FOAF. Why email these, why not just put them on the wiki? -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] IE8 + hAtom = hSlice
On Mar 5, 2008, at 7:28 AM, Dimitri Glazkov wrote: It looks like Microsoft is adopting microformats, if not in a rather awkward way: http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm#webslices On one hand, I am thrilled to see hAtom implemented in such an elegant manner, on the other hand, I am puzzled about the 'hslice' nonsense. But hey, I'll take this over some proprietary XML markup any day. Yeah, I find it strange that they say that they're using hAtom, but then go and mint a new term. Why not just use hAtom and be done with it? Would it be too much to ask for this feature to work with *already deployed content on the web*? /rant Come on, microsoft, you're so close to getting it right here! -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Reflections on community time, rules, guidelines, and banning Andy
The admins have recently spent some time reflecting on the past 18 months or so the microformats community, our progress on various efforts, participation, and how time has been spent. One of the larger conclusions is that a significant (majority) of admins' time has been spent dealing with community meta matters, identifying and diagnosing misbehaviors or other community damaging patterns within the community, careful drafting of additional how to play wiki editing [1] and mailing lists [2] guidelines. Unfortunately this has meant that significantly less time has been spent over the past 18 months or more on doing actual microformats work, resolving issues, iterating and improving existing specs and documentation, and helping guide the development of new microformats as well as improve the process for the development thereof based on all the feedback. An analysis of the how to play and mailing list rules and guidelines has revealed that the vast majority of these rules have been created in response to the community misbehaviors of one individual: Andy Mabbett. This is an acknowledgment that the continued process of identifying a misbehavior, creating a rule to avoid it, and then warning subsequently, has been insufficient, or rather has merely resulted in admins spending most of their time on microformats on administrivia rather than actual microformats, and that this lack of active productive participation is due primarily to the actions of one individual. As a result we have decided to ban Andy Mabbett from community participation (wiki, lists, blog comments, IRC) for a period of 18 months. This is not Andy's first ban and this action is not taken lightly. The how-to-play and mailing-lists pages have been updated with annotations documenting which of the rules have been created directly due to one or more of Andy's actions (wiki edits and/or emails). As time permits, the admins will both hyperlink each of those annotations to the specific email in the archives or edit in the wiki history that caused it, as well as annotate any remaining rules with their causes as well. We believe this will help provide better transparency and accountability. In addition, in the coming days and weeks we will be taking the time to document more how-to-play and mailing-lists rules and guidelines (most of which are directly due to Andy's actions as well) in the hopes of further minimizing community misbehaviors, and making it clearer to newcomers what kinds of behavior are or are not acceptable. Ryan King (on behalf of the microformats admins[3]) [1] http://microformats.org/wiki/how-to-play [2] http://microformats.org/wiki/mailing-lists [3] http://microformats.org/wiki/admins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: To-do items?
On Feb 24, 2008, at 9:46 AM, Toby A Inkster wrote: Mark Ng wrote: So far as I understand it (though I'm very far from an authority on this subject, and haven't actually seen an implementation of this) - hCalendar is a one-to-one mapping of iCalendar (RFC 2445). iCalendar allows for VTODO entries. http://microformats.org/wiki/hcalendar-examples#4.6.2_To- do_Component in the wiki does actually mention this usage, but has (ironically) a TODO where the implementation is. The hcalendar spec itself seems to suggest that vcalendar and vevent are the only possible root class names and doesn't make any reference to VTODO, VFREEBUSY, etc. They are not included on the cheatsheet either. However in the introduction it does claim to be a 1:1 representation of iCalendar in HTML. I suppose that this apparent contradiction can be resolved if we assume that VTODO and other iCalendar components may be used, but must not be employed as root class names. (a vevent class can be used outside a vcalendar class, and this implies that the page itself is a VCALENDAR.) It can be resolved by saying that no one has gotten around to specifying how the other iCalendar objects would work in hCalendar. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=contact
On Feb 18, 2008, at 5:43 AM, Toby A Inkster wrote: The XFN 1.1 meaning of rel=contact conflicts with the proposed semantics of rel=contact in HTML 5. XFN 1.1 http://gmpg.org/xfn/11#contact: | contact: Someone you know how to get in touch with. Often symmetric. HTML 5 http://www.whatwg.org/specs/web-apps/current-work/#contact: | contact: Gives a link to contact information for the current document. I've given this feedback to the HTML-WG already. Ian Hickson, one of the editors, has said he'll address it in HTML5. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fragment identifiers in hCard links
On Feb 11, 2008, at 6:33 AM, Rickards, Julian (NDM) wrote: -Original Message- Please make sure your page is at least well-formed: http://validator.w3.org/check?uri=http%3A//www.mndm.gov.on.ca/ mndm/mines/lands/pro/contact_e.asp%23devosst Ryan: I fixed the page and now it is valid. However, that doesn't change the result. Having done a bit of testing, it appears that in the URI link where I use a fragment identifier (which would normally use the # as in index.html#fragment), I have tried both # and %23 (where that comes from, I don't know) '%23' is the url-encoded version of '#'. but neither work properly. When I use #, only the first contact is downloaded no matter which contact link I click. However, when I use %23 in the URI, the only response I get is No vCards found which is obviously not true because the hCard code meets the specs. Maybe Brian Suda has changed the code on his server because a test page of mine that used to work doesn't work any longer. Does anyone have any ideas as to how to put multiple hCards on one page and have individual links download individual vCards to the client's address book? You're doing it correctly, it appears to be a problem with X2V. Please document this issue on http://microformats.org/wiki/xfn-issues . -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fragment identifiers in hCard links
On Feb 7, 2008, at 1:19 PM, Rickards, Julian (NDM) wrote: Hi: I have multiple hCards on one page (http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp blocked::http://www.mndm.gov.on.ca/mndm/mines/lands/pro/ contact_e.asp ). I created a unique ID for each div class=vcard so that the link beside each one (http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=http : //www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst blocked::http://suda.co.uk/projects/microformats/hcard/get-contact.php? uri=http://www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp#devosst ) allows the visitor to add specific vcards to their address book. I tried this before (several months ago) and it seemed to work but I can't get this process to work again. I tried using a # in the URI but the link only downloads the first hCard on the page. When I checked my code, I noticed that I had used %23 in place of # so I presume that this was in response to a suggestion but when I use %23, Suda's server response with No vCards found. Please make sure your page is at least well-formed: http://validator.w3.org/check?uri=http%3A//www.mndm.gov.on.ca/mndm/mines/lands/pro/contact_e.asp%23devosst -ryan ___ 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 Feb 5, 2008, at 8:23 AM, Toby A Inkster wrote: Tantek =?ISO-8859-1?B?xw==?=elik wrote: 1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't. A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered. It does claim that it's a set of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world set to be interpreted in that way -- far more likely they were referring to the layman's definition of the word. Specs aren't generally written in layman's terms. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar duration problem.
On Sep 24, 2007, at 4:14 PM, Andy Mabbett wrote: The first hCalendar on: http://www.westmidlandbirdclub.com/diary/2008/03.htm for The Outdoors Show, has a duration of P3D, which is detected by operator, but does not appear in the exported event, in any of the several parsers I've tried. Which parsers, in particular? Is it my mark-up at fault, or is there some other problem? It's likely that parsers don't support duration. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Storing Microformats
On Sep 18, 2007, at 7:21 AM, Christopher St John wrote: b) Be super corporate about it and come up with a relational schema that matched the _semantics_ (not the markup) of each microformat, then publish the schema to the group for others to use. Kinda brittle in the face of standards changes, but it should be clear how to proceed and people would probably find the research useful. This is essentially what I've done for the microformats search on http://kitchen.technorati.com (which is woefully neglected). Changes to stable microformats tend to coming in terms of markup, not model, so my database models have been pretty stable. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Storing Microformats
On Sep 17, 2007, at 12:44 PM, Paul Kinlan wrote: I have created a C#/.Net Stream-based Microformat parser (http://www.codeplex.com/microformat) and I am trying to create some reference applications to show it off. I am in the process of creating an Operator like plugin for IE (It currently parses and displays the microformats that have been found on a page). One of the other ideas that I am toying with is a Microformat spider, that crawls the web looking for microformats, storing them and then allowing them to be searched. My question is: How are people storing the data present in microformats so that they can be searched and maintained and consumed in applications etc? In short, I use mysql tables, one for each microformat and one for each elemental type that can be many-to-many (images, photos, tags, etc) which then have polymorphic many-to-many relationships with the tables for the formats themselves. We also build search indexes, currently using Ferret [http:// ferret.davebalmain.com/trac/], but hopefully soon switching our standard Lucene infrastructure at Technorati. We cache all objects in memcache with indefinite timeouts (all cache clearing is done proactively). This includes all related items in one cache entry. When it comes down to it, it's all a matter of scale. When we were indexing 10^5 and 10^6 items, we would actually parse some of the markup on the fly when someone did a search. Sounds crazy but it worked alright for awhile (I blame Tantek). Now we parse it all out into a relatively normalized model. We're at 10^8 or so items now. If we hit another order of magnitude we'll have to rethink things and probably take some stuff (like BLOBs) out of the relational database and put them somewhere else. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag on delicious
On Sep 22, 2007, at 9:06 AM, Taylor Cowan wrote: Does anybody know why delicious isn't microformatted? I can only guess, either yahoo is starving the site, or they are against the concept. It sticks out like a sore thumb in my weblife...on occasion when demonstrating Operator to friends I go to delicious assuming they have some, alwasy forgetting because it seems like a perfect site to host MF's. Last time I talked to Joshua Schachter (founder of del.icio.us) about this, we was opposed to microformats in general. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [Fwd: Search engine results, where do they go?]
On Sep 22, 2007, at 5:14 PM, Øyvind Østlund wrote: Hello, Bare with me, I am new to this. But I have been reading quite a bit lately about Microformats, and I want to try to use them for my search results on a web page I have. On the Wiki there is a link (today goes nowhere http://randomchaos.com/microformats/base/) about using hAtom for search results. Is that really the way to go? Looking at xFolk it looks much closer to what a search result really is. After a search you are presented with something similar to a bookmark with all the information already filled out. Can anyone tell me if I am completely in the wild here? My opinion, in short, would be use both. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCards and Companies
On Sep 21, 2007, at 1:31 PM, Duncan Cragg wrote: Hello uF list! I've got some questions on hCards used to represent a company... disclaimer mood=friendly Nothing here should be constituted as a request for a new uF; I've read the hCard and vCard specs; I know about paving the cowpath, 80:20 and POSH; I've Googled as much as I can.. =0) /disclaimer Right: - I would like a person hCard to have a pointer to the hCard of the company they work for in the 'org' bit: can I include or link to the company hCard? I can imagine separate company hCards for the main company and the specific 'organisation-unit' within it. First, I assume the use case is: given an hcard for the person, how can I find more contact info for that company? Unfortunately, there isn't any structure for company urls in vcard/ hcard. Creative solutions within the bounds of vcard compatibility would be nice. :) - I would like my company hCards, conversely, to contain a list of [role-hCard] links - e.g. CEO: [link to CEO's hCard]; CIO: [link to CIO's hCard] - I know 'agent' exists, but this is different, and not in the hCard spec itself. I assume the use case here would be a staff page like http:// technorati.com/about/staff.html ? A concrete example like that would be easier to talk about. - I would like to have a full, official registered company name in a company hCard that differs from the public, friendly name - the spec says 'n' should be blank for company/organisation hCards, so where can the official name go? (the spec forces 'org' to be the same as the friendly name, of course) should I use fn/nickname resp? or abbr? abbr might be appropriate here. My own hcards say Technorati, when the company name is actually something like Technorati, Incorporated or something like that. Of course if you use abbr, only the full name would be extracted, then. Nickname might be an appropriate semantic. A quick look at Address Book.app shows that at least that application supports nicknames for companies. - I would like to drop in a field for the ticker code: NASDAQ:MSFT, etc; also the SEDOL and ISIN codes. Similarly a field for sector, UK Companies House classification, etc. Shall I just go POSH, here? Use rel-tag? Any suggestions or precedents? I'd say go POSH, but make sure that you put it inside the hcard's note so that you have useful fallback behavior. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] marking up table rows - carrying id through rows to create multiple unique .ics exports
On Sep 12, 2007, at 9:43 PM, Matt Warnock wrote: Hello - I have a question of how to create an id that carries through several cell elements and then links to the X2V service to create the .ics file. I am hoping to have multiple events on one page and want to give the user one option to download the class they want to attend and not all the classes. Do you create and id in the first element, then reference this in the headers= attribute? I can't seem to get it going and populating the ics file correctly. I had it going but it would add the location, now it's just shooting blanks. I don't mean to run to this discussion board every time I can't figure stuff out, but it's been a long day on this. My cards keep coming up empty. I am giving the first element (cell) of the row time th an id, then referencing that id in the following td classes through the headers attribute. I'm using the clues in the Allsopp book of naming the axis attribute the same as the th column id, and then stating the scope of row but it's getting me confused. I'm using a fragmented URL with an escaped %23 for the button to ping the conversion service at Suda's X2V address. If someone could take a peek at the code I would be really appreciate it. Its the first table, the today's upcoming classes table http://exhale.daisyinteractive.com/locations/santa-monica/ put class='vevent' and id='foo' on the tr and it should work fine. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats Would Benefit From a Pseudo-Namespace
On Sep 13, 2007, at 12:59 PM, [EMAIL PROTECTED] wrote: Since it belongs here: http://meiert.com/en/blog/20070913/microformats-and-pseudo-namespaces/ I hope you don't think I'm being overly critical, I just think your reasoning is flawed in a few ways and doesn't line up with the experience many of us have had in working with microformats over the last few years. To quote from the article: Current microformats unnecessarily limit “regular” web development. This may be somewhat true, but your supporting assertions are not: The hCard microformat alone theoretically blocks more than 20 class names is true only if you qualify it with when used in the context of an element that has the class name of 'vcard'. This has no conflict with hCard: !doctype html htmlspan class=titleNot a job title/span Again from the article: There is unnecessary cognitive load. Since this relies on the previous point, I don't think its valid. Authors only need to worry about root class names conflicting and using conflicting names within elements that have root class names on them. It's no where as bad as you make it sound. also, This is a very strict point of view, but seen mathematically, the microformat development will theoretically result in blocking every name available, is unfounded given the process [http://microformats.org/wiki/process] and ammounts to little more than FUD. Also, I'm not sure what you mean by mathematically? Do you mean, assuming unabated growth of microformats, we will eventually run out class names to use? If so, I think you're also assuming an infinite number of monkeys typing up random microformat specs (which use infinitely long class names (there's no limit on the length of class names)). Not only is this point practically wrong, but also wrong in theory. There are unnecessary layout risks. The larger the project and the more web decorators, designers, or developers involved, the greater the likelihood that there are unforeseen display problems when maintaining and extending the project. This is just a plain fact, independent of available measures. Microformats currently unnecessarily increase this likelihood as illustrated above, just due to the fact that they require developers who are aware of the constraints imposed by microformats. Again, this is just superfluous. The larger the project, the more need there is for markup best practices, and microformats present a set or markup best practices which can be shared from one workplace to another, not just within individual projects. I think microformats are a benefit to large projects, not a hinderance. Also, I don't see how your supporting points have anything to do with the layout of microformats in particular, it seems to be relevant to all markup practices. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Marking up table rows
On Sep 4, 2007, at 8:39 AM, Nick Fitzsimons wrote: I suspect it's the fact the lon/lat need a @class=geo wrapper. that would have to go on the TR meaning the vcard gets pushed up a level. tr class=vcard geo or is that naughty? :-) It's not naughty, but it just doesn't mean what you hope it means. :) -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Simple solution to abbr-D-P accessibility concerns: 'Title Trigger'
On Aug 17, 2007, at 5:41 AM, Toby A Inkster wrote: Andy Mabbett wrote: Here's a proposal, for a title trigger, an alternative to the abbr-design pattern. This is a reasonably good solution. For what it's worth, I'm waiting until this very long-standing issue has been resolved before implementing hCalendar and hAtom for my CMS software. (It already supports XMDP, XFN, rel-tag, rel-license and hCard.) Really, microformats.org needs to bless one of the many replacements for the abbr-design-pattern. I'm sure I'm not the only one who's waiting for a clear direction before proceeding. PS: I'm still looking for feedback on my metadata profile http://demiblog.org/schemes/metadata?ver=0.2.3. Does it comply with the spirit of the XMDP spec (I know it slightly deviates from the letter)? How about GRDDL? Though this is likely the best place to ask abou XMDP, there aren't many here with significant experience authoring XMDP documents. Questions about GRDDL would probably best be directed towards the GRDDL working group. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RubHub closing down?
On Aug 7, 2007, at 2:03 AM, Brian Suda wrote: On 8/6/07, David Mead [EMAIL PROTECTED] wrote: I just saw that RubHub is closing down. Does anyone know of any other sites out there that are doing, or plan to do, the same sort of thing? --- and/or if there is any plans to release the source code. I know Technorati uses kitchen.technorati.com and is spidering microformats, at the moment they are not displaying XFN (if they index it),... We do index XFN. I've done a bit of work on ways to display it, but haven't gotten them release-ready. -ryan ___ 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 Jun 28, 2007, at 1:37 AM, Andy Mabbett wrote: hQuote anyone? ;-) http://www.w3.org/TR/html401/struct/text.html#edef-Q -ryan ___ 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 Jun 28, 2007, at 6:13 AM, Frances Berriman wrote: On 28/06/07, Thom Shannon [EMAIL PROTECTED] wrote: Exactly! We need a brand and a website that introduces people to the concept, tells them where to get the plugins or the right browsers and possibly encourages them to put pressure on their web guys to implement them, Want x's on your site? Then use Microformats I think better encouragement would come from putting energy into creating tools, plug-ins, examples and tutorials for those people - rather than trying to re-brand something that's already something else re-branded. I couldn't agree more. I think this discussion is rather unproductive for this community. Just build the tools, design them well and get people to use them. If you never use the word 'microformat' in your application, that's fine. No harm, no foul, no need to build a new brand. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Question about telephone numbers
On Jun 25, 2007, at 5:10 AM, Rickards, Julian (NDM) wrote: The current format forces us to include voice or fax in text rather than in the attributes. In my original case, I didn't want to include the word voice in the text because in the contacts page I was/am creating, all of the numbers were voice numbers (all of the people in the contacts page share a single fax number so I didn't need to specify a fax number for each and use fax and voice to distinguish them for each person). voice is a default type. You can leave it out. The other problem I will encounter is the fact that because my efforts are on our government web pages (in Ontario, Canada, all government pages must be in both English and French), I must use the French equivalent to voice and fax in the text which means that the microformat will be broken. However, if voice and fax were accepted as attribute values, then I don't need to worry about the text in the page because the attribute value would be used instead of the text. You can put the type values in the title attribute of abbr elements in this case. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uF dumped in tag soup?
On Jun 15, 2007, at 8:15 AM, Dougal Campbell wrote: Okay, so I started a new job recently. The web site and service has a lot to do with SEO. But despite that, the HTML is a mess of table-based layout and tag soup. I'm hoping I can change that in time, but it won't happen quickly. But one of the main reasons that I think it's possible to change it is because I think that the interest in microformats, and the related boost in search indexing from Technorati and friends, will appeal to my boss. And from there, I have a stepping stone to the benefits of POSH in a more general sense. So I guess my question is, if I manage to shove some microformats (rel-tag, hCard and hReview come to mind) into the middle of our ugly-as-sin markup, are we going to get raked across the coals? :) Go for it. It's not guaranteed to work everywhere, since tag soup parsing isn't well defined and interoperable (we're working on that, though [1]). Many tools use tidy or libxml2's html parsing interface, so most will work pretty well already. -ryan 1. http://www.whatwg.org/specs/web-apps/current-work/#parsing ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Question about telephone numbers
On Jun 20, 2007, at 11:41 AM, Rickards, Julian (NDM) wrote: Hi: I am working on our government web site and am working towards implementing the hCard microformat for our contact pages. However, I am having a bit of difficulty with phone numbers. To verify my work, I installed the Tails Export extension for Firefox but when I export to Microsoft Outlook Contacts, the telephone number in the hCard doesn't export. An example of my efforts is: div class=vcardspan class=fnJim McAuley/span, span class=tel705-670-5855/span, a class=email href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/ a/div Is the problem with the export a limitation on Tails Export (I also tried the Operator extension with the same results) or something else? It's most likely a problem with outlook (see [1]). If you could provide us with a URL to an example that doesn't work, or a full example of the markup (in email) we'd be able to help more. -ryan 1. http://microformats.org/wiki/vcard-implementations#Microsoft_Outlook ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: XFN for email addresses?
On Jun 14, 2007, at 8:45 AM, Chris Messina wrote: I suppose this is where graph theory has to come in to some degree and afford immediate lapses as such, for, in the example you described, if somewhere there exists a reference, say on theryanking.com, that points to that email address using rel-me, we'll be able to apply some kind logic that would, in the least, be able to say that that URL has laid an unverified claim to that email address. This is my point– we can't do identity consolidation in this case. rel-me requires that we have links going both directions. Interestingly, this is, to some degree, the problem that MicroID was trying to solve, albeit with hidden meta tags. I agree that the lack of transitivity with email endpoints make them very weak from a claims perspective, and I agree that we can do better, but given that Technorati and the like still require a verified email address to open an account, I don't see this behavior going away anytime soon. Technorati does not require a verified email address. One goal of mine to develop a replacement for those add friends from your address book widgets, which are so seductive and therefore so dangerous. People are being trained to enter their email and password on almost every new social network; in the case of Gmail, that username/password combo access far more than just your mail (think: Google Checkout, web history, etc). This is extremely dangerous. If we could instead train people to type in a URL-pointer to their list of friends, authenticate remotely, and then pull down the list of contacts, including email addresses as necessary, we'd have a much safer social web. I agree that this is a Good Goal (tm), but that doesn't mean that XFN alone is the way to do it. In fact here's a better way: 1. User enters url (possible OpenId enabled) to a page that contains their contact info and XFN data. 2. The XFN data (rel-friend, rel-colleague) is used to find the list of people to import 3. Use rel-me hcard uid, etc to find contact information for the people on the list. 4. Import the contact info you find. Currently this requires a bit of hand waving, but I think we can make it work. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On Jun 12, 2007, at 8:15 PM, Chris Messina wrote: Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. And this is a quite large issue. It effectively removes the N in XFN. It's hard to build a network where some nodes can only by sinks[1]. -ryan 1. http://en.wikipedia.org/wiki/Degree_(graph_theory)#Sink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN for email addresses?
On Jun 13, 2007, at 4:25 PM, Chris Messina wrote: On 6/13/07, Ryan King [EMAIL PROTECTED] wrote: On Jun 12, 2007, at 8:15 PM, Chris Messina wrote: Clearly the biggest issue I see with this scheme is the inability to link out *from* the email address. However, I'm not sure that this case nullifies the utility of such links. And this is a quite large issue. It effectively removes the N in XFN. It's hard to build a network where some nodes can only by sinks[1]. -ryan 1. http://en.wikipedia.org/wiki/Degree_(graph_theory)#Sink [Trying again] And while that is a valid concern to be noted, I don't think that it precludes using non-URL based indicators as person identifiers. Just be clear, I believe that by non-URL you mean non-HTTP-URL. I mean, I'm a huge proponent of OpenID and URLs for identity; at the same time, that vision doesn't match with reality and I don't think it's going to change immediately; therefore, XFN should not be able to deal with the established convention even while things are (hopefully) moving in the direction of URL-based identifiers. In any case, consider mailing list subscriptions -- the fact that a message is sent to the identifier (aka your email address) and you respond by clicking a confirmation link proving that you can receive messages sent to that email address is no different than Technorati's current Javascript-based URL-claiming mechanism, whereby, instead of clicking a link, you insert a script that Technorati expects to find at the destination URL. The same argument can be made for IM links, since a bot could ping you and ask you for some data that only you would know, and if you're able to respond accurately, then you've similarly proven ownership of that destination. Actually they are different in an important way. The code we give people to put on their blogs includes rel=me and when blog claims are successfully completed, we link back to the blog with rel=me [1]. So, these assertions are public and can be indexed by anyone. To step back a bit, I see nothing wrong with trying to use email addresses to connect people's identities. It seems to be a cowpath that's already paved. However, I don't think it fits very cleanly into XFN. For example, you can do: a rel=met href=mailto:[EMAIL PROTECTED]ryan king/a Which is a clear, unambigious assertion, there's no way to connect the URL mailto:[EMAIL PROTECTED] to the rest of the XFN network via identity reconciliation and without that, we lack a lot of utility. Of course, I don't really have a better suggestion right now. :) But I think we can find a better way to do this. -ryan 1. We know this doesn't work for multi-author blogs, we're working around that. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fragment identifiers and XFN
On Jun 8, 2007, at 7:19 AM, Brian Suda wrote: I'm not sure that would apply to any query strings? http://example.org/users.php?user=briansuda that could return a unique page with a proper HTTP response code, because that is evaluated on the server side. But that's another discussion. Well, if you want to follow web architecture, all urls are opaque, so it doesn't matter whether the URL has a query string or not. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Problem with VoteLinks?
On Jun 7, 2007, at 7:42 AM, Costello, Roger L. wrote: Hi Folks, There may be a problem with VoteLinks. REVIEW OF VoteLinks Here's an example of using the VoteLinks Microformat to express support for a Web site that sells garlic capsules: a rev=vote-for title=I agree with taking garlic to lower cholesterol; I took garlic capsules for 2 months and it lowered my cholesterol by 30 points href=http://www.all-about-lowering-cholesterol.com/garlic- cholesterol. html Garlic Cholesterol /a Have you seen such examples in the wild? Or is this something you've authored? I think this would more naturally be expressed in hReview. div class=hreview p class=description I agree with taking garlic to lower cholesterol; I took garlic capsules for 2 months and it lowered my cholesterol by 30 points. /p p class=item a class=url href=http://www.all-about-lowering- cholesterol.com/garlic-cholesterol.htmlGarlic Cholesterol/a /p /div If you want to put the rationale in human readable text, they this would be a way to do it. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Problem with VoteLinks?
On Jun 7, 2007, at 10:47 AM, Costello, Roger L. wrote: The VoteLinks specification says that a VoteLink is used to (1) indicate agreement or disagreement with the resource indicated by href, and (2) the title attribute should be used to express a human-readable commentary (i.e., a rationale) for the vote. Brian and Ryan have shown that these two items of information are better expressed using hReview. Thus, it appears that VoteLinks is redundant at best, and in violation of the Microformat principles at worst, i.e., it hides rationale information - human information - in the title attribute. Thoughts? You might be right that vote-links is redundant. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fragment identifiers and XFN
On Jun 7, 2007, at 3:24 PM, Charles Iliya Krempeaux wrote: Hello Chris, AFAIK any URI should do. So you can use fragments too. It's actually not that simple. A more difficult example: http://technorati.com/about/staff.html#tantek_celik That page has identifying information for a number of people on it. XFN doesn't define how to process a part of a page, only an entire page. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a question about concatenation and hAtom entry content
On Jun 1, 2007, at 11:41 AM, Ryan King wrote: On Jun 1, 2007, at 10:59 AM, David Janes wrote: I concur. Time to start ramping up for hAtom 0.2, if I can get some blocks of free time. I'm more than willing to help. I have time to spend on it right now. I'll work on collecting issues to deal with. Ok, FWIW, here's the already open issues I think we need to deal with for hAtom 0.2. Even if this is all we do, I think it'd be a great improvement: 1. http://microformats.org/wiki/hatom-issues#Feed_id_.28atom:id.29 2. http://microformats.org/wiki/hatom-issues#Feed_permalink_. 28atom:permalink.29 3. http://microformats.org/wiki/hatom-issues#Feed_updated_. 28atom:updated.29 4. http://microformats.org/wiki/hatom-issues#Entry_id_.28atom:id.29 All of these issues cover areas where hAtom is not expressive enough to provide all the information necessary to generate a valid Atom file. Robert Bachmann, et al, worked around these issues by adding extensions to html2Atom.xsl. I've implemented some of extensions myself and they seem to work pretty naturally (even without authors even knowing about them!). David, if you like, I can find some more test cases and/or examples for each of these. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom 0.2 (was: a question about concatenation...)
On Jun 2, 2007, at 9:11 AM, David Janes wrote: On 6/1/07, Ryan King [EMAIL PROTECTED] wrote: On Jun 1, 2007, at 10:59 AM, David Janes wrote: I concur. Time to start ramping up for hAtom 0.2, if I can get some blocks of free time. I'm more than willing to help. I have time to spend on it right now. I'll work on collecting issues to deal with. Excellent. Brian indicated some willingness a while ago to help with this too. As a starting point, may I _suggest_ that we restrict hAtom 0.2 to _not_ adding new fields, unless they're already documented microformats. This still gives a fair amount of scope: how does rel-tag, rel-encloure working, better defaulting rules, loosening restrictions / defining defaults for required fields such as updated and author I think we have a reasonable amount of practical experience to draw upon now. If we do want to add new fields, they should be appropriated documented in the -examples. I think there may be an area where we need to consider adding new fields– as it currently stands, its actually difficult to author an hAtom instance that can be converted to valid Atom. There are just some things missing from hAtom, but all of these seem to be documented on http://microformats.org/wiki/hatom-issues , mostly thanks to Robert Bachmann. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: atom:category scheme
On Jun 3, 2007, at 1:42 AM, Edward O'Connor wrote: Ryan King wrote: I think we should use rel-tag tagspaces for atom category schemes. Sounds good to me. I wrote a bit about how to represent tags within atom:category here: http://edward.oconnor.cx/2007/02/representing-tags-in-atom Could you put a summary of your ideas and a link at http:// microformats.org/wiki/hatom-issues#atom:category_scheme ? thanks, ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a question about concatenation and hAtom entry content
On May 31, 2007, at 11:29 AM, David Janes wrote: On 5/31/07, Ryan King [EMAIL PROTECTED] wrote: Another option is that entry content is: p class=entry-contentContent/p p class=entry-contentMore Content/p Is there a reason why hAtom as currently spec'ed only does text, not markup? I thought it did markup! I totally see what you are saying here though; the question here is whether we include the DOM nodes that specify entry-content. This isn't in the spec, and you wouldn't want to do it everywhere (entry-title, for example) but it would make sense if it did. You're right, I'm suggesting that only for entry-content (and maybe entry-summary) that we take the nodes that have the class name on them. The reason? I've seen this several times: ... class=hentry ... p class=entry-content.../p p class=entry-content.../p / It makes sense, to me, to put the paragraph nodes, intact, in the content. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a question about concatenation and hAtom entry content
On Jun 1, 2007, at 7:25 AM, Brian Suda wrote: On 6/1/07, David Janes [EMAIL PROTECTED] wrote: --- maybe i mis-interpreted this, but do you mean that in a p class=entry-contentstrongContent/strong/p the strongs should be carried through? or converted to *Content*? The strongs (i.e., and all other HTML) should be carried through. Interesting -- are people reading the spec such that only text is implied? --- maybe that is a good thing, if i am converting hFeed into something that is NOT html, The spec just deals with how to convert to the Atom model. Your application can do whatever it wants with it from there. If a lot of people are converting to plain text, though, it would be useful to specify an algorithm (as we have on http://microformats.org/wiki/ hcard-parsing). -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] atom:category scheme
There has been some previous discussion[1] of this (in 2005!), but it seems to have been lost. I think we should use rel-tag tagspaces for atom category schemes. For those not familiar with Atom, category elements define 3 attributes: term, label and scheme. hAtom currently defines mapping to term and label (from the tag and text). I think we should map rel-tag tagspaces to atom:category schemes. I've put an entry on [2] at [3]. Any reason why we shouldn't do this? -ryan 1. http://microformats.org/wiki/hatom-issues#rel-tag 2. http://microformats.org/wiki/hatom-issues 3. http://microformats.org/wiki/hatom-issues#atom:category_scheme ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a question about concatenation and hAtom entry content
On Jun 1, 2007, at 10:59 AM, David Janes wrote: I concur. Time to start ramping up for hAtom 0.2, if I can get some blocks of free time. I'm more than willing to help. I have time to spend on it right now. I'll work on collecting issues to deal with. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a question about concatenation and hAtom entry content
On May 23, 2007, at 10:22 PM, Ben Wiley Sittler wrote: excerpted from http://microformats.org/wiki/hAtom#Entry_Content : an Entry MAY have 0 or more Entry Content elements. The logical Entry Content of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry Many weblogs split content into multiple sections with a Read More link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content. so if an hAtom entry contains p class=entry-contentContent/p !-- ad --pa href=http://mozilla.com;img src=chrome:// branding/content/about.png alt=Get Firefox! //a/p p class=entry-contentMore Content/p is the logical entry content 1. ContentMore Content (concatenation with no intervening space), 2. Content More Content (concatenation with space), 3. Content More Content (concatenation with newline), or 4. something else entirely? Another option is that entry content is: p class=entry-contentContent/p p class=entry-contentMore Content/p Is there a reason why hAtom as currently spec'ed only does text, not markup? -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] W3HTML WG, HTML5, semantics, and so on
On May 13, 2007, at 3:13 AM, Henri Sivonen wrote: On May 11, 2007, at 3:15 PM, John Allsopp wrote: (abbr pattern problems, Clearly, there's a need for markup for the generic pattern of marking up a triple of data presented to humans, the microformat class and a normalized easy-to-parse representation of the data. HTML5 time addresses only one instance of this pattern. I'm not sure it's clear that we need a general mechanism. AFAIK, the only real problem is with datetime fields. Everything else seems to work pretty well now. The problem with using abbr for this pattern is that title='' is intended to be human-readable and the pattern contaminates abbreviation data, so with microformats abbr is now less useful for e.g. non-microformat-aware but abbr-aware screen readers. The question that needs to be asked is: Will microformat producers and consumers be willing to migrate to a replacement of the abbr pattern if one is provided or will they continue to use abbr anyway for backwards compat? There's no way that we'll get 100% of microformat producers to switch to the new mechanism, but with advocacy we can get a large number to upgrade. If producers switch so will consumers (and I'll put it in the test suite, too :D). For example, should HTML 5 define a uf-data='' attribute as a common attribute such that the value of this attribute would be considered in preference over textContent by microformat consumers? Or should HTML 5 just mitigate the damage to the title attribute by defining a boolean attribute title-is-uf='' for flagging title='' attributes not meant for human consumption? I don't think so. This fails to solve a specific problem (solves a general problem that I'm not sure we need to solve). It also encourages hiding data, which is Not a Good Thing(tm). Is it too late to get rid of this? abbr title='uf data'human data/abbr Like I said, we probably won't be able to upgrade 100% of the data in the wild, so consumers will still have to support it, but we can probably get a lot. Would this be accepted by the uf community? span uf-data='uf data'human data/span Like I said, we should focus on specific problems and solutions, of which time does a great job of solving the the datetime-in-abbr- title issue. If not, would this be backwards-compatible with uf consumers? span title='uf data' title-is-ufhuman data/span Consumers would all have to be updated. So while it's backwards compatible with existing content, it isn't future compatible (if you started publishing this before consumers were updated, your content would not be handled correctly). -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fwd: Twitter Is Now Even More Geeky
On May 11, 2007, at 12:13 AM, Ben Buchanan wrote: And for the really geeky, we have a surprise: Twitter now fully supports microformats. Now that is pretty geektastic. How 'bout that! But what does that mean? Hmm, well it looks like all the are now hCards and the streams are hAtom. Nothing else is jumping out from a quick glance - can anyone spot anything more? XFN. All of the side bars use [rel=contact]. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a[name] as machine data?
On May 10, 2007, at 3:23 PM, James Craig wrote: Just a thought: Haven't thought too much about this, but are there any obvious gotchas to using an anchor element with name attribute as a potential replacement for the abbr-design-pattern? I believe a[name] and @id need to be unique across an entire page. This would make it impossible to have two events with the the same dtstart, dtend or dtstamp on the same page. I think that makes it unworkable. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] a[name] as machine data?
On May 10, 2007, at 4:45 PM, James Craig wrote: Ryan King wrote: James Craig wrote: Haven't thought too much about this, but are there any obvious gotchas to using an anchor element with name attribute as a potential replacement for the abbr-design-pattern? I believe a[name] and @id need to be unique across an entire page. This would make it impossible to have two events with the the same dtstart, dtend or dtstamp on the same page. I think that makes it unworkable. Only ID has that restriction. Radio buttons, for example, require elements have unique IDs but the same NAME. a[name has restrictions that input[name] does not have. Per [1], @id's and a[name] are collectively known as anchor names and must be unique, as they share the same name space. A relevant snippet: The id and name attributes share the same name space. This means that they cannot both define an anchor with the same name in the same document. It is permissible to use both attributes to specify an element's unique identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used on a single element, their values must be identical. -ryan 1. http://www.w3.org/TR/html401/struct/links.html#h-12.2.1 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
On May 3, 2007, at 4:53 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ben Wiley Sittler [EMAIL PROTECTED] writes Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar- brainstorming#Simplification_of_date-end but it has, so far, been ignored. It hasn't been ignored. I know that I've read and thought about it, but there isn't much to do about it right now, since it is predicated on a new version of hCalendar which diverges from iCalendar, which is not something I think we should be considering yet. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Yahoo introduces no-search microformat like function
On May 4, 2007, at 6:46 PM, Ben Ward wrote: On 4 May 2007, at 22:19, Ted Drake wrote: What’s the traction for something like this and “no-follow” to get integrated into the microformat platform? Well, robots-nocontent is not part of the the robots-exclusion draft, which in itself has not been updated for over 18 months. I contacted Priyank yesterday and he confirmed that Search have not implemented any of the robots-exclusion draft itself, nor have they implemented an opposite ‘robots-content’ class. I will email him again to see if we can get a concise specification of the indexing behaviour for robots-nocontent page sections so that it can at least be documented. If Peter Janes is still active here or if anyone else has an interest in picking up the robots- exclusion spec then it will be up to them and their work within the process to determine if the implementation can be documented as part of it. It seems like as good a time to ask; does anyone in the community still have an active interest in Robots-Exclusion? Are there any implementations? (Since I know disclosure is appreciated: If it's not already clear from the communications documented in this message, I recently started working for Yahoo! Europe. With relevance to this issue though, I am not in any way involved in Yahoo! Search. In a more general sense, at this time, none of my contributions to this list are representative of Yahoo! and so on and so forth yada yada) AFAIK, there has been 0 interest in robots-exclusion since before we even launched mf.org. However, if yahoo search is interested in implementing this, I'd encourage anyone with influence there to point them at our wiki and encourage them to go through the process. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] New Microformats.dk website
On May 8, 2007, at 10:22 AM, Brian Suda wrote: I found this Website today, i don't think it has been mentioned on this list before. It is a microformats website for Danish speakers. http://www.microformats.dk/ I know that we now have several other sites which are translating our blog and other content. We have a French Site, English, Japanese, Danish, Ukrainian (i think), and i'm sure i am forgetting others. As a community how should we embrace and extended these relationships? I couldn't find a wiki page that lists these other sites - and i'm not sure what you'd call it if we were to start a page. Any thoughts about how we could get these other communities to help advocate and localize content? we should help them to work independently but at the same time give them enough information in formats that they can use so we have a consistent message. How can we help? There's already some notes here: http://microformats.org/wiki/ Main_Page#microformats_wiki_translations_in_other_languages Anyone who'd like to create translations of wiki content is welcome to do so on the mf.org wiki. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On Apr 24, 2007, at 2:25 PM, Drew McLellan wrote: They're also subprops of fn when n isn't present. But n is present. They are? If so, that's news to me. Maybe you're referring to the implied-n rules? -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCard names - n vs. fn
On Apr 23, 2007, at 12:55 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes TD class=n SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=fnTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD On reflection, would it make more sense to reverse the n and fn, thus: TD class=fn SPAN class=honorific-prefixThe Rt Hon/SPANnbsp; nbsp; SPAN class=nTony Blair/SPAN nbsp; SPAN class=honorific-suffixMP/SPAN /TD honorific-prefix and honorific-suffix are subproperties of n, so no, I don't think it makes more sense. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] URLs in hrefs
On Apr 20, 2007, at 6:08 AM, Nic James Ferrier wrote: David Janes [EMAIL PROTECTED] writes: The reason that there has been little discussion is that the rules for dealing with this are well understood and settled. This document [1] will give you everything you need -- written in 1995. Regards, etc... [1] http://www.ietf.org/rfc/rfc1808.txt I disagree. I think Mikey raises a good point. When you're parsing bits of data from a page with xslt or javascript you sometimes have to do the url resolution yourself and that is not as simple as it should be. Here's a stylesheet that'll help you do it in xslt: http://www.w3.org/2000/07/uri43/uri.xsl -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] URLs in hrefs
On Apr 19, 2007, at 9:45 AM, Michael Smethurst wrote: Afternoon all Standard practice at the beeb has always been to use link urls relative to the root: href=/radio4/today Clearly these are of little use in a microformat (or any attempt to use html as an api) It's not clear that they're of little use. Anyone processing HTML documents on the web has to deal with relative URLs already (and base). Don't change. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Numbers of Microformats in the Wild?
On Apr 12, 2007, at 8:06 AM, Kevin Lawver wrote: I'm presenting on microformats at Web 2.0 Expo (well, hopefully, if they can move me back to my original time) next week, and would love to have more examples of folks using microformats as APIs. I ungraciously stole an idea I saw on the list of grabbing the URL used as an OpenID and looking for an hcard on it to build a demo for my talk, but, I'd love more examples to point to. Also, anyone have the digits that Tantek likes to use about the number of pieces of microformatted content out there in the wild? I don't have the latest... I don't think we have any good overall estimates. AFAIK, no one has an index of all microformats in the wild. Most estimates I make are based off of the implementations and examples-in-the-wild pages on the wiki with some estimates of extrapolation. -ryan ___ microformats-discuss mailing list [EMAIL PROTECTED] http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] table headers inclusion method axis
On Apr 9, 2007, at 6:40 AM, Andy Mabbett wrote: Thee are a couple of references, on the wiki, to the table headers inclusion method and axis in tables, not least: http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars from a year ago, but I can't find any more definitive documentation. Nor do I recall any recent discussion. I don't believe there is more definitive documentation and most of the discussion of the techniques was in IRC, IIRC. Is it part of the spec for hCard, hCalendar, or any other microformats? It's a proposed addition, but it's been low priority, because there hasn't been much demand for it. Which parsers are using it, and for which microformats? It's in our test suite[1] for hCard. X2V uses it, our parser at Technorati uses it. -ryan 1. http://hg.microformats.org/tests?f=1672a460cd67;file=hcard/32- header.html;style=gitweb ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] table headers inclusion method axis
On Apr 9, 2007, at 12:39 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ryan King [EMAIL PROTECTED] writes Thee are a couple of references, on the wiki, to the table headers inclusion method and axis in tables, not least: [...] Thank you for your answers, but... Is it part of the spec for hCard, hCalendar, or any other microformats? It's a proposed addition, but it's been low priority, because there hasn't been much demand for it. ...perhaps that's because no-one knows about it; because it's not documented..? (Chickens and eggs would seem to be a topical simile!) You're probably right, the lack of documentation has not helped with adoption. If you understand the techniques, I encourage you to document them. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Geo deployed on Wikipedia.
On Apr 4, 2007, at 4:31 AM, Costello, Roger L. wrote:
Is there an adr template in Wikipedia, so that the adr Microformat
can be automatically injected into Wikipedia pages?
Not /yet/...
Is there a way to create new templates? Can we create a template
for
hcard, vevent, and so forth?
That's being looked at, but the situation is extremely complex, ...
I think that it might not be complex, if the scope is limited.
Many wiki articles have the name of a person. Create a wikipedia
template that wraps the name with hCard.
For example, here's a wikipedia article on Arthur Ernest Percival [1].
His name could be wrapped in a wiki template like this:
{{person-name
|given-name=Arthur|additional-name=Ernest|family-name=Percival}}
The HTML that is generated by the template could be:
Arthur Ernest Percival
span class=hcard style=display:none
(span class=family-namePercival/span,
span class=given-nameArthur/span
span class=additional-nameErnest/span)
/span
Please don't introduce hidden metadata. That's one of the things
we're trying to avoid with microformats.
-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hCard creator and multitoken given/family names
On Apr 4, 2007, at 7:58 AM, Henri Sivonen wrote: On Mar 28, 2007, at 21:00, Ryan King wrote: On Mar 28, 2007, at 9:47 AM, Henri Sivonen wrote: I'd be interested in a design rationale pointer explaining why having more than two tokens in an fn is not allowed when the information about the roles of the tokens is unavailable to the producer of the markup. Is this something that has been inherited wholesale from vCard? Having more than 2 tokens in an fn is allowed, it's just not useful for calculating an implied-n. Now I'm confused. Is it allowed even if the same hCard does not contain an explicit n or explicit name part tokens? Where is it specified that more than 2 tokens in an fn are allowed? I'm not objecting. fn with more than 2 token is what I was asking for. I just don't see spec text allowing it. FNs with more than 3 tokens are perfectly fine, it's just that there's no implied-n rule that can deal with it, so the creator needs to explicitly mark up N. With just two tokens (given and family name) we leave the N markup out, because the implied-n rules can take care of it. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: hCard creator and multitoken given/family names
On Apr 4, 2007, at 11:14 AM, Henri Sivonen wrote: On Apr 4, 2007, at 20:10, Ryan King wrote: FNs with more than 3 tokens are perfectly fine, it's just that there's no implied-n rule that can deal with it, so the creator needs to explicitly mark up N. Well, that doesn't help. It doesn't solve the issue of what to do when the generator has formatted names but does not have data about the token roles available. :-( I'm not sure how that'd happen, since the form[1] asks for the N sub- properties separately and combines them to form the FN. -ryan 1. http://microformats.org/code/hcard/creator -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] xfolk questions
On Apr 3, 2007, at 5:12 AM, John Metcalf wrote: Hi, I'm new to microformats and have some questions about xFolk: Is it okay to have the taggedlink inside the description? Yes. Is it okay to mark up my internal links with xFolk? Sure. Can I tag links without the actual tag being a link somewhere? No. xFolk uses rel-tag[1], which is designed to use links for tagging. -ryan 1. http://microformats.org/wiki/rel-tag -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: hCard creator and multitoken given/family names (was: Re: [uf-discuss] hCite elevator pitch and my bibliography generator)
On Mar 28, 2007, at 9:47 AM, Henri Sivonen wrote: On Mar 23, 2007, at 14:22, Paul Wilkins wrote: Currently the formatted names are accepted in the following formats given-name (space) family-name family-name (comma) given-name family-name (comma) given-name-first-initial family-name (space) given-name-first-initial (optional period) Then it appears that hCard creator (http://microformats.org/code/ hcard/creator) is broken. If I enter Jesus Maria as the given name and van der Boer y Gonzales as the family name, I get: span class=fnJesus Maria van der Boer y Gonzales/span This is a bug caused by lack of foresight on my part. It should be fixed now. I'd be interested in a design rationale pointer explaining why having more than two tokens in an fn is not allowed when the information about the roles of the tokens is unavailable to the producer of the markup. Is this something that has been inherited wholesale from vCard? Having more than 2 tokens in an fn is allowed, it's just not useful for calculating an implied-n. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] An Inconvenient hCard
On Mar 11, 2007, at 6:06 PM, Ara Pehlivanian wrote: I've got a bit of a problem with an hCard that I need to mark up and I was wondering if anyone could lend me a hand. I realize the syntax requires that a type be specified for telephone numbers (voice, fax, etc...) and that's where my problem lies. Type is not required. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Identity-related hCards?
On Mar 1, 2007, at 6:25 PM, Joe Andrieu wrote: Ryan King wrote: On Feb 20, 2007, at 12:23 PM, Scott Reynen wrote: And maybe that's because what you're describing is actually more specific that related hCards implies. It seems here you're just talking about a single relationship: identity. Yes. You're exactly right. I'm afraid I haven't been that clear. When I say related hCards I mean related in that they represent the same person or organization. I've been using related hCards as shorthand for hCards that represent the same person or organization, which I now realize must be confusing. (but it seemed so clear in my head! :D) Ryan, That made me laugh out loud. I was definitely responding to uid +url as non-identity relations earlier and it seemed perfectly clear in my head as well. =) So, don't equal UIDs already imply identitical hCards? No. Per the RFC, UID identifies the entity represented by the vCard or hCard [1]. In other words, what I think we've really been discussing is how to discover hCards for identical entities, using either URL or SOURCE (or via, although I think SOURCE is much better). Exactly. Frankly, it seems like it would work if it SHOULD be expected that consume apps MAY use URL and/or SOURCE to look for identical hCards. I believe this approach allows both uid+url and uid+source to link to related and/or sourcing hCards without any of further restrictions on the UID. I don't see any reason why source can't be used as well as url+uid. They signify different semantics, but are both already a part of the format. They only thing we need to figure out with SOURCE is what consuming applications that convert to vCard (like X2V) should do. Should they take the SOURCE value from the hCard or should they use the URL of the hCard (as X2V currently does). -ryan 1. From section 3.6.7 of RFC 2426 (http://www.ietf.org/rfc/rfc2426.txt): Type purpose: To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. ... Type special notes: The type is used to uniquely identify the object that the vCard represents. -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] related hcards [was VIA or VIA SELF to indicateauthoritativehCard[was:UID URL to indicate (relatively)moreauthoritativehCard...]]
On Feb 23, 2007, at 1:44 AM, Joe Andrieu wrote: Ryan King wrote: I understand this. I agree that this is a desirable goal. I would personally like to see it happen. However, the simpler problem of two hcards representing the same person (or organization) should be solved first, because it is a simpler problem, with a simpler solution (which may not require adding any properties to hCard). If all you want to do is have two hCards represent the same entity, why not just use the same UID? I think I understand that it is to traverse the network to discover multiple, synonymous hCards for the same entity? That what you want is not just synonymity, but discoverable synonymity. Is that correct? Yes. The nice thing about URLs is that you can dereference them and consume the resource returned. RFC2426 [1] (the vCard spec incorporated by reference into hCard) specifies the URL type use as: To specify a uniform resource locator associated with the object that the vCard refers to. Your algorithm was: 1. if no uid or uid == the uid from the previous iteration/recursion = you're done 2. if url == uid and there's an hCard at that url, recurse with the new hCard In that case, what you are saying is that if the UID is the same as the URL, one should expect to be able to assume a common relationship between this hCard and any hCard with either no UID or a matching UID at the URL for this hCard. Here's what seems to fail in this usage: 1. Referrees without UID match any referring hCard 2. Ambiguous relation when multiple hCards are present at URL 3. UIDs that are XRIs and not URLs 4. UIDs that are not URLs, generally. 1. Referrees without UID match any referring hCard If the referred to hCard has no UID, the algorithm assumes relatedness, but that seems dubious at best without a confirming UID. I agree. It is a bit dubious. This might be something that's left to consuming applications to decide. 2. Ambiguous relation when multiple hCards are present at URL If the referred to URL has multiple hCards, each with no UID, there is no way to disambiguate which one(s) should be related. So... Refering card: span class=vcard span class=fnMr. Andrieu/span span class=uid urlhttp://www.andrieu.net/span /span While on Andrieu.net we might have multiple hCards span class=vcard span class=fnJoe Andrieu/span /span span class=vcard span class=fnJulia Andrieu/span /span span class=vcard span class=fnMike Andrieu/span /span span class=vcard span class=fnMaureen Andrieu/span /span Who is Mr. Andrieu? This is even more likely to occur when we accept the dynamic nature of the web and the inevitable consistency errors of less-than-perfect data maintenance. It seems to me that relating only cards with common UIDs makes a lot of sense. One option here would be to only take hCards in an address. Of course that doesn't apply in your example, but it would work in some real world examples (like http://theryanking.com/blog/). 3. UIDs that are XRIs and not URLs With the use of OpenID as UID, do we extend the field URL to include XRIs? This may or may not make sense, but stuffing an XRI into a URL/URI is out of spec unless the spec changes to allow it. XRIs are designed to replace URIs, but plenty of consuming applications break today if you try that. 4. UIDs that are not URLs I stand by the argument that UIDs that are not URLs should be viable in any mainstream use of any microformat. Your bias towards URLs as UIDs shouldn't limit people's use of UIDs with alternate formats, such as XRIs. If we feel strongly about such a bias, as a community, we should change the hCard spec to require UIDs as URLs. XRIs as UIDs is just /one/ example where I think the evidence is overwhelmingly clear that there is technical acceptance and solid reasoning for UIDs that are not URLs. Now, we could change the definition of URL to include XRIs, but I think we are better off accepting that we cannot predict the future, nor should we presume that URLs are the only good UID unless we are willing to make that a requirement in the spec. And frankly, that would put our definition of URL at odds with RFC for URLs.[2] The spec uses should for good reason. It is because of that *should* that XRI UIDs are 100% compliant with hCard /today/ without redefining the spec. That's a good thing. Making URL UIDs a requirement for discovering synonymous hCards seems arbitrarily limiting with minimal payoff. Items 1 2 could be trivially addressed by simply modifying your algorithm to require that the UID of the /referred to/ hCard match the UID of the referring hCard for anything to work. So they aren't major issues. (And it is clear that in the brevity of your algorithm, you didn't say termination assumed relatedness, so 12 aren't all that important.) However, non-URL UIDs, as exemplified by XRIs as UIDs is a fundamental problem that you have not satisfactorily addressed
Re: [uf-discuss] Identity-related hCards?
On Feb 20, 2007, at 12:23 PM, Scott Reynen wrote: On Feb 20, 2007, at 1:05 PM, Ryan King wrote: However, the simpler problem of two hcards representing the same person (or organization) should be solved first, because it is a simpler problem, with a simpler solution (which may not require adding any properties to hCard). The implication I've always taken from the simpler problem first principle is that this makes the more complex problems easier to solve. But this is only true if the simpler problem actually helps solve the more complex problem. Related hCards is also a simpler problem than book citations, but we don't half that discussion because solving the simpler problem has no descernable impact on the more complex problem. I think what's confusing those of us interested in the more complex problem of authoritative hCards is how solving related hCards would actually help solve that problem. And maybe that's because what you're describing is actually more specific that related hCards implies. It seems here you're just talking about a single relationship: identity. Yes. You're exactly right. I'm afraid I haven't been that clear. When I say related hCards I mean related in that they represent the same person or organization. I've been using related hCards as shorthand for hCards that represent the same person or organization, which I now realize must be confusing. (but it seemed so clear in my head! :D) -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Training events in hResume
On Feb 16, 2007, at 9:53 PM, Colin Barrett wrote: I'd just like to pop into the thread briefly and remind people to take a look at what markup and best practices already exist in the wild. We don't want to wander off into purely theoretical land here ;) That's great advice. I'd also suggest that those who want to extend hResume start by experimenting with their own resumes/CVs. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Training events in hResume
On Feb 16, 2007, at 9:15 AM, Rob Crowther wrote: I think that's a good idea, though we should probably use title as type doesn't seem to be a valid attribute on anything other than links? So we could have: The title attribute is hidden metadata, which we try to avoid as much as possible. span class=education title=school ... /span span class=education title=university ... /span span class=education title=training ... /span span class=education title=certification ... /span span class=education title=informal ... /span Why not just use tags? span class=education vevent ... a rel=tag href=/ informal.../a/span ? -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] User Groups
On Feb 22, 2007, at 10:45 AM, Thom Shannon wrote: I'm trying to come up with a way to join the huge network of user groups out there and make it easier to find user groups in your area. The obvious solution would be to create a website where people go and add their group. I can't imagine if I setup such a site the take up would be that huge, plus the data would quickly get stale. So I had the idea of promoting some sort of microformat convention, such as creating an hCard for user groups and vCard for the meeting events, then tagging all of those with something like usergroup. Then you could use technorati to search all the microformats with that tag, and at some point you'll be able to filter them my area, I may end up writing that mashup myself. It will also tap into all the data on sites like upcoming.org. My problem is that I'm not sure how to come up with the right convention to start promoting, is a tag like usergroup a good idea? There are very few examples of people using it, but I can't find anything else specific that's used much. Please at least search the wiki before proposing a new format. A simple search for 'group' brings up: http://microformats.org/wiki/group-brainstorming http://microformats.org/wiki/group-examples There's also prior art in http://hellonline.com/cgi-bin/trac.cgi/wiki/XMF Thanks, ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 13, 2007, at 2:38 PM, Scott Reynen wrote: On Feb 13, 2007, at 12:32 PM, Ryan King wrote: And if the uid is not an url, then authors can't assert authority, correct? I'm not even considering authority for now. We need to just deal with related hCards first. I'm no longer clear on what you're proposing, Ryan. I thought you were proposing UID+URL as an alternative to VIA, as a way to declare authority through identification rather than through origin. But if you're not considering declaring authority at all, then how does this solve our original problem? As I've mentioned before in this thread. Before trying to solve the authority problem, we need to solve the simpler problem of related hCards. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritativehCard[was:UID URL to indicate (relatively) moreauthoritativehCard(Was:Vote on this: rel=me self to indicateanauthoritative hCard)]
On Feb 14, 2007, at 5:34 PM, Joe Andrieu wrote: Ryan King wrote: On Feb 10, 2007, at 3:09 AM, Joe Andrieu wrote: Ryan King wrote: First off, I'm not saying we should constrain UID to be a URL, but in the case that it *is* a URL, we can apply these semantics. And if the uid is not an url, then authors can't assert authority, correct? I'm not even considering authority for now. We need to just deal with related hCards first. This thread started with discussion about canonical cards, which I recast as authoritative. Everyone else has been discussing that goal. Your commitment to a different mechanism for related hCards might have merit, but it isn't what this conversation started as. I'm well aware of this. Secondly, UID is supposed to be a globally unique identifier, so something like a student id wouldn't qualify. Now if you take those two points together, plus the fact that URLs have a build-in system for distributed, uniform allocation, I think UIDs *should* be URLs. I can't imagine using anything else besides a URL in any useful way. Sure. I understand why uids *should* be urls. But it is not required. Limiting authority to publishers who agree with the spec authors' shouldness is unkind. If uids had to be urls, your argument would be much more compelling. Once again, we should solve the simpler problem of related hCards before we worry about which of a set of related hCards is the most authoritative. Please clarify why a desire for a potentially simpler mechanism solves the problem of canonical or authoritative hCards? This is one of the core principles of microformats solve simpler problems first. [1] The desire that started this conversation was for a referring card to explicitly claim another as canonical. The conversation as evolved for that claim to mean more authoritative. I, for one, would also like to see a way for an hCard to state that itself is the most authoritative hCard it knows of, which would address a way for authors to indicate a canonical or authoritative hCard. If you would also like a mechanism that specifies a non- authoritative relationship, that, I think is a different conversation. I understand this. I agree that this is a desirable goal. I would personally like to see it happen. However, the simpler problem of two hcards representing the same person (or organization) should be solved first, because it is a simpler problem, with a simpler solution (which may not require adding any properties to hCard). Also, I don't see what's unkind about building features that leverage a SHOULD in a spec. Compatibility for one. If you want a service to support all compliant hCards, then it should use the /requirements/ of the spec. If there is a way to enable new services, it should be able to work for all hCards that are compliant with the spec. If you prefer that hCard uids *must* be URLs, then lets talk about changing the spec. It is essentially passive-aggressive to build services that depend on *should* features instead of explicitly changing the spec. If the specs wrong, let's fix it. If it is right, then lets enable services that work for all compliant hCards. There's nothing wrong with building services that depend on parts of a spec that aren't required by a MUST. If people want to make use of the feature they are free to do so. However, in the particular case of hCard's UID, if we were to require URIs for the UID, we would render a large number of vCards unable to be rendered in hCard. That's not a good idea at this point. I am saying that we should use some terms from Atom in hCard to that publishers who have their own uid scheme can still assert authority in hCard. I understand, but unless we can first demonstrate that there's nothing in hCard that can help us, there's no reason to look outside it, even to something as well specified as Atom. I think the deeper problem is that you don't want to support the use case that started this conversation, namely canonical or authoritative hCards. I do want to support it. I really do. But we need to solve the simpler problem (with a simpler solution) first. Forcing the religion of uids should be urls on the rest of the world is not why we are here. I'm not sure why you call it religion. URLs are useful for very practical reasons- it's easy for many people to produce them in such a way that they won't clash and they have the advantage of being dereferencable. I refer to it as a religion, because it is a belief system you hold that URLs as UIDs is /always/ preferable. There are many domains, such as books, where the UID is not best served as a URL and I assert without online evidence that there are plenty of similar domains for individuals (SSN, passport #, driv. License #, etc.). I appreciate your personal disposition that UID as URL is the right way to do things, for your view of the world. But there are other
Re: [uf-discuss] Training events in hResume
On Feb 13, 2007, at 3:23 AM, Rob Crowther wrote: On 12/02/07, Pat Ramsey [EMAIL PROTECTED] wrote: Training being a learning experience, I would think marking it up as education is appropriate. But work is (or perhaps should be) a 'learning experience' too. It's not quite the same thing, but most application forms I've filled in have had separate sections for Education and Training. A quick google for some examples: 1 - http://www.chichester.gov.uk/your_council/council_jobs/ copy_of_job_appln_form1.cfm (link to Word doc on page) - Has an 'EDUCATION PROFESSIONAL QUALIFICATIONS' section, separate boxes for schooling, professional qualifications and 'other relevant training' but all under the same heading. 2 - http://www.tendringdc.gov.uk/NR/rdonlyres/ E8AE5F2D-4F09-46F7-8044-9A45A924CDCE/0/ApplicationForm130306.pdf - seperate sections for Education and Professional Qualifications 3 - http://www.unison.org.uk/acrobat/B1491.pdf - separate sections for Education and Training, though the distinction is that anything which leads to a qualification is Education, and everything else is Training. This is perhaps a more useful practical distinction than the slightly nebulous concepts I had in mind. 4 - http://www.scope.org.uk/downloads/jobs/jobapp_may05.doc - similar to 3, things with an exam are Education, other things are Training. 5 - http://www.rhul.ac.uk/personnel/application.pdf - similar to 1, all in one section but sperate boxes for School, Further/Higher Education, Formal Qualifications and Other Training 6 - http://www.broxtowe.gov.uk/application_form_april_2006.pdf - Education and Training all in the same box/section. On the basis of the above examples, I would suggest that a distinction between education and training could be useful as clearly employers sometimes see them as distinct concepts. Sometimes is not enough. We're trying to work with the 80 side of the 80/20. I have nothing against improving hResume here, but we shouldn't add features that only a minority of people would use. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 10, 2007, at 3:09 AM, Joe Andrieu wrote: Ryan King wrote: First off, I'm not saying we should constrain UID to be a URL, but in the case that it *is* a URL, we can apply these semantics. And if the uid is not an url, then authors can't assert authority, correct? I'm not even considering authority for now. We need to just deal with related hCards first. Secondly, UID is supposed to be a globally unique identifier, so something like a student id wouldn't qualify. Now if you take those two points together, plus the fact that URLs have a build-in system for distributed, uniform allocation, I think UIDs *should* be URLs. I can't imagine using anything else besides a URL in any useful way. Sure. I understand why uids *should* be urls. But it is not required. Limiting authority to publishers who agree with the spec authors' shouldness is unkind. If uids had to be urls, your argument would be much more compelling. Once again, we should solve the simpler problem of related hCards before we worry about which of a set of related hCards is the most authoritative. Also, I don't see what's unkind about building features that leverage a SHOULD in a spec. Forcing publishers to synchronize uids with urls may make for a more elegant standard, but it doesn't meet the test of humans first, machines second. Seems to me that authors should be able to indicate the source/reference/authoritative hCard without having to use the source url as their uid. I understand that in many cases we'd like to refer to entities that don't have a stable URL. I'm not sure this is the right place to introduce another universal identification scheme. Ryan, I didn't suggest that we introduce new universal identification scheme. I'm sorry if I misunderstood you, but it seemed like you were trying to deal with the problem of referring to hCards without a stable URL by introducing a new scheme. I am saying that we should use some terms from Atom in hCard to that publishers who have their own uid scheme can still assert authority in hCard. I understand, but unless we can first demonstrate that there's nothing in hCard that can help us, there's no reason to look outside it, even to something as well specified as Atom. Forcing the religion of uids should be urls on the rest of the world is not why we are here. I'm not sure why you call it religion. URLs are useful for very practical reasons– it's easy for many people to produce them in such a way that they won't clash and they have the advantage of being dereferencable. Remember, UID signifies the entity that the hCard represents and we're already observed and documented that, in practice, people use URLs to signify other people and companies. This is encoded in XFN and works well in practice. Making it easy for authors to connect their web content and web apps with the semantic web is. If someone else likes uids that aren't urls, and the spec supports that, then why should we keep them from establishing authoritative hCards? Every specification reflects opinions of its editors as to the best way to do things. I think the best UIDs are URLs. If you don't want to make UIDs that aren't URLs, then you'll have to find another way to refer to people and organizations on the web. Before solving the problem of 'canonical' or 'authoritative' hCards, we should solve the problem of 'hcards representing the same person'. Before you can have trust you need identity. Actually, I think authoritative is a simpler, special case of two hCards representing the same person. Trying to solve the general problem of multiple hCards representing the same person is a mess. Consider: school and work directories conference bios online papers and articles and blog comments public records like DMV and the courts youtube, flickr, yahoo, and google accounts In contrast, the if we can simply assert two claims, we have a useful relationship that I have already seen much use for: 1. This (refering) hCard is a stub or abbreviated version of this other source hCard. 2. This (authoritative) hCard is itself the most authoritative reference for this hCard. I don't get your point. Your arguement here assumes that we can figure out when two hCards refer to each other as related, which is the simpler problem I'd like to solve. I think we might be partially agreeing here in a way that isn't very clear. I'm saying that a general way to define relationships between hCards is a harder problem that (a) a specific relationship between two hCards and (b) a unique relationship between an hCard and itself (that is, the assertion that this hCard is itself authoritative). The difference is that we're defining two different kinds of relationships. I want to define the relationship that two hCards represent the same entity, whereas you want to define something more specific. I have another objection to your
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 12, 2007, at 6:36 AM, Ryan Cannon wrote: On Feb 12, 2007, at 8:16 AM, David Janes wrote: a globally unique identifier corresponding to the individual or resource associated with the vCard. (from http://www.ietf.org/rfc/rfc2426.txt) Is RK's UID http://theryanking.com/blog/contact/#vcard or http:// theryanking.com? Each hCard in that chain contains a *different* UID. That's not a globally unique identifier. The *object identifier* of the hCard and the *source document* for the hCard are two semantically different things, and need two different constructs. Actually, it is a globally unique identifier. I'm the only person in the world represented by http://theryanking.com, http:// theryanking.com/contact/ and http://theryanking.com/contact/#vcard. Any hCard that includes these as UIDs represent me. Though each of those represent only me, I obviously have many different URLs on the web that could be treated as my UID. This makes things messy, for sure, but it's how people work on the web already. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was:UID URL to indicate (relatively) more authoritativehCard(Was:Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 11, 2007, at 6:16 PM, Ryan Cannon wrote: On Feb 10, 2007, at 2:56 PM, Joe Andrieu wrote: Forcing the religion of uids should be urls on the rest of the world is not why we are here. Making it easy for authors to connect their web content and web apps with the semantic web is. If someone else likes uids that aren't urls, and the spec supports that, then why should we keep them from establishing authoritative hCards? ... How is via+via self more constraining? You can do everything you can with uid+url, but you don't have to use URLs for your UIDs. +1 UID+URL *is* more constraining. Like rel-tag, you're forcing a lot of assumptions about the documents *surrounding* these URLs--links have to point somewhere after all. My UID, if you will, is http://ryancannon.com/. I've established it across many different sites as the definitive link for me. By forcing UID+URL to be used to establish an hCard's source, you're also forcing my most robust hCard must exist at that URL. No, we're not. Once again, we're just talking about related-ness, not authority. Also, I don't see why authoritativeness has to also mean completeness. Wouldn't authority be applied on a field-by-field basis? However, when I redesign my home page, if I want to move my contact information to ryancannon.com/contact my UID shouldn't change--it's still just the domain. However, with URL+UID, I'm screwed. With @rel=via, I can still have the option to point to my full hCard. No, you're not screwed. All you have to do is put a minimal hcard on your home page with UID+URL=ryancannon.com/contact. That's it. Also, Ryan, you have yet to address the fact that URL+UID changes the parsing rules of the hCard--not that I believe it is currently ideal. Is it responsible for the community to change the rules of a deployed specification willy-nilly? While the implementation in X2V may be trivial, it may not be in other applications in the wild-- it's also not a good precedence to set for uFs in general. For backwards-compatibility alone, @rel=via seems to me an optimal solution. Yes, this would mean a change in how UIDs are parsed, however the only UID I can find in the wild are URLs. A change wouldn't break anything. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] SOURCE+URL to indicate authoritative hCard (was UID+URL vs. VIA)
On Feb 12, 2007, at 8:01 AM, Scott Reynen wrote: Has anyone looked at using the SOURCE property from vCard to indicate a more authoritative hCard? It seems to be much closer to what we're talking about than UID. The value is already defined as URI. SOURCE is already used by X2V to indicate the URL at which the current hCard is available. I don't think we'd be able to override that at this point. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] SOURCE+URL to indicate authoritative hCard (was UID+URL vs. VIA)
On Feb 12, 2007, at 12:49 PM, Brian Suda wrote: On 2/12/07, Scott Reynen [EMAIL PROTECTED] wrote: On Feb 12, 2007, at 1:05 PM, Ryan King wrote: Has anyone looked at using the SOURCE property from vCard to indicate a more authoritative hCard? It seems to be much closer to what we're talking about than UID. The value is already defined as URI. SOURCE is already used by X2V to indicate the URL at which the current hCard is available. I don't think we'd be able to override that at this point. SOURCE is just the 'source' of where the the hcard came from. 2.1.4 SOURCE Type If the SOURCE type is present, then its value provides information how to find the source for the vCard. SOURCE in vCard is essentially the same as self in Atom (AFAICT). -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard[was: UID URL to indicate (relatively) more authoritativehCard(Was: Vote on this: rel=me self to indicate anauthoritative hCard)]
Ryan King: The problem, IMO, with uid url is that the uid for a book, for example, is more likely an ISBN rather than a URL, so it wouldn't necessarily be a URI. Allowing both an ISBN uid and a via link allows parsers that aware of ISBN to do smart things (such as link to Amazon if they wish) /or/ follow the via tag for the author's source reference. I'm not sure how this is relevant. We're talking about hCard here, not a citation format. That's valid. I ended up being more general in that example than necessary for the simple hCard solution. (The via semantics could apply to any referring/authoritative microformat relationship.) However, the semantics remain an issue. url+uid presumes that the uid for the hCard /is/ a url. I can think of many situations where it isn't and the spec explicitly allows non-url uids. For example, when my school or company lists me in a directory. The uid in that domain could appropriately be my student or employee id, not the url where the authoritative record of my affiliation/status/contact information might be kept. First off, I'm not saying we should constrain UID to be a URL, but in the case that it *is* a URL, we can apply these semantics. Secondly, UID is supposed to be a globally unique identifier, so something like a student id wouldn't qualify. Now if you take those two points together, plus the fact that URLs have a build-in system for distributed, uniform allocation, I think UIDs *should* be URLs. I can't imagine using anything else besides a URL in any useful way. For example, this URL could be marked up with an hCard with personID as the UID http://www.search.caltech.edu/CIT_People_off_campus/action.lasso?- database=CIT_People-response=Detail_Person.html-layout=all_field sperson_id=16987-search Rather than the entire URL. In fact, the URL is probably not a permalink, making the person_id potentially a much more stable id for the contact info on that page. Of course, it all depends on the IT department, but the real issue is that while using permalink URLs for uids is elegant, it is not always practical, hence the SHOULD in the spec. Forcing publishers to synchronize uids with urls may make for a more elegant standard, but it doesn't meet the test of humans first, machines second. Seems to me that authors should be able to indicate the source/reference/authoritative hCard without having to use the source url as their uid. I understand that in many cases we'd like to refer to entities that don't have a stable URL. I'm not sure this is the right place to introduce another universal identification scheme. Ryan King: Also, the url+uid proposal only concerns the case where the url and uid are the same (and, therefore, a URL). From a different email Ryan also wrote: Problem 1: Not tackling the simplest problem first. Before solving the problem of 'canonical' or 'authoritative' hCards, we should solve the problem of 'hcards representing the same person'. Before you can have trust you need identity. Actually, I think authoritative is a simpler, special case of two hCards representing the same person. Trying to solve the general problem of multiple hCards representing the same person is a mess. Consider: school and work directories conference bios online papers and articles and blog comments public records like DMV and the courts youtube, flickr, yahoo, and google accounts In contrast, the if we can simply assert two claims, we have a useful relationship that I have already seen much use for: 1. This (refering) hCard is a stub or abbreviated version of this other source hCard. 2. This (authoritative) hCard is itself the most authoritative reference for this hCard. I don't get your point. Your arguement here assumes that we can figure out when two hCards refer to each other as related, which is the simpler problem I'd like to solve. So, let's look again at your proposal. Ryan King: Also, the algorithm for finding the most authoritative hCard: 1. if no uid or uid == the uid from the previous iteration/recursion = you're done 2. if url == uid and there's an hCard at that url, recurse with the new hCard This only works if you require that the uid be a URL. The standard currently allows any String as uid, stating only that it SHOULD be a URL. Publishers may want to use non-url UIDs as in the example above or they may want to use URL uids that are not intended to be authoritative. No, we don't have to require that the UID be a URL. The rule is only activated when the url is a uid (and equal to one of the URL fields of the hCard). People are still free to use non-URL UIDs, but they just don't get the benefit of being connected on the WWW. For example, a conference listing may have a bio page for an individual, use the URL of that bio page as the individual's uid with a conference-specific hCard, but support linking back to an authoritative
Re: [uf-discuss] authoritative hCards, a simpler proposl
On Feb 8, 2007, at 7:45 PM, Lachlan Hardy wrote:
Hi, Ryan
Thanks for summarising. It was getting confusing skipping around all
those threads
I want to address your points out of order, if I may. Firstly, just to
check that I have understood your proposal correctly
Also, the algorithm for finding the most authoritative hCard:
1. if no uid or uid == the uid from the previous iteration/recursion
= you're done
2. if url == uid and there's an hCard at that url, recurse with the
new hCard
To provide examples of my understanding of your proposal:
various hCards for Chris Messina (thanks for having so many hCards,
Chris!) at places such as ClaimID, blogrolls, conference sites etc
would read:
ClaimID:
a class=url uid fn href=http://factoryjoe.com/blog/hcard;Chris
Messina/a
or blog link to Some Conference:
a class=url uid fn
href=http://someconference.com/speakers/chrismessina;Chris
Messina/a
or link from Some Conference:
a class=url uid fn href=http://factoryjoe.com/blog/hcard;Chris
Messina/a
At each of these URLs it finds another hCard that leads on again, thus
identifying a series of related hCards. All of which are tied, by
virtue of the UID, to the value of the element (in this case, 'Chris
Messina')
Eventually, our parser ends up at factoryjoe.com/blog/hcard and finds
an hCard containing:
a class=url uid fn href=http://factoryjoe.com/blog/hcard;Chris
Messina/a
or
a class=url fn href=http://factoryjoe.com/blog/hcard;Chris
Messina/a
The self-referential nature of this link indicates that it is the
'authoritative' hCard.
Have I understood you correctly, Ryan?
I believe so.
I'd propose that the UID is still required at the final hCard, to
explicitly confirming that *this* URL is the definitive one for the
object of this hCard.
Or is an explicit reference superfluous given the implicit
confirmation of the self-referential URL?
You actually bring up a good point that I hadn't thought of yet.
I don't think we need a UID at the terminal hCard in order to
conclude that the hCards represent the same person/organization (or,
at least, their publishers think so).
However, the addition of UID at the terminal hCard may allow us to
conclude that it is authoritative.
My proposal is that we use UID+URL to hint that there's an hCard on
the other end of that URL which represents the same entity. Also,
multiple hCards with the same UID may be considered as representing
the same entity.
To move on, I get the feeling I'm missing something here. Your
proposal seems to me to suggest that we add UID to all URLs to that
indicate the presence of a related hCard (of another hCard which has
the same subject - either person or organisation)
I'd suggest that UID is initially unnecessary. FN+URL could provide
the same understanding - eg a unique combination within a hCard,
defining the subject of the hCard and providing a pointer to further
information
This is too brittle and lacks explicit semantics. I've actually build
a tool that tried to do cluster of hCards by FN+URL (based on data
from our search engine [http://kitchen.technorati.com/search/]), but
found a large number of false negatives. For example, if you linked
to by blog the link form the mf.org blog to my blog wouldn't work,
because the FN's are different ('Ryan' vs. 'Ryan King').
-ryan
--
Ryan King
[EMAIL PROTECTED]
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID URL to indicate (relatively) more authoritativehCard (Was: Vote on this: rel=me self to indicate anauthoritative hCard)
On Feb 9, 2007, at 12:31 AM, Sam Sethi wrote: Couldn't a class=uid url be your openid page? i.e http://samksethi.myopenid.com and this page contain my details in hCard? Certainly. It's just a web page! :D -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Vote on this: rel=me self to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
On Feb 7, 2007, at 2:56 PM, David Janes wrote: On 2/7/07, Ryan King [EMAIL PROTECTED] wrote: On Feb 7, 2007, at 12:50 PM, David Janes wrote: On 2/7/07, Ryan King [EMAIL PROTECTED] wrote: Yes there are several problems: 1. XFN applies to whole pages. This means that you can't reliably put different people's hCards on the same page and do this. 2. We have prior art that is being ignored. Publishers are already using a class=url uid ../a to do this. I apologize for being late to this discussion, but I think it's off track and we need to correct things a bit. Sure. Show us how it works with the original real-world case I provided -- i.e. your hCard on microformats.org blog, pointing to your home page, using your /contacts hcard as your authoritative hCard. On mf.org: address class=author vcarda class=url uid fn href=http:// theryanking.com/Ryan/a/address at http://theryanking.com/: address class=vcardThis site is the work of a href=http:// theryanking.com/blog/contact/#vcard class=fn uid urlRyan King/ a/address And at the end-point? (i.e. on /blog/contact). The reason I'm asking is what's the rule for determining if the hCard I'm looking at points to the authorative one. Both of these look the same. Nothing special is needed at /blog/contact/. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Vote on this: rel=me self to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
On Feb 8, 2007, at 11:02 AM, David Janes wrote: On 2/8/07, Ryan King [EMAIL PROTECTED] wrote: Nothing special is needed at /blog/contact/. But that's the authoritative hCard. What's the algorithm (or heuristic) that I follow if I'm a parser looking at the blog at microformats.org, see your partial hCard and try to find your authoritative hCard? Sorry if this sounds pedantic, I'm not trying to be. There's some assumption in what you're saying that I'm not getting. You're right, I haven't fully explained one of my assumptions. That assumption is that we should solve the simpler problem of 'related hcards' first, before we try to solve the problem of authoritative hcards. Secondly, using my proposal you might be able to sort out authoritative hCards by simply following the url+uid links back until you find an hcard that doesn't link to another with url+uid. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Vote on this: rel=me self to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
On Feb 8, 2007, at 12:00 PM, David Janes wrote: On 2/8/07, Ben Ward [EMAIL PROTECTED] wrote: On 8 Feb 2007, at 19:02, David Janes wrote: On 2/8/07, Ryan King [EMAIL PROTECTED] wrote: Nothing special is needed at /blog/contact/. -ryan But that's the authoritative hCard. […] Sorry if this sounds pedantic, I'm not trying to be. There's some assumption in what you're saying that I'm not getting. The difference in interpretation is this: You're looking to describe the *one true hcard*, to rule them all, bind them in the darkness and so on and so forth. No no no. I'm looking for the set of rules a consumer has to follow to get from Ryan's hCard on microformats.org to his authoritative hCard at *the*ryanking/contact. The algorithm is simple and recursive: 1. if uid != url you're done 2. if url == uid and there's an hCard at that url, recurse with the new hCard -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID URL to indicate (relatively) more authoritative hCard (Was: Vote on this: rel=me self to indicate an authoritative hCard)
On Feb 8, 2007, at 2:23 PM, David Janes wrote: On 2/8/07, Scott Reynen [EMAIL PROTECTED] wrote: So as I understand that, the rules for getting the most authoritative hCard for a given URL are: 1) parse hCard at current URL 2) If the hCard includes a class=uid url, load the URL in the href, and return to step 1. When the consumer gets to http://theryanking.com/blog/contact/#vcard and finds no a class=uid url, it stops there and that's his authoritative hCard. OK (and I'm not trying to turn into Andy here), but doesn't this feel at least a little unsatisfactory? That the authoritative hCard is the one that _doesn't_ have a UID, i.e. potentially has less information than a fragment hCard?! I just thought of another base case in the recursive algorithm if the uid of the current hcard equals that of the previous, you're done. I'm not killer against the idea or anything, but at least I think that should be brought up. I agree, what I'm proposing does less than what you proposed. But, I think we need to solve this simpler problem first. Here's one potential usage snag: - I copy the hCard at http://theryanking.com/blog/contact/#vcard to my address book - I use it somewhere (to refer to Ryan King) - It doesn't have a UID, so there's no tracing it back to source Sure, that would be unfortunate, but with the addition of the second base case (see above) it would be solved. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] VIA or VIA SELF to indicate authoritative hCard [was: UID URL to indicate (relatively) more authoritativehCard (Was: Vote on this: rel=me self to indicate anauthoritative hCard)]
On Feb 8, 2007, at 4:49 PM, Joe Andrieu wrote: Scott Reynen wrote: On Feb 8, 2007, at 4:29 PM, David Janes wrote: That the authoritative hCard is the one that _doesn't_ have a UID, i.e. potentially has less information than a fragment hCard?! I think this is how authority generally works in practice, from external references. Scott, Actually, I think that's quite contradicted by evidence in the wild, especially in the offline world. Birth certificates, passports, driver's licenses, etc., have indicia asserting their authority. I had previously voted for rel=self me, but the symmetry of that is more of a low-security technique to establish mutually endorsed validity. Interesting, but only partially useful. As explained previously, rel=me can't help us here, because it applies to the entire page, not a part of a page. That means that it can't be used in places like my staff hCard at technorati: http:// technorati.com/about/staff.html#ryan_king, because there are many hCards on that page. I'd like to reintroduce @rel=via to the conversation[1]: 5. The value via signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element. Why not just have a via point to source hCards and any hCard that is self-referential is authoritative? The simple answer is that we may already have a mechanism in hCard/ vCard which is sufficient (ie, UID). We should only look to add things if there is nothing already in the format which is sufficient. That seems both easy for publishers and relatively straightforward for parsers. Keep dereferencing @rel=via attributes until you find one that dereferences to itself with @rel=via self. Once you get to one that says I'm my own source, you've got a reasonable assertion of authority. It appears to me that this is essentially the same algorithm as the url+uid proposal, but with adding new terms. Ryan Cannon suggested this previously [2], but it seemed to get lost in uid url conversations. The problem, IMO, with uid url is that the uid for a book, for example, is more likely an ISBN rather than a URL, so it wouldn't necessarily be a URI. Allowing both an ISBN uid and a via link allows parsers that aware of ISBN to do smart things (such as link to Amazon if they wish) /or/ follow the via tag for the author's source reference. I'm not sure how this is relevant. We're talking about hCard here, not a citation format. Also, the url+uid proposal only concerns the case where the url and uid are the same (and, therefore, a URL). -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] authoritative hCards, a simpler proposl
I apologize for being semi-away for awhile. Catching up in the last few days, I find that there are some probelems with the authoritative hcards proposals. I've already spoken up a bit, but I want to delineate my perspective and outline in full my counter-proposal. First, the problems: Problem 1: Not tackling the simplest problem first. Before solving the problem of 'canonical' or 'authoritative' hCards, we should solve the problem of 'hcards representing the same person'. Before you can have trust you need identity. Problem 2: Not understanding the scope of XFN. XFN links apply to entire pages, not parts of pages. This means that using XFN links inside multiple hCards on the same page is not possible. Therefore, while using XFN's identity consolidation to consolidate hCards is useful (and can be used regardless of any other mechanisms), it is not sufficient, as it does not allow for the case of multiple hCards on a page, nor does it work for Organizations, only people. Problem 3: No analysis of prior art. Publishers have been using the UID property of hCard to signal another hCard for this one. The hypothesis that's being tested is that using URL and UID on the same URL is sufficient for being able to connect hCards that represent the same entity. (As a sidenote, I find that documentation of this experiment is hard to come by.) Problem 4: Not reusing within the format in question. Reusing properties from other microformats is great and certainly a design goal. However, first we must look within a given format to see if there's a property that can solve our problem. Ok, enough of the negative stuff, on to a proposal. My proposal is that we use UID+URL to hint that there's an hCard on the other end of that URL which represents the same entity. Also, multiple hCards with the same UID may be considered as representing the same entity. Note that eventful.com is already using this. From http:// eventful.com/events/E0-001-002585347-7: div class=location vcard a rel=bookmark class=url uid fn org href=/venues/ V0-001-000212939-9Pacific Science Center/a div class=adr span class=street-address200 Second Ave. N/spanbr / span class=localitySeattle/span, span class=regionWashington/span span class=postal-code98109/spanbr / span class=country-nameUnited States/span /div div class=geo abbr class=latitude title=47.583947.5839/abbr abbr class=longitude title=-122.052-122.052/abbr /div ... Notice that in the vcard for this location (within an hCalendar event), they link to the page for that venue (which contains another hCard for that venue). I propose that this is a simpler solution which will work better. Also, the algorithm for finding the most authoritative hCard: 1. if no uid or uid == the uid from the previous iteration/recursion = you're done 2. if url == uid and there's an hCard at that url, recurse with the new hCard A similar algorithm could be used to find all related hCards in the network, but only if you have access to a database of backlinks. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Authenticity of Authoritative hCard (was: Re: Vote on this: rel=me self to indicate an authoritative hCard)
On Jan 31, 2007, at 8:41 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Ara Pehlivanian [EMAIL PROTECTED] writes what if someone registers ben-ward.net and puts up a fake card on that site. Perhaps we need a class=pgp-public-key property for hCard? There's already a KEY field in vCard. From RFC2624: Type purpose: To specify a public key or authentication certificate associated with the object that the vCard represents. I'm sure we could make this work. :D -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Should microformat features (like rel-tag) have explicit scope?
On Jan 31, 2007, at 7:07 PM, Derrick Lyndon Pallas wrote: If I have a parser that only knows (and only cares about) the rel- tag format, it will be confused by people that use rel-tag for the category property in hCard. It seems unreasonable that every microformat should have to know about every other microformat, especially when they are nested. Actually I think it *is* quite reasonable to make parsers know about every microformat. Microformats are designed to be easy to publish, even when that means that they're hard to parse. Simple economics show that it's much more valuable to make publishing low-cost, because the increased in published data will allow you to amortize the cost of writing and maintaining parsers across more transactions. Also, microformats are not designed to be generic or open ended, but specific solutions to specific problems. Requiring authors to add markup in order to make rel-tag's scope explicit makes it hard to publish the data and doesn't solve any real problem. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]
Sorry, I'm way behind on this thread. I wish I weren't but there's nothing I can do about that now... On Jan 29, 2007, at 5:50 PM, John Allsopp wrote: Ben, For my money, John Allsopp's idea to reuse rel=bookmark self [1] makes most sense. As well as being gorgeously consistent with other existing microformats, it's also a completely graceful addition to existing hCards. thanks ;-) There's a lot of goodness to reuse from other ufs, for sure. Right, but there's also a lot of use to reusing things from the present microformat (hCard). vCard has a property called UID, which is defined as: Type purpose: To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. This is actually already in use by several large microformat publisher (eventful.com) to between venues in their events and the hCards for those events. It's been proposed before that using URL and UID together is sufficient for the things we're trying to solve here (I'm having trouble finding a reference in the archives). -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]
On Jan 30, 2007, at 2:28 PM, John Allsopp wrote: Chris, (all the following simply thoughts in the spirit of brainstorming, rather than any particular argument in favour of my original suggestion) I pretty much came up with a very similar proposal for handling this issue, though from the standpoint of XFN-links, and I think that John's suggestion is very good, though instead of using bookmark self might suggest me self for identifying the One True Hcard: div class=vcard id=vcard addressa href=http://factoryjoe.com/blog/hcard/#hcard; class=fn url rel=me selfChris Messina/a/address div class=orgCitizen Agency/a ... /div I wonder whether hAtom had predated XFN, self instead of me would have been chosen for the identity value? The definition of the self attribute value in Atom is self: the feed itself. The term the seems to indicate definitiveness. So, I was initially going to argue that self me was tautological, but in fact, in this sense it is not, and indeed, the addition of bookmark is probably tautological. Right, 'self' implies singular and is supposed to signal the URI (or IRI) for the feed itself, not an alternative representation or related resource elsewhere. 'me' just means another resource that represents the same person. So, I'd probably +1 this suggestion, and perhaps also suggest that for hReview simply a rel value of self be required for the permalink, for consistency. rel=bookmark is in HTML4, there's no reason to ignore it. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On Feb 2, 2007, at 2:57 PM, Ara Pehlivanian wrote: On 2/1/07, John Allsopp [EMAIL PROTECTED] wrote: use case - sure - for example, at our conference sites, we markup speakers with hCard, and this often includes a link to their blog etc. In this case, a link to an authoritative (or perhaps, to be even less strict detailed) hCard may be somethign that is very useful. If I understand the spec correctly, since a rel=me is symmetric, shouldn't the hCard you're pointing to also be pointing back? If that's true, then the authoritative hCard will quickly get unmanageable since it will contain tens if not hundreds of reciprocal links to partial hCards (imagine if you're listed in several different locale directories marked up with hCard). You're right, rel=me requires symmetry in order to be trusted at all. For this reason, and others XFN is not the simplest way to do Authoritative hCards. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Vote on this: rel=me self to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
On Jan 30, 2007, at 4:06 PM, Ben Ward wrote: Chris Messina: div class=vcard id=vcard addressa href=http://factoryjoe.com/blog/hcard/#hcard; class=fn url rel=me selfChris Messina/a/address div class=orgCitizen Agency/a ... /div John Allsopp: The definition of the self attribute value in Atom is self: the feed itself. The term the seems to indicate definitiveness. So, I was initially going to argue that self me was tautological, but in fact, in this sense it is not, and indeed, the addition of bookmark is probably tautological. So, I'd probably +1 this suggestion, […] +1 from me as well. Can we gauge wider support for this addition? Any problems from anyone? Yes there are several problems: 1. XFN applies to whole pages. This means that you can't reliably put different people's hCards on the same page and do this. 2. We have prior art that is being ignored. Publishers are already using a class=url uid ../a to do this. I apologize for being late to this discussion, but I think it's off track and we need to correct things a bit. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Authoritative hCards
On Feb 7, 2007, at 12:00 PM, Edward O'Connor wrote: Ryan wrote: Right, but there's also a lot of use to reusing things from the present microformat (hCard). vCard has a property called UID, which is defined as: Type purpose: To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. This is actually already in use by several large microformat publisher (eventful.com) to between venues in their events and the hCards for those events. It's been proposed before that using URL and UID together is sufficient for the things we're trying to solve here (I'm having trouble finding a reference in the archives). some-element class=vcard ... a rel=me url uid ... This feels right to me. Also, from an OpenID perspective, rel=uid in an hcard sounds an awful lot like this is my id. uid goes on @class, not rel. It doesn't have to be on an anchor, nor must it be a URL. [And yes, we (eventful.com) use rel=url uid to point from a venue hcard in an event entry to the venue's own (authoritative) page.] Actually you use @class. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] New new mailing list
Ok, after much feedback, deliberation and procrastination, we've started a new mailing list, microformats-new[1] for developing new microformats. One of the goals is to keep this list (microformats-discuss) focused on practical matters for people working with microformats. Though who wish to research and discuss possible new microformats should take those discussions to microformats-new. Thanks, ryan 1. http://microformats.org/discuss/#new -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Vote on this: rel=me self to indicate an authoritative hCard
On Feb 7, 2007, at 1:59 PM, Edward O'Connor wrote: However, UID is not a field that takes a URL for its value, just a string, so therefore: Perhaps this is addressed in [1] or [2]? 1. http://microformats.org/wiki/uid-brainstorming 2. http://microformats.org/discuss/mail/microformats-discuss/2006- April/003726.html (See also the rest of the thread) Indeed. I was trying to find those references, but failed. Thanks. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Vote on this: rel=me self to indicate an authoritative hCard {was: Re: [uf-discuss] Authoritative hCards [was RE: Canonical hCards (was: Search on CSS element)]}
On Feb 7, 2007, at 12:50 PM, David Janes wrote: On 2/7/07, Ryan King [EMAIL PROTECTED] wrote: Yes there are several problems: 1. XFN applies to whole pages. This means that you can't reliably put different people's hCards on the same page and do this. 2. We have prior art that is being ignored. Publishers are already using a class=url uid ../a to do this. I apologize for being late to this discussion, but I think it's off track and we need to correct things a bit. Sure. Show us how it works with the original real-world case I provided -- i.e. your hCard on microformats.org blog, pointing to your home page, using your /contacts hcard as your authoritative hCard. On mf.org: address class=author vcarda class=url uid fn href=http:// theryanking.com/Ryan/a/address at http://theryanking.com/: address class=vcardThis site is the work of a href=http:// theryanking.com/blog/contact/#vcard class=fn uid urlRyan King/ a/address -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Vote on this: rel=me self to indicate an authoritative hCard
On Feb 7, 2007, at 1:44 PM, Ryan Cannon wrote: On Feb 7, 2007, Ryan King wrote: 2. We have prior art that is being ignored. Publishers are already using a class=url uid ../a to do this. However, UID is not a field that takes a URL for its value, just a string, so therefore: a class=url uid href=http://ryancannon.com/;Ryan/a Should be parsed as URL: http;//ryancannon.com/ UID: Ryan Right? So while UID seems like the right value to use, according to my reading of the spec, UID has to sit in visible text, and could be any sort of number--like an American social security number or a mobile phone number with country code--both of those are usually globally unique individual identifiers. Indeed, in vcard UID is just a string, but my proposal is that we make it by default a URL. It's a simple change (which may already be implemented in X2V). -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XFN Test Data
On Feb 5, 2007, at 7:22 PM, Steve Ivy wrote: Hi folks, While working on figuring out how to help add XFN support to mofo (http://mofo.rubyforge.org/), I found it useful to create a page with test data for XFN. http://deliciouslymeta.com/projects/xfn/test_data.html First of all, this is probably better discussed on microformats-dev, where we have ongoing discussion about and work on a complete test suite. Looks cool. This page contains links with all the profile relationships (per http://gpmg.org/xfn/11), most if not all of the two-component combinations, and most if not all of the invalid two-component combinations. Please looks it over and let me know if it's reasonably complete. I tried to keep compound relationship in the realm of reality so there may be some technical gaps. Let me know how this data set should evolve. It looks rather complete, would you consider including it the general test suite? If so, let's head over to microformats-dev and discuss how to incorporate it. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
