From brian.suda at gmail.com Fri Dec 1 03:14:37 2006 From: brian.suda at gmail.com (Brian Suda) Date: Fri Dec 1 03:14:42 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <00a701c714ab$c1732360$a7dd15ac@ds.corp.yahoo.com> References: <00a701c714ab$c1732360$a7dd15ac@ds.corp.yahoo.com> Message-ID: <21e770780612010314w1dabb014n54e18bb3fb1416a4@mail.gmail.com> hm... not exactly sure what you mean? there is hAtom to mark-up HTML as a feed. But i think you are asking for a way to say: "That RSS over there is about this person!" (right?) if so, then i would look at the XFN rel="me" property. That is used for identity consolidation, which (i think) is what you are asking about... if not just reply and we can see what we can do. -brian On 11/30/06, Ted Drake wrote: > Hi all > > I am adding hcard to a page and wondered if there was a pattern for defining > the rss feed for an individual. > It seems like there would already be something simple, i.e. class="rss" or > rel="rss". I didn't see anything. > > Do you have a suggestion? > > Thanks > > Ted Drake > Yahoo! Tech - Tech Made Easy > > Member of the Yahoo! Accessibility StakeholdersGroup > > Is your site voice recognition friendly? > If you use an image for a button, the alt text needs to match the text in > the image. If the user says "hit send" nothing will happen if the alt text > says "subscribe to our wonderful newsletter by hitting this send button." > The same goes with using CSS image replacement techniques. > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- brian suda http://suda.co.uk From kmarks at technorati.com Fri Dec 1 04:58:41 2006 From: kmarks at technorati.com (Kevin Marks) Date: Fri Dec 1 04:59:50 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <21e770780612010314w1dabb014n54e18bb3fb1416a4@mail.gmail.com> References: <00a701c714ab$c1732360$a7dd15ac@ds.corp.yahoo.com> <21e770780612010314w1dabb014n54e18bb3fb1416a4@mail.gmail.com> Message-ID: If the page is for a person, then the RSS is an alternative. Use the Feed autodiscovery syntax makes sense: http://feedautodiscovery.org/doku.php but you could apply it to an Ted Drake's feed On Dec 1, 2006, at 3:14 AM, Brian Suda wrote: > hm... not exactly sure what you mean? there is hAtom to mark-up HTML > as a feed. > > But i think you are asking for a way to say: "That RSS over there is > about this person!" (right?) if so, then i would look at the XFN > rel="me" property. That is used for identity consolidation, which (i > think) is what you are asking about... if not just reply and we can > see what we can do. > > -brian > > On 11/30/06, Ted Drake wrote: >> Hi all >> >> I am adding hcard to a page and wondered if there was a pattern for >> defining >> the rss feed for an individual. >> It seems like there would already be something simple, i.e. >> class="rss" or >> rel="rss". I didn't see anything. >> >> Do you have a suggestion? From davidjanes at blogmatrix.com Fri Dec 1 05:45:29 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Dec 1 05:45:33 2006 Subject: [uf-discuss] simple rss question In-Reply-To: References: <00a701c714ab$c1732360$a7dd15ac@ds.corp.yahoo.com> <21e770780612010314w1dabb014n54e18bb3fb1416a4@mail.gmail.com> Message-ID: <21e523c20612010545u57b496d3idd42ccd1f00b7f2b@mail.gmail.com> If this is a url inside a hcard (if I understand Ted's original post correctly), wouldn't this be prefered: Ted Drake's feed I.e. add the "url" class from hCard [1][2]? Regards, etc... [1] http://microformats.org/wiki/hcard#More_Semantic_Equivalents [2] http://microformats.org/wiki/hcard-examples#3.6.8_URL_Type_Definition On 12/1/06, Kevin Marks wrote: > If the page is for a person, then the RSS is an alternative. Use the > Feed autodiscovery syntax makes sense: > > http://feedautodiscovery.org/doku.php > > but you could apply it to an > href="http://example.com/feed.rss" >Ted Drake's feed > > > On Dec 1, 2006, at 3:14 AM, Brian Suda wrote: > > > hm... not exactly sure what you mean? there is hAtom to mark-up HTML > > as a feed. > > > > But i think you are asking for a way to say: "That RSS over there is > > about this person!" (right?) if so, then i would look at the XFN > > rel="me" property. That is used for identity consolidation, which (i > > think) is what you are asking about... if not just reply and we can > > see what we can do. > > > > -brian > > > > On 11/30/06, Ted Drake wrote: > >> Hi all > >> > >> I am adding hcard to a page and wondered if there was a pattern for > >> defining > >> the rss feed for an individual. > >> It seems like there would already be something simple, i.e. > >> class="rss" or > >> rel="rss". I didn't see anything. > >> > >> Do you have a suggestion? > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com From brian.suda at gmail.com Fri Dec 1 06:10:51 2006 From: brian.suda at gmail.com (Brian Suda) Date: Fri Dec 1 06:11:01 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <21e523c20612010545u57b496d3idd42ccd1f00b7f2b@mail.gmail.com> References: <00a701c714ab$c1732360$a7dd15ac@ds.corp.yahoo.com> <21e770780612010314w1dabb014n54e18bb3fb1416a4@mail.gmail.com> <21e523c20612010545u57b496d3idd42ccd1f00b7f2b@mail.gmail.com> Message-ID: <21e770780612010610h2594bedt5ac34f4ce6e661dc@mail.gmail.com> On 12/1/06, David Janes wrote: > If this is a url inside a hcard (if I understand Ted's original post > correctly), wouldn't this be prefered: > > rel="alternate url" type="application/rss+xml" > title="RSS feed of Ted Drake" > href="http://example.com/feed.rss" >Ted Drake's feed > > I.e. add the "url" class from hCard [1][2]? --- yes, if you are trying to list all the URLs that are about an hCard then it would make sense to add the class="url" as well. vCard does not distinguishes between URL TYPES, so the fact that this is an RSS feed is not taken into account - for the purpose of vCard it is JUST a url, that URL might point to an HTML, a GIF, an EXE, or an XML file - vCard doesn't care. This certainly does not stop you from adding more semantics in the form of @type data and/or other class values, "rss|feed|atom|syncation|etc" there is nothing preventing you from doing so. -brian > > Regards, etc... > > [1] http://microformats.org/wiki/hcard#More_Semantic_Equivalents > [2] http://microformats.org/wiki/hcard-examples#3.6.8_URL_Type_Definition > > On 12/1/06, Kevin Marks wrote: > > If the page is for a person, then the RSS is an alternative. Use the > > Feed autodiscovery syntax makes sense: > > > > http://feedautodiscovery.org/doku.php > > > > but you could apply it to an > > > > href="http://example.com/feed.rss" >Ted Drake's feed > > > > > > On Dec 1, 2006, at 3:14 AM, Brian Suda wrote: > > > > > hm... not exactly sure what you mean? there is hAtom to mark-up HTML > > > as a feed. > > > > > > But i think you are asking for a way to say: "That RSS over there is > > > about this person!" (right?) if so, then i would look at the XFN > > > rel="me" property. That is used for identity consolidation, which (i > > > think) is what you are asking about... if not just reply and we can > > > see what we can do. > > > > > > -brian > > > > > > On 11/30/06, Ted Drake wrote: > > >> Hi all > > >> > > >> I am adding hcard to a page and wondered if there was a pattern for > > >> defining > > >> the rss feed for an individual. > > >> It seems like there would already be something simple, i.e. > > >> class="rss" or > > >> rel="rss". I didn't see anything. > > >> > > >> Do you have a suggestion? > > > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss > > > > > -- > David Janes > Founder, BlogMatrix > http://www.blogmatrix.com > http://www.onamine.com > http://blogmatrix.blogmatrix.com > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- brian suda http://suda.co.uk From tdrake at yahoo-inc.com Fri Dec 1 09:02:18 2006 From: tdrake at yahoo-inc.com (Ted Drake) Date: Fri Dec 1 09:02:45 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <21e770780612010610h2594bedt5ac34f4ce6e661dc@mail.gmail.com> Message-ID: <000901c7156a$75580d50$a7dd15ac@ds.corp.yahoo.com> Thank you everyone, this is very helpful. Should we add it to the vcard twiki? I think this is a common enough situation that people could use the advice. I will update my hcard with these attributes. Ted -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Brian Suda Sent: Friday, December 01, 2006 6:11 AM To: Microformats Discuss Subject: Re: [uf-discuss] simple rss question On 12/1/06, David Janes wrote: > If this is a url inside a hcard (if I understand Ted's original post > correctly), wouldn't this be prefered: > > rel="alternate url" type="application/rss+xml" > title="RSS feed of Ted Drake" > href="http://example.com/feed.rss" >Ted Drake's feed > > I.e. add the "url" class from hCard [1][2]? --- yes, if you are trying to list all the URLs that are about an hCard then it would make sense to add the class="url" as well. vCard does not distinguishes between URL TYPES, so the fact that this is an RSS feed is not taken into account - for the purpose of vCard it is JUST a url, that URL might point to an HTML, a GIF, an EXE, or an XML file - vCard doesn't care. This certainly does not stop you from adding more semantics in the form of @type data and/or other class values, "rss|feed|atom|syncation|etc" there is nothing preventing you from doing so. -brian > > Regards, etc... > > [1] http://microformats.org/wiki/hcard#More_Semantic_Equivalents > [2] http://microformats.org/wiki/hcard-examples#3.6.8_URL_Type_Definition > > On 12/1/06, Kevin Marks wrote: > > If the page is for a person, then the RSS is an alternative. Use the > > Feed autodiscovery syntax makes sense: > > > > http://feedautodiscovery.org/doku.php > > > > but you could apply it to an > > > > href="http://example.com/feed.rss" >Ted Drake's feed > > > > > > On Dec 1, 2006, at 3:14 AM, Brian Suda wrote: > > > > > hm... not exactly sure what you mean? there is hAtom to mark-up HTML > > > as a feed. > > > > > > But i think you are asking for a way to say: "That RSS over there is > > > about this person!" (right?) if so, then i would look at the XFN > > > rel="me" property. That is used for identity consolidation, which (i > > > think) is what you are asking about... if not just reply and we can > > > see what we can do. > > > > > > -brian > > > > > > On 11/30/06, Ted Drake wrote: > > >> Hi all > > >> > > >> I am adding hcard to a page and wondered if there was a pattern for > > >> defining > > >> the rss feed for an individual. > > >> It seems like there would already be something simple, i.e. > > >> class="rss" or > > >> rel="rss". I didn't see anything. > > >> > > >> Do you have a suggestion? > > > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss > > > > > -- > David Janes > Founder, BlogMatrix > http://www.blogmatrix.com > http://www.onamine.com > http://blogmatrix.blogmatrix.com > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- brian suda http://suda.co.uk _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From brian.suda at gmail.com Fri Dec 1 09:13:53 2006 From: brian.suda at gmail.com (Brian Suda) Date: Fri Dec 1 09:13:56 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <000901c7156a$75580d50$a7dd15ac@ds.corp.yahoo.com> References: <21e770780612010610h2594bedt5ac34f4ce6e661dc@mail.gmail.com> <000901c7156a$75580d50$a7dd15ac@ds.corp.yahoo.com> Message-ID: <21e770780612010913o40d1a9dat57a042863b1c79cf@mail.gmail.com> feel free to add it to the FAQ section if hCard, but what exactly was your original question? and do you have a URL so it is easier to discuss the mark-up options? -brian On 12/1/06, Ted Drake wrote: > Thank you everyone, this is very helpful. > Should we add it to the vcard twiki? I think this is a common enough > situation that people could use the advice. I will update my hcard with > these attributes. > > Ted > > > -----Original Message----- > From: microformats-discuss-bounces@microformats.org > [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Brian > Suda > Sent: Friday, December 01, 2006 6:11 AM > To: Microformats Discuss > Subject: Re: [uf-discuss] simple rss question > > On 12/1/06, David Janes wrote: > > If this is a url inside a hcard (if I understand Ted's original post > > correctly), wouldn't this be prefered: > > > > > rel="alternate url" type="application/rss+xml" > > title="RSS feed of Ted Drake" > > href="http://example.com/feed.rss" >Ted Drake's feed > > > > I.e. add the "url" class from hCard [1][2]? > > --- yes, if you are trying to list all the URLs that are about an > hCard then it would make sense to add the class="url" as well. vCard > does not distinguishes between URL TYPES, so the fact that this is an > RSS feed is not taken into account - for the purpose of vCard it is > JUST a url, that URL might point to an HTML, a GIF, an EXE, or an XML > file - vCard doesn't care. This certainly does not stop you from > adding more semantics in the form of @type data and/or other class > values, "rss|feed|atom|syncation|etc" there is nothing preventing you > from doing so. > > -brian > > > > > Regards, etc... > > > > [1] http://microformats.org/wiki/hcard#More_Semantic_Equivalents > > [2] http://microformats.org/wiki/hcard-examples#3.6.8_URL_Type_Definition > > > > On 12/1/06, Kevin Marks wrote: > > > If the page is for a person, then the RSS is an alternative. Use the > > > Feed autodiscovery syntax makes sense: > > > > > > http://feedautodiscovery.org/doku.php > > > > > > but you could apply it to an > > > > > > > href="http://example.com/feed.rss" >Ted Drake's feed > > > > > > > > > On Dec 1, 2006, at 3:14 AM, Brian Suda wrote: > > > > > > > hm... not exactly sure what you mean? there is hAtom to mark-up HTML > > > > as a feed. > > > > > > > > But i think you are asking for a way to say: "That RSS over there is > > > > about this person!" (right?) if so, then i would look at the XFN > > > > rel="me" property. That is used for identity consolidation, which (i > > > > think) is what you are asking about... if not just reply and we can > > > > see what we can do. > > > > > > > > -brian > > > > > > > > On 11/30/06, Ted Drake wrote: > > > >> Hi all > > > >> > > > >> I am adding hcard to a page and wondered if there was a pattern for > > > >> defining > > > >> the rss feed for an individual. > > > >> It seems like there would already be something simple, i.e. > > > >> class="rss" or > > > >> rel="rss". I didn't see anything. > > > >> > > > >> Do you have a suggestion? > > > > > > _______________________________________________ > > > microformats-discuss mailing list > > > microformats-discuss@microformats.org > > > http://microformats.org/mailman/listinfo/microformats-discuss > > > > > > > > > -- > > David Janes > > Founder, BlogMatrix > > http://www.blogmatrix.com > > http://www.onamine.com > > http://blogmatrix.blogmatrix.com > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss > > > > > -- > brian suda > http://suda.co.uk > _______________________________________________ > 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 > -- brian suda http://suda.co.uk From tdrake at yahoo-inc.com Fri Dec 1 10:17:06 2006 From: tdrake at yahoo-inc.com (Ted Drake) Date: Fri Dec 1 10:17:15 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <21e770780612010913o40d1a9dat57a042863b1c79cf@mail.gmail.com> Message-ID: <002601c71574$e8bba630$a7dd15ac@ds.corp.yahoo.com> Hi I'm working on something that isn't ready for public use. Here's a sample of the generated code:
Jane Doe - The Best of Foo Foo
Jane Doe View BioMy Yahoo RSS
Headline -

short summary of the main headline

Yahoo! Finance
You can see the link to the RSS feed near the middle of the definition link. I noticed this doesn't trigger the auto-discovery for Firefox 1.6. My class="microformatdetail" hides the information from the screen but provides it to the browser with positioning. I originally questioned how to markup the RSS link with microformats to work with the hcard format. How does this look? Ted -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Brian Suda Sent: Friday, December 01, 2006 9:14 AM To: Microformats Discuss Subject: Re: RE: [uf-discuss] simple rss question feel free to add it to the FAQ section if hCard, but what exactly was your original question? and do you have a URL so it is easier to discuss the mark-up options? -brian From brian.suda at gmail.com Fri Dec 1 10:32:24 2006 From: brian.suda at gmail.com (Brian Suda) Date: Fri Dec 1 10:32:29 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <002601c71574$e8bba630$a7dd15ac@ds.corp.yahoo.com> References: <21e770780612010913o40d1a9dat57a042863b1c79cf@mail.gmail.com> <002601c71574$e8bba630$a7dd15ac@ds.corp.yahoo.com> Message-ID: <21e770780612011032w49a463d9xe0d14d898a81b6af@mail.gmail.com> Thanks for the example, there are a few issues that i can see. #1, you have a class="title" for "The Best of Foo Foo", title inside a vcard means "job-title" so that would be pulled incorrectly. Next, you have "singleauth" both the hCite and hAtom use 'author' so you might consider using that (not sure what your overall goal is?) #2 The whole Headlines section looks alot to me like hAtom, feeds. You might consider working that in too (maybe in a later release). #3 you have a class="url" on the RSS, it would probably be wise to add one to the BIO as well. On the whole it looks good. When it gets further along please email us with a public link. Thanks, -brian On 12/1/06, Ted Drake wrote: > Hi > I'm working on something that isn't ready for public use. > Here's a sample of the generated code: > > >
>
> Jane Doe - The Best of Foo > Foo >
>
> class="url">Jane Doe > > View Bio href="http://add.my.yahoo.com/rss?url=foo.html" title="Add Jane Doe's > articles to your My Yahoo page">My > Yahoo > > src="/images/icon-rss.gif" alt="RSS"> > >
>
> Headline > -

short summary of the main headline

> >
>
> >
>
Yahoo! Finance
>
> > > You can see the link to the RSS feed near the middle of the definition link. > I noticed this doesn't trigger the auto-discovery for Firefox 1.6. > > My class="microformatdetail" hides the information from the screen but > provides it to the browser with positioning. > > I originally questioned how to markup the RSS link with microformats to work > with the hcard format. How does this look? > > Ted > > > > > > > > > > > > > > > > -----Original Message----- > From: microformats-discuss-bounces@microformats.org > [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Brian > Suda > Sent: Friday, December 01, 2006 9:14 AM > To: Microformats Discuss > Subject: Re: RE: [uf-discuss] simple rss question > > feel free to add it to the FAQ section if hCard, but what exactly was > your original question? and do you have a URL so it is easier to > discuss the mark-up options? > > -brian > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Fri Dec 1 11:31:31 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Dec 1 11:33:07 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <21e770780612010610h2594bedt5ac34f4ce6e661dc@mail.gmail.com> References: <00a701c714ab$c1732360$a7dd15ac@ds.corp.yahoo.com> <21e770780612010314w1dabb014n54e18bb3fb1416a4@mail.gmail.com> <21e523c20612010545u57b496d3idd42ccd1f00b7f2b@mail.gmail.com> <21e770780612010610h2594bedt5ac34f4ce6e661dc@mail.gmail.com> Message-ID: <6fBUOggTMIcFFwIE@pigsonthewing.org.uk> In message <21e770780612010610h2594bedt5ac34f4ce6e661dc@mail.gmail.com>, Brian Suda writes >vCard >does not distinguishes between URL TYPES, so the fact that this is an >RSS feed is not taken into account If you think that's a problem, you might want to mention it on: -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From digitalspaghetti at googlemail.com Fri Dec 1 12:18:33 2006 From: digitalspaghetti at googlemail.com (digital spaghetti) Date: Fri Dec 1 12:18:38 2006 Subject: [uf-discuss] Mailing list debate moved & new proposal In-Reply-To: <14596d040611280204r6f7d6da2h7a15267969760d06@mail.gmail.com> References: <84ce626f0610241124w70e9cf89pb873752faaf01e14@mail.gmail.com> <8ad71be30610241131h226db8b2u7555a70fcab3f615@mail.gmail.com> <84ce626f0610241143x4de5b3cby4e3077ff7f5bfd85@mail.gmail.com> <6ca82b0f0611271439x375b8c6cycf98c57a6e702115@mail.gmail.com> <6ca82b0f0611272012w7a89a0cfl49e742ddf2518bdc@mail.gmail.com> <14596d040611280204r6f7d6da2h7a15267969760d06@mail.gmail.com> Message-ID: I agree. Microformats are very organic at the moment and I think making more lists to discuss it would have the effect of braking up the community. Discussing on one list allows me to see what's going on as a whole and though one microformat might not suit my needs its good to see what's happening with it and if I can contibute in any way. Please let's not start foking at this early stage!!! Tane http://digitalspaghett.me.uk On 11/28/06, Tim Hodson wrote: > I'm someone who signed up to this list yesterday as a newbie. I would > rather have one list to look through, I can easily sift entries that > are not relevant to me, but the sifting process also raises my > awareness of topics and nuances of debate within the community. I do > not want to be subscribing to every new list that comes along on the > off chance that there might be something useful there. > > Cheers, > Tim > ======================= > http://timhodson.com > http://informationtakesover.co.uk > > On 28/11/06, Ben Buchanan wrote: > > > >I'd expect that if someone was keen enough to be joining this list > > > >they could probably pick up the concept pretty quickly. > > > It's the people who are *not* keen enough to be joining this list who we > > > need to consider. > > > > I'm not totally convinced about that ;) It's hard enough for keen > > people to find the time to work on uf stuff. > > > > > My original comment was: > > > For example, several academic and professional taxonomists have > > > told me in e-mail that they would be interested in the species > > > proposal, (and one astronomer, likewise, for mars/ luna), but do > > > not have the time to follow a general mailing list; indeed, a > > > couple asked me specifically if I would set up a separate > > > mailing list for the subject. > > > > I wouldn't bet on academics contributing even if you do bend over > > backwards to accommodate them*. If they're saying they're too busy to > > read this list, then they could easily be too busy to contribute to > > any list. > > > > That said, if a particular topic has several people expressing > > interest; I guess what's the harm in setting up the list as a trial? > > See if anyone other than those few people subscribe, as well as see > > how the discussion goes. It might be an excellent result. > > > > cheers, > > > > Ben > > > > > > [*] Perhaps I'm just cynical from spending the last six years in > > higher education ;) > > > > -- > > --- > > --- The future has arrived; it's just not > > --- evenly distributed. - William Gibson > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss > > > > > > -- > Tim Hodson > informationtakesover.co.uk > www.timhodson.co.uk > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From bdarcus.lists at gmail.com Fri Dec 1 13:55:01 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Fri Dec 1 13:55:08 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: References: Message-ID: On 11/30/06, Michael McCracken wrote: > If you mean "why not call it URI?", Yeah, that's what I mean, and worried about collapsing the notion of URI as a name, and URL as a location. I'm skeptical we can rely on parsing a URL fo extracting a DOI/ISBN/etc. Bruce From scott at randomchaos.com Fri Dec 1 14:49:28 2006 From: scott at randomchaos.com (Scott Reynen) Date: Fri Dec 1 14:49:41 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: References: Message-ID: On Dec 1, 2006, at 3:55 PM, Bruce D'Arcus wrote: >> If you mean "why not call it URI?", > > Yeah, that's what I mean, and worried about collapsing the notion of > URI as a name, and URL as a location. I'm skeptical we can rely on > parsing a URL fo extracting a DOI/ISBN/etc. Data point: ISBNs are already being reliably extracted from URLs: http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html Peace, Scott From ross.singer at library.gatech.edu Fri Dec 1 20:44:35 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Fri Dec 1 20:44:39 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: References: Message-ID: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> But how many 'citable' URLs contain ISBNs? DOIs are likely to be in a URL, but they are, sadly, impossible to discern (don't let the 10.foo fool you -- a DOI can contain any character and as many characters until whitespace - there is no way to know if the DOI ends before the URL does). Also, where do get that Jon Udell's Library Lookup 'is reliably extracting ISBNs from URLs'? LibraryLookup finds ISBNs in /HTML/ and writes a URL to a library catalog based on it. -Ross. On 12/1/06, Scott Reynen wrote: > On Dec 1, 2006, at 3:55 PM, Bruce D'Arcus wrote: > > >> If you mean "why not call it URI?", > > > > Yeah, that's what I mean, and worried about collapsing the notion of > > URI as a name, and URL as a location. I'm skeptical we can rely on > > parsing a URL fo extracting a DOI/ISBN/etc. > > Data point: ISBNs are already being reliably extracted from URLs: > > http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html > > Peace, > Scott > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > > From mikeschinkel at gmail.com Fri Dec 1 21:23:19 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Fri Dec 1 21:23:24 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: Message-ID: <010a01c715d1$fa9bc850$2102fea9@Guides.local> On Dec 1, 2006, at 3:55 PM, Bruce D'Arcus wrote: >> Scott Reynen >> If you mean "why not call it URI?", >> > >> > Yeah, that's what I mean, and worried about collapsing the notion of >> > URI as a name, and URL as a location. I'm skeptical we can rely on >> > parsing a URL fo extracting a DOI/ISBN/etc. Have you looked at the ISSN URN (RFC 3044)? http://www.ietf.org/rfc/rfc3044.txt -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From mail at ciaranmcnulty.com Fri Dec 1 23:09:41 2006 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Dec 1 23:09:45 2006 Subject: [uf-discuss] simple rss question In-Reply-To: <21e523c20612010545u57b496d3idd42ccd1f00b7f2b@mail.gmail.com> References: <00a701c714ab$c1732360$a7dd15ac@ds.corp.yahoo.com> <21e770780612010314w1dabb014n54e18bb3fb1416a4@mail.gmail.com> <21e523c20612010545u57b496d3idd42ccd1f00b7f2b@mail.gmail.com> Message-ID: On 12/1/06, David Janes wrote: > rel="alternate url" type="application/rss+xml" > title="RSS feed of Ted Drake" > href="http://example.com/feed.rss" >Ted Drake's feed @rel="alternate" is not really appropriate in this instance. Semantically it says that the link is an alternate for the current page, which I doubt is correct. -Ciaran McNulty From lists at hubmed.org Sat Dec 2 03:25:40 2006 From: lists at hubmed.org (Alf Eaton) Date: Sat Dec 2 03:26:17 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> Message-ID: <457162B4.20809@hubmed.org> Ross Singer wrote: > Also, where do get that Jon Udell's Library Lookup 'is reliably > extracting ISBNs from URLs'? LibraryLookup finds ISBNs in /HTML/ and > writes a URL to a library catalog based on it. LibraryLookup does actually get the ISBN from the URL: it looks for ([\/-]|is[bs]n=)(\d{7,9}[\dX]) This means it only works on some URLs (Amazon, isbn.nu) and not others (Barnes and Noble). The regexp could be adapated to cover more cases, but it's debatable whether it could cover every URL that anyone might use to identify any kind of work. If you could fetch the resource identified by the URL/URI and it would return metadata about itself, that would be another story... alf. From scott at randomchaos.com Sat Dec 2 06:06:06 2006 From: scott at randomchaos.com (Scott Reynen) Date: Sat Dec 2 06:06:22 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> Message-ID: On Dec 1, 2006, at 10:44 PM, Ross Singer wrote: > But how many 'citable' URLs contain ISBNs? Apparently every book on Amazon.com, BarnesAndNoble.com and ISBN.nu has a URL containing its ISBN. > DOIs are likely to be in a > URL, but they are, sadly, impossible to discern (don't let the 10.foo > fool you -- a DOI can contain any character and as many characters > until whitespace - there is no way to know if the DOI ends before the > URL does). I don't know of any tools for extracting DOIs from URLs, so skepticism of that may well be warranted. But it's clearly possible to extract ISBNs from URLs because people are doing it. > Also, where do get that Jon Udell's Library Lookup 'is reliably > extracting ISBNs from URLs'? LibraryLookup finds ISBNs in /HTML/ and > writes a URL to a library catalog based on it. Sorry, that's just false. Here's the description: "Let's say you're on a book-related site (Amazon, BN, isbn.nu) and your current page's URL includes an ISBN." Note the word "URL." And here's an example LibraryLookup bookmarklet: javascript:var%20re=/([\/-]|is[bs]n=)(\d{7,9}[\dX])/i;if(re.test (location.href)==true){var%20isbn=RegExp.$2;void(win=window.open ('http://ksclib.keene.edu'+'/search/ i='+isbn,'LibraryLookup','scrollbars=1,resizable=1,location=1,width=575, height=500'))} Note the "location.href" -- that's the URL. There's no parsing of the HTML in this JavaScript. Peace, Scott From davidjanes at blogmatrix.com Sat Dec 2 06:27:37 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Dec 2 06:27:42 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> Message-ID: <21e523c20612020627g6b0e56d9q25f5088abb17dedc@mail.gmail.com> As a peripheral observer of this discussion, may I note that parsing within a URI/URL has a precident in rel-tag [1] Regards, etc... David [1] http://microformats.org/wiki/rel-tag#Abstract -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com From lists at hubmed.org Sat Dec 2 06:39:26 2006 From: lists at hubmed.org (Alf Eaton) Date: Sat Dec 2 06:40:00 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> Message-ID: <4571901E.2010806@hubmed.org> Scott Reynen wrote: > On Dec 1, 2006, at 10:44 PM, Ross Singer wrote: >> DOIs are likely to be in a >> URL, but they are, sadly, impossible to discern (don't let the 10.foo >> fool you -- a DOI can contain any character and as many characters >> until whitespace - there is no way to know if the DOI ends before the >> URL does). > > I don't know of any tools for extracting DOIs from URLs, so skepticism > of that may well be warranted. /http:\/\/dx.doi.org\/(.+)/ alf. From ross.singer at library.gatech.edu Sat Dec 2 08:34:34 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sat Dec 2 08:34:38 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <457162B4.20809@hubmed.org> References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> <457162B4.20809@hubmed.org> Message-ID: <23b83f160612020834u40d06967kd1a53b733d9895a3@mail.gmail.com> On 12/2/06, Alf Eaton wrote: > Ross Singer wrote: > > Also, where do get that Jon Udell's Library Lookup 'is reliably > > extracting ISBNs from URLs'? LibraryLookup finds ISBNs in /HTML/ and > > writes a URL to a library catalog based on it. > > LibraryLookup does actually get the ISBN from the URL: it looks for > ([\/-]|is[bs]n=)(\d{7,9}[\dX]) > Thanks Alf. I stand corrected. -Ross. From ross.singer at library.gatech.edu Sat Dec 2 08:44:19 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sat Dec 2 08:44:23 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> Message-ID: <23b83f160612020844t33b2fa23o894e19030b5fc7dc@mail.gmail.com> On 12/2/06, Scott Reynen wrote: > On Dec 1, 2006, at 10:44 PM, Ross Singer wrote: > > > But how many 'citable' URLs contain ISBNs? > > Apparently every book on Amazon.com, BarnesAndNoble.com and ISBN.nu > has a URL containing its ISBN. > This is still my point. When you are 'citing' a work, that 'work' was not found at Amazon or BarnesAndNoble. How do you include these URLs then? These are URLs for places to /buy/ the work cited, which, in my experience, has no precedent in your average bibliography. Yes, it could potentially work for a book review or casually mentioning something in a blog, but why not just mark up the ISBN in that case? > Sorry, that's just false. Here's the description: > > "Let's say you're on a book-related site (Amazon, BN, isbn.nu) and > your current page's URL includes an ISBN." > Again, I stand corrected. I was mixing up LibraryLookup's functionality with LibX and Google's Tooltips (or whatever it's called). I stand by my point, though, why rely on ambiguity? -Ross. From ross.singer at library.gatech.edu Sat Dec 2 08:51:53 2006 From: ross.singer at library.gatech.edu (Ross Singer) Date: Sat Dec 2 08:51:59 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <4571901E.2010806@hubmed.org> References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> <4571901E.2010806@hubmed.org> Message-ID: <23b83f160612020851u6610c164rb2338b73c9648a80@mail.gmail.com> On 12/2/06, Alf Eaton wrote: > /http:\/\/dx.doi.org\/(.+)/ > Well, this requires the user to understand a lot about DOIs. A user might /find/ a dx.doi.org URL, but it's definitely not going to be the URL they wind up at (dx.doi.org is a redirection service, for those that don't know). So, again, yes, you can parse this particular case, but why? Why not unambigiously mark up the identifier? Wiley URLs also frequently contain DOIs, I think Science Direct can, as can Blackwell-Synergy, but unless the URL you have is dx.doi.org, you can't really be 100% certain when you parse it. -Ross. From bdarcus.lists at gmail.com Sat Dec 2 14:29:20 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Sat Dec 2 14:29:23 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <23b83f160612020844t33b2fa23o894e19030b5fc7dc@mail.gmail.com> References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> <23b83f160612020844t33b2fa23o894e19030b5fc7dc@mail.gmail.com> Message-ID: On 12/2/06, Ross Singer wrote: [...] > I stand by my point, though, why rely on ambiguity? Exactly! Bruce From mikeschinkel at gmail.com Sat Dec 2 18:32:32 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sat Dec 2 18:32:34 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: Message-ID: <019d01c71683$493d00d0$2102fea9@Guides.local> A couple points on this subject. I have recently been doing a *lot* of research in the area of URLs/URIs and having discussions with numerous people on REST-discuss and www-TAG lists so I feel I'm pretty well-versed on this subject now. Although it is possible to infer an ISBN or maybe even a DOI from a URL, it is considered "Bad Practice" unless the "URI Authority" (i.e. owner of the website) specifically documented the structure of the URL and gave a reasonably trustworthy guarantee that it will not change. References: 1.) "Architecture of the World Wide Web, Volume One" section 2.5 on "URI Opacity" [1]: Good practice: URI opacity Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource. 2.) "The use of Metadata in URIs" section 2.1 on "Reliability of URI metadata" [2] Constraint: Web software MUST NOT depend on the correctness of metadata inferred from a URI, except when the encoding of such metadata is documented by applicable standards and specifications. 3.) "The use of Metadata in URIs" section 2.1 on "Reliability of URI metadata" [2] The principle conclusions of this finding are: * Assignment authorities may publish specifications detailing the structure and semantics of the URIs they assign. Other users of those URIs may use such specifications to infer information about resources identified by URI assigned by that authority. * People and software using URIs assigned outside of their own authority should make as few inferences as possible about a resource based on its URI. The more dependencies a piece of software has on particular constraints and inferences, the more fragile it becomes to change and the lower its generic utility. In the case of Jon Udel's LibraryLookup which as been referenced as an example: Data point: ISBNs are already being reliably extracted from URLs: http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html Jon's work has been derided by purists as doing something it shouldn't i.e. "peeking" into URLs when they should remain opaque. Personally, I don't see what Jon did as such a bad thing. Jon's script interfaces with a human only, and if Amazon ever changes their URLs his script just won't work and the user will figure that out. In the mean time by breaking the rules he's offering pretty useful functionality that he couldn't get otherwise. And even Amazon does changes their URLs and his script breaks, which is highly unlikely given their affiliate program, Jon can just update his script and then anyone who has a broken script can search for Jon's new version (unless Amazon eliminates the ISBN from the URL, which I would highly doubt.) However, advocating the use of non-document metadata in a URL for a Microformat citation is a completely different matter. Rather than one author (Jon Udell) using it for one app (LibraryLookup) where it's users can later get updates if required, advocating it for a Microformat where authors will markup untold HTML content, much of which will never get updated for future revisions requires a very high bar for immutability. IOW, we should ensure that we have a *guarantee* that the format of the URL will *never* or we shouldn't use it. Yes we *could* still parse the old format, but we'd have to continue adding parsers some of which might eventually fail for ambiguity. At the moment, the only immutable reference for an ISBN is a URN from RFC 3187[4]. For example: URN:ISBN:0-395-36341-1 This doesn't deference in a browser, if used in IE7 for example, but one day it might. But we can be sure it is definitely immutable. As for resolving DOIs, they are new to me and I've not done enough research to determine if there is an immutable resolvable source for DOIs. This article[5] and these websites ([6] & [7]) might be helpful there. As an aside, please don't take this as me being unsupportive. On the contrary, I am a strong advocate to get website owners to put metadata in their URLs and to document that metadata. However, until we have solid sources of URLs with documented metadata, we should probably all play smartly by the rules as specified by the W3C, at least IMO. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.w3.org/TR/webarch/#uri-opacity [2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html [3] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html#N1023D [4] http://www.ietf.org/rfc/rfc3187.txt [5] http://www.dlib.org/dlib/june98/06powell.html [6] http://www.handle.net/ [7] http://www.doi.org/ From andy at pigsonthewing.org.uk Sat Dec 2 23:25:56 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Dec 2 23:27:10 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <21e523c20612020627g6b0e56d9q25f5088abb17dedc@mail.gmail.com> References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> <21e523c20612020627g6b0e56d9q25f5088abb17dedc@mail.gmail.com> Message-ID: In message <21e523c20612020627g6b0e56d9q25f5088abb17dedc@mail.gmail.com>, David Janes writes >parsing within a URI/URL has a precident in rel-tag What about: which could be a URL on the same site as the citation, or on a trusted bibliographic website. -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From mikeschinkel at gmail.com Sun Dec 3 01:00:03 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Dec 3 01:00:06 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: Message-ID: <01e201c716b9$6bde2570$2102fea9@Guides.local> Andy Mabbett wrote: >> What about: >> >> which could be a URL on the same site as the citation, >> or on a trusted bibliographic website. Agreed, but is there the latter? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From lists at hubmed.org Mon Dec 4 03:17:35 2006 From: lists at hubmed.org (Alf Eaton) Date: Mon Dec 4 03:19:37 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <23b83f160612020851u6610c164rb2338b73c9648a80@mail.gmail.com> References: <23b83f160612012044g72e56840p321055bd94372904@mail.gmail.com> <4571901E.2010806@hubmed.org> <23b83f160612020851u6610c164rb2338b73c9648a80@mail.gmail.com> Message-ID: On 02 Dec 2006, at 16:51, Ross Singer wrote: > On 12/2/06, Alf Eaton wrote: > > /http:\/\/dx.doi.org\/(.+)/ >> > Well, this requires the user to understand a lot about DOIs. A user > might /find/ a dx.doi.org URL, but it's definitely not going to be the > URL they wind up at (dx.doi.org is a redirection service, for those > that don't know). So, again, yes, you can parse this particular case, > but why? Why not unambigiously mark up the identifier? I agree. Lots of articles have DOIs in them, but most don't link to dx.doi.org (although perhaps they should...). alf. From andy at pigsonthewing.org.uk Mon Dec 4 10:57:59 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Dec 4 10:59:59 2006 Subject: [uf-discuss] More cheat-sheets for checking: hAtom & hCalendar Message-ID: I have created two more "cheat sheets": Please can someone check their accuracy? Thank you. -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From davidjanes at blogmatrix.com Mon Dec 4 11:18:46 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Dec 4 11:18:49 2006 Subject: [uf-discuss] More cheat-sheets for checking: hAtom & hCalendar In-Reply-To: References: Message-ID: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> Cool. I made a few changed to the hAtom page, hopefully keeping the spirit of the thing. On 12/4/06, Andy Mabbett wrote: > > I have created two more "cheat sheets": > > > > > > Please can someone check their accuracy? > > Thank you. > > > -- > Andy Mabbett > Say "NO!" to compulsory ID Cards: > > Free Our Data: > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com From michael.mccracken at gmail.com Mon Dec 4 13:48:04 2006 From: michael.mccracken at gmail.com (Michael McCracken) Date: Mon Dec 4 13:48:07 2006 Subject: [uf-discuss] [citation] url field In-Reply-To: <019d01c71683$493d00d0$2102fea9@Guides.local> References: <019d01c71683$493d00d0$2102fea9@Guides.local> Message-ID: On 12/2/06, Mike Schinkel wrote: > A couple points on this subject. I have recently been doing a *lot* of > research in the area of URLs/URIs and having discussions with numerous > people on REST-discuss and www-TAG lists so I feel I'm pretty well-versed on > this subject now. > > Although it is possible to infer an ISBN or maybe even a DOI from a URL, it > is considered "Bad Practice" unless the "URI Authority" (i.e. owner of the > website) specifically documented the structure of the URL and gave a > reasonably trustworthy guarantee that it will not change. > > References: > > 1.) "Architecture of the World Wide Web, Volume One" section 2.5 on "URI > Opacity" [1]: > > Good practice: URI opacity > Agents making use of URIs SHOULD NOT attempt to infer properties of > the referenced resource. > > 2.) "The use of Metadata in URIs" section 2.1 on "Reliability of URI > metadata" [2] > > Constraint: Web software MUST NOT depend on the correctness of > metadata > inferred from a URI, except when the encoding of such metadata is > documented > by applicable standards and specifications. > > 3.) "The use of Metadata in URIs" section 2.1 on "Reliability of URI > metadata" [2] > > The principle conclusions of this finding are: > > * Assignment authorities may publish specifications detailing the > structure and > semantics of the URIs they assign. Other users of those URIs may use > such > specifications to infer information about resources identified by > URI assigned by > that authority. > > * People and software using URIs assigned outside of their own > authority should > make as few inferences as possible about a resource based on its > URI. The more > dependencies a piece of software has on particular constraints and > inferences, > the more fragile it becomes to change and the lower its generic > utility. > > In the case of Jon Udel's LibraryLookup which as been referenced as an > example: > > Data point: ISBNs are already being reliably extracted from URLs: > > http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html > > Jon's work has been derided by purists as doing something it shouldn't i.e. > "peeking" into URLs when they should remain opaque. Personally, I don't see > what Jon did as such a bad thing. Jon's script interfaces with a human only, > and if Amazon ever changes their URLs his script just won't work and the > user will figure that out. In the mean time by breaking the rules he's > offering pretty useful functionality that he couldn't get otherwise. And > even Amazon does changes their URLs and his script breaks, which is highly > unlikely given their affiliate program, Jon can just update his script and > then anyone who has a broken script can search for Jon's new version (unless > Amazon eliminates the ISBN from the URL, which I would highly doubt.) > > However, advocating the use of non-document metadata in a URL for a > Microformat citation is a completely different matter. Rather than one > author (Jon Udell) using it for one app (LibraryLookup) where it's users can > later get updates if required, advocating it for a Microformat where authors > will markup untold HTML content, much of which will never get updated for > future revisions requires a very high bar for immutability. IOW, we should > ensure that we have a *guarantee* that the format of the URL will *never* or > we shouldn't use it. Yes we *could* still parse the old format, but we'd > have to continue adding parsers some of which might eventually fail for > ambiguity. > > At the moment, the only immutable reference for an ISBN is a URN from RFC > 3187[4]. For example: > > URN:ISBN:0-395-36341-1 > > This doesn't deference in a browser, if used in IE7 for example, but one day > it might. But we can be sure it is definitely immutable. > > As for resolving DOIs, they are new to me and I've not done enough research > to determine if there is an immutable resolvable source for DOIs. This > article[5] and these websites ([6] & [7]) might be helpful there. > > As an aside, please don't take this as me being unsupportive. On the > contrary, I am a strong advocate to get website owners to put metadata in > their URLs and to document that metadata. However, until we have solid > sources of URLs with documented metadata, we should probably all play > smartly by the rules as specified by the W3C, at least IMO. > > -Mike Schinkel > http://www.mikeschinkel.com/blogs/ > http://www.welldesignedurls.org/ > > [1] http://www.w3.org/TR/webarch/#uri-opacity > [2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html > [3] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html#N1023D > [4] http://www.ietf.org/rfc/rfc3187.txt > [5] http://www.dlib.org/dlib/june98/06powell.html > [6] http://www.handle.net/ > [7] http://www.doi.org/ > Mike, thanks for all the detail. I definitely learned some things. In the context of my original proposal to add a "URL" field to the microformat, I now feel like I need to separate that proposal from one of the statements I made in it: "I also suggest that in the case of identifiers like a DOI or ISBN which can be represented as a parameter in a link to doi.org or some other resolver, that the format encourage using a URL field for those identifiers and not include separate fields for each such identifier. In other words, I think that class="url uid" is sufficient to encode DOI/ISBN/etc., and we shouldn't add a separate DOI class, a separate ISBN class, and so on. " To be clear - I still think that *if* it is possible to mark up a DOI or ISBN as a link without obscuring the DOI, then that's a positive thing. It sounds like it's just more complicated than I thought to do that. So maybe the format doesn't need to mention those in connection with the URL field. I do think that a URL field (class="url") should be included, to represent a link to a copy of the cited work, and if we want to mark up one or more identifiers, we can use a separate class (I suggest "uid") to do so. If we're lucky and there's a good way to merge them, then use class="url uid". I'd like to get feedback on whether or not the list likes the idea of a URL field as outlined above - separate from the issue of URNs and metadata recovery. The use case I'm focused on is here: http://microformats.org/wiki/citation-brainstorming#Acquiring_reference_information_from_the_web Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From costello at mitre.org Mon Dec 4 16:06:43 2006 From: costello at mitre.org (Costello, Roger L.) Date: Mon Dec 4 16:02:32 2006 Subject: [uf-discuss] ANN: hCard Tutorial Message-ID: Hi Folks, I have created a tutorial on how to markup (X)HTML documents using the hCard properties: http://www.xfront.com/microformats/hCard.html Comments welcome. /Roger From drernie at opendarwin.org Mon Dec 4 16:08:05 2006 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Mon Dec 4 16:08:26 2006 Subject: [uf-discuss] cheat-sheets, rekeyed In-Reply-To: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> References: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> Message-ID: <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> Hi all, At Andy's invitation, I redid all the cheatsheets to use a common, regex-style key: http://microformats.org/wiki/Template:cheatsheet-key Specifically: http://microformats.org/wiki/adr-cheatsheet http://microformats.org/wiki/geo-cheatsheet http://microformats.org/wiki/hatom-cheatsheet http://microformats.org/wiki/hcalendar-cheatsheet http://microformats.org/wiki/hcard-cheatsheet I also tried to clean them up for consistency, e.g., removing "class=" which some of them had. When in doubt, I erred on the side of legibility. However, there were a few irregularities I didn't understand, and thus didn't clean up: * Why are some class names italicized? Are those all for "0 or more" classes? * Why does hCard have so many parentheticals? Should that be in notes, or do we need a better syntax for them? * What exactly does "default rule" mean in the hatom cheat? * In hAtom, what is the cleanest way to indicate that the use of "rel" instead of class? Suggestions? --- Ernie P. On Dec 4, 2006, at 11:18 AM, David Janes wrote: > Cool. I made a few changed to the hAtom page, hopefully keeping the > spirit of the thing. > > On 12/4/06, Andy Mabbett wrote: >> >> I have created two more "cheat sheets": >> >> >> >> >> >> Please can someone check their accuracy? >> >> Thank you. >> >> >> -- >> Andy Mabbett >> Say "NO!" to compulsory ID Cards: > www.no2id.net/> >> >> Free Our Data: >> _______________________________________________ >> microformats-discuss mailing list >> microformats-discuss@microformats.org >> http://microformats.org/mailman/listinfo/microformats-discuss >> > > > -- > David Janes > Founder, BlogMatrix > http://www.blogmatrix.com > http://www.onamine.com > http://blogmatrix.blogmatrix.com > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From mail at ciaranmcnulty.com Mon Dec 4 23:41:51 2006 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Mon Dec 4 23:41:55 2006 Subject: [uf-discuss] cheat-sheets, rekeyed In-Reply-To: <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> References: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> Message-ID: On 12/5/06, Dr. Ernie Prabhakar wrote: > * What exactly does "default rule" mean in the hatom cheat? Yeah that's not really clear. It means that if the field isn't literally stated, it's often derivable anyhow. For instance, if there is no @class="author" in an entry, then the entry author will default to the nearest in-parent address@class="author" -Ciaran McNulty From davidjanes at blogmatrix.com Tue Dec 5 00:43:55 2006 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Dec 5 00:44:02 2006 Subject: [uf-discuss] cheat-sheets, rekeyed In-Reply-To: References: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> Message-ID: <21e523c20612050043i3cfe629ewd0708333fef7e88b@mail.gmail.com> Well, the cheatsheets are fairly sparse so I didn't feel it was correct to write an elobrate explantion. In most cases, the user will treat the fields as "required"; however, like Ciaran says, there's also ways of deriving the value. Regards, etc... On 12/5/06, Ciaran McNulty wrote: > On 12/5/06, Dr. Ernie Prabhakar wrote: > > * What exactly does "default rule" mean in the hatom cheat? > > Yeah that's not really clear. It means that if the field isn't > literally stated, it's often derivable anyhow. For instance, if there > is no @class="author" in an entry, then the entry author will default > to the nearest in-parent address@class="author" > > -Ciaran McNulty > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com From andy at pigsonthewing.org.uk Tue Dec 5 00:54:30 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 5 00:56:01 2006 Subject: [uf-discuss] cheat-sheets, rekeyed In-Reply-To: <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> References: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> Message-ID: In message <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org>, Dr. Ernie Prabhakar writes >At Andy's invitation, I redid all the cheatsheets to use a common, >regex-style key Your changes to the cheat-sheet key have restored the problem to which my changes were a solution; emboldened text alone is not recognised by assistive technology and text-only browsers. Please reintroduce a secondary indicator, as I had done. Thank you. -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From kmarks at technorati.com Tue Dec 5 02:39:15 2006 From: kmarks at technorati.com (Kevin Marks) Date: Tue Dec 5 02:39:22 2006 Subject: [uf-discuss] Re: [video_vertigo] Re: [videoblogging] Media RSS what? In-Reply-To: References: <18D8E943D728594C864C7AA427FDC62201EE9E1F@CL4EXBE03.ad2.softcom.biz> Message-ID: <22ac8ca169e6c6f15290b91507bb7dcc@technorati.com> On Dec 4, 2006, at 9:16 PM, Mike Meiser wrote: > On 12/4/06, Mike Hudack wrote: >> Mrss-thumbnail would work for me. Do we want to tie this so >> explicitly to >> MediaRSS though? Maybe just media-thumbnail? > > Makes sense to me. > > I was thinking about the whole schema tying to media RSS doesn't seem strong > > > class, not id (id's need to be unique per page) > flash version > There is an existing HTML way to express the type of a linked file, using MIME types flash version see http://microformats.org/wiki/alternates- brainstorming#Strawman_6_.28lists_.2B_explicit_alternator_.2B_using_exis ting_HTML_idiom.29 > > The point is we need to make it as flat and simple as possible. > > > flash version > flash > version > > Simple enough? It's not clear that the files are alternatives - see the discussion at http://microformats.org/wiki/alternates-brainstorming
  1. Flash version
  2. QuickTime version
> Media is the namespace. Shouldn't be any conflicts there. Namespaces are an antipattern. Lets find a term that is expressive and converge it. http://microformats.org/wiki/namespaces-considered-harmful > > Should be fairly extenisble. > > And as Andreas pointed out you can specify alternative class info. > > I.E. cool styles link > > Where cool-links might be a CSS style, and media-enclosure and > media-filetype might be attributes of our media spec. > > All we're talking about right now is "media-thumbnail" but just > keeping an eye out looking forward. I think 'thumbnail' alone is OK (can you think of it being confused with markup for false nails or something?) Looking at http://microformats.org/wiki/existing-classes there isn't an existing classname that fits (you could argue for class="photo summary" perhaps, but I think that is less accurate). > > Simple enough? Or still to convoluted? > > I know services like blip can and will pick up on this stuff real > quick once we publish a spec, but it's got to be simple enough for > everday vloggers too. > > The end goal is better marked up code in video and audio blog posts > everywhere dealing with media. Would also be great for images, pdf > and other media too in the future. See http://microformats.org/wiki/media-info for previous discussions. It seems like a revival of interest here could help us move on to converging schemas and proposing names. > I think the problem this points to is that the magic happens in the > blog post, not in the RSS. By embedding the metadata in the RSS with > mediaRSS we've cut most vloggers and services like blip who interact > by cross posting to blogs off from properly identifying the elements > of their blog post. > > Feedburner's been picking videos out and enclosing them using the > rel="enclosure" standard. And technoratti and others have been > picking out tags using the rel="tag" standard, but it's time to > develop a more robust schema to put the more power back into the blog > posting input box. > > And finally, I like that this schema can be flat, like tags > themselves. Allowing multiple atributes to be attributed in the > "class" space. I think people may well get it. > > Let's just define ourselves a simple schema or language then, shall we? > > This is maybe something could be something that could really catch on > among bloggers and podcasters in the coming years to give them more > control. > > It also leaves plenty of room for additional complimentary schema as > well wheras standards like rel="tag" and rel="nofollow" cannot be used > in conjunction with one another. Yes they can, multiple rel's are legal HTML; rel="tag nofollow" is a little nonsensical (the link is a tag for the page, but don't index it?) but see above for more coherent examples. > > Peace, > > -Mike > mefeedia.com > mmeiser.com/blog > >> >> ----- Original Message ----- >> From: videoblogging@yahoogroups.com >> To: video_vertigo@yahoogroups.com >> Cc: Kevin Marks ; Eric Lunt >> ; >> mefeedia-core@yahoogroups.com ; >> videoblogging@yahoogroups.com >> Sent: Mon Dec 04 20:06:33 2006 >> Subject: Re: [video_vertigo] Re: [videoblogging] Media RSS what? >> >> Yeah, >> >> I like as andreas points out using the class attibute to declare a >> thumbnail. Because class is an atribute unlike name that is standard >> across >> all manner of elements (images, links ans such) and it is very >> extensible >> allowing the specification of multiple atributes and nearly infinite >> namespaces. >> >> I.E. > class="mrss-thumbnail"> >> >> >> This is very similar to the technorati tags microformat for >> specifying tags >> on blog posts. >> >> I.E. >> >> >> The only real difference is we're using class and to avoid conflicts >> with >> CSS we're using a namespace, "mrss" in addition to "thumbnails" >> >> >> That's a pretty good start, but simpler suggestions are very welcome. >> >> It's important that not only automated tools and services like >> blip.tv, >> moveabletype, blogger.com or wordpress be able to add this markup to >> a blog >> post, but also that it become as simple a language as possible so >> everyday >> ordinary people can easily learn and use the "mrss" markup language >> the way >> they've learned to adopt technoratti tags. >> >> BTW, should this be called the "mrss" microformat, or does >> microformats.orghave their own name space? >> >> We are replicating some of the functionalities of Yahoo's mrss (aka. >> media >> RSS) so perhaps it's best to make some attempt to correlate what >> we're doing >> with that. >> >> -Mike >> mefeedia.com >> mmeiser.com/blog >> >> On 12/4/06, Lisa Rein wrote: >> > >> > Hi gang, >> > >> > We'll implement anything that's XHTML compliant. >> > >> > With that in mind, I vote for the "title" attribute of the "img" >> > element, since "alt" is generally used for titles. >> > >> > There's a "name" attribute too, which is already in use for >> scripting. >> > But perhaps it's *already* being used to say things like "thumbnail" >> > for scripting anyway, in which case it would work fine. >> > >> > http://www.zvon.org/xxl/xhtmlReference/Standard/struct/ >> > objects.html#edef-IMG >> > >> > http://www.zvon.org/xxl/xhtmlReference/Standard/struct/ >> > global.html#adef-title >> > >> > >> > >> > thanks! >> > >> > lisa >> > >> > p.s. how do i get back on the list? :-) >> > >> > On Dec 3, 2006, at 6:25 PM, Mike Meiser wrote: >> > >> > > First off, I think whatever email client you're using is marking >> > > everything as *****SPAM***** in the subject line. Very >> detrimental to >> > > conversation. :) >> > > >> > > Response below. >> > > >> > > On 12/3/06, Mike Hudack wrote: >> > > > We currently use rel="enclosure" in cross-posts, but we don't >> and >> > > can't >> > > > use rel="thumbnail" because (afaik) images in XHTML don't have >> a rel >> > > > attribute. I'd be very hesitant to use something like >> > > class="thumbnail" >> > > > because of potentially conflicting CSS on remote sites (we >> prefix >> > > class >> > > > names in cross-posts with a namespace like "blip_" to avoid >> > > conflicts). >> > > > I'm not sure what the proper approach to attaching semantically >> > > > important information to images is, but that's all the more >> reason >> > > why >> > > > this conversation is more important for the >> microformats-discuss >> > > list >> > > > than the videoblogging list. >> > > >> > > Where's andreas of solitude.dk when you need him? :) >> > > >> > > Overall, yeah, I agree. >> > > >> > > But I don't think I'm on this microstandards discussion list for >> some >> > > reason. Must have been some oversite on my part. You got a url or >> > > were you talking video vertigo? >> > > >> > > > The only way that a standard for additional metadata will be >> > > adopted is >> > > > if FeedBurner is on board. As I said in my previous e-mail, >> I've >> > > > discussed this with them and they're gung-ho for the idea but >> don't >> > > have >> > > > room in their roadmap right now. At blip we're ready to go >> with it, >> > > > though. We'll add whatever microformats we have to so that the >> > > > blip->cross-post->FeedBurner->MediaRSS workflow works best. >> > > >> > > Well, I think if just mefeedia and blip adopt it'll be mutually >> > > beneficial to us both immediately making it worthwhile. Peter is >> out >> > > of town at the moment, but this is at the very top of our >> priority >> > > list. Those damn thumbnails are sort of important to people and >> we >> > > can't generate them all. >> > > >> > > Remember, if it's in the blog post, even if Feedburner doesn't >> pick it >> > > up immediately and translate it to mediaRSS it'll get through to >> the >> > > RSS anyway and anyone including mefeedia, democracy, dabble or >> anyone >> > > who chooses to identify and use it can. >> > > >> > > Right now we're talking about going back in to identify all the >> videos >> > > coming from blip and their thumbnails and then cross referencing >> that >> > > with videos we're picking up from feedburner feeds and using the >> > > thumbnails there. It's be much easier for everyone if those >> thumbnails >> > > (and other meta info from blip) were contained right in those >> > > feeburner RSS feeds, either with mediaRSS as they get the >> chance, or >> > > with microstandards until then. >> > > >> > > This is not just about thumbnails of course, that's just at the >> > > forefront. We're talking about ways to pass around geographic >> data on >> > > individual posts, and having ways to continually extend and add >> new >> > > semantic data. Data that blip and others are collecting, data >> that >> > > gets lost in the cross posting. >> > > >> > > The trick is to allow people to specify as much metadata, or >> semantic >> > > data in the post as possible as simple as possible. This is >> something >> > > everyone can benefit from. >> > > >> > > The problem is as it turns out with mediaRSS is most people don't >> > > write their own mediaRSS feeds. They need simple microformats to >> > > specify semantically key meta info right in the blog post. >> > > >> > > rel=tag is a great example of this. >> > > >> > > We need a way to identify thumbnails next. >> > > >> > > Then to start looking at other metainfo that's missing. >> > > >> > > > We're more than happy to do support this in code before >> FeedBurner >> > > > does... so if FB agrees to support a microstandards standard at >> > > some point >> > > > in the future we'll add support to it in our code immediately. >> > > >> > > Rock on. That's what I'm talking about. >> > > >> > > Just got to figure out if we can't specify rel=thumbnail on image >> > > source what else we can do. >> > > >> > > We could use the "alt" space. It's usually used for text >> describing >> > > the image, but alt=thumbnail might work. >> > > >> > > Keep in mind while blip is going to be handling all this stuff >> > > automatically we need to keep it very simple to keep it >> accessible to >> > > everyday people whom very well may be hand coding it. >> > > >> > > So... if we can keep it rel=thumbnail that would be best. >> > > >> > > How else are people specifying microstandards? Within div tags? >> > > >> > >
>> > > >> > > What about ? >> > > >> > > I must admit I'm so out of touch. :P >> > > >> > > What strikes me as a more technical question is how to >> semantically >> > > specify alternate video formats like Flash in the source. As far >> as I >> > > know there's no way to extend rel=enclosure. >> > > >> > > The only think I can think of is to specify urls in duplicate. >> For >> > > example specifying one url for the generic rel="enclosure", >> specifying >> > > it again with rel="quicktime-enclosure", and another time with >> > > rel="flash-enclosure". >> > > >> > > That seems very complex though. There's got to be a simpler way. >> > > >> > > > If I had my druthers, Kevin Marks from Technorati, Lisa Rein >> from >> > > Dabble >> > > > and Eric Lunt from FeedBurner would be part of this >> conversation >> > > and we >> > > > could settle on a solution very quickly. So I've gone ahead >> and CC'd >> > > > all of them (and also CC'd Video Vertigo, which most of them >> are >> > > on). >> > > >> > > Sure, this should be pretty cut and dry. It's very simple and >> yet very >> > > useful stuff. >> > > >> > > -Mike >> > > mefeedia.com >> > > mmeiser.com/blog >> > > >> > > > Yours, >> > > > >> > > > Mike >> > > > blip.tv >> > > > >> > > > groups-yahoo-com@mmeiser.com wrote: >> > > > > >> > > > > Good question jay, >> > > > > >> > > > > Does anyone know if Moveabletype, blogger, or Wordpress >> support >> > > > > mediaRSS? Has anyone created a plugin perhaps for MT or >> Wordpress? >> > > > > >> > > > > I've realized one of the primary issues with the mediaRSS >> spec is >> > > that >> > > > > when you're righting a post there's no quick markup to >> specify >> > > > > metadata IN the post. Specifically for example I was going to >> > > propose >> > > > > a series of Microstandards like "rel=thumbnail" so people >> could >> > > > > semanticly specify metadata in their post. >> > > > > >> > > > > For example when you specify the image to represent your >> video in >> > > the >> > > > > page you'd specify it like this. >> > > > > >> > > > > >> > > > > >> > > > > As some may have noticed one of the biggest issues we have >> with >> > > > > mefeedia is generating tens of thousands of email a day. One >> of >> > > the >> > > > > things I've realized is that MOST people are specifying a >> > > > > representative thumbnail in their post, they're just not >> > > specified in >> > > > > the mediaRSS. >> > > > > >> > > > > I think we're going to adopt this rel=thumbnail standard >> pretty >> > > quick >> > > > > on mefeedia. >> > > > > >> > > > > But if we can also just get a few providers on board like >> > > feedburner, >> > > > > blip.tv, dabble and a few others we could creat much >> prettier and >> > > more >> > > > > usefull feeds really quick. >> > > > > >> > > > > A couple examples. >> > > > > >> > > > > 1) if feedburner jumps on board identifying thumbnails based >> on >> > > the >> > > > > rel=thumbnail standard they can also specify those >> thumbnails in >> > > > > mediaRSS and aggregatory tools like democracy, itunes, >> mefeedia, >> > > > > fireant or whomever recognizes mediaRSS will immediately >> start >> > > > > displaying the thumbnails you specify in your blog instead of >> > > randomly >> > > > > pulling their own. >> > > > > >> > > > > 2) This is particularly an interesting issue with people >> hosting >> > > > > their videos on blip. Blip does allow you to specify a >> thumbnail >> > > for >> > > > > each video, and they DO put it in your blip feed. However, >> 99% of >> > > all >> > > > > people using blip don't use blip's feed, they cross post from >> > > blip to >> > > > > their video blog where such meta information as the >> thumbnail is >> > > not >> > > > > semantically specified. By semantically specified I mean the >> > > image is >> > > > > just genrically specified in the page and the aggregator >> can't >> > > assume >> > > > > to know what it is. >> > > > > >> > > > > The point is as a result all the blip feeds look great on >> > > mefeedia, >> > > > > but all people's primary feeds have no thumbnails specified. >> > > > > >> > > > > If blip specified the thumbnails using the "rel=thumbnail" >> > > standard >> > > > > when crossposting to people's vlogs that information would >> make it >> > > > > into the RSS feed where it could be picked up by any >> aggregator. >> > > > > >> > > > > The bottom line is this... more semantic data = a prettier >> and >> > > more >> > > > > useful vlogosphere for everyone. >> > > > > >> > > > > So... who's with me? Josh K? Mike H., Justin, and the >> Blippers? >> > > Lisa >> > > > > Rien, Mary Hodder and the dabblers? Do we have someone >> > > representing >> > > > > feedburner here? >> > > > > >> > > > > On top of this I'd like to take a look at what other >> information >> > > is >> > > > > getting specified in blog posts, such as that that blip is >> > > collecting, >> > > > > that's not making it into the mediaRSS and why not. >> > > > > >> > > > > Again, 99% of vloggers specify a thumbnail in their blog >> post, but >> > > > > these thumbnails aren't making it into the mediaRSS because >> > > there's no >> > > > > way to semantically specify it in the blog post. >> Rel=thumbnail is >> > > the >> > > > > simplest way i can think of to accomplish this. >> > > > > >> > > > > Jay, you said you recently took a look at mediaRSS. What >> sort of >> > > > > metadata are you talking about, what metadata do you want to >> > > specify? >> > > > > Can you give a few examples of what your clients might find >> > > > > particularly interesting? >> > > > > >> > > > > I'm afraid that other than developing this and other >> > > microstandards >> > > > > that can be specified right in the blog post, rich meta >> > > information >> > > > > will continue to get missed untill the major blogging >> platforms >> > > like >> > > > > Blogger, Wordpress, and Moveable type support mediaRSS by >> default. >> > > > > >> > > > > Oh, and you should also note that Yahoo video search will >> pick up >> > > > > these thumnails too if we can get feedburner to support this >> > > proposed >> > > > > RelThumbnail standard. >> > > > > >> > > > > Are there any other major search engines or services I'm >> > > forgetting >> > > > > about that aggregate mediaRSS for search and such? >> > > > > >> > > > > -Mike >> > > > > mefeedia.com >> > > > > mmeiser.com/blog >> > > > > >> > > > > On 12/3/06, Jay dedman > > > > > > wrote: >> > > > > > > Here's the MRSS spec: >> > > > > > > > > >> > > > > > > It was developed by Yahoo! with a lot of collaboration >> from a >> > > > > > > community of contributors, including many folks on this >> list. >> > > > > > > FeedBurner supports MRSS in a pretty limited way -- >> really >> > > just as an >> > > > > > > addition to the enclosure element. Blip.tv includes a >> lot of >> > > MRSS >> > > > > > > metadata in their feeds, including support for media >> > > thumbnails and >> > > > > > > alternate versions of each video (FLV, Quicktime, etc.). >> > > > > > > Is there something in particular you want to do with >> MRSS? >> > > > > > >> > > > > > >> > > > > > yep....i saw the spec, but am having a hard time fitting my >> > > brain >> > > > > around it. >> > > > > > I am working with a group of Community TV stations that are >> > > starting >> > > > > > to upload and trade TV programs for playback around the >> country. >> > > > > > >> > > > > > They want to attach a lot of metadata into their >> posts....so >> > > they are >> > > > > > asking if Media RSS could help them. Questions I have >> is....how >> > > do >> > > > > > they create feeds that attach all this info into their >> feed? >> > > > > > Do they need to make their feeds by hand? >> > > > > > >> > > > > > right now, they are just uploading to their own >> servers...and >> > > using >> > > > > > Drupla to create their feeds. >> > > > > > >> > > > > > >> > > > > > Jay >> > > >> > http://www.dabble.com >> > http://www.onlisareinsradar.com >> > >> > >> > >> > >> >> >> [Non-text portions of this message have been removed] >> >> >> >> >> Yahoo! Groups Links >> >> >> >> >> >> [Non-text portions of this message have been removed] >> >> >> >> >> Yahoo! Groups Links >> >> <*> To visit your group on the web, go to: >> http://groups.yahoo.com/group/videoblogging/ >> >> <*> Your email settings: >> Individual Email | Traditional >> >> <*> To change settings online go to: >> http://groups.yahoo.com/group/videoblogging/join >> (Yahoo! ID required) >> >> <*> To change settings via email: >> mailto:videoblogging-digest@yahoogroups.com >> mailto:videoblogging-fullfeatured@yahoogroups.com >> >> <*> To unsubscribe from this group, send an email to: >> videoblogging-unsubscribe@yahoogroups.com >> >> <*> Your use of Yahoo! Groups is subject to: >> http://docs.yahoo.com/info/terms/ >> >> From mikeschinkel at gmail.com Tue Dec 5 03:30:15 2006 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Tue Dec 5 03:30:28 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats Message-ID: <005101c71860$c22b1980$0702a8c0@Guides.local> For those on this list who are not following [whatwg], here is an interesting thread about inability to use Microformats: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8462.html I wonder if his issues can be addressed? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ From lists at ben-ward.co.uk Tue Dec 5 05:05:51 2006 From: lists at ben-ward.co.uk (Ben Ward) Date: Tue Dec 5 05:06:01 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <005101c71860$c22b1980$0702a8c0@Guides.local> References: <005101c71860$c22b1980$0702a8c0@Guides.local> Message-ID: <4C82E349-7925-4A36-AD27-01BDC991C7CA@ben-ward.co.uk> On 5 Dec 2006, at 11:30, Mike Schinkel wrote: > For those on this list who are not following [whatwg], here is an > interesting thread about inability to use Microformats: > > http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- > December/00 > 8462.html > > I wonder if his issues can be addressed? I'm not sure if they can, or not here at least. What I get from his message is not a problem with any specific Microformat, but that IBM finds the class/rel/rev/profile extension mechanism of HTML too limiting for their needs. In particular, he gives an example of ?customers submitting their own microformats?, which is not the same as what we refer to as ?microformats? at all. In fact, such broad user-defined formats sounds distinctly out-of-scope of our efforts. If handling a large number of discrete user submitted bespoke formats is IBM's goal on their project, it's comprehensible that the extension mechanisms in HTML probably are inappropriate. Therefore, I think they're taking the right path in asking the WHATWG for a more suitable mechanism for them and their goal, but it doesn't really expose any problems with well specified microformats here. Ben From brian.suda at gmail.com Tue Dec 5 05:07:10 2006 From: brian.suda at gmail.com (Brian Suda) Date: Tue Dec 5 05:07:15 2006 Subject: [uf-discuss] New Microformats Cheatsheet PDF Message-ID: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> With all the movement around the cheatsheets on the wiki, i have taken the opportunity to correct a few errors on my PDF. I have also worked in a few suggestions from folks, such as a new labeling scheme for the Matrix of what properties are available for which formats and to try and better visually set-off the columns and added some more spacing and white-space. The cheatsheet is always a work in progress, just like microformats, so if anyone spots and error please let me know and/or update the wiki pages as well. Hopefully, the PDF can help drive the wiki, and vice versa. I have r10 (release 10) in the corner of the PDF, so please be sure to check for the newest release number to make sure your cheatsheet is up-to-date. All comments, suggestions, etc. are welcome. http://suda.co.uk/projects/microformats/cheatsheet/ Thanks, -brian -- brian suda http://suda.co.uk From bdarcus.lists at gmail.com Tue Dec 5 05:07:20 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Tue Dec 5 05:07:24 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <005101c71860$c22b1980$0702a8c0@Guides.local> References: <005101c71860$c22b1980$0702a8c0@Guides.local> Message-ID: On 12/5/06, Mike Schinkel wrote: > For those on this list who are not following [whatwg], here is an > interesting thread about inability to use Microformats: > > http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 > 8462.html > > I wonder if his issues can be addressed? I think the only way it can be addressed is with some effort to harmonize microformats and RDFa, which is not going to happen for what seem to me largely political reasons. The fact that we can't have a title property in hCite is already evidence of the practical problems that will result without such an effort. FWIW. Elias is an engineer (who writes code; "rep" sounds to me more marketing, but maybe tha's just me). Bruce From ssriram at gmail.com Tue Dec 5 08:48:37 2006 From: ssriram at gmail.com (S. Sriram) Date: Tue Dec 5 08:48:44 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats References: <005101c71860$c22b1980$0702a8c0@Guides.local> Message-ID: <002001c7188d$37331b20$0367c33f@sitsam> From: "Mike Schinkel" > > http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 > 8462.html > > I wonder if his issues can be addressed? > How about a distributed parser-discovery service More specifically a YADIS discovered JSON returning uf-specific parser: 1. Place an entry on the uf-authored page detailing the ufs-used 2. Place a yadiservices discovery pointer to where parser(s) maybe found, (on the same uf-authored page) 3. add parser service data to the (existing) yadis file pointed to within the uf-authored page. http://openid.net/signon/1.0 http://www.livejournal.com/openid/server.bml http://microformats.org/hreview/1.0 http://www.blah.com/path/to/uf2json-parser http://mysite.com/hwidget/1.0 http://www.mysite.com/path/to/uf2json-parser 4. ..domain../path/to/uf2json-parser is a REST-call that is passed a 'uf-snippet' and returns a JSON object. Browsers that are uf-aware would call the parser with the uf-snippet, and than hand of the JSON to the storing module. CONS: The parser needs to be 'hosted', incurring bandwidth costs. PROS: Roll your own microformat and parser - or - *leave your html as is and just build a parser for it and point tothe parser from within the page.* S. Sriram From tantek at cs.stanford.edu Tue Dec 5 09:15:58 2006 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue Dec 5 09:18:42 2006 Subject: [uf-discuss] ANN: hCard Tutorial In-Reply-To: Message-ID: On 12/4/06 4:06 PM, "Costello, Roger L." wrote: > Hi Folks, > > I have created a tutorial on how to markup (X)HTML documents using the > hCard properties: > > http://www.xfront.com/microformats/hCard.html > > Comments welcome. Hi Roger, This is a nice step by step tutorial presentation. One critique is that the first couple of examples with Dr. John Q. Public are invalid hCard because you cannot *only* use "fn" with a formatted name that is more than two words - you *must* also use "n" and its subproperties. See: http://microformats.org/wiki/hcard#Implied_.22n.22_Optimization Consider changing your first and second examples to only state "John Public" and therefore able to use the implied N optimization rule. This way you introduce people to the common easy case first, and then show the more detailed example with "n" and subproperties later. Thanks, Tantek From ramsey.pat at gmail.com Tue Dec 5 11:21:20 2006 From: ramsey.pat at gmail.com (Pat Ramsey) Date: Tue Dec 5 11:45:46 2006 Subject: [uf-discuss] New Microformats Cheatsheet PDF In-Reply-To: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> References: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> Message-ID: <83a2ad2f0612051121w4823652fr4b9cfdeaa79a0eb0@mail.gmail.com> As always, Brian, thanks! This is a great resource and I've used it more than once to remember that little piece of an hCard or hCalendar implementation. Cheers! Pat On 12/5/06, Brian Suda wrote: > With all the movement around the cheatsheets on the wiki, i have taken > the opportunity to correct a few errors on my PDF. I have also worked > in a few suggestions from folks, such as a new labeling scheme for the > Matrix of what properties are available for which formats and to try > and better visually set-off the columns and added some more spacing > and white-space. The cheatsheet is always a work in progress, just > like microformats, so if anyone spots and error please let me know > and/or update the wiki pages as well. > > Hopefully, the PDF can help drive the wiki, and vice versa. I have r10 > (release 10) in the corner of the PDF, so please be sure to check for > the newest release number to make sure your cheatsheet is up-to-date. > > All comments, suggestions, etc. are welcome. > > http://suda.co.uk/projects/microformats/cheatsheet/ > > Thanks, > -brian -- Pat Ramsey ramsey.pat@gmail.com http://www.southwestern.edu/~ramseyp From digitalspaghetti at googlemail.com Tue Dec 5 11:26:11 2006 From: digitalspaghetti at googlemail.com (digital spaghetti) Date: Tue Dec 5 12:20:32 2006 Subject: [uf-discuss] Fwd: Re: [Microid] MicroID hashing algorithm(s) and normalization In-Reply-To: References: <047201c7138c$b22e0ca0$6402a8c0@YanivT60> <4575A049.4040807@jabber.org> Message-ID: ---------- Forwarded message ---------- From: digital spaghetti Date: Tue, 5 Dec 2006 19:24:40 +0000 Subject: Re: [Microid] MicroID hashing algorithm(s) and normalization To: Peter Saint-Andre Hi I'm new to the list, and I appoligise I can't provide full examples as I'm on my blackberry just now. I agree though this needs to be settled on. I've created a module for drupal that generates microID's and embeds them as a meta tag in the header (and using JS also adds a class to the node's main div tag). I've confirmed that the url it's using is correct and for myself the correct email address, but the hash I get is different to the one on claimID so it never validates my links. I'm using sha1 to encode the hash, like this: $hash = sha1(sha1(email) . Sha1(url)); It's the same algorithim as the wordpress plugin that's available. If you like I could post an example on here tommorow. You can also see the module at work on my site below. Just click on any blog post then view the rendered source (with firebug or web developer, standard view source does not work correctly). Tane http://digitalspaghetti.me.uk On 12/5/06, Peter Saint-Andre wrote: > Yaniv Golan wrote: > >> Personally I don't see a big difference here between HMAC and SHA1 > >> here because we're not attempting to provide cryptographic > >> assurance. > >> I think we need to settle on one algorithm and leave it at that. > >> Fewer options, fewer ways to go wrong. > >> > > Fewer options are good, but it's also good to indicate which option > > you're using, just in case you'd like to change your mind later. > > > > So, my microid for my Yedda profile page: > > > > http://yedda.com/people/9512186217351/ > > > > which right now is: > > > > > content="e5de55ef248b5f8b06d38253cac0ae725d6455fb" /> > > > > Would change to > > > > > content="sh1:e5de55ef248b5f8b06d38253cac0ae725d6455fb" /> > > > > Small change, but it allows future revisions of the spec to support > > legacy support. To rephrase the old saying, "better metadata than > > sorry" :) > > > > In fact, given the introduction of OpenID into the discussion, I think > > that it would make sense to load the content with additional metadata, > > such as the element used as the verification anchor: > > > > In the case of email: > > > > > content="sh1:email:e5de55ef248b5f8b06d38253cac0ae725d6455fb" /> > > > > In the case the OpenID identity is used instead of email: > > > > > content="sh1:openid:e5de55ef248b5f8b06d38253cac0ae725d6455fb"/> > > I have no deep objections to that approach since it's more flexible. > However I think we'd want to at least maintain a registry of values for > the hashing/MAC algorithms and the element (or elements?) used. > > So for hash/MAC we'd have things like sha1, sha256, hmac. > > Do we need to list both elements that are used to make the microid? > E.g., the two elements could be an HTTP URL and a mailto: URI, two > OpenIDs, an OpenID and a Jabber ID, or whatever. > > Peter > > > > From scott at randomchaos.com Tue Dec 5 12:27:46 2006 From: scott at randomchaos.com (Scott Reynen) Date: Tue Dec 5 12:28:06 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <002001c7188d$37331b20$0367c33f@sitsam> References: <005101c71860$c22b1980$0702a8c0@Guides.local> <002001c7188d$37331b20$0367c33f@sitsam> Message-ID: <901C2E10-DBAB-43A5-B03D-6602032CFA85@randomchaos.com> On Dec 5, 2006, at 10:48 AM, S. Sriram wrote: > From: "Mike Schinkel" > >> http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- >> December/00 >> 8462.html >> >> I wonder if his issues can be addressed? Ian said: > "class", "rel", and "profile" are the extension mechanism for HTML And Elias said: > We have tried using microformats as an extension mechanism for HTML That response confuses the issues here. Ian pointed out the only allowed methods of extending HTML and said that microformats use these methods. That Elias is unsatisfied with these methods is a problem with HTML, not with microformats. We're not in charge of HTML here. > How about a distributed parser-discovery service > > More specifically a YADIS discovered JSON returning uf-specific > parser: > > 1. Place an entry on the uf-authored page detailing the ufs-used > As Ian mentioned in the message Elias responded to, HTML already has this functionality with profile headers: http://microformats.org/wiki/profile-uris > 2. Place a yadiservices discovery pointer to where parser(s) > maybe found, (on the same uf-authored page) > > > > 3. add parser service data to the (existing) yadis file pointed to > within > the uf-authored page. > > > > http://openid.net/signon/1.0 > http://www.livejournal.com/openid/server.bml > > > http://microformats.org/hreview/1.0 > http://www.blah.com/path/to/uf2json-parser > > > http://mysite.com/hwidget/1.0 > http://www.mysite.com/path/to/uf2json-parser > > > > 4. ..domain../path/to/uf2json-parser is a REST-call that is passed > a 'uf-snippet' and returns a JSON object. > Browsers that are uf-aware would call the parser with the uf-snippet, > and than hand of the JSON to the storing module. > > CONS: The parser needs to be 'hosted', incurring bandwidth costs. > PROS: Roll your own microformat and parser - or - *leave your html > as is and just build a parser for it and point tothe parser from > within the page.* What you've described above is a process for converting all microformats to JSON, but that doesn't really solve the problem Elias described. It just changes the format. Each individual parser still needs to figure out what the JSON means, where before they had to figure out what the HTML means. In HTML or JSON, new formats need new parsers, which must be written by someone. Elias is coming from an RDF background, and microformats simply aren't RDF, and they never will be. And that's a good thing. If what you want is RDF, just use RDF. Peace, Scott From drernie at opendarwin.org Tue Dec 5 11:35:55 2006 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Tue Dec 5 12:51:16 2006 Subject: [uf-discuss] New Microformats Cheatsheet PDF In-Reply-To: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> References: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> Message-ID: Hi Brian, On Dec 5, 2006, at 5:07 AM, Brian Suda wrote: > All comments, suggestions, etc. are welcome. > > http://suda.co.uk/projects/microformats/cheatsheet/ Beautiful work; I love the table on the right! One question: why not use "?" for single occurence optional, and "+" for one or more, like Perl (and I) do. I actually can't figure out what character you use for "One or More" -- or is that a rendering error? -- Ernie P. From brian.suda at gmail.com Tue Dec 5 13:40:33 2006 From: brian.suda at gmail.com (Brian Suda) Date: Tue Dec 5 13:40:37 2006 Subject: [uf-discuss] New Microformats Cheatsheet PDF In-Reply-To: References: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> Message-ID: <21e770780612051340q252c5ac7q5cb8456d91b35683@mail.gmail.com> On 12/5/06, Dr. Ernie Prabhakar wrote: > Beautiful work; I love the table on the right! --- cheers, i hope you find it helpful. > One question: why not use "?" for single occurence optional, and "+" > for one or more, like Perl (and I) do. I actually can't figure out > what character you use for "One or More" -- or is that a rendering > error? --- i think there was an reason why i didn't use ?, +, * (but i can't remember at the moment). The "One or More" is the UTF "currency sign", for me it is sort of emtpy circle with a cross through it - if they are too similar, i can look into switching them. Part of the issue with ?,+,* is how to you represent just "required" in REGEX simply having a char there makes it exist, but on the chart it is slightly more difficult. I'm certainly open to making things clearer so let me know what you think. -brian -- brian suda http://suda.co.uk From drernie at opendarwin.org Tue Dec 5 13:42:58 2006 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Tue Dec 5 13:43:02 2006 Subject: [uf-discuss] cheat-sheets, rekeyed In-Reply-To: References: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> Message-ID: <239BB363-FEC9-4F1B-B9C7-63BAC20D35C8@opendarwin.org> Hi all, Okay, I've added a Perl-style '{1}' for elements that must appear only once: http://microformats.org/wiki/adr-cheatsheet http://microformats.org/wiki/geo-cheatsheet http://microformats.org/wiki/hatom-cheatsheet http://microformats.org/wiki/hcalendar-cheatsheet http://microformats.org/wiki/hcard-cheatsheet I also rephrased "default rules" as: > # if absent, defaults as described at hatom#Entry_Author I'm not happy with that, but it seems a slightly clearer clue. Any suggestions? Also, I decided to make the Key its own template: http://microformats.org/wiki/Template:cheatsheet-key This makes it easier to keep everything consistent, but results in unused items being present on some pages. The tradeoff seems worthwhile to me -- what do the rest of you think? -- Ernie P. On Dec 5, 2006, at 12:54 AM, Andy Mabbett wrote: > In message <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org>, Dr. > Ernie Prabhakar writes > >> At Andy's invitation, I redid all the cheatsheets to use a common, >> regex-style key > > > Your changes to the cheat-sheet key have restored the problem to which > my changes were a solution; emboldened text alone is not recognised by > assistive technology and text-only browsers. Please reintroduce a > secondary indicator, as I had done. Thank you. > > -- > Andy Mabbett > Say "NO!" to compulsory ID Cards: www.no2id.net/> > > Free Our Data: > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From drernie at opendarwin.org Tue Dec 5 13:47:25 2006 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Tue Dec 5 13:47:28 2006 Subject: [uf-discuss] New Microformats Cheatsheet PDF In-Reply-To: <21e770780612051340q252c5ac7q5cb8456d91b35683@mail.gmail.com> References: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> <21e770780612051340q252c5ac7q5cb8456d91b35683@mail.gmail.com> Message-ID: Hi Brian, On Dec 5, 2006, at 1:40 PM, Brian Suda wrote: > --- i think there was an reason why i didn't use ?, +, * (but i can't > remember at the moment). The "One or More" is the UTF "currency sign", > for me it is sort of emtpy circle with a cross through it - if they > are too similar, i can look into switching them. Part of the issue > with ?,+,* is how to you represent just "required" in REGEX simply > having a char there makes it exist, but on the chart it is slightly > more difficult. > > I'm certainly open to making things clearer so let me know what you > think. I think using "x" for required is reasonable, since it does have the connotation of "present." If you replace the funky currency sign with "+", and make "?" the 'One Optional' character, I think it should work, right? -- Ernie P. From andy at pigsonthewing.org.uk Tue Dec 5 14:12:13 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 5 14:13:31 2006 Subject: [uf-discuss] New Microformats Cheatsheet PDF In-Reply-To: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> References: <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com> Message-ID: In message <21e770780612050507k1dd55df5mfb1f4cee0a5493d@mail.gmail.com>, Brian Suda writes >a new labeling scheme for the >Matrix of what properties are available for which formats Thanks for including that. -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From andy at pigsonthewing.org.uk Tue Dec 5 14:14:17 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 5 14:15:31 2006 Subject: [uf-discuss] ANN: hCard Tutorial In-Reply-To: References: Message-ID: In message , "Costello, Roger L." writes >I have created a tutorial on how to markup (X)HTML documents using the >hCard properties: > >http://www.xfront.com/microformats/hCard.html > >Comments welcome. Nice work, but in maximised Firefox, at 1280x1024, I find the red examples too small and closely bunched to read. Would you like a screenshot? -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From andy at pigsonthewing.org.uk Tue Dec 5 14:21:45 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 5 14:23:00 2006 Subject: [uf-discuss] cheat-sheets, rekeyed In-Reply-To: <239BB363-FEC9-4F1B-B9C7-63BAC20D35C8@opendarwin.org> References: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> <239BB363-FEC9-4F1B-B9C7-63BAC20D35C8@opendarwin.org> Message-ID: In message <239BB363-FEC9-4F1B-B9C7-63BAC20D35C8@opendarwin.org>, Dr. Ernie Prabhakar writes >Also, I decided to make the Key its own template: > >http://microformats.org/wiki/Template:cheatsheet-key Sensible, but I don't like the table borders. >This makes it easier to keep everything consistent, but results in >unused items being present on some pages. >The tradeoff seems worthwhile to me -- what do the rest of you think? Mention the unused key entries in the "Notes"? -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From andy at pigsonthewing.org.uk Tue Dec 5 14:24:40 2006 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Dec 5 14:26:28 2006 Subject: [uf-discuss] hCard/ adr clarification Message-ID: <94+l3XgoGfdFFwzb@pigsonthewing.org.uk> In "adr", the class "adr" is required, of any oft eh sub-classes are used. In hCard, "adr" is optional, as are its subclasses. Should "adr" be required, if any of its sub-categories are present, in hCard? -- Andy Mabbett Say "NO!" to compulsory ID Cards: Free Our Data: From drernie at opendarwin.org Tue Dec 5 14:36:16 2006 From: drernie at opendarwin.org (Dr. Ernie Prabhakar) Date: Tue Dec 5 14:36:19 2006 Subject: [uf-discuss] cheat-sheets, rekeyed In-Reply-To: References: <21e523c20612041118j14da6dfci156b1bc40558e0d2@mail.gmail.com> <4EAA78CD-85C0-4187-BC8D-2F852F306A78@opendarwin.org> <239BB363-FEC9-4F1B-B9C7-63BAC20D35C8@opendarwin.org> Message-ID: Hi Andy, On Dec 5, 2006, at 2:21 PM, Andy Mabbett wrote: >> http://microformats.org/wiki/Template:cheatsheet-key > > Sensible, but I don't like the table borders. > >> This makes it easier to keep everything consistent, but results in >> unused items being present on some pages. >> The tradeoff seems worthwhile to me -- what do the rest of you think? > > Mention the unused key entries in the "Notes"? I see your point, but am unsure what would look best. Feel free to experiment... -enp From ssriram at gmail.com Tue Dec 5 14:55:59 2006 From: ssriram at gmail.com (S. Sriram) Date: Tue Dec 5 14:56:06 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats References: <005101c71860$c22b1980$0702a8c0@Guides.local><002001c7188d$37331b20$0367c33f@sitsam> <901C2E10-DBAB-43A5-B03D-6602032CFA85@randomchaos.com> Message-ID: <015b01c718c0$891ff970$0367c33f@sitsam> From: "Scott Reynen" > >> 2. Place a yadiservices discovery pointer to where parser(s) > > What you've described above is a process for converting all microformats > to JSON, but that doesn't really solve the problem Elias described. It > just changes the format. Each individual parser still needs to figure > out what the JSON means, where before they had to figure out what the > HTML means. > In point of fact it exactly solves elias's problem in somewhat the same way that inline RDFa does. Because of the key-value pairs retuned by JSON. Take Elias's hCard example [1] with the need for additional attributes i.e. blog-url, activity-url etc. and the inability to 'add new properties' to an existing microformat. In the distributed parser model, the returned JSON would allow all uf-aware-browser-apps to look only for hCard data and allow 'uf-aware-special-browser-apps' to seek out the additional attributes i.e. blog-url etc. satisfying elias's need. In other words by looking at parsing/rendering as two seperate and distinct steps, with ditributed parsing one can accomodate 'generic' formats and 'custom' formats and one can accomodate 'generic' rendering and 'custom' rendering. One could also in theory extend the YADIS service to offer a uf-rendering service, so a browser could look at uf-authored page, send the uf-snippet to the 'discoverd' uf2json parser, and than send the json to the discovered 'uf-json-renderer/storer'.etc. [1] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/008500.html S. Sriram From ryan at ryancannon.com Tue Dec 5 16:00:43 2006 From: ryan at ryancannon.com (Ryan Cannon) Date: Tue Dec 5 23:01:21 2006 Subject: [uf-discuss] New Microformats Cheatsheet PDF In-Reply-To: <200612052141.kB5Lf2Im001427@microformats.org> References: <200612052141.kB5Lf2Im001427@microformats.org> Message-ID: On Dec 5, 2006, at 4:41 PM, "Brian Suda" wrote: >> One question: why not use "?" for single occurence optional, and "+" >> for one or more, like Perl (and I) do. I actually can't figure out >> what character you use for "One or More" -- or is that a rendering >> error? > > --- i think there was an reason why i didn't use ?, +, * (but i can't > remember at the moment). I'm guessing that in the type of Regular Expressions Dr. Prabhakar mentions, the existence of a term implies that it is required, and implies an order, whereas in this format you have to differentiate between "Not Applicable" and "required once". That said, I till prefer ?, + and *, as I have to continually move my eye between the two charts in order to remember which is which. I would remember ?, + and *. Perhaps instead of the table on the right, which duplicates the other information on the page, you could have a similar column to the right of each class name, with either and symbols for occurrence: " " or "!" Required once "?" or " " Optional "+" at least one "*" one or more Regardless, moving the class name requirements closer to the structure list will decrease the amount of time a reader takes to look up the the information. -- Ryan http://RyanCannon.com From dps1 at ualberta.ca Tue Dec 5 23:14:41 2006 From: dps1 at ualberta.ca (Shorthouse, David) Date: Tue Dec 5 23:14:43 2006 Subject: [uf-discuss] species microformats & OpenSearch Message-ID: <002501c71906$33104170$9930c450$@ca> Folks, I am a relative newcomer to microformats and come with a biological sciences background so am most interested in the "species" microformat group of discussions (http://microformats.org/wiki/species). Rod Page and I with contributions from Charles Roper have been having an interesting discussion about OpenSearch on his iSpecies (http://darwin.zoology.gla.ac.uk/~rpage/ispecies/) blog (http://ispecies.blogspot.com/) as it relates to The Nearctic Spider Database's use of some software called Zoom Search. Of particular concern to me is: 1) using correct & appropriate nomenclature and, 2) providing a means to aggregate the sorts of species pages produced as exemplified by The Nearctic Spider Database (http://canadianarachnology.dyndns.org/data/canada_spiders/). To that end, I now make use of uBio LSIDs & marked-up species pages with:

Theridion agrifoliae Levi, 1957

.in the hopes that uBio's and other LSIDs will eventually contribute to the semantic web in a taxonomically intelligent way. This in my opinion is the way to go with microformats. I simply cannot comprehend how something like:

Theridion agrifoliae Levi, 1957

.could ever contribute to the semantic web in a meaningful way & will stand the test of taxonomic revisions (i.e how do the current species microformats deal with synonyms, homonyms, and other recognized nomenclature?). Finally, what steps have been taken to aggregate or make use of species microformats and can OpenSearch play some sort of role here in taking the next step? David P. Shorthouse ------------------------------------------------------ Department of Biological Sciences CW-403, Biological Sciences Centre University of Alberta Edmonton, AB T6G 2E9 Phone: 1-780-492-3080 mailto:dps1@ualberta.ca http://canadianarachnology.webhop.net http://arachnidforum.webhop.net ------------------------------------------------------ From brian.suda at gmail.com Wed Dec 6 04:51:10 2006 From: brian.suda at gmail.com (Brian Suda) Date: Wed Dec 6 04:51:14 2006 Subject: [uf-discuss] hCard/ adr clarification In-Reply-To: <94+l3XgoGfdFFwzb@pigsonthewing.org.uk> References: <94+l3XgoGfdFFwzb@pigsonthewing.org.uk> Message-ID: <21e770780612060451g16d6c920l87007433d91cce73@mail.gmail.com> On 12/5/06, Andy Mabbett wrote: > > In "adr", the class "adr" is required, of any oft eh sub-classes are > used. > > In hCard, "adr" is optional, as are its subclasses. > > Should "adr" be required, if any of its sub-categories are present, in > hCard? --- this is a slightly tricky answer... from a validation point of view, something like this is completely valid HTML and microformats:
foo-bar name
foo-bar
now, a parse would NOT parser the country-name value as part of an address, but it is still valid. If you intend for the country-name to be part of the vcard then it MUST be a child of a class="adr". But if a class="country-name" does exist outside of an ADR, then that does not make ADR required - it could simply mean the publisher has chosen a semantic class name - not intending it to be part of the vcard. So, i guess the short answer is: If a ADR child is present it is NOT manditory to make ADR present, but it will NOT be parsed into a vCard. it will ONLY be considered part of the hCard data IF it is a child of ADR, but neither the ADR or child-property are required. I hope this makes sense and help? -brian -- brian suda http://suda.co.uk From bdarcus.lists at gmail.com Wed Dec 6 05:45:20 2006 From: bdarcus.lists at gmail.com (Bruce D'Arcus) Date: Wed Dec 6 05:45:24 2006 Subject: [uf-discuss] Comments from IBM/Lotus rep about Microformats In-Reply-To: <901C2E10-DBAB-43A5-B03D-6602032CFA85@randomchaos.com> References: <005101c71860$c22b1980$0702a8c0@Guides.local> <002001c7188d$37331b20$0367c33f@sitsam> <901C2E10-DBAB-43A5-B03D-6602032CFA85@randomchaos.com> Message-ID: On 12/5/06, Scott Reynen wrote: ... > In HTML or JSON, new formats need new parsers, which must be written > by someone. Exactly. The point is if you have a generic model you have a generic parser. > Elias is coming from an RDF background, and microformats > simply aren't RDF, and they never will be. And that's a good thing. > If what you want is RDF, just use RDF. The issue isn't really microformats vs. RDF (except as RDF provides a model), but microformats vs. RDFa. Both microformats and RDFa are addressing the exact same use cases and requirements (augmenting visible content with structured data). RDFa includes namespacing, the lack of which is already a problem in microformats (witness hCite and the serious awkwardness that title will be indicate using fn), and which will grow over time as more and more people want to mark up their content. Moreover, the need to write dedicate code for each new microformat will also present serious scalability problems. Finally, that there's no model at the heart of microformats with clear extension rules means that the vaunted social process here is a mess. It's all centralized, and people get frustrated when their pet property isn't included because they know what that means: the tools written for the blessed microformats won't see them. So while it might be comforting to dismiss RDFa and "it's not our problem", I don't think it's good strategy. Bruce From scott at randomchaos.com Wed Dec 6 06:14:47 2006 From: scott at randomchaos.com (Scott Reynen) Date: Wed Dec 6 06:14:55 2006 Subject: [uf-discuss] species microformats & OpenSearch In-Reply-To: <002501c71906$33104170$9930c450$@ca> References: <002501c71906$33104170$9930c450$@ca> Message-ID: <328B8A6C-C308-4455-AA4E-94E472660EEF@randomchaos.com> On Dec 6, 2006, at 1:14 AM, Shorthouse, David wrote: > To that end, I now make use of uBio LSIDs & marked-up species pages > with: > >

Theridion > agrifoliae Levi, 1957

> > .in the hopes that uBio's and other LSIDs will eventually > contribute to the > semantic web in a taxonomically intelligent way. This in my opinion > is the > way to go with microformats. Hi David. Welcome to the list. The above seems to me very unlikely to be adopted by HTML publishers. That LSID URN refers to an RDF resource, and RDF is not intended to be consumed by humans. Microformats are for humans first. Also, the RDF resource lists the canonical name as "Theridion agrifoliae," so that alone should be canonically descriptive, right? What exactly is the benefit of repeating this information in the class when it's already in the content? http://names.ubio.org/authority/metadata.php? lsid=urn:lsid:ubio.org:namebank:2029133 > I simply cannot comprehend how something like: > >

Theridion agrifoliae Levi, 1957

> > .could ever contribute to the semantic web in a meaningful way & > will stand > the test of taxonomic revisions (i.e how do the current species > microformats > deal with synonyms, homonyms, and other recognized nomenclature?). Synonyms and other nomenclature are covered by , e.g.: Along came a spider and sat down beside her. This keeps the more precise version accessible to human readers (unlike class names), without requiring them to read it.