From info at weborganics.co.uk Wed Mar 5 12:53:13 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed Mar 5 13:19:37 2008 Subject: [uf-new] hAudio Title possible alternative? Message-ID: <1204750393.19077.14.camel@weborganicscouk> Hello All This is an effort to help restart the stalled discussion on the hAudio title issue http://microformats.org/discuss/mail/microformats-new/2008-February/001532.html I have been spending some time lately on the audio info examples page asking How Many of the examples use the word "Title" to mean an audio title ? http://microformats.org/wiki/audio-info-examples the results are enlightening Out of 54 working examples 20 use the word or have the word Title in markup 37% 34 use just song, track or nothing in markup 63% There Is No clear 80/20 result, The action may be at this point to choose what would seem to be second best and choose "title" but 63% of the examples are doing something else, In most cases nothing meaningful just giving names. I would like to Recommend use "NAME" instead of title as this seems to be what the majority of the examples are doing simply naming the objects. dfn name "1, A word or words by which an entity is designated and distinguished from others." http://www.answers.com/name&r=67 Name "A name is a label for a human or animal, thing, place, product (as in a brand name) and even an idea or concept, normally used to distinguish one from another. Names can identify a class or category of things, or a single thing, either uniquely, or within a given context." http://en.wikipedia.org/wiki/Name hAudio From info at weborganics.co.uk Wed Mar 5 13:49:29 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed Mar 5 13:49:41 2008 Subject: [uf-new] hAudio Title Possible Alternative? Message-ID: <1204753770.19185.46.camel@weborganicscouk> Hello All This is to try and help the stalled hAudio Title Issue http://microformats.org/discuss/mail/microformats-new/2008-February/001532.html hAudio title is an Issue because its meaning is not the same as the hcard definition a "job title" unless the title attribute in haudio means "Job title" we cant use it because microformats describe single precise instances and do not have the ability to disambiguate... there are probably more reasons but the above is a good reason why a solution should be found, the development and adoption of the haudio microformat can not realistically continue until this issue is resolved. So I have been spending some time recently studying the audio info examples pages asking How Many of the examples use the word "Title" to mean an audio title? we want to call this thing "title" lets find some hard evidence? http://microformats.org/wiki/audio-info-examples Out of 54 working examples 20 use the word or have the word Title in markup 37% 34 use just song, track or nothing in markup 63% As you can see there is no clear cut 80/20 result, so the action may be at this point to choose what would seem to be second best and choose "title" but 63% of the examples are doing something else, In most cases nothing meaningful just naming things. Alternative use "NAME" instead of "TITLE" as this seems to be what the majority of the examples are doing simply naming the objects. name http://www.answers.com/name&r=67 "1, A word or words by which an entity is designated and distinguished from others." good... Name http://en.wikipedia.org/wiki/Name "A name is a label for a human or animal, thing, place, product (as in a brand name) and even an idea or concept, normally used to distinguish one from another. Names can identify a class or category of things, or a single thing, either uniquely, or within a given context." better... possible microformats definition name - A label for the object or thing, contents are a short textual description of the object or thing. hmm! ...that's just my deffinition :) I have dumped all my notes on why "name" may be more desirable than "title" in a single text file which may make interesting reading http://tinyurl.com/yt7g4u Its interesting to add that a "name" microformat may enhance the "n" definition on http://microformats.org/wiki/existing-classes where it says "The name of the unit" name can be hyperlinked to the "name" definition of "A short textual description of the object or thing" I dont know if any of the above helps, It may even muddy the waters more comments feedback would be nice. Thanks all Martin McEvoy From info at weborganics.co.uk Wed Mar 5 13:54:49 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed Mar 5 13:55:10 2008 Subject: [uf-new] Re: hAudio Title possible alternative? In-Reply-To: <1204750393.19077.14.camel@weborganicscouk> References: <1204750393.19077.14.camel@weborganicscouk> Message-ID: <1204754089.19185.50.camel@weborganicscouk> On Wed, 2008-03-05 at 20:53 +0000, Martin McEvoy wrote: > Hello All > > This is an effort to help restart the stalled discussion on the hAudio > title issue > http://microformats.org/discuss/mail/microformats-new/2008-February/001532.html > > I have been spending some time lately on the audio info examples page > asking How Many of the examples use the word "Title" to mean an audio > title ? > http://microformats.org/wiki/audio-info-examples > > the results are enlightening > > Out of 54 working examples > 20 use the word or have the word Title in markup 37% > 34 use just song, track or nothing in markup 63% > > There Is No clear 80/20 result, The action may be at this point to > choose what would seem to be second best and choose "title" but 63% of > the examples are doing something else, In most cases nothing meaningful > just giving names. > > I would like to Recommend use "NAME" instead of title as this seems to > be what the majority of the examples are doing simply naming the > objects. > > dfn > > name > > "1, A word or words by which an entity is designated and distinguished > from others." > http://www.answers.com/name&r=67 > > Name > > "A name is a label for a human or animal, thing, place, product (as in a > brand name) and even an idea or concept, normally used to distinguish > one from another. Names can identify a class or category of things, or a > single thing, either uniquely, or within a given context." > http://en.wikipedia.org/wiki/Name > > > hAudio Sorry about this part email my email client went a bit nuts, I thought I had lost this email and did it again but apparently it sent why I don't no but sorry all anyway please disregard my above. Thanks Martin From csarven at gmail.com Wed Mar 5 14:06:12 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Wed Mar 5 14:06:17 2008 Subject: [uf-new] hAudio Title Possible Alternative? In-Reply-To: <1204753770.19185.46.camel@weborganicscouk> References: <1204753770.19185.46.camel@weborganicscouk> Message-ID: NAME appears to be a better solution then TITLE, FN, or something along the lines of a prefixed "object class term" (e.g., AUDIO-TITLE). * No conflicts with hCard (since this was one of the issues we had previously) * No prefixes or the whole namespace dilemmas. * Reusable for other media type formats (e.g., video title) and objects. Based on the definitions of "name", NAME would be appropriate to *distinguish* one object from another. Is this in any way create a conflict (perhaps a misconception) if the hAudio object were to contain multiple NAMEs? (re: http://microformats.org/wiki/haudio-cheatsheet#Properties states that TITLE may occur more than once). Hope that made sense. -Sarven On Wed, Mar 5, 2008 at 4:49 PM, Martin McEvoy wrote: > Hello All > > This is to try and help the stalled hAudio Title Issue > http://microformats.org/discuss/mail/microformats-new/2008-February/001532.html > > hAudio title is an Issue because its meaning is not the same as the > hcard definition a "job title" unless the title attribute in haudio > means "Job title" we cant use it because microformats describe single > precise instances and do not have the ability to disambiguate... there > are probably more reasons but the above is a good reason why a solution > should be found, the development and adoption of the haudio microformat > can not realistically continue until this issue is resolved. > > So I have been spending some time recently studying the audio info > examples pages asking How Many of the examples use the word "Title" to > mean an audio title? we want to call this thing "title" lets find some > hard evidence? > http://microformats.org/wiki/audio-info-examples > > Out of 54 working examples > 20 use the word or have the word Title in markup 37% > 34 use just song, track or nothing in markup 63% > > As you can see there is no clear cut 80/20 result, so the action may be > at this point to choose what would seem to be second best and choose > "title" but 63% of the examples are doing something else, In most cases > nothing meaningful just naming things. > > Alternative use "NAME" instead of "TITLE" as this seems to be what the > majority of the examples are doing simply naming the objects. > > name http://www.answers.com/name&r=67 > "1, A word or words by which an entity is designated and distinguished > from others." > > good... > > Name http://en.wikipedia.org/wiki/Name > "A name is a label for a human or animal, thing, place, product (as in a > brand name) and even an idea or concept, normally used to distinguish > one from another. Names can identify a class or category of things, or a > single thing, either uniquely, or within a given context." > > better... > > possible microformats definition > > name - A label for the object or thing, contents are a short textual > description of the object or thing. > > hmm! ...that's just my deffinition :) > > I have dumped all my notes on why "name" may be more desirable than > "title" in a single text file which may make interesting reading > > http://tinyurl.com/yt7g4u > > Its interesting to add that a "name" microformat may enhance the "n" > definition on http://microformats.org/wiki/existing-classes > where it says "The name of the unit" name can be hyperlinked to the > "name" definition of "A short textual description of the object or > thing" > > I dont know if any of the above helps, It may even muddy the waters more > comments feedback would be nice. > > Thanks all > > Martin McEvoy > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From info at weborganics.co.uk Wed Mar 5 14:45:54 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed Mar 5 14:46:05 2008 Subject: [uf-new] hAudio Title Possible Alternative? In-Reply-To: References: <1204753770.19185.46.camel@weborganicscouk> Message-ID: <1204757154.19928.16.camel@weborganicscouk> Hello Sarven On Wed, 2008-03-05 at 17:06 -0500, Sarven Capadisli wrote: > Is this in any way create a > conflict (perhaps a misconception) if the hAudio object were to > contain multiple NAMEs? (re: > http://microformats.org/wiki/haudio-cheatsheet#Properties states that > TITLE may occur more than once). > > Hope that made sense. I think so :) Will "this in any way create a conflict (perhaps a misconception) if the hAudio object were to contain multiple NAMEs?" I do not think it will at least not as many problems as "Title" does, If we take the definition of "name" to be a short textual description of the object or thing I think It would be the same in both contexts? Thanks Martin McEvoy From geraldbauer2007 at gmail.com Sun Mar 9 19:29:48 2008 From: geraldbauer2007 at gmail.com (Gerald Bauer) Date: Sun Mar 9 19:29:50 2008 Subject: [uf-new] Microformats for Slide Show/Presentations - hShow, hSlide - State-of-the-Art? Message-ID: <7e7cb8940803092029q9673475w783a6357f72321fa@mail.gmail.com> Hello, I've recently developed a Ruby gem called - surprise, surprise - Slide Show (S9) [1] - that's a free alternative to PowerPoint and KeyNote and let's you create slide shows and author slides in plain text using a wiki-style markup language that's easy-to-write and easy-to-read. Anyways, the HTML generated by the Ruby gem is compatible with the Opera Show Format and the FullerScreen Firefox Addon and close but not yet compatible with S5. Over the next couple of weeks I plan to document the format used by Slide Show (S9) and, thus, I wonder if anyone else is working on a Microformat for slide shows/presentations such as hShow, hSlide or similar. Any points to existing work is appreciated. For some ideas about the Microformat here's a basic structure proposal using semantic markup: presentation ( layout ( footer, header, background ), slide ( step*, notes )* ) Cheers. [1] http://slideshow.rubyforge.org -- Gerald Bauer - Internet Professional - http://geraldbauer.wordpress.com From davidjanes at blogmatrix.com Wed Mar 12 07:58:23 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Wed Mar 12 07:58:30 2008 Subject: [uf-new] Multi-paged XFN Message-ID: <21e523c20803120858x53971e4dk2da3c9558104e054@mail.gmail.com> I'm just tossing an idea out for discussion (and to get it out of my head). I've been looking recently at XFN as it's used "in the wild" as a method of social network portability, or as Chris has probably more correctly relabeled it, "portable contact lists" [1]. In several cases, for example here [2]. Obviously this is a requirement to make this _human usable_ but unfortunately without further assistance an XFN parser is only going to get a fraction of the contact list. Not good. HTML has rel= elements for paging through data: rel, next, index, start and contents [3]. My thoughts: - has something already been done and I'm missing it (if so: end here ;-) otherwise - let's gather examples from the web, and start seeing how we can sort this out I don't think this is an overly difficult project, maybe, hopefully. I may just be a matter of defining how those link types work within the context of a page or particular microformats. In particular, there's probably an hAtom hfeed/fentry connection here too, and probably also for contact lists. Maybe there's a need to define an (optional) enclosing element, maybe there's not. Regards, etc... [1] http://factoryjoe.com/blog/2008/03/11/portable-contact-lists-and-the-case-against-xfn/ [2] http://twitter.com/statuses/friends/scobleizer.xml [3] http://www.w3.org/TR/html401/types.html#type-links -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From lists at allinthehead.com Wed Mar 12 12:21:52 2008 From: lists at allinthehead.com (Drew McLellan) Date: Wed Mar 12 12:21:59 2008 Subject: [uf-new] Multi-paged XFN In-Reply-To: <21e523c20803120858x53971e4dk2da3c9558104e054@mail.gmail.com> References: <21e523c20803120858x53971e4dk2da3c9558104e054@mail.gmail.com> Message-ID: On 12 Mar 2008, at 15:58, David Janes wrote: > I'm just tossing an idea out for discussion (and to get it out of my > head). > > I've been looking recently at XFN as it's used "in the wild" as a > method of social network portability, or as Chris has probably more > correctly relabeled it, "portable contact lists" [1]. In several > cases, for example here [2]. Obviously this is a requirement to make > this _human usable_ but unfortunately without further assistance an > XFN parser is only going to get a fraction of the contact list. Not > good. > > HTML has rel= elements for paging through data: rel, next, index, > start and contents [3]. > > My thoughts: > - has something already been done and I'm missing it (if so: end here > ;-) otherwise Glenn Jones has already done quite a bit of thinking and work around this: http://www.glennjones.net/Post/830/BacknetworkLabXFNpagination.htm drew. From lists at allinthehead.com Wed Mar 12 12:34:24 2008 From: lists at allinthehead.com (Drew McLellan) Date: Wed Mar 12 12:34:40 2008 Subject: [uf-new] Microformats for Slide Show/Presentations - hShow, hSlide - State-of-the-Art? In-Reply-To: <7e7cb8940803092029q9673475w783a6357f72321fa@mail.gmail.com> References: <7e7cb8940803092029q9673475w783a6357f72321fa@mail.gmail.com> Message-ID: <5E21AE1B-8C69-4522-A3E9-D0D1F07FDBFB@allinthehead.com> On 10 Mar 2008, at 03:29, Gerald Bauer wrote: > I've recently developed a Ruby gem called - surprise, surprise - > Slide Show (S9) [1] - that's a free alternative to PowerPoint and > KeyNote and let's you create slide shows and author slides in plain > text using a wiki-style markup language that's easy-to-write and > easy-to-read. > > Anyways, the HTML generated by the Ruby gem is compatible with the > Opera Show Format and the FullerScreen Firefox Addon and close but not > yet compatible with S5. Over the next couple of weeks I plan to > document the format used by Slide Show (S9) and, thus, I wonder if > anyone else is working on a Microformat for slide shows/presentations > such as hShow, hSlide or similar. > > Any points to existing work is appreciated. My question would be why is a microformat needed? If you look at the approach that S5 takes (which I think is a good approach), the content is marked up in POSH like any other document, and then it's the application of presentation (as in styling) and behaviour layers that make it look and act like a slideshow. It strikes me that the mechanics of a slideshow presentation itself is a different thing entirely to the content being presented. Whilst it's valid to say "this content is an event" or "this content is a about xyz" as these describe the meaning of the content, saying "this content is in a slideshow" is telling us about the medium, not the content. Would you agree? drew. From geraldbauer2007 at gmail.com Wed Mar 12 13:01:47 2008 From: geraldbauer2007 at gmail.com (Gerald Bauer) Date: Wed Mar 12 13:01:51 2008 Subject: [uf-new] Microformats for Slide Show/Presentations - hShow, hSlide - State-of-the-Art? In-Reply-To: <5E21AE1B-8C69-4522-A3E9-D0D1F07FDBFB@allinthehead.com> References: <7e7cb8940803092029q9673475w783a6357f72321fa@mail.gmail.com> <5E21AE1B-8C69-4522-A3E9-D0D1F07FDBFB@allinthehead.com> Message-ID: <7e7cb8940803121401h50578c2drd60c120ace76f480@mail.gmail.com> Hello, Thanks for your thoughts. > My question would be why is a microformat needed? Simply to interoperate and make authoring tools and projection tools work together because they can rely on a common microformat. > It strikes me that the mechanics of a slideshow presentation itself is > a different thing entirely to the content being presented. > > Whilst it's valid to say "this content is an event" or "this content > is a about xyz" as these describe the meaning of the content, saying > "this content is in a slideshow" is telling us about the medium, not > the content. > > Would you agree? How is this different from hAtom or hSlice? hAtom saying "this content is a web feed" and hSlice saying "this content is a web slice". Am I missing something? Any insight appreciated. Cheers. -- Gerald Bauer - Internet Professional - http://geraldbauer.wordpress.com From lists at allinthehead.com Wed Mar 12 13:55:08 2008 From: lists at allinthehead.com (Drew McLellan) Date: Wed Mar 12 13:55:17 2008 Subject: [uf-new] Microformats for Slide Show/Presentations - hShow, hSlide - State-of-the-Art? In-Reply-To: <7e7cb8940803121401h50578c2drd60c120ace76f480@mail.gmail.com> References: <7e7cb8940803092029q9673475w783a6357f72321fa@mail.gmail.com> <5E21AE1B-8C69-4522-A3E9-D0D1F07FDBFB@allinthehead.com> <7e7cb8940803121401h50578c2drd60c120ace76f480@mail.gmail.com> Message-ID: <067E7BE6-CAD2-4512-B98E-BAE49B99D60D@allinthehead.com> On 12 Mar 2008, at 21:01, Gerald Bauer wrote: > Hello, > > Thanks for your thoughts. > >> My question would be why is a microformat needed? > > Simply to interoperate and make authoring tools and projection > tools work together because they can rely on a common microformat. > >> It strikes me that the mechanics of a slideshow presentation itself >> is >> a different thing entirely to the content being presented. >> >> Whilst it's valid to say "this content is an event" or "this content >> is a about xyz" as these describe the meaning of the content, saying >> "this content is in a slideshow" is telling us about the medium, not >> the content. >> >> Would you agree? > > How is this different from hAtom or hSlice? hAtom saying "this > content is a web feed" and hSlice saying "this content is a web > slice". Am I missing something? Any insight appreciated. hAtom is describing a list of time-related items, and within each item describing the timestamp, description, summary and all the component parts that make up that item. It's adding extra information about the relationships between the discreet data points that enables us to understand them more fully. What it's not describing is how that is data is treated with regard to presentation. (I've not heard of hSlice, and so don't have an opinion on that.) The crucial point being that if I mark something up as a heading, it's because it is a heading in the context of the document, and no treatment of the document will change that. By saying something is a slide, does that make it so? What is the intrinsic nature of a slide? Is there anything I could do to it that makes it no longer a slide? What if I print it on large paper - does it then become a poster? Feel free to disagree, of course, but I think a slide is a presentation medium for content, and not content itself. drew. From ckstjohn at gmail.com Wed Mar 12 15:38:33 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Wed Mar 12 15:38:37 2008 Subject: [uf-new] Microformats for Slide Show/Presentations - hShow, hSlide - State-of-the-Art? In-Reply-To: <067E7BE6-CAD2-4512-B98E-BAE49B99D60D@allinthehead.com> References: <7e7cb8940803092029q9673475w783a6357f72321fa@mail.gmail.com> <5E21AE1B-8C69-4522-A3E9-D0D1F07FDBFB@allinthehead.com> <7e7cb8940803121401h50578c2drd60c120ace76f480@mail.gmail.com> <067E7BE6-CAD2-4512-B98E-BAE49B99D60D@allinthehead.com> Message-ID: <8ba906450803121638q4c518439t46411feb4b463edc@mail.gmail.com> On Wed, Mar 12, 2008 at 4:55 PM, Drew McLellan wrote: > > hAtom is describing a list of time-related items, and within each item > describing the timestamp, description, summary and all the component > parts that make up that item. It's adding extra information about the > relationships between the discreet data points that enables us to > understand them more fully. What it's not describing is how that is > data is treated with regard to presentation. > Wouldn't that also be more or less what a slideshow format does? I think you could re-state the format as being a time-sequenced series of related bits of information. Maybe with the addition that the info may also be associated with a spoken narrative of some sort. The fact that slide authoring programs allow multiple views (slideshow, speaker notes, and even an outline view) suggests that there's an underlying concept beyond just presentation. On the other hand, there are several existing microformats that might be good to reuse, has the original poster given that a shot yet? -cks -- Christopher St. John http://artofsystems.blogspot.com From jrrodgers at gmail.com Wed Mar 12 18:46:31 2008 From: jrrodgers at gmail.com (Jesse Rodgers) Date: Wed Mar 12 18:46:34 2008 Subject: [uf-new] Microformats for Slide Show/Presentations - hShow, hSlide - State-of-the-Art? In-Reply-To: <8ba906450803121638q4c518439t46411feb4b463edc@mail.gmail.com> References: <7e7cb8940803092029q9673475w783a6357f72321fa@mail.gmail.com> <5E21AE1B-8C69-4522-A3E9-D0D1F07FDBFB@allinthehead.com> <7e7cb8940803121401h50578c2drd60c120ace76f480@mail.gmail.com> <067E7BE6-CAD2-4512-B98E-BAE49B99D60D@allinthehead.com> <8ba906450803121638q4c518439t46411feb4b463edc@mail.gmail.com> Message-ID: <88190c0f0803121946h55bb4e46v936ef3455ebd559d@mail.gmail.com> On Wed, Mar 12, 2008 at 7:38 PM, Christopher St John wrote: > The fact that slide authoring programs allow multiple views (slideshow, > speaker notes, and even an outline view) suggests that there's an > underlying concept beyond just presentation. It does seem to me like that is no different than saying a small screen view or an iphone custom view is a different concept beyond presentation. You do have a different purpose and a different level of interaction with web content displayed for different purposes but how does a format help? I might actually argue it would, especially with slide based presentations or mobile devices as it helps the device know how to display the content. But I think that is supposed to be the job of CSS and javascript... Microformats would be crossing into adding structure first, semantics second. Jesse From flying.mushroom at gmail.com Fri Mar 14 00:01:12 2008 From: flying.mushroom at gmail.com (Nelson Menezes) Date: Fri Mar 14 00:01:15 2008 Subject: [uf-new] Metadata/machine-readable data patterns Message-ID: Hi all. I was reading through http://www.webstandards.org/2007/04/27/haccessibility when a possible solution to that problem occurred to me. I've tried looking through the list and wiki but haven't found a similar suggestion; however if it's a been brought up before... apologies in advance. To cut to the chase: why not use fields to store metadata that must be machine-read within microformats? It would avoid stretching the semantics of existing tags and (I believe) avoid issues with screen readers. Besides, it's what the tag is for... Here are a few more thoughts: - elements don't require being within a
. They do require being within a block-level element in XHTML for validation. The spec (http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.2.1) mentions that "...elements used to create controls generally appear inside a FORM element, but may also appear outside of a FORM element declaration when they are used to build user interfaces." - If they are within a , they can be submitted (which might be a desired effect) or not (by adding the disabled="disabled" attribute). - To my knowledge, no user agent renders fields. Easily accessible via JS or any other parsers though. - For identification of an element we could use the "name" attribute (which can be repeated in the same page), or a class. Or it can be inferred from its parent node. Here's a half-baked, not-well-thought-through, example of how this could be used to solve the hCard (or any other datetime) issue:
http://www.web2con.com/ Web 2.0 Conference: October 5- 19, at the Argent Hotel, San Francisco, CA
Another possibility is to discard the s altogether:
http://www.web2con.com/ Web 2.0 Conference: October 5-19, at the Argent Hotel, San Francisco, CA
Good? Bad? Evil? -- Nelson Menezes flying.mushroom@gmail.com From regine at regine-heidorn.de Fri Mar 14 01:08:30 2008 From: regine at regine-heidorn.de (Regine Heidorn) Date: Fri Mar 14 01:08:36 2008 Subject: [uf-new] hTopList In-Reply-To: References: Message-ID: Sorry, I missed it some days ago: somebody wanted to know about hTopList. Just for fun I developed a TopList mixing hAudio and hReview, you may find it here: http://www.regine-heidorn.de/thinner.html It's an example-list of my favorite thinner-tracks and I had the following thoughts on it: - as a TopList it has to be an ordered list (
    ) with its ID telling the numbers of tops (5 in this case) and its class telling the whole out of which the tops are taken (thinner-tracks in this case). The whole can be a magazine, an artist, an album, a label, the genre etc. Since you can assign multiple classes it's also possible to add more information like e. g. class="thinner albums benfay" meaning: a TopList containing albums of the netlabel thinner from the artist benfay. - it could cooperate with more microformats, the list could also contain hCalendar for events like concerts, readings, performances etc. or one could add another hReview and include videos, blog-posts and more. The artist could be named via hCard that could also be used to specify the rater or reviewer. - the
      should contain exactly the number of
    1. -elements that are top-rated, e. g. a top5-list should contain 5
    2. s. Same for the rating which always has to be the rating out of the whole number, e. g. 3 out of 5. All in all it's maybe not necessary to create an own hTopList, one can just mix some elaborated microformats. Only specification to make it a TopList and not only a mixture of existing microformats would be to use an
        with IDs and classes as mentioned above and the obligation to use exactly the number of
      1. s according to the number of items rated. The
      2. s have to be in the right order, e. g. 5 out of 5 has to be the first
      3. , 3 out of 5 the third. Apart from that hTopList would give some orientation on how to mix existing microformats not creating a tag-soup but using always the same convention. I guess as a microformat it might be usefull also for platforms like last.fm, but it would also be nice for those bloggers addicted to lists, I think of something like a WordPress-PlugIn for TopLists. From ckstjohn at gmail.com Fri Mar 14 07:01:23 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Fri Mar 14 07:01:26 2008 Subject: [uf-new] Metadata/machine-readable data patterns In-Reply-To: References: Message-ID: <8ba906450803140801t6d916b8eqf4110fb453c23dda@mail.gmail.com> On Fri, Mar 14, 2008 at 4:01 AM, Nelson Menezes wrote: > > To cut to the chase: why not use fields to > store metadata that must be machine-read within microformats? It would > avoid stretching the semantics of existing tags and (I believe) avoid > issues with screen readers. Besides, it's what the tag is for... > I'd read: http://tantek.com/log/2005/06.html#d03t2359 then spend a bit of time looking through the mailing list and chat logs (google with site:microformats.org is helpful) Short version: If you gotta hide stuff (like ISO dates), then hide them very, very close to the visible representation on the page of the thing you're hiding. If there's no visible version, then you probably don't want an invisible version, either. But that's just a fraction of the full argument. If you're serious about wading in I'd highly suggest doing the reading... -cks -- Christopher St. John http://artofsystems.blogspot.com From flying.mushroom at gmail.com Fri Mar 14 12:50:49 2008 From: flying.mushroom at gmail.com (Nelson Menezes) Date: Fri Mar 14 12:57:15 2008 Subject: [uf-new] Metadata/machine-readable data patterns In-Reply-To: <8ba906450803140801t6d916b8eqf4110fb453c23dda@mail.gmail.com> References: <8ba906450803140801t6d916b8eqf4110fb453c23dda@mail.gmail.com> Message-ID: On 14/03/2008, Christopher St John wrote: > I'd read: > > http://tantek.com/log/2005/06.html#d03t2359 That is a good read, and a good point. I concede that you really don't want to use hidden data unless there is a good case for it. > then spend a bit of time looking through the mailing list and chat logs (google > with site:microformats.org is helpful) I did, but I can't find anything referring specifically to this scenario. Apologies if I'm a bit thick! If you know of a specific talk/page I'm happy to read it... > Short version: If you gotta hide stuff (like ISO dates), then hide them very, > very close to the visible representation on the page of the thing you're hiding. Agreed. And when there are relevant (i.e. semantically meaningful) tags or tag attributes that should be the way to go. If, however, there aren't or they cause significant side-effects, I think that carefully-thought-through use of fields could be a good option. The ISO date seems like one of these scenarios: the usage of the title attribute makes sense but has practical disadvantages that (in my opinion) will actually hinder its adoption. For instance, many designers would dislike the idea of non-human-friendly tooltips scarring their websites (and so might want to opt out of using the microformat). More importantly, there's the well-documented accessibility issue with screen readers. So I would suggest something like this as the simplest approach for a date pattern: March 14th Is it hidden data? Yes, but so is the title attribute in an tag. This is maybe slightly more "hidden", but I think it's a good compromise. -- Nelson Menezes flying.mushroom@gmail.com From bjonkman at sobac.com Fri Mar 14 13:25:43 2008 From: bjonkman at sobac.com (Bob Jonkman) Date: Fri Mar 14 13:27:38 2008 Subject: [uf-new] Metadata/machine-readable data patterns In-Reply-To: References: , <8ba906450803140801t6d916b8eqf4110fb453c23dda@mail.gmail.com>, Message-ID: <47DAB517.4162.458FDC@bjonkman.sobac.com> +1 for Has someone tested this with a screen reader? I'm surprised that an is valid without being nested inside a , but pleasantly so. This syntax seems no more difficult to parse than and using a standards-compliant attribute to identify hidden text is far better than keeping visible something that is meant only for machines. And it isn't _really_ hiding anything. The human-readable equivalent text is still very visible, and has exactly the same meaning as the value="something". --Bob. >>> 14 Mar 2008 20:50 Nelson Menezes >>> > On 14/03/2008, Christopher St John wrote: > > I'd read: > > > > http://tantek.com/log/2005/06.html#d03t2359 > > That is a good read, and a good point. I concede that you really don't > want to use hidden data unless there is a good case for it. > > > then spend a bit of time looking through the mailing list and chat > > logs (google with site:microformats.org is helpful) > > I did, but I can't find anything referring specifically to this > scenario. Apologies if I'm a bit thick! If you know of a specific > talk/page I'm happy to read it... > > > Short version: If you gotta hide stuff (like ISO dates), then hide > > them very, very close to the visible representation on the page of > > the thing you're hiding. > > Agreed. And when there are relevant (i.e. semantically meaningful) > tags or tag attributes that should be the way to go. If, however, > there aren't or they cause significant side-effects, I think that > carefully-thought-through use of fields could > be a good option. > > The ISO date seems like one of these scenarios: the usage of the > title attribute makes sense but has practical disadvantages > that (in my opinion) will actually hinder its adoption. For instance, > many designers would dislike the idea of non-human-friendly tooltips > scarring their websites (and so might want to opt out of using the > microformat). More importantly, there's the well-documented > accessibility issue with screen readers. > > So I would suggest something like this as the simplest approach for a > date pattern: > > March 14th /> > > Is it hidden data? Yes, but so is the title attribute in an > tag. This is maybe slightly more "hidden", but I think it's a good > compromise. > > -- > Nelson Menezes > flying.mushroom@gmail.com > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -- -- -- -- Bob Jonkman http://sobac.com/sobac/ SOBAC Microcomputer Services Voice: +1-519-669-0388 6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413 Software --- Office & Business Automation --- Consulting From csarven at gmail.com Fri Mar 14 14:22:56 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Fri Mar 14 14:23:01 2008 Subject: [uf-new] Metadata/machine-readable data patterns In-Reply-To: <47DAB517.4162.458FDC@bjonkman.sobac.com> References: <8ba906450803140801t6d916b8eqf4110fb453c23dda@mail.gmail.com> <47DAB517.4162.458FDC@bjonkman.sobac.com> Message-ID: On Fri, Mar 14, 2008 at 4:50 PM, Nelson Menezes wrote: > March 14th > > Is it hidden data? Yes, but so is the title attribute in an > tag. This is maybe slightly more "hidden", but I think it's a good > compromise. @title value in is not hidden data. The user is able to hover the element and get to the information. The @title value is used as an alternative or replacement of textContent. This is not the case in . On Fri, Mar 14, 2008 at 5:25 PM, Bob Jonkman wrote: > +1 for > > Has someone tested this with a screen reader? > > I'm surprised that an is valid without being nested inside a > , but pleasantly so. > > This syntax seems no more difficult to parse than title="something"> and using a standards-compliant attribute to > identify hidden text is far better than keeping visible something that > is meant only for machines. It is misleading to think that ISO 8601 is meant only for the machines. It is important to keep the data paired, a) human readable date/timestamp within context, b) human readable standardised date/timestamp. is "good enough" for this or at least the most semantic candidate with minimal negative impact. Screen readers may have a problem with it only because of the way they are configured to treat the data. The information inside is independent from how it will be interpret or treated by any UA for that matter. e.g.

        I will see you next week

        Using on the other hand hides information from humans and is essentially a very similar case to using meta keywords (as opposed to human tagging which is far more favoured now). -Sarven http://www.csarven.ca From flying.mushroom at gmail.com Sat Mar 15 00:10:56 2008 From: flying.mushroom at gmail.com (Nelson Menezes) Date: Sat Mar 15 00:11:01 2008 Subject: [uf-new] Metadata/machine-readable data patterns In-Reply-To: References: <8ba906450803140801t6d916b8eqf4110fb453c23dda@mail.gmail.com> <47DAB517.4162.458FDC@bjonkman.sobac.com> Message-ID: On 14/03/2008, Sarven Capadisli wrote: > @title value in is not hidden data. The user is able to hover > the element and get to the information. The @title value is used as an > alternative or replacement of textContent. This is not the case > in . Point taken. But the data is still "hidden" in the sense that most users don't tend to hover their cursor over every word to see if there is more information about each word. It is still possible to let the title attribute fall out of sync with the "human" content. And likewise it's just as easy to abuse as "properly hidden" data: Free stuff! > It is important to keep the data paired, a) human readable > date/timestamp within context, b) human readable standardised > date/timestamp. is "good enough" for this or at least the most > semantic candidate with minimal negative impact. Screen readers may > have a problem with it only because of the way they are configured to > treat the data. The information inside is independent from how > it will be interpret or treated by any UA for that matter. > > e.g.

        I will see you next > week

        It's a good example above, but let's be honest: the real reason we have the ISO dates in microformats like hCalendar is so that dates are machine-readable. If it were possible to reliably parse something like next Thursday at sundown then we wouldn't be having this discussion. Using is a decent semantic compromise in many circumstances. But screen readers are not doing anything wrong by interpreting the data the way they do (they are very much following the spec, and the semantics). It's the stretching of the semantics by microformats that unwittingly caused the issue; it's not right to expect screen readers to address the issue by changing the way they interpret the data. I have been convinced, so far, that using hidden input elements as a "blanket solution" for machine-readable data is indeed a bad idea. The title of my original email is therefore somewhat inadequate. However, I maintain that in specific circumstances where we have data that is *meant* for machine-readability and that has adverse effects on human readability then we should consider using a hidden input field. -- Nelson Menezes flying.mushroom@gmail.com From bjonkman at sobac.com Sat Mar 15 12:50:01 2008 From: bjonkman at sobac.com (Bob Jonkman) Date: Sat Mar 15 12:51:35 2008 Subject: [uf-new] Metadata/machine-readable data patterns In-Reply-To: References: , <47DAB517.4162.458FDC@bjonkman.sobac.com>, Message-ID: <47DBFE39.18388.4AA9674@bjonkman.sobac.com> This is what Sarven Capadisli said about "Re: [uf-new] Metadata/machine-reada" on 14 Mar 2008 at 18:22 > @title value in is not hidden data. The user is able to hover > the element and get to the information. Respectfully, I disagree. The display of the "title" attribute is entirely dependent on browser implementation. Your statement is true enough for GUI browsers, but "title" is invisible in text browsers, minimalist browsers (phones, PDAs), and any application that scrapes HTML for the page content. I don't think there's anything in the HTML spec that _requires_ conforming implementations to show or speak the value of a "title" attribute[1]. > [...] b) human readable standardised > date/timestamp. is "good enough" for this or at least the most > semantic candidate with minimal negative impact. Screen readers may > have a problem with it only because of the way they are configured to > treat the data. Again I disagree. It is not "good enough". It is "broken". The microformat use of is interfering with screen readers' use of the Web. For every other aspect of microformats we insist that the behaviour of the microformat follows usage found "in the wild". Here we have a documented case where the microformat use of does not match the use of screen readers "in the wild". It is likely that screen reader users have a much larger use base than microformat users, and it is unreasonable for the microformat community to expect the screen reader users and developers to re-engineer their products to conform to an abitrary microformat standard, especially now that Nelson Menezes has found a standards-compliant method to achieve the same purpose without causing interference with screen readers. We have here the opportunity to correct an oversight that's causing grief for a minority... --Bob. [1] http://www.w3.org/TR/html401/struct/global.html#adef-title -- -- -- -- Bob Jonkman http://sobac.com/sobac/ SOBAC Microcomputer Services Voice: +1-519-669-0388 6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413 Software --- Office & Business Automation --- Consulting From lists at ben-ward.co.uk Sat Mar 15 15:45:08 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Sat Mar 15 17:54:15 2008 Subject: [uf-new] Calendar-wide scope for properties in hCalendar Message-ID: <23B29302-4124-4DB5-A5D7-567232B4B912@ben-ward.co.uk> Hi hi, We (by which I mean ?Steve Marshall?) at Yahoo! recently relaunched our European TV Listings page. We've attempted to integrate a full complement of hCalendar across the various listings pages. In doing so, there are a few issues we've found, and I'll raise them here as separate threads for ease of management. First up: Consider pages like these: ? http://uk.tv.yahoo.com/listings/channel-4/2008-03-15/ ? http://uk.tv.yahoo.com/listings/bbc-two/2008-03-15/ These are pages listing programmes on one particular channel. Each programme is a single VEVENT, the DTSTART, SUMMARY, and URL+UID are self explanatory from the page. The issue is LOCATION ? the channel name ? which for a page like this only appears once, in the heading of the page. Currently, hCalendar requires the following structure: VCALENDAR (implied) VEVENT SUMMARY LOCATION URL UID DTSTART VEVENT ? VEVENT ? VEVENT ? But the implied publishing structure we actually have on our page is: VCALENDAR (implied) VEVENT SUMMARY LOCATION URL UID DTSTART VEVENT ? VEVENT ? VEVENT ? But, in terms of our *publishing* pattern, we actually have: VCALENDAR (implied) LOCATION VEVENT SUMMARY URL UID DTSTART VEVENT ? Now, this seems like an extremely reasonable page structure, not just for television channels, but also for pages which list events from one single LOCATION (e.g. http://upcoming.yahoo.com/venue/22943/). Plausible Solution #1: Include-Pattern We could extend hCalendar to permit use of the include pattern. This would parse. However, in the case of pages like ours it would produce a huge amount of extraneous mark-up. On the "BBC 2" page, we'd have to repeat the include code 42 times. {} to reference a five character string. It's clumsy at best, definitely ugly and I really feel that it's publisher unfriendly. Plausible Solution #2: Permit certain properties to be used globally in hCalendar The include-pattern solution is publisher-unfriendly, especially since hCalendar could, I think, support a far more graceful data structure to solve this particular problem. ? Allow the LOCATION property to be a direct child of the VCALENDAR object, and apply that LOCATION to all VEVENT objects by default. (where a VEVENT has a LOCATION child, the default LOCATION would be overridden) This way, the location data is only added once, whilst remaining a structurally contained part of the calendar. Mark-up would look something like this:
        BBC 2
        1. ?
        2. ?
        3. ?
        4. ?
        The downside, of course, is that this deviates from data structure in the VCALENDAR spec, and would require parsers to perform more complex processing to include a LOCATION property for each VEVENT that may be exported. In that regard, I'd like to ask those who build parsers to a more complex degree than I do to contribute here and answer whether such an optimisation would be unreasonably expensive to parse. ? I would spec this to *require* that the VCALENDAR class name be explicit in cases where properties are used globally ? This concept of globalising certain calendar properties could be extended to a few others, too. Namely ORGANIZER, for pages where a particular organisation is the sole organiser of events (I don't have an example to hand, though, hence this further expansion is offered only as a footnote to keep in mind). Thanks, Ben From mail at tobyinkster.co.uk Sun Mar 16 03:46:20 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Mar 16 03:46:48 2008 Subject: [uf-new] Re: Calendar-wide scope for properties in hCalendar Message-ID: <18F1B5C7-BE0A-446C-BC6B-34C968B66780@tobyinkster.co.uk> Ben Ward wrote: > Plausible Solution #1: Include-Pattern > We could extend hCalendar to permit use of the include pattern. This > would parse. {} to > reference a five character string. It's clumsy at best, definitely > ugly and I really feel that it's publisher unfriendly. Yes, the present include pattern is very verbose. Whatsmore, use of the element can trigger excessive memory usage in some browsers, and if you switch to , then you might start interfering with the tab cycle. :-( For these reasons, I proposed a replacement for the current include pattern, by which you'd just be able to use
      4. ...
        5. to include the element with ID "channel" as part of the event. Details: http://microformats.org/wiki/include-pattern-strawman#Non- Verbose_Class-Based_Solution This is currently implemented in Cognition (http://buzzword.org.uk/ cognition/). If you were publishing the events as a table rather than a list, you could use the table header pattern described on the hcalendar- brainstorming page. This is supported by Cognition and IIRC X2V. > Allow the LOCATION property to be a direct child of the VCALENDAR > object, and apply that LOCATION to all VEVENT objects by default. It seems to me that improving the include pattern to make it more usable is a better solution. Sure, this adjustment may seem fruitful in the short term, but then what happens when you have the same problem with organisations for multiple hCards, or items for multiple hReviews. An improvement to the include pattern would be usable for all properties in all compound microformats -- not just locations in hCalendar. > In that regard, I'd like to ask those who build parsers to a more > complex degree than I do to contribute here and answer whether such > an optimisation would be unreasonably expensive to parse. Although I've only been working on it for a month or so, I think Cognition is possibly the most complex parser around, in that it supports several different microformats, RDF (including RDFa and eRDF) and more. Such an extension wouldn't make hCalendars unreasonably difficult to parse. In the case of Cognition, it would basically be copying and pasting a chunk of code from the hEvent module to the hCalendar module. But I really think that the include pattern is the way to go. If it's too verbose, then we should improve the include pattern for the benefit of all, rather than complicating hCalendar for the benefit of the few. -- Toby A Inkster From bhawkeslewis at googlemail.com Sun Mar 16 03:57:01 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Mar 16 03:57:05 2008 Subject: [uf-new] Re: Calendar-wide scope for properties in hCalendar In-Reply-To: <18F1B5C7-BE0A-446C-BC6B-34C968B66780@tobyinkster.co.uk> References: <18F1B5C7-BE0A-446C-BC6B-34C968B66780@tobyinkster.co.uk> Message-ID: <47DD0B0D.2040301@googlemail.com> Toby A Inkster wrote: > It seems to me that improving the include pattern to make it more usable > is a better solution. Sure, this adjustment may seem fruitful in the > short term, but then what happens when you have the same problem with > organisations for multiple hCards, or items for multiple hReviews. If this is a real problem there (are they examples of this?), might the same solution be applicable there too? What's nice about this proposal, it seems to me, is that it brings the microformat closer to how content is marked up without the microformat, whereas the include pattern pulls it away from that simplicity, in so far as it involves adding extra markup you wouldn't normally include. -- Benjamin Hawkes-Lewis From silviu.savin at gmail.com Wed Mar 19 06:06:46 2008 From: silviu.savin at gmail.com (Silviu Savin) Date: Wed Mar 19 06:06:51 2008 Subject: [uf-new] hjob In-Reply-To: References: Message-ID: Ok, we have hresume. What if we would have hjob for companies that have Career pages on their website? This way we will have information that is accessible and available in a large, wide spread format that can be read by anyone. Companies will publish their jobs on their webpages according to these standards. Everyone will be able to pull these information easily. Companies don't have to publish the same job announce to several jobboards portals anymore. Looking forward for your thoughts on this! From csarven at gmail.com Wed Mar 19 06:12:50 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Wed Mar 19 06:12:54 2008 Subject: [uf-new] hjob In-Reply-To: References: Message-ID: On Wed, Mar 19, 2008 at 10:06 AM, Silviu Savin wrote: > Ok, we have hresume. > > What if we would have hjob for companies that have Career pages on > their website? > > This way we will have information that is accessible and available in > a large, wide spread format > that can be read by anyone. Companies will publish their jobs on their > webpages according to these > standards. Everyone will be able to pull these information easily. > Companies don't have to publish the same > job announce to several jobboards portals anymore. http://microformats.org/wiki/hlisting might be what you are looking for. Sarven Capadisli - http://www.csarven.ca From dbounds at gmail.com Wed Mar 19 06:13:36 2008 From: dbounds at gmail.com (Darren Bounds) Date: Wed Mar 19 06:13:41 2008 Subject: [uf-new] hjob In-Reply-To: References: Message-ID: <26563eca0803190713p2db7e4acr7549d68ed07ac8cb@mail.gmail.com> Hello Silviu, Excellent idea. We're currently working on a specification for exactly this purpose. Please see the 'job-listing' pages on the Microformats wiki. We welcome your input! Thank you, Darren Bounds On Wed, Mar 19, 2008 at 10:06 AM, Silviu Savin wrote: > Ok, we have hresume. > > What if we would have hjob for companies that have Career pages on > their website? > > This way we will have information that is accessible and available in > a large, wide spread format > that can be read by anyone. Companies will publish their jobs on their > webpages according to these > standards. Everyone will be able to pull these information easily. > Companies don't have to publish the same > job announce to several jobboards portals anymore. > > Looking forward for your thoughts on this! > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Thank you, Darren Bounds From silviu.savin at gmail.com Wed Mar 19 07:02:36 2008 From: silviu.savin at gmail.com (Silviu Savin) Date: Wed Mar 19 07:31:39 2008 Subject: [uf-new] hjob In-Reply-To: <26563eca0803190713p2db7e4acr7549d68ed07ac8cb@mail.gmail.com> References: <26563eca0803190713p2db7e4acr7549d68ed07ac8cb@mail.gmail.com> Message-ID: Hi Darren, where are these 'job-listing' pages? On Wed, Mar 19, 2008 at 4:13 PM, Darren Bounds wrote: > Hello Silviu, > > Excellent idea. We're currently working on a specification for exactly > this purpose. Please see the 'job-listing' pages on the Microformats > wiki. > > We welcome your input! > > > Thank you, > > Darren Bounds > > > > On Wed, Mar 19, 2008 at 10:06 AM, Silviu Savin wrote: > > > Ok, we have hresume. > > > > What if we would have hjob for companies that have Career pages on > > their website? > > > > This way we will have information that is accessible and available in > > a large, wide spread format > > that can be read by anyone. Companies will publish their jobs on their > > webpages according to these > > standards. Everyone will be able to pull these information easily. > > Companies don't have to publish the same > > job announce to several jobboards portals anymore. > > > > Looking forward for your thoughts on this! > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > > > > > > -- > > Thank you, > Darren Bounds > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From scott at makedatamakesense.com Wed Mar 19 08:46:10 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Mar 19 08:46:17 2008 Subject: [uf-new] hjob In-Reply-To: References: <26563eca0803190713p2db7e4acr7549d68ed07ac8cb@mail.gmail.com> Message-ID: <7A239EF8-A265-4C49-855F-EB9041301B68@makedatamakesense.com> On Mar 19, 2008, at 9:02 AM, Silviu Savin wrote: > where are these 'job-listing' pages? Here: http://microformats.org/wiki/job-listing-examples http://microformats.org/wiki/job-listing-brainstorming I originally split job listings off from the hListing pages, and I now think I should have done more research into the limits of hListing before I did that. I'm no longer publishing job listings myself, but I'd encourage anyone who is to try out hListing and identify specifically where it falls short before continuing speculation about job listings. It seems to me it's already pretty far away from the "start as simple as possible" principle of microformats. -- Scott Reynen MakeDataMakeSense.com From me at filipcte.ro Wed Mar 19 12:36:09 2008 From: me at filipcte.ro (Filip Chereches-Tosa) Date: Wed Mar 19 12:36:14 2008 Subject: [uf-new] hListing vs hJob Message-ID: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> With the hListing proposal (http://microformats.org/wiki/hlisting), is there any interest in further developing hJob (http://microformats.org/wiki/job-listing-brainstorming)? Or at least finalize hListing and make it a real microformat... I'm actively involved in the online-jobs industry and a standard format to describe job postings would be great to have! :) Cheers, Filip --- Filip Chereches-Tosa +40-723-149.439 me@filipcte.ro ____________________________________ www.filipcte.ro // blog www.jobber.ro // IT jobs www.jobberbase.com // open source job board www.geekmeet.ro // Meet-ups for IT people From ryan at theryanking.com Wed Mar 19 15:50:31 2008 From: ryan at theryanking.com (Ryan King) Date: Wed Mar 19 15:50:38 2008 Subject: [uf-new] Multi-paged XFN In-Reply-To: <21e523c20803120858x53971e4dk2da3c9558104e054@mail.gmail.com> References: <21e523c20803120858x53971e4dk2da3c9558104e054@mail.gmail.com> Message-ID: On Mar 12, 2008, at 8:58 AM, David Janes wrote: > I'm just tossing an idea out for discussion (and to get it out of my > head). > > I've been looking recently at XFN as it's used "in the wild" as a > method of social network portability, or as Chris has probably more > correctly relabeled it, "portable contact lists" [1]. In several > cases, for example here [2]. Obviously this is a requirement to make > this _human usable_ but unfortunately without further assistance an > XFN parser is only going to get a fraction of the contact list. Not > good. > > HTML has rel= elements for paging through data: rel, next, index, > start and contents [3]. > > My thoughts: > - has something already been done and I'm missing it (if so: end here > ;-) otherwise http://microformats.org/wiki/hcard-xfn-supporting-friends-lists#Implement_hCard_XFN_supporting_friends_lists Synopsis: just put rel="me" on pagination links. -ryan From silviu.savin at gmail.com Thu Mar 20 10:46:34 2008 From: silviu.savin at gmail.com (Silviu Savin) Date: Thu Mar 20 10:53:21 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> Message-ID: I guess since these websites like http://www.edgeio.com and http://jobs.emurse.com already supports hListing, even if this format is not fully yet approved and only as a draft, a new format only for describing job posting might not be necessary, even if that would be great. Is it just me or this process from proposal to have a fully microformat it takes a while? The draft for hListing is from 2006. I might also be wrong. Silviu Savin On Wed, Mar 19, 2008 at 3:36 PM, Filip Chereches-Tosa wrote: > With the hListing proposal (http://microformats.org/wiki/hlisting), is > there any interest in further developing hJob (http://microformats.org/wiki/job-listing-brainstorming)? > > Or at least finalize hListing and make it a real microformat... > > I'm actively involved in the online-jobs industry and a standard > format to describe job postings would be great to have! :) > > Cheers, > Filip > > > --- > Filip Chereches-Tosa > > +40-723-149.439 > me@filipcte.ro > ____________________________________ > www.filipcte.ro // blog > www.jobber.ro // IT jobs > www.jobberbase.com // open source job board > www.geekmeet.ro // Meet-ups for IT people > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From dbounds at gmail.com Thu Mar 20 11:20:42 2008 From: dbounds at gmail.com (Darren Bounds) Date: Thu Mar 20 11:20:48 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> Message-ID: <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> These sites are relatively irrelavent in the industry and therefore I personally do not feel they should necessarily be cause to us steer in any specific direction. In ATS space you have global leaders like: Vurv Technology, Inc. (http://www.vurv.com) Taleo (http://www.taleo.com) Kenexa (http://www.kenexa) These are people who sell their solutions to the Global Fortune 500 as well as small and medium sized businesses. You also have the job boards like Career Builder, Monster, Dice, etc... I represent Vurv and we definitely see value in defining a job requisition standard which may or may not leverage existing Microformats but could not be contained by hListing and hCard alone. Thanks, Darren Bounds On Thu, Mar 20, 2008 at 2:46 PM, Silviu Savin wrote: > I guess since these websites like http://www.edgeio.com and > http://jobs.emurse.com already supports hListing, even if this format > is not fully yet approved and only as a draft, a new format only for > describing job posting might not be necessary, even if that would be > great. > > Is it just me or this process from proposal to have a fully > microformat it takes a while? > The draft for hListing is from 2006. I might also be wrong. > > Silviu Savin > > > > On Wed, Mar 19, 2008 at 3:36 PM, Filip Chereches-Tosa wrote: > > With the hListing proposal (http://microformats.org/wiki/hlisting), is > > there any interest in further developing hJob (http://microformats.org/wiki/job-listing-brainstorming)? > > > > Or at least finalize hListing and make it a real microformat... > > > > I'm actively involved in the online-jobs industry and a standard > > format to describe job postings would be great to have! :) > > > > Cheers, > > Filip > > > > > > --- > > Filip Chereches-Tosa > > > > +40-723-149.439 > > me@filipcte.ro > > ____________________________________ > > www.filipcte.ro // blog > > www.jobber.ro // IT jobs > > www.jobberbase.com // open source job board > > www.geekmeet.ro // Meet-ups for IT people > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Thank you, Darren Bounds From silviu.savin at gmail.com Thu Mar 20 11:44:23 2008 From: silviu.savin at gmail.com (Silviu Savin) Date: Thu Mar 20 11:44:27 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> Message-ID: Darren, sounds great! How can we move on with the hJob, job-listing microformat? On Thu, Mar 20, 2008 at 2:20 PM, Darren Bounds wrote: > These sites are relatively irrelavent in the industry and therefore I > personally do not feel they should necessarily be cause to us steer in > any specific direction. > > In ATS space you have global leaders like: > > Vurv Technology, Inc. (http://www.vurv.com) > Taleo (http://www.taleo.com) > Kenexa (http://www.kenexa) > > These are people who sell their solutions to the Global Fortune 500 as > well as small and medium sized businesses. > > You also have the job boards like Career Builder, Monster, Dice, etc... > > I represent Vurv and we definitely see value in defining a job > requisition standard which may or may not leverage existing > Microformats but could not be contained by hListing and hCard alone. > > > Thanks, > > Darren Bounds > > > > On Thu, Mar 20, 2008 at 2:46 PM, Silviu Savin wrote: > > I guess since these websites like http://www.edgeio.com and > > http://jobs.emurse.com already supports hListing, even if this format > > is not fully yet approved and only as a draft, a new format only for > > describing job posting might not be necessary, even if that would be > > great. > > > > Is it just me or this process from proposal to have a fully > > microformat it takes a while? > > The draft for hListing is from 2006. I might also be wrong. > > > > Silviu Savin > > > > > > > > On Wed, Mar 19, 2008 at 3:36 PM, Filip Chereches-Tosa wrote: > > > With the hListing proposal (http://microformats.org/wiki/hlisting), is > > > there any interest in further developing hJob (http://microformats.org/wiki/job-listing-brainstorming)? > > > > > > Or at least finalize hListing and make it a real microformat... > > > > > > I'm actively involved in the online-jobs industry and a standard > > > format to describe job postings would be great to have! :) > > > > > > Cheers, > > > Filip > > > > > > > > > --- > > > Filip Chereches-Tosa > > > > > > +40-723-149.439 > > > me@filipcte.ro > > > ____________________________________ > > > www.filipcte.ro // blog > > > www.jobber.ro // IT jobs > > > www.jobberbase.com // open source job board > > > www.geekmeet.ro // Meet-ups for IT people > > > > > > _______________________________________________ > > > microformats-new mailing list > > > microformats-new@microformats.org > > > http://microformats.org/mailman/listinfo/microformats-new > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > > > > > > -- > > Thank you, > Darren Bounds > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From lists at ben-ward.co.uk Thu Mar 20 14:56:37 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Thu Mar 20 14:56:44 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> Message-ID: <60EF4528-8414-47BC-A711-CE01C8FD8C91@ben-ward.co.uk> On 20 Mar 2008, at 11:46, Silviu Savin wrote: > I guess since these websites like http://www.edgeio.com and > http://jobs.emurse.com already supports hListing, even if this format > is not fully yet approved and only as a draft, a new format only for > describing job posting might not be necessary, even if that would be > great. > > Is it just me or this process from proposal to have a fully > microformat it takes a while? > The draft for hListing is from 2006. I might also be wrong. The current draft of hListing is dated 2006, but the core schema has been implemented successfully on multiple occasions (Kelkoo recently published 26.5 million product listings with hListing mark-up at the core). Having spent the time working with the schema, I'm intending to take over as editor of the hlisting spec shortly, and hopefully help structure the work again. In the meantime, please please please start adding any known issues to http://microformats.org/wiki/hlisting-issues and if you have new examples of listings, add them to the examples section of the hlisting proposal page (that will get restructured properly in the new few weeks.) Regards, Ben From chucka at hr-xml.org Thu Mar 20 16:42:50 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Thu Mar 20 16:49:38 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> Message-ID: <47E3048A.7060805@hr-xml.org> Darren Bounds wrote: > I represent Vurv and we definitely see value in defining a job > requisition standard which may or may not leverage existing > Microformats but could not be contained by hListing and hCard alone. > Darren, What you say is true, but I wonder if the reason it is true is that the requisition use case isn't necessarily equivalent to the hJob or hListing microformat use case. The latter is all about getting some semantics/structure in a browser so content can be indexed/mashed-up, etc. I think the requisition use case is a bit different. In connection with the on-going HR-XML 3.0 re-architecture, our recruiting work group did a bit of survey work and analysis of the "PositionOpening" XML instances that came in under our certification program. We found a tremendous variation in the fields used by implementers. This variation is by industry, occupation, level of job, custom in the particular country or region, etc. My point in mentioning this is that our recent research tends to mirror some of the wide variation documented in the job-listing wiki pages: http://microformats.org/wiki/job-listing-brainstorming http://microformats.org/wiki/job-listing-examples This recent review leads me to believe that the simpler hListing is likely a better path than the more richly descriptive hJob. If the Microformats community were to build out everything under the job-listing brainstorming page (something approaching what might be required in a requisition), you might be adding complexity and opportunities for variation without commensurate benefit. I think you'd have something closer to a "document format" than a "microformat". The HR-XML recruiting work group kicked off its latest round of work just recently. This is still on-going, but the workgroup's current direction also may be informative. They are looking at splitting the existing PositionOpening spec into two different documents. One would be greatly simplified and primarily intended to communicate a formatted representation of a position (even a Microformatted formatted representation) to an advertising venue or recruiting partner. This responds to one usage pattern we saw a lot of -- implementers using a thin bit of XML for the administrivia that trading partners need to know about one another and for a bit of classification of the position, but passing most of the real job content as HTML within a CDATA section. The other document they are considering is a structured PositionProfile. This would be designed for the back office computer-to-computer provisioning of one system by another with very structured, discretely fielded information describing the position. I hope some of the above makes sense. If there is interest, I can share drafts of some of the above as they become available. Best Regards, Chuck Allen HR-XML Consortium, Inc. From me at filipcte.ro Thu Mar 20 22:06:20 2008 From: me at filipcte.ro (Filip Chereches-Tosa) Date: Thu Mar 20 22:06:27 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: <47E3048A.7060805@hr-xml.org> References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> <47E3048A.7060805@hr-xml.org> Message-ID: On Mar 21, 2008, at 2:42 AM, Chuck Allen wrote: > > I hope some of the above makes sense. If there is interest, I can > share drafts of some of the above as they become available. > > Best Regards, > > Chuck Allen > HR-XML Consortium, Inc. By all means, Chuck, do share those drafts, as I'm sure many are interested in those specs. Thank you! --- Filip Chereches-Tosa +40-723-149.439 me@filipcte.ro ____________________________________ www.filipcte.ro // blog www.jobber.ro // IT jobs www.jobberbase.com // open source job board www.geekmeet.ro // Meet-ups for IT people From silviu.savin at gmail.com Fri Mar 21 00:19:44 2008 From: silviu.savin at gmail.com (Silviu Savin) Date: Fri Mar 21 00:20:12 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> <47E3048A.7060805@hr-xml.org> Message-ID: Hey, do we need a microformat that will cover every little aspect - in terms of descriptions and details that a job listing would cover? Or is it just enough to go with the most important details (structure) that an end user will find useful? Silviu Savin Creative Director www.joobs.ro On Fri, Mar 21, 2008 at 8:06 AM, Filip Chereches-Tosa wrote: > On Mar 21, 2008, at 2:42 AM, Chuck Allen wrote: > > > > I hope some of the above makes sense. If there is interest, I can > > share drafts of some of the above as they become available. > > > > Best Regards, > > > > Chuck Allen > > HR-XML Consortium, Inc. > > > By all means, Chuck, do share those drafts, as I'm sure many are > interested in those specs. > Thank you! > > > --- > Filip Chereches-Tosa > > +40-723-149.439 > me@filipcte.ro > ____________________________________ > www.filipcte.ro // blog > www.jobber.ro // IT jobs > www.jobberbase.com // open source job board > www.geekmeet.ro // Meet-ups for IT people > > _______________________________________________ > > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From dbounds at gmail.com Fri Mar 21 06:48:44 2008 From: dbounds at gmail.com (Darren Bounds) Date: Fri Mar 21 06:48:48 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: <47E3048A.7060805@hr-xml.org> References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> <47E3048A.7060805@hr-xml.org> Message-ID: <26563eca0803210748x735531a5rce14ff16f7969503@mail.gmail.com> Hi Chuck, Thanks for the insight. I'd love to see the drafts when they become available. I'm curious, how do you envision describing common job posting artifacts like 'full-time', 'part-time', 'contract' using hListing? Darren On Thu, Mar 20, 2008 at 8:42 PM, Chuck Allen wrote: > Darren Bounds wrote: > > I represent Vurv and we definitely see value in defining a job > > requisition standard which may or may not leverage existing > > Microformats but could not be contained by hListing and hCard alone. > > > Darren, > > What you say is true, but I wonder if the reason it is true is that the requisition use case isn't necessarily equivalent to the hJob or hListing > microformat use case. The latter is all about getting some semantics/structure in a browser so content can be indexed/mashed-up, etc. I think the > requisition use case is a bit different. > > In connection with the on-going HR-XML 3.0 re-architecture, our recruiting work group did a bit of survey work and analysis of the "PositionOpening" > XML instances that came in under our certification program. We found a tremendous variation in the fields used by implementers. This variation is by > industry, occupation, level of job, custom in the particular country or region, etc. My point in mentioning this is that our recent research tends to > mirror some of the wide variation documented in the job-listing wiki pages: > http://microformats.org/wiki/job-listing-brainstorming > http://microformats.org/wiki/job-listing-examples > > This recent review leads me to believe that the simpler hListing is likely a better path than the more richly descriptive hJob. If the Microformats > community were to build out everything under the job-listing brainstorming page (something approaching what might be required in a requisition), you > might be adding complexity and opportunities for variation without commensurate benefit. I think you'd have something closer to a "document format" > than a "microformat". > > The HR-XML recruiting work group kicked off its latest round of work just recently. This is still on-going, but the workgroup's current direction also > may be informative. They are looking at splitting the existing PositionOpening spec into two different documents. One would be greatly simplified and > primarily intended to communicate a formatted representation of a position (even a Microformatted formatted representation) to an advertising venue or > recruiting partner. This responds to one usage pattern we saw a lot of -- implementers using a thin bit of XML for the administrivia that trading > partners need to know about one another and for a bit of classification of the position, but passing most of the real job content as HTML within a > CDATA section. The other document they are considering is a structured PositionProfile. This would be designed for the back office > computer-to-computer provisioning of one system by another with very structured, discretely fielded information describing the position. > > I hope some of the above makes sense. If there is interest, I can share drafts of some of the above as they become available. > > Best Regards, > > Chuck Allen > HR-XML Consortium, Inc. > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Thank you, Darren Bounds From chucka at hr-xml.org Fri Mar 21 08:52:15 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Fri Mar 21 08:52:31 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: <26563eca0803210748x735531a5rce14ff16f7969503@mail.gmail.com> References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> <47E3048A.7060805@hr-xml.org> <26563eca0803210748x735531a5rce14ff16f7969503@mail.gmail.com> Message-ID: <47E3E7BF.7050400@hr-xml.org> Darren Bounds wrote: > Hi Chuck, > > Thanks for the insight. I'd love to see the drafts when they become available. > > I'm curious, how do you envision describing common job posting > artifacts like 'full-time', 'part-time', 'contract' using hListing? > > > Darren I think those are exactly the kinds of items that are likely border-line for inclusion in a microformat. I think the challenge of this is keeping the "micro" in this format. If you had to boil this down to the very essential things "a human first" and a "computer second" would search/leverage with respect to job information on the web, you are likely talking about little more than: Organization Industry Occupation classification (e.g., Accountant, Software Engineer, etc.) Location ( City, Region, PostalCode, Country, etc.) Remuneration (likely a range and or description) Competency (anyone interested in a "Wikipedia of Skills"? http://www.hr-xml.org/blog/?p=161 ) How to apply (basically hCard stuff) An HR aside (mircoformatters needn't read on) -- The "classification stuff" - 'full-time', 'part-time', 'contract' etc. - is tricky territory from an HR perspective and traditionally has been modeled in a way that munges a lot of concepts together (often in the form of a system-specific "job classification code"). I'm going to be putting a webinar on the schedule in the next month to zoom in on how we've remodeled this stuff in a much more sensible and consistent way than in the past. But I assure you (and I'm sure few on this list will doubt), our new model belongs in the back office and not in a microformat. I'll follow-up off line so we can get you connected under Vurv's membership. Best Regards, Chuck Allen HR-XML Consortium, Inc. From chucka at hr-xml.org Fri Mar 21 11:02:54 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Fri Mar 21 11:02:58 2008 Subject: [uf-new] hListing vs hJob In-Reply-To: <47E3E7BF.7050400@hr-xml.org> References: <86F2A188-24CC-4A6F-9558-6B65EB85CC86@filipcte.ro> <26563eca0803201220j5ab955d1qa8e278bd4eda5e32@mail.gmail.com> <47E3048A.7060805@hr-xml.org> <26563eca0803210748x735531a5rce14ff16f7969503@mail.gmail.com> <47E3E7BF.7050400@hr-xml.org> Message-ID: <47E4065E.5020009@hr-xml.org> Chuck Allen wrote: > If you had to boil this down to the very > essential things "a human first" and a "computer second" would > search/leverage with respect to job information on the web, you are > likely talking about little more than: > > Organization > Industry > Occupation classification (e.g., Accountant, Software Engineer, etc.) > Location ( City, Region, PostalCode, Country, etc.) > Remuneration (likely a range and or description) > Competency (anyone interested in a "Wikipedia of Skills"? > http://www.hr-xml.org/blog/?p=161 ) > How to apply (basically hCard stuff) > Noticed I left "Title" out of the above list of essential stuff (IMHO) in the scope of a job microformat that is still genuinely "micro". Chuck Allen