Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
Tantek wrote: The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. +1 I absolutely think that IDs make referencing easier but I'm thinking more about IDs on the elements *containing* the hCard(s) rather than on the hCard itself. I've been working on a JavaScript hCard/GoogleMaps mashup (building on what I did for http://austin.adactio.com/) with the aim of releasing it for anybody to use on their site (the more tools that encourage people to use microformats, the better). I want it to be modular so that people can have more than one map per page. To do this, the script currently takes a single required argument: the ID of a containing element for a series of hCards. Here's a working demo of what I've got so far: http://2006.dconstruct.org/location/ The JavaScript is here: http://2006.dconstruct.org/scripts/map.js Unfortunately, it isn't quite as simple as add this script tag to your document for anybody to use this: the Google Maps API demands that each domain has their own API key so anyone who would want to use this would have to go off to Google first (register if they don't yet have an account), and request an API key. That's a few too many hoops to jump through. :-( But anyway, back to the topic at hand... When you mark up people/companies as hCards or hCalendar events or hReviews, along with other things on a single page, try using an id attribute on the root element (the element with class=vcard etc.) and report back how ti works with you. If this works for folks, I'll add it to hcard-authoring as a recommended good practice. Regardless of my wish for an ID on the über-element containing the hCards/hCalendars/hReviews, the idea of associating unique a ID with a specific microformat chunk sounds like a good one to me. If a convention arose for people to mark up their own hCard with something like id=author or id=me, then it would be easier for people to build/use tools to extract just that single hCard, leaving any others on the page alone if desired. Perhaps this is something that could also be recommended as a best practice... if enough people start doing it, that is. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On 23 Jun 2006, at 09:52, Jeremy Keith wrote: Tantek wrote: The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. +1 I absolutely think that IDs make referencing easier but I'm thinking more about IDs on the elements *containing* the hCard(s) rather than on the hCard itself. I'm slightly wary of any pattern that prescribes doing anything outside the root element of a given µF. context. One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div Granted, there's danger of the concept duplicating problems already solved by either XFN, or by intrinsic groupings already created by the values within the hCards themselves. Most groupings I imagine are based on location, companies, or XFN properties like friends, collegues, family. I think we'd also need to see more real-world examples to demonstrate a need for something like this. I guess two examples would be your d.Construct Locations page, where groups are travel, accomadation, freewifi, etc, and the LPG site I did the other week where all my hCards were gas stations, and would be sensible to group as such. It gets more complex with the d.Construct case, though, where you'd actually want to group everything overall into one 'dconstruct' group too. e.g. div class=vcard travel dconstruct div class=fn orgBrighton Train Station/div /div The above would belong to the travel group and the dconstruct group. I'm not sure how a parser would know how those should be nested, however. (Does each of travel, accomodation, freewifi contain a dconstruct group, or does the dconstruct group contain the others?). So you'd need rules about group name exclusivity .. and all in all I think I've talked myself out of the idea ;) drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On 6/23/06, Drew McLellan [EMAIL PROTECTED] wrote: One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div I think it's only logical. However, using IDs is what gives the capability to address a specific microformat content outside of the context of the document (URL, in less fancy words). How would one use classes to do the same? :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On 23 Jun 2006, at 11:51, Dimitri Glazkov wrote: On 6/23/06, Drew McLellan [EMAIL PROTECTED] wrote: One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div I think it's only logical. However, using IDs is what gives the capability to address a specific microformat content outside of the context of the document (URL, in less fancy words). How would one use classes to do the same? Oh, it wouldn't. I was thinking more along the lines of Jeremy's idea of addressing a group of hCards. As for addressing an specific hCard from outside the document, then indeed, we just need a small set of ID conventions. An ID must be unique in a document of course, so these should be namespaced in some way, so as not to force publishers to rework existing documents. e.g. 'author-vcard', not just 'author'. The only requirement on parsers then should be fragment support, which is already a requirement. drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats Community Mark
Today on IRC[1], we talked briefly about the Microformats Logo and how it is setup to be a Community Mark. Tantek pointed to Chris Messina's original post about the idea of a community mark[2]. I really do like the idea, it fits nicely with everything that we are doing here as a community, but i do have some reservations and questions. Hopefully, as a community we can help clarify what a community mark (cm) really is? I also know Microformats are very much against Theoretical situations, so i'll try and ground this in the real world as much as possible! Back in March, i had a suggestion for a Microformat style T-Shirt[3] I really like it, but i'm biased. Now since the logo is a community mark, I would need to ask the community's approval to use the logo and put it on a shirt and possibly sell it on my own Microformats store. Questions: 1) What constitutes a community consensus, if I ask the list and 5 people respond saying, sure go ahead, is that enough? 2) Can it be revoked? If my shirt sells like wild-fire and and the other microformats store[4] gets mad, can my usage be revoked? 3) what about projects that can not be disclosed? Pingerati.net[5] has a big Microformats logo on it, Technorati didn't ask the community (i'm sure it would have been OK) but if they had asked, the description of usage would have either been vague or they would have to give away the surprise of what they were working on. I've shared apartments with people before and we had similar community agreements, you can eat my food, use my stuff, just ask, or just give back - and that works really well, until someone says we you let me use it last week... (we all know how it starts, and we all know how it ends!) I ask these question not because I want this to fail, but because I want it to succeed. -brian [1] - http://rbach.priv.at/Microformats-IRC/2006-06-23#T002652 [2] - http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ [3] - http://flickr.com/photos/factoryjoe/117364751/ [4] - http://www.goodstorm.com/stores/factorycity [5] - http://pingerati.net/ Tantek Çelik wrote: On 6/22/06 5:13 PM, Rémi Prévost [EMAIL PROTECTED] wrote: Hello all, I made a (very simple) wallpaper[1] for promoting microformats. I didn't make it available on my website yet because I wanted to know if using the microformats logo is ok because I didn't find the license which it released under. Thank you, [1]: As seen on http://www.flickr.com/photos/remiprev/171676336 Hi Rémi, Nice wallpaper. The current proposal is to make the microformats logo a CommunityMark(cm) just like BarCamp(cm). http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ Thus ask the community if your use is proper or not, and see what people say. I for one like your wallpaper, and suggest that you share it under a creative commons license. ;) Thanks, Tantek ___ 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] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
At first look i really like this idea, but then i though about it for a minute You are adding 'brighton' into the class attribute, which violates the human readable aspect of Microformats. This would be better... div class=vcard span class=fnJeremy Keith/span in span class=groupBrighton/span /div in hCard there already is a property for grouping, class=category so you could use div class=vcard span class=fnJeremy Keith/span in span class=categoryBrighton/span /div or even a class=category rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a Then you could begin to make a distributed web-sized group. It is slightly more difficult for a parser to find a class=category, then look up the tree and see if it is a child of class=vcard rather than putting them both on the root-element. The other downside to adding semantics outside of the scope of hCard, is that it is impossible to determine if it is a CSS style or a semantic attribute. div class=vcard brighton call-out-box.../div is call-out-box also a group or a style? I would recommend looking into using the category property for groups. -brian Drew McLellan wrote: I'm slightly wary of any pattern that prescribes doing anything outside the root element of a given µF. context. One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div Granted, there's danger of the concept duplicating problems already solved by either XFN, or by intrinsic groupings already created by the values within the hCards themselves. Most groupings I imagine are based on location, companies, or XFN properties like friends, collegues, family. I think we'd also need to see more real-world examples to demonstrate a need for something like this. I guess two examples would be your d.Construct Locations page, where groups are travel, accomadation, freewifi, etc, and the LPG site I did the other week where all my hCards were gas stations, and would be sensible to group as such. It gets more complex with the d.Construct case, though, where you'd actually want to group everything overall into one 'dconstruct' group too. e.g. div class=vcard travel dconstruct div class=fn orgBrighton Train Station/div /div The above would belong to the travel group and the dconstruct group. I'm not sure how a parser would know how those should be nested, however. (Does each of travel, accomodation, freewifi contain a dconstruct group, or does the dconstruct group contain the others?). So you'd need rules about group name exclusivity .. and all in all I think I've talked myself out of the idea ;) drew. ___ 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] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
I tend to agree with Brian's assessment. Categories/tags are the best way to do named groups of things, and that works across microformats as well (in case you wanted to group Brighton people and Brighton events and reviews of Brighton related things). I would recommend using Tags to be even more specific than just the plain string, as Brian suggests as an alternative. div class=vcard span class=fnJeremy Keith/span in a class=category rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a /div Not that it is ambiguous at all in this case, but in general using rel-tag tags/categories provides a much better specificity, and provides a nice UI hook for what did the author *mean* by Brighton? (Imagine distinguishing Paris, France vs. Paris, Texas for example). And in this case, it wouldn't hurt to mark it up as the locality as well. div class=vcard span class=fnJeremy Keith/span in span class=adr a class=category locality rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a /span /div This definitely sounds like a good candidate for hcard-authoring in a how to collect hCards into groups or sets section. Tantek On 6/23/06 7:41 AM, brian suda [EMAIL PROTECTED] wrote: At first look i really like this idea, but then i though about it for a minute You are adding 'brighton' into the class attribute, which violates the human readable aspect of Microformats. This would be better... div class=vcard span class=fnJeremy Keith/span in span class=groupBrighton/span /div in hCard there already is a property for grouping, class=category so you could use div class=vcard span class=fnJeremy Keith/span in span class=categoryBrighton/span /div or even a class=category rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a Then you could begin to make a distributed web-sized group. It is slightly more difficult for a parser to find a class=category, then look up the tree and see if it is a child of class=vcard rather than putting them both on the root-element. The other downside to adding semantics outside of the scope of hCard, is that it is impossible to determine if it is a CSS style or a semantic attribute. div class=vcard brighton call-out-box.../div is call-out-box also a group or a style? I would recommend looking into using the category property for groups. -brian Drew McLellan wrote: I'm slightly wary of any pattern that prescribes doing anything outside the root element of a given µF. context. One proposal would be to introduce a very simple pattern for groups of hCards - just like groups in address book programs (friends, family, collegues etc). In XHTML we already have a mechanism of grouping elements - the class attribute. So how about treating hCards that share a common class name other than 'vcard' as a loose group? div class=vcard brighton div class=fnJeremy Keith/div /div div class=vcard brighton div class=fnAndy Budd/div /div div class=vcard div class=fnDrew McLellan/div /div Granted, there's danger of the concept duplicating problems already solved by either XFN, or by intrinsic groupings already created by the values within the hCards themselves. Most groupings I imagine are based on location, companies, or XFN properties like friends, collegues, family. I think we'd also need to see more real-world examples to demonstrate a need for something like this. I guess two examples would be your d.Construct Locations page, where groups are travel, accomadation, freewifi, etc, and the LPG site I did the other week where all my hCards were gas stations, and would be sensible to group as such. It gets more complex with the d.Construct case, though, where you'd actually want to group everything overall into one 'dconstruct' group too. e.g. div class=vcard travel dconstruct div class=fn orgBrighton Train Station/div /div The above would belong to the travel group and the dconstruct group. I'm not sure how a parser would know how those should be nested, however. (Does each of travel, accomodation, freewifi contain a dconstruct group, or does the dconstruct group contain the others?). So you'd need rules about group name exclusivity .. and all in all I think I've talked myself out of the idea ;) drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
Tantek wrote: Not that it is ambiguous at all in this case, but in general using rel-tag tags/categories provides a much better specificity, and provides a nice UI hook for what did the author *mean* by Brighton? (Imagine distinguishing Paris, France vs. Paris, Texas for example). And in this case, it wouldn't hurt to mark it up as the locality as well. div class=vcard span class=fnJeremy Keith/span in span class=adr a class=category locality rel=tag href=http://en.wikipedia.org/wiki/Brighton;Brighton/a /span /div That looks a good solution. Leaving aside the reltag, the category solution could still be used with a unique identifier for the document: div class=vcard span class=fnJeremy Keith/span in span class=adr a class=category locality href=#brightonBrighton/a /span /div Here, the category is pointing to a part of the current document that has been uniquely identified with id = brighton. This wouldn't be a good candidate for a reltag (it would create a circular reference), but it would solve the problem of grouping together many hcards into different groups on a single document... thereby paving the way for parsers to extract just the hcards for people in a particular category. Bye, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTTP profile header proposal
On Jun 23, 2006, at 11:58 AM, Scott Reynen wrote: Via Danny Ayers' blog [1], Mark Nottingham's proposal to add profiles to HTTP headers seems very relevant to microformats: http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header -00.txt It would allow for HEAD requests to identify pages containing microformats without downloading the full document. Peace, Scott [1] http://dannyayers.com/2006/06/23/return-of-the-http the question remains with all profile discussion -- does their lack of accuracy overcome their usefulness how does a blog package (as an example) know if there is a hreview or hcalendar data in one of the individual blog postd displayed on a given page to accurately represent what profiles are to be used / sent in the headers? Failing the ability to do just that, do you ignore profile inclusion or just include all profiles all the time? sorry for not adding anything new to the discussion, just felt the desire to re-present the question. -- [ Chris Casciano ] [ [EMAIL PROTECTED] ] [ http://placenamehere.com ] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
