From mark at markwunsch.com Mon Aug 11 13:46:57 2008 From: mark at markwunsch.com (Mark Wunsch) Date: Mon Aug 11 13:47:01 2008 Subject: [uf-discuss] hRecipe implementation Message-ID: <1b7e4d860808111346od08475dpf0c6009b50d7bf8@mail.gmail.com> Hi everyone, I'm a front-end developer currently working on a high-visibility website that specializes in Food and Cooking. The team I am working with is very excited about implementing microformats. One microformat we are going to be implementing is hRecipe -- a format-in-progress according to the wiki ( http://microformats.org/wiki/recipe-brainstorming). We will be using a variation of this draft and we want to put it forward for community digestion (pun intended). This is what we will be deploying at launch and we are open to suggestions to further the format: The recipe root container is class "hrecipe" The title of the recipe is required: "recipe-title" The recipe author will use the class "author" and be written as an hcard. "recipe-summary" indicates a container for any notes or information about the recipe, including "difficulty" "cook-time" "prep-time" (Preparation time) "wait-time" (i.e. Put these in the fridge overnight) "published" (date published) "yield" (serves how many?) The ingredients should be placed within "ingredients". Within "ingredients" are "ingredient" and that is further broken up into "quantity" (which contains "unit") and "item". An ingredient can also have a note, declared by class "note". An example of note is in a recipe that calls for an ingredient to be prepared a certain way: An ingredient with a class of "option" denotes an optional ingredient, otherwise it is to be considered a required ingredient for the recipe. A recipe MUST have at least one required ingredient, however "quantity" is not required. Furthermore, within "ingredient" you can also make a class of "alternate" and include "quantity" and "item" within that. So for example, you would want a tablespoon of butter that you could substitute for margarine you would say:
  • 1 tbsp butter.
    1 tbsp margarine.
    • After ingredients, "method" is the containing class for the directions of the recipe. This MUST be present. Furthermore, you can include an image with class "photo" to be used as an image of the recipe. Recipes can be tagged with rel=tag, and license information can be shown with rel=license. We will also be integrating hReview with our recipes. We hope that by settling on these conventions and moving forward, we can help propel the hRecipe format from a brainstorming session to an in-practice specification. Thanks, Mark Wunsch mark@markwunsch.com From Michael.Smethurst at bbc.co.uk Wed Aug 13 02:33:39 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Aug 13 02:33:49 2008 Subject: [uf-discuss] hcard: additional additional names Message-ID: Hello! I'm currently working with a database that has a table of composers. The data's quite granular and gives: - personal title (can be sir or just mr, ms, etc) - first name - middle_name_1 - middle_name_2 - middle_name_3 - last_name_prefix (von, de los, van der) - last_name So my questions are: 1. can I just use middle_name_1 middle_name_2 middle_name_3? The closest thing I've seen is the andrew andrew example here: http://adactio.com/journal/1302/ Or should I use: middle_name_1 middle_name_2 middle_name_3 As suggested here: http://microformats.org/wiki/hcard-brainstorming#Implied_FN_from_N additional-name's (as found in document order) 2. is it ok to use plain old mr and ms in honorific-prefix. It's not very honorific but: http://microformats.org/wiki/hcard-examples-rfc2426#N_Example_1 Suggests that's fine 3. Should I just collapse last_name_prefix and last_name into: last_name_prefix last_name There doesn't seem to be a way of marking up last_name_prefix separately Thanks for your help Michael http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From brian.suda at gmail.com Wed Aug 13 02:50:57 2008 From: brian.suda at gmail.com (Brian Suda) Date: Wed Aug 13 02:51:01 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: Message-ID: <21e770780808130250r16e24b17pb4b57975dea161f9@mail.gmail.com> 2008/8/13, Michael Smethurst : > So my questions are: > > 1. can I just use middle_name_1 middle_name_2 > middle_name_3? > ... > Or should I use: > middle_name_1 > middle_name_2 > middle_name_3 --- there is a subtle semantic difference. The first would produce a vCard with 1 additional-name of "middle_name_1 middle_name_2 middle_name_3" whereas the second would produce 3 additional names, all comma separated "middle_name_1,middle_name_2,middle_name_3" So if the name was "Mary Pat" as an additional-name it might be 1 object, so you?d use the first method, if it was a definitely two separate names, then i would probably use the second style and mark-up each word individually. > 3. Should I just collapse last_name_prefix and last_name into: > last_name_prefix last_name > There doesn't seem to be a way of marking up last_name_prefix separately --- I am assuming you are talking about something like "Ludwig van Beethoven" were the second name is "van Beethoven". This will vary by cultures, so there is probably no hard-n-fast rules for this... is "van" part of the family name or is it additional or is it something else completely? what about MacDougal, or O?Reilly? Adding some semantics is certainly better than none, and will probably be a judgement call on your part. You are correct, with vCard there isn't any way to define last_name_prefix. I hope this helps, -brian -- brian suda http://suda.co.uk From Michael.Smethurst at bbc.co.uk Wed Aug 13 03:05:15 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed Aug 13 03:05:27 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <21e770780808130250r16e24b17pb4b57975dea161f9@mail.gmail.com> Message-ID: On 13/8/08 10:50, "Brian Suda" wrote: > 2008/8/13, Michael Smethurst : >> So my questions are: >> >> 1. can I just use middle_name_1 middle_name_2 >> middle_name_3? >> ... >> Or should I use: >> middle_name_1 >> middle_name_2 >> middle_name_3 > > --- there is a subtle semantic difference. The first would produce a > vCard with 1 additional-name of "middle_name_1 middle_name_2 > middle_name_3" whereas the second would produce 3 additional names, > all comma separated "middle_name_1,middle_name_2,middle_name_3" > > So if the name was "Mary Pat" as an additional-name it might be 1 > object, so you?d use the first method, if it was a definitely two > separate names, then i would probably use the second style and mark-up > each word individually. > >> 3. Should I just collapse last_name_prefix and last_name into: >> last_name_prefix last_name >> There doesn't seem to be a way of marking up last_name_prefix separately > > --- I am assuming you are talking about something like "Ludwig van > Beethoven" were the second name is "van Beethoven". This will vary by > cultures, so there is probably no hard-n-fast rules for this... is > "van" part of the family name or is it additional or is it something > else completely? what about MacDougal, or O?Reilly? Adding some > semantics is certainly better than none, and will probably be a > judgement call on your part. You are correct, with vCard there isn't > any way to define last_name_prefix. > > I hope this helps, Thanks brian, helps a lot > > -brian http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From Michael.Smethurst at bbc.co.uk Thu Aug 14 02:54:36 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Aug 14 02:54:45 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <21e770780808130250r16e24b17pb4b57975dea161f9@mail.gmail.com> Message-ID: On 13/8/08 10:50, "Brian Suda" wrote: > 2008/8/13, Michael Smethurst : >> 3. Should I just collapse last_name_prefix and last_name into: >> last_name_prefix last_name >> There doesn't seem to be a way of marking up last_name_prefix separately > > --- I am assuming you are talking about something like "Ludwig van > Beethoven" were the second name is "van Beethoven". This will vary by > cultures, so there is probably no hard-n-fast rules for this... is > "van" part of the family name or is it additional or is it something > else completely? what about MacDougal, or O?Reilly? Adding some > semantics is certainly better than none, and will probably be a > judgement call on your part. You are correct, with vCard there isn't > any way to define last_name_prefix. This gets a bit tricky cos some family name prefixes (Mc, Mac, Fitz, O') stay attached to the family name when listing alphabetically. So you see: Macfarren, George O'Connor, Mark But some detach: Beethoven, Ludwig van In the database I'm working with O' and Mac and etc are part of the family name but von, van, le are in a separate 'family-name-prefix' I've had a look around but can't find any label to differentiate between attached and detached prefixes so for now I'm going with:
  • Beethoven, Ludwig van
    • On listings pages and:

    Ludwig van Beethoven

    On ludwig's page It means that Ludwig loses his van on operator export but I guess he won't complain. Is family-name-prefix a good label here? Can we agree a better one. Realise this isn't strictly a UF question but maybe a posh one?!? Further reading here: http://www.library.yale.edu/cataloging/music/pernames.htm (no anchors - search for surnames with prefix) http://www.library.yale.edu/cataloging/music/entryele.htm > > I hope this helps, > > -brian http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From jim at eatyourgreens.org.uk Thu Aug 14 04:19:37 2008 From: jim at eatyourgreens.org.uk (jim@eatyourgreens.org.uk) Date: Thu Aug 14 04:19:41 2008 Subject: [uf-discuss] hcard: additional additional names Message-ID: <380-220088414111937178@M2W005.mail2web.com> Hi, O'Connor ought to be listed under C in an alphabetical list, although that rule's not applied very strictly any more. Otherwise Irish phonebooks would be nothing but O :) Certainly I remember that my name was under D on the register at school. Cheers Jim O'Donnell Original Message: ----------------- From: Michael Smethurst Michael.Smethurst@bbc.co.uk Date: Thu, 14 Aug 2008 10:54:36 +0100 To: microformats-discuss@microformats.org Subject: Re: [uf-discuss] hcard: additional additional names On 13/8/08 10:50, "Brian Suda" wrote: > 2008/8/13, Michael Smethurst : This gets a bit tricky cos some family name prefixes (Mc, Mac, Fitz, O') stay attached to the family name when listing alphabetically. So you see: Macfarren, George O'Connor, Mark -------------------------------------------------------------------- mail2web.com ? What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint From brian.suda at gmail.com Thu Aug 14 04:32:07 2008 From: brian.suda at gmail.com (Brian Suda) Date: Thu Aug 14 04:32:11 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: <21e770780808130250r16e24b17pb4b57975dea161f9@mail.gmail.com> Message-ID: <21e770780808140432g2e2f1f34o227418c6f620b43@mail.gmail.com> 2008/8/14, Michael Smethurst : > On listings pages and: > >

    > > Ludwig > van > Beethoven > >

    > > On ludwig's page > > It means that Ludwig loses his van on operator export but I guess he won't > complain. --- you could solve this by nesting the spans as well. van Beethoven This way, you are still adding POSH to the 'van' prefix, but it will get exported to Operator together with the family-name. Unless this would be a violation of the semantics of "family-name", but i think in this case the nesting would be ok. -brian -- brian suda http://suda.co.uk From Michael.Smethurst at bbc.co.uk Thu Aug 14 04:43:48 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Aug 14 04:43:57 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <380-220088414111937178@M2W005.mail2web.com> Message-ID: Hi Jim Unfortunately the data I'm working with would have O'Connor as one field and the sort letter would be 0. So you'd appear on ../o I fear But even if you were indexed as D and appeared under ../d you'd appear there as: O'Donnell, Jim And not: Donnell, Jim O' Whereas beethoven has van as a separate field and an index letter of B. So he appear under ../b as: Beethoven, Ludwig van Talking to colleagues with more library background than me the attachment/detachment does appear to be subject to enormous cultural variation particularly with van and vons In the meantime are people happy with class="family-name-prefix" as a way of marking up ludwig's van? I'll go now before I add any more confusion On 14/8/08 12:19, "jim@eatyourgreens.org.uk" wrote: > Hi, > > O'Connor ought to be listed under C in an alphabetical list, although that > rule's not applied very strictly any more. Otherwise Irish phonebooks would > be nothing but O :) > > Certainly I remember that my name was under D on the register at school. > > Cheers > Jim O'Donnell > > Original Message: > ----------------- > From: Michael Smethurst Michael.Smethurst@bbc.co.uk > Date: Thu, 14 Aug 2008 10:54:36 +0100 > To: microformats-discuss@microformats.org > Subject: Re: [uf-discuss] hcard: additional additional names > > > > > > On 13/8/08 10:50, "Brian Suda" wrote: > >> 2008/8/13, Michael Smethurst : > > > This gets a bit tricky cos some family name prefixes (Mc, Mac, Fitz, O') > stay attached to the family name when listing alphabetically. So you see: > > Macfarren, George > O'Connor, Mark > > > > -------------------------------------------------------------------- > mail2web.com ? What can On Demand Business Solutions do for you? > http://link.mail2web.com/Business/SharePoint > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From Michael.Smethurst at bbc.co.uk Thu Aug 14 04:50:47 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Aug 14 04:50:57 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <21e770780808140432g2e2f1f34o227418c6f620b43@mail.gmail.com> Message-ID: On 14/8/08 12:32, "Brian Suda" wrote: > 2008/8/14, Michael Smethurst : >> On listings pages and: >> >>

    >> >> Ludwig >> van >> Beethoven >> >>

    >> >> On ludwig's page >> >> It means that Ludwig loses his van on operator export but I guess he won't >> complain. > > --- you could solve this by nesting the spans as well. > > > van > Beethoven > Cool, I'll do this on the person page and leave him slightly broke on the listings where the nesting isn't possible cos of the separation Beethoven, Ludwig van I've asked around and the label "Onomastic prefix" has been suggested: http://www.listservicedirect.com/ethnic_religious.html But again it doesn't seem to differentiate between attached and detached prefixes So I'll stick with family-name-prefix for now (it's easier to spell for one) unless anyone has a better idea > > This way, you are still adding POSH to the 'van' prefix, but it will > get exported to Operator together with the family-name. Unless this > would be a violation of the semantics of "family-name", but i think in > this case the nesting would be ok. > > -brian http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From mail at tobyinkster.co.uk Thu Aug 14 05:36:57 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Aug 14 05:56:53 2008 Subject: [uf-discuss] hcard: additional additional names Message-ID: <2CE85AD7-CB89-4591-B205-66676A7E280E@tobyinkster.co.uk> > But some detach: > Beethoven, Ludwig van Ludwig van Beethoven -- Toby A Inkster From Michael.Smethurst at bbc.co.uk Thu Aug 14 06:53:13 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Aug 14 06:53:22 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <2CE85AD7-CB89-4591-B205-66676A7E280E@tobyinkster.co.uk> Message-ID: On 14/8/08 13:36, "Toby A Inkster" wrote: >> But some detach: >> Beethoven, Ludwig van > > > Ludwig > > van > Beethoven > > But as I said earlier on listing pages it should be Beecham, Thomas Beethoven, Ludwig van Behrend Bell, W H Bell, Joshua http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From mail at tobyinkster.co.uk Thu Aug 14 07:23:34 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Aug 14 07:24:04 2008 Subject: [uf-discuss] hcard: additional additional names Message-ID: > But as I said earlier on listing pages it should be > Beethoven, Ludwig van Not especially pretty, but: Beethoven, Ludwig van -- Toby A Inkster From jrrodgers at gmail.com Thu Aug 14 07:35:12 2008 From: jrrodgers at gmail.com (Jesse Rodgers) Date: Thu Aug 14 07:35:15 2008 Subject: [uf-discuss] Microformats research Message-ID: <88190c0f0808140735j7f705cdt2da539a09b75bf5b@mail.gmail.com> Hi, A little while ago I posted a version of my Masters research paper on Microformats in Higher Education: http://whoyoucallingajesse.com/past/2008/7/16/a_look_at_microformats_for/ One thing I didn't cover in my research was a set of use cases. My goal was to try and establish/apply a decent way to assess content and try and identify any unique patterns. I only looked at home pages in the interest of getting it done but there is a lot more research that could be done if anyone was so inclined and/or found it useful. >From the experience I learned a few things: - the microformats wiki creates a problem for academic papers - wiki content (arguably most web based content that isn't a published paper) needs to be copy/pasted into an appendix, the wiki doesn't make that easy. I had to reformat a lot of text in MS Word... - John Allsopp's book and a handful of articles was all I could find that was directly related and published -- John's book made life easier ;) - most microformats 'research' (at the time) explained what they are not looking at how they may be really useful - that requires someone figures out a way to assess 'value' I think - academic research can be fun, the process not so much I thought some folks might find the bibliography useful at the very least... I did finally post some use cases for higher education as well: http://whoyoucallingajesse.com/past/2008/8/14/how_can_microformats_help_higher/ ...and I still think course information (found in what is called a course calendar or catalogue) needs its own format. But that is a discussion for another time... Jesse From martin at weborganics.co.uk Thu Aug 14 07:48:09 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Aug 14 07:48:16 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: Message-ID: <48A445A9.4010106@weborganics.co.uk> Hello Michael Michael Smethurst wrote: > > On 14/8/08 12:32, "Brian Suda" wrote: > > >> 2008/8/14, Michael Smethurst : >> >>> On listings pages and: >>> >>>

    >>> >>> Ludwig >>> van >>> Beethoven >>> >>>

    >>> >>> On ludwig's page >>> >>> It means that Ludwig loses his van on operator export but I guess he won't >>> complain. >>> >> --- you could solve this by nesting the spans as well. >> >> >> van >> Beethoven >> >> > > Cool, I'll do this on the person page and leave him slightly broke on the > listings where the nesting isn't possible cos of the separation > Beethoven, Ludwig van > > I've asked around and the label "Onomastic prefix" has been suggested: > > http://www.listservicedirect.com/ethnic_religious.html > > But again it doesn't seem to differentiate between attached and detached > prefixes > > So I'll stick with family-name-prefix for now (it's easier to spell for one) > unless anyone has a better idea > *family-name-preposition* is probably more accurate to what you are trying to describe "von" in dutch simply means "of" or "from", "O" as in "O'Donnell", in Irish means "descendant of" or "grandson of" (in Gaelic Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as in "FitzGerald" is an Irish hash of the french "fils de" which also means "son of". What I am trying to say is any of these prefixes simply mean "of" and shouldn't really be considered part of their family name although they mostly are, think "Van Gough" would you know who I meant if I just said "Gough"? Best wishes Martin McEvoy > > >> This way, you are still adding POSH to the 'van' prefix, but it will >> get exported to Operator together with the family-name. Unless this >> would be a violation of the semantics of "family-name", but i think in >> this case the nesting would be ok. >> >> -brian >> > > > http://www.bbc.co.uk/ > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From Michael.Smethurst at bbc.co.uk Thu Aug 14 07:59:39 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Aug 14 07:59:49 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: Message-ID: On 14/8/08 15:23, "Toby A Inkster" wrote: >> But as I said earlier on listing pages it should be >> Beethoven, Ludwig van > > Not especially pretty, but: > > Beethoven, > > Ludwig > > van > > > Eeeuuurrgghhhh! Interestingly I don't know if the new BBC standards allow for the use of the include pattern or not. It's a design pattern rather than a uf so doesn't have draft / specification status but I know it's not supported by various parsers so I assume it's draft-ish The standards mandate against using draft ufs. Don't know how the include pattern fits into this.... Looks ugly tho ;-) http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From mail at tobyinkster.co.uk Thu Aug 14 08:20:53 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Aug 14 08:21:23 2008 Subject: [uf-discuss] hcard: additional additional names Message-ID: <9A609EAE-5D3E-4FA4-BA2E-C0DA6D7D7AF8@tobyinkster.co.uk> > Eeeuuurrgghhhh! Well, I did warn that it was not pretty. The sort of hCard that might be found at goatse.cx perhaps. Using my own suggested alternative to the include pattern, it would be: Beethoven, Ludwig van http://microformats.org/wiki/include-pattern-strawman#Non- Verbose_Class-Based_Solution -- Toby A Inkster From tantek at cs.stanford.edu Thu Aug 14 12:04:51 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Thu Aug 14 12:04:54 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <48A445A9.4010106@weborganics.co.uk> References: <48A445A9.4010106@weborganics.co.uk> Message-ID: <60cb038a0808141204tac7d416k592256c68ff35021@mail.gmail.com> On Thu, Aug 14, 2008 at 7:48 AM, Martin McEvoy wrote: > Hello Michael > > Michael Smethurst wrote: >> >> On 14/8/08 12:32, "Brian Suda" wrote: >>> >>> 2008/8/14, Michael Smethurst : >>>> >>>> van ... >> >> I've asked around and the label "Onomastic prefix" has been suggested: >> >> http://www.listservicedirect.com/ethnic_religious.html >> >> But again it doesn't seem to differentiate between attached and detached >> prefixes >> >> So I'll stick with family-name-prefix for now (it's easier to spell for >> one) >> unless anyone has a better idea >> > > *family-name-preposition* is probably more accurate to what you are trying > to describe "von" in dutch simply means "of" or "from", "O" as in > "O'Donnell", in Irish means "descendant of" or "grandson of" (in Gaelic > Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as in > "FitzGerald" is an Irish hash of the french "fils de" which also means "son > of". What I am trying to say is any of these prefixes simply mean "of" and > shouldn't really be considered part of their family name although they > mostly are, think "Van Gough" would you know who I meant if I just said > "Gough"? > > > Best wishes > > Martin McEvoy Jim O'Donnell (and others), This is the most knowledgable discussion I've seen yet of any extension / decomposition of family-name. As we're not (currently) adding any properties to hCard beyond what is in vCard, there isn't a format solution for this. However, we are *documenting* possible extensions to vCard properties here in the hopes that suggestions with sufficient merit may make it into an update of vCard (which we could then add to hCard) : http://microformats.org/wiki/vcard-suggestions I encourage you to add your suggestion of a family-name prefix or preposition etc. to that page, perhaps in the new sub-properties section: http://microformats.org/wiki/vcard-suggestions#Suggestions_for_New_Sub-properties In the meantime, the POSH approach is a good one. Thanks, Tantek From jim at eatyourgreens.org.uk Thu Aug 14 15:21:21 2008 From: jim at eatyourgreens.org.uk (Jim O'Donnell) Date: Thu Aug 14 15:21:26 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: Message-ID: <932D9790-6685-4DBE-9D51-6904CB2DE321@eatyourgreens.org.uk> Hi MIchael, > > > Unfortunately the data I'm working with would have O'Connor as one > field and > the sort letter would be 0. So you'd appear on ../o I fear > > But even if you were indexed as D and appeared under ../d you'd > appear > there as: > > O'Donnell, Jim > That's fine - that's exactly how it should be written. The surname is written O'Donnell (not Donnell) but is indexed/sorted under D. > And not: > > Donnell, Jim O' > > Whereas beethoven has van as a separate field and an index letter > of B. So > he appear under ../b as: > > Beethoven, Ludwig van > > > Talking to colleagues with more library background than me the > attachment/detachment does appear to be subject to enormous cultural > variation particularly with van and vons I had a quick look through some of our Dutch items at work. The way names are displayed varies between catalogues. Sometimes the surname is listed without the 'Van': http://www.nmm.ac.uk/collections/search/listResults.cfm?Maker=Keulen% 2C%20Johannes%20van&SortBy=maker Sometimes with http://www.nmm.ac.uk/collections/prints/listPrints.cfm? filter=makers&node=8767 and sometimes the name is simply written out as it would be spoken: http://www.nmm.ac.uk/collections/explore/people.cfm/id/22357 I don't know if that helps, or just makes the whole situation more confusing. I imagine Spanish names, with the matrimonial surname, must be fun to deal with too :) Jim Jim O'Donnell jim@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens From paul.m.wilkins at gmail.com Thu Aug 14 15:38:49 2008 From: paul.m.wilkins at gmail.com (Paul Wilkins) Date: Thu Aug 14 16:03:00 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <932D9790-6685-4DBE-9D51-6904CB2DE321@eatyourgreens.org.uk> References: <932D9790-6685-4DBE-9D51-6904CB2DE321@eatyourgreens.org.uk> Message-ID: On Fri, Aug 15, 2008 at 10:21 AM, Jim O'Donnell wrote: > That's fine - that's exactly how it should be written. The surname is > written O'Donnell (not Donnell) but is indexed/sorted under D. This means that the surname is properly supposed to be "O'Donnell" and we should not care about sorting details. That job should be left to be implemented by some other system. -- Paul Wilkins From chucka at hr-xml.org Thu Aug 14 17:48:08 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Thu Aug 14 17:48:14 2008 Subject: [Fwd: Re: [Fwd: Re: [uf-discuss] hcard: additional additional names]] Message-ID: <48A4D248.9060900@hr-xml.org> Martin suggested I go pass this on for those interested in names. The first doc has some background on representing custom/approaches to handling names in Saudia Arabia and UAE whereas the second covers a good cross-section of Europe and Asia: http://docs.hr-xml.org/resources/PersonNameReferenceExamplesKSAUAE_final_.pdf http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/PersonName.html#_Toc127535930 Chuck Allen -------- Original Message -------- Subject: Re: [Fwd: Re: [uf-discuss] hcard: additional additional names] Date: Fri, 15 Aug 2008 01:14:45 +0100 From: Martin McEvoy To: chucka@hr-xml.org CC: mail@tobyinkster.co.uk References: <48A48EC5.7020404@hr-xml.org> Hello Chuck Nice to hear from you... Chuck Allen wrote: > I'm sending this off line since Tantek seemed to signal it was time to > take this to the wiki - I was just about to share some relevant > research -- > some pertaining to Saudi names that was just contributed to HR-XML. > See below. > Hope this proves useful. > > http://docs.hr-xml.org/resources/PersonNameReferenceExamplesKSAUAE_final_.pdf > > > http://ns.hr-xml.org/2_5/HR-XML-2_5/CPO/PersonName.html#_Toc127535930 > > Chuck Allen I have just read your work, this is great stuff , informative, you *should* post this to the list as others no doubt will be very interested in this study, Just what I was looking for ;) Best wishes Martin McEvoy From lisagoodlin at gmail.com Thu Aug 14 17:51:52 2008 From: lisagoodlin at gmail.com (Lisa Goodlin) Date: Thu Aug 14 17:51:56 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <48A445A9.4010106@weborganics.co.uk> Message-ID: On 8/14/08 10:48 AM, "Martin McEvoy" wrote: > *family-name-preposition* is probably more accurate to what you are > trying to describe "von" in dutch simply means "of" or "from", "O" as in > "O'Donnell", in Irish means "descendant of" or "grandson of" (in > Gaelic Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as > in "FitzGerald" is an Irish hash of the french "fils de" which also > means "son of". What I am trying to say is any of these prefixes simply > mean "of" and shouldn't really be considered part of their family name > although they mostly are, think "Van Gough" would you know who I meant > if I just said "Gough"? And that's why art historians refer to "Leonardo" and turn away in disgust when people say "da Vinci." From martin at weborganics.co.uk Thu Aug 14 17:52:59 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Aug 14 17:53:07 2008 Subject: [uf-discuss] rel-ecolabel Message-ID: <48A4D36B.6020304@weborganics.co.uk> Hello all http://microformats.org/wiki/Main_Page#Drafts rel-ecolabel - for indicating ecolabelled products/services/companies I didnt know there was such a thing! when did this get to Draft? I dont remember any discussion about ecolabels? can someone point me to the discussion please I have been a bit slow on this one. Thanks Martin McEvoy From tantek at cs.stanford.edu Thu Aug 14 18:53:00 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Thu Aug 14 18:53:02 2008 Subject: [uf-discuss] rel-ecolabel In-Reply-To: <48A4D36B.6020304@weborganics.co.uk> References: <48A4D36B.6020304@weborganics.co.uk> Message-ID: <60cb038a0808141853o2c33e815v1a40b4b3a8108280@mail.gmail.com> On Thu, Aug 14, 2008 at 5:52 PM, Martin McEvoy wrote: > Hello all > > http://microformats.org/wiki/Main_Page#Drafts > > rel-ecolabel - for indicating > ecolabelled products/services/companies > > > I didnt know there was such a thing! when did this get to Draft? I dont > remember any discussion about ecolabels? can someone point me to the > discussion please I have been a bit slow on this one. I didn't see any discussion either, and the proposer who added it to the drafts section clearly failed to read the introduction or how-to-play or process or anything else above where they added it on the Main_Page. Moved to a new section in exploratory discussions (along with a few others, more to follow I'm sure). http://microformats.org/wiki/exploratory-discussions#failed_to_follow_process Tantek -- http://tantek.com/ From martin at weborganics.co.uk Fri Aug 15 01:31:02 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 15 01:31:09 2008 Subject: [uf-discuss] rel-ecolabel In-Reply-To: <60cb038a0808141853o2c33e815v1a40b4b3a8108280@mail.gmail.com> References: <48A4D36B.6020304@weborganics.co.uk> <60cb038a0808141853o2c33e815v1a40b4b3a8108280@mail.gmail.com> Message-ID: <48A53EC6.60803@weborganics.co.uk> Hello Tantek Tantek ?elik wrote: > On Thu, Aug 14, 2008 at 5:52 PM, Martin McEvoy wrote: > >> Hello all >> >> http://microformats.org/wiki/Main_Page#Drafts >> >> rel-ecolabel - for indicating >> ecolabelled products/services/companies >> >> >> I didnt know there was such a thing! when did this get to Draft? I dont >> remember any discussion about ecolabels? can someone point me to the >> discussion please I have been a bit slow on this one. >> > > I didn't see any discussion either, and the proposer who added it to > the drafts section clearly failed to read the introduction or > how-to-play or process or anything else above where they added it on > the Main_Page. > Phew! I thought I had fallen asleep there and missed something :) > Moved to a new section in exploratory discussions (along with a few > others, more to follow I'm sure). > > http://microformats.org/wiki/exploratory-discussions#failed_to_follow_process > Good > Tantek > Best Wishes Martin McEvoy From martin at weborganics.co.uk Fri Aug 15 01:39:44 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 15 01:39:51 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: Message-ID: <48A540D0.9090400@weborganics.co.uk> Hello Lisa Lisa Goodlin wrote: > On 8/14/08 10:48 AM, "Martin McEvoy" wrote: > > > >> *family-name-preposition* is probably more accurate to what you are >> trying to describe "von" in dutch simply means "of" or "from", "O" as in >> "O'Donnell", in Irish means "descendant of" or "grandson of" (in >> Gaelic Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as >> in "FitzGerald" is an Irish hash of the french "fils de" which also >> means "son of". What I am trying to say is any of these prefixes simply >> mean "of" and shouldn't really be considered part of their family name >> although they mostly are, think "Van Gough" would you know who I meant >> if I just said "Gough"? >> > > And that's why art historians refer to "Leonardo" and turn away in disgust > when people say "da Vinci." > I have never considered that, a good point on differences in peoples names in popular culture, I quite like being on first name terms with artists, makes me feel like I am their buddy or something :-) Thanks Martin McEvoy > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mail at ciaranmcnulty.com Fri Aug 15 09:05:20 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Aug 15 09:05:25 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <48A540D0.9090400@weborganics.co.uk> References: <48A540D0.9090400@weborganics.co.uk> Message-ID: To add to the confusion I'll throw a few more data points in. 'Mc' prefixes are historically contractions of 'Mac', and names often get the prefixes dropped. I've seen the names McNulty, Nulty and MacNulty listed in surname lists: a) Separately as you'd expect alphabetically b) All together under N c) Nulty separately with McNulty and MacNulty listed together in a separate Mc section after the M section. That said I think sorting is a bit out of scope for hCard and would consider O'-, Fitz-, Mc- and Mac- prefixes to be parts of surnames, nowadays. -Ciaran McNulty From chris.messina at gmail.com Sat Aug 16 09:41:40 2008 From: chris.messina at gmail.com (Chris Messina) Date: Sat Aug 16 09:41:46 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats Message-ID: <1bc4603e0808160941l7c279a31v3f04026393394240@mail.gmail.com> It's funny, since this was posted to the list June 5 of last year (NetNewsWire 3 supports microformats): http://microformats.org/discuss/mail/microformats-discuss/2007-June/009777.html But now, turns out that future versions of NNW will no longer support microformat detection: http://microformatique.com/?p=266 http://inessential.com/?comments=1&postid=3514 Judging from discussions around this decision (on a private mailing list), there seems to be little real value from this feature in NetNewsWire, a very popular feed reader for the Mac. On the one hand, it's hard to argue with the detractors who point out that there's actually little microformatted content in feeds (NNW only detects hcalendar and hcard -- the most widely deployed microformats) and that even when such content shows up, adding hcards to your address book, or clicking the Add to Calendar button provided by NNW is hardly beneficial when feeds that have an iCal equivalent either tack it on as an enclosure or link off to a remotely hosted .ics file... basically making the embedded hcalendar redundant (though arguably still best practice). I have a lot of respect for Brent Simmons -- and his choice to *remove* microformats after he'd been convinced (and had decided) to add them really concerns me. To the best of my knowledge, there are few if any other aggregators that support microformats consumption -- and fewer still that expose an end-user interface [1] for converting microformatted content on the client side. This makes me reconsider some things. * Are microformats valuable in client-side applications? * Should their presence be made known to end-users? Where there is data that can be converted, should an interface be provided to do so? * Does the slight overhead/performance hit that parsing HTML to look for microformatted content in feeds outweigh their benefits (performance was cited as one gain from removing the parsing code) * Is parsing microformats, given their fluid nature and lack of concrete specificity (compared with more machine-friendly formats like JSON or XML), too burdensome for developers who have the choice of alternative, machine-friendly formats? Do the availability of parsing libraries allay this burden? Where we lack libraries in certain languages, would the existence of such libraries help to promote wider microformats adoption? * Have we actually identified valuable use cases for microformats in client-side applications? * Is adding hcards to address books and hcalendars to calendars really the best possible value of adding microformats parsing to an application? If not, what other application has demonstrated additional, or different, value? For my own part, I think that Apple's data detectors concept [2] is probably the most compelling example where embedded microformatted content could be useful -- at least in terms of reducing ambiguity or increasing accuracy (if an ADD picks up the term "yesterday" without context, an embedded microformat that follows that date-pattern could provide absolute time values). Additionally, we see Microsoft flirting with support for microformats with the addition of "hSlice" detection in IE8... so there is, conceptually, hope -- although hSlice sadly didn't come out of this community, but one company's bastardization of hAtom. I also see benefits for improvements for client-side search... and this is something that I'd like to propose to Brent... and that I had intended for Flock [3]: Apple's Spotlight is able to pull out data from documents by file type, rather than object type. Microformats like hcard and hcalendar provide hooks that would allow client-side search to differentiate objects, or to allow you to divide and conquer, as it were, for example, if you were searching for a person... you could search by author, by name, by address, etc... and locate related biographical information were the data formatted as an hcard. Anyway, the news got me noodling, and I'm curious what other folks think. Chris [1] http://www.newsgator.com/img/ss/nnw_microformats.png [2] http://miramontes.com/portfolio/add/ [3] http://flickr.com/photos/factoryjoe/75389965/ -- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private From mdagn at spraci.com Sun Aug 17 04:12:08 2008 From: mdagn at spraci.com (MichaelMD) Date: Sun Aug 17 04:12:12 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats In-Reply-To: <1bc4603e0808160941l7c279a31v3f04026393394240@mail.gmail.com> References: <1bc4603e0808160941l7c279a31v3f04026393394240@mail.gmail.com> Message-ID: <1218971528.10681.107.camel@droid2> > > http://microformats.org/discuss/mail/microformats-discuss/2007-June/009777.html > > But now, turns out that future versions of NNW will no longer support > microformat detection: > > http://microformatique.com/?p=266 > http://inessential.com/?comments=1&postid=3514 > > Judging from discussions around this decision (on a private mailing > list), there seems to be little real value from this feature in > NetNewsWire, a very popular feed reader for the Mac. > > On the one hand, it's hard to argue with the detractors who point out > that there's actually little microformatted content in feeds (NNW only > detects hcalendar and hcard -- the most widely deployed microformats) > and that even when such content shows up, adding hcards to your > address book, or clicking the Add to Calendar button provided by NNW > is hardly beneficial when feeds that have an iCal equivalent either > tack it on as an enclosure or link off to a remotely hosted .ics > file... basically making the embedded hcalendar redundant (though > arguably still best practice). but removing it? ... how about giving the users a choice of whether to use this feature? btw I've seen a lot more hCalendar items in RSS feeds than I have seen iCal links in enclosures. I don't think having to fetch another file for each event just to get the date of the event is a good solution! ... and what if someone wants to mark up the city/country where the event is happening? ... in hCalendar it can be done by using hCard/adr/geo inside "location" but can anything like that be done in iCal? From mail at tobyinkster.co.uk Sun Aug 17 05:03:58 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Aug 17 05:04:29 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats Message-ID: <28AF2369-5C03-46F4-B01B-1A5B0972023D@tobyinkster.co.uk> I've been using NNW since January and don't think I've ever used the microformat icons in it, so I can't say I'm bothered that it's gone. In 95% of cases, you could probably just open the article link in your browser and find the microformat there anyway. I do notice that NNW can call external applescripts. I don't know much applescript, but I imagine that it would only take a dozen lines or so to connect to a Cognition daemon running on a local TCP port and do something useful. :-) > but removing it? ... > how about giving the users a choice of whether to use this feature? As I understand it the motivation to remove it was not a matter of UI clutter, but to cut out chunks of source code, speeding the application up, slimming it down and removing dependance on a rather ugly API. Making it an optional feature thus wouldn't achieve the objectives. -- Toby A Inkster From andr3.pt at gmail.com Sun Aug 17 06:08:52 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Sun Aug 17 06:08:55 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats In-Reply-To: <1218971528.10681.107.camel@droid2> References: <1bc4603e0808160941l7c279a31v3f04026393394240@mail.gmail.com> <1218971528.10681.107.camel@droid2> Message-ID: IMHO, what this highlights is the need to push adoption of plugins that make it easier to publish microformatted html in blog posts and such. A few of us who write posts by hand, have no problem sprinkling microformats in our posts, but to become common place, we need to have the mainstream bloggers using this... and this calls for widgets that help publishing microformats. http://microformats.org/wiki/wordpress-plugins -- Andr? Lu?s On Sun, Aug 17, 2008 at 12:12 PM, MichaelMD wrote: > >> >> http://microformats.org/discuss/mail/microformats-discuss/2007-June/009777.html >> >> But now, turns out that future versions of NNW will no longer support >> microformat detection: >> >> http://microformatique.com/?p=266 >> http://inessential.com/?comments=1&postid=3514 >> >> Judging from discussions around this decision (on a private mailing >> list), there seems to be little real value from this feature in >> NetNewsWire, a very popular feed reader for the Mac. >> >> On the one hand, it's hard to argue with the detractors who point out >> that there's actually little microformatted content in feeds (NNW only >> detects hcalendar and hcard -- the most widely deployed microformats) >> and that even when such content shows up, adding hcards to your >> address book, or clicking the Add to Calendar button provided by NNW >> is hardly beneficial when feeds that have an iCal equivalent either >> tack it on as an enclosure or link off to a remotely hosted .ics >> file... basically making the embedded hcalendar redundant (though >> arguably still best practice). > > but removing it? ... > how about giving the users a choice of whether to use this feature? > > > > > btw I've seen a lot more hCalendar items in RSS feeds than I have seen > iCal links in enclosures. > > I don't think having to fetch another file for each event just to get > the date of the event is a good solution! > > ... and what if someone wants to mark up the city/country where the > event is happening? ... in hCalendar it can be done by using > hCard/adr/geo inside "location" but can anything like that be done in > iCal? > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From lists at ben-ward.co.uk Sun Aug 17 11:24:56 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Sun Aug 17 11:25:13 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats In-Reply-To: <1bc4603e0808160941l7c279a31v3f04026393394240@mail.gmail.com> References: <1bc4603e0808160941l7c279a31v3f04026393394240@mail.gmail.com> Message-ID: I'm also a long time NNW user, and haven't seen the Microformats UI in over a year. On 16 Aug 2008, at 09:41, Chris Messina wrote: > * Are microformats valuable in client-side applications? > * Should their presence be made known to end-users? Where there is > data that can be converted, should an interface be provided to do so? > * Is adding hcards to address books and hcalendars to calendars really > the best possible value of adding microformats parsing to an > application? If not, what other application has demonstrated > additional, or different, value? I don't think it takes much argument to say that microformats can and will be useful in client UI, but the NNW UI specifically was not the right solution. I think there's potential to do far more ambitious UI that used microformats which would be far more useful to end users and more inspiring to authors. NNW has a source list down the left hand side with ?Latest News?, ?Flagged Items? and ?Clippings?. An ?Upcoming Events? item in there, generated from hCalendar in feeds (and optionally exposed to iCal as well) would, in my brain-farting mode, be a far more engaging prospect for users and publishers. The NNW UI was a great little experiment, but authors need more substantial ideas to encourage them to publish more. If Newsgator were saying ?use hCalendar ? it's a standard!? and link it to some UI in their software, I think they'd get interest. B From tantek at cs.stanford.edu Sun Aug 17 13:12:28 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Sun Aug 17 13:12:58 2008 Subject: Download NNW 3.1 while you still can (was Re: [uf-discuss] NetNewsWire ditches support for microformats) Message-ID: <1565218067-1219003967-cardhu_decombobulator_blackberry.rim.net-1280577096-@bxe017.bisx.prod.on.blackberry> Ben Ward wrote: >I'm also a long time NNW user, and haven't seen the Microformats UI in over a year. I see it every time Jeremy Keith posts. You may find some in my infrequent blog posts also. That being said I agree we need to encourage simpler blog post authoring interfaces that enable and encourage more semantic publishing. Please contribute tips, suggestions, wants to the CMSs of your choice: http://microformats.org/wiki/cms For now, I recommend everyone download NNW v3.1 (with microformats support) while it is still available. I've add NNW 3.2 to my own personal warning page: http://tantek.pbwiki.com/UpgradesToAvoid Tantek From mdagn at spraci.com Mon Aug 18 03:09:22 2008 From: mdagn at spraci.com (Michael MD) Date: Mon Aug 18 03:09:29 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats References: <1bc4603e0808160941l7c279a31v3f04026393394240@mail.gmail.com><1218971528.10681.107.camel@droid2> Message-ID: <002001c9011a$7d428a20$116bacca@COMCEN> > IMHO, what this highlights is the need to push adoption of plugins > that make it easier to publish microformatted html in blog posts and > such. > > A few of us who write posts by hand, have no problem sprinkling > microformats in our posts, but to become common place, we need to have > the mainstream bloggers using this... and this calls for widgets that > help publishing microformats. > > http://microformats.org/wiki/wordpress-plugins > good point - I remember seeing the "Structured Blogging" plugin for Wordpress a few years ago ... I'll have to check out some of those others.. ..maybe something could be ported to other popular CMS (eg Drupal, Xoops, Joomla, phpBB, etc)? From tdrake at yahoo-inc.com Mon Aug 18 08:03:23 2008 From: tdrake at yahoo-inc.com (Ted Drake) Date: Mon Aug 18 08:03:30 2008 Subject: [uf-discuss] hRecipe implementation In-Reply-To: <1b7e4d860808111346od08475dpf0c6009b50d7bf8@mail.gmail.com> References: <1b7e4d860808111346od08475dpf0c6009b50d7bf8@mail.gmail.com> Message-ID: <006001c90143$8f7fe510$f172480a@ds.corp.yahoo.com> Hi During one of the internal Yahoo Hack Days, I created an hrecipe format prototype for Yahoo Food. I'd be happy to share what I put together. I wouldn't call it finished, but it may give you some ideas and would be good to synch. Ted Drake Yahoo -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Mark Wunsch Sent: Monday, August 11, 2008 1:47 PM To: microformats-discuss@microformats.org Subject: [uf-discuss] hRecipe implementation Hi everyone, I'm a front-end developer currently working on a high-visibility website that specializes in Food and Cooking. The team I am working with is very excited about implementing microformats. One microformat we are going to be implementing is hRecipe -- a format-in-progress according to the wiki ( http://microformats.org/wiki/recipe-brainstorming). We will be using a variation of this draft and we want to put it forward for community digestion (pun intended). This is what we will be deploying at launch and we are open to suggestions to further the format: The recipe root container is class "hrecipe" The title of the recipe is required: "recipe-title" The recipe author will use the class "author" and be written as an hcard. "recipe-summary" indicates a container for any notes or information about the recipe, including "difficulty" "cook-time" "prep-time" (Preparation time) "wait-time" (i.e. Put these in the fridge overnight) "published" (date published) "yield" (serves how many?) The ingredients should be placed within "ingredients". Within "ingredients" are "ingredient" and that is further broken up into "quantity" (which contains "unit") and "item". An ingredient can also have a note, declared by class "note". An example of note is in a recipe that calls for an ingredient to be prepared a certain way:
    • 4 cups sliced, peeled peaches
    An ingredient with a class of "option" denotes an optional ingredient, otherwise it is to be considered a required ingredient for the recipe. A recipe MUST have at least one required ingredient, however "quantity" is not required. Furthermore, within "ingredient" you can also make a class of "alternate" and include "quantity" and "item" within that. So for example, you would want a tablespoon of butter that you could substitute for margarine you would say:
  • 1 tbsp butter.
    1 tbsp margarine.
    • After ingredients, "method" is the containing class for the directions of the recipe. This MUST be present. Furthermore, you can include an image with class "photo" to be used as an image of the recipe. Recipes can be tagged with rel=tag, and license information can be shown with rel=license. We will also be integrating hReview with our recipes. We hope that by settling on these conventions and moving forward, we can help propel the hRecipe format from a brainstorming session to an in-practice specification. Thanks, Mark Wunsch mark@markwunsch.com _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Wed Aug 20 14:35:46 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 20 14:36:18 2008 Subject: [uf-discuss] Cognition 0.1-alpha12 out today! Message-ID: Cognition 0.1-alpha12 is out now (maybe I'll move into betas one of these days). A full change log is available at the Cognition website where you can download the latest version or try it online. A summary of the changes for this version: * Lots and lots of bugfixes, in particular handling parsing edge cases for RDFa and nested microformats. * Turtle output. * M3U output. * Full parsing of durations and time intervals - not just treated as plain old strings. This includes experimental support for parsing non- ISO-8601 durations and intervals, as outlined at http:// buzzword.org.uk/cognition/uf-plus.html -- Toby A Inkster From martin at weborganics.co.uk Wed Aug 20 14:57:08 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 14:57:24 2008 Subject: [uf-discuss] Cognition 0.1-alpha12 out today! In-Reply-To: References: Message-ID: <48AC9334.7070004@weborganics.co.uk> Hello Toby Toby A Inkster wrote: > Cognition 0.1-alpha12 is out now (maybe I'll move into betas one of > these days). A full change log is available at the Cognition website > where you can download the latest > version or try it online. [...] > > * M3U output. This is great I tried it on http://weborganics.co.uk/haudio-rss/ worked perfectly thanks (you saved me a job). Best Wishes Martin McEvoy From mail at tobyinkster.co.uk Wed Aug 20 15:19:04 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 20 15:19:35 2008 Subject: [uf-discuss] [off-list] Cognition 0.1-alpha12 out today! Message-ID: <9D9ABF38-7487-4471-971E-5FFA397CC4EA@tobyinkster.co.uk> > This is great I tried it on http://weborganics.co.uk/haudio-rss/ > worked > perfectly thanks (you saved me a job). Excellent. And if you include machine readable durations, in any of the four formats outlined at , those will be included in the M3U file as well. In some future version I'm hoping to include an export module for some sort of podcast format (i.e. RSS or Atom). The problem I'm struggling with is what to do when people overlay hAtom and hAudio. If hAudio is output as Atom and hAtom is output as Atom, then when the page as a whole is output as hAtom, then each song will end up having two entries in the feed. :-( I'll come up with something eventually I'm sure. -- Toby A Inkster From Michael.Smethurst at bbc.co.uk Thu Aug 21 04:30:56 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Aug 21 04:31:03 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <48A445A9.4010106@weborganics.co.uk> Message-ID: Hi Martin On 14/8/08 15:48, "Martin McEvoy" wrote: > Hello Michael > > Michael Smethurst wrote: >> >> On 14/8/08 12:32, "Brian Suda" wrote: >> >> >>> 2008/8/14, Michael Smethurst : >>> >>>> On listings pages and: >>>> >>>>

    >>>> >>>> Ludwig >>>> van >>>> Beethoven >>>> >>>>

    >>>> >>>> On ludwig's page >>>> >>>> It means that Ludwig loses his van on operator export but I guess he won't >>>> complain. >>>> >>> --- you could solve this by nesting the spans as well. >>> >>> >>> van >>> Beethoven >>> >>> >> >> Cool, I'll do this on the person page and leave him slightly broke on the >> listings where the nesting isn't possible cos of the separation >> Beethoven, Ludwig van >> >> I've asked around and the label "Onomastic prefix" has been suggested: >> >> http://www.listservicedirect.com/ethnic_religious.html >> >> But again it doesn't seem to differentiate between attached and detached >> prefixes >> >> So I'll stick with family-name-prefix for now (it's easier to spell for one) >> unless anyone has a better idea >> > > *family-name-preposition* is probably more accurate to what you are > trying to describe "von" in dutch simply means "of" or "from", "O" as in > "O'Donnell", in Irish means "descendant of" or "grandson of" (in > Gaelic Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as > in "FitzGerald" is an Irish hash of the french "fils de" which also > means "son of". What I am trying to say is any of these prefixes simply > mean "of" and shouldn't really be considered part of their family name > although they mostly are, think "Van Gough" would you know who I meant > if I just said "Gough"? Family-name-preposition it is. You can see beethoven here: http://bbc-hackday.dyndns.org:1895/people/16 I've disabled vcards on lists cos the lists are kinda long and operator was choking > > > Best wishes > > Martin McEvoy >> >> >>> This way, you are still adding POSH to the 'van' prefix, but it will >>> get exported to Operator together with the family-name. Unless this >>> would be a violation of the semantics of "family-name", but i think in >>> this case the nesting would be ok. >>> >>> -brian >>> >> >> >> http://www.bbc.co.uk/ >> This e-mail (and any attachments) is confidential and may contain personal >> views which are not the views of the BBC unless specifically stated. >> If you have received it in error, please delete it from your system. >> Do not use, copy or disclose the information in any way nor act in reliance >> on it and notify the sender immediately. >> Please note that the BBC monitors e-mails sent or received. >> Further communication will signify your consent to this. >> >> _______________________________________________ >> microformats-discuss mailing list >> microformats-discuss@microformats.org >> http://microformats.org/mailman/listinfo/microformats-discuss >> > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From Michael.Smethurst at bbc.co.uk Thu Aug 21 05:28:09 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Aug 21 05:28:16 2008 Subject: [uf-discuss] hcard: born and died and flourished Message-ID: Just wanted to run some stuff past people. I'm working with a table of composers/artists and starting to markup birth and death dates. The cases I've seen: - both dates unknown http://bbc-hackday.dyndns.org:1895/people/797 - date of death unknown http://bbc-hackday.dyndns.org:1895/people/396 - date of birth unknown http://bbc-hackday.dyndns.org:1895/people/28276 - date of birth and date of death known http://bbc-hackday.dyndns.org:1895/people/16 - person still alive http://bbc-hackday.dyndns.org:1895/people/1 - date of birth approximate http://bbc-hackday.dyndns.org:1895/people/303 - date of death approximate http://bbc-hackday.dyndns.org:1895/people/248 - both dates approximate http://bbc-hackday.dyndns.org:1895/people/295 In some cases the dates are not birth and death but when the person flourished: http://bbc-hackday.dyndns.org:1895/people/410 In these cases all the above cases of unknown-ness and approximation may also be true. So I've added class='bday' to known dates of birth. And I've decided to use class="dday" for date of death and class='flourished-start' and class='flourished-end' for flourished dates Where either date is circa I've included ca. in the span with bday, dday, flourished-start or flourished-end: ca. 1575-ca. 1614 Does this look /feel right or am I missing something obvious? Is there established POSH for death date and flourished dates? http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From brian.suda at gmail.com Thu Aug 21 06:21:21 2008 From: brian.suda at gmail.com (Brian Suda) Date: Thu Aug 21 06:21:26 2008 Subject: [uf-discuss] hcard: born and died and flourished In-Reply-To: References: Message-ID: <21e770780808210621s4b78ade1xff8c2699f442bdbe@mail.gmail.com> 2008/8/21, Michael Smethurst : > Just wanted to run some stuff past people. I'm working with a table of > composers/artists and starting to markup birth and death dates. > Does this look /feel right or am I missing something obvious? Is there > established POSH for death date and flourished dates? --- the most info on the wiki is here: http://microformats.org/wiki/hcard-date-of-death There have been some discussion of fuzzy dates, but at the end of the day most consuming apps what a hard-coded single point in time. -brian -- brian suda http://suda.co.uk From mail at tobyinkster.co.uk Thu Aug 21 06:49:34 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Aug 21 06:50:09 2008 Subject: [uf-discuss] hcard: born and died and flourished Message-ID: <9AD79001-F5D5-44C2-B38C-6FB7C19B15D3@tobyinkster.co.uk> > And I've decided to use class="dday" for date of death and > class='flourished-start' and class='flourished-end' for flourished > dates > > Where either date is circa I've included ca. in the span with bday, > dday, > flourished-start or flourished-end: > > ca. 1575-ca. 1614 > > Does this look /feel right or am I missing something obvious? Is there > established POSH for death date and flourished dates? I've previously recommended using 'dday' for date of death. DDAY is the name of the property in the draft vCard 4.0 spec, so it seems likely that any future extension of hCard that does include a date of death will name the property 'dday'. 'dday' is already supported in Cognition . I imagine that your use of 'ca.' in dates will cause problems for some parsers, which expect to find an ISO 8601 date these - it certainly breaks in Cognition. You may be able to improve parser behaviour by using value excerpting: ca. 1575 -- Toby A Inkster From martin at weborganics.co.uk Thu Aug 21 10:41:09 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Aug 21 10:47:32 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: Message-ID: <48ADA8B5.1070406@weborganics.co.uk> Michael Smethurst wrote: > Hi Martin > > > On 14/8/08 15:48, "Martin McEvoy" wrote: > > > *family-name-preposition* is probably more accurate to what you are > > trying to describe "von" in dutch simply means "of" or "from" Oh I quoted wrong there I meant to say "van" in Dutch simply means "of" or "from" my bad! ;-) "von" still means "of" or "from" but is also used to indicate German/Austrian nobility similar to "de" in French. > , "O" as in > > "O'Donnell", in Irish means "descendant of" or "grandson of" (in > > Gaelic Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as > > in "FitzGerald" is an Irish hash of the french "fils de" which also > > means "son of". What I am trying to say is any of these prefixes simply > > mean "of" and shouldn't really be considered part of their family name > > although they mostly are, think "Van Gough" would you know who I meant > > if I just said "Gough"? > > > Family-name-preposition it is. You can see beethoven here: > > http://bbc-hackday.dyndns.org:1895/people/16 > Ahh Shame! the link doesn't work for me I will try it later Best Wishes Martin McEvoy From msporny at digitalbazaar.com Thu Aug 21 11:27:27 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Aug 21 12:20:22 2008 Subject: [uf-discuss] Mozilla Labs Aurora mock-up depends on RDFa/uF-like technology Message-ID: <48ADB38F.6070603@digitalbazaar.com> Mozilla Labs announced a pretty cool new browser concept dubbed Aurora. It's pretty flashy and integrates some experimental UI concepts that are questionable. However, one of the fundamental, underlying principles of the browser is the concept of data portability. The idea that you own your data and can pipe, mix and match data from different websites was key to the browsing/collaboration experience. I caught myself thinking "You'd use RDFa/uF to do that... and that... and that" throughout each video. Here are the direct links to Vimeo WebHD content: Aurora - Part 1 - Collaboration, History, Data Objects, Basic Navigation http://www.vimeo.com/1450211 Aurora - Part 2 - Geo-location-based browsing http://www.vimeo.com/1476338 Aurora - Part 3 - Integrating Web w/ Physical Environment (also, sexism) http://www.vimeo.com/1481810 (non-WebHD) Aurora - Part 4 - Personal Data Portability (bonuses: copious diversity and "the liberal agenda") http://www.vimeo.com/1488633 -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches From mail at tobyinkster.co.uk Fri Aug 22 01:24:43 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Aug 22 01:25:25 2008 Subject: [uf-discuss] More than three years Message-ID: <7407953A-7D78-4E3D-80AA-6CD996E2F343@tobyinkster.co.uk> Compare and contrast: http://microformats.org/wiki?title=Main_Page&oldid=251 http://microformats.org/wiki/Main_Page#Specifications The only difference between these lists are XFN and XMDP, both of which were adopted from outside the community. -- Toby A Inkster From fberriman at gmail.com Fri Aug 22 01:35:35 2008 From: fberriman at gmail.com (Frances Berriman) Date: Fri Aug 22 01:35:39 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: <48A445A9.4010106@weborganics.co.uk> Message-ID: 2008/8/21 Michael Smethurst : > http://bbc-hackday.dyndns.org:1895/people/16 > Michael actually means: http://bbc-hackday.dyndns.org:2840/ -- Frances Berriman http://fberriman.com From martin at weborganics.co.uk Fri Aug 22 06:01:53 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 22 06:01:59 2008 Subject: [uf-discuss] Problems with rel-license? Message-ID: <48AEB8C1.4010709@weborganics.co.uk> Hello All I am having problems with the actual definition of "license" which seems to ambiguous as it means TWO things and I am not sure which applies. > http://en.wikipedia.org/wiki/License "The verb *license* or *grant > license* means to give permission. The noun *licence* (or license in > American Spelling) is the document demonstrating that permission". Microformat class names are mostly (if not all) Nouns I am English I spell it licence as in Driving licence, or TV licence so to mark up a link to the document demonstrating that permission I would write, Read My Licence Presuming there is nothing amiss it is wrong however (I've done this :-[ ) this is the correct mark up: Read My Licence This (to me) seems semantically wrong , should I be bothered about this? Thanks Martin McEvoy From mail at ciaranmcnulty.com Fri Aug 22 06:15:05 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Aug 22 06:15:09 2008 Subject: [uf-discuss] Problems with rel-license? In-Reply-To: <48AEB8C1.4010709@weborganics.co.uk> References: <48AEB8C1.4010709@weborganics.co.uk> Message-ID: On Fri, Aug 22, 2008 at 2:01 PM, Martin McEvoy wrote: > Read My Licence > > This (to me) seems semantically wrong , should I be bothered about this? I think we Brits should just accept that the uF in question is specified in en_us and not worry too much about it. The idea of internationalising uF fields is too horrific to contemplate, after all! See also text-align: center; -Ciaran McNulty From andr3.pt at gmail.com Fri Aug 22 06:20:07 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Fri Aug 22 06:20:09 2008 Subject: [uf-discuss] Problems with rel-license? In-Reply-To: <48AEB8C1.4010709@weborganics.co.uk> References: <48AEB8C1.4010709@weborganics.co.uk> Message-ID: On Fri, Aug 22, 2008 at 2:01 PM, Martin McEvoy wrote > > This (to me) seems semantically wrong , should I be bothered about this? If you should, then all non-english speaking authors should be bothered as well. I would write: Leia a minha licen?a Even though I publish content in Portuguese, I mostly use english class-names, so I personally see no problem in that. Hope this perspective helps. :) -- Andr? Lu?s From scott at randomchaos.com Fri Aug 22 07:30:34 2008 From: scott at randomchaos.com (Scott Reynen) Date: Fri Aug 22 07:30:39 2008 Subject: [uf-discuss] Problems with rel-license? In-Reply-To: <48AEB8C1.4010709@weborganics.co.uk> References: <48AEB8C1.4010709@weborganics.co.uk> Message-ID: On [Aug 22], at [ Aug 22] 7:01 , Martin McEvoy wrote: > I am having problems with the actual definition of "license" > I am English I spell it licence For better or worse, we're using American English spelling. > I would write, > > Read My > Licence > > Presuming there is nothing amiss it is wrong however (I've done > this :-[ ) this is the correct mark up: > > Read My > Licence > > This (to me) seems semantically wrong , should I be bothered about > this? As far as I can tell, the American English word "license" means the same thing as the British English word "licence." So the two lines above mean the same thing in different languages. Does this resolve your concern? Peace, Scott From martin at weborganics.co.uk Fri Aug 22 08:09:33 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 22 08:09:40 2008 Subject: [uf-discuss] Problems with rel-license? In-Reply-To: References: <48AEB8C1.4010709@weborganics.co.uk> Message-ID: <48AED6AD.1030208@weborganics.co.uk> Ciaran McNulty wrote: > On Fri, Aug 22, 2008 at 2:01 PM, Martin McEvoy wrote: > >> Read My Licence >> >> This (to me) seems semantically wrong , should I be bothered about this? >> > > I think we Brits should just accept that the uF in question is > specified in en_us and not worry too much about it. > > The idea of internationalising uF fields is too horrific to > contemplate, after all! > > See also text-align: center; > I'm sure a few Brits have been dumbfounded by that one when validating their css! ;-) Anyway its not internationalization I have a problem with its the definition not the two words I have problems with. 1, License is an action by the licensor giving permission to a licensee either verbally or some other form of communication typically in writing. 2 Licence is the actual document itself demonstrating those permissions such as a Drivers Licence. I do think in order for the Licensing http://microformats.org/wiki/license discussion to progress fully it is very important to distinguish the difference between the two Thanks Martin McEvoy > -Ciaran McNulty > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From jeremy at adactio.com Fri Aug 22 11:10:57 2008 From: jeremy at adactio.com (Jeremy Keith) Date: Fri Aug 22 11:11:02 2008 Subject: [uf-discuss] Problems with rel-license? In-Reply-To: <48AED6AD.1030208@weborganics.co.uk> References: <48AEB8C1.4010709@weborganics.co.uk> <48AED6AD.1030208@weborganics.co.uk> Message-ID: <61F73767-6F91-41A5-A90E-56FE417EA6CD@adactio.com> Martin wrote: > Anyway its not internationalization I have a problem with its the > definition not the two words I have problems with. They are one and the same issue. The difference between license and licence is only made in British English. In American English, the word license covers both the verb and the noun. HTH, Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/ From jim at eatyourgreens.org.uk Fri Aug 22 14:43:38 2008 From: jim at eatyourgreens.org.uk (Jim O'Donnell) Date: Fri Aug 22 14:43:47 2008 Subject: [uf-discuss] hcard: born and died and flourished In-Reply-To: References: Message-ID: <07CC234C-C4CF-43EC-8FE2-5489886EF353@eatyourgreens.org.uk> Hi Michael, On 21 Aug 2008, at 13:28, Michael Smethurst wrote: > Where either date is circa I've included ca. in the span with bday, > dday, > flourished-start or flourished-end: > > ca. 1575-ca. 1614 > You could represent fuzzy dates as two timestamps seperated by a slash, as per http://www.ukoln.ac.uk/metadata/pns/pndsdcap/ #DctermsTemporalPndstermsISO8601Per eg. ca. 1575 could be written as 1570-01-01/1580-12-31 or you might be able to just get away wth 1570/1580. I'm not quite sure how you'd represent that in HTML, but it is a standard for representing periods of time. Oh, and I suppose with dates that far back there'll be calendar issues with Julian vs. Gregorian and what day does the year begin if you get into days and months and comparing dates from different parts of Europe. I have to admit I generally ignore those since the uncertainty in dates for works of art and the like is usually much bigger than any difference introduced by different calendars. Jim Jim O'Donnell jim@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens From martin at weborganics.co.uk Fri Aug 22 14:55:05 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 22 14:55:11 2008 Subject: [uf-discuss] Problems with rel-license? In-Reply-To: <61F73767-6F91-41A5-A90E-56FE417EA6CD@adactio.com> References: <48AEB8C1.4010709@weborganics.co.uk> <48AED6AD.1030208@weborganics.co.uk> <61F73767-6F91-41A5-A90E-56FE417EA6CD@adactio.com> Message-ID: <48AF35B9.407@weborganics.co.uk> Hello Jeremy Jeremy Keith wrote: > Martin wrote: >> Anyway its not internationalization I have a problem with its the >> definition not the two words I have problems with. > > They are one and the same issue. The difference between license and > licence is only made in British English. you mean in every English speaking country accept America.... > In American English, the word license covers both the verb and the noun. Which is a shame really because it kind of muddies the definition of license. Ah well if this isn't an issue so be it :-) Thanks Martin > > HTH, > > Jeremy > From bjonkman at sobac.com Sun Aug 24 11:26:49 2008 From: bjonkman at sobac.com (Bob Jonkman) Date: Sun Aug 24 11:28:33 2008 Subject: [uf-discuss] hcard: born and died and flourished In-Reply-To: <9AD79001-F5D5-44C2-B38C-6FB7C19B15D3@tobyinkster.co.uk> References: <9AD79001-F5D5-44C2-B38C-6FB7C19B15D3@tobyinkster.co.uk> Message-ID: <48B16FA9.22353.76EB9@bjonkman.sobac.com> Approximate dates and ambiguous dates figure prominently in genealogy as well. >From http://microformats.org/wiki/genealogy-formats : The GEDCOM data interchange format for genealogical data allows approximate dates, specifically "ABT 4 July 1776", "BEF 25 Dec 1903", "AFT 11 Nov 1918". It also also allows ambiguous dates, "July 1867" or just "1886", or even "4 July". And these in combination, (Approximately ambiguous dates? Ambiguously approximate dates?), eg. "BEF Feb 2007", "AFT 1945". The most ambiguous entries I've seen for dates are "DECEASED" when date-of-death is unknown, and "NOT MARRIED" for couples who have not had a wedding ceremony. (Info from Guidelines for event dates in the PAF Help File). It would be great to see the same syntax formally applied to microformat dates, perhaps with the class name "approx" as suggested by Toby. --Bob. On 21 Aug 2008 at 14:49, Toby A Inkster wrote: > > And I've decided to use class="dday" for date of death and > > class='flourished-start' and class='flourished-end' for flourished > > dates > > > > Where either date is circa I've included ca. in the span with bday, > > dday, flourished-start or flourished-end: > > > > ca. 1575-ca. > > 1614 > > > > Does this look /feel right or am I missing something obvious? Is > > there established POSH for death date and flourished dates? > > I've previously recommended using 'dday' for date of death. DDAY is > the name of the property in the draft vCard 4.0 spec, so it seems > likely that any future extension of hCard that does include a date of > death will name the property 'dday'. > > 'dday' is already supported in Cognition cognition/>. > > I imagine that your use of 'ca.' in dates will cause problems for > some parsers, which expect to find an ISO 8601 date these - it > certainly breaks in Cognition. You may be able to improve parser > behaviour by using value excerpting: > > > ca. > 1575 > > > -- > Toby A Inkster > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss -- -- -- -- 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 chris.messina at gmail.com Sun Aug 24 16:42:18 2008 From: chris.messina at gmail.com (Chris Messina) Date: Sun Aug 24 16:42:21 2008 Subject: [uf-discuss] Microformats on YouTube Message-ID: <1bc4603e0808241642t375dd6d2we1b7347e1be0914@mail.gmail.com> I searched around on the wiki and mailing list and didn't see anyone else reference this, so I thought I'd share that YouTube has added basic hcard support to its video pages: http://www.flickr.com/photos/factoryjoe/2793731119/in/photostream/ I've added this to the hcard-examples-in-wild-pending page. Cheers, Chris -- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private From andr3.pt at gmail.com Sun Aug 24 16:55:52 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Sun Aug 24 16:55:55 2008 Subject: [uf-discuss] Microformats on YouTube In-Reply-To: <1bc4603e0808241642t375dd6d2we1b7347e1be0914@mail.gmail.com> References: <1bc4603e0808241642t375dd6d2we1b7347e1be0914@mail.gmail.com> Message-ID: Chris, They had come by looking for some directions back in July: http://microformats.org/discuss/mail/microformats-new/2008-July/001643.html Seems like they ended up walking the walk. Way to go. :) Cheers, -- Andr? Lu?s On Mon, Aug 25, 2008 at 12:42 AM, Chris Messina wrote: > I searched around on the wiki and mailing list and didn't see anyone > else reference this, so I thought I'd share that YouTube has added > basic hcard support to its video pages: > > http://www.flickr.com/photos/factoryjoe/2793731119/in/photostream/ > > I've added this to the hcard-examples-in-wild-pending page. > > Cheers, > > Chris > > -- > Chris Messina > Citizen-Participant & > Open Source Advocate-at-Large > factoryjoe.com # diso-project.org > citizenagency.com # vidoop.com > This email is: [ ] bloggable [X] ask first [ ] private > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From csarven at gmail.com Sun Aug 24 16:58:10 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sun Aug 24 16:58:14 2008 Subject: [uf-discuss] Microformats on YouTube In-Reply-To: <1bc4603e0808241642t375dd6d2we1b7347e1be0914@mail.gmail.com> References: <1bc4603e0808241642t375dd6d2we1b7347e1be0914@mail.gmail.com> Message-ID: On Sun, Aug 24, 2008 at 7:42 PM, Chris Messina wrote: > I searched around on the wiki and mailing list and didn't see anyone > else reference this, so I thought I'd share that YouTube has added > basic hcard support to its video pages: > > http://www.flickr.com/photos/factoryjoe/2793731119/in/photostream/ > > I've added this to the hcard-examples-in-wild-pending page. Thanks Chris. It was only fairly recent that the YouTube dev team asked this community on how to approach microformats [1]. Nice to see that they have hCard going. [1] http://microformats.org/discuss/mail/microformats-new/2008-July/001643.html Sarven Capadisli http://www.csarven.ca From martin at weborganics.co.uk Mon Aug 25 07:57:35 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 25 07:57:51 2008 Subject: [uf-discuss] hcard: born and died and flourished In-Reply-To: <07CC234C-C4CF-43EC-8FE2-5489886EF353@eatyourgreens.org.uk> References: <07CC234C-C4CF-43EC-8FE2-5489886EF353@eatyourgreens.org.uk> Message-ID: <48B2C85F.7050306@weborganics.co.uk> Hello Jim Jim O'Donnell wrote: > Hi Michael, > > On 21 Aug 2008, at 13:28, Michael Smethurst wrote: > >> Where either date is circa I've included ca. in the span with bday, >> dday, >> flourished-start or flourished-end: >> >> ca. 1575-ca. 1614 >> > > > You could represent fuzzy dates as two timestamps seperated by a > slash, as per > http://www.ukoln.ac.uk/metadata/pns/pndsdcap/#DctermsTemporalPndstermsISO8601Per > > > eg. ca. 1575 could be written as 1570-01-01/1580-12-31 or you might be > able to just get away wth 1570/1580. > > I'm not quite sure how you'd represent that in HTML, but it is a > standard for representing periods of time. http://en.wikipedia.org/wiki/ISO_8601#Time_intervals says that as well as using slash "/" and solidus (like a slash but steeper don't think its on a standard key on a keyboard) you can also use double dashes "--" so possible mark-up could be: 1575--1614 No there is no @class=interval just a bit of "posh" Best Wishes Martin McEvoy > > Oh, and I suppose with dates that far back there'll be calendar issues > with Julian vs. Gregorian and what day does the year begin if you get > into days and months and comparing dates from different parts of > Europe. I have to admit I generally ignore those since the uncertainty > in dates for works of art and the like is usually much bigger than any > difference introduced by different calendars. > > Jim > > Jim O'Donnell > jim@eatyourgreens.org.uk > http://eatyourgreens.org.uk > http://flickr.com/photos/eatyourgreens > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From msporny at digitalbazaar.com Mon Aug 25 19:47:14 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Aug 25 20:20:25 2008 Subject: [uf-discuss] HTML5, Microformats and RDFa Message-ID: <48B36EB2.30303@digitalbazaar.com> There have been several threads discussing Microformats, RDFa and HTML5 that are occurring on the WHATWG mailing list. The discussion relates to whether or not HTML5 should depend on the Microformats community to solve HTML5's semantic markup issues, or if both Microformats and RDFa should be considered for semantic web markup issues. The start of the discussion is here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015860.html and continues here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015875.html I have authored a blog reply, stating that HTML5 should not depend on the Microformats community to develop all semantic web vocabularies, the reasoning can be viewed here: http://blog.digitalbazaar.com/2008/08/23/html5-rdfa-and-microformats/ and my first response to the WHATWG mailing list http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015949.html Things start getting dicey here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015892.html and here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015950.html and my second response to the WHATWG mailing list, outlining some of the shortcomings of Microformats and stating what differentiates RDFa in it's approach: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015957.html Posting to this list because there are many on here that would be interested in the WHATWG's current position on web semantics: "not important enough to consider as part of the HTML language". Note that the XHTML1.1 and XHTML2 workgroups have already accepted the position that: "web semantics are important and a standard method of semantics expression is necessary for the future development of the web". -- manu From scott at randomchaos.com Tue Aug 26 07:00:02 2008 From: scott at randomchaos.com (Scott Reynen) Date: Tue Aug 26 07:00:11 2008 Subject: [uf-discuss] HTML5, Microformats and RDFa In-Reply-To: <48B36EB2.30303@digitalbazaar.com> References: <48B36EB2.30303@digitalbazaar.com> Message-ID: <4F16BA11-FCDC-4088-A2CF-0934DF4F79C3@randomchaos.com> On [Aug 25], at [ Aug 25] 8:47 , Manu Sporny wrote: > There have been several threads discussing Microformats, RDFa and > HTML5 > that are occurring on the WHATWG mailing list. The discussion > relates to > whether or not HTML5 should depend on the Microformats community to > solve HTML5's semantic markup issues, or if both Microformats and RDFa > should be considered for semantic web markup issues. > > The start of the discussion is here: > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015860.html > > and continues here: > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015875.html > > I have authored a blog reply, stating that HTML5 should not depend on > the Microformats community to develop all semantic web vocabularies, > the > reasoning can be viewed here: > > http://blog.digitalbazaar.com/2008/08/23/html5-rdfa-and-microformats/ Manu, I agree it's unfortunate microformats, created to fill gaps in HTML, are now suggested as a reason to not fill those gaps. That said, it seems to me you're misreading your opposition here. Microformats are based entirely on HTML (which Ian fully understands, having participated early on in the microformats community), so the underlying argument being made against RDFa is that *HTML* is already sufficient, that there is no need for it to solve the wider problem RDFa would solve. As Ian said (with no mention of microformats): > It would be helpful if you could send a separate message that is > specifically asking for the changes you desire, and explaining what > problem it is they address, and what research shows that that is an > important enough problem that we should address it. Whatever shortcomings microformats or the process have should be irrelevant to making such a case for RDFa. Microformats explicitly do not seek to solve the wider problem as RDFa does, so rather than trying to convince people that RDFa solves the problem better than microformats, I suggest you convince them that the wider problem would actually be useful to solve. (That microformats don't solve it should then be self-evident, as microformats do not even attempt to solve it.) I think comparing RDFa to microformats actually hurts your argument by suggesting they solve the same problem and reinforcing the notion that the wider problem RDFa seeks to solve is unimportant. Rather, I would interpret the mentions of microformats as an indication that people are missing the wider problem RDFa would solve, and focus on making that clearer, by talking about what RDFa does that microformats don't even attempt to do. Peace, Scott From lists at ben-ward.co.uk Tue Aug 26 13:01:45 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Tue Aug 26 13:01:50 2008 Subject: [uf-discuss] HTML5, Microformats and RDFa In-Reply-To: <48B36EB2.30303@digitalbazaar.com> References: <48B36EB2.30303@digitalbazaar.com> Message-ID: On 25 Aug 2008, at 19:47, Manu Sporny wrote: > There have been several threads discussing Microformats, RDFa and > HTML5 > that are occurring on the WHATWG mailing list. The discussion > relates to > whether or not HTML5 should depend on the Microformats community to > solve HTML5's semantic markup issues, or if both Microformats and RDFa > should be considered for semantic web markup issues. I've been out of touch with HTML5 development for a bit, but the way you describe this paragraph is somewhat alarming. We, the microformats community, absolutely *should not* be relied on the fill every gap in HTML. That they would not specify minority concerns in the HTML language is perfectly understandable, but the Microformats Community is itself not designed to do that either. This community, with this development process, is completely inappropriate for filling every single extended use for HTML that people might have. HOWEVER, there may just be misinterpretation here. Perhaps rather than intending to depend on our specific community, the intention is that the gaps be filled with ?microformat-like patterns?. Patterns, class- patterns, ?posh?? whatever you want to call it. Microformats.org does not own the class attribute and anyone working on techniques that are incompatible with our process can do so. It seems to me the case is not about ?microformats.org?, but instead about the capabilities of the class attribute itself. Is it just that the word ?microformats? is being used as a generic catch-all for semantic class name patterns? It seems quite reasonable that the HTML working group be considering the use case of ?extended semantic description in HTML? and considering its existing capabilities (which are proving very capable in the specific case of microformats), rather than a use case of ?support RDFa in HTML?, which is just one solution. I think Scott is correct in that you may need to reframe your argument. Any push to have RDFa made a part of HTML5 should be focused on the capabilities of RDFa compared to the class attribute, not the (often intentional) limitations of one particular user of the class attribute (us). Ben From chris at feedmechocolate.com Wed Aug 27 05:39:18 2008 From: chris at feedmechocolate.com (Chris Mear) Date: Wed Aug 27 05:39:23 2008 Subject: [uf-discuss] More than three years In-Reply-To: <7407953A-7D78-4E3D-80AA-6CD996E2F343@tobyinkster.co.uk> References: <7407953A-7D78-4E3D-80AA-6CD996E2F343@tobyinkster.co.uk> Message-ID: <68af9cd10808270539j2d7410d2sb3b060447ddd662c@mail.gmail.com> 2008/8/22 Toby A Inkster : > Compare and contrast: > > http://microformats.org/wiki?title=Main_Page&oldid=251 > http://microformats.org/wiki/Main_Page#Specifications Our work here, evidently, is done. Chris From martin at weborganics.co.uk Wed Aug 27 11:31:25 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 27 11:31:37 2008 Subject: [uf-discuss] Ubiquity Message-ID: <48B59D7D.4080907@weborganics.co.uk> Hey All Have you seen this http://labs.mozilla.com/2008/08/introducing-ubiquity/ Very Cool If you have tryed it out surf your way to http://transformr.co.uk/ for some Microformat commands they are, get-atom => get an atom feed from hatom get-vcard => from hcard get-events => get hCalendar Events get-podcast => Get a RSS2 podcast from hAudio get-rdfa => Gets RDF from RDFa documents Thanks Martin McEvoy From mattsches at gmail.com Wed Aug 27 12:21:15 2008 From: mattsches at gmail.com (Matthias Gutjahr) Date: Wed Aug 27 12:21:20 2008 Subject: [uf-discuss] Ubiquity In-Reply-To: <48B59D7D.4080907@weborganics.co.uk> References: <48B59D7D.4080907@weborganics.co.uk> Message-ID: <107cffa30808271221w320420edu6f5ed5d0b39911b6@mail.gmail.com> Hey Martin, I tried it out, seems to work pretty well. Even recognizes the hAudio in my blog (although transformr adds an ugly element .. why?). IMHO ubiquity is a cool tool, at least for us geeks ;O), and you've come up with some good commands pretty quickly. Cheers - Matthias 2008/8/27 Martin McEvoy : > Hey All > > Have you seen this > > http://labs.mozilla.com/2008/08/introducing-ubiquity/ > > Very Cool If you have tryed it out surf your way to > http://transformr.co.uk/ for some Microformat commands they are, > > get-atom => get an atom feed from hatom > get-vcard => from hcard > get-events => get hCalendar Events > get-podcast => Get a RSS2 podcast from hAudio > get-rdfa => Gets RDF from RDFa documents > > > Thanks > > Martin McEvoy > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From zack.carter at gmail.com Wed Aug 27 17:38:20 2008 From: zack.carter at gmail.com (Zachary Carter) Date: Wed Aug 27 17:38:22 2008 Subject: [uf-discuss] More than three years In-Reply-To: <68af9cd10808270539j2d7410d2sb3b060447ddd662c@mail.gmail.com> References: <7407953A-7D78-4E3D-80AA-6CD996E2F343@tobyinkster.co.uk> <68af9cd10808270539j2d7410d2sb3b060447ddd662c@mail.gmail.com> Message-ID: What does it take to bump a draft, say hResume, to spec status? Just resolving the remaining open issues, or is there more to it? Best, Zach Carter http://zachcarter.info On Wed, Aug 27, 2008 at 8:39 AM, Chris Mear wrote: > 2008/8/22 Toby A Inkster : >> Compare and contrast: >> >> http://microformats.org/wiki?title=Main_Page&oldid=251 >> http://microformats.org/wiki/Main_Page#Specifications > > Our work here, evidently, is done. > > Chris > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From lists at ben-ward.co.uk Wed Aug 27 18:03:59 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Wed Aug 27 18:04:04 2008 Subject: Draft to Specification (was: [uf-discuss] More than three years) In-Reply-To: References: <7407953A-7D78-4E3D-80AA-6CD996E2F343@tobyinkster.co.uk> <68af9cd10808270539j2d7410d2sb3b060447ddd662c@mail.gmail.com> Message-ID: On 27 Aug 2008, at 17:38, Zachary Carter wrote: > What does it take to bump a draft, say hResume, to spec status? Just > resolving the remaining open issues, or is there more to it? It's definitely something that people are unclear on. On my part I've been thinking a lot regarding ?the role of editors?, spec status and so forth. My moving to San Francisco this month has pretty much neutralised my ability to contribute whilst I find an apartment and get settled in the US. The sunshine is awesome, though. I will get it written up fully, but in short, my view is that spec editors need to be ?actively? working on their spec (for some value of active, with some *simple* conditions for passing editorial control of specs away from inactive/unsuitable editors when demand arises). In my view, a specification goes from draft to ?release? when all issues are resolved in some way, and issue resolution should be a simple enumeration, probably one of ?fixed?, ?invalid? or ?deferred for future iteration?. Some clause needs to sit in place to ensure that specs are suitably vetted ? we don't want someone creating a spec quickly, fixing a small number of raised issues and declaring something a spec just because they reach the ?issues? finishing line. It absolutely needs not to be a ?finishing line? at all. Maybe each spec should have a required minimum draft iterations before it can go 1.0, allowing people to participate at different levels. Those passionate about subject matter will take interest at the 0.1 stage, those who are simply active within microformats in general would review specs at the second or third draft to protect against process violations and fast-tracking. I wouldn't want anything too strict, but all specs iterate draft versions anyway, so it might be wise to map them to cue issue review. It's also worth saying that I'd want to avoid ?spec status? being misinterpreted as something being ?finished?. Specs should always be open to evolutionary iteration. Ben From chris at feedmechocolate.com Thu Aug 28 01:47:46 2008 From: chris at feedmechocolate.com (Chris Mear) Date: Thu Aug 28 01:47:52 2008 Subject: Draft to Specification (was: [uf-discuss] More than three years) In-Reply-To: References: <7407953A-7D78-4E3D-80AA-6CD996E2F343@tobyinkster.co.uk> <68af9cd10808270539j2d7410d2sb3b060447ddd662c@mail.gmail.com> Message-ID: <68af9cd10808280147s772c5e97p51b10018a106486d@mail.gmail.com> 2008/8/28 Ben Ward : > Maybe each spec should have a required minimum draft iterations before it > can go 1.0, allowing people to participate at different levels. Those > passionate about subject matter will take interest at the 0.1 stage, those > who are simply active within microformats in general would review specs at > the second or third draft to protect against process violations and > fast-tracking. I wouldn't want anything too strict, but all specs iterate > draft versions anyway, so it might be wise to map them to cue issue review. Like 'release candidates' for software, you mean? Eg. 1.0-RC1 and 1.0-RC2, which are announced by the core contributors in a "hey, wider community, check this out before we close the door on it" sort of way? Or is that too strict? Chris From mail at tobyinkster.co.uk Thu Aug 28 03:41:46 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Aug 28 03:42:15 2008 Subject: Draft to Specification (was: [uf-discuss] More than three years) Message-ID: Yay! Finally the sort of discussion I was hoping to kick-start. I think 'adr' and 'geo' should certainly be considered candidates for promoting from drafts to specs - these have been stable for ages and don't seem to have any issues raised (at least none which don't effect hCard, or microformats in general). There have been plenty of ideas proposed for extensions to them, but the current drafts certainly address 80% of use cases. These can be deferred to a future iteration which would address 80% of the remaining 20% of use cases. (This would also address the anomaly that hCalendar, a full specification, recommends that event locations may be marked up with adr and geo, each of which are only drafts.) And hAudio and figure are probably stable enough to go on the "official drafts" list. The Microformats process is extremely helpful in the early stages of drafting a spec, taking the authors/editors through the process of researching relevant examples, looking at existing standards, narrowing down requirements to a simple, usable and deliverable set, and building a draft vocabulary; but after that, the process leaves you dangling: there is no defined process for knowing when to freeze a spec, when to start asking for implementations, creating test suites, publishing as a formal spec once you've got a few implementations that pass the tests, restarting the effort for a v1.1 iteration, etc. [That was a very long sentence. I apologise to readers: my writing style tends to favour run-ons.] The process itself should be considered a product of the microformats community; but the process does not yet cover 80% of use cases, so needs more work. -- Toby A Inkster From james at atomless.com Thu Aug 28 09:39:03 2008 From: james at atomless.com (James Tindall) Date: Thu Aug 28 09:40:18 2008 Subject: [uf-discuss] hcard authority? Message-ID: <48B6D4A7.4070807@atomless.com> Hi, I was just wondering if there's any existing mechanism for determining the authority of hcards? In other words, if a social graph query finds two hcards in different locations refering to the same person are there any guidlines for determining which should be considered authoritative if neither one has a rev value? =james.tindall From supercanadian at gmail.com Thu Aug 28 10:04:38 2008 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu Aug 28 10:04:48 2008 Subject: [uf-discuss] hcard authority? In-Reply-To: <48B6D4A7.4070807@atomless.com> References: <48B6D4A7.4070807@atomless.com> Message-ID: <84ce626f0808281004j5a08389cw6226e5dd35df7d0@mail.gmail.com> Hello James, On Thu, Aug 28, 2008 at 9:39 AM, James Tindall wrote: > > Hi, > > I was just wondering if there's any existing mechanism for determining the authority of hcards? > > In other words, if a social graph query finds two hcards in different locations refering to the same person are there any guidlines for > determining which should be considered authoritative if neither one has a rev value? That's likely beyond the scope of the hCard spec. Although I think people can become "creative" with figuring out that kind of information. Using information like... - the domain's WHOIS information. - the number of hCards on a domain. - whether the hCard is on the homepage or not. - a comparison of the various hCards out there for the person (to look for matching data, conflicting data, etc) etc, etc. It will probably take some trial and error.... and an observation of how people are using hCards (today)... to figure out an algorithm that is "good enough". (Over time, as people's usage of hCards changes, you may need to change your algorithm.) See ya -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ From kevinmarks at gmail.com Thu Aug 28 10:25:01 2008 From: kevinmarks at gmail.com (Kevin Marks) Date: Thu Aug 28 10:25:06 2008 Subject: [uf-discuss] hcard authority? In-Reply-To: <84ce626f0808281004j5a08389cw6226e5dd35df7d0@mail.gmail.com> References: <48B6D4A7.4070807@atomless.com> <84ce626f0808281004j5a08389cw6226e5dd35df7d0@mail.gmail.com> Message-ID: <73766b160808281025o208ff32el5ed5353c4331117e@mail.gmail.com> Have a look at the representative hCard brainstorming: http://microformats.org/wiki/representative-hcard-brainstorming if the cards are linked, this can help you decide which to use. On Thu, Aug 28, 2008 at 10:04 AM, Charles Iliya Krempeaux wrote: > > Hello James, > > On Thu, Aug 28, 2008 at 9:39 AM, James Tindall wrote: > > > > Hi, > > > > I was just wondering if there's any existing mechanism for determining the authority of hcards? > > > > In other words, if a social graph query finds two hcards in different locations refering to the same person are there any guidlines for > > determining which should be considered authoritative if neither one has a rev value? > > That's likely beyond the scope of the hCard spec. > > Although I think people can become "creative" with figuring out that > kind of information. Using information like... > - the domain's WHOIS information. > - the number of hCards on a domain. > - whether the hCard is on the homepage or not. > - a comparison of the various hCards out there for the person (to look > for matching data, conflicting data, etc) > > etc, etc. > > It will probably take some trial and error.... and an observation of > how people are using hCards (today)... to figure out an algorithm that > is "good enough". (Over time, as people's usage of hCards changes, > you may need to change your algorithm.) > > > See ya > > -- > Charles Iliya Krempeaux, B.Sc. > http://ChangeLog.ca/ > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From tantek at cs.stanford.edu Thu Aug 28 10:47:51 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Thu Aug 28 10:48:04 2008 Subject: [uf-discuss] hcard authority? In-Reply-To: <73766b160808281025o208ff32el5ed5353c4331117e@mail.gmail.com> References: <48B6D4A7.4070807@atomless.com><84ce626f0808281004j5a08389cw6226e5dd35df7d0@mail.gmail.com><73766b160808281025o208ff32el5ed5353c4331117e@mail.gmail.com> Message-ID: <1304575275-1219945676-cardhu_decombobulator_blackberry.rim.net-1305909385-@bxe017.bisx.prod.on.blackberry> Thanks Kevin. Also, before making negative assertions like "beyond the spec" or "does not exist", or *especially* before brainstorming in email (wiki is preferred for brainstorming), consider searching the wiki or using web search to search site:microformats.org for the terms in question. I've added a "synonyms" section to: http://microformats.org/wiki/representative-hcard to help w this in the future. Thanks, Tantek -----Original Message----- From: "Kevin Marks" Date: Thu, 28 Aug 2008 10:25:01 To: Microformats Discuss Subject: Re: [uf-discuss] hcard authority? Have a look at the representative hCard brainstorming: http://microformats.org/wiki/representative-hcard-brainstorming if the cards are linked, this can help you decide which to use. On Thu, Aug 28, 2008 at 10:04 AM, Charles Iliya Krempeaux wrote: > > Hello James, > > On Thu, Aug 28, 2008 at 9:39 AM, James Tindall wrote: > > > > Hi, > > > > I was just wondering if there's any existing mechanism for determining the authority of hcards? > > > > In other words, if a social graph query finds two hcards in different locations refering to the same person are there any guidlines for > > determining which should be considered authoritative if neither one has a rev value? > > That's likely beyond the scope of the hCard spec. > > Although I think people can become "creative" with figuring out that > kind of information. Using information like... > - the domain's WHOIS information. > - the number of hCards on a domain. > - whether the hCard is on the homepage or not. > - a comparison of the various hCards out there for the person (to look > for matching data, conflicting data, etc) > > etc, etc. > > It will probably take some trial and error.... and an observation of > how people are using hCards (today)... to figure out an algorithm that > is "good enough". (Over time, as people's usage of hCards changes, > you may need to change your algorithm.) > > > See ya > > -- > Charles Iliya Krempeaux, B.Sc. > http://ChangeLog.ca/ > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From msporny at digitalbazaar.com Thu Aug 28 11:28:42 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Aug 28 11:28:48 2008 Subject: [uf-discuss] HTML5, Microformats and RDFa In-Reply-To: <4F16BA11-FCDC-4088-A2CF-0934DF4F79C3@randomchaos.com> References: <48B36EB2.30303@digitalbazaar.com> <4F16BA11-FCDC-4088-A2CF-0934DF4F79C3@randomchaos.com> Message-ID: <48B6EE5A.1050902@digitalbazaar.com> Scott Reynen wrote: > I think comparing RDFa to microformats actually hurts your argument by > suggesting they solve the same problem and reinforcing the notion that > the wider problem RDFa seeks to solve is unimportant. Rather, I would > interpret the mentions of microformats as an indication that people are > missing the wider problem RDFa would solve, and focus on making that > clearer, by talking about what RDFa does that microformats don't even > attempt to do. Scott, Ben - thanks for the feedback, both of you make some very good points and I've adjusted my argumentation a bit to follow advice expressed by both of you. Things are being clarified in some ways on the HTML5 list and muddied in others. The one thing that is clear is that most of those on the list are not as up-to-speed with web semantics as either this community or the RDFa community would expect. Certainly, I was a bit blind-sided by some of the false assertions those on the list were making about semantics in general. The very long thread continues, RDFa Problem Statement and Features http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015957.html Intro to RDFa http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015974.html RDFa markup consistency http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015992.html CSS-based approach to semantic data on the Web (Microformats and RDFa) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015996.html Of particular note is the last thread - the CSS-based approach to semantic data markup. It's a proposal that, while interesting, ignores the hard work that this community and the RDFa community has done over the past several years. I could be mis-reading the various threads, so some feedback from this list would be appreciated. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches From msporny at digitalbazaar.com Thu Aug 28 12:24:25 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Aug 28 12:24:30 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force Message-ID: <48B6FB69.2030509@digitalbazaar.com> Hi uFers, RDFa is going to become an official W3C standard in the next 2-3 months. Martin McEvoy had posted something about two weeks ago on the RDFa mailing list stating that he'd like to use RDFa to express Microformats: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Aug/0081.html At first, I dismissed it as something this community would not be interested in, and even if they were, something that the RDFa community wouldn't be interested in doing. Shame on me for assuming without checking with both communities first! Over the past week, I've been thinking about some of the stuff Mark Birbeck (who started the RDFa initiative) said several months ago and what Martin re-iterated in his e-mail two weeks ago: There should be a way to provide Microformats-like markup using RDFa. Afterall, it would solve the unified parser/markup issue that some (both inside and outside this community) have with Microformats. So, I drew together a very quick proposal before the RDFa Task Force meeting this morning: It is possible to use RDFa attributes to replace/enhance usage of the @class attribute and the ABBR design pattern in Microformats. We should be able to do so without introducing the concept of namespaces to the author that is marking up content - keeping the simplicity of Microformats authoring intact. Doing so would provide a unified model of semantics expression between RDFa and Microformats. It would also provide one unified parser that could parse both namespaced RDFa and non-namespaced Microformats. Here's a link to the discussion: http://www.w3.org/2008/08/28-rdfa-minutes.html#item03 The group was very enthusiastic - they would like to work with the Microformats community to address some of these long standing issues in our community. If we are successful in this endeavor, it would mean: - 9 additional parsers that could parse Microformats. - A unified parsing model in addition to the ad-hoc one provided by Microformats. - A full test suite for the unified parsing model. - A unified method of Microformats and RDFa expression in HTML4, XHTML1.1, and XHTML2. - A painless upgrade path from Microformats to RDFa if the author so desired. - A solution to the ABBR accessibility problem. - A solution to the Microformats containment problem (class="item"). - A solution to the mfo problem. - A unified method of semantics expression for the web. It will take a couple of weeks to give examples of how this will all work, but I wanted to get feedback from this community before proceeding. We have a fantastic opportunity in front of us now - who in this community thinks that we should work with the W3C on this endeavor? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches From andreluis.pt at gmail.com Thu Aug 28 13:01:34 2008 From: andreluis.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Thu Aug 28 13:01:40 2008 Subject: [uf-discuss] HTML5, Microformats and RDFa In-Reply-To: <48B6EE5A.1050902@digitalbazaar.com> References: <48B36EB2.30303@digitalbazaar.com> <4F16BA11-FCDC-4088-A2CF-0934DF4F79C3@randomchaos.com> <48B6EE5A.1050902@digitalbazaar.com> Message-ID: Manu, the css based approach is somethin that has come up in discussions about semantics with fellow workers. I believe it does not trash all of the hard work the communities have don so far. All it does, from what i gathered, is move the semantics from html and places it in a separate file/place. The vocabulary used could be one specified by ufs. For instance: #tags a { rel: "tag"; } it all comes down to: do we want to separate semantics from our markup? thanks for the heads up on this matter. Cheers, Andr? Lu?s On 8/28/08, Manu Sporny wrote: > Scott Reynen wrote: >> I think comparing RDFa to microformats actually hurts your argument by >> suggesting they solve the same problem and reinforcing the notion that >> the wider problem RDFa seeks to solve is unimportant. Rather, I would >> interpret the mentions of microformats as an indication that people are >> missing the wider problem RDFa would solve, and focus on making that >> clearer, by talking about what RDFa does that microformats don't even >> attempt to do. > > Scott, Ben - thanks for the feedback, both of you make some very good > points and I've adjusted my argumentation a bit to follow advice > expressed by both of you. Things are being clarified in some ways on the > HTML5 list and muddied in others. > > The one thing that is clear is that most of those on the list are not as > up-to-speed with web semantics as either this community or the RDFa > community would expect. Certainly, I was a bit blind-sided by some of > the false assertions those on the list were making about semantics in > general. > > The very long thread continues, > > RDFa Problem Statement and Features > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015957.html > > Intro to RDFa > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015974.html > > RDFa markup consistency > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015992.html > > CSS-based approach to semantic data on the Web (Microformats and RDFa) > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015996.html > > Of particular note is the last thread - the CSS-based approach to > semantic data markup. It's a proposal that, while interesting, ignores > the hard work that this community and the RDFa community has done over > the past several years. I could be mis-reading the various threads, so > some feedback from this list would be appreciated. > > -- manu > > -- > Manu Sporny > President/CEO - Digital Bazaar, Inc. > blog: Bitmunk 3.0 Website Launches > http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Sent from Gmail for mobile | mobile.google.com From msporny at digitalbazaar.com Thu Aug 28 14:11:02 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Aug 28 14:11:07 2008 Subject: [uf-discuss] HTML5, Microformats and RDFa In-Reply-To: References: <48B36EB2.30303@digitalbazaar.com> <4F16BA11-FCDC-4088-A2CF-0934DF4F79C3@randomchaos.com> <48B6EE5A.1050902@digitalbazaar.com> Message-ID: <48B71466.5080708@digitalbazaar.com> Andr? Lu?s wrote: > Manu, > the css based approach is somethin that has come up in discussions > about semantics with fellow workers. I believe it does not trash all > of the hard work the communities have don so far. I never said the discussions "trashed" all of our hard work. I said that some of the discussions "ignore" (some) of the hard work performed by this community as well as the RDFa community. > All it does, from > what i gathered, is move the semantics from html and places it in a > separate file/place. Right - which both this community and the RDFa community are opposed to: 1. We do not want semantics to be placed in separate files. 2. We do not want vocabularies to be re-defined from site to site. 3. We want semantic markup to be easy to author for regular people - CSS is /not/ easy to author. That's what I was attempting to point out with my statement. Apologies if I was not clear :) -- manu From lists at ben-ward.co.uk Thu Aug 28 14:55:04 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Thu Aug 28 14:55:10 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force In-Reply-To: <48B6FB69.2030509@digitalbazaar.com> References: <48B6FB69.2030509@digitalbazaar.com> Message-ID: <59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> On 28 Aug 2008, at 12:24, Manu Sporny wrote: > It will take a couple of weeks to give examples of how this will all > work, but I wanted to get feedback from this community before > proceeding. We have a fantastic opportunity in front of us now - who > in > this community thinks that we should work with the W3C on this > endeavor? I'm not sure I completely see the benefit in this, and seeing your examples would be very helpful in getting a better idea of what you're proposing. From your bullet points, it seems to suggest taking microformat vocabularies and expressing them in RDFa, rather than HTML? It seems redundant for publishers. However, I do have a somewhat related issue that you might consider part of this effort. Some discussions I've had lately revealed usefulness in being able to _map_ microformats into RDF, for the purpose of combining microformats with other RDF vocabularies in a back-end somewhere (so, conversion for processing, rather than publishing. Publishing remains in HTML where it is most effective). I'm told that RDF ?versions? of vcard and icalendar are out of date compared to the microformats. As such, it strikes me that rather than maintaining duplicate specifications, it would instead make sense to develop a set of standard transformations so that any microformat can be transformed from HTML to RDF, without requiring duplicate effort to maintain another spec. This I'm sure would relate closely to GRDDL, since that already deals with transformation. This latter issue seems valuable, and preferable to a situation where every processor of microformats and RDF comes up with their own incompatible conversions. Note, I'm talking about mapping rules, not separate specs. For example, we have the ?jCard? page on the wiki, which I still feel should be more generic ?JSON Mapping Rules? page that can cover parsing from any format, not just hcard. If this RDF mapping effort is pursued by anyone, I would again favour ?RDF Mapping Rules?, rather than ?rCard?, ?rCal? and ?rListing? ? duplicate specs not based in HTML are not something that this community was founded to produce. Cheers, Ben From tantek at cs.stanford.edu Thu Aug 28 15:23:51 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Thu Aug 28 15:24:02 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C andRDFa Task Force In-Reply-To: <59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> References: <48B6FB69.2030509@digitalbazaar.com><59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> Message-ID: <113670345-1219962236-cardhu_decombobulator_blackberry.rim.net-875986100-@bxe017.bisx.prod.on.blackberry> Completely agreed w all of Ben Ward's points. In addition - I would be very concerned that the microformats principles would be compromised by any such efforts as Manu suggests, and efficiency of parsing/parsers and other points listed are not worth compromising the principles. Tantek -----Original Message----- From: Ben Ward Date: Thu, 28 Aug 2008 14:55:04 To: Microformats Discuss Subject: Re: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force On 28 Aug 2008, at 12:24, Manu Sporny wrote: > It will take a couple of weeks to give examples of how this will all > work, but I wanted to get feedback from this community before > proceeding. We have a fantastic opportunity in front of us now - who > in > this community thinks that we should work with the W3C on this > endeavor? I'm not sure I completely see the benefit in this, and seeing your examples would be very helpful in getting a better idea of what you're proposing. From your bullet points, it seems to suggest taking microformat vocabularies and expressing them in RDFa, rather than HTML? It seems redundant for publishers. However, I do have a somewhat related issue that you might consider part of this effort. Some discussions I've had lately revealed usefulness in being able to_map_ microformats into RDF, for the purpose of combining microformats with other RDF vocabularies in a back-end somewhere (so, conversion for processing, rather than publishing. Publishing remains in HTML where it is most effective). I'm told that RDF ?versions? of vcard and icalendar are out of date compared to the microformats. As such, it strikes me that rather than maintaining duplicate specifications, it would instead make sense to develop a set of standard transformations so that any microformat can be transformed from HTML to RDF, without requiring duplicate effort to maintain another spec. This I'm sure would relate closely to GRDDL, since that already deals with transformation. This latter issue seems valuable, and preferable to a situation where every processor of microformats and RDF comes up with their own incompatible conversions. Note, I'm talking about mapping rules, not separate specs. For example, we have the ?jCard? page on the wiki, which I still feel should be more generic ?JSON Mapping Rules? page that can cover parsing from any format, not just hcard. If this RDF mapping effort is pursued by anyone, I would again favour ?RDF Mapping Rules?, rather than ?rCard?, ?rCal? and ?rListing? ? duplicate specs not based in HTML are not something that this community was founded to produce. Cheers, Ben _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From scott at randomchaos.com Thu Aug 28 16:05:42 2008 From: scott at randomchaos.com (Scott Reynen) Date: Thu Aug 28 16:05:45 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C andRDFa Task Force In-Reply-To: <113670345-1219962236-cardhu_decombobulator_blackberry.rim.net-875986100-@bxe017.bisx.prod.on.blackberry> References: <48B6FB69.2030509@digitalbazaar.com><59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> <113670345-1219962236-cardhu_decombobulator_blackberry.rim.net-875986100-@bxe017.bisx.prod.on.blackberry> Message-ID: <3D277D44-3445-46CF-B292-B8C25776255F@randomchaos.com> On [Aug 28], at [ Aug 28] 4:23 , Tantek Celik wrote: > I would be very concerned that the microformats principles would be > compromised by any such efforts as Manu suggests, and efficiency of > parsing/parsers and other points listed are not worth compromising > the principles. That, or we'd compromise RDFa. As the two efforts have somewhat divergent priorities, I don't see how we could combine them without compromising on one side or both. Improving translation between the two, however, seems likely to provide many of the same benefits without the drawbacks. Peace, Scott From andreluis.pt at gmail.com Thu Aug 28 16:44:47 2008 From: andreluis.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Thu Aug 28 16:44:52 2008 Subject: [uf-discuss] HTML5, Microformats and RDFa In-Reply-To: <48B71466.5080708@digitalbazaar.com> References: <48B36EB2.30303@digitalbazaar.com> <4F16BA11-FCDC-4088-A2CF-0934DF4F79C3@randomchaos.com> <48B6EE5A.1050902@digitalbazaar.com> <48B71466.5080708@digitalbazaar.com> Message-ID: I had misread you there, Manu. I apologize. Thanks for clearing it up. Those 3x bullet points are a great summary. Well done. -- Andr? On Thu, Aug 28, 2008 at 10:11 PM, Manu Sporny wrote: > Andr? Lu?s wrote: >> Manu, >> the css based approach is somethin that has come up in discussions >> about semantics with fellow workers. I believe it does not trash all >> of the hard work the communities have don so far. > > I never said the discussions "trashed" all of our hard work. I said that > some of the discussions "ignore" (some) of the hard work performed by > this community as well as the RDFa community. > >> All it does, from >> what i gathered, is move the semantics from html and places it in a >> separate file/place. > > Right - which both this community and the RDFa community are opposed to: > > 1. We do not want semantics to be placed in separate files. > 2. We do not want vocabularies to be re-defined from site to site. > 3. We want semantic markup to be easy to author for regular people - CSS > is /not/ easy to author. > > That's what I was attempting to point out with my statement. Apologies > if I was not clear :) > > -- manu > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From msporny at digitalbazaar.com Thu Aug 28 23:06:50 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Aug 28 23:06:55 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force In-Reply-To: <59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> References: <48B6FB69.2030509@digitalbazaar.com> <59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> Message-ID: <48B791FA.9040303@digitalbazaar.com> Ben Ward wrote: >> It will take a couple of weeks to give examples of how this will all >> work, but I wanted to get feedback from this community before >> proceeding. We have a fantastic opportunity in front of us now - who in >> this community thinks that we should work with the W3C on this endeavor? > > I'm not sure I completely see the benefit in this, and seeing your > examples would be very helpful in getting a better idea of what you're > proposing. I'll get a set of examples written up soon, then. > From your bullet points, it seems to suggest taking > microformat vocabularies and expressing them in RDFa, rather than HTML? > It seems redundant for publishers. No, the markup would still happen in HTML, using Microformat properties, but instead of using @class, we MAY (not MUST) use @typeof, @property, and @content (in the case of machine-readable data) to express Microformats. The key being that these attributes are specifically designed to contain semantic data. Here's a brief example showing how we could get rid of the ABBR design problem by re-using RDFa's @content attribute. Note that this would work in HTML 4.01, XHTML1.1 and XHTML2:
    Start Wearing Purple by Gogol Bordello May 14th, 2002
    > However, I do have a somewhat related issue that you might consider part > of this effort. Some discussions I've had lately revealed usefulness in > being able to _map_ microformats into RDF, for the purpose of combining > microformats with other RDF vocabularies in a back-end somewhere (so, > conversion for processing, rather than publishing. Publishing remains in > HTML where it is most effective). Publishing would stay in HTML, where it is most effective. Nobody is suggesting that it move elsewhere - RDFa follows the same principles as Microformats in this case. As for the mapping between uF/RDF Vocabularies, I started a page to do just that back in October 2007: http://wiki.digitalbazaar.com/en/Mapping-ufs-to-rdfa Want me to move it to Microformats.org? > I'm told that RDF ?versions? of vcard and icalendar are out of date > compared to the microformats. I don't think they are, but could be mistaken... The last update to VCARD was on 22 February 2001: http://www.w3.org/TR/vcard-rdf and the vocabulary: http://www.w3.org/2001/vcard-rdf/3.0# The last update to iCalendar was on 29 September 2005 http://www.w3.org/TR/rdfcal/ and the vocabulary: http://www.w3.org/2002/12/cal# > As such, it strikes me that rather than > maintaining duplicate specifications, it would instead make sense to > develop a set of standard transformations so that any microformat can be > transformed from HTML to RDF, without requiring duplicate effort to > maintain another spec. This I'm sure would relate closely to GRDDL, > since that already deals with transformation. Yes, agreed, that would be useful. > Note, I'm talking about mapping rules, not separate specs. For example, > we have the ?jCard? page on the wiki, which I still feel should be more > generic ?JSON Mapping Rules? page that can cover parsing from any > format, not just hcard. We're also working on that in our company, but internally for now. There is the issue of a generic object representation format for semantic data objects. We have a generalized RDF-based representation for RDFa and Microformats now... but didn't think this community would be interested in such a solution. Should a wiki-page be started on various "JSON Mapping Rules" between uF/RDFa to JSON? -- manu From msporny at digitalbazaar.com Thu Aug 28 23:23:54 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Aug 28 23:23:59 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C andRDFa Task Force In-Reply-To: <113670345-1219962236-cardhu_decombobulator_blackberry.rim.net-875986100-@bxe017.bisx.prod.on.blackberry> References: <48B6FB69.2030509@digitalbazaar.com><59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> <113670345-1219962236-cardhu_decombobulator_blackberry.rim.net-875986100-@bxe017.bisx.prod.on.blackberry> Message-ID: <48B795FA.5090501@digitalbazaar.com> Tantek Celik wrote: > Completely agreed w all of Ben Ward's points. Even the ones that seem to state that RDFa does not operate in the realm of HTML? The reason I raise this point is that RDFa will be a W3C standard, applicable to XHTML1.1 and XHTML2 by the end of October 2008 (roughly). We're in the process of working out a HTML4+RDFa DTD and validator for HTML 4.01 as well. This will cover all current HTML family languages, so stating that RDFa is "outside" of HTML will only be accurate until the end of October 2008. After that, RDFa will be a part of all deployed HTML family languages. > In addition - I would be very concerned that the microformats > principles would be compromised by any such efforts as Manu suggests, > and efficiency of parsing/parsers and other points listed are not > worth compromising the principles. Nobody is suggesting that anybody compromise their principles. What I'm suggesting is that we may have figured out a way to bring a unified semantic data processing mechanism to RDFa and the Microformats community, across all current HTML family languages, without changing either community's approach to semantic data markup. If we're correct, it means a great deal of progress will have been made in both communities - all I'm asking for is that we cooperate with the W3C, are given the chance to do the work, and to see what falls out. -- manu From msporny at digitalbazaar.com Thu Aug 28 23:30:22 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Aug 28 23:30:26 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force In-Reply-To: <3D277D44-3445-46CF-B292-B8C25776255F@randomchaos.com> References: <48B6FB69.2030509@digitalbazaar.com><59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> <113670345-1219962236-cardhu_decombobulator_blackberry.rim.net-875986100-@bxe017.bisx.prod.on.blackberry> <3D277D44-3445-46CF-B292-B8C25776255F@randomchaos.com> Message-ID: <48B7977E.4020301@digitalbazaar.com> Scott Reynen wrote: > That, or we'd compromise RDFa. I can almost guarantee that neither side is going to compromise their set of beliefs. The Microformats community is too hard headed to do so, and the RDFa community has a very long, arduous W3C process to consider when changing anything major in the RDFa specification. > As the two efforts have somewhat > divergent priorities, I don't see how we could combine them without > compromising on one side or both. Let's give it a shot, give it a number of months, and see if either side feels like they're compromising on anything. I believe that approach is better than saying that it's impossible, throwing up our hands and giving up before we've even started. -- manu From Michael.Smethurst at bbc.co.uk Fri Aug 29 02:53:57 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Fri Aug 29 02:54:05 2008 Subject: [uf-discuss] hcard: born and died and flourished In-Reply-To: <9AD79001-F5D5-44C2-B38C-6FB7C19B15D3@tobyinkster.co.uk> Message-ID: Hi Toby / all On 21/8/08 14:49, "Toby A Inkster" wrote: >> And I've decided to use class="dday" for date of death and >> class='flourished-start' and class='flourished-end' for flourished >> dates >> >> Where either date is circa I've included ca. in the span with bday, >> dday, >> flourished-start or flourished-end: >> >> ca. 1575-ca. 1614 >> >> Does this look /feel right or am I missing something obvious? Is there >> established POSH for death date and flourished dates? > > I've previously recommended using 'dday' for date of death. DDAY is > the name of the property in the draft vCard 4.0 spec, so it seems > likely that any future extension of hCard that does include a date of > death will name the property 'dday'. > > 'dday' is already supported in Cognition cognition/>. > > I imagine that your use of 'ca.' in dates will cause problems for > some parsers, which expect to find an ISO 8601 date these - it > certainly breaks in Cognition. You may be able to improve parser > behaviour by using value excerpting: > > > ca. > 1575 > I've ended up with something similar: ca. 1660 - ca. 1732 Which can be seen here: http://bbc-hackday.dyndns.org:2840/people/45284 For flourished dates I've gone with: fl. ca. 1418 - ca. 1426 As here: http://bbc-hackday.dyndns.org:2840/people/45105 Does this seem acceptable? Again this is useful: http://www.library.yale.edu/cataloging/music/pernames.htm#dates http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From Michael.Smethurst at bbc.co.uk Fri Aug 29 03:49:15 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Fri Aug 29 03:49:23 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: <48ADA8B5.1070406@weborganics.co.uk> Message-ID: On 21/8/08 18:41, "Martin McEvoy" wrote: > Michael Smethurst wrote: >> Hi Martin >> >> >> On 14/8/08 15:48, "Martin McEvoy" wrote: >> >> >> *family-name-preposition* is probably more accurate to what you are >>> trying to describe "von" in dutch simply means "of" or "from" > Oh I quoted wrong there I meant to say "van" in Dutch simply means "of" > or "from" my bad! ;-) > > "von" still means "of" or "from" but is also used to indicate > German/Austrian nobility similar to "de" in French. > > >> , "O" as in >>> "O'Donnell", in Irish means "descendant of" or "grandson of" (in >>> Gaelic Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as >>> in "FitzGerald" is an Irish hash of the french "fils de" which also >>> means "son of". What I am trying to say is any of these prefixes simply >>> mean "of" and shouldn't really be considered part of their family name >>> although they mostly are, think "Van Gough" would you know who I meant >>> if I just said "Gough"? >> >> >> Family-name-preposition it is. You can see beethoven here: >> >> http://bbc-hackday.dyndns.org:1895/people/16 >> > Ahh Shame! the link doesn't work for me My bad. Was on internal port. Try http://bbc-hackday.dyndns.org:2840/people/16 > > > I will try it later > > > Best Wishes > > Martin McEvoy > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From martin at weborganics.co.uk Fri Aug 29 04:13:20 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 29 04:13:26 2008 Subject: [uf-discuss] hcard: additional additional names In-Reply-To: References: Message-ID: <48B7D9D0.5040002@weborganics.co.uk> Michael Smethurst wrote: > On 21/8/08 18:41, "Martin McEvoy" wrote: > > >> Michael Smethurst wrote: >> >>> Hi Martin >>> >>> >>> On 14/8/08 15:48, "Martin McEvoy" wrote: >>> >>> >>> *family-name-preposition* is probably more accurate to what you are >>> >>>> trying to describe "von" in dutch simply means "of" or "from" >>>> >> Oh I quoted wrong there I meant to say "van" in Dutch simply means "of" >> or "from" my bad! ;-) >> >> "von" still means "of" or "from" but is also used to indicate >> German/Austrian nobility similar to "de" in French. >> >> >> >>> , "O" as in >>> >>>> "O'Donnell", in Irish means "descendant of" or "grandson of" (in >>>> Gaelic Ua), Mc and Mac are again Irish meaning "son of", and "Fitz" as >>>> in "FitzGerald" is an Irish hash of the french "fils de" which also >>>> means "son of". What I am trying to say is any of these prefixes simply >>>> mean "of" and shouldn't really be considered part of their family name >>>> although they mostly are, think "Van Gough" would you know who I meant >>>> if I just said "Gough"? >>>> >>> >>> >>> Family-name-preposition it is. You can see beethoven here: >>> >>> http://bbc-hackday.dyndns.org:1895/people/16 >>> >>> >> Ahh Shame! the link doesn't work for me >> > > My bad. Was on internal port. Try > http://bbc-hackday.dyndns.org:2840/people/16 > Thank you Michael looks Great the vcard extracts nicely too try: http://transformr.co.uk/hcard/http://bbc-hackday.dyndns.org:2840/people/16 Best Wishes Martin McEvoy >> I will try it later >> >> >> Best Wishes >> >> Martin McEvoy >> _______________________________________________ >> microformats-discuss mailing list >> microformats-discuss@microformats.org >> http://microformats.org/mailman/listinfo/microformats-discuss >> > > > http://www.bbc.co.uk/ > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From Michael.Smethurst at bbc.co.uk Fri Aug 29 04:17:09 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Fri Aug 29 04:17:16 2008 Subject: [uf-discuss] hCard: Quick question about nicknames Message-ID: Hello The data I'm working with has an optional pseudonym field on the people table. Some of the values in here look like nicknames (eg le cadet, le grand, JC001): http://bbc-hackday.dyndns.org:2840/people/44970 http://bbc-hackday.dyndns.org:2840/people/31944 http://bbc-hackday.dyndns.org:2840/people/45140 But others look more like proper pseudonyms: http://bbc-hackday.dyndns.org:2840/people/1394 http://bbc-hackday.dyndns.org:2840/people/1381 For now I'm marking them all up with class="nickname". Is this stretching the semantics of nickname too much? Should I just be POSH and use class="pseudonym"? http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From mail at ciaranmcnulty.com Fri Aug 29 04:24:37 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Aug 29 04:24:41 2008 Subject: [uf-discuss] Employment end dates in hResume - outstanding issue Message-ID: As there's been some discussion about moving drafts into specification status lately, I'd like to address one of the outstanding issues in hResume. The problem that has arisen quite a few times, is that a lot of people with a resume are currently employed and don't know what to provide as the DTEND in their markup for their current job. The problem is not as apparent with educational events, as they tend to have a defined end point even if it's in the future (PhD students may argue, mind you). The solutions in the wild tend to be either: 1. Set the DTEND to the date the resume was generated. The problem with this approach is that if I save your resume and come back and look at it in a year's time, I might think your employment period ended on that date. 2. Set the DTEND to some far-future date. This could be confusing and could be taken to indicate that your contract ends at some specified date in the future. 3. Set the DTEND to the same as DTSTART. This makes the event be either instantaneous or 1 day long in hCalendar, which could be confusing. 4. Omit the DTEND. This is actually equivalent to option 3 (see http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html) Personally I don't think this problem is going to be solvable within hCalendar, and 'ongoing' events may be somewhat out of spec for that particular format. I would lean towards choosing one of the above approaches and defining some optional additional semantic within hResume that indicates that an experience event is 'ongoing'. My particular preference would be to recommend option 4 and add a @class="ongoing" that can be added to an event in hResume:
    Managing Director Example PLC 2002 to 2005
    CEO Another PLC 2005 to Present
    When viewed by an hCalendar parser, the second event would be considered to be an all-day event occuring on 23rd Jan 2005. An hResume parser would however note the presence of @class="ongoing" within the event and be able to I'd welcome any feedback about: A. Whether this is a problem that needs solving, or if there's an obvious way of representing these events in hCalendar that we've all missed. B. Whether it needs to be solved by adding a concept of 'now' to hCalendar or whether it needs to be solved in hResume as I've suggested. C. What people think of my example markup. Thanks, -Ciaran McNulty From mail at ciaranmcnulty.com Fri Aug 29 04:30:27 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Aug 29 04:30:31 2008 Subject: [uf-discuss] hCard: Quick question about nicknames In-Reply-To: References: Message-ID: On Fri, Aug 29, 2008 at 12:17 PM, Michael Smethurst wrote: > For now I'm marking them all up with class="nickname". Is this stretching > the semantics of nickname too much? > > Should I just be POSH and use class="pseudonym"? Even if you use class="pseudonym" you still need to decide whether to populate N or NICKNAME. What I mean is you either say George Eliot is given-name + family-name or a nickname, regardless of any extra POSH semantics you'd care to add. The vCard RFC seems remarkably unenlightening about the semantics of the different fields: " Type special note: The nickname is the descriptive name given instead of or in addition to the one belonging to a person, place, or thing. It can also be used to specify a familiar form of a proper name specified by the FN or N types. Type example: NICKNAME:Robbie NICKNAME:Jim,Jimmie " Based on the two examples I'd lean towards markup up pseudonyms that are structurally formatted like names as names, with everything else as nickname, i.e.: George Eliot = given-name, family-name with a pseudonym wrapper El Greco = nickname However I don't think there's any hard-and-fast rule about it. -Ciaran McNulty From Michael.Smethurst at bbc.co.uk Fri Aug 29 04:36:31 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Fri Aug 29 04:36:39 2008 Subject: [uf-discuss] hCard: Quick question about nicknames In-Reply-To: Message-ID: Hi Ciaran On 29/8/08 12:30, "Ciaran McNulty" wrote: > On Fri, Aug 29, 2008 at 12:17 PM, Michael Smethurst > wrote: >> For now I'm marking them all up with class="nickname". Is this stretching >> the semantics of nickname too much? >> >> Should I just be POSH and use class="pseudonym"? > > Even if you use class="pseudonym" you still need to decide whether to > populate N or NICKNAME. > > What I mean is you either say George Eliot is given-name + family-name > or a nickname, regardless of any extra POSH semantics you'd care to > add. > > The vCard RFC seems remarkably unenlightening about the semantics of > the different fields: > > " Type special note: The nickname is the descriptive name given instead > of or in addition to the one belonging to a person, place, or thing. > It can also be used to specify a familiar form of a proper name > specified by the FN or N types. > > Type example: > > NICKNAME:Robbie > > NICKNAME:Jim,Jimmie > " > > Based on the two examples I'd lean towards markup up pseudonyms that > are structurally formatted like names as names, with everything else > as nickname, i.e.: > > George Eliot = given-name, family-name with a pseudonym wrapper > El Greco = nickname Don't have the pseudonym data at that granular a level Family name, given name and additional names are given in addition so I'm fn-ing those > > However I don't think there's any hard-and-fast rule about it. > > -Ciaran McNulty > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From martin at weborganics.co.uk Fri Aug 29 05:32:11 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 29 05:32:18 2008 Subject: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force In-Reply-To: <48B791FA.9040303@digitalbazaar.com> References: <48B6FB69.2030509@digitalbazaar.com> <59936330-2D65-49F5-AD6F-943ACBE6DC2F@ben-ward.co.uk> <48B791FA.9040303@digitalbazaar.com> Message-ID: <48B7EC4B.6020201@weborganics.co.uk> Hello Manu, all Manu I think you need to explain that RDFa is a way of expressing semantics in html, not just a way of expressing RDF annotations in html Manu Sporny wrote: > Ben Ward wrote: > >>> It will take a couple of weeks to give examples of how this will all >>> work, but I wanted to get feedback from this community before >>> proceeding. We have a fantastic opportunity in front of us now - who in >>> this community thinks that we should work with the W3C on this endeavor? >>> >> I'm not sure I completely see the benefit in this, and seeing your >> examples would be very helpful in getting a better idea of what you're >> proposing. >> > > I'll get a set of examples written up soon, then. > > >> From your bullet points, it seems to suggest taking >> microformat vocabularies and expressing them in RDFa, rather than HTML? >> It seems redundant for publishers. >> > No, the markup would still happen in HTML, using Microformat properties, > but instead of using @class, we MAY (not MUST) use @typeof, @property, > and @content (in the case of machine-readable data) to express > Microformats. > Its interesting to point out that most people who publish Microformats, are not really expressing any semantics at all, @class doesn't expresses any semantics without meta data profiles and most publishers do not use them, yes some search engines can pick up hcards and calendar events but really that's about it. any other Microformats are Ignored mostly. > The key being that these attributes are specifically designed to contain > semantic data. Here's a brief example showing how we could get rid of > the ABBR design problem by re-using RDFa's @content attribute. Note that > this would work in HTML 4.01, XHTML1.1 and XHTML2: > >
    > Start Wearing Purple by > Gogol Bordello > May 14th, 2002 >
    > That is a good example of how microformats could be used in RDFa everything (to me) seems to be in the right place. @typeof can include any root Microformat Class names @property is any Microformat Property name @rel is any microformat rel value Microformats Map pretty well in this way > >> However, I do have a somewhat related issue that you might consider part >> of this effort. Some discussions I've had lately revealed usefulness in >> being able to _map_ microformats into RDF, for the purpose of combining >> microformats with other RDF vocabularies in a back-end somewhere (so, >> conversion for processing, rather than publishing. Publishing remains in >> HTML where it is most effective). >> > > Publishing would stay in HTML, where it is most effective. Nobody is > suggesting that it move elsewhere - RDFa follows the same principles as > Microformats in this case. > > As for the mapping between uF/RDF Vocabularies, I started a page to do > just that back in October 2007: > > http://wiki.digitalbazaar.com/en/Mapping-ufs-to-rdfa > > Want me to move it to Microformats.org? > I think you should Manu, so the rest of the community can read your most excellent work :-) > >> I'm told that RDF ?versions? of vcard and icalendar are out of date >> compared to the microformats. >> > > I don't think they are, but could be mistaken... > > The last update to VCARD was on 22 February 2001: > http://www.w3.org/TR/vcard-rdf > and the vocabulary: > http://www.w3.org/2001/vcard-rdf/3.0# > > The last update to iCalendar was on 29 September 2005 > http://www.w3.org/TR/rdfcal/ > and the vocabulary: > http://www.w3.org/2002/12/cal# > > >> As such, it strikes me that rather than >> maintaining duplicate specifications, it would instead make sense to >> develop a set of standard transformations so that any microformat can be >> transformed from HTML to RDF, without requiring duplicate effort to >> maintain another spec. This I'm sure would relate closely to GRDDL, >> since that already deals with transformation. >> > > Yes, agreed, that would be useful. > Agreed. > >> Note, I'm talking about mapping rules, not separate specs. For example, >> we have the ?jCard? page on the wiki, which I still feel should be more >> generic ?JSON Mapping Rules? page that can cover parsing from any >> format, not just hcard. >> > > We're also working on that in our company, but internally for now. There > is the issue of a generic object representation format for semantic data > objects. We have a generalized RDF-based representation for RDFa and > Microformats now... but didn't think this community would be interested > in such a solution. Should a wiki-page be started on various "JSON > Mapping Rules" between uF/RDFa to JSON? > > -- manu > Best Wishes Martin McEvoy > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From james at atomless.com Fri Aug 29 05:58:51 2008 From: james at atomless.com (James Tindall) Date: Fri Aug 29 05:59:01 2008 Subject: [uf-discuss] xfn relationships of influence Message-ID: <48B7F28B.2090807@atomless.com> I've been refering to the xfn-brainstorming wiki for guidance on additional xfn ralationships. I can see from the wiki page that there's a desire to find a word to define the inverse of 'follower' but what I need is to offer users more options to choose from on both sides of the relationship - specifically in relation to the flow of influence. Are there any examples or points of reference out there that I may have missed that already extend the xfn relationship options in this direction? Or should I not even be thinking about doing such a thing because xfn is not about influence? The relationships I'm considering fall into two predicate groups, influence out(applied) and influence in(received). Influence out: 'follower', 'student', 'subscriber', 'listener', 'reader', 'viewer', 'supporter' and 'collaborator'. Influence in: 'inspiration', 'favourite', 'teacher', 'mentor', 'adviser', 'influence', 'source' and 'collaborator'. I'm interested to hear any thoughts on this - whether I'm reinventing some wheel - if I'm adding complexity where none is needed or any other suggestions? cheers, =James.Tindall From msporny at digitalbazaar.com Fri Aug 29 11:17:01 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Aug 29 11:17:05 2008 Subject: [uf-discuss] HTML5+RDFa discussion on WHATWG involves Microformats Message-ID: <48B83D1D.2020109@digitalbazaar.com> Samuel Santos has started blogging about the HTML5 + RDFa/Microformats discussion that we've been having in WHATWG: http://www.samaxes.com/2008/08/29/the-semantic-web-and-rdfa/ -- manu From tantek at cs.stanford.edu Fri Aug 29 13:20:46 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Fri Aug 29 13:21:11 2008 Subject: [uf-discuss] xfn relationships of influence In-Reply-To: <48B7F28B.2090807@atomless.com> References: <48B7F28B.2090807@atomless.com> Message-ID: <1744404272-1220041265-cardhu_decombobulator_blackberry.rim.net-600340433-@bxe118.bisx.prod.on.blackberry> Hi James, I think you have some interesting ideas here and it would be useful to capture them in the xfn-brainstorming page. Perhaps create a new (sub)section "influences and influencers" and add some of your thoughts starting with: "The relationships I'm considering fall into two predicate groups, influence out(applied) and influence in(received)." Thanks, Tantek -----Original Message----- From: James Tindall Date: Fri, 29 Aug 2008 13:58:51 To: Microformats Discuss Subject: [uf-discuss] xfn relationships of influence I've been refering to the xfn-brainstorming wiki for guidance on additional xfn ralationships. I can see from the wiki page that there's a desire to find a word to define the inverse of 'follower' but what I need is to offer users more options to choose from on both sides of the relationship - specifically in relation to the flow of influence. Are there any examples or points of reference out there that I may have missed that already extend the xfn relationship options in this direction? Or should I not even be thinking about doing such a thing because xfn is not about influence? The relationships I'm considering fall into two predicate groups, influence out(applied) and influence in(received). Influence out: 'follower', 'student', 'subscriber', 'listener', 'reader', 'viewer', 'supporter' and 'collaborator'. Influence in: 'inspiration', 'favourite', 'teacher', 'mentor', 'adviser', 'influence', 'source' and 'collaborator'. I'm interested to hear any thoughts on this - whether I'm reinventing some wheel - if I'm adding complexity where none is needed or any other suggestions? cheers, =James.Tindall _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss