From pwgdarchive at gmail.com Sat Mar 3 07:29:08 2007 From: pwgdarchive at gmail.com (=?ISO-8859-1?Q?Benjamin_Melan=E7on?=) Date: Sat Mar 3 07:29:11 2007 Subject: [uf-new] Book Review microformat - new or how to extend hreview Message-ID: <1406bb8f0703030729q7c97dd78j14fb9f736cd8865f@mail.gmail.com> Hi, I'm looking for how to mark up a book review for the semantic web, or RDF, or microformat, or really anything that has some hope of being a standard and extending the usefulness of my review. I'm posting here because I don't see how to do it with the hreview format in a way that will be a generally recognizable standard. With luck if I can get started with such schema it will be a boon to all mankind through my involvement in the open source content management system Drupal. Or at least a boon to a couple other Drupal users. Thanks! - ben Agaric Design Collective Open Source Web Development http://AgaricDesign.com/ People Who Give a Damn building the infrastructure of a network for everyone http://pwgd.org/ From bewest at gmail.com Sat Mar 3 20:28:00 2007 From: bewest at gmail.com (Benjamin West) Date: Sat Mar 3 20:28:03 2007 Subject: [uf-new] Book Review microformat - new or how to extend hreview In-Reply-To: <1406bb8f0703030729q7c97dd78j14fb9f736cd8865f@mail.gmail.com> References: <1406bb8f0703030729q7c97dd78j14fb9f736cd8865f@mail.gmail.com> Message-ID: <8ad71be30703032028g3619df20rba01bb6279c60b7@mail.gmail.com> On 3/3/07, Benjamin Melan?on wrote: > Hi, I'm looking for how to mark up a book review for the semantic web, > or RDF, or microformat, or really anything that has some hope of being > a standard and extending the usefulness of my review. Great. hreview is perfect for that. > I'm posting here because I don't see how to do it with the hreview > format in a way that will be a generally recognizable standard. I'm not sure what you mean by "generally recognizable standard," but have a look at which is a real example of a book review encoded in hreview. Also check out , which shows you how to do so. Is there any reason this won't work? Generally, we try to actually use pre-existing solutions before making new ones. Thanks, Ben West From marian at sendung.de Tue Mar 6 23:44:14 2007 From: marian at sendung.de (Marian Steinbach) Date: Tue Mar 6 23:44:18 2007 Subject: [uf-new] Microformat for Music Downloads Message-ID: Hello all! Several days ago I wrote to the microformats-discuss list [1] and stated that I was interested in development of a microformat for music downloads. Several replies were sent, but then the discussion was redirected to this list, microformats-new. This is the attempt to restart the thread here and gather input from those who are interested. First of all: To those who replied to the former music thread, please drop in here and make yourself heard again. My own motivation is twofold. I am experimenting with the automatic discovery of audio files, especially music MP3s, on web pages. And I'm not the only one. Several search engines do so. And at least one interesting client application named "Songbird" [2] does this, too. What Songbird, myself, and some other "consumers" of this data want is: Provide users with the correct metadata about the audio files so users know who it's from and whether or not they want the file. In case of music, this usually means an artist, a song title and so on. For audio in general, this could also mean size of the file, duration, bitrate and some other technical parameters like DRM info etc. Currently, what songbird and other applications do in order to aquire that metadata is very expensive both for the client and the server: They read each audio file, at least partially, hoping that it provides useful and valid ID3 tags or OGG comments. Not only that this consumes bandwidth, it also manipulates access statistics for the files -- something that should become more important for music vendors. So a microformat for audio downloads, especially music downloads, could help a lot of people out there enhance the user experience and save time and money. For people like me, who have just joined the microformats discussion, it could be worthwhile to know the status of the current efforts on music, audio and media microformats. There are several pages in the wiki I'd like to point out here: Music-examples http://microformats.org/wiki/music-examples Media-info-examples http://microformats.org/wiki/media-info-examples Media-info-brainstorming http://microformats.org/wiki/media-info-brainstorming I thinks it's also important to set the scope of this effort. While some might want to solve the "media metadata" issue (including images, moving images, audio, etc.) I would like to focus on music downloads here. I'm note even sure if streaming media should be part of the effort. While the vast majority of the downloadable music out there is pop music, also jazz and classical might want to be considered, since there is a difference in decription of meta information (title/artist/album vs. title/musician(s)/composer vs. title/orchestra/conductor/composer/work). I read in earlier music discussions that OGG comments [3] provide a pretty useful model for the description of classical. For now, I hope that this is enough to restart the discussion. Please, drop in your requirements -- again, if you already did so. Thanks! Marian [1] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008848.html [2] http://www.songbirdnest.com/ [3] http://www.xiph.org/vorbis/doc/v-comment.html -- http://musik.sendung.de/ From marian.steinbach at gmail.com Wed Mar 7 00:05:25 2007 From: marian.steinbach at gmail.com (Marian Steinbach) Date: Wed Mar 7 00:05:30 2007 Subject: [uf-new] Microformat for Music Downloads Message-ID: Hello all! Several days ago I wrote to the microformats-discuss list [1] and stated that I was interested in development of a microformat for music downloads. Several replies were sent, but then the discussion was redirected to this list, microformats-new. This is the attempt to restart the thread here and gather input from those who are interested. First of all: To those who replied to the former music thread, please drop in here and make yourself heard again. My own motivation is twofold. I am experimenting with the automatic discovery of audio files, especially music MP3s, on web pages. And I'm not the only one. Several search engines do so. And at least one interesting client application named "Songbird" [2] does this, too. What Songbird, myself, and some other "consumers" of this data want is: Provide users with the correct metadata about the audio files so users know who it's from and whether or not they want the file. In case of music, this usually means an artist, a song title and so on. For audio in general, this could also mean size of the file, duration, bitrate and some other technical parameters like DRM info etc. Currently, what songbird and other applications do in order to aquire that metadata is very expensive both for the client and the server: They read each audio file, at least partially, hoping that it provides useful and valid ID3 tags or OGG comments. Not only that this consumes bandwidth, it also manipulates access statistics for the files -- something that should become more important for music vendors. So a microformat for audio downloads, especially music downloads, could help a lot of people out there enhance the user experience and save time and money. For people like me, who have just joined the microformats discussion, it could be worthwhile to know the status of the current efforts on music, audio and media microformats. There are several pages in the wiki I'd like to point out here: Music-examples http://microformats.org/wiki/music-examples Media-info-examples http://microformats.org/wiki/media-info-examples Media-info-brainstorming http://microformats.org/wiki/media-info-brainstorming I thinks it's also important to set the scope of this effort. While some might want to solve the "media metadata" issue (including images, moving images, audio, etc.) I would like to focus on music downloads here. I'm note even sure if streaming media should be part of the effort. While the vast majority of the downloadable music out there is pop music, also jazz and classical might want to be considered, since there is a difference in decription of meta information (title/artist/album vs. title/musician(s)/composer vs. title/orchestra/conductor/composer/work). I read in earlier music discussions that OGG comments [3] provide a pretty useful model for the description of classical. For now, I hope that this is enough to restart the discussion. Please, drop in your requirements -- again, if you already did so. Thanks! Marian [1] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008848.html [2] http://www.songbirdnest.com/ [3] http://www.xiph.org/vorbis/doc/v-comment.html -- http://musik.sendung.de/ From pwgdarchive at gmail.com Thu Mar 8 14:12:15 2007 From: pwgdarchive at gmail.com (=?ISO-8859-1?Q?Benjamin_Melan=E7on?=) Date: Thu Mar 8 14:12:19 2007 Subject: [uf-new] Book Review microformat - new or how to extend hreview In-Reply-To: <8ad71be30703032028g3619df20rba01bb6279c60b7@mail.gmail.com> References: <1406bb8f0703030729q7c97dd78j14fb9f736cd8865f@mail.gmail.com> <8ad71be30703032028g3619df20rba01bb6279c60b7@mail.gmail.com> Message-ID: <1406bb8f0703081412m6ef70714haa6b086a26cf2800@mail.gmail.com> Hi Ben-- I didn't see your message because I thought it was my own posted to the list-- darn gmail's habit of shortening us to our first names! I found some of these resources after I posted, but I still don't think I have what I need. For instance, the book review module in Drupal (which I would like to improve to have microformat tags) has fields for cover image, publisher, copyright, isbn, # of pages, price, synopsis as well as authors and distinguishing between links for purchase and other links. And, of course, I want to do this in a way that will be the same as other people using hreview for book reviews and that smart web indexing engines can understand (e.g., to allow 'give me all reviews of books by this author published before this date under this number of pages'). Is there a repository and a process for defining standard implementations? Or do I need a 'book' microformat that hreview then refers to? - ben On 3/3/07, Benjamin West wrote: > On 3/3/07, Benjamin Melan?on wrote: > > Hi, I'm looking for how to mark up a book review for the semantic web, > > or RDF, or microformat, or really anything that has some hope of being > > a standard and extending the usefulness of my review. > > Great. hreview is perfect for that. > > > I'm posting here because I don't see how to do it with the hreview > > format in a way that will be a generally recognizable standard. > > I'm not sure what you mean by "generally recognizable standard," but > have a look at > which is a real example of a book review encoded in hreview. Also > check out , which > shows you how to do so. > > Is there any reason this won't work? Generally, we try to actually > use pre-existing solutions before making new ones. > > Thanks, > Ben West > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From bewest at gmail.com Thu Mar 8 14:48:53 2007 From: bewest at gmail.com (Benjamin West) Date: Thu Mar 8 14:48:56 2007 Subject: [uf-new] Book Review microformat - new or how to extend hreview In-Reply-To: <1406bb8f0703081412m6ef70714haa6b086a26cf2800@mail.gmail.com> References: <1406bb8f0703030729q7c97dd78j14fb9f736cd8865f@mail.gmail.com> <8ad71be30703032028g3619df20rba01bb6279c60b7@mail.gmail.com> <1406bb8f0703081412m6ef70714haa6b086a26cf2800@mail.gmail.com> Message-ID: <8ad71be30703081448n913f502jc53cb844359b5f9a@mail.gmail.com> Ben, On 3/8/07, Benjamin Melan?on wrote: > Hi Ben-- I didn't see your message because I thought it was my own > posted to the list-- darn gmail's habit of shortening us to our first > names! No problem :-) > I found some of these resources after I posted, but I still don't > think I have what I need. > > For instance, the book review module in Drupal (which I would like to > improve to have microformat tags) has fields for cover image, > publisher, copyright, isbn, # of pages, price, synopsis as well as > authors and distinguishing between links for purchase and other links. What's missing? > And, of course, I want to do this in a way that will be the same as > other people using hreview for book reviews and that smart web > indexing engines can understand (e.g., to allow 'give me all reviews > of books by this author published before this date under this number > of pages'). > > Is there a repository and a process for defining standard implementations? Implementations aren't standard, only the behaviour of implementations. > Or do I need a 'book' microformat that hreview then refers to? > > - ben > I don't think you need a new format. I think you probably just need to create a plugin for drupal. -Ben West From pwgdarchive at gmail.com Thu Mar 8 15:12:02 2007 From: pwgdarchive at gmail.com (=?ISO-8859-1?Q?Benjamin_Melan=E7on?=) Date: Thu Mar 8 15:12:05 2007 Subject: [uf-new] Book Review microformat - new or how to extend hreview In-Reply-To: <8ad71be30703081448n913f502jc53cb844359b5f9a@mail.gmail.com> References: <1406bb8f0703030729q7c97dd78j14fb9f736cd8865f@mail.gmail.com> <8ad71be30703032028g3619df20rba01bb6279c60b7@mail.gmail.com> <1406bb8f0703081412m6ef70714haa6b086a26cf2800@mail.gmail.com> <8ad71be30703081448n913f502jc53cb844359b5f9a@mail.gmail.com> Message-ID: <1406bb8f0703081512p2086cabfge46d58629955ec85@mail.gmail.com> I haven't found an hreview in existence that uses any author tag, let alone publisher, copyright, isbn, number of pages etc. If I tag my number of pages as: class="pages" And someone else tags it as: class="numpages" The goal of a standard fails, same for every other tag (copyright or date or pubdate?). Am I missing something fundamental? Here's one place where I know book reviews are living in the real world - http://dwlt.net/archives/2006/11/28/TheStarbucksExperience - but the tags don't go beyond purchase, description, rating... Even type, at least an already existing tag, is given as "product" rather than "book". How could a web search reliably find book reviews of books by a given author? Thanks for patience and explanation, ben :: http://AgaricDesign.com : http://pwgd.org On 3/8/07, Benjamin West wrote: > Ben, > > On 3/8/07, Benjamin Melan?on wrote: > > Hi Ben-- I didn't see your message because I thought it was my own > > posted to the list-- darn gmail's habit of shortening us to our first > > names! > No problem :-) > > > I found some of these resources after I posted, but I still don't > > think I have what I need. > > > > For instance, the book review module in Drupal (which I would like to > > improve to have microformat tags) has fields for cover image, > > publisher, copyright, isbn, # of pages, price, synopsis as well as > > authors and distinguishing between links for purchase and other links. > > What's missing? > > > And, of course, I want to do this in a way that will be the same as > > other people using hreview for book reviews and that smart web > > indexing engines can understand (e.g., to allow 'give me all reviews > > of books by this author published before this date under this number > > of pages'). > > > > > Is there a repository and a process for defining standard implementations? > > Implementations aren't standard, only the behaviour of implementations. > > > Or do I need a 'book' microformat that hreview then refers to? > > > > - ben > > > I don't think you need a new format. I think you probably just need > to create a plugin for drupal. > > -Ben West > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From andy at pigsonthewing.org.uk Thu Mar 8 17:13:42 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 8 17:15:14 2007 Subject: [uf-new] Book Review microformat - new or how to extend hreview In-Reply-To: <1406bb8f0703081412m6ef70714haa6b086a26cf2800@mail.gmail.com> References: <1406bb8f0703030729q7c97dd78j14fb9f736cd8865f@mail.gmail.com> <8ad71be30703032028g3619df20rba01bb6279c60b7@mail.gmail.com> <1406bb8f0703081412m6ef70714haa6b086a26cf2800@mail.gmail.com> Message-ID: In message <1406bb8f0703081412m6ef70714haa6b086a26cf2800@mail.gmail.com>, Benjamin Melan?on writes >Or do I need a 'book' microformat that hreview then refers to? See: -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Thu Mar 8 17:13:06 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Mar 8 17:16:16 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: Message-ID: In message , Marian Steinbach writes >I am experimenting with the automatic >discovery of audio files, especially music MP3s, on web pages. Doesn't the "type" (MIME type): attribute, of the "A": and "OBJECT": elements, provide for that? -- Andy Mabbett Welcome to the world's longest week! From marian at sendung.de Fri Mar 9 01:28:22 2007 From: marian at sendung.de (Marian Steinbach) Date: Fri Mar 9 01:28:28 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: Message-ID: 2007/3/9, Andy Mabbett : > In message > , Marian > Steinbach writes > > >I am experimenting with the automatic > >discovery of audio files, especially music MP3s, on web pages. > > Doesn't the "type" (MIME type): > > > > attribute, of the "A": > > > > and "OBJECT": > > > > elements, provide for that? > Hi Andy! You're right, the 'type' attribute can be used to declare that a hyperlink points to a certain mime type, e.g. audio/mpeg. E.g. ... I absolutely agree that this should be used. But that only solves one of several problems. The microformat for music downloads should also help to identify the most common metadata about that music file, apart from the media type. I started this thread with the aim to gather and discuss requirements from the people who care. >From looking at many, many examples, it seems as pubulishers are most frequently giving the following information (of course in an unstructured format): - Track title (i.e. song title) -- most frequent - Artist name (i.e. singer, band or musisician) -- very frequent - Album title -- less frequent Evertyhing else that could be said about a track is much less frequently told. That could be duration, file size, bitrate etc., recording date and place (especially for live recordings). Here is a simple draft with artist and track title:
The Shins - Phantom Limb
Draft with album title:
The Shins - Phantom Limb (from the album Wincing The Night Away)
Any comments so far? (It'll get more complicated soon enough!) Cheers, Marian -- http://musik.sendung.de/ From kevinmarks at mac.com Fri Mar 9 01:42:44 2007 From: kevinmarks at mac.com (Kevin Marks) Date: Fri Mar 9 01:42:49 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: Message-ID: <077AADAD-97F8-4F65-BC33-997F071FA4BD@mac.com> On Mar 9, 2007, at 1:28 AM, Marian Steinbach wrote: > > You're right, the 'type' attribute can be used to declare that a > hyperlink points to a certain mime type, e.g. audio/mpeg. E.g. > > ... > > I absolutely agree that this should be used. But that only solves one > of several problems. Using rel-enclosure is the common way to express the link as a download (as in podcasts) http://microformats.org/wiki/rel-enclosure the alternates discussion is helpful here too: http://microformats.org/wiki/alternates > > The microformat for music downloads should also help to identify the > most common metadata about that music file, apart from the media type. > > I started this thread with the aim to gather and discuss requirements > from the people who care. > >> From looking at many, many examples, it seems as pubulishers are most > frequently giving the following information (of course in an > unstructured format): > > - Track title (i.e. song title) -- most frequent > - Artist name (i.e. singer, band or musisician) -- very frequent > - Album title -- less frequent Do think about classical music too. also see http://microformats.org/wiki/media-info for extensive examples of current practice. > > Evertyhing else that could be said about a track is much less > frequently told. That could be duration, file size, bitrate etc., > recording date and place (especially for live recordings). > > Here is a simple draft with artist and track title: > >
> The Shins span> - > Phantom Limb >
> > Draft with album title: > >
> The Shins span> - > Phantom Limb > (from the album Wincing The Night Away) >
using 'title' is a bad idea, as it has a different meaning in hCard - try and re-use the existing classes to mean the same things first: http://microformats.org/wiki/existing-classes > > Any comments so far? (It'll get more complicated soon enough!) moving this to the wiki could make sense, either as part of media- info (which is a rather bigger problem). Maybe the way to break the impasse would be for music to be a proper subset of media-info? From scott at makedatamakesense.com Fri Mar 9 07:07:10 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri Mar 9 07:07:10 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: Message-ID: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> On Mar 9, 2007, at 3:28 AM, Marian Steinbach wrote: > Draft with album title: > >
> The Shins span> - > Phantom Limb > (from the album Wincing The Night Away) >
> > Any comments so far? (It'll get more complicated soon enough!) Let's not make it any more complicated than it absolutely needs to be. I'm not even convinced we need to worry about album in the first draft. We can always add later, but we can't easily take away complication after it's in use. I have two general comments. First, I don't see any benefit to restricting this to music. All of your use cases seem to be just as relevant to non-music audio downloads. Second, I think it makes sense for the various elements to be containers, with the possibility of containing information about the artist (e.g. URL), track (e.g. recorded date), and album (e.g. published date). I think hCard and hCalendar could offer some useful semantics here. E.g.:
Chicago Public Radio - #188: Kid Logic (from the album This American Life)
Another option would be to use hAtom for everything:
Chicago Public Radio - #188: Kid Logic (from the album This American Life)
Here simply adding the class "audio-download" to the root hfeed element would give existing hAtom properties new meaning, e.g. feed- title is album, author is artist, entry-title is track. This is basically treating every audio download as a podcast with (as little as) one entry. The main problem I see is that hAtom requires a date updated, and those don't appear to be commonly published on music download sites. -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Fri Mar 9 14:29:51 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 9 14:31:27 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> Message-ID: In message <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com>, Scott Reynen writes >This is basically treating every audio download as a podcast with (as >little as) one entry. That seems reasonable. >The main problem I see is that hAtom requires a date updated Why is that? What harm would accrue from making that optional and, if not present, inferring a date from the page's "Last-Modified" header or the date of access? -- Andy Mabbett Welcome to the world's longest week! From andy at pigsonthewing.org.uk Fri Mar 9 14:38:22 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Mar 9 14:39:32 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <077AADAD-97F8-4F65-BC33-997F071FA4BD@mac.com> References: <077AADAD-97F8-4F65-BC33-997F071FA4BD@mac.com> Message-ID: In message <077AADAD-97F8-4F65-BC33-997F071FA4BD@mac.com>, Kevin Marks writes >Using rel-enclosure is the common way to express the link as a >download (as in podcasts) > >http://microformats.org/wiki/rel-enclosure Specifically (from that page): "for indicating files to cache" That's not gong to apply to a menu page which lists dozens of downloads. >Do think about classical music too Never mind classical music, what about: ? >using 'title' is a bad idea, as it has a different meaning in hCard - >try and re-use the existing classes to mean the same things first: > >http://microformats.org/wiki/existing-classes "Title" is proposed for hCite: -- Andy Mabbett Welcome to the world's longest week! From davidjanes at blogmatrix.com Sun Mar 11 03:01:15 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Mar 11 03:01:19 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> Message-ID: <21e523c20703110401i11ec4fb7oebd0e8f69e82361@mail.gmail.com> On 3/9/07, Andy Mabbett wrote: > In message <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com>, > Scott Reynen writes > > >The main problem I see is that hAtom requires a date updated > > Why is that? What harm would accrue from making that optional and, if > not present, inferring a date from the page's "Last-Modified" header or > the date of access? For what it's worth, I think a defaulting rules would be an excellent addition to hAtom 0.2. Regards, etc... David -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From ryan at technorati.com Tue Mar 13 15:25:52 2007 From: ryan at technorati.com (Ryan King) Date: Tue Mar 13 15:25:58 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> Message-ID: On Mar 9, 2007, at 9:07 AM, Scott Reynen wrote: > On Mar 9, 2007, at 3:28 AM, Marian Steinbach wrote: > >> Draft with album title: >> >>
>> The Shins> span> - >> Phantom Limb >> (from the album Wincing The Night Away) >>
>> >> Any comments so far? (It'll get more complicated soon enough!) > > Let's not make it any more complicated than it absolutely needs to > be. I'm not even convinced we need to worry about album in the > first draft. Have you collected any examples to inform this opinion? -ryan From scott at makedatamakesense.com Tue Mar 13 16:35:48 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Mar 13 16:35:50 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> Message-ID: <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> On Mar 13, 2007, at 6:25 PM, Ryan King wrote: > On Mar 9, 2007, at 9:07 AM, Scott Reynen wrote: >> On Mar 9, 2007, at 3:28 AM, Marian Steinbach wrote: >> >>> Draft with album title: >>> >>>
>>> The >>> Shins - >>> Phantom Limb >>> (from the album Wincing The Night Away) >>>
>>> >>> Any comments so far? (It'll get more complicated soon enough!) >> >> Let's not make it any more complicated than it absolutely needs to >> be. I'm not even convinced we need to worry about album in the >> first draft. > > Have you collected any examples to inform this opinion? Which opinion? Starting as simple as possible is a microformats principle, so I hope you're not questioning that. Here are the current examples of music download sites: http://microformats.org/wiki/music-examples -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Wed Mar 14 01:17:14 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 14 01:20:37 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> Message-ID: In message <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com>, Scott Reynen writes >>>I'm not even convinced we need to worry about album in the first >>>draft. >> >> Have you collected any examples to inform this opinion? > >Which opinion? Starting as simple as possible is a microformats >principle, so I hope you're not questioning that. By that argument, hCard might not have included anything other than name and e-mail address. "Adapt to current behaviors and usage patterns" is also a "microformats principle. If there is evidence that many music upload sites list album titles, why should that not be included as an optional field in the relevant microformat? -- Andy Mabbett Welcome to the world's longest week! From scott at makedatamakesense.com Wed Mar 14 05:38:45 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Mar 14 05:38:46 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> Message-ID: <7184FC73-09E5-4295-9D8B-4972B8D19F3E@makedatamakesense.com> On Mar 14, 2007, at 4:17 AM, Andy Mabbett wrote: > In message <378A9FDC- > E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com>, Scott Reynen > writes > >>>> I'm not even convinced we need to worry about album in the >>>> first draft. >>> >>> Have you collected any examples to inform this opinion? >> >> Which opinion? Starting as simple as possible is a microformats >> principle, so I hope you're not questioning that. > > By that argument, hCard might not have included anything other than > name and e-mail address. In that case, reusing an existing standard was the simplest alternative, or at least believed to be. The same is true of hCalendar and hAtom. Though none of those are actually published as full 1-to-1 relationships to the original standard (because the original standard does more than is necessary to solve most real- world problems), having a well-established standard as a reference point makes adoption simpler. If we have an equivalent well- established standard for music downloads, we should consider doing the same. > "Adapt to current behaviors and usage patterns" is also a > "microformats principle. Right. And as those behaviors change to include new microformats, we should re-evaluate each format. We can always add fields later, but we can't really take them away. > If there is evidence that many music upload sites list album > titles, why should that not be included as an optional field in the > relevant microformat? If there is such evidence, I agree we should defer to it. I personally don't see a lot of albums in the examples. "Start as simple as possible" implies there's a problem we're starting to solve. Obviously doing nothing is the simplest course of action, but that doesn't solve the problem. So we look at the examples to see what is needed. But we don't add everything we see in the examples, just the bare minimum to solve the problem for most use cases. This is explicitly stated on the music-examples page, taken straight from the process: http://microformats.org/wiki/music-examples "Simple and minimalist. As simple as possible." I'm very surprised to find this is a point of contention among people who have been involved in microformats for so long. While I didn't express a firm opinion on inclusion of album, my first pass through the examples suggests it isn't a prevalent field. I expect to be updating that impression as the examples become more detailed and organized. I didn't intend to start a series of speculation before an implied schema is taken from the examples. This was all in direct response to the statement: "(It'll get more complicated soon enough!)" Getting more complicated is neither desirable nor inevitable. Whether or not it's necessary in this case remains to be seen. -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Wed Mar 14 16:46:12 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Mar 14 16:47:43 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <7184FC73-09E5-4295-9D8B-4972B8D19F3E@makedatamakesense.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> <7184FC73-09E5-4295-9D8B-4972B8D19F3E@makedatamakesense.com> Message-ID: In message <7184FC73-09E5-4295-9D8B-4972B8D19F3E@makedatamakesense.com>, Scott Reynen writes > I personally don't see a lot of albums in the examples. "Absence of evidence is not evidence of absence." Here's your evidence: and most other songs with articles about them on Wikipedia. And here's a link to a download page for that song, on iTunes, which is timing out as I write: but which Goole says has the album title: aka: Incidentally, the "Emphasis..." wording on: is hardly likely to encourage participation. -- Andy Mabbett Welcome to the world's longest week! From marian at sendung.de Thu Mar 15 06:59:52 2007 From: marian at sendung.de (Marian Steinbach) Date: Thu Mar 15 07:06:51 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> <7184FC73-09E5-4295-9D8B-4972B8D19F3E@makedatamakesense.com> Message-ID: Hi all! It seems as if we are off track already, when discussing whether or not to include something for album information into the microformat. The ones we want to use this microformat are the publishers of music and information on music. Those people have a huge interest in communicating which album this piece can be found on, because the album/disc is still the product they want to sell. Here are some random record labels who obviously want users to know which album a download is from: http://www.dischord.com/downloads http://www.matadorrecords.com/music/mp3s.html http://www.fatwreck.com/audio/ http://www.johnscofield.com/music.html http://www.invisiblehands.co.uk/shop/tracks.asp?artistid=6 http://spill-label.org/compilations.php http://www.mightyatomsmasher.com/catalogue.htm http://www.lousrecords.com/downloads.php http://misrarecords.com/mp3.php http://www.barsuk.com/media http://www.sayhitoyourmom.com/music.htm http://www.iheartnoise.com/sounds.htm Cheers, Marian From scott at makedatamakesense.com Thu Mar 15 07:27:53 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Thu Mar 15 07:27:50 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> <7184FC73-09E5-4295-9D8B-4972B8D19F3E@makedatamakesense.com> Message-ID: <365440E7-42DC-444D-A811-C79A5645D105@makedatamakesense.com> On Mar 14, 2007, at 7:46 PM, Andy Mabbett wrote: >> I personally don't see a lot of albums in the examples. > > "Absence of evidence is not evidence of absence." Right, the microformat process is iterative, so we don't need to worry about any sort of finality. I was just sharing my current thoughts, in the interest of *avoiding* assumptions about what will be included, not of making such assumptions. I expect my current thoughts will change as I see more examples of the problem we're trying to solve. Speaking of which, it would probably help us focus if we had that problem formally stated in the wiki. I've added Marian's initial problem statement to the wiki: On Mar 7, 2007, at 1:44 AM, Marian Steinbach wrote: > Provide users with the correct metadata about the audio files so > users know who it's from and whether or not they want the file. http://microformats.org/wiki/music-examples#The_Problem -- Scott Reynen MakeDataMakeSense.com From marian at sendung.de Thu Mar 15 09:39:56 2007 From: marian at sendung.de (Marian Steinbach) Date: Thu Mar 15 09:40:00 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <365440E7-42DC-444D-A811-C79A5645D105@makedatamakesense.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> <7184FC73-09E5-4295-9D8B-4972B8D19F3E@makedatamakesense.com> <365440E7-42DC-444D-A811-C79A5645D105@makedatamakesense.com> Message-ID: 2007/3/15, Scott Reynen : > On Mar 14, 2007, at 7:46 PM, Andy Mabbett wrote: > ...I've added > Marian's initial problem statement to the wiki... Scott, thanks for that. I'd like to state that the page http://microformats.org/wiki/music-examples has the description "An attempt to gather together examples of pages describing, linking to, or referring to music.". I think it's worthwhile to be very clear about the focus. It was my intention from the beginning to focus on music downloads. There are a lot of sites giving a lot of information about music. And these sights may or may not have a demand for publishing structured information about music, musicians etc. And the concepts may be related as well. However, in terms of "devide and conquer" or how ever you'd like to call the principle, I'd suggest to be distinctive about the problem realm we're talking about here. If there is enough demand for a music download microformat, should we create a special wiki page for that? Marian -- Marian Steinbach http://musik.sendung.de/ From bewest at gmail.com Thu Mar 15 10:04:23 2007 From: bewest at gmail.com (Benjamin West) Date: Thu Mar 15 10:04:25 2007 Subject: [uf-new] process discussion: search results as evidence Message-ID: <8ad71be30703151104s2a013455w4810f891e65e8d30@mail.gmail.com> Before creating a microformat, the process demands a couple of concrete actions to be taken first. The general idea is to document current authorship techniques. If current techniques make it possible to encode a piece of information, there is no need for a microformat. Thus, we set ourselves up to make it difficult to create a format. The specific steps required involved require us to document copious amount of examples, and an anlysis of what those examples imply. Take a look at the current recipe efforts: . (If you are aspiring to create a microformat, this is an excellent example of how to do so.) What makes the research useful is the list of URLs with the subject material actually appearing on those pages. In we see a list of recipes grouped by a useful qualification (in this case the type of publisher). On the brainstorming page, there is ongoing commentary on what these examples imply. Notice that no format is being proposed, instead examples are collected, and the most commonly authored items are proposed as future properties in possible future format. The reason for this post, however, is to highlight the need for primary sources as evidence. While searching is a useful technique for finding resources, I'm not convinced they constitute useful evidence (unless you are researching how search engines markup results)., because they don't contain any substantive material that can be analysed in the brainstorming effort. Some may argue that search results constitue evidence that a given datatype is published, however, I'm not convinced this is true either. The evidence for data or some property of data being published is discovered by documenting and analyzing the pages they were actually published on, and I've yet to see a public search engine capable of performing this task. -Ben West From andy at pigsonthewing.org.uk Sun Mar 18 03:11:40 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 18 03:13:05 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now Message-ID: Abstract ======== We can have uFs for ISBNs and ISSNs. The very specific nature of the way in which those codes are formatted means that further evidence gathering would be superfluous. Such uFs would be useful components in a number of other, currently-proposed, microformats. Acting now will ensure that a standard method can be applied across such be formats Coverage ======== This post addresses the use of ISBNs; almost all of it applies to ISSNs equally. Proposal ======== There as been previous discussion of marking-up ISBNs (International Standard Book Numbers: ISBNs include a checksum digit: and can (only) be either 10 or 1 digits long. Such discussion has, for example, taken place around the proposed citation uF: I believe, however, that a UF for ISBN should stand alone, and thus be available for use in any other microformat (for recipes, for example, or for hResume, hAtom, hReview or hListing). I then started to think about evidence-gathering, and it occurred to me that so many websites use ISBN numbers, that I would never have time to examine even 1% - so I could ever be sure that I was dealing with cases in the larger side of an 80-20 divide. It then occurred to me that there are very few ways in which ISBN numbers can be marked up, in a meaningful and valid sense. Furthermore, the very nature of ISBNs, with rigidly defined formats, and check-sums, means that detecting, validating and parsing ISBNs is relatively easy to describe. Consider these examples (all found on the aforesaid citations-examples)
0-313-32847-1
0-313-32847-1 0195162471 (note that "isbnNumber" is a tautology!) and these other possible methods of marking up those ISBNs:
ISBN 0-313-32847-1
ISBN: 0-313-32847-1 the ISBN is 0195162471 ISBN: 0-95115-320-X in each case, the marked-up text includes a valid ISBN (some with permitted, but superfluous, dashes) and, in the latter cases, some other non-numerical characters. All a parser need do is discard the non numerical characters, apart from a possible "X" check-digit (it's interesting to note that no "X" check-digit occurs on citation-examples), and check that the remaining digits validate to the included checksum digit. If the mark-up has introduced additional digits: the ISBN of book #42 is 0195162471 then a parser may simply discard the results as invalid - and thus requiring a more tightly applied element. Use case ======== Marking up ISBNs would allow tools to enable users to quickly locate the relevant title in a shop or library; for example in the way which Wikipedia uses ISBNs: Indeed, that service could be the target used by a user agent (as could: for ISSNs). Conclusion ========== I believe that we could, quickly, have uFs for ISBN and ISSN; and that this would be of benefit to the development of any other uF which includes an ISBN or ISSN component - as well as benefiting the many thousands of publishers, and the any millions of consumers, of ISBNs and ISSNs All that remains is to agree a suitable class-name (ISBN vs. hISBN, for example). Next steps ========== I hope Mike Kaply, to whom I'm forwarding a copy of this e-mail, will agree to place a test-case version in a beta version of Operator. I've marked up a test-case (using class="isbn") on: which has two with "X" check digits, and I'll be happy to add further examples. I'll be placing a version of this message on the 'wiki' in due course. -- Andy Mabbett Ten-day moderation delays amount to a defacto ban! From alexander.graf at deri.org Sun Mar 18 04:16:33 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Sun Mar 18 04:16:51 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: References: Message-ID: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> Andy, while I personally think a microformat for ISBN numbers is a great idea, I want you to know that the ISBN format has changed as of Januar 1st 2007. In your test cases, the ISBN numbers are ten digits, which is *no longer valid*! To quote: > As of January 1, 2007, all book and book-related products must > carry 13-digit ISBNs. > > All 10-digit ISBNs in circulation will have the 3-digit EAN prefix > "978" added (which currently represents the book industry). This 13- > digit ISBN is already represented, and will be identical, to > current EAN bar codes carrying ISBN with the "978" prefix. > > All 10-digit ISBNs must be converted to the 13-digit format and all > systems will need to accommodate its use in this format. To easily > convert your 10-digit ISBNs to 13-digits use a conversion utility. - from: http://www.niso.org/standards/resources/ISBN.html Those are also a good read: - http://www.ariadne.ac.uk/issue41/chapman/ - http://www.lac-bac.gc.ca/iso/tc46sc9/isbn.htm I agree with a possible ISBN microformat standing alone so it can be incorporated into other formats. Oh, and I vote for class="isbn". Best regards, Alexander Graf DERI Innsbruck Digital Enterprise Research Institute Leopold-Franzens-Universit?t ICT Technologiepark, Technikerstrasse 21a 6020 Innsbruck, Austria mail: alexander.graf@deri.org web: www.deri.at On 18.03.2007, at 12:11, Andy Mabbett wrote: > > Abstract > ======== > > We can have uFs for ISBNs and ISSNs. The very specific nature of > the way > in which those codes are formatted means that further evidence > gathering > would be superfluous. Such uFs would be useful components in a > number of > other, currently-proposed, microformats. Acting now will ensure that a > standard method can be applied across such be formats > > > Coverage > ======== > > This post addresses the use of ISBNs; almost all of it applies to > ISSNs > equally. > > > Proposal > ======== > > There as been previous discussion of marking-up ISBNs (International > Standard Book Numbers: > > > > ISBNs include a checksum digit: > > > > and can (only) be either 10 or 1 digits long. > > Such discussion has, for example, taken place around the proposed > citation uF: > > > > > I believe, however, that a UF for ISBN should stand alone, and thus be > available for use in any other microformat (for recipes, for > example, or > for hResume, hAtom, hReview or hListing). > > > I then started to think about evidence-gathering, and it occurred > to me > that so many websites use ISBN numbers, that I would never have > time to > examine even 1% - so I could ever be sure that I was dealing with > cases > in the larger side of an 80-20 divide. > > It then occurred to me that there are very few ways in which ISBN > numbers can be marked up, in a meaningful and valid sense. > Furthermore, > the very nature of ISBNs, with rigidly defined formats, and check- > sums, > means that detecting, validating and parsing ISBNs is relatively > easy to > describe. > > > Consider these examples (all found on the aforesaid citations- > examples) > >
0-313-32847-1
> > 0-313-32847-1 > > 0195162471 > > (note that "isbnNumber" is a tautology!) > > and these other possible methods of marking up those ISBNs: > >
ISBN 0-313-32847-1
> > ISBN: 0-313-32847-1 > > the ISBN is 0195162471 > > ISBN: 0-95115-320-X > > in each case, the marked-up text includes a valid ISBN (some with > permitted, but superfluous, dashes) and, in the latter cases, some > other > non-numerical characters. All a parser need do is discard the non > numerical characters, apart from a possible "X" check-digit (it's > interesting to note that no "X" check-digit occurs on > citation-examples), and check that the remaining digits validate to > the > included checksum digit. > > If the mark-up has introduced additional digits: > > the ISBN of book #42 is > 0195162471 > > then a parser may simply discard the results as invalid - and thus > requiring a more tightly applied element. > > > Use case > ======== > > Marking up ISBNs would allow tools to enable users to quickly > locate the > relevant title in a shop or library; for example in the way which > Wikipedia uses ISBNs: > > title=Special:Booksources&isbn=0950788120> > > Indeed, that service could be the target used by a user agent (as > could: > > > > for ISSNs). > > > Conclusion > ========== > > I believe that we could, quickly, have uFs for ISBN and ISSN; and that > this would be of benefit to the development of any other uF which > includes an ISBN or ISSN component - as well as benefiting the many > thousands of publishers, and the any millions of consumers, of > ISBNs and > ISSNs > > All that remains is to agree a suitable class-name (ISBN vs. hISBN, > for > example). > > > Next steps > ========== > > I hope Mike Kaply, to whom I'm forwarding a copy of this e-mail, will > agree to place a test-case version in a beta version of Operator. > > > I've marked up a test-case (using class="isbn") on: > > sandwellISBNTEST.htm> > > which has two with "X" check digits, and I'll be happy to add further > examples. > > I'll be placing a version of this message on the 'wiki' in due course. > > -- > Andy Mabbett > > > Ten-day moderation delays amount to a defacto ban! > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From andy at pigsonthewing.org.uk Sun Mar 18 04:53:13 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 18 04:54:33 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> Message-ID: In message <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org>, Alexander Graf writes >I want you to know that the ISBN format has changed as of >Januar 1st 2007. In your test cases, the ISBN numbers are ten >digits, which is *no longer valid*! It's my understanding that 10-digit ISBNs (a published in millions of books and journals and many thousands, if not millions, of websites) are still valid. Can you provide specific a citation otherwise, please? -- Andy Mabbett Ten-day moderation delays amount to a defacto ban! From alexander.graf at deri.org Sun Mar 18 05:08:45 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Sun Mar 18 05:08:59 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> Message-ID: <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> On 18.03.2007, at 13:53, Andy Mabbett wrote: > It's my understanding that 10-digit ISBNs (a published in millions > of books and journals and many thousands, if not millions, of > websites) are still valid. Can you provide specific a citation > otherwise, please? Hi Andy, the citation was in my mail: > As of January 1, 2007, all book and book-related products must > carry 13-digit ISBNs. > > All 10-digit ISBNs in circulation will have the 3-digit EAN prefix > "978" added (which currently represents the book industry). This 13- > digit ISBN is already represented, and will be identical, to > current EAN bar codes carrying ISBN with the "978" prefix. > > All 10-digit ISBNs must be converted to the 13-digit format and all > systems will need to accommodate its use in this format. To easily > convert your 10-digit ISBNs to 13-digits use a conversion utility. http://www.niso.org/standards/resources/ISBN.html or: http://www.isbn.org/standards/home/isbn/transition.asp Of course systems should still read 10 digit ISBNs, but only 13 digit ISBNs are issued. This is not a problem for your proposed microformat per se, but I just wanted to make sure everyone involved in the discussion which will start around your isbn format is up to date on current ISBN standards. Also a extension which reads ISBN numbers should/must automatically convert any 10 digit ISBNs to their 13 digits equivalent for use with other systems. I think disallowing 10 digit ISBNs in the microformat is not a good idea as there may be websites that want to mark up their existing ISBN lists. Best, Alexander Graf DERI Innsbruck Digital Enterprise Research Institute Leopold-Franzens-Universit?t ICT Technologiepark, Technikerstrasse 21a 6020 Innsbruck, Austria mail: alexander.graf@deri.org web: www.deri.at -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070318/df4cf123/attachment-0001.html From brian.suda at gmail.com Sun Mar 18 05:40:52 2007 From: brian.suda at gmail.com (Brian Suda) Date: Sun Mar 18 05:40:54 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> Message-ID: <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> ISBNs are special cases of unique identifiers. We do NOT need to invent a system specifically to ISBNs, ISSN, ISBN-10, ISBN-13, etc.... microformats solve a GENERAL problem, not a specific one. We have a mechanism already for unique identifiers, it is called UID! Before any goes and proposes hISBN or hIdentifer, PLEASE, PLEASE, PLEASE look at existing formats and technologies before proposing anything, creating wiki pages, asking applications to support something without looking at prior work! The Citation format has discussed how to handle ISBNs with the UID and TYPES http://microformats.org/wiki/citation-brainstorming#Outstanding_Issues The UID brainstroming page has suggestions to re-use the abbr-design pattern: http://microformats.org/wiki/uid-brainstorming#abbr_pattern The UID examples page has examples from the wild, how they are marked-up http://microformats.org/wiki/uid-examples#Real-World_Examples There is also an ISBN RFC: http://www.ietf.org/rfc/rfc3187.txt The creation of the wiki page for ISBN http://microformats.org/wiki/isbn should be re-worked to incorporate OLD examples and the use of UID NOT as a proposal for a new format. The ISBN page should be a redirect to http://microformats.org/wiki/uid and not a seperate microformats! -brian From alexander.graf at deri.org Sun Mar 18 06:17:32 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Sun Mar 18 06:17:39 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> Message-ID: <20CD095D-44BD-41A9-B2DF-9ADF0354BA1C@deri.org> On 18.03.2007, at 14:40, Brian Suda wrote: > microformats solve a GENERAL problem, not a specific one. Actually I thought it was the other way round. > We have a mechanism already for unique identifiers, it is called UID! In any case there needs to be a way to differentiate UIDs. A unique identifier in a news feed item is something different than a ISBN. Tools like operator need to do specific things with microformats and there are things you can do with ISBNs which you can't do with other UIDs and vice versa. So if a new ISBN microformat is out of the question, there needs to be more work on UID... Best, Alexander Graf DERI Innsbruck Digital Enterprise Research Institute Leopold-Franzens-Universit?t ICT Technologiepark, Technikerstrasse 21a 6020 Innsbruck, Austria mail: alexander.graf@deri.org web: www.deri.at From pwgdarchive at gmail.com Sun Mar 18 06:31:49 2007 From: pwgdarchive at gmail.com (=?ISO-8859-1?Q?Benjamin_Melan=E7on?=) Date: Sun Mar 18 06:31:53 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: References: Message-ID: <1406bb8f0703180731x10375aa0hf897d5d413eb7589@mail.gmail.com> A strong vote for adding ISBN to microformats including hreview. Just having this conversation offlist with another member. I really don't care how it's done but the point is to have a standard. Is there an ISBN lookup service? I searched the Internet and looked around ISBN.org (which seems disturbingly for-profit) but didn't find anything. I'm trying to get this straight... an hReview for a book should reference an hcite which has the author, publisher (both as hcard), format, and ISBN information etc? Number of pages, printing date, etc. still need standards, and format needs to be firmed up it looks like. How is a reference done-- just sharing author and title? Thanks... ben :: http://AgaricDesign.com :: http://PWGD.org On 3/18/07, Andy Mabbett wrote: > > Abstract > ======== > > We can have uFs for ISBNs and ISSNs. The very specific nature of the way > in which those codes are formatted means that further evidence gathering > would be superfluous. Such uFs would be useful components in a number of > other, currently-proposed, microformats. Acting now will ensure that a > standard method can be applied across such be formats > > > Coverage > ======== > > This post addresses the use of ISBNs; almost all of it applies to ISSNs > equally. > > > Proposal > ======== > > There as been previous discussion of marking-up ISBNs (International > Standard Book Numbers: > > > > ISBNs include a checksum digit: > > > > and can (only) be either 10 or 1 digits long. > > Such discussion has, for example, taken place around the proposed > citation uF: > > > > > I believe, however, that a UF for ISBN should stand alone, and thus be > available for use in any other microformat (for recipes, for example, or > for hResume, hAtom, hReview or hListing). > > > I then started to think about evidence-gathering, and it occurred to me > that so many websites use ISBN numbers, that I would never have time to > examine even 1% - so I could ever be sure that I was dealing with cases > in the larger side of an 80-20 divide. > > It then occurred to me that there are very few ways in which ISBN > numbers can be marked up, in a meaningful and valid sense. Furthermore, > the very nature of ISBNs, with rigidly defined formats, and check-sums, > means that detecting, validating and parsing ISBNs is relatively easy to > describe. > > > Consider these examples (all found on the aforesaid citations-examples) > >
0-313-32847-1
> > 0-313-32847-1 > > 0195162471 > > (note that "isbnNumber" is a tautology!) > > and these other possible methods of marking up those ISBNs: > >
ISBN 0-313-32847-1
> > ISBN: 0-313-32847-1 > > the ISBN is 0195162471 > > ISBN: 0-95115-320-X > > in each case, the marked-up text includes a valid ISBN (some with > permitted, but superfluous, dashes) and, in the latter cases, some other > non-numerical characters. All a parser need do is discard the non > numerical characters, apart from a possible "X" check-digit (it's > interesting to note that no "X" check-digit occurs on > citation-examples), and check that the remaining digits validate to the > included checksum digit. > > If the mark-up has introduced additional digits: > > the ISBN of book #42 is > 0195162471 > > then a parser may simply discard the results as invalid - and thus > requiring a more tightly applied element. > > > Use case > ======== > > Marking up ISBNs would allow tools to enable users to quickly locate the > relevant title in a shop or library; for example in the way which > Wikipedia uses ISBNs: > > > > Indeed, that service could be the target used by a user agent (as could: > > > > for ISSNs). > > > Conclusion > ========== > > I believe that we could, quickly, have uFs for ISBN and ISSN; and that > this would be of benefit to the development of any other uF which > includes an ISBN or ISSN component - as well as benefiting the many > thousands of publishers, and the any millions of consumers, of ISBNs and > ISSNs > > All that remains is to agree a suitable class-name (ISBN vs. hISBN, for > example). > > > Next steps > ========== > > I hope Mike Kaply, to whom I'm forwarding a copy of this e-mail, will > agree to place a test-case version in a beta version of Operator. > > > I've marked up a test-case (using class="isbn") on: > > > > which has two with "X" check digits, and I'll be happy to add further > examples. > > I'll be placing a version of this message on the 'wiki' in due course. > > -- > Andy Mabbett > > > Ten-day moderation delays amount to a defacto ban! > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From scott at makedatamakesense.com Sun Mar 18 08:10:42 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Mar 18 08:10:55 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> Message-ID: <329EFF65-C0A8-4DB9-BC66-6C1F88D42DD3@makedatamakesense.com> On Mar 18, 2007, at 8:40 AM, Brian Suda wrote: > ISBNs are special cases of unique identifiers. We do NOT need to > invent a system specifically to ISBNs, ISSN, ISBN-10, ISBN-13, etc.... > microformats solve a GENERAL problem, not a specific one. I disagree with this as stated. The microformat principles clearly state "solve a specific problem." We should, however, solve a *specific problem* with a *general solution*, to allow for "modularity / embeddability" (another principle), which I hope is what Brian was trying to communicate. > We have a mechanism already for unique identifiers, it is called UID! Great. Let's apply that general mechanism to the specific problem of ISBNs. Solving of a problem with existing techniques is A Good Thing, and we should focus on that goodness more. > The Citation format has discussed how to handle ISBNs with the UID > and TYPES > http://microformats.org/wiki/citation-brainstorming#Outstanding_Issues This looks like it will solve this specific problem:
ISBN: 123456
Now let's document that somewhere where it won't be so easily overlooked again. > The creation of the wiki page for ISBN > http://microformats.org/wiki/isbn should be re-worked to incorporate > OLD examples and the use of UID NOT as a proposal for a new format. > The ISBN page should be a redirect to http://microformats.org/wiki/uid > and not a seperate microformats! I agree that the ISBN page should be edited to explore using a technique already established in the work on citations. But I see no harm, and a lot of good, in exploring how this technique applies specifically to ISBNs on a separate page, just as we explored using hCalendar for marking up operating hours on a separate page: http://microformats.org/wiki/operating-hours As Ben West said recently: > documenting techniques should be a successful goal for the > microformats community Such documentation is very useful for publishers trying to understand how general techniques apply to specific problems, and should be encouraged. -- Scott Reynen MakeDataMakeSense.com From brian.suda at gmail.com Sun Mar 18 08:29:48 2007 From: brian.suda at gmail.com (Brian Suda) Date: Sun Mar 18 08:29:50 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <329EFF65-C0A8-4DB9-BC66-6C1F88D42DD3@makedatamakesense.com> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> <329EFF65-C0A8-4DB9-BC66-6C1F88D42DD3@makedatamakesense.com> Message-ID: <21e770780703180929r78a6d3cem1c9e7526b27f5d66@mail.gmail.com> On 3/18/07, Scott Reynen wrote: > On Mar 18, 2007, at 8:40 AM, Brian Suda wrote: > > > ISBNs are special cases of unique identifiers. We do NOT need to > > invent a system specifically to ISBNs, ISSN, ISBN-10, ISBN-13, etc.... > > microformats solve a GENERAL problem, not a specific one. > > I disagree with this as stated. The microformat principles clearly > state "solve a specific problem." We should, however, solve a > *specific problem* with a *general solution*, to allow for > "modularity / embeddability" (another principle), which I hope is > what Brian was trying to communicate. --- correct. With things like Reviews we choose to create hReview and not hBookReview or hConcertReview. ISBN is a unique identifer, UIDs solve this problem. > This looks like it will solve this specific problem: > >
ISBN: class="value">123456
--- much akin to IM names, we can also explore using the protocol to describe the TYPE. A book > I agree that the ISBN page should be edited to explore using a > technique already established in the work on citations. But I see no > harm, and a lot of good, in exploring how this technique applies > specifically to ISBNs on a separate page, just as we explored using > hCalendar for marking up operating hours on a separate page: > > http://microformats.org/wiki/operating-hours correct, UID is a subset of hCards just like Opening-hours is a subset of hCalendar. I think we should NOT further fragment UID into ISBN/ISSN/XYZ they are all Unique Identifers. We SHOULD make the UID page more 'findable' and it should encompass things such as ISBNs, but i don't think we need to duplicate efforts for each individual TYPE of UID. We don't have individual pages for TEL TYPE FAX so why have pages for UID TYPE ISBN? By keeping all the UID types together at the UID page we can (hopefully) help the next person find information better when they want to mark-up things like their Nintendo DS code for the world to see, or other unique identifers. Things like MD5 and SHA-1 hashs for downloads also fall into the category of UID and NOT their own formats. This is certainly worth exploring, but re-use is best. -brian -- brian suda http://suda.co.uk From alexander.graf at deri.org Sun Mar 18 08:56:55 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Sun Mar 18 08:57:02 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <21e770780703180929r78a6d3cem1c9e7526b27f5d66@mail.gmail.com> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> <329EFF65-C0A8-4DB9-BC66-6C1F88D42DD3@makedatamakesense.com> <21e770780703180929r78a6d3cem1c9e7526b27f5d66@mail.gmail.com> Message-ID: <4758682E-3ED3-4E50-8A81-8B3AE5FF3925@deri.org> On 18.03.2007, at 17:29, Brian Suda wrote: > correct, UID is a subset of hCards just like Opening-hours is a subset > of hCalendar. In my opinion, this is not necessarily the best solution. If, at one point, someone wants to add additional properties to UID, this will be impossible since UID is then a locked subset of hCards. The same thing is happening with "geo" at the moment. Altitude and date information is certainly useful in geo but can't be added because no changes to geo are accepted, since they are not in vCards and subsequently not in hCards. Will UID be locked too, just like geo? If this is not the case, then I'm fine with using UID for ISBN/ISSN numbers. Protocol style identifiers (isbn://) and type identifiers (ISBN) are both very good solutions and have worked elsewhere. Best, Alexander Graf DERI Innsbruck Digital Enterprise Research Institute Leopold-Franzens-Universit?t ICT Technologiepark, Technikerstrasse 21a 6020 Innsbruck, Austria mail: alexander.graf@deri.org web: www.deri.at From scott at makedatamakesense.com Sun Mar 18 09:37:25 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Mar 18 09:37:38 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <21e770780703180929r78a6d3cem1c9e7526b27f5d66@mail.gmail.com> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> <329EFF65-C0A8-4DB9-BC66-6C1F88D42DD3@makedatamakesense.com> <21e770780703180929r78a6d3cem1c9e7526b27f5d66@mail.gmail.com> Message-ID: On Mar 18, 2007, at 11:29 AM, Brian Suda wrote: > We don't have individual pages for TEL TYPE FAX so why have pages > for UID TYPE ISBN? Because it's less clear that UID solves the ISBN problem than it is that TEL solves the FAX problem, as evidenced by this thread. If we start seeing suggestions to create a new FAX microformat, I think it would make sense to create additional documentation explaining how to use TEL to solve that specific problem. > By keeping all the UID types together at the UID > page we can (hopefully) help the next person find information better > when they want to mark-up things like their Nintendo DS code for the > world to see, or other unique identifers. Improving documentation of the UID technique in general and improving documentation of using UID for ISBN markup are not at all mutually exclusive and we should do both. > Things like MD5 and SHA-1 > hashs for downloads also fall into the category of UID and NOT their > own formats. Right, but those could be documented on separate pages without being separate formats (though I see no evidence that would be useful in this case). > This is certainly worth exploring, but re-use is best. Re-use of techniques is best. But re-use of documentation is not, because it's not conducive to re-use of techniques. If I'm a publisher looking for a standard markup for my ISBNs, I'm more likely to end up re-using the UID technique if it's explained to me in the context of my specific use case. Obviously we can't document every specific use-case, but it's something we should encourage. Not only because it would result in better documentation, but also for a more subtle reason: If we don't treat documentation of a general technique for a specific use case as a successful outcome, we're left with only two possible outcomes: successful new microformat or failure. Naturally, this leads to everyone pushing hard for new microformats for everything, as no one wants their work to result in failure. -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Sun Mar 18 12:46:11 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 18 12:51:20 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> Message-ID: In message <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org>, Alexander Graf writes >>>I want you to know that the ISBN format has changed as of >>>Januar 1st 2007. In your test cases, the ISBN numbers are ten >>>digits, which is *no longer valid*! >On 18.03.2007, at 13:53, Andy Mabbett wrote: > >> It's my understanding that 10-digit ISBNs (a published in millions of >>books and journals and many thousands, if not millions, of websites) >>are still valid. Can you provide specific a citation otherwise, please? >the citation was in my mail: > >> As of January 1, 2007, all book and book-related products must carry >>13-digit ISBNs. >> >> All 10-digit ISBNs in circulation will have the 3-digit EAN prefix >>"978" added (which currently represents the book industry). This 13- >>digit ISBN is already represented, and will be identical, to current >>EAN bar codes carrying ISBN with the "978" prefix. >> >> All 10-digit ISBNs must be converted to the 13-digit format and all >>systems will need to accommodate its use in this format. To easily >>convert your 10-digit ISBNs to 13-digits use a conversion utility. > >http://www.niso.org/standards/resources/ISBN.html > >or: http://www.isbn.org/standards/home/isbn/transition.asp Thank you, but I asked for a *specific* citation, such as you have now provided, AS far as can see, none of the support your claim that the ISBN's on the sample page I provided are "*no longer valid*". >Of course systems should still read 10 digit ISBNs Quite. >, but only 13 digit ISBNs are issued. >Also a extension which reads ISBN numbers should/must >automatically convert any 10 digit ISBNs to their 13 digits equivalent >for use with other >systems. That seems reasonable; provided that the other systems are already accepting 13-fdigit ISBNs. >I think disallowing 10 digit ISBNs in the microformat is not a good >idea as there may be >websites that want to mark up their existing ISBN lists. There are any which already do; it is not for us to require people to amend the data they validly publish. -- Andy Mabbett Ten-day moderation delays amount to a defacto ban! From andy at pigsonthewing.org.uk Sun Mar 18 12:58:49 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 18 12:59:54 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> References: <522C3D75-3485-433C-9017-68EEC9C1DFF9@deri.org> <77755A4C-B488-4B99-B1E1-04F94843FEB5@deri.org> <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com> Message-ID: In message <21e770780703180640i1b09dab3ma6b4cf058ec38388@mail.gmail.com>, Brian Suda writes >microformats solve a GENERAL problem, not a specific one. I see that others have already addressed this point. I wonder whether ISBN and ISSN, between them, comprise more or less than 80% of the UIDs published online. >The Citation format has discussed how to handle ISBNs with the UID and TYPES >http://microformats.org/wiki/citation-brainstorming#Outstanding_Issues > >The UID brainstroming page has suggestions to re-use the abbr-design pattern: >http://microformats.org/wiki/uid-brainstorming#abbr_pattern I thought one of the microformats "principles" was to make things easy for publishers; and another to base uFs on existing practice; How are:
ISBN: 123456
or 0 9507881-2-0 doing either of those things; and how are they better for publishers than:
ISBN 0-313-32847-1
? In the case of the former example, how sure are we that the string "ISBN" is "always" published alongside ISBN numbers? It's also somewhat alarming that ISBN was raised there in August 2005, yet we still don't seem to be near to having a format which publishers can use to resolve the problem in my original post in this thread. -- Andy Mabbett Ten-day moderation delays amount to a defacto ban! From andy at pigsonthewing.org.uk Sun Mar 18 13:09:15 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 18 13:10:40 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: <1406bb8f0703180731x10375aa0hf897d5d413eb7589@mail.gmail.com> References: <1406bb8f0703180731x10375aa0hf897d5d413eb7589@mail.gmail.com> Message-ID: In message <1406bb8f0703180731x10375aa0hf897d5d413eb7589@mail.gmail.com>, Benjamin Melan?on writes >Is there an ISBN lookup service? If you want to enter an ISBN and find the title and author, etc., then you can use the Wikipedia service in my original post. For the reverse, you need to find the book in a library catalogue, on-line bookshop (such as Amazon) or suchlike, Note that books published before 1974 do not have ISBNs (there's an interesting case to be made for retrospectively issuing them but this isn't the place for that). Note that ISBN have been assigned for almost 35 years in over 150 countries or territories. I don't know many millions that amounts too, but I'd wager that the vast majority are published on-line, at least once, and often many thousands of times. -- Andy Mabbett Ten-day moderation delays amount to a defacto ban! From pwgdarchive at gmail.com Mon Mar 19 03:38:59 2007 From: pwgdarchive at gmail.com (=?ISO-8859-1?Q?Benjamin_Melan=E7on?=) Date: Mon Mar 19 03:39:02 2007 Subject: [uf-new] ISBN, ISSN and the case for moving forward now In-Reply-To: References: <1406bb8f0703180731x10375aa0hf897d5d413eb7589@mail.gmail.com> Message-ID: <1406bb8f0703190438w1976cbeeqa57ea6d80970ba87@mail.gmail.com> On 3/18/07, Andy Mabbett wrote: > >Is there an ISBN lookup service? > > If you want to enter an ISBN and find the title and author, etc., then > you can use the Wikipedia service in my original post. Thanks-- I'd missed that. But what I don't find there is a service that provides author, publisher, etc in XML markup or any API that software could use to fill in the blanks (I review a book in a CMS-backed web site, put in the ISBN, and the title and all are displayed right there). From my perspective then I still need microformat best practices for describing all parts of an edition of a book, including number of pages etc., some of which I've listed before. And I'm still not sure if an hcite should be embedded in an hreview or referenced in an hreview and how. - ben From michael.biven at gmail.com Mon Mar 19 08:50:35 2007 From: michael.biven at gmail.com (Michael Biven) Date: Mon Mar 19 08:50:39 2007 Subject: [uf-new] feedback wanted on property listing microformat Message-ID: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> Hello, I've started working with a MLS (Multiple List Service) / IDX (Internet Data Exchange) system and after seeing the many differences in these systems across the U.S. I think that this is a problem that a microformat could solve and improve how people work with the data. Currently you can search for listings in an area on one of the many MLS / IDX systems available to the public from national, regional, or local MLS sites, individual real estate broker sites, your local or regional online version of the classifieds, or Craigslist and eBay. Besides pen and paper there are not many other tools to aggregate everything from those sites to work with the available information. I'm not knocking pen and paper I use it to work out most of my ideas and thoughts, but the tools used to work with information on property listings from online sources could be improved upon. As for now I'll just be calling this idea mListing as there is already a hListing format in the works. Though this is to be more narrowly focused than hListing by sticking to real estate listings across any IDX / MLS system or online classified site (Craigslist or local newspaper) that choose to use it. Also right now there is work on a new version of the RETS standard and some discussion if the MLS system should be made open, combined into one large or regional databases and possible action from the DoJ over antitrust issues. So what if there was a common set of data fields across these systems that would allow the shopper to view, save or mashup that information? Until questions and issues that are currently ongoing in the real estate field about the MLS system are answered, mListing could be a good way to provide this common information to people about a property listing. So a person could use this to save a set of listings for later, email to someone, lookup additional information (property values, reviews of the broker, and neighborhood information) or just make a map with driving directions so you can go see the property in person. I'd love to hear some feedback on this before I get started and go off and create a new page in the wiki. Below are a few links to some examples and a few posts / sites that relate to this idea. Examples: http://realtor.com http://www.homes.com Your local or regional Realtor Association http://louisville.craigslist.org/hhh/ http://pages.ebay.com/realestate/ Links of interest: http://wiki.rets.org/index.php/Main_Page http://blog.realtors.org/crt/ http://www.crt.realtors.org/ http://www.flexmls.com/blog/ http://www.raincityguide.com/2006/06/23/there-you-go-again-the-mls-doesnt-scale/ http://blog.shackprices.com/ (great people to talk about mListing) http://www.bloodhoundrealty.com/BloodhoundBlog/ hListing http://microformats.org/wiki/hlisting-proposal http://microformats.org/wiki/hlisting-feedback http://microformats.org/wiki/listing-examples http://microformats.org/wiki/listing-formats http://microformats.org/wiki/listing-brainstorming Thanks, Michael B. -- Michael Biven michael.biven@gmail.com http://biven.org From brian.suda at gmail.com Mon Mar 19 09:05:02 2007 From: brian.suda at gmail.com (Brian Suda) Date: Mon Mar 19 09:05:05 2007 Subject: [uf-new] feedback wanted on property listing microformat In-Reply-To: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> References: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> Message-ID: <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> On 3/19/07, Michael Biven wrote: > Hello, I've started working with a MLS (Multiple List Service) / IDX > (Internet Data Exchange) system and after seeing the many differences > in these systems across the U.S. I think that this is a problem that a > microformat could solve and improve how people work with the data. specifically, what is it about hListing that does not cover houses? can you give specific listing so we can examine it with hListing and see what is missing? then we can walk through it and see if other microformats cover those areas NOT addressed by hListing. I've spent my fair share of time playing with MLS data to know that Bathroom count and Room count are all just a FRACTION of what comes out of the database, at some point a microformats will ONLY address the common aspects each listing and not necessarily the complete profile. -brian -- brian suda http://suda.co.uk From michael.biven at gmail.com Mon Mar 19 09:43:07 2007 From: michael.biven at gmail.com (Michael Biven) Date: Mon Mar 19 09:43:09 2007 Subject: [uf-new] feedback wanted on property listing microformat In-Reply-To: <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> References: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> Message-ID: <7ec7b4220703191043m6f687782o8c7819dcbd7a0078@mail.gmail.com> On 3/19/07, Brian Suda wrote: > specifically, what is it about hListing that does not cover houses? To me it seems that hListing is trying to do too much, almost as if instead of having hCard and hCalendar we got hPIM instead. After looking at the hListing proposal it looks to be limited in the available fields because it is trying to do too much rather than focus on one type to better support its unique requirements. Basically by focusing on just the real estate listings it would be simpler to add the needed fields there rather than adding a bunch to hListing standard. And this isn't just for houses, but anything (land, condos, commercial property etc) that might be in a MLS system or in the real estate section of the classifieds. > can you give specific listing so we can examine it with hListing and > see what is missing? then we can walk through it and see if other > microformats cover those areas NOT addressed by hListing. http://glarhomes.com/(vlwbm0553oibtw55tzfx3v55)/propertyDetails.aspx?mls=1154360 As for what is missing I think my comment below explains my thinking best. > I've spent my fair share of time playing with MLS data to know that > Bathroom count and Room count are all just a FRACTION of what comes > out of the database, at some point a microformats will ONLY address > the common aspects each listing and not necessarily the complete > profile. Exactly! Like I said in the original post I'm working with a MLS system right now and I've seen the differences, both large and small, in the schema's between some MLS systems. For example some will just use "total sq ft." while others will use the ANSI above-grade, below-grade and "total living area" standards instead. It is those exact differences in the schema between MLS systems and the lack of them sometimes in classifieds, Craigslist or eBay that I think can be addressed by a microformat focused on real estate listings. Thanks! Michael B. -- Michael Biven michael.biven@gmail.com http://biven.org From ryan at technorati.com Mon Mar 19 21:37:48 2007 From: ryan at technorati.com (Ryan King) Date: Mon Mar 19 21:37:52 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> Message-ID: <3FC688F8-F0CD-4E94-BA20-C57E4217D243@technorati.com> On Mar 13, 2007, at 5:35 PM, Scott Reynen wrote: > On Mar 13, 2007, at 6:25 PM, Ryan King wrote: > >> On Mar 9, 2007, at 9:07 AM, Scott Reynen wrote: >>> On Mar 9, 2007, at 3:28 AM, Marian Steinbach wrote: >>> >>>> Draft with album title: >>>> >>>>
>>>> The >>>> Shins - >>>> Phantom Limb >>>> (from the album Wincing The Night Away) >>>>
>>>> >>>> Any comments so far? (It'll get more complicated soon enough!) >>> >>> Let's not make it any more complicated than it absolutely needs >>> to be. I'm not even convinced we need to worry about album in >>> the first draft. >> >> Have you collected any examples to inform this opinion? > > Which opinion? Starting as simple as possible is a microformats > principle, so I hope you're not questioning that. Here are the > current examples of music download sites: No, that album is not common or simple. It just seems that talking about what fields should be in format before there's any documented examples from the wild is premature. -ryan -- Ryan King ryan@technorati.com From ryan at technorati.com Mon Mar 19 21:41:38 2007 From: ryan at technorati.com (Ryan King) Date: Mon Mar 19 21:41:40 2007 Subject: [uf-new] feedback wanted on property listing microformat In-Reply-To: <7ec7b4220703191043m6f687782o8c7819dcbd7a0078@mail.gmail.com> References: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> <7ec7b4220703191043m6f687782o8c7819dcbd7a0078@mail.gmail.com> Message-ID: On Mar 19, 2007, at 10:43 AM, Michael Biven wrote: > On 3/19/07, Brian Suda wrote: > >> specifically, what is it about hListing that does not cover houses? > > To me it seems that hListing is trying to do too much, almost as if > instead of having hCard and hCalendar we got hPIM instead. After > looking at the hListing proposal it looks to be limited in the > available fields because it is trying to do too much rather than focus > on one type to better support its unique requirements. > > Basically by focusing on just the real estate listings it would be > simpler to add the needed fields there rather than adding a bunch to > hListing standard. And this isn't just for houses, but anything (land, > condos, commercial property etc) that might be in a MLS system or in > the real estate section of the classifieds. Before proposing that we replace, replicate or extend hListing, please experiment with it on actual examples and provide feedback about its limitations. As of now, your objections are theoretical. Microformats don't encode every possible bit of information, instead they focus on the most common and useful parts. -ryan -- Ryan King ryan@technorati.com From scott at makedatamakesense.com Mon Mar 19 22:02:56 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Mar 19 22:03:05 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <3FC688F8-F0CD-4E94-BA20-C57E4217D243@technorati.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> <3FC688F8-F0CD-4E94-BA20-C57E4217D243@technorati.com> Message-ID: <74937B5E-4566-4E81-BE5A-7E00427F289E@makedatamakesense.com> On Mar 20, 2007, at 12:37 AM, Ryan King wrote: > On Mar 13, 2007, at 5:35 PM, Scott Reynen wrote: > >> On Mar 13, 2007, at 6:25 PM, Ryan King wrote: >> >>> On Mar 9, 2007, at 9:07 AM, Scott Reynen wrote: >>>> On Mar 9, 2007, at 3:28 AM, Marian Steinbach wrote: >>>> >>>>> Any comments so far? (It'll get more complicated soon enough!) >>>> >>>> Let's not make it any more complicated than it absolutely needs >>>> to be. I'm not even convinced we need to worry about album in >>>> the first draft. >>> >>> Have you collected any examples to inform this opinion? >> >> Which opinion? Starting as simple as possible is a microformats >> principle, so I hope you're not questioning that. Here are the >> current examples of music download sites: > > No, that album is not common or simple. It just seems that talking > about what fields should be in format before there's any documented > examples from the wild is premature. I wasn't trying to say anything about what fields should be in a format. I meant for "I'm not even convinced" to be a statement of uncertainty, as opposed to "It'll get more complicated soon enough!" which sounded to me like the kind of assumption we shouldn't be making. -- Scott Reynen MakeDataMakeSense.com From michael.biven at gmail.com Tue Mar 20 04:09:20 2007 From: michael.biven at gmail.com (Michael Biven) Date: Tue Mar 20 04:09:23 2007 Subject: [uf-new] feedback wanted on property listing microformat In-Reply-To: References: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> <7ec7b4220703191043m6f687782o8c7819dcbd7a0078@mail.gmail.com> Message-ID: <7ec7b4220703200509g4973f3b5o5c0d814c70e043e9@mail.gmail.com> On 3/20/07, Ryan King wrote: > Before proposing that we replace, replicate or extend hListing, > please experiment with it on actual examples and provide feedback > about its limitations. As of now, your objections are theoretical. That you can count on. I have to disagree that my point is theoretical, but instead it is practical. There is enough common fields between each of the different types of real estate listings that are not included with hListings, becasue it deals with a much larger set of different types of unrelated "things" to list. > Microformats don't encode every possible bit of information, instead > they focus on the most common and useful parts. To me that sentence in itself explains pretty well why people dealing with real estate listings would benefit from having a separate standard for them. -- Michael Biven michael.biven@gmail.com http://biven.org From scott at makedatamakesense.com Tue Mar 20 05:44:27 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Mar 20 05:44:41 2007 Subject: [uf-new] feedback wanted on property listing microformat In-Reply-To: <7ec7b4220703200509g4973f3b5o5c0d814c70e043e9@mail.gmail.com> References: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> <7ec7b4220703191043m6f687782o8c7819dcbd7a0078@mail.gmail.com> <7ec7b4220703200509g4973f3b5o5c0d814c70e043e9@mail.gmail.com> Message-ID: <4CC5C0FB-89F8-4F00-A361-306512AB5415@makedatamakesense.com> On Mar 20, 2007, at 7:09 AM, Michael Biven wrote: > On 3/20/07, Ryan King wrote: > >> Before proposing that we replace, replicate or extend hListing, >> please experiment with it on actual examples and provide feedback >> about its limitations. As of now, your objections are theoretical. > > That you can count on. I have to disagree that my point is > theoretical, but instead it is practical. There is enough common > fields between each of the different types of real estate listings > that are not included with hListings, becasue it deals with a much > larger set of different types of unrelated "things" to list. Actual experimentation with hListing is more useful than abstract discussion. We could go around in circles about whether hListing would help for months, or someone could actually try it and we could all see clearly where it works and where it doesn't. The latter is strongly preferred. >> Microformats don't encode every possible bit of information, instead >> they focus on the most common and useful parts. > > To me that sentence in itself explains pretty well why people dealing > with real estate listings would benefit from having a separate > standard for them. No one benefits from unused standards, and what Ryan suggested would provide an indication that people dealing with real estate listings are willing to experiment with standards before their problem is 100% solved. If they're not, we're just wasting our time, because microformats never solve 100% of anything. It's an iterative process, and we always need experimentation with the current iteration to inform the next. That's why participation of relevant publishers is so crucial. -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Tue Mar 20 12:13:50 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Mar 20 12:15:16 2007 Subject: [uf-new] Citing the page being visited Message-ID: Work is underway on Wikipedia, to include (hidden) COinS data, so that users (or user agent) can extract the data required to cite the page being visited, when referring to it elsewhere. Example: (See last content item in page source, using class="Z3988".) Adding a class of, say "self" to an attribute of the proposed strawman would achieve this purpose, with the added advantage of allowing the citation to be ignored by any parser which might be building a "tree" of citations, and preventing the setting up of an infinite loop. I have added this observation to the Wiki: aka: -- Andy Mabbett Welcome to the world's longest week! From ryan at technorati.com Wed Mar 21 08:58:43 2007 From: ryan at technorati.com (Ryan King) Date: Wed Mar 21 08:58:47 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <74937B5E-4566-4E81-BE5A-7E00427F289E@makedatamakesense.com> References: <3A729F4A-906E-4391-9AD6-742B1DF0CFD4@makedatamakesense.com> <378A9FDC-E005-4E9B-8904-7F6850D5CD63@makedatamakesense.com> <3FC688F8-F0CD-4E94-BA20-C57E4217D243@technorati.com> <74937B5E-4566-4E81-BE5A-7E00427F289E@makedatamakesense.com> Message-ID: On Mar 19, 2007, at 11:02 PM, Scott Reynen wrote: > On Mar 20, 2007, at 12:37 AM, Ryan King wrote: >> On Mar 13, 2007, at 5:35 PM, Scott Reynen wrote: >>> On Mar 13, 2007, at 6:25 PM, Ryan King wrote: >>> >>>> On Mar 9, 2007, at 9:07 AM, Scott Reynen wrote: >>>>> On Mar 9, 2007, at 3:28 AM, Marian Steinbach wrote: >>>>> >>>>>> Any comments so far? (It'll get more complicated soon enough!) >>>>> >>>>> Let's not make it any more complicated than it absolutely needs >>>>> to be. I'm not even convinced we need to worry about album in >>>>> the first draft. >>>> >>>> Have you collected any examples to inform this opinion? >>> >>> Which opinion? Starting as simple as possible is a microformats >>> principle, so I hope you're not questioning that. Here are the >>> current examples of music download sites: >> >> No, that album is not common or simple. It just seems that talking >> about what fields should be in format before there's any >> documented examples from the wild is premature. > > I wasn't trying to say anything about what fields should be in a > format. I meant for "I'm not even convinced" to be a statement of > uncertainty, as opposed to "It'll get more complicated soon > enough!" which sounded to me like the kind of assumption we > shouldn't be making. Gotcha. Sorry for the misunderstanding. -ryan -- Ryan King ryan@technorati.com From ryan at technorati.com Wed Mar 21 09:00:47 2007 From: ryan at technorati.com (Ryan King) Date: Wed Mar 21 09:00:57 2007 Subject: [uf-new] feedback wanted on property listing microformat In-Reply-To: <7ec7b4220703200509g4973f3b5o5c0d814c70e043e9@mail.gmail.com> References: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> <7ec7b4220703191043m6f687782o8c7819dcbd7a0078@mail.gmail.com> <7ec7b4220703200509g4973f3b5o5c0d814c70e043e9@mail.gmail.com> Message-ID: <61C7714A-DA80-4D19-95DE-D8BB1B7DB902@technorati.com> On Mar 20, 2007, at 5:09 AM, Michael Biven wrote: > On 3/20/07, Ryan King wrote: > >> Before proposing that we replace, replicate or extend hListing, >> please experiment with it on actual examples and provide feedback >> about its limitations. As of now, your objections are theoretical. > > That you can count on. I have to disagree that my point is > theoretical, but instead it is practical. There is enough common > fields between each of the different types of real estate listings > that are not included with hListings, becasue it deals with a much > larger set of different types of unrelated "things" to list. I'm sure you're an expert on real estate and other types of listings, but before we can say that the various kinds of listings *on the web* have field overlap, we need to do the research into existing examples, analyzing them for implied schemata. >> Microformats don't encode every possible bit of information, instead >> they focus on the most common and useful parts. > > To me that sentence in itself explains pretty well why people dealing > with real estate listings would benefit from having a separate > standard for them. They also share vocabulary as much as possible, invent as little as possible and are based on research into existing practice *on the web*. -ryan -- Ryan King ryan@technorati.com From ryan at technorati.com Wed Mar 21 09:01:26 2007 From: ryan at technorati.com (Ryan King) Date: Wed Mar 21 09:01:28 2007 Subject: [uf-new] feedback wanted on property listing microformat In-Reply-To: <4CC5C0FB-89F8-4F00-A361-306512AB5415@makedatamakesense.com> References: <7ec7b4220703190950y14034d6n20c37ce07954ec5f@mail.gmail.com> <21e770780703191005x293a569epf14b4d09dae7f05f@mail.gmail.com> <7ec7b4220703191043m6f687782o8c7819dcbd7a0078@mail.gmail.com> <7ec7b4220703200509g4973f3b5o5c0d814c70e043e9@mail.gmail.com> <4CC5C0FB-89F8-4F00-A361-306512AB5415@makedatamakesense.com> Message-ID: <45077A96-0BA0-4FEA-8308-6ED8013792EA@technorati.com> On Mar 20, 2007, at 6:44 AM, Scott Reynen wrote: > On Mar 20, 2007, at 7:09 AM, Michael Biven wrote: > >> On 3/20/07, Ryan King wrote: >> >>> Before proposing that we replace, replicate or extend hListing, >>> please experiment with it on actual examples and provide feedback >>> about its limitations. As of now, your objections are theoretical. >> >> That you can count on. I have to disagree that my point is >> theoretical, but instead it is practical. There is enough common >> fields between each of the different types of real estate listings >> that are not included with hListings, becasue it deals with a much >> larger set of different types of unrelated "things" to list. > > Actual experimentation with hListing is more useful than abstract > discussion. We could go around in circles about whether hListing > would help for months, or someone could actually try it and we > could all see clearly where it works and where it doesn't. The > latter is strongly preferred. ....with documentation on the wiki. -ryan -- Ryan King ryan@technorati.com From msporny at digitalbazaar.com Thu Mar 22 21:38:21 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Mar 22 21:38:25 2007 Subject: [uf-new] Re: Microformat for Music Downloads Message-ID: <460367CD.1090706@digitalbazaar.com> Good to see that there is some renewed discussion in the "we need a music microformat!" debate. I should mention that there has been quite a bit of "in the wild" documentation on the media-info-examples page. We run a digital content store called bitmunk.com, which currently sells digital content for around 63,655 artists - over 848,000 songs. We are also working with the Songbird folks and have been talking about implementing a music microformat for some time. The Firefox team is interested in Microformats as well - music would be a good killer app for them... not to mention the rest of our content partners. We've convinced some of our content partners to adopt a music microformat... so, they're all waiting on one to get settled upon before they switch their websites over. >>> Have you collected any examples to inform this opinion? I should point out that the music download microformat does overlap very heavily with the media-info microformat... but more discussion should help shake things out. We collect stats on our competitors - a month or two ago we uploaded some of those stats to microformats.org - 79 online webstores, 48 of which are still in business, and only around 33 of those are accessible via non-flash/non-HTML interfaces. The data needs to be cleaned up a bit, but you can start to see some strong patterns in what most music websites list. These are the online music commerce sites that were examined: AudioFind, Telstra BigPond, Bitmunk, Download Punk, FYE, iMusic, AON Music , MSN, TDC Online, Audio Lunchbox, Chaos Music, Sony Connect, Digirama, eMusic, FNAC, Sanity, MisRolas, MTV, Musica360, Musicload, Musicmatch (Merged with Yahoo! Jukebox), MusicNet (Service Provider), AOL Music Now (Merged with Napster), Napster, Nate.com (Appears to be Korean, cannot find album examples), Next Radio (Service Provider), PartyMob, Peer Impact, Pure Tracks, Reggae Country, Real/Rhapsody, Ruckus, Sanity, Soundbuzz (Requires MS IE6), Starbucks (Requires Flash 8 player), Starzik SARL, Street CDs (parked domain name), Synacor (Service provider), Telecom Italia (Service provider), Pixbox (Terra) (Windows application), CellCity, top100.cn, Virgin Digital (merged with Napster), Virgin (Requires Windows), Wippit, Yanga Album Statistics: 100%: artist 91%: title 85%: release date 76%: label 70%: web-based purchase 64%: genre 58%: price 55%: cover image 45%: tracks 42%: track list 27%: format 24%: sample 21%: length 15%: physical-based purchase 12%: album rating 12%: summary 12%: reviews 9%: bitrate 9%: publisher 9%: number of tracks 6%: rating 6%: quality 6%: track count 6%: styles 6%: total length 6%: description 6%: long description 6%: add to wishlist 3%: SKU 3%: product id 3%: related albums 3%: regular price 3%: disc count 3%: share 3%: DRM information 3%: add to playlist 3%: price in points 3%: store price 3%: availability 3%: size 3%: album title 3%: style 3%: catalog id 3%: save to playlist 3%: subscriber price 3%: review 3%: comments 3%: catalog ID 3%: payees 3%: album 3%: production credits 3%: add bookmark 3%: UPC 3%: samples (flash) 3%: also bought 3%: total price 3%: non-subscriber price 3%: sample (flash applet) 3%: license 3%: price in credits 3%: p2p-based purchase 3%: web-based purchse 3%: savings 3%: artist rating 3%: purchase (application link) Track Statistics: 88%: title 70%: track number 70%: web-based purchase 64%: sample 64%: price 52%: length 45%: artist 18%: release date 15%: genre 12%: album 12%: format 9%: rating 9%: label 6%: composer 6%: quality 6%: size 6%: comments 6%: album title 3%: DRM information 3%: add to pop-list 3%: genres 3%: song title 3%: payees 3%: add to playlist 3%: label (popup) 3%: description 3%: add bookmark 3%: add to wishlist 3%: file type 3%: tracks 3%: bitrate 3%: total price 3%: sample (flash applet) 3%: publisher 3%: price in credits 3%: performance artist 3%: p2p-based purchase 3%: video sample 3%: web-based purchase link 3%: creators -- manu -- Manu Sporny President/CEO Digital Bazaar, Inc. http://blog.digitalbazaar.com/ From tmbdev at gmail.com Tue Mar 27 23:25:36 2007 From: tmbdev at gmail.com (Thomas Breuel) Date: Tue Mar 27 23:25:37 2007 Subject: [uf-new] announcing the hOCR and hBIB microformats Message-ID: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> We're currently developing a new open source OCR system, with a focus on digital library applications (www.ocropus.org). As part of this, we needed formats for representing both OCR output and bibliographic metadata, and we have defined two new microformats for this purpose: hOCR and hBIB. hOCR is a format for representing OCR output, including layout information, character confidences, bounding boxes, and style information. It embeds this information invisibly in standard HTML. By building on standard HTML, it automatically inherits well-defined support for most scripts, languages, and common layout options. Furthermore, unlike previous OCR formats, the recognized text and OCR-related information co-exist in the same file and survives editing and manipulation. hOCR markup is independent of the presentation. The hBIB format is a microformat that makes it easy to indicate both where a document has been published, as well as to indicate references stored within the document (e.g., for reference lists). It is a straightforward embedding of BibTeX into HTML and should also be useful for making available reference lists and embedding citation information into the output of tools like latex2html. We're starting to make available tools and samples for both formats at: http://code.google.com/p/hocr-tools http://code.google.com/p/hbib-tools Cheers, Thomas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070328/62919733/attachment.html From tantek at cs.stanford.edu Wed Mar 28 00:03:19 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Wed Mar 28 00:03:12 2007 Subject: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> Message-ID: On 3/28/07 12:25 AM, "Thomas Breuel" wrote: > We're currently developing a new open source OCR system, with a focus on > digital library applications (www.ocropus.org). As part of this, we needed > formats for representing both OCR output and bibliographic metadata, and we > have defined two new microformats for this purpose: hOCR and hBIB. Thomas, First of all, welcome, and you have found the right mailing-list to discuss new microformats. Second, that is great news to hear that you are working on an *open source* OCR system. Third, the path to defining a new microformat is through the microformats process: http://microformats.org/wiki/process The goals of the process are to ensure that the microformats defined follow the microformats principles. Among those is to reuse existing work, and thus minimize reinvention. In particular, as far as hBIB, note that the microformats community has done a significant amount of research and work developing a citation microformat. Start with reading these: http://microformats.org/wiki/citation http://microformats.org/wiki/citation-examples http://microformats.org/wiki/citation-formats http://microformats.org/wiki/citation-brainstorming Finally, I strongly encourage you to both read those pages, and ask any questions you have about the process or the citation microformat to date here on the list. I sincerely hope you join the effort to develop a citation microformat and help with your contributions and experience. Thanks and welcome, Tantek From alexkirmse at gmail.com Wed Mar 28 21:37:00 2007 From: alexkirmse at gmail.com (Alex Kirmse) Date: Wed Mar 28 21:37:03 2007 Subject: [uf-new] Interested in the hProduct mf Message-ID: <17241a7a0703282237s2b3f2f23p3a55181864b0b851@mail.gmail.com> Hi, I joined this list after attending the SXSW conference although I had a big interest in microformats before that. I'm specifically interested in hProduct, it's proposed uses and implementations. I read the Wiki on hProduct but I'm interested in brainstorming and discussing this more. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070328/f840b378/attachment.html From brian.suda at gmail.com Wed Mar 28 23:52:07 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed Mar 28 23:52:09 2007 Subject: [uf-new] Interested in the hProduct mf In-Reply-To: <17241a7a0703282237s2b3f2f23p3a55181864b0b851@mail.gmail.com> References: <17241a7a0703282237s2b3f2f23p3a55181864b0b851@mail.gmail.com> Message-ID: <21e770780703290052y413c097fl4ed89aed01bbb78d@mail.gmail.com> On 3/29/07, Alex Kirmse wrote: > Hi, > > I joined this list after attending the SXSW conference although I had a big > interest in microformats before that. I'm specifically interested in > hProduct, it's proposed uses and implementations. I read the Wiki on > hProduct but I'm interested in brainstorming and discussing this more. --- have a look at hListing http://microformats.org/wiki/hlisting it is designed to list products for sale. That would be an ideal start, see what you can mark-up using existing formats. -brian -- brian suda http://suda.co.uk From msporny at digitalbazaar.com Thu Mar 29 11:05:07 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Mar 29 11:05:09 2007 Subject: [uf-new] Microformats for Music, Video and Images discussion with Firefox folks Message-ID: <460C0DE3.4040708@digitalbazaar.com> Just a quick note to mention that we've started a formal discussion with the Firefox folks about the potential for Microformat integration for music, video and images. It is very high-level and focused on brainstorming, but some of you might be interested: https://labs.mozilla.com/forum/index.php/topic,33.0.html Also, the first cut for music example analysis is done: http://microformats.org/wiki/media-info-examples#Analysis_of_Music_Sites We'll be focusing on television, video and film next... If you want to help out, please add links to your favorite online TV, video or film sites here: http://microformats.org/wiki/media-info-examples#Video -- manu -- Manu Sporny Digital Bazaar, Inc. http://blog.digitalbazaar.com/ From supercanadian at gmail.com Thu Mar 29 12:40:54 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu Mar 29 12:41:00 2007 Subject: [uf-new] Microformats for Music, Video and Images discussion with Firefox folks In-Reply-To: <460C0DE3.4040708@digitalbazaar.com> References: <460C0DE3.4040708@digitalbazaar.com> Message-ID: <84ce626f0703291340p753e84acq1155d1e29c2d31b2@mail.gmail.com> Hello, Just an FYI. (In case you weren't aware of it already.) There's been a flurry of e-mails on the WhatWG mailing list about Video in HTML. It might be worth checking out too. See ya On 3/29/07, Manu Sporny wrote: > > Just a quick note to mention that we've started a formal discussion with > the Firefox folks about the potential for Microformat integration for > music, video and images. It is very high-level and focused on > brainstorming, but some of you might be interested: > > https://labs.mozilla.com/forum/index.php/topic,33.0.html > > Also, the first cut for music example analysis is done: > > http://microformats.org/wiki/media-info-examples#Analysis_of_Music_Sites > > We'll be focusing on television, video and film next... If you want to > help out, please add links to your favorite online TV, video or film > sites here: > > http://microformats.org/wiki/media-info-examples#Video > > -- manu > > -- > Manu Sporny > Digital Bazaar, Inc. > http://blog.digitalbazaar.com/ > > -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070329/32599259/attachment.html