From Jay.Myers at bestbuy.com Tue Nov 4 11:07:41 2008 From: Jay.Myers at bestbuy.com (Myers, Jay) Date: Tue Nov 4 11:11:53 2008 Subject: [uf-new] hProduct draft schema References: <79618EC6-E409-4775-B02E-15558D7D3AF9@tobyinkster.co.uk> <21e523c20810311207r2fd35facl3e5276c11bd7bb4b@mail.gmail.com> Message-ID: <0A55472BC29958468426825844F9F22E03D9E050@dsp63mail.na.bestbuy.com> Would it make sense to use Paul's suggestion of title: title. optional. fn | text thanks j -----Original Message----- From: microformats-new-bounces@microformats.org on behalf of David Janes Sent: Fri 10/31/2008 2:07 PM To: For discussion of new microformats. Subject: Re: [uf-new] hProduct draft schema On Fri, Oct 31, 2008 at 2:27 PM, Paul Lee (???) wrote: > > On Wed, Oct 29, 2008 at 10:58 AM, Toby A Inkster wrote: > > 2. "name" should reuse either "fn" from hCard or "summary" from hCalendar > > Hmm, looking at the hCard and hCalendar pages, it seems that name here > is used a bit differently, since it is intended to be the product > name/title. Is this really the same meaning at fn and summary? Or > should we perhaps use "title" instead to disambiguate? Oh Jebus on a pogo stick, can we not go through this again. Regards, etc... -- David Janes Mercenary Programmer _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From mail at tobyinkster.co.uk Tue Nov 4 16:51:31 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Nov 4 16:51:49 2008 Subject: [uf-new] hProduct draft schema Message-ID: <35832518-FEF9-432B-A695-97FB31A0CD4D@tobyinkster.co.uk> Jay Myers wrote: > Would it make sense to use Paul's suggestion of title: > title. optional. fn | text "title" is forever more in microformats defined as meaning "job title". See the discussion on this list regarding hAudio. It's unfortunate, but it seems that that's the way it has to be. If you want to capture the semantic of the name of something, use "fn" or "summary". -- Toby A Inkster From martin at weborganics.co.uk Sun Nov 9 12:23:16 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 9 12:23:22 2008 Subject: [uf-new] Media Microformat Message-ID: <491746B4.30003@weborganics.co.uk> Hello all I would like to inform you that the Media Examples Anyalisis has at last been completed please see http://microformats.org/wiki/media-info-examples. The full results and discovered schema for a Media Microformat is available here: http://microformats.org/wiki/media-info-brainstorming#Schema. Thanks -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Sun Nov 9 16:51:08 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 9 16:51:19 2008 Subject: [uf-new] Re: Media Microformat In-Reply-To: <491746B4.30003@weborganics.co.uk> References: <491746B4.30003@weborganics.co.uk> Message-ID: <4917857C.1020703@weborganics.co.uk> I said: > I would like to inform you that the Media Examples Anyalisis has at > last been completed please see > http://microformats.org/wiki/media-info-examples. > The full results and discovered schema for a Media Microformat is > available here: > http://microformats.org/wiki/media-info-brainstorming#Schema. Why a Media Microformat?, Isn't this a lot like hAudio? hMedia is not primarily about audio, it is More about Images, Video and Audio and the common properties that they share and a few domain specific properties such as video, photo and enclosure. Yes hMedia is a lot like hAudio, In fact it reuses to fairly important properties from haudio "contributor" and "item" and it draws on the last year and half's discussion about an audio info microformat but there the similarities end because its more about the common elements that Images, Video and Audio all share. As far as hmedia goes I proves really what a good job the audio info discussion has done identifying a vocabulary for all media. Thanks -- Martin McEvoy http://weborganics.co.uk/ From mail at tobyinkster.co.uk Mon Nov 10 02:37:34 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Nov 10 02:53:50 2008 Subject: [uf-new] Media Microformat Message-ID: > I would like to inform you that the Media Examples Anyalisis has at > last > been completed please see http://microformats.org/wiki/media-info- > examples. > The full results and discovered schema for a Media Microformat is > available here: > http://microformats.org/wiki/media-info-brainstorming#Schema. It strikes me that it's missing guidance on how to mark up thumbnails for images. The "obvious" way would seem to be:
whatever
But, as class="photo" is used to provide a graphical preview for video and audio files, it seems that a better way would be to use class="photo" for the thumbnail and rel="enclosure" (but not class="photo") for the full sized image:
whatever
Though that is not immediately obvious, so I think it would benefit from explicit mention in any spec. -- Toby A Inkster From martin at weborganics.co.uk Mon Nov 10 09:00:26 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 10 09:00:33 2008 Subject: [uf-new] Media Microformat In-Reply-To: References: Message-ID: <491868AA.2010502@weborganics.co.uk> Hello Toby... Toby A Inkster wrote: >> I would like to inform you that the Media Examples Anyalisis has at last >> been completed please see >> http://microformats.org/wiki/media-info-examples. >> The full results and discovered schema for a Media Microformat is >> available here: >> http://microformats.org/wiki/media-info-brainstorming#Schema. > > It strikes me that it's missing guidance on how to mark up thumbnails > for images. OK... > > The "obvious" way would seem to be: > >
> > whatever > >
> ... > But, as class="photo" is used to provide a graphical preview for video > and audio files, it seems that a better way would be to use > class="photo" for the thumbnail and rel="enclosure" (but not > class="photo") for the full sized image: > >
> > whatever > >
the above example is kind of how it goes
name of image
here the @alt of the image will form the textual name ("fn") of the media. > > Though that is not immediately obvious, so I think it would benefit > from explicit mention in any spec. > Agreed.. Thanks -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Mon Nov 10 12:02:32 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 10 12:02:45 2008 Subject: [uf-new] Re: Media Microformat In-Reply-To: <491746B4.30003@weborganics.co.uk> References: <491746B4.30003@weborganics.co.uk> Message-ID: <49189358.3020402@weborganics.co.uk> Martin McEvoy wrote: > Hello all > > I would like to inform you that the Media Examples Anyalisis has at > last been completed please see > http://microformats.org/wiki/media-info-examples. > The full results and discovered schema for a Media Microformat is > available here: > http://microformats.org/wiki/media-info-brainstorming#Schema. > > Thanks > I would also like to inform you that a Media Info Proposal is now available for viewing and comments http://microformats.org/wiki/media-info-proposal One point I would like to bring up now is that the proposal supports a new element called comment http://microformats.org/wiki/media-info-proposal#comment I didn't want to create anything new to mark up the contents of a comment, I just reused hcard eg: hcard properties used are: * fn The name of the person who authored a comment * url A URI of the person who authored a comment. * note To specify a comment that is associated with the person who authored a comment. Contents can be text or Valid html mark up * rev Datetime of the revision of the entire coment. This element SHOULD use the datetime-design-pattern. * uid A unique URI identifier of a comment, typically a "permalink" to a comment Toby has raised an issue with this because it is bending the definition of a few properties from hcard, but I am not too sure, hcard properties are primarily used for people and organizations but also for Objects, A solution to this is use hAtom hentry for this, which I tentatively agree with, But for one or two Problems, It would lose rev and uid, these are important because every time someone gives feedback on say a blog post, they are creating a new revision of a document(rev), also if a permalink to the comment is available this forms part of a unique identifier(uid) of the comment. Another thought I have on this Is Are people leaving their contact information and a note when they give feedback on something? Has anyone any More thoughts on this? Thanks -- Martin McEvoy http://weborganics.co.uk/ From tantek at cs.stanford.edu Mon Nov 10 12:32:54 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Mon Nov 10 12:32:58 2008 Subject: [uf-new] Media Microformat In-Reply-To: <491746B4.30003@weborganics.co.uk> References: <491746B4.30003@weborganics.co.uk> Message-ID: <60cb038a0811101232q50fcc512y90a93c068ec34008@mail.gmail.com> On Sun, Nov 9, 2008 at 12:23 PM, Martin McEvoy wrote: > Hello all > > I would like to inform you that the Media Examples Anyalisis has at last > been completed please see http://microformats.org/wiki/media-info-examples. > The full results and discovered schema for a Media Microformat is available > here: http://microformats.org/wiki/media-info-brainstorming#Schema. Martin, Excellent analysis and summary on the media info examples. It's good to see this making progress. The only suggested feedback/improvement I have at this time is to consider the principle of modularity: http://microformats.org/wiki/principles and perhaps separate out a few bits, thus simplifying a potential media info microformat. That is, see how much of a media info posting can be marked up as an hAtom entry, and then produce a media info schema based on what remains, rather than what hAtom has already marked up, e.g. * published * comment - should probably go into an iteration of hAtom or a separate microformat instead, see existing work: http://microformats.org/wiki/comment (links to a lot of pre-existing work) Also, for "alternate", see http://microformats.org/wiki/alternates (ditto). Thanks! Tantek From mail at tobyinkster.co.uk Mon Nov 10 13:14:45 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Nov 10 13:15:04 2008 Subject: [uf-new] Re: Media Microformat Message-ID: <8F122D33-C82B-440D-B8B9-993C55582691@tobyinkster.co.uk> Martin McEvoy wrote: > [Using hAtom for comments] would lose rev and uid "rev" is defined as "datetime of the revision of the entire comment". hAtom has "published" for this. "uid" is defined as "a unique URI identifier of a comment, typically a 'permalink' to a comment". hAtom has rel="bookmark" for this. See: http://microformats.org/wiki/hatom#Schema -- Toby A Inkster From martin at weborganics.co.uk Mon Nov 10 17:05:38 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 10 17:05:47 2008 Subject: [uf-new] Media Microformat In-Reply-To: <60cb038a0811101232q50fcc512y90a93c068ec34008@mail.gmail.com> References: <491746B4.30003@weborganics.co.uk> <60cb038a0811101232q50fcc512y90a93c068ec34008@mail.gmail.com> Message-ID: <4918DA62.50607@weborganics.co.uk> Hello Tantek Tantek ?elik wrote: > On Sun, Nov 9, 2008 at 12:23 PM, Martin McEvoy wrote: > >> Hello all >> >> I would like to inform you that the Media Examples Anyalisis has at last >> been completed please see http://microformats.org/wiki/media-info-examples. >> The full results and discovered schema for a Media Microformat is available >> here: http://microformats.org/wiki/media-info-brainstorming#Schema. >> > > Martin, > > Excellent analysis and summary on the media info examples. It's good > to see this making progress. > Thank you.. > The only suggested feedback/improvement I have at this time is to > consider the principle of modularity: > > http://microformats.org/wiki/principles > > and perhaps separate out a few bits, thus simplifying a potential > media info microformat. > > That is, see how much of a media info posting can be marked up as an > hAtom entry, and then produce a media info schema based on what > remains, rather than what hAtom has already marked up, e.g. > * published > * comment - should probably go into an iteration of hAtom or a > I think re-use hAtom too I have done for a long time, but when I mentioned placing media-info in the domain of hAtom, It received quite a lot of push back from the community [1] I got "talked" out of the whole idea, I thought maybe I shouldn't go there again this time, but now the evidence is In so to speak, It was the right thought to begin with. [1] http://microformats.org/discuss/mail/microformats-new/2007-April/000120.html > separate microformat instead, see existing work: > http://microformats.org/wiki/comment (links to a lot of pre-existing work) > I looked at comment but It doesn't seem to have got very far, and has not got much in the way of examples But seems to mostly concern itself with , I have already analysed 25 really good examples of Comments, so maybe I should add what I know to that and go from there? my only concern is wasn't a comment microformat(hcomment) depreciated? > Also, for "alternate", see http://microformats.org/wiki/alternates (ditto). > I wasn't aware of that discussion, thanks. Thanks for your valuable feedback Best Wishes -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Mon Nov 10 17:09:26 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 10 17:09:34 2008 Subject: [uf-new] Re: Media Microformat In-Reply-To: <8F122D33-C82B-440D-B8B9-993C55582691@tobyinkster.co.uk> References: <8F122D33-C82B-440D-B8B9-993C55582691@tobyinkster.co.uk> Message-ID: <4918DB46.6040005@weborganics.co.uk> Hello Toby.... Toby A Inkster wrote: > Martin McEvoy wrote: > >> [Using hAtom for comments] would lose rev and uid > > "rev" is defined as "datetime of the revision of the entire comment". > hAtom has "published" for this. Or updated may be more accurate. > > "uid" is defined as "a unique URI identifier of a comment, typically a > 'permalink' to a comment". hAtom has rel="bookmark" for this. Agreed ;) > > See: http://microformats.org/wiki/hatom#Schema > Thanks -- Martin McEvoy http://weborganics.co.uk/ From csarven at gmail.com Mon Nov 10 17:50:44 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Mon Nov 10 17:50:48 2008 Subject: [uf-new] Media Microformat In-Reply-To: <4918DA62.50607@weborganics.co.uk> References: <491746B4.30003@weborganics.co.uk> <60cb038a0811101232q50fcc512y90a93c068ec34008@mail.gmail.com> <4918DA62.50607@weborganics.co.uk> Message-ID: On Mon, Nov 10, 2008 at 3:32 PM, Tantek ?elik wrote: > * comment - should probably go into an iteration of hAtom or a > separate microformat instead, see existing work: > http://microformats.org/wiki/comment (links to a lot of pre-existing work) On Mon, Nov 10, 2008 at 8:05 PM, Martin McEvoy wrote: > I looked at comment but It doesn't seem to have got very far, and has not > got much in the way of examples But seems to mostly concern itself with , I > have already analysed 25 really good examples of Comments, so maybe I should > add what I know to that and go from there? my only concern is wasn't a > comment microformat(hcomment) depreciated? There is possibly no need for a new comment format, see: http://microformats.org/wiki/hatom-brainstorming#User_comment_entries I still have to experiment with it: http://krijnhoetmer.nl/irc-logs/microformats/20081029#l-36 -Sarven From tantek at cs.stanford.edu Mon Nov 10 18:02:36 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Mon Nov 10 18:02:41 2008 Subject: [uf-new] Media Microformat In-Reply-To: <4918DA62.50607@weborganics.co.uk> References: <491746B4.30003@weborganics.co.uk> <60cb038a0811101232q50fcc512y90a93c068ec34008@mail.gmail.com> <4918DA62.50607@weborganics.co.uk> Message-ID: <60cb038a0811101802i2c445a3r37f0a6702c3c0c57@mail.gmail.com> On Mon, Nov 10, 2008 at 5:05 PM, Martin McEvoy wrote: > > Tantek ?elik wrote: >> >> On Sun, Nov 9, 2008 at 12:23 PM, Martin McEvoy >> wrote: >> ... > I think re-use hAtom too I have done for a long time, but when I mentioned > placing media-info in the domain of hAtom, It received quite a lot of push > back from the community [1] I got "talked" out of the whole idea, I thought > maybe I shouldn't go there again this time, but now the evidence is In so to > speak, It was the right thought to begin with. > > [1] > http://microformats.org/discuss/mail/microformats-new/2007-April/000120.html I agree with that push back in that *extending* hAtom is not the answer, but rather using hAtom + an hMedia in a modular way, as building blocks, and then trying that composite use of both to capture/publish the semantics you have documented in your schema analysis. >> see existing work: >> http://microformats.org/wiki/comment (links to a lot of pre-existing work) >> > > I looked at comment but It doesn't seem to have got very far, and has not > got much in the way of examples But seems to mostly concern itself with , I > have already analysed 25 really good examples of Comments, so maybe I should > add what I know to that and go from there? Yes. The work on "comment" needs quite a bit of gardening and improvement, and I think you've clearly done enough additional analysis to take a shot at re-organizing / cleaning up the existing work on comment-examples, comment-formats, and comment-brainstorming accordingly. In my opinion, there is not much special/unique to comments on media info entries as opposed to comments on published entries in general, thus the problems appear fairly equivalent to solve (with a much broader benefit if the broader comments on entries problem is solved). > my only concern is wasn't a > comment microformat(hcomment) depreciated? The "hcomment" effort (like many new microformat efforts) was premature (named/written up before good/sufficient examples, formats, brainstorming was done first) and thus documented as such. In contrast, I think with the work you've done, it looks like you have enough to move forward with a decent brainstorm/proposal. >> Also, for "alternate", see http://microformats.org/wiki/alternates >> (ditto). >> > > I wasn't aware of that discussion, thanks. > > Thanks for your valuable feedback Absolutely. Thanks for iterating on this with a good balance of progress on the wiki and minimal update summaries in email. Tantek -- http://tantek.com/ From martin at weborganics.co.uk Tue Nov 11 05:02:16 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Nov 11 05:02:39 2008 Subject: [uf-new] Comment Questions Message-ID: <49198258.4000704@weborganics.co.uk> Hello I have updated some of the pages relating to a comment microformat see: http://microformats.org/wiki/comment-examples http://microformats.org/wiki/comment-formats And also http://microformats.org/wiki/comment-brainstorming I believe a simple comment format is achievable, but first I have some things that need to be discussed The common consensus is that a comment format should rest in the realm of hAtom particularly hEntry, I kind of agree accept for one or two points The hAtom spec says : "an Entry /SHOULD/ have an Entry Title" Unfortunately None of the comment examples Support an entry-title element, in fact the "title" of a comment rarely occurs in common practice. How would a comment microformat (should it reuse hatom terms) resolve the concept of entry-title? http://microformats.org/wiki/hatom#Entry_Title The hAtom spec' also says: an Entry /SHOULD/ have an Entry Permalink Permalinks to comments DO occur but only around 40% of the time in the examples I have studied, but more often than that there is no permalink at all. The easy solution to that I suppose is require that every comment /must/ have a unique ID then a "permalink" can be generated into a fragment url eg: http://someweb.com/page#comment1, but isnt this imposing too much on would be authors by explicitly stating that every comment /must/ have an ID http://microformats.org/wiki/hatom#Entry_Permalink Thanks. -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Tue Nov 11 05:16:21 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Nov 11 05:16:23 2008 Subject: [uf-new] Comment Questions In-Reply-To: <49198258.4000704@weborganics.co.uk> References: <49198258.4000704@weborganics.co.uk> Message-ID: <21e523c20811110516sdc8ca95rdbe7bdfed5fc05fb@mail.gmail.com> On Tue, Nov 11, 2008 at 8:02 AM, Martin McEvoy wrote: > The hAtom spec says : > > "an Entry /SHOULD/ have an Entry Title" > > Unfortunately None of the comment examples Support an entry-title element, > in fact the "title" of a comment rarely occurs in common practice. How would > a comment microformat (should it reuse hatom terms) resolve the concept of > entry-title? > > http://microformats.org/wiki/hatom#Entry_Title Noting the difference between the Physical Model and the Logical Model for hAtom, several options occur when a entry-title is not present: * use the parent's entry-title * use Re: (locale issues) * use an empty tile > The hAtom spec' also says: > > an Entry /SHOULD/ have an Entry Permalink > > Permalinks to comments DO occur but only around 40% of the time in the > examples I have studied, but more often than that there is no permalink at > all. The easy solution to that I suppose is require that every comment > /must/ have a unique ID then a "permalink" can be generated into a fragment > url eg: http://someweb.com/page#comment1, but isnt this imposing too much on > would be authors by explicitly stating that every comment /must/ have an ID > > http://microformats.org/wiki/hatom#Entry_Permalink > How many have an ID tag where an Entry Permalink could be inferred? Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Tue Nov 11 06:05:45 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Nov 11 06:05:54 2008 Subject: [uf-new] Comment Questions In-Reply-To: <21e523c20811110516sdc8ca95rdbe7bdfed5fc05fb@mail.gmail.com> References: <49198258.4000704@weborganics.co.uk> <21e523c20811110516sdc8ca95rdbe7bdfed5fc05fb@mail.gmail.com> Message-ID: <49199139.5000908@weborganics.co.uk> David Janes wrote: > On Tue, Nov 11, 2008 at 8:02 AM, Martin McEvoy wrote: > > >> The hAtom spec says : >> >> "an Entry /SHOULD/ have an Entry Title" >> >> Unfortunately None of the comment examples Support an entry-title element, >> in fact the "title" of a comment rarely occurs in common practice. How would >> a comment microformat (should it reuse hatom terms) resolve the concept of >> entry-title? >> >> http://microformats.org/wiki/hatom#Entry_Title >> > > Noting the difference between the Physical Model and the Logical Model > for hAtom, several options occur when a entry-title is not present: > > * use the parent's entry-title > * use Re: (locale issues) > * use an empty tile > Looks like a difficult parsing model, does anything actually implement that? Microformats are about what you can see on a page, creating stuff out of thin air seems a little inconsistent and a little difficult to explain.... > >> The hAtom spec' also says: >> >> an Entry /SHOULD/ have an Entry Permalink >> >> Permalinks to comments DO occur but only around 40% of the time in the >> examples I have studied, but more often than that there is no permalink at >> all. The easy solution to that I suppose is require that every comment >> /must/ have a unique ID then a "permalink" can be generated into a fragment >> url eg: http://someweb.com/page#comment1, but isnt this imposing too much on >> would be authors by explicitly stating that every comment /must/ have an ID >> >> http://microformats.org/wiki/hatom#Entry_Permalink >> >> > > How many have an ID tag where an Entry Permalink could be inferred? > Quite a few of the examples do have an @id attribute 60% of them, how would I determine a permalink for the other 40%. > Regards, etc... > > Thanks David -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Wed Nov 12 08:05:51 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Nov 12 08:06:00 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <49198258.4000704@weborganics.co.uk> References: <49198258.4000704@weborganics.co.uk> Message-ID: <491AFEDF.7090509@weborganics.co.uk> Martin McEvoy wrote: > Hello > > I have updated some of the pages relating to a comment microformat see: > > http://microformats.org/wiki/comment-examples > http://microformats.org/wiki/comment-formats > > And also > > http://microformats.org/wiki/comment-brainstorming > > I believe a simple comment format is achievable, .... I have proposed a schema for a "comment" which re-uses Atom/hAtom terms there is also some example markup for all to view, "comments" or feedback is welcome Thanks. -- Martin McEvoy http://weborganics.co.uk/ From mail at tobyinkster.co.uk Wed Nov 12 08:50:34 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Nov 12 08:50:57 2008 Subject: [uf-new] Re: Comment Questions Message-ID: Martin McEvoy wrote: > I have proposed a schema for a "comment" which re-uses Atom/hAtom > terms > there is also some example markup for all to view I don't see why you feel the need to create a new schema "which re- uses hAtom terms". What's wrong with simply using hAtom as it is (possibly with the addition of Sarven's "in-reply-to" proposal)? There is no need to re-invent the wheel each time for feeds of comments, feeds of opinions, feeds of jokes, feeds of poems, feeds of witty Groucho Marx quotations, etc. Start within hAtom as a base and refine it for your needs, adding additional terms only if strictly needed, but not removing anything. That way, the majority of your format will be parsable with standard hAtom tools without everyone needing to write new hGrouchoMarxQuote parsers. -- Toby A Inkster From ararat01 at hotmail.com Wed Nov 12 21:11:10 2008 From: ararat01 at hotmail.com (Yu val) Date: Wed Nov 12 21:11:13 2008 Subject: [uf-new] hStore Microformat suggestion Message-ID: Hi Guys, I have a new suggestion for a Microformat that will be helpful for online shops. I have drafted the suggestion on my blog http://www.yuvalararat.com/store-microformat-suggestion-the-hstore thanks in advance Yuval Ararat _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008 From scott at makedatamakesense.com Wed Nov 12 21:32:19 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Nov 12 21:32:27 2008 Subject: [uf-new] hStore Microformat suggestion In-Reply-To: References: Message-ID: <6AF406B9-F626-4997-926D-FF037526D531@makedatamakesense.com> On [Nov 12], at [ Nov 12] 10:11 , Yu val wrote: > Hi Guys, > I have a new suggestion for a Microformat that will be helpful for > online shops. > I have drafted the suggestion on my blog > http://www.yuvalararat.com/store-microformat-suggestion-the-hstore > thanks in advance > Yuval Ararat Hi Yuval, It looks like you've re-invented hProduct: http://microformats.org/wiki/hproduct In the future you can save yourself time and avoid re-inventing existing work by following the microformats process: http://microformats.org/wiki/process -- Scott Reynen MakeDataMakeSense.com From ararat01 at hotmail.com Wed Nov 12 23:04:41 2008 From: ararat01 at hotmail.com (Yu val) Date: Wed Nov 12 23:04:44 2008 Subject: [uf-new] hStore Microformat suggestion In-Reply-To: <6AF406B9-F626-4997-926D-FF037526D531@makedatamakesense.com> References: <6AF406B9-F626-4997-926D-FF037526D531@makedatamakesense.com> Message-ID: Thaks for that. i was looking for it but didnt find it in the wiki. I think that format can improve so i will join the effort. Cheers, Yuval yuvalararat.com > From: scott@makedatamakesense.com > To: microformats-new@microformats.org > Subject: Re: [uf-new] hStore Microformat suggestion > Date: Wed, 12 Nov 2008 22:32:19 -0700 > > On [Nov 12], at [ Nov 12] 10:11 , Yu val wrote: > >> Hi Guys, >> I have a new suggestion for a Microformat that will be helpful for >> online shops. >> I have drafted the suggestion on my blog >> http://www.yuvalararat.com/store-microformat-suggestion-the-hstore >> thanks in advance >> Yuval Ararat > > Hi Yuval, > > It looks like you've re-invented hProduct: > > http://microformats.org/wiki/hproduct > > In the future you can save yourself time and avoid re-inventing > existing work by following the microformats process: > > http://microformats.org/wiki/process > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new _________________________________________________________________ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008 From mark at markng.me.uk Thu Nov 13 04:25:30 2008 From: mark at markng.me.uk (Mark Ng) Date: Thu Nov 13 04:26:03 2008 Subject: [uf-new] Statement of Principles/code of conduct - any prior work ? Message-ID: I'm currently working on an initiative to help increase news media transparency using the "semantic web", initially focussing on encouraging the use of microformats for news ( http://www.mediastandardstrust.org/projects/transparency.aspx - it's getting its own dedicated site in the next day or two ). One of the most important building blocks for this is being able to specify a statement of principles/ethics or code of conduct for a piece of content. I envisage this working something like rel-license. On looking around for prior work in this area, I've noticed this : http://patthorntonfiles.com/blog/2008/10/07/the-online-ethics-seal-together-we-can-be-more-transparent/ (which doesn't talk about the technical implementation of the idea, but more about providing example ethics codes, like creative commons), but not much else. Is anyone aware of other things I should look at before building some examples on the wiki ? Regards, Mark From martin at weborganics.co.uk Thu Nov 13 04:38:52 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 04:39:03 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: Message-ID: <491C1FDC.9010701@weborganics.co.uk> Toby A Inkster wrote: > Martin McEvoy wrote: > >> I have proposed a schema for a "comment" which re-uses Atom/hAtom terms >> there is also some example markup for all to view > > I don't see why you feel the need to create a new schema "which > re-uses hAtom terms". because it is desirable for people to be able to track comments that they have made on other peoples blogs, as well as keep track of comments made on their own blog, without having to re-visit the blog to check on responses... > What's wrong with simply using hAtom as it is (possibly with the > addition of Sarven's "in-reply-to" proposal)? because a "comment" does not fit into the concept of a hEntry, comments lack the entry-title element, in fact a "title" it is almost non-existent in a comment. I like Sarvens Idea to use Atom Extensions, But I have issues with in-reply-to because its not a part of the Atom spec and may require extra prefixing(namespacing) for it to be represented correctly in hAtom terms, > There is no need to re-invent the wheel each time for feeds of > comments, feeds of opinions, feeds of jokes, feeds of poems, feeds of > witty Groucho Marx quotations, etc. Start within hAtom as a base and > refine it for your needs, adding additional terms only if strictly needed, That is exactly what the schema proposes! > but not removing anything. Which I havent.... > That way, the majority of your format will be parsable with standard > hAtom tools The majority of the proposed comment schema[1] will work with standard hAtom tools .... Thanks [1] http://microformats.org/wiki/comment-brainstorming#Schema -- Martin McEvoy http://weborganics.co.uk/ From mail at tobyinkster.co.uk Thu Nov 13 05:08:40 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Nov 13 05:09:02 2008 Subject: [uf-new] Statement of Principles/code of conduct - any prior work ? Message-ID: Mark Ng wrote: > Is anyone aware of other things I should look at > before building some examples on the wiki ? A wider viewpoint would be to say that you want a way to associate a page with a standard with which it complies. This might be an ethical statement, but could also be a safety standard, or a law. This is similar to the previously posed ecolabel idea. On the rel-ecolabel page on the wiki, I added an idea for using Dublin Core's "conformsTo" term to cover this purpose: http://microformats.org/wiki/rel-ecolabel#RDFa -- Toby A Inkster From mail at tobyinkster.co.uk Thu Nov 13 05:20:21 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Nov 13 05:20:59 2008 Subject: [uf-new] Re: Comment Questions Message-ID: Martin McEvoy wrote: > Toby A Inkster wrote: > > > What's wrong with simply using hAtom as it is (possibly with the > > addition of Sarven's "in-reply-to" proposal)? > > because a "comment" does not fit into the concept of a hEntry, > comments > lack the entry-title element, in fact a "title" it is almost > non-existent in a comment. hAtom is still a draft format. This use case might be a convincing argument for hAtom 0.2 to drop the requirement for entry-title, and make it an optional property. > The majority of the proposed comment schema[1] will work with standard > hAtom tools > [1] http://microformats.org/wiki/comment-brainstorming#Schema The example given there doesn't have a root class name of "hentry", so would not be picked up by existing hAtom parsers. -- Toby A Inkster From mark at markng.me.uk Thu Nov 13 05:23:08 2008 From: mark at markng.me.uk (Mark Ng) Date: Thu Nov 13 05:23:13 2008 Subject: [uf-new] Statement of Principles/code of conduct - any prior work ? In-Reply-To: References: Message-ID: 2008/11/13 Toby A Inkster : > A wider viewpoint would be to say that you want a way to associate a page > with a standard with which it complies. This might be an ethical statement, > but could also be a safety standard, or a law. This is similar to the > previously posed ecolabel idea. Yup, and this is a very useful pattern. One important use case your example below misses though is distinguishing between different types of standards you comply to. If you're trying, for example to compile a list of different journalistic codes, it's not very helpful if you end up with a bunch of laws and ecological policies at the same time :). How would an RDFa example change to account for this ? (considering me RDFa-stupid, as I've done very very little with it). > http://microformats.org/wiki/rel-ecolabel#RDFa Is this something worth encoding as a microformat as well as RDFa, too ? From davidjanes at blogmatrix.com Thu Nov 13 05:32:15 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Nov 13 05:32:19 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: Message-ID: <21e523c20811130532i24569ea9x43a548489f67223f@mail.gmail.com> On Thu, Nov 13, 2008 at 8:20 AM, Toby A Inkster wrote: > hAtom is still a draft format. This use case might be a convincing argument > for hAtom 0.2 to drop the requirement for entry-title, and make it an > optional property. hAtom doesn't require a title to be physically present [1], but it's need for logically being present is because of the Atom spec [2]. In my mind I'd like _everything_ to be optionally present but easily inferable (to be standards compliant) in hAtom 0.2. Perhaps this would be good time to start that? Tantek mentioned to me clearing out a space on the wiki to start the ball rolling, we could list issues we want to see resolved / fixed / changed / added and go from there. Regards, etc... [1] http://microformats.org/wiki/hatom#Entry_Title [2] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.entry -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Thu Nov 13 06:00:02 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 06:00:34 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: Message-ID: <491C32E2.4090701@weborganics.co.uk> Toby A Inkster wrote: > Martin McEvoy wrote: >> Toby A Inkster wrote: >> >> > What's wrong with simply using hAtom as it is (possibly with the >> > addition of Sarven's "in-reply-to" proposal)? >> >> because a "comment" does not fit into the concept of a hEntry, comments >> lack the entry-title element, in fact a "title" it is almost >> non-existent in a comment. > > hAtom is still a draft format. This use case might be a convincing > argument for hAtom 0.2 to drop the requirement for entry-title, and > make it an optional property. > >> The majority of the proposed comment schema[1] will work with standard >> hAtom tools >> [1] http://microformats.org/wiki/comment-brainstorming#Schema > > The example given there doesn't have a root class name of "hentry", so > would not be picked up by existing hAtom parsers. > You would have to place the current proposed markup inside an hEntry... parsers would have to change (a little) Ok lets re-use hatom terms only this works...
Contributor said
about 72 days ago,

Hey Great Post

link to this
Is this proposed mark up acceptable there is a test page here: http://weborganics.co.uk/test/test.html and the extracted Atom Is here: http://transformr.co.uk/hatom/http://weborganics.co.uk/test/test.html Is the above mark-up acceptable to everyone? Best Wishes Thanks.. -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Thu Nov 13 06:24:40 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 06:24:51 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C32E2.4090701@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> Message-ID: <491C38A8.60504@weborganics.co.uk> Martin McEvoy wrote: > Toby A Inkster wrote: >> Martin McEvoy wrote: >>> Toby A Inkster wrote: >>> >>> > What's wrong with simply using hAtom as it is (possibly with the >>> > addition of Sarven's "in-reply-to" proposal) [...edit...] >>> Ok lets re-use hatom terms only this works... >>> >>>
>>>
>>> >> href="http://contributor.com/blog/">Contributor said >>>
>>> about 72 >>> days ago, >>>
>>>

Hey Great Post

>>>
>>> link to this >>>
>>> >>> Is this proposed mark up acceptable there is a test page here: >>> http://weborganics.co.uk/test/test.html >>> >>> and the extracted Atom Is here: >>> http://transformr.co.uk/hatom/http://weborganics.co.uk/test/test.html >>> I have updated the comment brainstorming pages, the Schema[1] strictly re-uses hAtom[2] terms [1] http://microformats.org/wiki/comment-brainstorming#Schema [2] http://microformats.org/wiki/hatom Thanks -- Martin McEvoy http://weborganics.co.uk/ From mail at tobyinkster.co.uk Thu Nov 13 07:18:18 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Nov 13 07:18:38 2008 Subject: [uf-new] Statement of Principles/code of conduct - any prior work ? Message-ID: <608FD46D-7DBC-4314-B2A6-43F7B66DC63B@tobyinkster.co.uk> Mark Ng wrote: > Yup, and this is a very useful pattern. One important use case your > example below misses though is distinguishing between different types > of standards you comply to. If you're trying, for example to compile > a list of different journalistic codes, it's not very helpful if you > end up with a bunch of laws and ecological policies at the same time > :). One solution to that would be to have the standards document itself state what type of standard it is, possibly using rel-tag. > How would an RDFa example change to account for this ? (considering me > RDFa-stupid, as I've done very very little with it). Assuming a namespace URI was set up at http://example.com/ns# with the definitions of all the types of standard, you could use something like:

This product conforms to the Foo law and Bar standards.

This page conforms to XHTML+RDFa 1.0.

In the example above, the
is just there as a convenient container to define the prefixes being used, "dc" and "ex". (In a theoretical microformat serialisation, this would probably be omitted, but I think it's useful to use a pure RDFa version as a prototype to get an idea about how a future microformat might work.) In RDFa, the about attribute is used to specify what you're making a statement about. The first paragraph says that "#product" (a fragment identifier representing the product in question) conforms to some stuff. The second paragraph omits an about attribute, so is taken to be about the page as a whole. If a microformat was created, perhaps nesting could be used to determine what the subject of the conformancy statement is. For example, within an hProduct or hListing, it would refer to the product; within an hCard, it would refer to the person or organisation; within an hCalendar event, it would refer to the event; within an hAtom entry, it would refer to the entry; within an hRecipe, it would refer to the recipe; otherwise it would refer to the page. The typeof attribute in RDFa then specifies the type of thing being complied with. The example above can be parsed by any RDFa implementation[1] resulting in a bunch of RDFa triples: <> dc:conformsTo . <#product> dc:conformsTo . <#product> dc:conformsTo . rdf:type ex:Law . rdf:type ex:Standard . rdf:type ex:WebStandard . A tool that is concerned with finding what is labelled that it complies with laws, but not worried about complying with standards would look for any triples such that X dc:conformsTo Y where Y has an rdf:type Z where Z is ex:Law or any subclass of ex:Law. The search for such triples could be handled using a single SPARQL[2] query. ____ 1. 2. SPARQL is a SQL-like language for querying RDF data. -- Toby A Inkster From martin at weborganics.co.uk Thu Nov 13 07:56:14 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 07:56:24 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C38A8.60504@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> Message-ID: <491C4E1E.1070801@weborganics.co.uk> Martin McEvoy wrote: > Martin McEvoy wrote: >> Toby A Inkster wrote: >>> Martin McEvoy wrote: >>>> Toby A Inkster wrote: >>>> >>>> > What's wrong with simply using hAtom as it is (possibly with the >>>> > addition of Sarven's "in-reply-to" proposal) > [...edit...] >>>> Ok lets re-use hatom terms only this works... >>>> >>>>
>>>>
>>>> >>> href="http://contributor.com/blog/">Contributor said >>>>
>>>> about 72 >>>> days ago, >>>>
>>>>

Hey Great Post

>>>>
>>>> link to this >>>>
>>>> >>>> Is this proposed mark up acceptable there is a test page here: >>>> http://weborganics.co.uk/test/test.html >>>> >>>> and the extracted Atom Is here: >>>> http://transformr.co.uk/hatom/http://weborganics.co.uk/test/test.html >>>> > > I have updated the comment brainstorming pages, the Schema[1] strictly > re-uses hAtom[2] terms > > [1] http://microformats.org/wiki/comment-brainstorming#Schema > [2] http://microformats.org/wiki/hatom > > Thanks > I would also like to propose that an hEntry that is a comment should be marked up like this.....
...
This will define the difference between the Post hEntry and a comment hEntry Thanks -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Thu Nov 13 07:58:17 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 07:58:27 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C4E1E.1070801@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> Message-ID: <491C4E99.6050200@weborganics.co.uk> Martin McEvoy wrote: > I would also like to propose that an hEntry that is a comment should > be marked up like this..... > >
> ... >
sorry I meant...
...
-- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Thu Nov 13 08:02:32 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Nov 13 08:02:35 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C4E99.6050200@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> Message-ID: <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> On Thu, Nov 13, 2008 at 10:58 AM, Martin McEvoy wrote: > Martin McEvoy wrote: >> >> I would also like to propose that an hEntry that is a comment should be >> marked up like this..... >> >>
>> ... >>
> > sorry I meant... > >
> ... >
> I think those would be equivalent (?). However, another way to do it would be to add "comments" to a wrapping hfeed
a comment
This is interestingly documented right here: http://www.flickr.com/photos/90594399@N00/2271787498/ Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From csarven at gmail.com Thu Nov 13 08:07:42 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Thu Nov 13 08:07:45 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C38A8.60504@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> Message-ID: On Thu, Nov 13, 2008 at 9:24 AM, Martin McEvoy wrote: > Martin McEvoy wrote: >> >> Toby A Inkster wrote: >>> >>> Martin McEvoy wrote: >>>> >>>> Toby A Inkster wrote: >>>> >>>> > What's wrong with simply using hAtom as it is (possibly with the >>>> > addition of Sarven's "in-reply-to" proposal) > > [...edit...] >>>> >>>> Ok lets re-use hatom terms only this works... >>>> >>>>
>>>>
>>>> >>> href="http://contributor.com/blog/">Contributor said >>>>
>>>> about 72 days >>>> ago, >>>>
>>>>

Hey Great Post

>>>>
>>>> link to this >>>>
>>>> >>>> Is this proposed mark up acceptable there is a test page here: >>>> http://weborganics.co.uk/test/test.html >>>> >>>> and the extracted Atom Is here: >>>> http://transformr.co.uk/hatom/http://weborganics.co.uk/test/test.html >>>> > > I have updated the comment brainstorming pages, the Schema[1] strictly > re-uses hAtom[2] terms
is misused there and is an open issue [1]. One way of going at it: http://csarven.ca/my-responses-are-in-white [1] http://microformats.org/wiki/hatom-issues#misuse_of_address_element -Sarven From csarven at gmail.com Thu Nov 13 08:13:09 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Thu Nov 13 08:13:12 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> Message-ID: On Thu, Nov 13, 2008 at 11:02 AM, David Janes wrote: > On Thu, Nov 13, 2008 at 10:58 AM, Martin McEvoy > wrote: >> Martin McEvoy wrote: >>> >>> I would also like to propose that an hEntry that is a comment should be >>> marked up like this..... >>> >>>
>>> ... >>>
>> >> sorry I meant... >> >>
>> ... >>
I've already proposed this [1] but it doesn't solve the actual replies. >> > I think those would be equivalent (?). However, another way to do it would > be to add "comments" to a wrapping hfeed > >
>
a comment
>
> > This is interestingly documented right here: > http://www.flickr.com/photos/90594399@N00/2271787498/ Cool. So we both reached in-reply-to [2] in our own separate investigations. [1] http://microformats.org/wiki/comment-brainstorming#Feedback [2] http://microformats.org/wiki/comment-brainstorming#hAtom_and_in-reply-to -Sarven -Sarven From hober0 at gmail.com Thu Nov 13 09:23:05 2008 From: hober0 at gmail.com (Edward O'Connor) Date: Thu Nov 13 09:23:07 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> Message-ID: <3b31caf90811130923s30c9573ep83631df4260f61a0@mail.gmail.com> I'm one of the original authors of the comment proposal--a proposal that we threw together without following the process, and that was made redundant by hAtom. I generally think simply using hAtom is enough; a separate comment format isn't necessary. That said, one thing to potentially look into would be the hAtom-ification of RFC 4685, the Atom Threading Extensions[0], to handle marking up which hentry is a reply to which other hentry. Something along these lines might do the trick:
... comments ...
... ... ...
Ted 0. http://www.ietf.org/rfc/rfc4685.txt From martin at weborganics.co.uk Thu Nov 13 11:57:35 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 11:57:45 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> Message-ID: <491C86AF.70803@weborganics.co.uk> Hello David... David Janes wrote: > On Thu, Nov 13, 2008 at 10:58 AM, Martin McEvoy > wrote: > >> Martin McEvoy wrote: >> >>> I would also like to propose that an hEntry that is a comment should be >>> marked up like this..... >>> >>>
>>> ... >>>
>>> >> sorry I meant... >> >>
>> ... >>
>> >> > I think those would be equivalent (?). However, another way to do it would > be to add "comments" to a wrapping hfeed > >
>
a comment
>
> Im Sorry David I totally disagree with the above approach because It detaches the comments from the original content, The Content and the Comment should be presented inside the same feed element. > This is interestingly documented right here: > http://www.flickr.com/photos/90594399@N00/2271787498/ > Great stuff David, I dont like the in-reply-to extension because for it to presented correctly in hAtom terms you would have to "emulate" another namespace, ie the entry- bit. Anyway If you are proposing adding stuff to hatom like in-reply-to(replies) etc... why not use an official atom term like "related"[1] link to this [1] http://www.atomenabled.org/developers/syndication/index.php#link Thanks. -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Thu Nov 13 12:02:45 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 12:02:55 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C86AF.70803@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> Message-ID: <491C87E5.2060308@weborganics.co.uk> Martin McEvoy wrote: > Hello David... > > David Janes wrote: >> On Thu, Nov 13, 2008 at 10:58 AM, Martin McEvoy >> wrote: >> >>> Martin McEvoy wrote: >>> >>>> I would also like to propose that an hEntry that is a comment >>>> should be >>>> marked up like this..... >>>> >>>>
>>>> ... >>>>
>>>> >>> sorry I meant... >>> >>>
>>> ... >>>
>>> >>> >> I think those would be equivalent (?). However, another way to do it >> would >> be to add "comments" to a wrapping hfeed >> >>
>>
a comment
>>
>> > Im Sorry David I totally disagree with the above approach because It > detaches the comments from the original content, The Content and the > Comment should be presented inside the same feed element. >> This is interestingly documented right here: >> http://www.flickr.com/photos/90594399@N00/2271787498/ >> > Great stuff David, I dont like the in-reply-to extension because for > it to presented correctly in hAtom terms you would have to "emulate" > another namespace, ie the entry- bit. > > Anyway If you are proposing adding stuff to hatom like > in-reply-to(replies) etc... why not use an official atom term like > "related"[1] > > link to this > > [1] http://www.atomenabled.org/developers/syndication/index.php#link Even better use an existing link type "section"[1] to indicate that the href attribute of a link is a section of the current page. link to this [1] http://www.w3.org/TR/html4/types.html#h-6.12 > > > Thanks. > > -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Thu Nov 13 12:10:20 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Nov 13 12:10:22 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C86AF.70803@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> Message-ID: <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> On Thu, Nov 13, 2008 at 2:57 PM, Martin McEvoy wrote: > Hello David... > > David Janes wrote: >> >> On Thu, Nov 13, 2008 at 10:58 AM, Martin McEvoy >> wrote: >> >>> >>> Martin McEvoy wrote: >>> >>>> >>>> I would also like to propose that an hEntry that is a comment should be >>>> marked up like this..... >>>> >>>>
>>>> ... >>>>
>>>> >>> >>> sorry I meant... >>> >>>
>>> ... >>>
>>> >>> >> >> I think those would be equivalent (?). However, another way to do it would >> be to add "comments" to a wrapping hfeed >> >>
>>
a comment
>>
>> > > Im Sorry David I totally disagree with the above approach because It > detaches the comments from the original content, The Content and the Comment > should be presented inside the same feed element. >> >> This is interestingly documented right here: >> http://www.flickr.com/photos/90594399@N00/2271787498/ >> > > Great stuff David, I dont like the in-reply-to extension because for it to > presented correctly in hAtom terms you would have to "emulate" another > namespace, ie the entry- bit. > > Anyway If you are proposing adding stuff to hatom like in-reply-to(replies) > etc... why not use an official atom term like "related"[1] > > link to this > > [1] http://www.atomenabled.org/developers/syndication/index.php#link Hi Martin, How does it detach it? You end up with a page that's structured like this: My Blog post Bla bla bla, I have a blog You are so smart and handsome I don't think there's too many blog pages that don't use this implicit structure. My apologies if I'm missing something.... Regards, etc... David -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Thu Nov 13 12:58:19 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 12:58:30 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> Message-ID: <491C94EB.1050505@weborganics.co.uk> David Janes wrote: > Hi Martin, > Hello David.. > How does it detach it? You end up with a page that's structured like this: > > > > My Blog post > Bla bla bla, I have a blog > > > You are so smart and handsome > > > > > I don't think there's too many blog pages that don't use this implicit > structure. Yes having a quick look at the examples I have I would say that you are correct. What the "comment"(singular) problem so to speak is a simpler problem than "comments"(plural), and really basic it deals with the singular issue of a comment, (solve the simpler problems first) which only consists really of a few singular properties such as the author, the date, the comment the author made and where it is > My apologies if I'm missing something.... > No need, many people have misunderstood the comment problem hence thats why this subject has splintered off in so many ways[1][2][3], this effort will hopefully consolidate this problem(which is really simple[4]). [1] http://microformats.org/wiki/comments-formats [2] http://microformats.org/wiki/mfcomment [3] http://microformats.org/wiki/hcomment [4] http://microformats.org/wiki/comment-problem Thanks -- Martin McEvoy http://weborganics.co.uk/ From tantek at cs.stanford.edu Thu Nov 13 14:13:28 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Thu Nov 13 14:14:16 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491C94EB.1050505@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk><21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com><491C94EB.1050505@weborganics.co.uk> Message-ID: <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> Martin, David Janes, Sarven thanks very much for your good analysis and back/forth discussion of possible approaches to solving the comment(s) problem(s). One comment on comment vs comments. In general it works better to develop microformats (and properties) to represent a single instance of something (rather than multiple instances), and then use the collection/list/pluralization/aggregation features of the context (whether implicit, like multiple contained/descendant elements, or explicit like in an OL/UL as with XOXO) to represent more than one instance. In some cases that collection itself will/canbe considered an instance of something that has its own properties. Hence hfeed and vcalendar in addition to hentry and vevent. But even in those cases it is better to focus on the instance first and then the collection later. Tantek -----Original Message----- From: Martin McEvoy Date: Thu, 13 Nov 2008 20:58:19 To: For discussion of new microformats. Subject: Re: [uf-new] Re: Comment Questions David Janes wrote: > Hi Martin, > Hello David.. > How does it detach it? You end up with a page that's structured like this: > > > > My Blog post > Bla bla bla, I have a blog > > > You are so smart and handsome > > > > > I don't think there's too many blog pages that don't use this implicit > structure. Yes having a quick look at the examples I have I would say that you are correct. What the "comment"(singular) problem so to speak is a simpler problem than "comments"(plural), and really basic it deals with the singular issue of a comment, (solve the simpler problems first) which only consists really of a few singular properties such as the author, the date, the comment the author made and where it is > My apologies if I'm missing something.... > No need, many people have misunderstood the comment problem hence thats why this subject has splintered off in so many ways[1][2][3], this effort will hopefully consolidate this problem(which is really simple[4]). [1] http://microformats.org/wiki/comments-formats [2] http://microformats.org/wiki/mfcomment [3] http://microformats.org/wiki/hcomment [4] http://microformats.org/wiki/comment-problem Thanks -- Martin McEvoy http://weborganics.co.uk/ _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Thu Nov 13 14:14:37 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 14:14:47 2008 Subject: [uf-new] Comment Proposal Message-ID: <491CA6CD.7020206@weborganics.co.uk> Hello all... As per the recent discussions on a comment microformat I have updated the comment-brainstorming page with an updated schema Proposal: * hentry (a container element for a comment entry) * author (author)100% o an Entry Author element MUST be encoded in an hCard 1. http://microformats.org/wiki/hatom#Entry_Author * url (author-url) 92% o Use the url value of a hcard * entry-content (comment) 100% o The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry 1. http://microformats.org/wiki/hatom#Entry_Content * updated (date) 100% o use the datetime-design-pattern to encode the updated datetime 1. http://microformats.org/wiki/hatom#Entry_Updated * section (comment-link) 40% o section: to indicate that the href attribute of a link is a section of the current page. 1. http://www.w3.org/TR/html4/types.html#h-6.12 2. A parser could parse this link type as either (depending on context and usage): + The Atom related (http://www.atomenabled.org/developers/syndication/index.php#link) link type(for atom conformity) + The in-reply-to Atom Threading Extension (http://tools.ietf.org/html/rfc4685) 3. The section link type is used to determine the difference between a comment and an article or blog post Example:
Author said
about 72 days ago,

Hey Great Post

link to this
Thanks http://microformats.org/wiki/comment-brainstorming -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Thu Nov 13 16:32:31 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 16:32:44 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk><21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com><491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> Message-ID: <491CC71F.40801@weborganics.co.uk> Tantek Celik wrote: > Martin, David Janes, Sarven thanks very much for your good analysis and back/forth discussion of possible approaches to solving the comment(s) problem(s). > Thank you. > One comment on comment vs comments. > > In general it works better to develop microformats (and properties) to represent a single instance of something (rather than multiple instances), and then use the collection/list/pluralization/aggregation features of the context (whether implicit, like multiple contained/descendant elements, or explicit like in an OL/UL as with XOXO) to represent more than one instance. > > In some cases that collection itself will/canbe considered an instance of something that has its own properties. Hence hfeed and vcalendar in addition to hentry and vevent. But even in those cases it is better to focus on the instance first and then the collection later. > I Agree, with that in mind I have updated the proposal for a comment microformat: http://microformats.org/wiki/comment-brainstorming#Proposal ...a summary is that on the whole nothing new is needed for a comment microformat, just use hAtom, but instead of using rel-bookmark use the html link type (http://www.w3.org/TR/html4/types.html#h-6.12) rel-section. Thanks -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Thu Nov 13 16:57:04 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 13 16:57:15 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491CC71F.40801@weborganics.co.uk> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk><21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com><491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <491CC71F.40801@weborganics.co.uk> Message-ID: <491CCCE0.7090606@weborganics.co.uk> Martin McEvoy wrote: > http://microformats.org/wiki/comment-brainstorming#Proposal > > ...a summary is that on the whole nothing new is needed for a comment > microformat, just use hAtom, but instead of using rel-bookmark use the > html link type (http://www.w3.org/TR/html4/types.html#h-6.12) > rel-section. You know, maybe the comment proposal could use XFN rel-contact instead of rel-section ? link to this what do you think? Thanks -- Martin McEvoy http://weborganics.co.uk/ From mail at tobyinkster.co.uk Fri Nov 14 01:58:55 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Nov 14 01:59:15 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> Martin McEvoy wrote: > ...a summary is that on the whole nothing new is needed for a comment > microformat, just use hAtom, but instead of using rel-bookmark use the > html link type (http://www.w3.org/TR/html4/types.html#h-6.12) rel- > section. Why not rel=bookmark? http://www.w3.org/TR/REC-html40/types.html#h-6.12 | Refers to a bookmark. A bookmark is a link to a key entry point within | an extended document. The title attribute may be used, for example, to | label the bookmark. Note that several bookmarks may be defined in each | document. http://microformats.org/wiki/rel-design-pattern#rel.3D.22bookmark.22 | By convention, this entry point also captures the notion of a "permalink". -- Toby A Inkster From martin at weborganics.co.uk Fri Nov 14 02:22:10 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 02:22:21 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> Message-ID: <491D5152.80508@weborganics.co.uk> Toby A Inkster wrote: > Martin McEvoy wrote: > >> ...a summary is that on the whole nothing new is needed for a comment >> microformat, just use hAtom, but instead of using rel-bookmark use the >> html link type (http://www.w3.org/TR/html4/types.html#h-6.12) >> rel-section. > > > Why not rel=bookmark? > > http://www.w3.org/TR/REC-html40/types.html#h-6.12 > > | Refers to a bookmark. A bookmark is a link to a key entry point within > | an extended document. The title attribute may be used, for example, to > | label the bookmark. Note that several bookmarks may be defined in each > | document. > > http://microformats.org/wiki/rel-design-pattern#rel.3D.22bookmark.22 > > | By convention, this entry point also captures the notion of a > "permalink". > Agreed, I also feel that in order for a parser to extract comments only from a page a different link type is needed for a comment, it will help distinguish a comment from the article. Having said that I am thinking re-use XFN rel-contact for this link type, and use rel-bookmark for backwards compatibility with existing parsers eg: link to this |contact could be parsed as the in-reply-to Atom Threading Extension (http://tools.ietf.org/html/rfc4685). |Thanks -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Fri Nov 14 02:26:24 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 02:26:35 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491D5152.80508@weborganics.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> Message-ID: <491D5250.9020608@weborganics.co.uk> Martin McEvoy wrote: > Toby A Inkster wrote: >> Why not rel=bookmark? >> >> http://www.w3.org/TR/REC-html40/types.html#h-6.12 >> >> | Refers to a bookmark. A bookmark is a link to a key entry point within >> | an extended document. The title attribute may be used, for example, to >> | label the bookmark. Note that several bookmarks may be defined in each >> | document. >> >> http://microformats.org/wiki/rel-design-pattern#rel.3D.22bookmark.22 >> >> | By convention, this entry point also captures the notion of a >> "permalink". >> > Agreed, I also feel that in order for a parser to extract comments > only from a page a different link type is needed for a comment, it > will help distinguish a comment from the article. > > Having said that I am thinking re-use XFN rel-contact for this link > type, and use rel-bookmark for backwards compatibility with existing > parsers eg: > > link to this > > |contact could be parsed as the in-reply-to Atom Threading Extension > (http://tools.ietf.org/html/rfc4685). Please see http://microformats.org/wiki/comment-brainstorming#Schema Thanks -- Martin McEvoy http://weborganics.co.uk/ From mark at markng.me.uk Fri Nov 14 03:15:33 2008 From: mark at markng.me.uk (Mark Ng) Date: Fri Nov 14 03:15:36 2008 Subject: [uf-new] Statement of Principles/code of conduct - any prior work ? In-Reply-To: <608FD46D-7DBC-4314-B2A6-43F7B66DC63B@tobyinkster.co.uk> References: <608FD46D-7DBC-4314-B2A6-43F7B66DC63B@tobyinkster.co.uk> Message-ID: 2008/11/13 Toby A Inkster : > Mark Ng wrote: > One solution to that would be to have the standards document itself state > what type of standard it is, possibly using rel-tag. Possibly, though how would you know *which* tag inside a page was denoting what type of document it is ? > In the example above, the
is just there as a convenient container to > define the prefixes being used, "dc" and "ex". (In a theoretical microformat > serialisation, this would probably be omitted, but I think it's useful to > use a pure RDFa version as a prototype to get an idea about how a future > microformat might work.) Yup - though I wonder how one might sensibly serialise this as a microformat as it is currently invisible data (and maybe it shouldn't be). Or is it actually best serialising this as rel="license" or rel="ecolabel" or, in my case rel="statement-of-principles" and just have the RDFa form of it be as you specify ? I'm not sure whether it would be better to suggest a larger "conforms" pattern or just suggest a specific rel-pattern that solves my particular problem - I guess I'm looking for some more guidance. Mark From davidjanes at blogmatrix.com Fri Nov 14 04:29:30 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Nov 14 04:29:33 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491D5250.9020608@weborganics.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> Message-ID: <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> Just so I get this straight, what's the official Wiki pages we're using to capture all of this? Regards, etc... On Fri, Nov 14, 2008 at 5:26 AM, Martin McEvoy wrote: > Martin McEvoy wrote: >> >> Toby A Inkster wrote: >>> >>> Why not rel=bookmark? >>> >>> http://www.w3.org/TR/REC-html40/types.html#h-6.12 >>> >>> | Refers to a bookmark. A bookmark is a link to a key entry point within >>> | an extended document. The title attribute may be used, for example, to >>> | label the bookmark. Note that several bookmarks may be defined in each >>> | document. >>> >>> http://microformats.org/wiki/rel-design-pattern#rel.3D.22bookmark.22 >>> >>> | By convention, this entry point also captures the notion of a >>> "permalink". >>> >> Agreed, I also feel that in order for a parser to extract comments only >> from a page a different link type is needed for a comment, it will help >> distinguish a comment from the article. >> >> Having said that I am thinking re-use XFN rel-contact for this link type, >> and use rel-bookmark for backwards compatibility with existing parsers eg: >> >> link to this >> >> |contact could be parsed as the in-reply-to Atom Threading Extension >> (http://tools.ietf.org/html/rfc4685). > > Please see http://microformats.org/wiki/comment-brainstorming#Schema > > Thanks > > > -- > Martin McEvoy > > http://weborganics.co.uk/ > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Fri Nov 14 05:43:28 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 05:43:39 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> Message-ID: <491D8080.7020209@weborganics.co.uk> David Janes wrote: > Just so I get this straight, what's the official Wiki pages we're > using to capture all of this? > http://microformats.org/wiki/comment ;-) > Regards, etc... > > On Fri, Nov 14, 2008 at 5:26 AM, Martin McEvoy wrote: > >> Martin McEvoy wrote: >> >>> Toby A Inkster wrote: >>> >>>> Why not rel=bookmark? >>>> >>>> http://www.w3.org/TR/REC-html40/types.html#h-6.12 >>>> >>>> | Refers to a bookmark. A bookmark is a link to a key entry point within >>>> | an extended document. The title attribute may be used, for example, to >>>> | label the bookmark. Note that several bookmarks may be defined in each >>>> | document. >>>> >>>> http://microformats.org/wiki/rel-design-pattern#rel.3D.22bookmark.22 >>>> >>>> | By convention, this entry point also captures the notion of a >>>> "permalink". >>>> >>>> >>> Agreed, I also feel that in order for a parser to extract comments only >>> from a page a different link type is needed for a comment, it will help >>> distinguish a comment from the article. >>> >>> Having said that I am thinking re-use XFN rel-contact for this link type, >>> and use rel-bookmark for backwards compatibility with existing parsers eg: >>> >>> link to this >>> >>> |contact could be parsed as the in-reply-to Atom Threading Extension >>> (http://tools.ietf.org/html/rfc4685). >>> >> Please see http://microformats.org/wiki/comment-brainstorming#Schema >> >> Thanks >> >> >> -- >> Martin McEvoy >> >> http://weborganics.co.uk/ >> >> _______________________________________________ >> microformats-new mailing list >> microformats-new@microformats.org >> http://microformats.org/mailman/listinfo/microformats-new >> >> > > > > -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Fri Nov 14 06:14:55 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Nov 14 06:14:58 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491D8080.7020209@weborganics.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> Message-ID: <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> On Fri, Nov 14, 2008 at 8:43 AM, Martin McEvoy wrote: > > David Janes wrote: >> >> Just so I get this straight, what's the official Wiki pages we're >> using to capture all of this? >> > > http://microformats.org/wiki/comment > > ;-) Excellent. I've added the proposal from the photo here [1] Regards, etc... [1] http://microformats.org/wiki/comment-brainstorming#Schema_II -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Fri Nov 14 06:30:23 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 06:30:34 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> Message-ID: <491D8B7F.1010601@weborganics.co.uk> David Janes wrote: > On Fri, Nov 14, 2008 at 8:43 AM, Martin McEvoy wrote: > >> David Janes wrote: >> >>> Just so I get this straight, what's the official Wiki pages we're >>> using to capture all of this? >>> >>> >> http://microformats.org/wiki/comment >> >> ;-) >> > > Excellent. I've added the proposal from the photo here [1] > > Regards, etc... > > [1] http://microformats.org/wiki/comment-brainstorming#Schema_II > Thank you David for your input I have Issues about this approach "if there is no Entry Title for a comment, it can be assumed to be empty or the blog post title (investigate current atom feeds) " the atom:title element should not be empty... "It is advisable that each atom:entry element contain a non-empty atom:title element" http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 (Providing Textual Content). To exclude the entry-title element I would recommend a comment use the value of "fn" presented in a contextual way eg: by Author Author said Author says etc... Also, Are there any parsers that will digest nested elements ? Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Fri Nov 14 06:37:14 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Nov 14 06:37:16 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491D8B7F.1010601@weborganics.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> <491D8B7F.1010601@weborganics.co.uk> Message-ID: <21e523c20811140637q7b5acdd6rc8ca88707fada6c6@mail.gmail.com> On Fri, Nov 14, 2008 at 9:30 AM, Martin McEvoy wrote: > "if there is no Entry Title for a comment, it can be assumed to be empty or > the blog post title (investigate current atom feeds) " > > the atom:title element should not be empty... > > "It is advisable that each atom:entry element contain a non-empty atom:title > element" > Advisable is not SHOULD or MUST though. The latter part of my comment is probably the important thing ... let's have a look at some Atom published comment feeds (I suspect Blogger/Blogspot does this) and see what the current use consensus is. > To exclude the entry-title element I would recommend a comment use the value > of "fn" presented in a contextual way eg: > > by Author > Author said > Author says > etc... This seems overly prescriptive to me, but even then: if we think this is a good idea, why not just infer this if there's no entry-title. Regards, etc... From martin at weborganics.co.uk Fri Nov 14 06:39:50 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 06:40:02 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491D8B7F.1010601@weborganics.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> <491D8B7F.1010601@weborganics.co.uk> Message-ID: <491D8DB6.5010508@weborganics.co.uk> Martin McEvoy wrote: > David Janes wrote: >> On Fri, Nov 14, 2008 at 8:43 AM, Martin McEvoy >> wrote: >> >>> David Janes wrote: >>> >>>> Just so I get this straight, what's the official Wiki pages we're >>>> using to capture all of this? >>>> >>>> >>> http://microformats.org/wiki/comment >>> >>> ;-) >>> >> >> Excellent. I've added the proposal from the photo here [1] >> >> Regards, etc... >> >> [1] http://microformats.org/wiki/comment-brainstorming#Schema_II >> [some edits] > > Also, Are there any parsers that will digest nested elements ? > I would like to add that one of the key problems about a "comment" is "How do you track blog comments you've made? " If you explicitly detach the comments from the article by presenting the the comments and the article in two separate feed elements, you break the conversation, in other words the subject of the conversation(the article or blog post) should explicitly remain with the conversation itself, this saves the subscriber of a feed having to visit the webpage again, just to find out what the conversation(comment) is about. Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Fri Nov 14 06:44:30 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Nov 14 06:44:33 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491D8DB6.5010508@weborganics.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> <491D8B7F.1010601@weborganics.co.uk> <491D8DB6.5010508@weborganics.co.uk> Message-ID: <21e523c20811140644k6e9789e3s53f892e46a71ae44@mail.gmail.com> On Fri, Nov 14, 2008 at 9:39 AM, Martin McEvoy wrote: > I would like to add that one of the key problems about a "comment" is "How > do you track blog comments you've made? " > > If you explicitly detach the comments from the article by presenting the the > comments and the article in two separate feed elements, you break the > conversation, in other words the subject of the conversation(the article or > blog post) should explicitly remain with the conversation itself, this saves > the subscriber of a feed having to visit the webpage again, just to find out > what the conversation(comment) is about. Two _nested_ Feeds. The Comment:Entry is nested in the Comments:Feed nested in the Blog:Entry in the (optional) Blog:Feed. BTW: Blogger just makes up a title [1] for comments Regard, etc... [1] http://rjmjanes.blogspot.com/feeds/comments/default?alt=atom -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Fri Nov 14 06:57:27 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 06:57:39 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811140637q7b5acdd6rc8ca88707fada6c6@mail.gmail.com> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> <491D8B7F.1010601@weborganics.co.uk> <21e523c20811140637q7b5acdd6rc8ca88707fada6c6@mail.gmail.com> Message-ID: <491D91D7.5020300@weborganics.co.uk> David Janes wrote: > On Fri, Nov 14, 2008 at 9:30 AM, Martin McEvoy wrote: > > >> "if there is no Entry Title for a comment, it can be assumed to be empty or >> the blog post title (investigate current atom feeds) " >> >> the atom:title element should not be empty... >> >> "It is advisable that each atom:entry element contain a non-empty atom:title >> element" >> >> > > Advisable is not SHOULD or MUST though. The latter part of my comment > is probably the important thing ... let's have a look at some Atom > published comment feeds (I suspect Blogger/Blogspot does this) and see > what the current use consensus is. > they usually build something contextual from the comment... http://www.chesslodge.com/2007/03/chess-video-lesson-2/feed/ http://bottomunion.com/blog/?feed=rss2&p=469 http://www.accidenthash.com/2007/04/02/gray-wet-yuck-monday/feed/ http://www.itsjerrytime.com/?feed=rss2&p=89 http://www.haloscan.com/members/rss.php?user=empirestatehuman http://ryanedit.blogspot.com/feeds/113755745032692159/comments/default .... are a few examples, the only thing they all really have in common is the authors Name. > >> To exclude the entry-title element I would recommend a comment use the value >> of "fn" presented in a contextual way eg: >> >> by Author >> Author said >> Author says >> etc... >> > > This seems overly prescriptive to me, but even then: if we think this > is a good idea, why not just infer this if there's no entry-title. > I don't know David nothing really, the only real answer I can give to this Is if you look at the feed examples above (and any other feed), none of the titles are empty and to be honest I have never really seen it in practice. Thanks > Regards, etc... > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Fri Nov 14 08:57:34 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 08:57:52 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811140644k6e9789e3s53f892e46a71ae44@mail.gmail.com> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> <491D8B7F.1010601@weborganics.co.uk> <491D8DB6.5010508@weborganics.co.uk> <21e523c20811140644k6e9789e3s53f892e46a71ae44@mail.gmail.com> Message-ID: <491DADFE.9090103@weborganics.co.uk> David Janes wrote: > On Fri, Nov 14, 2008 at 9:39 AM, Martin McEvoy wrote: > > >> I would like to add that one of the key problems about a "comment" is "How >> do you track blog comments you've made? " >> >> If you explicitly detach the comments from the article by presenting the the >> comments and the article in two separate feed elements, you break the >> conversation, in other words the subject of the conversation(the article or >> blog post) should explicitly remain with the conversation itself, this saves >> the subscriber of a feed having to visit the webpage again, just to find out >> what the conversation(comment) is about. >> > > Two _nested_ Feeds. The Comment:Entry is nested in the Comments:Feed > nested in the Blog:Entry in the (optional) Blog:Feed > "the Feed element is optional and, if missing, is assumed to be the page" http://microformats.org/wiki/hatom#Feed from the atom spec: http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 "The "atom:feed" element is the document (i.e., top-level) element of an Atom Feed Document" That being said the atom spec also says about content... "If the value of "type" is an XML media type [RFC3023] or ends with "+xml" or "/xml" (case insensitive), the content of atom:content MAY include child elements and SHOULD be suitable for handling as the indicated media type" which is interesting I think, does this include elements? > BTW: Blogger just makes up a title [1] for comments > > Regard, etc... > > [1] http://rjmjanes.blogspot.com/feeds/comments/default?alt=atom > > Thank you -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Fri Nov 14 09:00:18 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 09:00:29 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491DADFE.9090103@weborganics.co.uk> References: <1DB19069-4962-49E5-8F39-9F004BE9E13B@tobyinkster.co.uk> <491D5152.80508@weborganics.co.uk> <491D5250.9020608@weborganics.co.uk> <21e523c20811140429t66c062f5ibfde979e9d65fb9e@mail.gmail.com> <491D8080.7020209@weborganics.co.uk> <21e523c20811140614j2ba0b22ej915b7c0db9213b64@mail.gmail.com> <491D8B7F.1010601@weborganics.co.uk> <491D8DB6.5010508@weborganics.co.uk> <21e523c20811140644k6e9789e3s53f892e46a71ae44@mail.gmail.com> <491DADFE.9090103@weborganics.co.uk> Message-ID: <491DAEA2.10701@weborganics.co.uk> Martin McEvoy wrote: > > That being said the atom spec also says about content... > > "If the value of "type" is an XML media type [RFC3023] or ends with > "+xml" or "/xml" (case insensitive), the content of > atom:content MAY include child elements and SHOULD be suitable for > handling as the indicated media type" > oops! http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.3.3 -- Martin McEvoy http://weborganics.co.uk/ From mail at tobyinkster.co.uk Fri Nov 14 11:08:47 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Nov 14 11:09:07 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <3546AB2E-22E9-447B-94BA-0F709D1C593B@tobyinkster.co.uk> Martin McEvoy wrote: > Also, Are there any parsers that will digest nested elements ? Recent versions of Cognition will handle nested hfeeds correctly, only associating the hentries with their innermost ancestor hfeed. e.g.: Will be parsed as a structure: Feed f1: Entry f1e1 Entry f1e2 Feed f2: Entry f2e1 Feed f3: Entry f3e1 However, no particular relationship between the feeds is inferred from the nesting. They are taken to be completely independent. Atom files of course only allow a single element, so if outputting Atom, Cognition needs to be told which feed to output. By default it will pick the implied hfeed on if that has any entries, and if not it will pick one mostly at random. If given an input URI with a fragment identifier that points to an element with class='hfeed' it will output the feed identified. The RDF based outputs include all the feeds, but not using an RSS-compatible vocabulary. -- Toby A Inkster From mail at tobyinkster.co.uk Fri Nov 14 11:26:13 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Nov 14 11:34:05 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <66BE7085-65AC-48C5-9DF9-4EA062ED1CCB@tobyinkster.co.uk> Martin McEvoy wrote: > Having said that I am thinking re-use XFN rel-contact for this link > type, and use rel-bookmark for backwards compatibility with existing > parsers The XFN definition says that rel=contact is for people you know how to contact. I certainly don't know how to contact everyone who comments on my blog. I think the *best* way to indicate that a particular hentry represents a comment would be to rel-tag it as "Comment", but as rel- tags tend to be visible, that's not in keeping with current publishing practice. So class="comment" on the hentry or class="comments" on the hfeed makes more sense to me. I'd probably slightly prefer the former, as it allows for non-comments to also be included in the hfeed (e.g. "updated" messages, pingbacks, etc). > contact could be parsed as the in-reply-to Atom Threading Extension > (http://tools.ietf.org/html/rfc4685). Actually a good alternative to rel="in-reply-to" for describing a hierarchy of comments might be rel="up" to indicate a link to a comment further up the hierarchy. rel="up" is not standardised in HTML 4.01, but is widely used, and included in the current HTML5 drafts. -- Toby A Inkster From mail at tobyinkster.co.uk Fri Nov 14 11:51:30 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Nov 14 11:59:03 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <2D527F98-8114-48EC-A5A4-5AE42DCD7A44@tobyinkster.co.uk> I wrote: > I think the *best* way to indicate that a particular hentry > represents a comment would be to rel-tag it as "Comment", but as rel- > tags tend to be visible, that's not in keeping with current > publishing practice. So class="comment" on the hentry or > class="comments" on the hfeed makes more sense to me. Or perhaps a rel-tag of "Comments" on the feed itself: http://microformats.org/wiki/hatom#Feed_Category -- Toby A Inkster From martin at weborganics.co.uk Fri Nov 14 11:53:21 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Nov 14 13:05:33 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <66BE7085-65AC-48C5-9DF9-4EA062ED1CCB@tobyinkster.co.uk> References: <66BE7085-65AC-48C5-9DF9-4EA062ED1CCB@tobyinkster.co.uk> Message-ID: <491DD731.1060401@weborganics.co.uk> Toby A Inkster wrote: > Martin McEvoy wrote: > >> Having said that I am thinking re-use XFN rel-contact for this link >> type, and use rel-bookmark for backwards compatibility with existing >> parsers > > The XFN definition says that rel=contact is for people you know how to > contact. I certainly don't know how to contact everyone who comments > on my blog. > Yes you do, via your blog specifically the page that was commented on, a commenter also knows how to get in touch with you also via the same route. -- Martin McEvoy http://weborganics.co.uk/ From mail at tobyinkster.co.uk Sat Nov 15 05:28:17 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Nov 15 05:28:46 2008 Subject: [uf-new] Re: Comment Questions Message-ID: OK, I've had a think about this overnight, which is often a good way of clarifying an issue in ones head. Upon consideration, I think the best solution is as follows. What is the nature of a comment? What makes a piece of text not just a piece of text, but a comment? I think the answer is that a comment is a (usually short) reply to something. (The length of a reply can easily be determined by a byte count if required, so I will ignore this feature of comments.) So what we need is a method for indicating that one hentry is a reply to another hentry. I propose (or put my vote behind earlier proposals for) two methods and suggest that *both* be allowed. 1. Within the parent hentry, a class="hfeed replies" is used to group all direct replies to it. The entire replies hfeed must be within the parent *hentry* (not just within the parent hfeed). This solution suits a threaded layout, with each level of hfeed perhaps left inset by a few ems - similar to slashdot. No explicit visible links are required between an hentry and its parent, as the layout makes the relationships clear. 2. An hentry can link to its parent hentry using rel="in-reply- to" (or perhaps class="in-reply-to"). This is Sarven's proposal. This allows for comments to be placed in a sorted (e.g. chronological) order, where the link between a comment and its parent is not necessarily clear from layout, necessitating a visible link. In this case, the parent hentry needs a rel="bookmark" permalink or an id attribute on its root element, so that the child hentry knows where to link to. This solution also allows for an hentry to be in reply to multiple parent hentries, perhaps even hentries on different pages. When "in-reply-to" is found, this wins over "replies". In the spirit of reusing term rather than inventing new ones, both ("replies" and "in-reply-to") are taken from RFC 4685 - Atom Threading Extensions. Example in threaded style, showing only entry titles, contents and replies (i.e. omitting authorship for conciseness):

An Article

Some text.

Comments

A reply.

Reply to reply.

Another reply.

Might be used with the following stylesheet: .replies { margin-left: 3em; padding-left: 0.5em; border-left: 2px solid silver; } .replies .replies { font-size: 90%; } The same comment structure, shown semi-linearly:

An Article

Some text.

Comments

A reply.

Another reply.

Reply to reply.

In reply to: Fred.

The same comment structure, completely linear:

An Article

Some text.

Comments

A reply.

In reply to: article.

Another reply.

In reply to: article.

Reply to reply.

In reply to: Fred.

Thoughts? -- Toby A Inkster From davidjanes at blogmatrix.com Sat Nov 15 05:57:02 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 15 06:20:05 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: Message-ID: <21e523c20811150557peebd3kb04eb01ab2da1386@mail.gmail.com> On Sat, Nov 15, 2008 at 8:28 AM, Toby A Inkster wrote: > OK, I've had a think about this overnight, which is often a good way of > clarifying an issue in ones head. Upon consideration, I think the best > solution is as follows. > > What is the nature of a comment? What makes a piece of text not just a piece > of text, but a comment? I think the answer is that a comment is a (usually > short) reply to something. (The length of a reply can easily be determined > by a byte count if required, so I will ignore this feature of comments.) So > what we need is a method for indicating that one hentry is a reply to > another hentry. > > I propose (or put my vote behind earlier proposals for) two methods and > suggest that *both* be allowed. > > 1. Within the parent hentry, a class="hfeed replies" is used to group all > direct replies to it. The entire replies hfeed must be within the parent > *hentry* (not just within the parent hfeed). This solution suits a threaded > layout, with each level of hfeed perhaps left inset by a few ems - similar > to slashdot. No explicit visible links are required between an hentry and > its parent, as the layout makes the relationships clear. > > 2. An hentry can link to its parent hentry using rel="in-reply-to" (or > perhaps class="in-reply-to"). This is Sarven's proposal. This allows for > comments to be placed in a sorted (e.g. chronological) order, where the link > between a comment and its parent is not necessarily clear from layout, > necessitating a visible link. In this case, the parent hentry needs a > rel="bookmark" permalink or an id attribute on its root element, so that the > child hentry knows where to link to. This solution also allows for an hentry > to be in reply to multiple parent hentries, perhaps even hentries on > different pages. When "in-reply-to" is found, this wins over "replies". > > In the spirit of reusing term rather than inventing new ones, both > ("replies" and "in-reply-to") are taken from RFC 4685 - Atom Threading > Extensions. > > Example in threaded style, showing only entry titles, contents and replies > (i.e. omitting authorship for conciseness): > >
>

An Article

>

Some text.

>
>

Comments

>
>

A reply.

>
>
>

Reply to reply.

>
>
>
>
>

Another reply.

>
>
>
> > Might be used with the following stylesheet: > > .replies > { > margin-left: 3em; > padding-left: 0.5em; > border-left: 2px solid silver; > } > .replies .replies > { > font-size: 90%; > } > > The same comment structure, shown semi-linearly: > >
>

An Article

>

Some text.

>
>

Comments

>
>

A reply.

>
>
>

Another reply.

>
>
>

Reply to reply.

>

> In reply to: > Fred. >

>
>
>
> > The same comment structure, completely linear: > > >
>

An Article

>

Some text.

>
>

Comments

>
>

A reply.

>

> In reply to: > article. >

>
>
>

Another reply.

>

> In reply to: > article. >

>
>
>

Reply to reply.

>

> In reply to: > Fred. >

>
> > > Thoughts? I like the nested replies - i.e. the concept of an Entry Replies element, which could be physically represented as "hfeed replies". I don't see the benefit in the later format, as we can add a Entry Replies wrapper around that whole "

Comments

(all the comments)" section without presentation impact. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From scott at makedatamakesense.com Sat Nov 15 07:24:28 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Sat Nov 15 07:24:36 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811150557peebd3kb04eb01ab2da1386@mail.gmail.com> References: <21e523c20811150557peebd3kb04eb01ab2da1386@mail.gmail.com> Message-ID: <11ED0FBB-4F41-468B-96F0-938230018548@makedatamakesense.com> On [Nov 15], at [ Nov 15] 6:57 , David Janes wrote: > I don't see the benefit in the later format, as we can add a Entry > Replies wrapper around that whole "

Comments

(all the > comments)" section without presentation impact. It seems to me it's not practically useful to know that something is a reply, but rather we need to know to *what* it is a reply in order to solve the problem statement on comments-brainstorming. This example, I think, should be excluded as it makes that impossible: http://www.haloscan.com/comments/empirestatehuman/7424868678376349884/ There's no way to solve the problem statement with that example because a necessary piece of information (the subject of the comment) is missing for both people and machines. And I think we'd see the same problem with relying solely on a class="replies" wrapper: for cross-URL (e.g. "trackback") comments, it would make a critical piece of information (the subject of the comment) inaccessible to machines. That said, perhaps we should focus first on the simpler and common enough scope of comments appearing directly after the subject in the same document, and just be aware that we're not solving the whole problem (and that's okay). -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Sat Nov 15 07:27:10 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 15 07:27:17 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811150557peebd3kb04eb01ab2da1386@mail.gmail.com> References: <21e523c20811150557peebd3kb04eb01ab2da1386@mail.gmail.com> Message-ID: <491EEA4E.6020208@weborganics.co.uk> Hello David, Toby. I am inclined to agree with you both on most points, particularly the in-reply-to thread extension. But I would like to quietly remind you both that the subject is a "comment" (singular) how to nest, group a comments is not a topic of this conversation. That said I am not saying we should not be aware of grouping, just that it is not explicitly part of this problem, Its the simpler problem of "a comment". I have updated a comment schema 1 [1] to try and reflect the points highlighted in this conversation. [1] http://microformats.org/wiki/comment-brainstorming#Schema_I Best wishes -- Martin McEvoy http://weborganics.co.uk/ From csarven at gmail.com Sat Nov 15 07:30:50 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Nov 15 07:30:53 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> References: <491C32E2.4090701@weborganics.co.uk> <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> Message-ID: As Tantek suggested, it would be better to keep our focus on the instance of a comment. If I'm understanding this correctly, it means: what makes this a comment in and of it self? rel="in-reply-to": What makes this hentry (i.e., the comment) a response to another hentry? An hentry with rel="in-reply-to" suggests that it is an entry that is a response to another resource. This outlines a comment instance. It is self implied and it doesn't have the requirement of being part of any markup structure. I believe it would be better to focus on an type of hentry that is a reaction (or a response) to some other hentry as opposed to comments that are usually associated with the main hentry of the page. For instance, a blog post may be a response to another blog post (e.g., technorati's blog reactions). rel="in-reply-to" fits well into these equations because it creates a single instance of a comment, response, reaction or a reply. -Sarven On Thu, Nov 13, 2008 at 5:13 PM, Tantek Celik wrote: > Martin, David Janes, Sarven thanks very much for your good analysis and back/forth discussion of possible approaches to solving the comment(s) problem(s). > > One comment on comment vs comments. > > In general it works better to develop microformats (and properties) to represent a single instance of something (rather than multiple instances), and then use the collection/list/pluralization/aggregation features of the context (whether implicit, like multiple contained/descendant elements, or explicit like in an OL/UL as with XOXO) to represent more than one instance. > > In some cases that collection itself will/canbe considered an instance of something that has its own properties. Hence hfeed and vcalendar in addition to hentry and vevent. But even in those cases it is better to focus on the instance first and then the collection later. > > Tantek > > -----Original Message----- > From: Martin McEvoy > > Date: Thu, 13 Nov 2008 20:58:19 > To: For discussion of new microformats. > Subject: Re: [uf-new] Re: Comment Questions > > > David Janes wrote: >> Hi Martin, >> > Hello David.. >> How does it detach it? You end up with a page that's structured like this: >> >> >> >> My Blog post >> Bla bla bla, I have a blog >> >> >> You are so smart and handsome >> >> >> > >> >> I don't think there's too many blog pages that don't use this implicit >> structure. > Yes having a quick look at the examples I have I would say that you are > correct. > > What the "comment"(singular) problem so to speak is a simpler problem > than "comments"(plural), and really basic it deals with the singular > issue of a comment, (solve the simpler problems first) which only > consists really of a few singular properties such as the author, the > date, the comment the author made and where it is >> My apologies if I'm missing something.... >> > > No need, many people have misunderstood the comment problem hence thats > why this subject has splintered off in so many ways[1][2][3], this > effort will hopefully consolidate this problem(which is really simple[4]). > > [1] http://microformats.org/wiki/comments-formats > [2] http://microformats.org/wiki/mfcomment > [3] http://microformats.org/wiki/hcomment > [4] http://microformats.org/wiki/comment-problem > > > > Thanks > > -- > Martin McEvoy > > http://weborganics.co.uk/ > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From davidjanes at blogmatrix.com Sat Nov 15 07:46:04 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 15 07:46:07 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> Message-ID: <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> On Sat, Nov 15, 2008 at 10:30 AM, Sarven Capadisli wrote: > As Tantek suggested, it would be better to keep our focus on the > instance of a comment. If I'm understanding this correctly, it means: > what makes this a comment in and of it self? > I think that's framing the discussion to achieve a particular answer. Where does this lonely comment exist in the real world? I suggest that the best approach this exactly the same hAtom: - look at the real world examples - find a minimal solution that covers at least 80% of the examples and doesn't require presentation impact - see if that solution can be expanded afterward to cover edge cases & other interesting things (nesting, for example) Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Sat Nov 15 07:58:40 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 15 07:58:47 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> References: <491C38A8.60504@weborganics.co.uk> <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> Message-ID: <491EF1B0.6070300@weborganics.co.uk> David Janes wrote: > On Sat, Nov 15, 2008 at 10:30 AM, Sarven Capadisli wrote: > >> As Tantek suggested, it would be better to keep our focus on the >> instance of a comment. If I'm understanding this correctly, it means: >> what makes this a comment in and of it self? >> >> > > I think that's framing the discussion to achieve a particular answer. > Where does this lonely comment exist in the real world? > > I suggest that the best approach this exactly the same hAtom: > - look at the real world examples > - find a minimal solution that covers at least 80% of the examples and > doesn't require presentation impact > - see if that solution can be expanded afterward to cover edge cases & > other interesting things (nesting, for example) > > Regards, etc... > > I think there is a different discussion concerning "comments" [1] maybe your thoughts need to go there? [http://microformats.org/wiki/comments-formats] Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Sat Nov 15 08:04:08 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 15 08:04:10 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491EF1B0.6070300@weborganics.co.uk> References: <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> Message-ID: <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> On Sat, Nov 15, 2008 at 10:58 AM, Martin McEvoy wrote: > David Janes wrote: >> >> On Sat, Nov 15, 2008 at 10:30 AM, Sarven Capadisli >> wrote: >> >>> >>> As Tantek suggested, it would be better to keep our focus on the >>> instance of a comment. If I'm understanding this correctly, it means: >>> what makes this a comment in and of it self? >>> >>> >> >> I think that's framing the discussion to achieve a particular answer. >> Where does this lonely comment exist in the real world? >> >> I suggest that the best approach this exactly the same hAtom: >> - look at the real world examples >> - find a minimal solution that covers at least 80% of the examples and >> doesn't require presentation impact >> - see if that solution can be expanded afterward to cover edge cases & >> other interesting things (nesting, for example) >> >> Regards, etc... >> >> > > I think there is a different discussion concerning "comments" [1] maybe your > thoughts need to go there? > > [http://microformats.org/wiki/comments-formats] > > Thanks This is not a discussion of formats, it's a discussion of what people do. How can you discuss creating a microformat if you're not discussing what people are doing? -- David Janes Mercenary Programmer http://code.davidjanes.com From csarven at gmail.com Sat Nov 15 08:05:24 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Nov 15 08:05:26 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> References: <491C4E1E.1070801@weborganics.co.uk> <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> Message-ID: On Sat, Nov 15, 2008 at 10:46 AM, David Janes wrote: > On Sat, Nov 15, 2008 at 10:30 AM, Sarven Capadisli wrote: >> As Tantek suggested, it would be better to keep our focus on the >> instance of a comment. If I'm understanding this correctly, it means: >> what makes this a comment in and of it self? >> > > I think that's framing the discussion to achieve a particular answer. > Where does this lonely comment exist in the real world? I wasn't suggesting that it does. It is implied that a comment is a response to something that already exists. -Sarven From martin at weborganics.co.uk Sat Nov 15 08:07:48 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 15 08:07:55 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> References: <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> Message-ID: <491EF3D4.7060708@weborganics.co.uk> David Janes wrote: > On Sat, Nov 15, 2008 at 10:58 AM, Martin McEvoy > wrote: > >> David Janes wrote: >> >>> On Sat, Nov 15, 2008 at 10:30 AM, Sarven Capadisli >>> wrote: >>> >>> >>>> As Tantek suggested, it would be better to keep our focus on the >>>> instance of a comment. If I'm understanding this correctly, it means: >>>> what makes this a comment in and of it self? >>>> >>>> >>>> >>> I think that's framing the discussion to achieve a particular answer. >>> Where does this lonely comment exist in the real world? >>> >>> I suggest that the best approach this exactly the same hAtom: >>> - look at the real world examples >>> - find a minimal solution that covers at least 80% of the examples and >>> doesn't require presentation impact >>> - see if that solution can be expanded afterward to cover edge cases & >>> other interesting things (nesting, for example) >>> >>> Regards, etc... >>> >>> >>> >> I think there is a different discussion concerning "comments" [1] maybe your >> thoughts need to go there? >> >> [http://microformats.org/wiki/comments-formats] >> >> Thanks >> > > This is not a discussion of formats, it's a discussion of what people > do. How can you discuss creating a microformat if you're not > discussing what people are doing? > > I cant answer that David, the discussion needs to be consolidated and re-thought (the same as this discussion was) Thanks -- Martin McEvoy http://weborganics.co.uk/ From scott at makedatamakesense.com Sat Nov 15 08:31:37 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Sat Nov 15 08:31:45 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491EF3D4.7060708@weborganics.co.uk> References: <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> Message-ID: <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> On [Nov 15], at [ Nov 15] 9:07 , Martin McEvoy wrote: >> This is not a discussion of formats, it's a discussion of what people >> do. How can you discuss creating a microformat if you're not >> discussing what people are doing? >> > > I cant answer that David, the discussion needs to be consolidated > and re-thought (the same as this discussion was) I suggest everyone go back and re-examine (and potentially re-state) their proposals in terms of how they address the problem statement for the collected examples. That common ground seems to have been largely lost in this discussion. It's easy to start talking around an assumed definition of something as common as a comment, but it's crucial to stay focused on real world examples. Before proposing markup for nested comments, we should look at examples to see if that's a common pattern. Before proposing markup for links back to the source, we should look at the examples to see if such links commonly exist. Maybe everyone has already done this, but it's hard to tell. Knowing how our own proposals are based in the examples is not enough; for this collaborative effort, we need to explain the connections to everyone else. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Sat Nov 15 12:01:48 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 15 12:02:01 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> References: <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> Message-ID: <491F2AAC.1040305@weborganics.co.uk> Scott Reynen wrote: > On [Nov 15], at [ Nov 15] 9:07 , Martin McEvoy wrote: > >>> This is not a discussion of formats, it's a discussion of what people >>> do. How can you discuss creating a microformat if you're not >>> discussing what people are doing? >>> >> >> I cant answer that David, the discussion needs to be consolidated and >> re-thought (the same as this discussion was) > > > I suggest everyone go back and re-examine (and potentially re-state) > their proposals in terms of how they address the problem statement for > the collected examples. That common ground seems to have been largely > lost in this discussion. It's easy to start talking around an assumed > definition of something as common as a comment, but it's crucial to > stay focused on real world examples. I and Sarven are both staying on topic ie: "a comment" and are just focusing on the "real world" examples > Before proposing markup for nested comments, we should look at > examples to see if that's a common pattern. Before proposing markup > for links back to the source, we should look at the examples to see if > such links commonly exist. Maybe everyone has already done this, but > it's hard to tell. Knowing how our own proposals are based in the > examples is not enough; for this collaborative effort, we need to > explain the connections to everyone else. Please do not make any proposals towards a nested comment, as this is "off topic" the topic is "a comment" (singular) Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Sat Nov 15 12:46:19 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 15 12:46:22 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491F2AAC.1040305@weborganics.co.uk> References: <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> <491F2AAC.1040305@weborganics.co.uk> Message-ID: <21e523c20811151246n435288bcoabc317f2723d23a0@mail.gmail.com> On Sat, Nov 15, 2008 at 3:01 PM, Martin McEvoy wrote: > Scott Reynen wrote: >> >> On [Nov 15], at [ Nov 15] 9:07 , Martin McEvoy wrote: >> >>>> This is not a discussion of formats, it's a discussion of what people >>>> do. How can you discuss creating a microformat if you're not >>>> discussing what people are doing? >>>> >>> >>> I cant answer that David, the discussion needs to be consolidated and >>> re-thought (the same as this discussion was) >> >> >> I suggest everyone go back and re-examine (and potentially re-state) their >> proposals in terms of how they address the problem statement for the >> collected examples. That common ground seems to have been largely lost in >> this discussion. It's easy to start talking around an assumed definition of >> something as common as a comment, but it's crucial to stay focused on real >> world examples. > > I and Sarven are both staying on topic ie: "a comment" and are just focusing > on the "real world" examples > >> Before proposing markup for nested comments, we should look at examples to >> see if that's a common pattern. Before proposing markup for links back to >> the source, we should look at the examples to see if such links commonly >> exist. Maybe everyone has already done this, but it's hard to tell. >> Knowing how our own proposals are based in the examples is not enough; for >> this collaborative effort, we need to explain the connections to everyone >> else. > > Please do not make any proposals towards a nested comment, as this is "off > topic" > > the topic is "a comment" (singular) Well then you don't need to do anything: hAtom - "a microformat for content that can be syndicated, primarily but not exclusively weblog postings" [1] - is sufficient and complete to cover "a comment". If you're interested in showing the relationship between "a comment" and what-is-being-commented-on, I opened every single example in comment-examples [2] and every single one (excepting Haloscan, which seem to be utterly isolated from posting context) uses document structure to show the relationship. None that I noticed had a A.href link that a "rel-in-reply-to" could be hung on to. Regards, etc... [1] http://microformats.org/wiki/hatom [2] http://microformats.org/wiki/comment-examples -- David Janes Mercenary Programmer http://code.davidjanes.com From scott at makedatamakesense.com Sat Nov 15 13:08:15 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Sat Nov 15 13:08:26 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491F2AAC.1040305@weborganics.co.uk> References: <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> <491F2AAC.1040305@weborganics.co.uk> Message-ID: On [Nov 15], at [ Nov 15] 1:01 , Martin McEvoy wrote: > I and Sarven are both staying on topic ie: "a comment" and are just > focusing on the "real world" examples Which real world examples? How do they relate to your proposals? The connections you see are apparently not as obvious to everyone else. Please explain more how you arrived at your proposals. > Please do not make any proposals towards a nested comment, as this > is "off topic" Please explain why it's off topic in terms of the examples and the problem statement. In a group discussion, being on topic doesn't help much if you're unable to get everyone on the same topic. The collected examples and problem statement establish a common basis for discussion. Let's use it. On [Nov 15], at [ Nov 15] 1:46 , David Janes wrote: > I opened every single example in > comment-examples [2] and every single one (excepting Haloscan, which > seem to be utterly isolated from posting context) uses document > structure to show the relationship. None that I noticed had a A.href > link that a "rel-in-reply-to" could be hung on to. This is what I think we need to do more. Even if you still disagree, I hope you can see how David making his argument in terms of the examples makes his points easier for everyone to discuss. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Sat Nov 15 15:06:13 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 15 15:13:09 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> <491F2AAC.1040305@weborganics.co.uk> Message-ID: <491F55E5.7050204@weborganics.co.uk> Scott Reynen wrote: > On [Nov 15], at [ Nov 15] 1:01 , Martin McEvoy wrote: > >> I and Sarven are both staying on topic ie: "a comment" and are just >> focusing on the "real world" examples > > > Which real world examples? How do they relate to your proposals? The > connections you see are apparently not as obvious to everyone else. examples: http://microformats.org/wiki/comment-examples > Please explain more how you arrived at your proposals. http://microformats.org/wiki/comment-examples#Analysis > >> Please do not make any proposals towards a nested comment, as this is >> "off topic" > > Please explain why it's off topic in terms of the examples and the > problem statement. See above.... > In a group discussion, being on topic doesn't help much if you're > unable to get everyone on the same topic. The collected examples and > problem statement establish a common basis for discussion. Let's use it. we are (I hope?)... > > > On [Nov 15], at [ Nov 15] 1:46 , David Janes wrote: > >> I opened every single example in >> comment-examples [2] and every single one (excepting Haloscan, which >> seem to be utterly isolated from posting context) uses document >> structure to show the relationship. None that I noticed had a A.href >> link that a "rel-in-reply-to" could be hung on to. David, 40% of the examples used have a permalink something like this http://someblog.com/post#comment-001 A hash uri reference rel="reply" can be hung on this link because the url tells us two things 1, the origional post, http://someblog.com/post 2, and the location of the comment, comment-001 by defining TWO dereferenceable URI's one using a slash uri scheme http://someblog.com/post => rel="reply" and the other using a hash URI scheme http://someblog.com/post#comment-001 => rel="bookmark" and combining them rel="reply bookmark" This can be used to say that a hAtom entry is a Comment, nothing more is needed, It wouldn't therefore be difficult for any "future" hatom parser to extract just the comments because all it has to do is look for the hentry's that have a rel-reply link, this is (in my view) the simplest option for a comment format, nothing else is needed, and its fairly low on the cognitive load, nesting feeds, this simply is not anything to do with "a comment" sorry. > > > This is what I think we need to do more. Even if you still disagree, > I hope you can see how David making his argument in terms of the > examples makes his points easier for everyone to discuss. ? Thanks > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Sat Nov 15 15:25:32 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 15 15:25:38 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491F55E5.7050204@weborganics.co.uk> References: <491C4E99.6050200@weborganics.co.uk> <21e523c20811130802t36d394b3oa9106028e097a653@mail.gmail.com> <491C86AF.70803@weborganics.co.uk> <21e523c20811131210v7a003914l8d889d87b9899a19@mail.gmail.com> <491C94EB.1050505@weborganics.co.uk> <2020429302-1226614450-cardhu_decombobulator_blackberry.rim.net-2020670555-@bxe346.bisx.prod.on.blackberry> <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> <491F2AAC.1040305@weborganics.co.uk> <491F55E5.7050204@weborganics.co.uk> Message-ID: <491F5A6C.2040803@weborganics.co.uk> Martin McEvoy wrote: > 40% of the examples used have a permalink something like this > > http://someblog.com/post#comment-001 > > A hash uri reference > > rel="reply" can be hung on this link because the url tells us two things > > 1, the origional post, http://someblog.com/post > 2, and the location of the comment, comment-001 > > by defining TWO dereferenceable URI's one using a slash uri scheme > http://someblog.com/post => rel="reply" > and the other using a hash URI scheme > http://someblog.com/post#comment-001 => rel="bookmark" Please visit this link If anyone is having trouble with what a Dereferenceable Uniform Resource Identifier is http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Sat Nov 15 15:48:35 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 15 15:48:39 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <491F5A6C.2040803@weborganics.co.uk> References: <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> <491F2AAC.1040305@weborganics.co.uk> <491F55E5.7050204@weborganics.co.uk> <491F5A6C.2040803@weborganics.co.uk> Message-ID: <21e523c20811151548r7c74e77ep98a35c8653e720b1@mail.gmail.com> On Sat, Nov 15, 2008 at 6:25 PM, Martin McEvoy wrote: > Martin McEvoy wrote: >> >> 40% of the examples used have a permalink something like this >> >> http://someblog.com/post#comment-001 >> >> A hash uri reference >> >> rel="reply" can be hung on this link because the url tells us two things >> >> 1, the origional post, http://someblog.com/post >> 2, and the location of the comment, comment-001 >> >> by defining TWO dereferenceable URI's one using a slash uri scheme >> http://someblog.com/post => rel="reply" >> and the other using a hash URI scheme http://someblog.com/post#comment-001 >> => rel="bookmark" > > Please visit this link If anyone is having trouble with what a > Dereferenceable Uniform Resource Identifier is > > http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable or not, this seems to break the meaning a A.rel [1]: "This attribute describes the relationship from the current document to the anchor specified by the href attribute." 40% isn't a great hit rate either, though I'm actually surprised that number isn't higher. I assume the other 60% are not providing permalinks for comments. Regards, etc... [1] http://www.w3.org/TR/html4/struct/links.html#adef-rel -- David Janes Mercenary Programmer http://code.davidjanes.com From mail at tobyinkster.co.uk Sat Nov 15 13:34:45 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Nov 15 16:04:07 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <982D4FB8-7BF9-42DE-A86F-E22D96D10409@tobyinkster.co.uk> David Janes wrote: > I like the nested replies - i.e. the concept of an Entry Replies > element, which could be physically represented as "hfeed replies". > > I don't see the benefit in the later format The advantage of the flattened formats is that all the comments, regardless of how many levels of nesting are used, remain within the same hfeed. > If you're interested in showing the relationship between "a comment" > and what-is-being-commented-on, I opened every single example in > comment-examples [2] and every single one (excepting Haloscan, which > seem to be utterly isolated from posting context) uses document > structure to show the relationship. None that I noticed had a A.href > link that a "rel-in-reply-to" could be hung on to. Slashdot has links from comments to the "Parent" comment. So does Reddit. Twitter has (off-page) links from responses to the status update they are in response to. Whatsmore, many blog posts themselves are in fact replies to blog posts on other sites. rel="in-reply-to" is also useful for that situation. -- Toby A Inkster From mail at tobyinkster.co.uk Sat Nov 15 13:56:46 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Nov 15 16:24:07 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <7C7A9F17-18D6-4735-A661-2FD69D5D608B@tobyinkster.co.uk> I've put together an experimental implementation of rel=in-reply-to and class=replies. You can try it at: http://srv.buzzword.org.uk/ Here are a few test pages to play with: http://buzzword.org.uk/2008/hatom-threading-1.html http://buzzword.org.uk/2008/hatom-threading-2.html http://buzzword.org.uk/2008/hatom-threading-3.html Example Atom 1.0 output: http://srv.buzzword.org.uk/atom/buzzword.org.uk/2008/hatom- threading-1.html%2523main-feed http://srv.buzzword.org.uk/atom/buzzword.org.uk/2008/hatom- threading-1.html%2523comment-feed-for-article-101 http://srv.buzzword.org.uk/atom/buzzword.org.uk/2008/hatom- threading-1.html%2523comment-feed-for-comment-7501 http://srv.buzzword.org.uk/atom/buzzword.org.uk/2008/hatom- threading-2.html%2523main-feed http://srv.buzzword.org.uk/atom/buzzword.org.uk/2008/hatom- threading-2.html%2523comment-feed-for-article-101 http://srv.buzzword.org.uk/atom/buzzword.org.uk/2008/hatom- threading-3.html Also of potential interest is that Cognition allows hAtom to be output as iCalendar VJOURNAL entries: http://srv.buzzword.org.uk/ics/buzzword.org.uk/2008/hatom- threading-3.html -- Toby A Inkster From csarven at gmail.com Sat Nov 15 18:06:44 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Nov 15 18:06:46 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <7C7A9F17-18D6-4735-A661-2FD69D5D608B@tobyinkster.co.uk> References: <7C7A9F17-18D6-4735-A661-2FD69D5D608B@tobyinkster.co.uk> Message-ID: On Sat, Nov 15, 2008 at 4:56 PM, Toby A Inkster wrote: > I've put together an experimental implementation of rel=in-reply-to and > class=replies. You can try it at: > > http://srv.buzzword.org.uk/ That's great Toby! Having some hands on response is useful. Here is my understanding of rel="in-reply-to" and why that alone is sufficient to indicate that an hentry is a response to another hentry (anywhere). Commonly: * chronological comments (e.g., Wordpress) * threaded comments (e.g., Slashdot) * a blog entry as a reaction to another blog entry (e.g., Technorati) Advantages: * Creates a single instance of a comment [1] * Minimal set of requirements * Applicable to various forms of replies Disadvantages: * @id required In the wild, the requirement of @id is not an issue because it is already widely used in comments [2]. I would like to understand what's the main reason preventing us from taking this route and wrapping this up. Could anyone outline the (dis)advantages of alternative solutions and so we can have an overview and compare where we are at? [1] http://microformats.org/discuss/mail/microformats-new/2008-November/001899.html [2] http://microformats.org/wiki/comment-examples -Sarven From martin at weborganics.co.uk Sat Nov 15 19:08:12 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Nov 15 19:08:19 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811151548r7c74e77ep98a35c8653e720b1@mail.gmail.com> References: <21e523c20811150746r206651b6h290a268a0ee3d78e@mail.gmail.com> <491EF1B0.6070300@weborganics.co.uk> <21e523c20811150804l3b064f25o1d7949a16578f10e@mail.gmail.com> <491EF3D4.7060708@weborganics.co.uk> <8579292A-BD06-4BD1-8407-F3A6F7F0F8B5@makedatamakesense.com> <491F2AAC.1040305@weborganics.co.uk> <491F55E5.7050204@weborganics.co.uk> <491F5A6C.2040803@weborganics.co.uk> <21e523c20811151548r7c74e77ep98a35c8653e720b1@mail.gmail.com> Message-ID: <491F8E9C.90808@weborganics.co.uk> David Janes wrote: > On Sat, Nov 15, 2008 at 6:25 PM, Martin McEvoy wrote: > >> Martin McEvoy wrote: >> >>> 40% of the examples used have a permalink something like this >>> >>> http://someblog.com/post#comment-001 >>> >>> A hash uri reference >>> >>> rel="reply" can be hung on this link because the url tells us two things >>> >>> 1, the origional post, http://someblog.com/post >>> 2, and the location of the comment, comment-001 >>> >>> by defining TWO dereferenceable URI's one using a slash uri scheme >>> http://someblog.com/post => rel="reply" >>> and the other using a hash URI scheme http://someblog.com/post#comment-001 >>> => rel="bookmark" >>> >> Please visit this link If anyone is having trouble with what a >> Dereferenceable Uniform Resource Identifier is >> >> http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier >> > > Dereferenceable or not, this seems to break the meaning a A.rel [1]: > "This attribute describes the relationship from the current document > to the anchor specified by the href attribute." > Absolutely correct David, It should really be rev... a rev-reply link would say that This entry(or page) is a reply to the referenced url..... > 40% isn't a great hit rate either, though I'm actually surprised that > number isn't higher. so was I, but the examples don't just cover blogs. A few more examples added to the existing examples showing a "comment-url" in a comment and I would say 80% is definitely achievable. Some more examples that really need adding to this format are when the entire page is a reply or response to another page, Im sure you have seen pages that begin with something like..."I read this post about..." and a link to the post? > I assume the other 60% are not providing > permalinks for comments. > Correct, although 60% of the examples do use @id which relative url's can be generated from. Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Sat Nov 15 23:54:40 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sat Nov 15 23:54:43 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: References: <7C7A9F17-18D6-4735-A661-2FD69D5D608B@tobyinkster.co.uk> Message-ID: <21e523c20811152354i92f22cdv881d223a0edf77f9@mail.gmail.com> On Sat, Nov 15, 2008 at 9:06 PM, Sarven Capadisli wrote: > On Sat, Nov 15, 2008 at 4:56 PM, Toby A Inkster wrote: >> I've put together an experimental implementation of rel=in-reply-to and >> class=replies. You can try it at: >> >> http://srv.buzzword.org.uk/ > > That's great Toby! Having some hands on response is useful. > > Here is my understanding of rel="in-reply-to" and why that alone is > sufficient to indicate that an hentry is a response to another hentry > (anywhere). Commonly: > * chronological comments (e.g., Wordpress) > * threaded comments (e.g., Slashdot) > * a blog entry as a reaction to another blog entry (e.g., Technorati) > > Advantages: > * Creates a single instance of a comment [1] > * Minimal set of requirements > * Applicable to various forms of replies > > Disadvantages: > * @id required > > In the wild, the requirement of @id is not an issue because it is > already widely used in comments [2]. > > I would like to understand what's the main reason preventing us from > taking this route and wrapping this up. Could anyone outline the > (dis)advantages of alternative solutions and so we can have an > overview and compare where we are at? Because: 1) you give an example of a single site where there's an element that rel="in-reply-to" can be placed on; _every_ _single_ example in [1] (as of my writing this e-mail) does not provide such an element 2) using rel="in-reply-to" A.href URIs where the URI has to be parsed is _semantically incorrect_: it asserts a wrong fact 3) you suddenly have just tossed in "blog replies to other blog posts", despite earlier assertions that were made in other threads that this was about "a comment". Is this now about threading blog posts? Where's all the research on that and alternatives research (BLOCKQUOTE.cite, for example) that this is the best way to go? I'm not sure how much more wrong that can be, from both a semantic point of view and a microformats-process point of view. BTW: Schema II [2] can cover every example listed in [1] except Haloscan (which doesn't provide a pointer to the original post [3] and so is pretty well undoable anyway without presentation changes) and requires _no_ presentation changes and is semantically correct. [1] http://microformats.org/wiki/comment-examples [2] http://microformats.org/wiki/comment-brainstorming#Schema_II [3] http://www.haloscan.com/comments/empirestatehuman/7424868678376349884/ -- David Janes Mercenary Programmer http://code.davidjanes.com From mail at tobyinkster.co.uk Sun Nov 16 03:06:03 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Nov 16 03:06:27 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> So to summarise the discussion so far (and if anyone thinks I've missed out an important point here, feel free to step in) it seems that there are three basic proposals: 1. A special link from the comment to the thing being commented on. 2. A special link from the comment to itself. 3. Nesting an hfeed of comments within the thing being commented on. #1 is Sarven's rel="in-reply-to" proposal and variations on that theme. Advantages of it are that authors may give links to items which are off-page (for example, where a list of comments has been paginated due to extreme length), that a single comment may be made in-reply-to multiple items, and that it's conceptually very similar to Atom's threading extension (RFC 4685). A disadvantage is that it requires a link from one comment to another - such links are only found on a minority of sites in the wild, and whatsmore, they require the thing to which we are linking to have a fragment identifier. #2 is mostly Martin's proposal. Variations on rel="contact bookmark". Advantage of this is that it makes the comment self-contained, and does not introduce any new terms into the microformats lexicon. Disadvantages are that it again requires a visible link: to the comment itself, which is more common than to the thing being commented on (as per #1), but still only found in a minority of cases in the wild; it stretches the limit of XFN's rel="contact" almost to breaking point; it is an unusual use of rel="contact" (it would be more normal to place rel="contact" on the author's url); and it offers no explicit connection between the comment and the thing being commented on. #3, I think, David first brought to this list, with class="hfeed comments", though I had previously proposed class="hfeed replies" to Sarven off-list a month or two ago. Advantages are that although an explicit connection is given by placing the feed of replies within the thing being commented on, it requires no visible link at the comment level, and no fragment identifiers are required for each comment. This is a big advantage as it closely matches current publishing patterns. The disadvantages though are that it only allows a comment to be in reply to one particular thing; and it forces publishers of threaded messages to use one particular layout (the threaded one) rather than, say, a purely chronological order as the latter would lose connections between comments. (The threaded layout is of course the most common in practice, but in general microformats have historically steered away from enforcing any particular layout.) My proposal yesterday, was to allow both #1 *and* #3. This is because #3 is probably the best practical solution and most closely matches current publishing patterns, and #1 although less in tune with current publishing, mitigates both of #3's disadvantages, its advantages slotting nicely into #3's gaps. It is also worth noting that the combination of #1 and #3 is very similar to the solution that the Atom Publishing Format and Protocol working group arrived at with RFC 4685. -- Toby A Inkster From mail at tobyinkster.co.uk Sun Nov 16 03:29:27 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Nov 16 03:39:09 2008 Subject: [uf-new] Re: Comment Questions Message-ID: Sarven Capadisli wrote: > Here is my understanding of rel="in-reply-to" and why that alone is > sufficient to indicate that an hentry is a response to another hentry > (anywhere). Commonly: > * chronological comments (e.g., Wordpress) > * threaded comments (e.g., Slashdot) > * a blog entry as a reaction to another blog entry (e.g., Technorati) > > Advantages: > * Creates a single instance of a comment [1] > * Minimal set of requirements > * Applicable to various forms of replies > > Disadvantages: > * @id required I agree that it is a very simple and flexible solution, but you're leaving out what most people think is the biggest disadvantage: it requires an link from the comment to its parent, which is not very common in the wild. (Yes, there are examples out there, but they're the exception rather than the rule.) Of course, these links could be hidden via CSS. The normal arguments about hidden data becoming out of date are less applicable here, as virtually all comment systems are driven by databases and CMSes. But requiring a link which is going to be hidden by most people seems a bit of an icky route to go down. That's why I propose we adopt this *and* class="replies hfeed". The advantages and disadvantages of each complement each other, like two pieces of a jigsaw puzzle. Authors could choose whichever most closely matched their publishing patterns, or choose to use bits of both. It seems like two patterns will make it more difficult for parsers, but they don't need to conflict if you specify that rel=in-reply-to wins over class="replies hfeed", and what I've found is that once Sarven's proposal is implemented, class="replies hfeed" is very easy to add on. About 16 lines of code in my case. (And eight of those lines contain just a single bracket - my coding style is very generous with line breaks.) -- Toby A Inkster From davidjanes at blogmatrix.com Sun Nov 16 05:00:56 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 05:01:02 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> Message-ID: <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster wrote: > #3, I think, David first brought to this list, with class="hfeed comments", > though I had previously proposed class="hfeed replies" to Sarven off-list a > month or two ago. Advantages are that although an explicit connection is > given by placing the feed of replies within the thing being commented on, it > requires no visible link at the comment level, and no fragment identifiers > are required for each comment. This is a big advantage as it closely matches > current publishing patterns. The disadvantages though are that it only > allows a comment to be in reply to one particular thing; and it forces > publishers of threaded messages to use one particular layout (the threaded > one) rather than, say, a purely chronological order as the latter would lose > connections between comments. (The threaded layout is of course the most > common in practice, but in general microformats have historically steered > away from enforcing any particular layout.) "hfeed comments" has been kicking around since February, off list, and I got the photos to prove it ;-) I'm not sure why you think #3 forces a particular layout. Let me state more formally: * if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A" * an Entry Comments element is identified by using both class names "hfeed comments" That's it: you've got 100% coverage of all examples with no presentation change and no required or implied changes to format needed. -- David Janes Mercenary Programmer http://code.davidjanes.com From davidjanes at blogmatrix.com Sun Nov 16 05:08:55 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 05:08:58 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> Message-ID: <21e523c20811160508o355fc19fs4193dd5ab56688f7@mail.gmail.com> On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster wrote: > #1 is Sarven's rel="in-reply-to" proposal and variations on that theme. > Advantages of it are that authors may give links to items which are off-page > (for example, where a list of comments has been paginated due to extreme > length), that a single comment may be made in-reply-to multiple items, and > that it's conceptually very similar to Atom's threading extension (RFC > 4685). A disadvantage is that it requires a link from one comment to another > - such links are only found on a minority of sites in the wild, and > whatsmore, they require the thing to which we are linking to have a fragment > identifier. Of the examples listed on the Wiki (as of last night), 0% have presentation that could be covered by this pattern. If you're talking about doing URL hacking, then add to the disadvantages that "requires URL hacking" and "asserts semantically wrong facts as being true" Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From davidjanes at blogmatrix.com Sun Nov 16 05:32:26 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 05:32:29 2008 Subject: [uf-new] Comments example #1 Message-ID: <21e523c20811160532o6557c5b2we40dfd85f6d69fae@mail.gmail.com> Just to keep following the process, here's a blogspot comment block [1]. This is a case study in why following the process is good: how do you mark these entries up as an hAtom:Entry using valid XHTML? Regards, etc... [1] http://microformats.org/wiki/comment-examples#Blogspot_.231 -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Sun Nov 16 08:38:46 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 16 08:38:55 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> Message-ID: <49204C96.1030300@weborganics.co.uk> David Janes wrote: > On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster wrote: > > >> #3, I think, David first brought to this list, with class="hfeed comments", >> though I had previously proposed class="hfeed replies" to Sarven off-list a >> month or two ago. Advantages are that although an explicit connection is >> given by placing the feed of replies within the thing being commented on, it >> requires no visible link at the comment level, and no fragment identifiers >> are required for each comment. This is a big advantage as it closely matches >> current publishing patterns. The disadvantages though are that it only >> allows a comment to be in reply to one particular thing; and it forces >> publishers of threaded messages to use one particular layout (the threaded >> one) rather than, say, a purely chronological order as the latter would lose >> connections between comments. (The threaded layout is of course the most >> common in practice, but in general microformats have historically steered >> away from enforcing any particular layout.) >> > > "hfeed comments" has been kicking around since February, off list, and > I got the photos to prove it ;-) > > I'm not sure why you think #3 forces a particular layout. Let me state > more formally: > > * if Entry "B" is in an Entry Comments element of Entry "A", then > Entry "B" is a comment on Entry "A" > * an Entry Comments element is identified by using both class names > "hfeed comments" > > That's it: you've got 100% coverage of all examples with no > presentation change and no required or implied changes to format > needed. > David, you are asserting that all comments are grouped in some way, for this you should use xoxo this will give you the implied structure of a comment list, a fair amount of the examples do imply structure and grouping in this way by using
    ,
      , "hfeed comments" is simply wrong because you are implying that "hfeed" is required? if that's not true you are saying you can just use "comments" does this mean that hfeed is Implied? if that's the case then what is the point of using "hfeed" at all? , lastly all of this doesn't address a comment, it only addresses the grouping of comments not the comment this discussion does not go there (remember?). as for all the assertions you, and others are making "that a comment should be marked up in hatom" is also wrong because certain basic requirements of hAtom do not exist in a comment, an entry-title and a bookmarkable point (only 40% have a permalink), comments made on other things (not blogs) very rarely have a permalink also saying if an entry-title is not present "make something up" is false semantics, you are saying that something exists when it quite clearly doesn't I tried to get the conversation about a comment going again because it really is a simple format to build and couldn't understand why a comment format hasn't been addressed yet, now I know why, because some people don't understand what the problem is and have preconceptions of how this should be solved, which should be the simplest way, which is not dumping the whole hAtom format on it, what If I don't want to use hAtom to mark up a comment? I haven't got much choice have I? -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Sun Nov 16 08:46:29 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 16 09:10:11 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <49204C96.1030300@weborganics.co.uk> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> Message-ID: <49204E65.3010907@weborganics.co.uk> Martin McEvoy wrote: > David Janes wrote: >> On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster >> wrote: >> >>> #3, I think, David first brought to this list, with class="hfeed >>> comments", >>> though I had previously proposed class="hfeed replies" to Sarven >>> off-list a >>> month or two ago. Advantages are that although an explicit >>> connection is >>> given by placing the feed of replies within the thing being >>> commented on, it >>> requires no visible link at the comment level, and no fragment >>> identifiers >>> are required for each comment. This is a big advantage as it closely >>> matches >>> current publishing patterns. The disadvantages though are that it only >>> allows a comment to be in reply to one particular thing; and it forces >>> publishers of threaded messages to use one particular layout (the >>> threaded >>> one) rather than, say, a purely chronological order as the latter >>> would lose >>> connections between comments. (The threaded layout is of course the >>> most >>> common in practice, but in general microformats have historically >>> steered >>> away from enforcing any particular layout.) >> >> "hfeed comments" has been kicking around since February, off list, and >> I got the photos to prove it ;-) >> >> I'm not sure why you think #3 forces a particular layout. Let me state >> more formally: >> >> * if Entry "B" is in an Entry Comments element of Entry "A", then >> Entry "B" is a comment on Entry "A" >> * an Entry Comments element is identified by using both class names >> "hfeed comments" >> >> That's it: you've got 100% coverage of all examples with no >> presentation change and no required or implied changes to format >> needed. > David, you are asserting that all comments are grouped in some way, > for this you should use xoxo this will give you the implied structure > of a comment list, a fair amount of the examples do imply structure > and grouping in this way by using
        ,
          , > > "hfeed comments" is simply wrong because you are implying that "hfeed" > is required? if that's not true you are saying you can just use > "comments" does this mean that hfeed is Implied? if that's the case > then what is the point of using "hfeed" at all? , lastly all of this > doesn't address a comment, it only addresses the grouping of comments > not the comment this discussion does not go there (remember?). > > as for all the assertions you, and others are making "that a comment > should be marked up in hatom" is also wrong because certain basic > requirements of hAtom do not exist in a comment, an entry-title and a > bookmarkable point (only 40% have a permalink), comments made on other > things (not blogs) very rarely have a permalink also saying if an > entry-title is not present "make something up" is false semantics, you > are saying that something exists when it quite clearly doesn't > > I tried to get the conversation about a comment going again because it > really is a simple format to build and couldn't understand why a > comment format hasn't been addressed yet, now I know why, because some > people don't understand what the problem is and have preconceptions of > how this should be solved, which should be the simplest way, which is > not dumping the whole hAtom format on it, what If I don't want to use > hAtom to mark up a comment? I haven't got much choice have I? > Another Point David... Please change your selected examples[1] so that they only include a single comment ie:
        1. chase Says:
          October 21st, 2006 at 5:25 pm

          hurry, hurry, hurry ?

          2. This will keep tis discussion on track and NOT get distracted with grouping comments (that should be up to the author dont you think?) [1] http://microformats.org/wiki/comment-examples#Selected_Examples Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Sun Nov 16 09:26:30 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 09:26:33 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <49204C96.1030300@weborganics.co.uk> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> Message-ID: <21e523c20811160926m531b9e67j12a1bb332aae5b86@mail.gmail.com> On Sun, Nov 16, 2008 at 11:38 AM, Martin McEvoy wrote: > David Janes wrote: >> >> On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster >> wrote: >> >> >>> >>> #3, I think, David first brought to this list, with class="hfeed >>> comments", >>> though I had previously proposed class="hfeed replies" to Sarven off-list >>> a >>> month or two ago. Advantages are that although an explicit connection is >>> given by placing the feed of replies within the thing being commented on, >>> it >>> requires no visible link at the comment level, and no fragment >>> identifiers >>> are required for each comment. This is a big advantage as it closely >>> matches >>> current publishing patterns. The disadvantages though are that it only >>> allows a comment to be in reply to one particular thing; and it forces >>> publishers of threaded messages to use one particular layout (the >>> threaded >>> one) rather than, say, a purely chronological order as the latter would >>> lose >>> connections between comments. (The threaded layout is of course the most >>> common in practice, but in general microformats have historically steered >>> away from enforcing any particular layout.) >>> >> >> "hfeed comments" has been kicking around since February, off list, and >> I got the photos to prove it ;-) >> >> I'm not sure why you think #3 forces a particular layout. Let me state >> more formally: >> >> * if Entry "B" is in an Entry Comments element of Entry "A", then >> Entry "B" is a comment on Entry "A" >> * an Entry Comments element is identified by using both class names >> "hfeed comments" >> >> That's it: you've got 100% coverage of all examples with no >> presentation change and no required or implied changes to format >> needed. >> > > David, you are asserting that all comments are grouped in some way, for this > you should use xoxo this will give you the implied structure of a comment > list, a fair amount of the examples do imply structure and grouping in this > way by using
            ,
              , Did you actually go quantify this?: _Maybe that is how it should be done_. Since there's no analysis of the examples except how it will justify rel="in-reply-to", we don't know. > "hfeed comments" is simply wrong because you are implying that "hfeed" is > required? if that's not true you are saying you can just use "comments" > does this mean that hfeed is Implied? if that's the case then what is the > point of using "hfeed" at all? , lastly all of this doesn't address a > comment, it only addresses the grouping of comments not the comment this > discussion does not go there (remember?). I don't even know where to start addressing this paragraph: it doesn't seem to correspond to anything I've written. In _every single example shown comments appear grouped togther_. The argument being made is "we get to ignore this because then rel="in-reply-to" looks kinda pointless" > > as for all the assertions you, and others are making "that a comment should > be marked up in hatom" is also wrong because certain basic requirements of > hAtom do not exist in a comment, an entry-title and a bookmarkable point > (only 40% have a permalink), comments made on other things (not blogs) very > rarely have a permalink also saying if an entry-title is not present "make > something up" is false semantics, you are saying that something exists when > it quite clearly doesn't hAtom has very clear rules for how things get "made up": that's the difference between a physical and logical model. "Making titles up" is __exactly what happens in the real world on Atom feeds in the real world corresponding to comments__. It might be inconvenient or ugly or "oh god" but _that's how people do it_. > I tried to get the conversation about a comment going again because it > really is a simple format to build and couldn't understand why a comment > format hasn't been addressed yet, now I know why, because some people don't > understand what the problem is and have preconceptions of how this should be > solved, which should be the simplest way, which is not dumping the whole > hAtom format on it, what If I don't want to use hAtom to mark up a comment? > I haven't got much choice have I? If you want to mark up comments with microformats, using microformats is your only choice. If you want to use microformats, then you have to use the process, i.e. in particular: - actually look how comments are being done - look at how existing microformats can fit the the solution The proposed rel="in-reply-to" solution that requires 60% of comment makers to change _presentation_, requires the other 40% to add semantically incorrect markup (which BTW no rel="in-reply-to" proponents have bother to address yet) and ignores all the existing microformats work so far. -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Sun Nov 16 10:54:56 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 16 10:55:05 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811160926m531b9e67j12a1bb332aae5b86@mail.gmail.com> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> <21e523c20811160926m531b9e67j12a1bb332aae5b86@mail.gmail.com> Message-ID: <49206C80.1090001@weborganics.co.uk> David Janes wrote: > On Sun, Nov 16, 2008 at 11:38 AM, Martin McEvoy > wrote: > >> David Janes wrote: >> >>> On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster >>> wrote: >>> >>> >>> >>>> #3, I think, David first brought to this list, with class="hfeed >>>> comments", >>>> though I had previously proposed class="hfeed replies" to Sarven off-list >>>> a >>>> month or two ago. Advantages are that although an explicit connection is >>>> given by placing the feed of replies within the thing being commented on, >>>> it >>>> requires no visible link at the comment level, and no fragment >>>> identifiers >>>> are required for each comment. This is a big advantage as it closely >>>> matches >>>> current publishing patterns. The disadvantages though are that it only >>>> allows a comment to be in reply to one particular thing; and it forces >>>> publishers of threaded messages to use one particular layout (the >>>> threaded >>>> one) rather than, say, a purely chronological order as the latter would >>>> lose >>>> connections between comments. (The threaded layout is of course the most >>>> common in practice, but in general microformats have historically steered >>>> away from enforcing any particular layout.) >>>> >>>> >>> "hfeed comments" has been kicking around since February, off list, and >>> I got the photos to prove it ;-) >>> >>> I'm not sure why you think #3 forces a particular layout. Let me state >>> more formally: >>> >>> * if Entry "B" is in an Entry Comments element of Entry "A", then >>> Entry "B" is a comment on Entry "A" >>> * an Entry Comments element is identified by using both class names >>> "hfeed comments" >>> >>> That's it: you've got 100% coverage of all examples with no >>> presentation change and no required or implied changes to format >>> needed. >>> >>> >> David, you are asserting that all comments are grouped in some way, for this >> you should use xoxo this will give you the implied structure of a comment >> list, a fair amount of the examples do imply structure and grouping in this >> way by using
                ,
                  , >> > > Did you actually go quantify this?: _Maybe that is how it should be > done_. Since there's no analysis of the examples except how it will > justify rel="in-reply-to", we don't know. > > The same as your FALSE assertions that all comments are feeds how do you assert that? I have not seen a single comment that looks like a feeed in-reply-to is the popular approach supported by Sarven, Toby, and myself, the suggested term is rel="in-reply-to", which I dont like just rel="reply" will do, I have also Asserted that rel="reply" can be defined as saying that The "reply" element is used to indicate that an entry is a response to another resource. thats all nothing more.... >> "hfeed comments" is simply wrong because you are implying that "hfeed" is >> required? if that's not true you are saying you can just use "comments" >> does this mean that hfeed is Implied? if that's the case then what is the >> point of using "hfeed" at all? , lastly all of this doesn't address a >> comment, it only addresses the grouping of comments not the comment this >> discussion does not go there (remember?). >> > > I don't even know where to start addressing this paragraph: it doesn't > seem to correspond to anything I've written. In _every single example > shown comments appear grouped togther_. The argument being made is "we > get to ignore this because then rel="in-reply-to" looks kinda > pointless" > Infact this whole discussion is kinda pointless dont you think David? because You are talking about thing that don't concern a comment > >> as for all the assertions you, and others are making "that a comment should >> be marked up in hatom" is also wrong because certain basic requirements of >> hAtom do not exist in a comment, an entry-title and a bookmarkable point >> (only 40% have a permalink), comments made on other things (not blogs) very >> rarely have a permalink also saying if an entry-title is not present "make >> something up" is false semantics, you are saying that something exists when >> it quite clearly doesn't >> > > hAtom has very clear rules for how things get "made up": that's the > difference between a physical and logical model. ?... > "Making titles up" is > __exactly what happens in the real world on Atom feeds in the real > world corresponding to comments__. It might be inconvenient or ugly or > "oh god" but _that's how people do it_. > > What by marking up a title element in a comment and leaving it empty, or putting a note in there saying Make something UP, Is that really how people do it? Show me the evidence David (and I dont mean a feed example, I mean actual markup of a comment)... >> I tried to get the conversation about a comment going again because it >> really is a simple format to build and couldn't understand why a comment >> format hasn't been addressed yet, now I know why, because some people don't >> understand what the problem is and have preconceptions of how this should be >> solved, which should be the simplest way, which is not dumping the whole >> hAtom format on it, what If I don't want to use hAtom to mark up a comment? >> I haven't got much choice have I? >> > > If you want to mark up comments with microformats, using microformats > is your only choice. If you want to use microformats, then you have to > use the process, i.e. in particular: > ... > - actually look how comments are being done > - look at how existing microformats can fit the the solution > I suggest you do the same David > The proposed rel="in-reply-to" solution that requires 60% of comment > makers to change _presentation_, requires the other 40% to add > semantically incorrect markup (which BTW no rel="in-reply-to" > proponents have bother to address yet) and ignores all the existing > microformats work so far. > So you don't Like rel-reply, Its too complex for you?, Fair enough, but at least make a counter proposal that doesn't involve using a sledgehammer to bang in a nail so far a comment is made up of only 4 properties * author (name)100% * comment (text) 100% * published (date) 100% * author-url (href) 92% How do those four properties fit into the hAtom scheme of things, do you see a feed element? Last thing David you still have not re-formatted your Selected examples[1]? to just display information about a comment(like the rest of the examples do), would you like me to do it for you? [1] http://microformats.org/wiki/comment-examples#Selected_Examples Thanks. -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Sun Nov 16 09:27:29 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 11:02:27 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <49204E65.3010907@weborganics.co.uk> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> <49204E65.3010907@weborganics.co.uk> Message-ID: <21e523c20811160927u70e2b76pd07ac3172e187592@mail.gmail.com> On Sun, Nov 16, 2008 at 11:46 AM, Martin McEvoy wrote: > Martin McEvoy wrote: >> >> David Janes wrote: >>> >>> On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster >>> wrote: >>> >>>> #3, I think, David first brought to this list, with class="hfeed >>>> comments", >>>> though I had previously proposed class="hfeed replies" to Sarven >>>> off-list a >>>> month or two ago. Advantages are that although an explicit connection is >>>> given by placing the feed of replies within the thing being commented >>>> on, it >>>> requires no visible link at the comment level, and no fragment >>>> identifiers >>>> are required for each comment. This is a big advantage as it closely >>>> matches >>>> current publishing patterns. The disadvantages though are that it only >>>> allows a comment to be in reply to one particular thing; and it forces >>>> publishers of threaded messages to use one particular layout (the >>>> threaded >>>> one) rather than, say, a purely chronological order as the latter would >>>> lose >>>> connections between comments. (The threaded layout is of course the most >>>> common in practice, but in general microformats have historically >>>> steered >>>> away from enforcing any particular layout.) >>> >>> "hfeed comments" has been kicking around since February, off list, and >>> I got the photos to prove it ;-) >>> >>> I'm not sure why you think #3 forces a particular layout. Let me state >>> more formally: >>> >>> * if Entry "B" is in an Entry Comments element of Entry "A", then >>> Entry "B" is a comment on Entry "A" >>> * an Entry Comments element is identified by using both class names >>> "hfeed comments" >>> >>> That's it: you've got 100% coverage of all examples with no >>> presentation change and no required or implied changes to format >>> needed. >> >> David, you are asserting that all comments are grouped in some way, for >> this you should use xoxo this will give you the implied structure of a >> comment list, a fair amount of the examples do imply structure and grouping >> in this way by using
                    ,
                      , >> >> "hfeed comments" is simply wrong because you are implying that "hfeed" is >> required? if that's not true you are saying you can just use "comments" does >> this mean that hfeed is Implied? if that's the case then what is the point >> of using "hfeed" at all? , lastly all of this doesn't address a comment, it >> only addresses the grouping of comments not the comment this discussion does >> not go there (remember?). >> >> as for all the assertions you, and others are making "that a comment >> should be marked up in hatom" is also wrong because certain basic >> requirements of hAtom do not exist in a comment, an entry-title and a >> bookmarkable point (only 40% have a permalink), comments made on other >> things (not blogs) very rarely have a permalink also saying if an >> entry-title is not present "make something up" is false semantics, you are >> saying that something exists when it quite clearly doesn't >> >> I tried to get the conversation about a comment going again because it >> really is a simple format to build and couldn't understand why a comment >> format hasn't been addressed yet, now I know why, because some people don't >> understand what the problem is and have preconceptions of how this should be >> solved, which should be the simplest way, which is not dumping the whole >> hAtom format on it, what If I don't want to use hAtom to mark up a comment? >> I haven't got much choice have I? >> > Another Point David... > > Please change your selected examples[1] so that they only include a single > comment ie: > >
                    1. > chase Says: >
                      > > October 21st, 2006 at 5:25 pm > >

                      hurry, hurry, hurry ?

                      >
                      2. > > This will keep tis discussion on track and NOT get distracted with grouping > comments (that should be up to the author dont you think?) > > [1] http://microformats.org/wiki/comment-examples#Selected_Examples This has reached the point of insanity: __this is what is in the examples__. You don't get to pretend that you get to mark up one comment but not the one next to it. You're trying to frame the discussion to shoehorn a pre-made solution idea (rel=in-reply-to) as a microformat. This makes as much sense as writing a microformats for comments that contain the letter "q" but not the letter "u". -- David Janes Mercenary Programmer http://code.davidjanes.com From davidjanes at blogmatrix.com Sun Nov 16 11:09:38 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 11:09:40 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <49206C80.1090001@weborganics.co.uk> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> <21e523c20811160926m531b9e67j12a1bb332aae5b86@mail.gmail.com> <49206C80.1090001@weborganics.co.uk> Message-ID: <21e523c20811161109m744140c0yaab35e815aa111eb@mail.gmail.com> On Sun, Nov 16, 2008 at 1:54 PM, Martin McEvoy wrote: > > Last thing David you still have not re-formatted your Selected examples[1]? > to just display information about a comment(like the rest of the examples > do), would you like me to do it for you? > Sure, why don't you? Go do some process stuff - document examples in detail, see how they map into existing microformats, _see how the pages themselves indicate that certain parts of the pages are comments_, how the pages would have to be marked up to implement your strawman. Then make a proposal. -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Sun Nov 16 11:19:02 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 16 11:19:14 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811161109m744140c0yaab35e815aa111eb@mail.gmail.com> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> <21e523c20811160926m531b9e67j12a1bb332aae5b86@mail.gmail.com> <49206C80.1090001@weborganics.co.uk> <21e523c20811161109m744140c0yaab35e815aa111eb@mail.gmail.com> Message-ID: <49207226.7090308@weborganics.co.uk> David Janes wrote: > On Sun, Nov 16, 2008 at 1:54 PM, Martin McEvoy wrote: > > >> Last thing David you still have not re-formatted your Selected examples[1]? >> to just display information about a comment(like the rest of the examples >> do), would you like me to do it for you? >> >> > > Sure, why don't you? Thank you I will.... > Go do some process stuff - document examples in > detail, see how they map into existing microformats, _see how the > pages themselves indicate that certain parts of the pages are > comments_, how the pages would have to be marked up to implement your > strawman. > > Then make a proposal. > I already did that, what do you think, that I came out with a proposal from "thin air", Maybe YOU should try doing the same before you assert your proposals, But first understand the questions > > -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Sun Nov 16 11:21:22 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Nov 16 11:21:31 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811160927u70e2b76pd07ac3172e187592@mail.gmail.com> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> <49204E65.3010907@weborganics.co.uk> <21e523c20811160927u70e2b76pd07ac3172e187592@mail.gmail.com> Message-ID: <492072B2.6080104@weborganics.co.uk> David Janes wrote: > This has reached the point of insanity: > you brought it to this point David by not fully understanding the problem we are all supposed to be trying to solve. -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Sun Nov 16 11:54:25 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 11:54:28 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <49207226.7090308@weborganics.co.uk> References: <1E64318F-ADFB-48FF-9C42-4085A5953832@tobyinkster.co.uk> <21e523c20811160500n33a9b79fn11d4bdf9cd2f40fb@mail.gmail.com> <49204C96.1030300@weborganics.co.uk> <21e523c20811160926m531b9e67j12a1bb332aae5b86@mail.gmail.com> <49206C80.1090001@weborganics.co.uk> <21e523c20811161109m744140c0yaab35e815aa111eb@mail.gmail.com> <49207226.7090308@weborganics.co.uk> Message-ID: <21e523c20811161154n589ac2edm87f5811d85e8db5e@mail.gmail.com> On Sun, Nov 16, 2008 at 2:19 PM, Martin McEvoy wrote: > > I already did that, what do you think, that I came out with a proposal from > "thin air", Maybe YOU should try doing the same before you assert your > proposals, But first understand the questions Where is: - examples how comments currently "in-the-wild" indicate their parentage? - examples of the impact proposed changes modify existing markup? Here's the "comment problem" [1] as stated on the Wiki: | Shortform: How do you track blog comments you've made? | | Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog? | | How can you do this in a way that can be programically represented, ingested into some kind of datastore, searched or aggregated? In case you're missing where the "feed" is, here's the definition of feed [2] - it's a bucket for containing entries, further discussed here [3]. Given that _every single example_ has that bucket, I'm not sure why you think it's critical to ignore it, even given the problem statement. [1] http://microformats.org/wiki/comment-problem [2] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 [3] http://www.atomenabled.org/developers/syndication/#requiredFeedElements -- David Janes Mercenary Programmer http://code.davidjanes.com From mail at tobyinkster.co.uk Sun Nov 16 13:33:44 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Nov 16 13:34:04 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <4A6A5853-A9FE-4D0F-9EC7-6EE767193F4D@tobyinkster.co.uk> David Janes wrote: > I'm not sure why you think #3 forces a particular layout. Imagine the following comments: - Comment A to the main article at 1:00 pm. - Comment B to the main article at 2:00 pm. - Comment C in reply to comment A at 3:00 pm. - Comment D in reply to comment B at 4:00 pm. Use of class="hfeed replies" forces the comments to be placed in ACBD order: C is a reply to A so it needs to be nested within a feed nested within A; B cannot come between them. This means that the comments cannot be layed out chronologically. -- Toby A Inkster From davidjanes at blogmatrix.com Sun Nov 16 14:02:21 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 14:02:24 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <4A6A5853-A9FE-4D0F-9EC7-6EE767193F4D@tobyinkster.co.uk> References: <4A6A5853-A9FE-4D0F-9EC7-6EE767193F4D@tobyinkster.co.uk> Message-ID: <21e523c20811161402r5967f94ai2d80508b1e38641e@mail.gmail.com> On Sun, Nov 16, 2008 at 4:33 PM, Toby A Inkster wrote: > David Janes wrote: > >> I'm not sure why you think #3 forces a particular layout. > > Imagine the following comments: > > - Comment A to the main article at 1:00 pm. > - Comment B to the main article at 2:00 pm. > - Comment C in reply to comment A at 3:00 pm. > - Comment D in reply to comment B at 4:00 pm. > > Use of class="hfeed replies" forces the comments to be placed in ACBD order: > C is a reply to A so it needs to be nested within a feed nested within A; B > cannot come between them. This means that the comments cannot be layed out > chronologically. Sorry, I don't see this .... You can put ... around comments, independent of ordering or nesting. To spell it out explicitly, e.g. and assuming EntryComments is physicalized using "hfeed comments"
                      ... this is the blog post ...
                      ... the comments in hentrys whatever order ...
                      Regards, etc... David -- David Janes Mercenary Programmer http://code.davidjanes.com From scott at makedatamakesense.com Sun Nov 16 14:22:09 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Nov 16 14:22:33 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <4A6A5853-A9FE-4D0F-9EC7-6EE767193F4D@tobyinkster.co.uk> References: <4A6A5853-A9FE-4D0F-9EC7-6EE767193F4D@tobyinkster.co.uk> Message-ID: <64686A35-F900-4A47-8616-AAF5AE9011BD@makedatamakesense.com> On [Nov 16], at [ Nov 16] 2:33 , Toby A Inkster wrote: > Imagine the following comments: > > - Comment A to the main article at 1:00 pm. > - Comment B to the main article at 2:00 pm. > - Comment C in reply to comment A at 3:00 pm. > - Comment D in reply to comment B at 4:00 pm. Where did you see this on the web? I don't doubt such comments actually exist, but hypothetical examples prove a waste of everyone's time. This whole thread reminds me of the blind men and the elephant story [1]. Since everyone else seems certain they know what a comment typically looks like, please assume I don't, and provide the URLs of real world examples I would need to understand your points. [1] http://www.noogenesis.com/pineapple/blind_men_elephant.html -- Scott Reynen MakeDataMakeSense.com From csarven at gmail.com Sun Nov 16 14:56:11 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sun Nov 16 14:56:15 2008 Subject: [uf-new] Comments proposals Message-ID: Okay, so, here is my brain dump: David makes a valid point; we should put more focus back on the existing examples in the wild. I would like to get more insight from you (community) on why grabbing the URI out of rel="in-reply-to" is semantically incorrect as David mentioned [1]. Isn't this the case for all @rel values? Martin brought up a while back whether if anyElement in atom:content includes atom:feed. I couldn't get to the bottom of this either so I've tested this [2] and it does seem to be valid according to the Atom validator (if I didn't make a mistake) [3] and if the validator is accurate. However, the nested feed (type=application/atom+xml) appears to be lost when I gave it a go in Firefox, Opera, IE7, and Google Reader. If anyone could elaborate on their findings or interpretations, that would be great. Toby did mention that it is not allowed (even though possible to parse but doesn't hang on to the nested relationship currently) [4] and multiple hfeeds is a no go as far as the current definition goes in the Wiki [5] Doesn't this mean that we can't nest an hentry inside of another hentry? If we go this route we may need to change the hfeed property slightly. Am I missing something here? Where do we stand on this? Perhaps this is something we can look further into but a rel="replies" which point to the comments container may be useful (which then points to separate hentrys).
                      Although it works well for chronological comments, doesn't work too well for threaded comments. On a similar note, doing "hentry comment" together [6] works fine for chronological comments but not threaded. It was this case that led me into investigating Atom's in-reply-to. But now I understand and agree that it reflects a minor representation of comments out there as far as having an anchor with rel="in-reply-to". Clearly, our main problem is threaded comments. We are on the same page here right? As far as marking up the Blogpost #1 [7] example David mentioned with hAtom, I'm not sure where to begin or if it is even possible (i.e., without altering the structure). I do feel a bit uneasy about using rel="in-reply-to" after David's comments, however, how do we go at threaded comments without a) breaking the (h)Atom model (as long as we are clear on this and can nest entries, I'm fine) and b) using a URI to point back to the parent ? So, where the heck are we? One solution may be that we drop hentry in comments and if class="comment" is found, interpret it like a regular hentry. This would mean that class="comment" is like class="hentry" and used only in context of comments. A little confusion: would it still mean that we can't nest comments if we follow the hAtom format? Any way, an example: (optional) (optional) With this approach, we probably don't need rel="in-reply-to", but, it can be a useful extension. Of course, we can totally avoid using hentry and come up with something else but I don't feel that is the right approach here as this was already investigated [8]. However, I do think we need different perspectives at this point from the rest of the community to shed some light into the situation and so we can borrow some ideas or come up with new ones. [1] http://microformats.org/discuss/mail/microformats-new/2008-November/001942.html (Second point) [2] http://www.csarven.ca/labs/atom/test.atom [3] http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fwww.csarven.ca%2Flabs%2Fatom%2Ftest.atom [4] http://microformats.org/discuss/mail/microformats-new/2008-November/001917.html [5] http://microformats.org/wiki/hatom-cheatsheet [6] http://microformats.org/wiki/comment-brainstorming#Feedback [7] http://microformats.org/wiki/comment-examples#Blogspot_.231 [8] http://intertwingly.net/wiki/pie/CommentsAreEntries -Sarven From mail at tobyinkster.co.uk Sun Nov 16 15:03:39 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Nov 16 15:04:18 2008 Subject: [uf-new] Re: Comment Questions Message-ID: David Janes wrote: > On Sun, Nov 16, 2008 at 4:33 PM, Toby A Inkster tobyinkster.co.uk> wrote: > > David Janes wrote: > > > >> I'm not sure why you think #3 forces a particular layout. > > > > Imagine the following comments: > > > > - Comment A to the main article at 1:00 pm. > > - Comment B to the main article at 2:00 pm. > > - Comment C in reply to comment A at 3:00 pm. > > - Comment D in reply to comment B at 4:00 pm. > > > > Use of class="hfeed replies" forces the comments to be placed in > ACBD order: > > C is a reply to A so it needs to be nested within a feed nested > within A; B > > cannot come between them. This means that the comments cannot be > layed out > > chronologically. > > Sorry, I don't see this .... You can put > ... around comments, independent of > ordering or nesting. To spell it out explicitly, e.g. and assuming > EntryComments is physicalized using "hfeed comments"
                      ... this is the blog post ...

                      A

                      1:00 pm

                      B

                      2:00 pm

                      C

                      3:00 pm

                      D

                      4:00 pm
                      Now the problem is: how do we explicitly markup that C is a reply to A, and D is a reply to B? Without taking them out of chronological order! That is the use case for rel="in-reply-to". That's why I suggest allowing both class="hfeed replies" and rel="in- reply-to". The former takes care of the most simple case, but the latter is required for more complex threading. -- Toby A Inkster From mail at tobyinkster.co.uk Sun Nov 16 14:57:07 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Nov 16 15:04:29 2008 Subject: [uf-new] Re: Comment Questions Message-ID: <04F60D73-642F-4806-96DC-3091E53DEFA9@tobyinkster.co.uk> Scott Reynen wrote: > On [Nov 16], at [ Nov 16] 2:33 , Toby A Inkster wrote: > > > Imagine the following comments: > > > > - Comment A to the main article at 1:00 pm. > > - Comment B to the main article at 2:00 pm. > > - Comment C in reply to comment A at 3:00 pm. > > - Comment D in reply to comment B at 4:00 pm. > > Where did you see this on the web? I've updated the comments-examples page and redone the analysis for the existing pages, as some features such as pagination links, nested reply structures were not examined in the first run round, but can be found on many of the pages. 16% of pages with comments use explicit, visible links from comments to the thing being commented on. Off the web, in the more general case, Usenet and mailing lists are the kind of place where multiple threaded conversations are interleaved and may be chronologically intermingled. That is why Usenet and e-mail messages typically include in-reply-to headers - to figure out what a message is in reply to, as it is usually not the preceding message in a chronological sense. -- Toby A Inkster From davidjanes at blogmatrix.com Sun Nov 16 15:33:40 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 15:33:42 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <04F60D73-642F-4806-96DC-3091E53DEFA9@tobyinkster.co.uk> References: <04F60D73-642F-4806-96DC-3091E53DEFA9@tobyinkster.co.uk> Message-ID: <21e523c20811161533r159ecacegac4f9e10d58a60b6@mail.gmail.com> On Sun, Nov 16, 2008 at 5:57 PM, Toby A Inkster wrote: > Scott Reynen wrote: > >> On [Nov 16], at [ Nov 16] 2:33 , Toby A Inkster wrote: >> >> > Imagine the following comments: >> > >> > - Comment A to the main article at 1:00 pm. >> > - Comment B to the main article at 2:00 pm. >> > - Comment C in reply to comment A at 3:00 pm. >> > - Comment D in reply to comment B at 4:00 pm. >> >> Where did you see this on the web? > > I've updated the comments-examples page and redone the analysis for the > existing pages, as some features such as pagination links, nested reply > structures were not examined in the first run round, but can be found on > many of the pages. 16% of pages with comments use explicit, visible links > from comments to the thing being commented on. > > Off the web, in the more general case, Usenet and mailing lists are the kind > of place where multiple threaded conversations are interleaved and may be > chronologically intermingled. That is why Usenet and e-mail messages > typically include in-reply-to headers - to figure out what a message is in > reply to, as it is usually not the preceding message in a chronological > sense. This a reply to your previous example enumerated A-B-C-D example also. OK, but now we're not talking about "a comment" or "comments" any more. I'm totally cool with saying "let's discuss distributed threading", but then let's actually explicitly do that -- but I expect the scope of that is _much_ larger. This is actually one of my smell-test issues with rel=in-reply-to ... it looks like something much more substantial is trying to be brought in through the back door without case justification. As per the example, as Scott mentioned, it would be better if this was illuminated by real-world examples. All the sites that, off-the-cuff, remember ever showing "comment-x is a reply to comment-y" show this with nested structure. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From davidjanes at blogmatrix.com Sun Nov 16 17:01:23 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 17:01:25 2008 Subject: [uf-new] Comments proposals - the issue of rel="in-reply-to" Message-ID: <21e523c20811161701p26c2fd2fs5e475bd5ca3be51b@mail.gmail.com> I'm splitting Sarven's brain dump into multiple responses (with difference subject lines) On Sun, Nov 16, 2008 at 5:56 PM, Sarven Capadisli wrote: > Okay, so, here is my brain dump: > > David makes a valid point; we should put more focus back on the > existing examples in the wild. > > I would like to get more insight from you (community) on why grabbing > the URI out of rel="in-reply-to" is semantically incorrect as David > mentioned [1]. Isn't this the case for all @rel values? There are two cases here that have to be considered independently. In both cases, consider a blog post A identified by URL-A, and a comment B (on A) identified by URL-B. = Case 1 = We add to B:                       my parent This semantically correct, but 0% of the examples given on the Wiki have elements that you can add this to (though Slashdot has been mentioned in the mailing list). I.e. this has presentation impact and thus becomes un-microformatty because: - it is prescriptive - it doesn't follow examples in the wild = Case 2 = B has an existing hyperlink : this comment This happens in 40% of comments in the examples. It has been posited that if URL-B is substantially similar to URL-A -- i.e. URL-B differs by adding "#ID" to URL-A -- then we can do this in B this comment or as we'd see this "in the real world": this comment and that we can say, by fiat, that when we see A.rel="in-reply-to" we strip the #ID to get the real URL that the relationship is talking about (i.e. URL-A, not URL-B). Now, I have large objections to hacking URLs into pieces to understand them better, but I'll let that slide unless this debate gets even more details. My primary objection is that this does not work because it is contrary to the HTML definition of "rel" [1]: "This attribute describes the relationship from the current document to the anchor specified by the href attribute." The current document, in the microformats context, is the comment in question - that's a Rubicon that's long since been crossed. The anchor specified by the href _is the comment itself_. So A.rel is asserting an incorrect fact, that the comment is it's own parent! Also note that once you start down this road, how do you deal with nested comments, all of which have #ID tags! And then we still have to add this markup to 60% of comments! = Summary = Using rel="in-reply-to" either: - is prescriptive, requiring markup to be added to almost all comments systems, OR - requires URL hacking that: -- still is prescriptive/presentational in 60% of cases -- doesn't work in nested cases, if that's a design goal! -- asserts incorrect facts, according to the definition of A.rel Regards, etc... [1] http://www.w3.org/TR/html4/struct/links.html#adef-rel -- David Janes Mercenary Programmer http://code.davidjanes.com From davidjanes at blogmatrix.com Sun Nov 16 17:10:38 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 17:10:40 2008 Subject: [uf-new] Comments proposals In-Reply-To: References: Message-ID: <21e523c20811161710sf51f9f1qf09c110695d0b138@mail.gmail.com> Response #2 On Sun, Nov 16, 2008 at 5:56 PM, Sarven Capadisli wrote: > Martin brought up a while back whether if anyElement in atom:content > includes atom:feed. I couldn't get to the bottom of this either so > I've tested this [2] and it does seem to be valid according to the > Atom validator (if I didn't make a mistake) [3] and if the validator > is accurate. However, the nested feed (type=application/atom+xml) > appears to be lost when I gave it a go in Firefox, Opera, IE7, and > Google Reader. If anyone could elaborate on their findings or > interpretations, that would be great. Toby did mention that it is not > allowed (even though possible to parse but doesn't hang on to the > nested relationship currently) [4] and multiple hfeeds is a no go as > far as the current definition goes in the Wiki [5] Doesn't this mean > that we can't nest an hentry inside of another hentry? If we go this > route we may need to change the hfeed property slightly. Am I missing > something here? Where do we stand on this? *We* decide how HTML marked up with hAtom maps into Atom. The fact that we can nest an Entry Feed in an Entry _does not_ imply that such a structure has some sort of direct meaning in Atom: it is simply something that's happening in HTML world. Note that this is an inherently good point, passim discussions when we created hAtom that we'd not disallow nesting of Entry Feed; but we decided at the time not to give it "meaning" Note that your link "[5]" points to the the cheatsheet, not the hAtom spec: hAtom does not preclude nesting of Entry Feed [1]. Regards, etc... [1] http://microformats.org/wiki/hatom#Feed "[5]" http://microformats.org/wiki/hatom-cheatsheet -- David Janes Mercenary Programmer http://code.davidjanes.com From davidjanes at blogmatrix.com Sun Nov 16 17:18:30 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Nov 16 17:18:32 2008 Subject: [uf-new] Comments proposals - threaded comments Message-ID: <21e523c20811161718p4bdd65c0wd64d3cf762a2beea@mail.gmail.com> On Sun, Nov 16, 2008 at 5:56 PM, Sarven Capadisli wrote: > Although it works well for chronological comments, doesn't work too > well for threaded comments. > > On a similar note, doing "hentry comment" together [6] works fine for > chronological comments but not threaded. It was this case that led me > into investigating Atom's in-reply-to. But now I understand and agree > that it reflects a minor representation of comments out there as far > as having an anchor with rel="in-reply-to". I certainly don't think "hentry comment" is a great idea, though I've seen this in the wild (Niall Kennedy's blog). > Clearly, our main problem is threaded comments. We are on the same > page here right? Well, I'm not sure. Is it in scope or not? I've certainly taken flak today for saying we have to take into account multiple comments - because that's how they occur in the wild - saying we have talk about "a comment". In either case, I'm still quite comfortable that the "Schema #2" proposal -- baring of course _lots more investigation_ - covers it, for the real-world examples shown. Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From mail at tobyinkster.co.uk Sun Nov 16 22:51:23 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Nov 16 22:51:43 2008 Subject: [uf-new] Comments proposals - the issue of rel="in-reply-to" Message-ID: David Janes wrote: > In both cases, consider a blog post A identified by URL-A, and a > comment B (on A) identified by URL-B. > > We add to B: > my parent > > This semantically correct, but 0% of the examples given on the Wiki > have elements that you can add this to (though Slashdot has been > mentioned in the mailing list). Actually, that is not the case. I have gone through the list of examples and found that two of the example pages don't actually contain any comments, and two of the example URIs point to different portions of the same page (only one portion of which contains comments). Thus I have eliminated three pages from the list of examples and replaced them with slashdot, reddit and twitter to keep the list a nice round 25 pages long (easier for percentage calculations). Also, I've gone back over the examples Martin analysed, looking for interesting things he might have missed. For example, four of his examples include pagination links (comments are spread over multiple pages), but he didn't note that down. Two of the examples I added also include pagination links, bringing the total to 24%. On analysis, 16% of the examples *do* contain links suitable for hanging a rel="in-reply-to" link onto. > this has presentation impact and thus becomes un-microformatty > because: > - it is prescriptive My proposal (that authors are free to use class="hfeed replies" and/ or rel="in-reply-to") is non-prescriptive. Authors have a choice over whether to use rel="in-reply-to". If they don't want to, class="hfeed replies" will often be sufficient. > B has an existing hyperlink : > this comment > > This happens in 40% of comments in the examples. It has been posited > that if URL-B is substantially similar to URL-A -- i.e. URL-B differs > by adding "#ID" to URL-A -- then we can do this in B > > this comment > > or as we'd see this "in the real world": > > this comment This is a horrible idea and I don't think anybody has suggested we go down this route. Clearly a blog comment cannot be in reply to itself. Now I understand what you meant when you were going on about URL hacking. But you seem to be arguing against a monstrous idea that nobody had proposed. Take a look at what I'm actually proposing, and it's nothing anywhere near as ugly as what you're arguing against there. My proposal is that all three of the following are allowed: http://buzzword.org.uk/2008/hatom-threading-1.html (class="hfeed replies") http://buzzword.org.uk/2008/hatom-threading-2.html (both) http://buzzword.org.uk/2008/hatom-threading-3.html (rel="in-reply-to") Authors may pick whichever is most appropriate for their page. -- Toby A Inkster From davidjanes at blogmatrix.com Mon Nov 17 00:43:00 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Nov 17 00:43:08 2008 Subject: [uf-new] Comments proposals - the issue of rel="in-reply-to" In-Reply-To: References: Message-ID: <21e523c20811170043n536cc902m73a7694e2ddc9da3@mail.gmail.com> On Mon, Nov 17, 2008 at 1:51 AM, Toby A Inkster wrote: > David Janes wrote: > >> In both cases, consider a blog post A identified by URL-A, and a >> comment B (on A) identified by URL-B. >> >> We add to B: >> my parent >> >> This semantically correct, but 0% of the examples given on the Wiki >> have elements that you can add this to (though Slashdot has been >> mentioned in the mailing list). > > Actually, that is not the case. > > I have gone through the list of examples and found that two of the example > pages don't actually contain any comments, and two of the example URIs point > to different portions of the same page (only one portion of which contains > comments). Thus I have eliminated three pages from the list of examples and > replaced them with slashdot, reddit and twitter to keep the list a nice > round 25 pages long (easier for percentage calculations). > > Also, I've gone back over the examples Martin analysed, looking for > interesting things he might have missed. For example, four of his examples > include pagination links (comments are spread over multiple pages), but he > didn't note that down. Two of the examples I added also include pagination > links, bringing the total to 24%. > > On analysis, 16% of the examples *do* contain links suitable for hanging a > rel="in-reply-to" link onto. I wrote something that was factually correct, you then went and changed the wiki to make what I said wrong. On all my previous posts I had put in "as of this writing" for exactly this issue. Don't take this as me objecting to adding new things to the list, just having it asserted that I wrote something wrong when I didn't. Comments on the addition Twitter below. > >> this has presentation impact and thus becomes un-microformatty because: >> - it is prescriptive > > My proposal (that authors are free to use class="hfeed replies" and/or > rel="in-reply-to") is non-prescriptive. Authors have a choice over whether > to use rel="in-reply-to". If they don't want to, class="hfeed replies" will > often be sufficient. Just because they have a choice doesn't make it non-prescriptive. 16% (as of 2008-11-17T3:00:05-400) is not a particular large number, and as I'll point out below, it's lower than that. > >> B has an existing hyperlink : >> this comment >> >> This happens in 40% of comments in the examples. It has been posited >> that if URL-B is substantially similar to URL-A -- i.e. URL-B differs >> by adding "#ID" to URL-A -- then we can do this in B >> >> this comment >> >> or as we'd see this "in the real world": >> >> this comment > > This is a horrible idea and I don't think anybody has suggested we go down > this route. Clearly a blog comment cannot be in reply to itself. Now I > understand what you meant when you were going on about URL hacking. But you > seem to be arguing against a monstrous idea that nobody had proposed. Actually, that is exactly what is being proposed here [1][2]. > > Take a look at what I'm actually proposing, and it's nothing anywhere near > as ugly as what you're arguing against there. > > My proposal is that all three of the following are allowed: > > http://buzzword.org.uk/2008/hatom-threading-1.html (class="hfeed replies") > http://buzzword.org.uk/2008/hatom-threading-2.html (both) > http://buzzword.org.uk/2008/hatom-threading-3.html (rel="in-reply-to") > > Authors may pick whichever is most appropriate for their page. Either method has to stand independently on its own merits or fall alone on their issues. Why wouldn't this be the case? That 16% of comment systems (as of 2008-11-17T3:15:12-400) on the Wiki could also be marked up using rel="in-reply-to" doesn't make a compelling case to me *especially* since it's introducing seems opening a much wider issue that should be fully discussed and analyzed first [3]. In fact, it's not even 16%: Twitter is _not_ a commenting system and certainly not a commenting system as outlined by the problem statement [4]. Reply posts are not comments. Every post on Twitter is a free standing post, some of which may be replies to other posts. This is pretty well exactly the way people do threaded blogging discussions, except twitter "makes up" the fact that you meant a post to be a reply when you use @name [5] rather than allowing you to explicitly enter a link. If we want to make a microformat for replies, well, let's do that, but let's make it a "reply" or "thread" microformat and make sure we cover all the examples where that happens. As mentioned in a previous post, I believe that the Entry Comments proposal is sufficient and complete to cover all the examples given, except noting Twitter above. That's not saying "wrap it as a microformat", just that doing all the Wikiwork to complete the proposal is is probably worthwhile. Regards, etc.. [1] http://microformats.org/discuss/mail/microformats-new/2008-November/001935.html [2] http://microformats.org/discuss/mail/microformats-new/2008-November/001936.html [3] discussed in several e-mails were the general blog threading problem and USENET at least once [4] http://microformats.org/wiki/comment-problem - note the lack of the words "reply", "technorati", "trackback", etc. [5] as far as I can tell -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Mon Nov 17 06:42:07 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 17 06:42:14 2008 Subject: [uf-new] Comments proposals In-Reply-To: <21e523c20811170043n536cc902m73a7694e2ddc9da3@mail.gmail.com> References: <21e523c20811170043n536cc902m73a7694e2ddc9da3@mail.gmail.com> Message-ID: <492182BF.3090807@weborganics.co.uk> Hello all, @toby thank you for re-analysing the comment examples, you have done a good job Here Is my proposal for a comment microformat. On the whole to mark up comment's it is possible to use hAtom terms the only addition I would add is a rel-reply link. example and definition are as follows example: link to this * reply[1] (comment-link) 60% o By adding "rel-reply" the author is indicating that the page http://someblog/post#comment-001 is a reply for the referring page (see example). 1. reply MAY be defined as rfc4685 section 3[2] in-reply-to atom threading extension. 2. A parser MAY use the referring page http://someblog/post as the value of in-reply-to [1] http://microformats.org/wiki/comment-brainstorming#Proposal [2] http://tools.ietf.org/html/rfc4685#section-3 Thanks -- Martin McEvoy http://weborganics.co.uk/ From jason.karns at gmail.com Mon Nov 17 07:13:56 2008 From: jason.karns at gmail.com (Jason Karns) Date: Mon Nov 17 07:13:59 2008 Subject: [uf-new] Re: Comment Questions In-Reply-To: <21e523c20811161533r159ecacegac4f9e10d58a60b6@mail.gmail.com> References: <04F60D73-642F-4806-96DC-3091E53DEFA9@tobyinkster.co.uk> <21e523c20811161533r159ecacegac4f9e10d58a60b6@mail.gmail.com> Message-ID: <1005d65f0811170713t1d8a5863m8b77efbce647443a@mail.gmail.com> On Sun, Nov 16, 2008 at 6:33 PM, David Janes wrote: > As per the example, as Scott mentioned, it would be better if this was > illuminated by real-world examples. All the sites that, off-the-cuff, > remember ever showing "comment-x is a reply to comment-y" show this > with nested structure. > All Gawker media blogs have support both a threaded comments view and a chronological comments view. When in chronological order, the @user reply text is linked to the comment being replied-to. When in threaded view the @user text is still linked to the 'replied-to' comment, but the replies are nested under the comment to which they reply. In this manner, both in threaded and chronological views, the replies contain links (usernames) to the original comment. This is true for all of Gawker media blogs which include (but is not limited to) Gawker, Defamer, Jezebel, Gizmodo, Jalopnik, Kotaku, Deadspin, Valleywag, Lifehacker, Consumerist, and io9. Stats for traffic and number of comments [1]: 274 million pageviews, 22 million global unique visitors (13 million US) 1.58 million comments across the network in the third quarter of 2008 - (17,639 comments posted each day) 1 - http://advertising.gawker.com/5057679/traffic-and-commenting-at-highest-levels-ever ~ Jason Karns From davidjanes at blogmatrix.com Mon Nov 17 07:17:53 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Nov 17 07:17:55 2008 Subject: [uf-new] Comments proposals In-Reply-To: <492182BF.3090807@weborganics.co.uk> References: <21e523c20811170043n536cc902m73a7694e2ddc9da3@mail.gmail.com> <492182BF.3090807@weborganics.co.uk> Message-ID: <21e523c20811170717w142db9e0w641f447273777632@mail.gmail.com> On Mon, Nov 17, 2008 at 9:42 AM, Martin McEvoy wrote: > Hello all, > > @toby thank you for re-analysing the comment examples, you have done a good > job > > Here Is my proposal for a comment microformat. > > On the whole to mark up comment's it is possible to use hAtom terms the only > addition I would add is a rel-reply link. example and definition are as > follows > > example: link to > this > > * reply[1] (comment-link) 60% > o By adding "rel-reply" the author is indicating that the page > http://someblog/post#comment-001 is a reply for the referring page (see > example). > 1. reply MAY be defined as rfc4685 section 3[2] in-reply-to atom > threading extension. > 2. A parser MAY use the referring page http://someblog/post as the value > of in-reply-to > > [1] http://microformats.org/wiki/comment-brainstorming#Proposal > [2] http://tools.ietf.org/html/rfc4685#section-3 This is semantic nonsense. See my previous comments and Toby's from last night, i.e. "this [parsing the URL] is a horrible idea" -- David Janes Mercenary Programmer http://code.davidjanes.com From mail at tobyinkster.co.uk Mon Nov 17 08:15:17 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Nov 17 08:15:59 2008 Subject: [uf-new] Comments proposals Message-ID: David Janes wrote: > On Mon, Nov 17, 2008 at 9:42 AM, Martin McEvoy weborganics.co.uk> wrote: > > * reply[1] (comment-link) 60% > > o By adding "rel-reply" the author is indicating that the page > > http://someblog/post#comment-001 is a reply for the referring > page (see > > example). Martin, you've explained this a few times on the list, and I have to admit, this is the first time I've "got it". Yes, this does make sense as a solution. rel="reply bookmark" would be even better. I still think rel="in-reply-to" has merit - the cases where it overtakes the other solutions in usefulness are of limited number, but they do exist. (See Jason's recent message.) In some situations, admittedly many which go beyond the "normal" definitions of comment systems, the other solutions just don't cut it. If this is going beyond the scope of the comments project, then perhaps it is the scope that is too narrow? > This is semantic nonsense. See my previous comments and Toby's from > last night, i.e. "this [parsing the URL] is a horrible idea" David, I really think you must be misunderstanding some of these proposals. From my reading, none of them have required the URL to be parsed. Where Martin says that this: link to this Means: has a reply The former URL hasn't been gleaned by chopping up the latter URL -- the former URL is the full URL of the page on which the link has been found. Similarly, rel="in-reply-to" doesn't require any chopping up of URLs. The following link: Means: has a reply The former URL is the target of the in-reply-to link, and the latter URL is the permalink of the hentry that the in-reply-to link is sitting inside. No URL hacking in either case. -- Toby A Inkster From davidjanes at blogmatrix.com Mon Nov 17 08:33:38 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Nov 17 08:33:41 2008 Subject: [uf-new] Comments proposals In-Reply-To: References: Message-ID: <21e523c20811170833u7218b0b7w9b696651010b5b9a@mail.gmail.com> On Mon, Nov 17, 2008 at 11:15 AM, Toby A Inkster wrote: > David Janes wrote: > >> On Mon, Nov 17, 2008 at 9:42 AM, Martin McEvoy > weborganics.co.uk> wrote: >> >> * reply[1] (comment-link) 60% >> > o By adding "rel-reply" the author is indicating that the page >> > http://someblog/post#comment-001 is a reply for the referring page (see >> > example). > > > Martin, you've explained this a few times on the list, and I have to admit, > this is the first time I've "got it". Yes, this does make sense as a > solution. rel="reply bookmark" would be even better. I withdraw my comment about semantic nonsense and apologize to Martin for my tone. I thought this was the in-reply-to proposal. However, how is the different than saying a comment is marked up as "hentry comment", which will work on close to 100% [1] of the exemplars instead of 60%? Regards, etc... [1] there are universal issues for all proposals with blogger DL lists -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Mon Nov 17 12:39:31 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 17 13:33:48 2008 Subject: [uf-new] Comments proposals In-Reply-To: References: Message-ID: <4921D683.6050706@weborganics.co.uk> Hello Toby Toby A Inkster wrote: > David Janes wrote: > >> On Mon, Nov 17, 2008 at 9:42 AM, Martin McEvoy > weborganics.co.uk> wrote: >> >> * reply[1] (comment-link) 60% >> > o By adding "rel-reply" the author is indicating that the page >> > http://someblog/post#comment-001 is a reply for the referring page >> (see >> > example). > > > Martin, you've explained this a few times on the list, and I have to > admit, this is the first time I've "got it". Yes, this does make sense > as a solution. rel="reply bookmark" would be even better. Thank you toby, yes it would make sense to add rel-bookmark too, I just wanted to highlight the proposal ;-) > > I still think rel="in-reply-to" has merit - the cases where it > overtakes the other solutions in usefulness are of limited number, but > they do exist. (See Jason's recent message.) In some situations, > admittedly many which go beyond the "normal" definitions of comment > systems, the other solutions just don't cut it. If this is going > beyond the scope of the comments project, then perhaps it is the scope > that is too narrow? I am beginning to think that the scope is a little narrow, but I think that (for now) If we (the community) attempt to solve the simplest problem(just a comment), in a way that everyone can agree on, then that will give us room to expand the scope a little more to include other situations. [some edits...] > > link to this > > Means: > > has a reply I couldn't have put it better myself, I will add the above to the proposal if that is ok? Thanks -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Mon Nov 17 13:49:05 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Nov 17 13:49:08 2008 Subject: [uf-new] Comments proposals In-Reply-To: <4921D683.6050706@weborganics.co.uk> References: <4921D683.6050706@weborganics.co.uk> Message-ID: <21e523c20811171349p449a9560o8f63daef240466c@mail.gmail.com> On Mon, Nov 17, 2008 at 3:39 PM, Martin McEvoy wrote: > I am beginning to think that the scope is a little narrow, but I think that > (for now) If we (the community) attempt to solve the simplest problem(just a > comment), in a way that everyone can agree on, then that will give us room > to expand the scope a little more to include other situations. Ignoring the fact that comments occur in groups is contrary to the problem statement [1] [1] http://microformats.org/wiki/comment-problem -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Mon Nov 17 12:56:48 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 17 14:22:55 2008 Subject: [uf-new] Comments proposals In-Reply-To: <21e523c20811170833u7218b0b7w9b696651010b5b9a@mail.gmail.com> References: <21e523c20811170833u7218b0b7w9b696651010b5b9a@mail.gmail.com> Message-ID: <4921DA90.2020101@weborganics.co.uk> Hello David David Janes wrote: > On Mon, Nov 17, 2008 at 11:15 AM, Toby A Inkster wrote: > >> David Janes wrote: >> >> >>> On Mon, Nov 17, 2008 at 9:42 AM, Martin McEvoy >> weborganics.co.uk> wrote: >>> >>> * reply[1] (comment-link) 60% >>> >>>> o By adding "rel-reply" the author is indicating that the page >>>> http://someblog/post#comment-001 is a reply for the referring page (see >>>> example). >>>> >> Martin, you've explained this a few times on the list, and I have to admit, >> this is the first time I've "got it". Yes, this does make sense as a >> solution. rel="reply bookmark" would be even better. >> > > I withdraw my comment about semantic nonsense and apologize to Martin > for my tone. I thought this was the in-reply-to proposal. > No worries David we all say things we shouldn't discourse in any discussion like this usually ends in progress in my view ;-) > However, how is the different than saying a comment is marked up as > "hentry comment", which will work on close to 100% [1] of the > exemplars instead of 60%? > I have always liked "hentry comment" I made a fleeting attempt to propose it in an earlier message, http://microformats.org/discuss/mail/microformats-new/2008-November/001889.html I still think this is the best way to go, but it got lost in the following discussion ;-) > Regards, etc... > > [1] there are universal issues for all proposals with blogger DL lists > > Best wishes -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Mon Nov 17 14:29:09 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Nov 17 14:29:12 2008 Subject: [uf-new] Comments proposals In-Reply-To: <4921DA90.2020101@weborganics.co.uk> References: <21e523c20811170833u7218b0b7w9b696651010b5b9a@mail.gmail.com> <4921DA90.2020101@weborganics.co.uk> Message-ID: <21e523c20811171429s609db9few788c01e8dca06277@mail.gmail.com> On Mon, Nov 17, 2008 at 3:56 PM, Martin McEvoy wrote: > Hello David > > David Janes wrote: >> >> On Mon, Nov 17, 2008 at 11:15 AM, Toby A Inkster >> wrote: >> >>> >>> David Janes wrote: >>> >>> >>>> >>>> On Mon, Nov 17, 2008 at 9:42 AM, Martin McEvoy >>> weborganics.co.uk> wrote: >>>> >>>> * reply[1] (comment-link) 60% >>>> >>>>> >>>>> o By adding "rel-reply" the author is indicating that the page >>>>> http://someblog/post#comment-001 is a reply for the referring page (see >>>>> example). >>>>> >>> >>> Martin, you've explained this a few times on the list, and I have to >>> admit, >>> this is the first time I've "got it". Yes, this does make sense as a >>> solution. rel="reply bookmark" would be even better. >>> >> >> I withdraw my comment about semantic nonsense and apologize to Martin >> for my tone. I thought this was the in-reply-to proposal. >> > > No worries David we all say things we shouldn't discourse in any discussion > like this usually ends in progress in my view ;-) > >> However, how is the different than saying a comment is marked up as >> "hentry comment", which will work on close to 100% [1] of the >> exemplars instead of 60%? >> > > I have always liked "hentry comment" I made a fleeting attempt to propose it > in an earlier message, > > http://microformats.org/discuss/mail/microformats-new/2008-November/001889.html > > I still think this is the best way to go, but it got lost in the following > discussion ;-) > >> Regards, etc... >> >> [1] there are universal issues for all proposals with blogger DL lists >> >> > > Best wishes > I think every issue relating to every proposal has been thrashed through here. Can I make a consolidation list on the Wiki of each individual proposal (e.g. add "comment" to the "hentry") and we can add our plus/minus points? Regards, etc... -- David Janes Mercenary Programmer http://code.davidjanes.com From martin at weborganics.co.uk Mon Nov 17 15:27:25 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 17 15:27:34 2008 Subject: [uf-new] Comments proposals In-Reply-To: <21e523c20811171349p449a9560o8f63daef240466c@mail.gmail.com> References: <4921D683.6050706@weborganics.co.uk> <21e523c20811171349p449a9560o8f63daef240466c@mail.gmail.com> Message-ID: <4921FDDD.107@weborganics.co.uk> David Janes wrote: > On Mon, Nov 17, 2008 at 3:39 PM, Martin McEvoy wrote: > >> I am beginning to think that the scope is a little narrow, but I think that >> (for now) If we (the community) attempt to solve the simplest problem(just a >> comment), in a way that everyone can agree on, then that will give us room >> to expand the scope a little more to include other situations. >> > > Ignoring the fact that comments occur in groups is contrary to the > problem statement [1] > > [1] http://microformats.org/wiki/comment-problem > > David I dont see how? by solving the simplest problem, in the simplest way has always been a priority when developing a new microformat (I don't need to tell you that). I will explain.... Problem. How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog? How can you do this in a way that can be pragmatically represented, then ingested into some kind of datastore, searched or aggregated? Desirable behaviours * I post a comment to a blog, and want to monitor responses made to my comment - but I don't want to have to visit the website regularly to manually check for reponses * I want to monitor all comments published to my blog in my newsreader * I want to be able to be alerted when someone posts a comment to my favourite blog ALL the above can be solved using hAtom eg:
                      [the article entry]
                      [first comment]
                      [second comment]
                      If the Article and the comments are syndicated as a single feed, say to Google reader the user will be able to monitor comments made on article they were reading because the "updated" values will change as comments are made and will appear in chronological order, the last updated comment will be the most recent comment made on that article, the feed reader can update the page automatically and notify the user when a new comment is made. I don't believe that the topic(the article), and the discussion(the comments) should be separated or be presented in different feeds, because some people(like me) subscribe to lots of feeds, If my feeds JUST contained comments after a while I would need to be refreshed about what the topic was an have to re-visit the page just to be brought up to speed with what is going on, It would be better if I could just go back to the first entry in my feed an re-read it again, What is an important factor in all this is we shouldn't break the line of conversation, its counter intuitive because It makes a user (possibly) subscribe to two feed instead of one. All the above solves the problem of "a comment" you don't need anything else. The last problem that needs to be resolved is "what if I want to subscribe to just comments?", that came up in our recent discussions. Easy(I would say) just tag the hEntrys in some way to say this is a comment, "hentry comment" is the easiest thing to do by far, you could even use "item hentry" (which is very "microformaty") but I think I would have a hard time explaining that, you could do "hfeed comments" but that has drawbacks, first ALL microformats are Nouns, Singular you would have to describe in in some other way like "comment-list" or something, also the "hfeed" element in hAtom is optional in fact it would be interesting to know how many hAtom authors actually use the hfeed element as it makes no difference if you include it or not, version 0.2 of hatom could really do with dropping it as it seems entirely presentational and confining. There is a small matter of rel="reply" as it seems to have more uses in a more general term, I think there is a good case for rev="reply" for all those web pages you see that start off with... "I read this article on cool site and this is my response...." ...or something along those lines. A rev reply link is ideal in these situations and would say that "this page" has a reply to cool site(http://somecoolsite.com), any way I am sure there is plenty of evidence of behaviour like that enough for a separate proposal, and good discussion about un-grandfathering rev in microformats ;-) Thank you. -- Martin McEvoy http://weborganics.co.uk/ From martin at weborganics.co.uk Mon Nov 17 15:28:40 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Nov 17 15:28:48 2008 Subject: [uf-new] Comments proposals In-Reply-To: <21e523c20811171429s609db9few788c01e8dca06277@mail.gmail.com> References: <21e523c20811170833u7218b0b7w9b696651010b5b9a@mail.gmail.com> <4921DA90.2020101@weborganics.co.uk> <21e523c20811171429s609db9few788c01e8dca06277@mail.gmail.com> Message-ID: <4921FE28.8000909@weborganics.co.uk> David Janes wrote: > On Mon, Nov 17, 2008 at 3:56 PM, Martin McEvoy wrote: > >> Hello David >> >> David Janes wrote: >> >>> On Mon, Nov 17, 2008 at 11:15 AM, Toby A Inkster >>> wrote: >>> >>> >>>> David Janes wrote: >>>> >>>> >>>> >>>>> On Mon, Nov 17, 2008 at 9:42 AM, Martin McEvoy >>>> weborganics.co.uk> wrote: >>>>> >>>>> * reply[1] (comment-link) 60% >>>>> >>>>> >>>>>> o By adding "rel-reply" the author is indicating that the page >>>>>> http://someblog/post#comment-001 is a reply for the referring page (see >>>>>> example). >>>>>> >>>>>> >>>> Martin, you've explained this a few times on the list, and I have to >>>> admit, >>>> this is the first time I've "got it". Yes, this does make sense as a >>>> solution. rel="reply bookmark" would be even better. >>>> >>>> >>> I withdraw my comment about semantic nonsense and apologize to Martin >>> for my tone. I thought this was the in-reply-to proposal. >>> >>> >> No worries David we all say things we shouldn't discourse in any discussion >> like this usually ends in progress in my view ;-) >> >> >>> However, how is the different than saying a comment is marked up as >>> "hentry comment", which will work on close to 100% [1] of the >>> exemplars instead of 60%? >>> >>> >> I have always liked "hentry comment" I made a fleeting attempt to propose it >> in an earlier message, >> >> http://microformats.org/discuss/mail/microformats-new/2008-November/001889.html >> >> I still think this is the best way to go, but it got lost in the following >> discussion ;-) >> >> >>> Regards, etc... >>> >>> [1] there are universal issues for all proposals with blogger DL lists >>> >>> >>> >> Best wishes >> >> > > I think every issue relating to every proposal has been thrashed > through here. Can I make a consolidation list on the Wiki of each > individual proposal (e.g. add "comment" to the "hentry") and we can > add our plus/minus points? > > Regards, etc... > > Yes David Go ahead It will help A LOT Thanks. -- Martin McEvoy http://weborganics.co.uk/ From davidjanes at blogmatrix.com Tue Nov 18 03:55:23 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Nov 18 03:55:26 2008 Subject: [uf-new] Comment consolidation Message-ID: <21e523c20811180355l2850bd60u32abbcbb2cd590b8@mail.gmail.com> I've added a comment consolidation section [1] to capture all the "micro-ideas" we've discussed. I'm sure I've not gotten everything, so feel free (perhaps even obligated) to add ideas or proposals that are still in play to this section, and of course start filling in the sections. [1] http://microformats.org/wiki/comment-brainstorming#Idea_Consolidation -- David Janes Mercenary Programmer http://code.davidjanes.com From ararat01 at hotmail.com Wed Nov 19 19:58:18 2008 From: ararat01 at hotmail.com (Yu val) Date: Wed Nov 19 19:58:23 2008 Subject: [uf-new] hDirectory based on hListing draft and rel-directory In-Reply-To: <200811172229.mAHMTFXk025792@microformats.org> References: <200811172229.mAHMTFXk025792@microformats.org> Message-ID: Hi Guys, Got an idea for a microformat for the web Directories. its an extension of the hList and uses even the rel-directory to pinpoint the parent directory. I have posted my idea to my blog with some examples: http://www.yuvalararat.com/hdirecory-microformat-idea Cheers, Yuval Ararat _________________________________________________________________ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008 From martin at weborganics.co.uk Thu Nov 20 11:44:21 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Nov 20 11:50:07 2008 Subject: [uf-new] Comment consolidation In-Reply-To: <21e523c20811180355l2850bd60u32abbcbb2cd590b8@mail.gmail.com> References: <21e523c20811180355l2850bd60u32abbcbb2cd590b8@mail.gmail.com> Message-ID: <4925BE15.6010701@weborganics.co.uk> David Janes wrote: > I've added a comment consolidation section [1] to capture all the > "micro-ideas" we've discussed. I'm sure I've not gotten everything, so > feel free (perhaps even obligated) to add ideas or proposals that are > still in play to this section, and of course start filling in the > sections. > > [1] http://microformats.org/wiki/comment-brainstorming#Idea_Consolidation > Thank you David this is helpful , I have added my own feedback and votes. Best Wishes -- Martin McEvoy http://weborganics.co.uk/ From paullee at google.com Thu Nov 20 17:41:47 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Thu Nov 20 17:41:51 2008 Subject: [uf-new] hProduct draft schema In-Reply-To: <35832518-FEF9-432B-A695-97FB31A0CD4D@tobyinkster.co.uk> References: <35832518-FEF9-432B-A695-97FB31A0CD4D@tobyinkster.co.uk> Message-ID: Thanks - page updated. On Tue, Nov 4, 2008 at 4:51 PM, Toby A Inkster wrote: > > Jay Myers wrote: > >> Would it make sense to use Paul's suggestion of title: >> title. optional. fn | text > > "title" is forever more in microformats defined as meaning "job title". See the discussion on this list regarding hAudio. It's unfortunate, but it seems that that's the way it has to be. If you want to capture the semantic of the name of something, use "fn" or "summary". > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -- Paul Lee Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 +1 (650) 214-6612