From john at proionta.gr Sun Apr 1 16:03:11 2007 From: john at proionta.gr (John) Date: Sun Apr 1 16:03:15 2007 Subject: [uf-new] Proposal: wishlist microformat Message-ID: <46103A2F.8040802@proionta.gr> Similar to the Amazon wishlist, a user would be able to list things that he wants using this microformat. Can be also thought of as an opposite to hlisting. What do the microformats list members think? From scott at makedatamakesense.com Sun Apr 1 16:39:35 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Apr 1 16:39:43 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: <46103A2F.8040802@proionta.gr> References: <46103A2F.8040802@proionta.gr> Message-ID: <329B0352-8485-4894-8486-DD7F74CF4660@makedatamakesense.com> On Apr 1, 2007, at 6:03 PM, John wrote: > Similar to the Amazon wishlist, a user would be able to list things > that he wants using this microformat. Can be also thought of as an > opposite to hlisting. > > What do the microformats list members think? A user can already list things that he wants using HTML. What would you expect machine parsers to do with this information? Or, to quote the process [1]: "Why? There must be a problem to be solved. No problem, no microformat." [1] http://microformats.org/wiki/process -- Scott Reynen MakeDataMakeSense.com From john at proionta.gr Sun Apr 1 17:33:04 2007 From: john at proionta.gr (John) Date: Sun Apr 1 17:33:09 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: <329B0352-8485-4894-8486-DD7F74CF4660@makedatamakesense.com> References: <46103A2F.8040802@proionta.gr> <329B0352-8485-4894-8486-DD7F74CF4660@makedatamakesense.com> Message-ID: <46104F40.8050706@proionta.gr> Scott Reynen wrote: > On Apr 1, 2007, at 6:03 PM, John wrote: > >> Similar to the Amazon wishlist, a user would be able to list things >> that he wants using this microformat. Can be also thought of as an >> opposite to hlisting. >> >> What do the microformats list members think? > > A user can already list things that he wants using HTML. What would > you expect machine parsers to do with this information? Or, to quote > the process [1]: > > "Why? > There must be a problem to be solved. No problem, no microformat." There is a problem. Many auction websites have a "wanted" section, where people can post what they want. They usually go unnoticed because they're relatively few and it's very unlikely that someone will have one of the items listed there. It would be nice if a bot would check my wishlist periodically and search the web for matching hlistings (or matching sellers at a different auctions site) and notify me about it if I want to. It could also have other uses, but I'm keeping those a secret for the time being, I think one reason should be enough, no? From alexander.graf at deri.org Sun Apr 1 18:49:06 2007 From: alexander.graf at deri.org (Alexander Graf) Date: Sun Apr 1 18:49:30 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: <46104F40.8050706@proionta.gr> References: <46103A2F.8040802@proionta.gr> <329B0352-8485-4894-8486-DD7F74CF4660@makedatamakesense.com> <46104F40.8050706@proionta.gr> Message-ID: <6090B321-0FE4-4494-B538-F32BEFB10A2E@deri.org> > There is a problem. > > Many auction websites have a "wanted" section, where people can > post what they want. They usually go unnoticed because they're > relatively few and it's very unlikely that someone will have one of > the items listed there. It would be nice if a bot would check my > wishlist periodically and search the web for matching hlistings (or > matching sellers at a different auctions site) and notify me about > it if I want to. > > It could also have other uses, but I'm keeping those a secret for > the time being, I think one reason should be enough, no? You will still have to tell your crawler the urls it should crawl, it can't crawl the whole web and find only *your* wishlists. So, if the crawler knows the URL to look at, it doesn't matter how the content is marked up, semantically. XOXO and/or hReview for items is enough. The crawler looks at all hReview entries on the page and stores them in a database. Then it can do whatever you want it to. Best, Alex From scott at makedatamakesense.com Sun Apr 1 20:17:33 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Apr 1 20:17:41 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: <46104F40.8050706@proionta.gr> References: <46103A2F.8040802@proionta.gr> <329B0352-8485-4894-8486-DD7F74CF4660@makedatamakesense.com> <46104F40.8050706@proionta.gr> Message-ID: On Apr 1, 2007, at 7:33 PM, John wrote: > Scott Reynen wrote: >> On Apr 1, 2007, at 6:03 PM, John wrote: >> >>> Similar to the Amazon wishlist, a user would be able to list >>> things that he wants using this microformat. Can be also thought >>> of as an opposite to hlisting. >>> >>> What do the microformats list members think? >> >> A user can already list things that he wants using HTML. What >> would you expect machine parsers to do with this information? Or, >> to quote the process [1]: >> >> "Why? >> There must be a problem to be solved. No problem, no microformat." > > There is a problem. > > Many auction websites have a "wanted" section, where people can > post what they want. They usually go unnoticed because they're > relatively few and it's very unlikely that someone will have one of > the items listed there. Can you point to some examples of these wanted lists on auction websites? Generally if they're relatively few, they're not appropriate for a microformat (which targets the "low-hanging fruit" of widely published data), but maybe these lists share semantics with some type of information published more widely (e.g. job listings are a sort of wanted list). I'm still not very clear on what we're talking about and it would be helpful to see some examples. -- Scott Reynen MakeDataMakeSense.com From paul_wilkins at xtra.co.nz Mon Apr 2 00:21:02 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Mon Apr 2 00:21:18 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: References: <46103A2F.8040802@proionta.gr> <329B0352-8485-4894-8486-DD7F74CF4660@makedatamakesense.com> <46104F40.8050706@proionta.gr> Message-ID: <4610AEDE.9070202@xtra.co.nz> Scott Reynen wrote: > On Apr 1, 2007, at 7:33 PM, John wrote: > >> Many auction websites have a "wanted" section, where people can post >> what they want. They usually go unnoticed because they're relatively >> few and it's very unlikely that someone will have one of the items >> listed there. > > > Can you point to some examples of these wanted lists on auction > websites? Generally if they're relatively few, they're not > appropriate for a microformat (which targets the "low-hanging fruit" > of widely published data), but maybe these lists share semantics with > some type of information published more widely (e.g. job listings are > a sort of wanted list). I'm still not very clear on what we're > talking about and it would be helpful to see some examples. It seems to me that wanted sections, wish-lists and jobs wanted would all fall under the classification of classifieds. -- Paul Wilkins From tantek at cs.stanford.edu Mon Apr 2 01:36:06 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Apr 2 01:36:54 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: <4610AEDE.9070202@xtra.co.nz> Message-ID: On 4/2/07 12:21 AM, "Paul Wilkins" wrote: > It seems to me that wanted sections, wish-lists and jobs wanted would > all fall under the classification of classifieds. Indeed, an unordered (or perhaps ordered for importance) list of hListings would seem to solve the 80/20 of wish-list problems. http://microformats.org/wiki/hlisting Thanks, Tantek From john at proionta.gr Mon Apr 2 03:17:26 2007 From: john at proionta.gr (John) Date: Mon Apr 2 03:17:31 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: <6090B321-0FE4-4494-B538-F32BEFB10A2E@deri.org> References: <46103A2F.8040802@proionta.gr> <329B0352-8485-4894-8486-DD7F74CF4660@makedatamakesense.com> <46104F40.8050706@proionta.gr> <6090B321-0FE4-4494-B538-F32BEFB10A2E@deri.org> Message-ID: <4610D836.4060107@proionta.gr> Alexander Graf wrote: >> There is a problem. >> >> Many auction websites have a "wanted" section, where people can post >> what they want. They usually go unnoticed because they're relatively >> few and it's very unlikely that someone will have one of the items >> listed there. It would be nice if a bot would check my wishlist >> periodically and search the web for matching hlistings (or matching >> sellers at a different auctions site) and notify me about it if I >> want to. >> >> It could also have other uses, but I'm keeping those a secret for the >> time being, I think one reason should be enough, no? > > You will still have to tell your crawler the urls it should crawl, it > can't crawl the whole web and find only *your* wishlists. So, if the > crawler knows the URL to look at, it doesn't matter how the content is > marked up, semantically. XOXO and/or hReview for items is enough. The > crawler looks at all hReview entries on the page and stores them in a > database. Then it can do whatever you want it to. But how would a spider know that a XOXO list that it retrieves is a wishlist and not something else? For example, I can have two XOXO lists in a webpage, one being a wishlist and another being items I have for sale. How will the crawler know which is which? Shouldn't the markup state whether an item is for sale or wanted or simply a review by the page author? If not, won't lots of mistaken interpretations happen? From john at proionta.gr Mon Apr 2 03:32:26 2007 From: john at proionta.gr (John) Date: Mon Apr 2 03:32:30 2007 Subject: [uf-new] Proposal: wishlist microformat In-Reply-To: References: Message-ID: <4610DBBA.1010600@proionta.gr> Tantek ?elik wrote: > On 4/2/07 12:21 AM, "Paul Wilkins" wrote: > > >> It seems to me that wanted sections, wish-lists and jobs wanted would >> all fall under the classification of classifieds. >> > > Indeed, an unordered (or perhaps ordered for importance) list of hListings > would seem to solve the 80/20 of wish-list problems. > > http://microformats.org/wiki/hlisting > You are right, and I'm sorry - I just saw that hlisting's "listing action" can take a value of "wanted". :-) - John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070402/b6bbb671/attachment.html From michael.mccracken at gmail.com Mon Apr 2 12:57:41 2007 From: michael.mccracken at gmail.com (Michael McCracken) Date: Mon Apr 2 12:57:45 2007 Subject: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> Message-ID: Hi Thomas, I've taken a look at the hBib documentation available at https://misc.iupr.org/docs/doku.php?id=pub:hocr:bibtex-microformat and I would like to comment on a couple of things: First of all, the citation microformat process is continuing, just slowly. The wiki pages are a little confusing if you haven't been following the mailing list discussions - this reflects a lack of time to clean it up. A note at the top of the iupr.org page says that the citation-formats page contains proposals for the citation microformat. This isn't the case - that page is research on existing formats that have been in use elsewhere. The actual work towards an official citation microformat is going on in the citation-brainstorming page, in the section "working straw schema": http://microformats.org/wiki?title=citation-brainstorming#Working_straw_schema That working format is currently very close to doing everything that a bibtex-based format can do. I have code in BibDesk that generates that working format and reads it in and translates it to bibtex. I strongly suggest looking there and working with us on the straw schema instead of doing something different based on BibTeX. If you produce content that uses the straw schema, the currently shipping version of BibDesk can read it. I appreciate the desire to get something working now, but I'd like to emphasize that we're really close, and if you help, we can have one working format soon instead of two immediately. Thanks, -mike PS, in case it's not familiar, BibDesk is a reference management app for OS X at bibdesk.sf.net 2007/3/28, Tantek ?elik : > 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 > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From tmbdev at gmail.com Tue Apr 3 06:40:58 2007 From: tmbdev at gmail.com (Thomas Breuel) Date: Tue Apr 3 06:41:02 2007 Subject: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> Message-ID: <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> > That working format is currently very close to doing everything that a > bibtex-based format can do. I have code in BibDesk that generates that > working format and reads it in and translates it to bibtex. I don't see how either of those statements can be true. For example, BibTeX incorporates a lot of knowledge and constraints about what kinds of documents can be cited and what fields mean for those cases, but Straw doesn't define that. Furthermore, Straw ignores the issue of markup (math, chemistry, mixed scripts/styles, etc.) in citations. And Straw attempts to enforce the use of semantic markup for fields like dates. As a result, different converters might convert BibTeX->Straw and Straw->BibTeX inconsistently, conversions may not render correctly, and, worse yet, converters often probably won't even notice when they're altering citations. In practice (and I've seen this a number of times), converters just end up handling the common cases and leave the rest to manual cleanup. The basic problem with Straw is that, at the same time as defining how to encapsulate citations in HTML, it introduces yet another citation format with yet slightly different semantics from all previous citation formats; no citation manager understands Straw semantics and there is no existing practice. I think encapsulating BibTeX and other formats in microformats is a better approach, since existing citation managers already know how to deal with BibTeX semantics and the problem reduces to one of syntactic and markup conversion (which is hard enough). In any case, in the short term, we've already independently decided to go with Dublin Core for the document metadata for the current collection of documents we're dealing with (and DC already has well-defined embeddings in HTML), so this issue is less pressing. But in the long term, when we will be recognizing and extracting citations from OCR'ed papers, it will be impossible to fully conform with a format like Straw. I'll add some more comments to the Wiki. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070403/d1aba4f6/attachment-0001.html From scott at makedatamakesense.com Tue Apr 3 07:11:15 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Apr 3 07:11:20 2007 Subject: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> Message-ID: <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> On Apr 3, 2007, at 8:40 AM, Thomas Breuel wrote: >> That working format is currently very close to doing everything >> that a >> bibtex-based format can do. I have code in BibDesk that generates >> that >> working format and reads it in and translates it to bibtex. > > I don't see how either of those statements can be true. For > example, BibTeX incorporates a lot of knowledge and constraints > about what kinds of documents can be cited and what fields mean for > those cases, but Straw doesn't define that. Furthermore, Straw > ignores the issue of markup (math, chemistry, mixed scripts/styles, > etc.) in citations. And Straw attempts to enforce the use of > semantic markup for fields like dates. As a result, different > converters might convert BibTeX->Straw and Straw->BibTeX > inconsistently Can you provide some examples of these inconsistencies? I'm not clear on the problems you're describing. Also, "straw" is not the name of a format; it's a generic term for a format not complete enough to warrant naming. Similar to a "straw man," [1] it exists primarily to be torn apart, e.g. with arguments about what is wrong with it. The goal is for an iterative process to encourage collaboration. If you're open to such collaboration, you're input would not doubt be valuable. > I'll add some more comments to the Wiki. Please do. [1] http://en.wikipedia.org/wiki/Straw_man -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Wed Apr 4 06:55:42 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Apr 4 06:55:22 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> Message-ID: <1175694942.21745.23.camel@localhost.localdomain> I have been reading the discussion on a new microformat for music downloads here http://microformats.org/discuss/mail/microformats-new/2007-March/000028.html this is what encouraged me to join this discussion. I have tried to implement this method using existing microformats by using a combination of hAtom and hReview. >From one static web page, we can get a Atom 1.0 feed via tools.microformatic.com and then taking the resulting feed and transforming it into a podcast via Feedburner. an example of the markup I used is here :http://weborganics.co.uk/files/podtest.html. A working live example can be viewed here. http://weborganics.co.uk/podcast/ To answer Marian's question do we need a "Microformat for Music Downloads" I would say no there are enough existing Microformats to do the job. I might suggest that we add extra properties to the hReview Microformat to include, artist, and object. I hope this is of some help Kind Regards Martin McEvoy From msporny at digitalbazaar.com Wed Apr 4 08:26:00 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Apr 4 08:26:04 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <1175694942.21745.23.camel@localhost.localdomain> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> Message-ID: <4613C388.8050605@digitalbazaar.com> Martin McEvoy wrote: > To answer Marian's question do we need a "Microformat for Music > Downloads" I would say no there are enough existing Microformats to do > the job. I might suggest that we add extra properties to the hReview > Microformat to include, artist, and object. Martin, If the only fields that we have to contend with are artist and object, I would agree with you. However, if you take a look at the types of fields that we are dealing with for music: http://microformats.org/wiki/media-info-examples#Analysis_of_Music_Sites It starts to become evident that semantically describing music is much different that describing feeds (hAtom) and reviews (hReview). hAtom is for feeds, which music items are usually not. hReview is for single reviews - usually there is always more than one comment on a page regarding an album (there are multiple hReviews per music item). In the very least, we need to consider the following: For albums: artist, title, tracks, release date, label, genre, web-based purchase, cover image For songs: artist, title, release date, label, genre, web-based purchase, cover image, track number, sample link, price, length Analysis of over 85 music sites have shown that those are the norm - and I can't see them fitting neatly into hAtom or hReview. Can anybody think of any combination of existing Microformat mappings that would work for the fields listed above? -- manu From davidjanes at blogmatrix.com Wed Apr 4 09:48:47 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Wed Apr 4 09:48:50 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <4613C388.8050605@digitalbazaar.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> Message-ID: <21e523c20704040948x42640f37rb3661ee9f2434dee@mail.gmail.com> On 4/4/07, Manu Sporny wrote: > Martin McEvoy wrote: > > To answer Marian's question do we need a "Microformat for Music > > Downloads" I would say no there are enough existing Microformats to do > > the job. I might suggest that we add extra properties to the hReview > > Microformat to include, artist, and object. > > Martin, > > If the only fields that we have to contend with are artist and object, I > would agree with you. However, if you take a look at the types of fields > that we are dealing with for music: > > http://microformats.org/wiki/media-info-examples#Analysis_of_Music_Sites > > It starts to become evident that semantically describing music is much > different that describing feeds (hAtom) and reviews (hReview). hAtom is > for feeds, which music items are usually not. hReview is for single > reviews - usually there is always more than one comment on a page > regarding an album (there are multiple hReviews per music item). hAtom is for describing blog posts and similar microcontent. Feeds are entirely incidental. Regards, etc... David From scott at makedatamakesense.com Wed Apr 4 09:58:33 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Apr 4 09:58:35 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <4613C388.8050605@digitalbazaar.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> Message-ID: <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> On Apr 4, 2007, at 10:26 AM, Manu Sporny wrote: > Martin, > > If the only fields that we have to contend with are artist and > object, I > would agree with you. However, if you take a look at the types of > fields > that we are dealing with for music: > > http://microformats.org/wiki/media-info- > examples#Analysis_of_Music_Sites I think Martin was talking about this problem: http://microformats.org/wiki/music-examples#The_Problem Which is much simpler than the media info problem: http://microformats.org/wiki/media-info-brainstorming#The_Problem > It starts to become evident that semantically describing music is much > different that describing feeds (hAtom) and reviews (hReview). > hAtom is > for feeds, which music items are usually not. hAtom is not only for feeds; it's for "practically any other place Atom may be used," and feeds are only the most prominent example of that. hAtom contains a title, description, and item for download, which is very close to what's needed for music downloads. > Analysis of over 85 music sites have shown that those are the norm Many of the sites you surveyed don't have audio downloads available, so while they may be relevant to the media-info work, they're outside the scope of music downloads. > - and > I can't see them fitting neatly into hAtom or hReview. Can anybody > think > of any combination of existing Microformat mappings that would work > for > the fields listed above? I think media-info will likely need a new format, as it's relatively broad in scope. But music downloads is a simpler problem, and I think Martin did a great job of demonstrating that we can solve most of it with existing microformats. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Wed Apr 4 11:27:29 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Apr 4 11:27:32 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> Message-ID: <4613EE11.7090107@digitalbazaar.com> Scott Reynen wrote: > I think Martin was talking about this problem: > http://microformats.org/wiki/music-examples#The_Problem > > Which is much simpler than the media info problem: > http://microformats.org/wiki/media-info-brainstorming#The_Problem I'm probably being dense. The problem description on music-examples seems like a subset of the problem description in media-info. Am I misunderstanding the problem description on either page? Can anybody help clarify the difference between the two? > hAtom is not only for feeds; it's for "practically any other place Atom > may be used," and feeds are only the most prominent example of that. > hAtom contains a title, description, and item for download, which is > very close to what's needed for music downloads. Agreed, but I didn't think that it was the sole purpose for the music-examples problem description. Again, am I misunderstanding the problem description for music-examples? I've spoken with Dean Hudson at SubPop (one of the authors of the music-examples page) and my understanding of what he was shooting for didn't include anything in the hAtom/hReview ballpark. It was more complicated. It seemed to me that music-examples problem description was a subset of media-info... I can talk to him again... perhaps Rod Begbie could clarify the difference between the two as well? > Many of the sites you surveyed don't have audio downloads available, so > while they may be relevant to the media-info work, they're outside the > scope of music downloads. Are we differentiating a sample from a download? If so, what makes that differentiation? In dealing with music and video thus far, a pattern is starting to emerge that shows no strong overlap between the two. It is still too early to tell, more research will have to be done, but it looks like music and video are not sharing many common pieces of information - there is around a 50% overlap in the meta-data between the two formats. If we were to take all of the results from music and video and analyze them together the resulting media-info microformat would look different than one where we created a music-media-info microformat and a video-media-info microformat. It seems like there might be evidence for a separate music-media-info and a video-media-info microformat. I'm assuming the community doesn't want to do something like that, correct? -- manu From scott at makedatamakesense.com Wed Apr 4 11:57:45 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Apr 4 11:57:48 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <4613EE11.7090107@digitalbazaar.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <4613EE11.7090107@digitalbazaar.com> Message-ID: On Apr 4, 2007, at 1:27 PM, Manu Sporny wrote: > Scott Reynen wrote: >> I think Martin was talking about this problem: >> http://microformats.org/wiki/music-examples#The_Problem >> >> Which is much simpler than the media info problem: >> http://microformats.org/wiki/media-info-brainstorming#The_Problem > > I'm probably being dense. The problem description on music-examples > seems like a subset of the problem description in media-info. Am I > misunderstanding the problem description on either page? > > Can anybody help clarify the difference between the two? This is how I see the distinction: Music downloads is only the information necessary to know whether or not a download is desired. Media info is general information about media, which may be used to identify where the same media is being referenced in multiple places, and retrieve addition information about that media. Most of music downloads is a subset of media info (and should remain a subset, as smaller problems are easier to solve). But the actual download URL doesn't appear to be necessary in media info, whereas it is the most important property of music downloads. >> hAtom is not only for feeds; it's for "practically any other place >> Atom >> may be used," and feeds are only the most prominent example of that. >> hAtom contains a title, description, and item for download, which is >> very close to what's needed for music downloads. > > Agreed, but I didn't think that it was the sole purpose for the > music-examples problem description. Again, am I misunderstanding the > problem description for music-examples? I've spoken with Dean > Hudson at > SubPop (one of the authors of the music-examples page) and my > understanding of what he was shooting for didn't include anything > in the > hAtom/hReview ballpark. It was more complicated. It seemed to me that > music-examples problem description was a subset of media-info... I can > talk to him again... perhaps Rod Begbie could clarify the difference > between the two as well? Let's just make sure we're not revising the problem to fit a solution. >> Many of the sites you surveyed don't have audio downloads >> available, so >> while they may be relevant to the media-info work, they're outside >> the >> scope of music downloads. > > Are we differentiating a sample from a download? If so, what makes > that > differentiation? I'm not making that differntiation. There are plenty of examples in your media-info list, e.g. MusicBrainz, which contain no links to audio of any sort, only descriptions of audio. > If we were to take all of the results from music and video and analyze > them together the resulting media-info microformat would look > different > than one where we created a music-media-info microformat and a > video-media-info microformat. It seems like there might be evidence > for > a separate music-media-info and a video-media-info microformat. I'm > assuming the community doesn't want to do something like that, > correct? Breaking down larger problems into smaller problems is part of the microformats process. We may not want to do that, as it would sure be nice to have one huge format to describe everything. Nonetheless, we should always start with smaller problems where we can. Still, I think there's a difference between music metadata and music downloads. If we're no longer focusing on solving the music downloads problem (i.e. how do I know what I'm downloading?), we should change the subject of this thread to reflect that. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Wed Apr 4 12:39:03 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Apr 4 12:38:53 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> Message-ID: <1175715543.23767.27.camel@localhost.localdomain> On Wed, 2007-04-04 at 11:58 -0500, Scott Reynen wrote: > On Apr 4, 2007, at 10:26 AM, Manu Sporny wrote: > > > Martin, > > > > If the only fields that we have to contend with are artist and > > object, I > > would agree with you. However, if you take a look at the types of > > fields > > that we are dealing with for music: > > > > http://microformats.org/wiki/media-info- > > examples#Analysis_of_Music_Sites > > I think Martin was talking about this problem: > > http://microformats.org/wiki/music-examples#The_Problem Yes I was referring more to this problem, a was thinking more along the lines of playing the content in a music player such as iTunes or Amarok directly from a blog or Artist's website and being able to read a review about the track you are listening to either as a feed or by viewing the web page its self. > > Which is much simpler than the media info problem: > > http://microformats.org/wiki/media-info-brainstorming#The_Problem > >From what I understand so far is this about the actual file itself? maybe the media-info should relate more to the metadata attached to the file itself and should follow the lines if already widely used formats such as idv3. > > It starts to become evident that semantically describing music is much > > different that describing feeds (hAtom) and reviews (hReview). > > hAtom is > > for feeds, which music items are usually not. > > hAtom is not only for feeds; it's for "practically any other place > Atom may be used," and feeds are only the most prominent example of > that. hAtom contains a title, description, and item for download, > which is very close to what's needed for music downloads. > > > Analysis of over 85 music sites have shown that those are the norm > > Many of the sites you surveyed don't have audio downloads available, > so while they may be relevant to the media-info work, they're outside > the scope of music downloads. > > > - and > > I can't see them fitting neatly into hAtom or hReview. Can anybody > > think > > of any combination of existing Microformat mappings that would work > > for > > the fields listed above? > > I think media-info will likely need a new format, as it's relatively > broad in scope. But music downloads is a simpler problem, and I > think Martin did a great job of demonstrating that we can solve most > of it with existing microformats. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Wed Apr 4 14:44:20 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Apr 4 14:44:23 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <4613EE11.7090107@digitalbazaar.com> Message-ID: <46141C34.10306@digitalbazaar.com> Scott Reynen wrote: > This is how I see the distinction: Music downloads is only the > information necessary to know whether or not a download is desired. > Media info is general information about media, which may be used to > identify where the same media is being referenced in multiple places, > and retrieve addition information about that media. Most of music > downloads is a subset of media info (and should remain a subset, as > smaller problems are easier to solve). But the actual download URL > doesn't appear to be necessary in media info, whereas it is the most > important property of music downloads. If that is what the Music Downloads microformat proposal was intended to do, then I agree with you and Martin. The problem description on the Music Downloads examples page: "Publishers of audio files annotate them with visible data about the audio, so users know who they're from and whether or not they want the files. A format that semantically marked up existing info about audio would allow software such as a CD playing program to parse and index that information from the respective web page (c/f CDDB (http://en.wikipedia.org/wiki/CDDB))." It is not clear from this description that it means what you and Martin believe it to be. I think the Music Download uF is suffering from a vague problem description. > Let's just make sure we're not revising the problem to fit a solution. I agree, we shouldn't revise the problem. We should clarify the definition of the problem. If it is what you and Martin are stating it is, then I don't see a need for a Music Download microformat as what Martin proposed is adequate. However, if the scope is larger than that, then it should be discussed in more depth. > I'm not making that differntiation. There are plenty of examples in > your media-info list, e.g. MusicBrainz, which contain no links to audio > of any sort, only descriptions of audio. If we are not going to make that differentiation, then 67% of all music sites have a "sample" link. 62% have an acquisition method (web-based purchase/download). Combined, it's well over 80%. There are more examples of having a download link than not having one for media-info. This seems to imply that even if a Music Download uF were to exist, it would be a subset of media-info. > Breaking down larger problems into smaller problems is part of the > microformats process. We may not want to do that, as it would sure be > nice to have one huge format to describe everything. Isn't that contrary to the Microformat way? :) I agree with you - it would be nice to have a universal method of identifying media. I think it is possible to have a small flexible format that applies to music, video and images - as there is overlap. > Still, I think > there's a difference between music metadata and music downloads. Agreed. > If > we're no longer focusing on solving the music downloads problem (i.e. > how do I know what I'm downloading?), we should change the subject of > this thread to reflect that. Let's make sure that "Music Downloads" really means music downloads and not "Music Metadata" before we change the thread. -- manu From msporny at digitalbazaar.com Wed Apr 4 14:56:17 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Apr 4 14:56:21 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <1175715543.23767.27.camel@localhost.localdomain> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> Message-ID: <46141F01.1070600@digitalbazaar.com> Martin McEvoy wrote: > Yes I was referring more to this problem, a was thinking more along the > lines of playing the content in a music player such as iTunes or Amarok > directly from a blog or Artist's website and being able to read a review > about the track you are listening to either as a feed or by viewing the > web page its self. Have you used Songbird yet, Martin? It is a great use case example of what you are describing. It gets the information by ripping the MP3s off of a site and reading their IDv3 tags. After talking with their developers and some of the Firefox guys - they seem more keen on using media-info to do this than Music Download. I think the use case you are looking at supporting is more of a Democracy Player/Songbird angle on the problem? Subscribe to an RSS feed or point it at a web page and the player automatically identifies the media on the page for playback? Am I understanding you correctly? > From what I understand so far is this about the actual file itself? > maybe the media-info should relate more to the metadata attached to the > file itself and should follow the lines if already widely used formats > such as idv3. media-info is less about the actual file itself, and more about the metadata regarding the file: artist, title, publisher, runtime length, associated image data, etc. There is some discussion if media-info should include the file information as well - we might want to split that into a separate microformat. The format of a file has very little to do with what the file is about. For example: a song can be represented as an MP3 audio file, or an MPEG-2 music video. I don't know if Music Download is about the file itself or the metadata associated with the file. Or both? -- manu From scott at makedatamakesense.com Wed Apr 4 15:34:42 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Apr 4 15:34:45 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <46141C34.10306@digitalbazaar.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <4613EE11.7090107@digitalbazaar.com> <46141C34.10306@digitalbazaar.com> Message-ID: <46346A53-4A57-475E-BF70-D9949D8FD991@makedatamakesense.com> On Apr 4, 2007, at 4:44 PM, Manu Sporny wrote: >> Breaking down larger problems into smaller problems is part of the >> microformats process. We may not want to do that, as it would >> sure be >> nice to have one huge format to describe everything. > > Isn't that contrary to the Microformat way? :) Yeah, that was my point. Our first instinct is generally to try to add more, because we want more published. But microformats work best by adding less, because publishers are more likely to use simpler standards. So we need to always keep that instinct to add more in check. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Wed Apr 4 16:06:31 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Apr 4 16:06:12 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <46141F01.1070600@digitalbazaar.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> Message-ID: <1175727991.25172.20.camel@localhost.localdomain> On Wed, 2007-04-04 at 17:56 -0400, Manu Sporny wrote: > Martin McEvoy wrote: > > Yes I was referring more to this problem, a was thinking more along the > > lines of playing the content in a music player such as iTunes or Amarok > > directly from a blog or Artist's website and being able to read a review > > about the track you are listening to either as a feed or by viewing the > > web page its self. > > Have you used Songbird yet, Martin? It is a great use case example of > what you are describing. It gets the information by ripping the MP3s off > of a site and reading their IDv3 tags. After talking with their > developers and some of the Firefox guys - they seem more keen on using > media-info to do this than Music Download. > Yes I have seen and used Songbird it has been inspiring and excellent at what it does....but not everyone is likely to use Songbird (just yet) as their choice player and I would like my visitors to be able to play the content of my website regardless of which web browser or player they use. > I think the use case you are looking at supporting is more of a > Democracy Player/Songbird angle on the problem? Subscribe to an RSS feed > or point it at a web page and the player automatically identifies the > media on the page for playback? Am I understanding you correctly? > > > From what I understand so far is this about the actual file itself? > > maybe the media-info should relate more to the metadata attached to the > > file itself and should follow the lines if already widely used formats > > such as idv3. > > media-info is less about the actual file itself, and more about the > metadata regarding the file: artist, title, publisher, runtime length, > associated image data, etc. right! I get it :) > > There is some discussion if media-info should include the file > information as well - we might want to split that into a separate > microformat. The format of a file has very little to do with what the > file is about. For example: a song can be represented as an MP3 audio > file, or an MPEG-2 music video. isn't rel="enclosure" type="audio/mpeg" sufficient enough to do this then? maybe just adding length="198000" or something ? > > I don't know if Music Download is about the file itself or the metadata > associated with the file. Or both? I think maybe both. but not all audio is music it could be speech or sound effects so maybe not....hmm Its such a broad spectrum to consider that I think we will have no choice but to create both. > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Thu Apr 5 07:53:09 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Apr 5 07:53:12 2007 Subject: [uf-new] Separating File Content from File Format Message-ID: <46150D55.2080401@digitalbazaar.com> Apologies if this subject has already been discussed - I couldn't find anywhere that it was: What is the Microformat approach to describing file format vs. describing file content? The media-info-brainstorming page lists several pieces of file-format information that should be described: format (MP3, FLAC, OGG), audio codec, video codec, bit rate, size We should consider separating file content from file format - there is more on this concept here: http://microformats.org/wiki/media-info-brainstorming#Differentiating_File_Content_from_File_Format It seems that Microformats tend to focus on content, not format. However, it is desirable at times to specify the format of a particular file. Has this subject been discussed before? Do we need a file-format Microformat? -- manu From msporny at digitalbazaar.com Thu Apr 5 07:56:11 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Apr 5 07:56:14 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <1175727991.25172.20.camel@localhost.localdomain> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> Message-ID: <46150E0B.3030304@digitalbazaar.com> Martin McEvoy wrote: > Yes I have seen and used Songbird it has been inspiring and excellent at > what it does....but not everyone is likely to use Songbird (just yet) as > their choice player and I would like my visitors to be able to play the > content of my website regardless of which web browser or player they > use. media-info will definitely solve this problem once it is finalized. That being said, does that invalidate the need for Music Download microformat? Based on Stephen and your problem definition for Music Download, and with your addition below, I think it does. > isn't rel="enclosure" type="audio/mpeg" sufficient enough to do this > then? maybe just adding length="198000" or something ? That is a good, simple solution. 'rel' and 'type' are standard elements and would aid a browser in recognizing that you are talking about an MP3 file... Amarok/iTunes could detect an hAtom/hReview combo with a type="audio/mpeg" link. It would be difficult for it to recognize artist/track information - wouldn't it? Wouldn't that have to be standardized to some degree? While we can use hAtom/hReview to do this - it seems a bit like a band-aid... media-info being the real solution to this problem. Do you agree or disagree? The Atom standard defines "length" for content, so it wouldn't be a stretch to imagine that being an optional element of hAtom? The question is... do we want to add that to hAtom? Probably not at this point - this seems to be the only supporting case of needing to define length. -- manu From scott at makedatamakesense.com Thu Apr 5 08:17:49 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Thu Apr 5 08:18:10 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <46150E0B.3030304@digitalbazaar.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> <46150E0B.3030304@digitalbazaar.com> Message-ID: <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> On Apr 5, 2007, at 9:56 AM, Manu Sporny wrote: > media-info will definitely solve this problem once it is finalized. > That > being said, does that invalidate the need for Music Download > microformat? Based on Stephen and your problem definition for Music > Download, and with your addition below, I think it does. I think this is backwards. We shouldn't delay solving the simpler problem until the more complex problem is solved. We should solve the simpler problem first, and make that solution a modular part of the more complex solution. >> isn't rel="enclosure" type="audio/mpeg" sufficient enough to do this >> then? maybe just adding length="198000" or something ? > > That is a good, simple solution. 'rel' and 'type' are standard > elements and would aid a browser in recognizing that you are talking > about an MP3 file... Amarok/iTunes could detect an hAtom/hReview combo > with a type="audio/mpeg" link. It would be difficult for it to > recognize > artist/track information - wouldn't it? Wouldn't that have to be > standardized to some degree? While we can use hAtom/hReview to do > this - > it seems a bit like a band-aid... media-info being the real > solution to > this problem. Do you agree or disagree? I agree that artist and track information are still needed, but disagree that this in some way reduces the value in reusing existing standards. We can and should reuse existing standards *and* add artist and track information. > The Atom standard defines "length" for content, so it wouldn't be a > stretch to imagine that being an optional element of hAtom? The > question > is... do we want to add that to hAtom? Even before asking that, the question is: is length a property we need to add at all? It shows up in just over half of surveyed sites, a bit short of our rough 80% benchmark. We can always add more later, so we should start as simple as possible. Maybe that means including length, but maybe it doesn't. We shouldn't be adding properties just because we can. -- Scott Reynen MakeDataMakeSense.com From supercanadian at gmail.com Thu Apr 5 11:44:44 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu Apr 5 11:44:48 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <46150D55.2080401@digitalbazaar.com> References: <46150D55.2080401@digitalbazaar.com> Message-ID: <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> Hello Manu On 4/5/07, Manu Sporny wrote: > Apologies if this subject has already been discussed - I couldn't find > anywhere that it was: > > What is the Microformat approach to describing file format vs. > describing file content? > > The media-info-brainstorming page lists several pieces of file-format > information that should be described: > > format (MP3, FLAC, OGG), audio codec, video codec, bit rate, size > > We should consider separating file content from file format - there is > more on this concept here: > > http://microformats.org/wiki/media-info-brainstorming#Differentiating_File_Content_from_File_Format > > It seems that Microformats tend to focus on content, not format. > However, it is desirable at times to specify the format of a particular > file. Has this subject been discussed before? Do we need a file-format > Microformat? > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___________________________________________________________________________ Make Television http://maketelevision.com/ ___________________________________________________________________________ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/ From supercanadian at gmail.com Thu Apr 5 11:49:44 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu Apr 5 11:49:47 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> Message-ID: <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> Hello Manu, (Sorry for the last message... my mouse pointer was over the "send" button while I was starting to type the message... and it seemed to have accidentally gotten pressed.) This topic has come up before. One of the things that got noted is that the HTML anchor element -- -- has a type attribute that can be used to describe the type of the content. So, for example... ... Or... ... You can do other sophisticated stuff with the "type" attribute to... since it holds a "Content Type" and not just a "MIME type". So you can add parameters to it too. See ya On 4/5/07, Charles Iliya Krempeaux wrote: > Hello Manu > > On 4/5/07, Manu Sporny wrote: > > Apologies if this subject has already been discussed - I couldn't find > > anywhere that it was: > > > > What is the Microformat approach to describing file format vs. > > describing file content? > > > > The media-info-brainstorming page lists several pieces of file-format > > information that should be described: > > > > format (MP3, FLAC, OGG), audio codec, video codec, bit rate, size > > > > We should consider separating file content from file format - there is > > more on this concept here: > > > > http://microformats.org/wiki/media-info-brainstorming#Differentiating_File_Content_from_File_Format > > > > It seems that Microformats tend to focus on content, not format. > > However, it is desirable at times to specify the format of a particular > > file. Has this subject been discussed before? Do we need a file-format > > Microformat? > > > > -- manu -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com From scott at makedatamakesense.com Thu Apr 5 12:46:34 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Thu Apr 5 12:46:48 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> Message-ID: <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> On Apr 5, 2007, at 1:49 PM, Charles Iliya Krempeaux wrote: > You can do other sophisticated stuff with the "type" attribute to... > since it holds a "Content Type" and not just a "MIME type". So you > can add parameters to it too. The distinction between "content type" and "MIME type" doesn't seem very clear in the HTML spec: http://www.w3.org/TR/html401/types.html#type-content-type The header "Content types (MIME types)" seems to suggest they're interchangeable terms, though they're apparently not as "text/html; charset=UTF-8" is a valid content type, but not a valid MIME type. Does anyone know of a reference where the definition of "content type" is made more clear? Are there any existing standards around sub-parameters of content types? I also wonder whether this is appropriate when the additional human- readable file information is published somewhere other than the link. For example, this is a snippet from a screen-scraping tool I made to provide download links for video files:

3:32

Frog Princess

Larry Wilmore explains that when you wish upon a star, it makes a difference who you are.

I publish human-readable file types, bitrates (low vs. high quality), and lengths, so it would be nice to have machine-readable versions of all of that information. I could add type="application/x-shockwave- flash; length: 212; bitrate=128" to the links, and that would seem to make sense for the MIME type and bitrate, which are published in human-readable form within the link. But the length is published outside the link, so it seems a little awkward to be publishing the machine-readable version of that in the link. -- Scott Reynen MakeDataMakeSense.com From supercanadian at gmail.com Thu Apr 5 12:56:31 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu Apr 5 12:56:36 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> Message-ID: <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> Hello Scott, You can find more info about Content Types here... Section 14.17 of RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 See ya On 4/5/07, Scott Reynen wrote: > On Apr 5, 2007, at 1:49 PM, Charles Iliya Krempeaux wrote: > > > You can do other sophisticated stuff with the "type" attribute to... > > since it holds a "Content Type" and not just a "MIME type". So you > > can add parameters to it too. > > The distinction between "content type" and "MIME type" doesn't seem > very clear in the HTML spec: > > http://www.w3.org/TR/html401/types.html#type-content-type > > The header "Content types (MIME types)" seems to suggest they're > interchangeable terms, though they're apparently not as "text/html; > charset=UTF-8" is a valid content type, but not a valid MIME type. > Does anyone know of a reference where the definition of "content > type" is made more clear? Are there any existing standards around > sub-parameters of content types? > > I also wonder whether this is appropriate when the additional human- > readable file information is published somewhere other than the > link. For example, this is a snippet from a screen-scraping tool I > made to provide download links for video files: > >
>
> >

3:32

>
>

Frog Princess

>

Larry Wilmore explains that when you wish upon a star, it makes a > difference who you are.

> >
> > I publish human-readable file types, bitrates (low vs. high quality), > and lengths, so it would be nice to have machine-readable versions of > all of that information. I could add type="application/x-shockwave- > flash; length: 212; bitrate=128" to the links, and that would seem to > make sense for the MIME type and bitrate, which are published in > human-readable form within the link. But the length is published > outside the link, so it seems a little awkward to be publishing the > machine-readable version of that in the link. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From scott at makedatamakesense.com Thu Apr 5 13:35:22 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Thu Apr 5 13:35:34 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> Message-ID: On Apr 5, 2007, at 2:56 PM, Charles Iliya Krempeaux wrote: > Hello Scott, > > You can find more info about Content Types here... > > Section 14.17 of RFC 2616 > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 Hmm, reading that gives me the impression that parameters are defined when media types are registered, and aren't something we can add to suit our needs. That links to this: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 Which says "The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry." So the media type registry determines the significance of parameters for that media type. In the text/html registry [1], for example, I see "Optional parameters: charset". But in the audio/mpeg registry, I see "Optional parameters: none". I couldn't find any discussion of parameters specific to video/mpeg, but video/mp4 [3] also says "Optional parameters: none", as does video/quicktime [4]. Microsoft has, of course, used unregistered X- content types. So what exactly does "Optional parameters: none" mean? It seems to suggest we don't have the option of parameters on these content types, but maybe I'm reading that too literally? [1] http://tools.ietf.org/html/rfc2854 [2] http://tools.ietf.org/html/rfc3003 [3] http://tools.ietf.org/html/rfc4337 [4] http://www.iana.org/assignments/media-types/video/quicktime -- Scott Reynen MakeDataMakeSense.com From supercanadian at gmail.com Thu Apr 5 13:46:48 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu Apr 5 13:46:52 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> Message-ID: <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> Hello Scott, On 4/5/07, Scott Reynen wrote: > On Apr 5, 2007, at 2:56 PM, Charles Iliya Krempeaux wrote: > > > Hello Scott, > > > > You can find more info about Content Types here... > > > > Section 14.17 of RFC 2616 > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 > > Hmm, reading that gives me the impression that parameters are defined > when media types are registered, and aren't something we can add to > suit our needs. I don't believe that is the case. I believe (according to the spec) you are free to create your own Content Type parameters. That quote... "The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry." ... only implies that there MIGHT be some Content Type parameters defined with the Media Type registration -- with the MIME Type registration. I've seen examples in the wild of people creating their own Content Type parameters to existing registered Media/MIME types. (I've even done it.) And although that does not prove that doing so is what the spec says... it is evidence towards it. See ya > That links to this: > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 > > Which says "The presence or absence of a parameter might be > significant to the processing of a media-type, depending on its > definition within the media type registry." > > So the media type registry determines the significance of parameters > for that media type. In the text/html registry [1], for example, I > see "Optional parameters: charset". But in the audio/mpeg registry, > I see "Optional parameters: none". I couldn't find any discussion of > parameters specific to video/mpeg, but video/mp4 [3] also says > "Optional parameters: none", as does video/quicktime [4]. Microsoft > has, of course, used unregistered X- content types. So what exactly > does "Optional parameters: none" mean? It seems to suggest we don't > have the option of parameters on these content types, but maybe I'm > reading that too literally? > > [1] http://tools.ietf.org/html/rfc2854 > [2] http://tools.ietf.org/html/rfc3003 > [3] http://tools.ietf.org/html/rfc4337 > [4] http://www.iana.org/assignments/media-types/video/quicktime -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From martin at weborganics.co.uk Fri Apr 6 03:36:55 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Apr 6 03:36:35 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> <46150E0B.3030304@digitalbazaar.com> <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> Message-ID: <1175855815.30323.51.camel@localhost.localdomain> On Thu, 2007-04-05 at 10:17 -0500, Scott Reynen wrote: > On Apr 5, 2007, at 9:56 AM, Manu Sporny wrote: > > > media-info will definitely solve this problem once it is finalized. > > That > > being said, does that invalidate the need for Music Download > > microformat? Based on Stephen and your problem definition for Music > > Download, and with your addition below, I think it does. > > I think this is backwards. We shouldn't delay solving the simpler > problem until the more complex problem is solved. We should solve > the simpler problem first, and make that solution a modular part of > the more complex solution. > > >> isn't rel="enclosure" type="audio/mpeg" sufficient enough to do this > >> then? maybe just adding length="198000" or something ? > > > > That is a good, simple solution. 'rel' and 'type' are standard > > elements and would aid a browser in recognizing that you are talking > > about an MP3 file... Amarok/iTunes could detect an hAtom/hReview combo > > with a type="audio/mpeg" link. It would be difficult for it to > > recognize > > artist/track information - wouldn't it? Wouldn't that have to be > > standardized to some degree? While we can use hAtom/hReview to do > > this - > > it seems a bit like a band-aid... media-info being the real > > solution to > > this problem. Do you agree or disagree? > > I agree that artist and track information are still needed, but > disagree that this in some way reduces the value in reusing existing > standards. We can and should reuse existing standards *and* add > artist and track information. I can agree with scott we should re-use existing formats if we can to solve the simpler problem, isn't this the Microformat way to solve the simple problem. If the new format can be hooked into an existing format such as hAtom, with the addition of rel="enclosure" with a few extra extensions such as artist, and length, why not its simple which is how it should be, and easy for developers of all skill levels to use. The problem as far as I can see is the Question "Microformat for music download" as far as I can understand it the microformat for music download should be simple in the same way as when I choose to download a music file I will already know about the file because I have already made the choice to download the file because previously I like the artist or I have visited the website or on-line store and read about it first. > > > The Atom standard defines "length" for content, so it wouldn't be a > > stretch to imagine that being an optional element of hAtom? The > > question > > is... do we want to add that to hAtom? > > Even before asking that, the question is: is length a property we > need to add at all? It shows up in just over half of surveyed sites, > a bit short of our rough 80% benchmark. We can always add more > later, so we should start as simple as possible. Maybe that means > including length, but maybe it doesn't. We shouldn't be adding > properties just because we can. What I'm trying to get at is before hand we know very little about the file itself or how it relates to an artist, when we download a file we rename the file or convert it into a different format and strip the tags and replace them with something that fits in with our way of things iTunes will do all this automatically as soon as the file is downloaded into its music collection. All I want to know before hand is "Is it the file type I'm expecting i.e. mp3" and "Is it by who I'm expecting it to be" A new microformat media-info may be something to solve a more extended problem how to describe the information outside the file or download itself, where a customer gets information about their favorite artist or speaker is usually different to where they download a file, and something which is a far greater and involved discussion to be debated. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Fri Apr 6 08:39:19 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Apr 6 08:39:21 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <1175855815.30323.51.camel@localhost.localdomain> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> <46150E0B.3030304@digitalbazaar.com> <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> <1175855815.30323.51.camel@localhost.localdomain> Message-ID: <461669A7.7080605@digitalbazaar.com> Martin McEvoy wrote: > I can agree with scott we should re-use existing formats if we can to > solve the simpler problem, isn't this the Microformat way to solve the > simple problem. If the new format can be hooked into an existing format > such as hAtom, with the addition of rel="enclosure" with a few extra > extensions such as artist, and length, why not its simple which is how > it should be, and easy for developers of all skill levels to use. I agree with both of you in principal - new formats should not be created if minor modifications to a pre-existing format, such as hAtom or hReview, will do. However, it would be a bad idea to bloat pre-existing standards such as hAtom and hReview when a new microformat is needed. I believe the discussion we are having is "Do we need a new microformat to describe music downloads?". The problem description that I believe you have proposed is (paraphrased): All I want to know before hand is 'Is it the file type I'm expecting i.e. mp3' and 'Is it by who I'm expecting it to be'. I might also be interested in the title of the download and the length of the file. If you look back to the beginning of this thread: http://microformats.org/discuss/mail/microformats-new/2007-March/000028.html Marian stated a more complex problem description: "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.... 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 description 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." Marian's problem description is much larger in scope than your problem description. So, which problem are we attempting to solve? We have several options that I can see: 1. Extend hAtom/hReview to support a very small subset of Marian and your problem description, solving a simple problem, but potentially bloating a Microformat when a new microformat is needed. 2. Complete media-info - which will solve both your and Marian's problem descriptions, but could take a really long time to solve a complex problem. 3. Create a very simple hAudio microformat, which can then be integrated into media-info, solving your problem and Marian's problem. It would also lay some foundation for media-info, which I know Scott was concerned about. The downside being YAuF - yet another Microformat. Any thoughts on how to proceed? I think we should start by outlining what problem we are trying to solve. I was under the impression that we were trying to solve Marian's problem description and the one vaguely outlined on the music-examples page. -- manu From msporny at digitalbazaar.com Fri Apr 6 09:27:01 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Apr 6 09:27:04 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> Message-ID: <461674D5.3000603@digitalbazaar.com> Charles Iliya Krempeaux wrote: >> Hmm, reading that gives me the impression that parameters are defined >> when media types are registered, and aren't something we can add to >> suit our needs. > > I don't believe that is the case. > > I believe (according to the spec) you are free to create your own > Content Type parameters. I disagree, you could break backwards compatibility if you start tacking on parameters that are not defined in the MIME-type (which is used in the Accept and Content-Type fields): "When sending data to older HTTP applications, implementations SHOULD only use media type parameters when they are required by that type/subtype definition."[1] I can't find any statement in the literature that says that you can add parameters that are not in the "Required" or "Optional" listing. Furthermore, RFC 2045 states: "Use of non-registered media types is discouraged." [1] "MIME implementations must ignore any parameters whose names they do not recognize."[2] I believe this means that web browsers should ignore any parameters whose names they do not recognize. That means if it isn't in the MIME-Type specification, it should be ignored by any implementation reading a field containing the MIME-Type. In short - if it isn't registered with the Mime-Type - you shouldn't be using it. -- manu [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 [2] http://rfc.net/rfc2045.html#p10 From scott at makedatamakesense.com Fri Apr 6 09:32:39 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri Apr 6 09:32:51 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <461669A7.7080605@digitalbazaar.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> <46150E0B.3030304@digitalbazaar.com> <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> <1175855815.30323.51.camel@localhost.localdomain> <461669A7.7080605@digitalbazaar.com> Message-ID: <5F08935F-905D-4923-A9DB-DF4813100A1D@makedatamakesense.com> On Apr 6, 2007, at 10:39 AM, Manu Sporny wrote: > 1. Extend hAtom/hReview to support a very small subset of Marian and > your problem description, solving a simple problem, but potentially > bloating a Microformat when a new microformat is needed. I don't think extending hAtom is an option. Music is not fundamental to the purpose of hAtom. But we could still use hAtom with the addition of music-specific properties that aren't part of hAtom. > 2. Complete media-info - which will solve both your and Marian's > problem > descriptions, but could take a really long time to solve a complex > problem. > 3. Create a very simple hAudio microformat, which can then be > integrated > into media-info, solving your problem and Marian's problem. It would > also lay some foundation for media-info, which I know Scott was > concerned about. The downside being YAuF - yet another Microformat. These are mutually exclusive options in name only. The same properties can be 1) used with hAtom, 2) used in media-info, and 3) used outside both hAtom and media-info. The semantics of something like class="album-title" don't change when we use them with a different microformat, as long as we define them clearly. That's the "modularity / embeddability" principle: http://microformats.org/about/ I suspect the music downloads problem can be solved by using some semantics from hAtom and introducing other new HTML semantics (e.g. album title) that may be part of media-info in the future. But I see no reason we need to give those new semantics a separate microformat name, and no reason we need to wait for all of media-info to be complete before we start using them. The point is solving the problem. If we solve this problem without creating a whole new microformat with a whole new name, that's still a successful outcome. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Fri Apr 6 10:28:17 2007 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Apr 6 10:27:56 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <5F08935F-905D-4923-A9DB-DF4813100A1D@makedatamakesense.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <7e51d15d0704030640lcda20dcu40b5133e50eab722@mail.gmail.com> <23EDEA4C-C9DB-4B3C-ACF0-C63C623EA933@makedatamakesense.com> <1175694942.21745.23.camel@localhost.localdomain> <4613C388.8050605@digitalbazaar.com> <9905B64D-32CB-4827-88C8-E5E631F3D7FB@makedatamakesense.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> <46150E0B.3030304@digitalbazaar.com> <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> <1175855815.30323.51.camel@localhost.localdomain> <461669A7.7080605@digitalbazaar.com> <5F08935F-905D-4923-A9DB-DF4813100A1D@makedatamakesense.com> Message-ID: <1175880497.2742.45.camel@localhost.localdomain> On Fri, 2007-04-06 at 11:32 -0500, Scott Reynen wrote: > On Apr 6, 2007, at 10:39 AM, Manu Sporny wrote: > > > 1. Extend hAtom/hReview to support a very small subset of Marian and > > your problem description, solving a simple problem, but potentially > > bloating a Microformat when a new microformat is needed. > > I don't think extending hAtom is an option. Music is not fundamental > to the purpose of hAtom. But we could still use hAtom with the > addition of music-specific properties that aren't part of hAtom. > > > 2. Complete media-info - which will solve both your and Marian's > > problem > > descriptions, but could take a really long time to solve a complex > > problem. > > 3. Create a very simple hAudio microformat, which can then be > > integrated > > into media-info, solving your problem and Marian's problem. It would > > also lay some foundation for media-info, which I know Scott was > > concerned about. The downside being YAuF - yet another Microformat. Marian's problem is very involved, its a bid to allow music players and web players to view media info without actually having to download part of the file first to read the info contained in the download.? containing this information in hAtom seems logical to me because the data can be re-used in many ways on all platforms. The content relates to what you are reading on the screen It can be used to contain factual information about the file that matches the tag information. I suggested rel enclosure because of its wide usage in podcasting, its already reasonably well known Microformat hReview is just another way to extend this theory further It could contain official reviews or announcements about the track or album or maybe not included at all. extending hAtom or hReview may not be wise or practical doing it this way can make your code very bloated, but it seems we have to explore existing paths fist before we go a head and create the hAudio/media-info microformat. > > These are mutually exclusive options in name only. The same > properties can be 1) used with hAtom, 2) used in media-info, and 3) > used outside both hAtom and media-info. The semantics of something > like class="album-title" don't change when we use them with a > different microformat, as long as we define them clearly. That's the > "modularity / embeddability" principle: > > http://microformats.org/about/ > > I suspect the music downloads problem can be solved by using some > semantics from hAtom and introducing other new HTML semantics (e.g. > album title) that may be part of media-info in the future. But I see > no reason we need to give those new semantics a separate microformat > name, and no reason we need to wait for all of media-info to be > complete before we start using them. The point is solving the > problem. If we solve this problem without creating a whole new > microformat with a whole new name, that's still a successful outcome. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From supercanadian at gmail.com Fri Apr 6 12:03:32 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Fri Apr 6 12:03:35 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <461674D5.3000603@digitalbazaar.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> <461674D5.3000603@digitalbazaar.com> Message-ID: <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> Hello Manu On 4/6/07, Manu Sporny wrote: > Charles Iliya Krempeaux wrote: > >> Hmm, reading that gives me the impression that parameters are defined > >> when media types are registered, and aren't something we can add to > >> suit our needs. > > > > I don't believe that is the case. > > > > I believe (according to the spec) you are free to create your own > > Content Type parameters. > > I disagree, you could break backwards compatibility if you start tacking > on parameters that are not defined in the MIME-type (which is used in > the Accept and Content-Type fields): > > "When sending data to older HTTP applications, implementations SHOULD > only use media type parameters when they are required by that > type/subtype definition."[1] > > I can't find any statement in the literature that says that you can add > parameters that are not in the "Required" or "Optional" listing. > Furthermore, RFC 2045 states: > > "Use of non-registered media types is discouraged." [1] > > "MIME implementations must ignore any parameters whose names they do not > recognize."[2] > > I believe this means that web browsers should ignore any parameters > whose names they do not recognize. That means if it isn't in the > MIME-Type specification, it should be ignored by any implementation > reading a field containing the MIME-Type. > > In short - if it isn't registered with the Mime-Type - you shouldn't be > using it. > > -- manu > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7 > [2] http://rfc.net/rfc2045.html#p10 I don't think we are disagreeing. You are saying that it says we SHOULD NOT use them. And I'm not arguing that. But "SHOULD NOT" is NOT the same a "MUST NOT". And therefore, despite the encouragement (from the spec) to NOT make up your own Content Type parameters, you still could. And if you did, you would still be complying with the spec. -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From msporny at digitalbazaar.com Fri Apr 6 13:15:46 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Apr 6 13:15:49 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> <461674D5.3000603@digitalbazaar.com> <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> Message-ID: <4616AA72.9080606@digitalbazaar.com> Charles Iliya Krempeaux wrote: > I don't think we are disagreeing. > > You are saying that it says we SHOULD NOT use them. And I'm not arguing > that. > > But "SHOULD NOT" is NOT the same a "MUST NOT". Agreed. Although, I don't think I made myself clear in the last post to this thread. The following I see as a MUST NOT: "MIME implementations must ignore any parameters whose names they do not recognize." In other words, "Web browsers MUST NOT process parameters whose names they do not recognize". Parameter recognition is based on MIME-type, isn't it? Or am I missing something? > And therefore, despite the encouragement (from the spec) to NOT make > up your own Content Type parameters, you still could. And if you did, > you would still be complying with the spec. Isn't this a slippery slope? Remember, we're not just talking about one MIME-type here, we're talking about possibly adding 2-5 parameters for all of these MIME-types: audio/basic audio/mp4 audio/mpeg audio/mpeg4-generic audio/ac3 video/DV video/H264 video/mp4 video/mpeg video/quicktime video/vc1 image/gif image/jpeg image/tiff image/png --------------------------------------------------------------------- Just to set up an alternative for discussion purposes. If we wanted to specify the following for a file (WARNING: Strawman ahead): type, audio-codec, audio-codec-sample-rate, video-codec-sample-rate, video-codec-bitrate, size-in-octets, URL We could then mark-up the following text in a uF: ---------------------------------------------------------------------- We just went rock climbing at The Gorge in West Virginia. Here are two downloadable files of us doing Angels Arete: The Gorge - DV (54MB, PCM 48Khz audio, HD-VCR/1125-60 video) The Gorge - MPEG (22MB, MP3 192Kbps audio, MPEG-2 video) ---------------------------------------------------------------------- We could create a hFile uF like so:
The Gorge - DV (54MB, PCM 48Khz audio, HD-VCR/1125-60 video)
The Gorge - MPEG (22MB, PCM 192Kbps audio, MPEG-2 video)
---------------------------------------------------------------------- The argument for the first alternative, adding parameters to pre-existing MIME-Types, seems a bit shaky. The second alternative, adding classes, is based on a widely accepted standard. Which one is the better solution for describing file formats? -- manu -- Manu Sporny President/CEO Digital Bazaar, Inc. http://blog.digitalbazaar.com/ From supercanadian at gmail.com Fri Apr 6 14:07:34 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Fri Apr 6 14:07:38 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <4616AA72.9080606@digitalbazaar.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> <461674D5.3000603@digitalbazaar.com> <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> <4616AA72.9080606@digitalbazaar.com> Message-ID: <84ce626f0704061407v301e7004hfd42318454257bab@mail.gmail.com> Hello Manu, On 4/6/07, Manu Sporny wrote: > Charles Iliya Krempeaux wrote: > > I don't think we are disagreeing. > > > > You are saying that it says we SHOULD NOT use them. And I'm not arguing > > that. > > > > But "SHOULD NOT" is NOT the same a "MUST NOT". > > Agreed. Although, I don't think I made myself clear in the last post to > this thread. The following I see as a MUST NOT: > > "MIME implementations must ignore any parameters whose names they do not > recognize." > > In other words, "Web browsers MUST NOT process parameters whose names > they do not recognize". Parameter recognition is based on MIME-type, > isn't it? Or am I missing something? Again... we are not disagreeing here. I am not arguing this. This still does not stop people from serving resources (on the web) using Content Type with non-registered Content Type parameters. > > And therefore, despite the encouragement (from the spec) to NOT make > > up your own Content Type parameters, you still could. And if you did, > > you would still be complying with the spec. > > Isn't this a slippery slope? I think this was an intended path to extension. Much like developers defining their own (HTML) class name, and developers defining their own "x-" prefixed MIME types, and developers defining their own XML namespaces. > Remember, we're not just talking about one > MIME-type here, we're talking about possibly adding 2-5 parameters for > all of these MIME-types: > > audio/basic > audio/mp4 > audio/mpeg > audio/mpeg4-generic > audio/ac3 > video/DV > video/H264 > video/mp4 > video/mpeg > video/quicktime > video/vc1 > image/gif > image/jpeg > image/tiff > image/png > > --------------------------------------------------------------------- > > Just to set up an alternative for discussion purposes. If we wanted to > specify the following for a file (WARNING: Strawman ahead): > > type, audio-codec, audio-codec-sample-rate, video-codec-sample-rate, > video-codec-bitrate, size-in-octets, URL > > We could then mark-up the following text in a uF: > > ---------------------------------------------------------------------- > We just went rock climbing at The Gorge in West Virginia. Here are two > downloadable files of us doing Angels Arete: > > The Gorge - DV (54MB, PCM 48Khz audio, HD-VCR/1125-60 video) > The Gorge - MPEG (22MB, MP3 192Kbps audio, MPEG-2 video) > ---------------------------------------------------------------------- > > We could create a hFile uF like so: > >
> The Gorge - DV > (54MB, > PCM > 48Khz audio, > HD-VCR/1125-60 video) >
> >
> The Gorge - MPEG > (22MB, > PCM > 192Kbps audio, > MPEG-2 video) >
> ---------------------------------------------------------------------- > > The argument for the first alternative, adding parameters to > pre-existing MIME-Types, seems a bit shaky. The second alternative, > adding classes, is based on a widely accepted standard. > > Which one is the better solution for describing file formats? Well... 2nd choice... with the (HTML) class names... is definitely more in tune with the Microformat way. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From scott at makedatamakesense.com Sat Apr 7 09:08:29 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sat Apr 7 09:08:35 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <4616AA72.9080606@digitalbazaar.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> <461674D5.3000603@digitalbazaar.com> <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> <4616AA72.9080606@digitalbazaar.com> Message-ID: <4CD9728D-17F6-450F-AA7A-57CB953A0FCD@makedatamakesense.com> On Apr 6, 2007, at 3:15 PM, Manu Sporny wrote: > "MIME implementations must ignore any parameters whose names they > do not > recognize." > > In other words, "Web browsers MUST NOT process parameters whose names > they do not recognize". Parameter recognition is based on MIME-type, > isn't it? It's based on MIME type, but does that mean it's restricted to only what's listed in the registry? I don't see a clear answer to this anywhere, but that "must ignore" actually makes me think it's intended to be extended. In general, "must ignore" rules are intended to allow extensions of specs without worry of breaking older applications. For example, the microformat parsing guidelines [1] state "Simple rule: ignore anything you don't need" so we can safely add new properties to microformats. The only alternative to ignoring non-recognized parameters is to error on them. They can't be processed because they're not recognized. So "must ignore" seems intended to prevent errors on non-registered additions. [1] http://microformats.org/wiki/implementation-guidelines#Parsing -- Scott Reynen MakeDataMakeSense.com From bewest at gmail.com Sun Apr 8 17:05:15 2007 From: bewest at gmail.com (Benjamin West) Date: Sun Apr 8 17:05:19 2007 Subject: citation issues was: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) Message-ID: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> On 4/3/07, Thomas Breuel wrote: > I'll add some more comments to the Wiki. > > Thomas > Thomas: First, thanks for your feedback on the wiki. You added a couple of things to the wiki as requirements. However, I don't see these as requirements: mostly they are issues. In order to support the assertions, eg the importance of preserving the typeface of the original citation, you'll need to provide examples from the web. (FWIW, html does not make any promises to preserve the presentation of a resource by design, so I doubt this will really be a requirement here.) Instead, I'm re-organizing them as issues, and I'll let those more familiar with this work comment further. In addition, I'm going to scan through the citation documents and move anything that can easily be rephrased as an issue to the issues page. Hopefully have them concentrated in one place will help, and people won't mind me moving things around too much. -Ben Addition of requirements: http://microformats.org/wiki?title=citation-brainstorming&diff=0&oldid=15286 citation-issues: http://microformats.org/wiki/citation-issues From michael.mccracken at gmail.com Sun Apr 8 17:23:30 2007 From: michael.mccracken at gmail.com (Michael McCracken) Date: Sun Apr 8 17:23:33 2007 Subject: citation issues was: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> References: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> Message-ID: 2007/4/8, Benjamin West : > On 4/3/07, Thomas Breuel wrote: > > > I'll add some more comments to the Wiki. > > > > Thomas > > > > > Thomas: > First, thanks for your feedback on the wiki. > You added a couple of things to the wiki as requirements. However, > I don't see these as requirements: mostly they are issues. In order to > support the assertions, eg the importance of preserving the typeface > of the original citation, you'll need to provide examples from the web. > (FWIW, html does not make any promises to preserve the presentation > of a resource by design, so I doubt this will really be a requirement here.) > > Instead, I'm re-organizing them as issues, and I'll let those more familiar > with this work comment further. In addition, I'm going to scan through the > citation documents and move anything that can easily be rephrased as an issue > to the issues page. Hopefully have them concentrated in one place > will help, and people won't mind me moving things around too much. I'm sure it will help. The pages are jumbled right now, and if you can clear things up it'd be a big help. For instance, the brainstorming page has years of layers that have been kept around to avoid stepping on other people's toes, but could probably be deleted, since they're mainly obsolete and are still in history anyway. I have one request - if you create an issues page that refers to issues that have been discussed WRT the straw format, could you link to the discussion section that I put after the straw format so wiki readers can find their way to the full discussion? Or you could just move the discussion section onto the issues page, so long as the links from the format to the discussions still work... Thanks, -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ From bewest at gmail.com Sun Apr 8 17:44:18 2007 From: bewest at gmail.com (Benjamin West) Date: Sun Apr 8 17:44:21 2007 Subject: citation issues was: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: References: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> Message-ID: <8ad71be30704081744s46293ff8j5db1a26c192a072e@mail.gmail.com> On 4/8/07, Michael McCracken wrote: > I have one request - if you create an issues page that refers to > issues that have been discussed WRT the straw format, could you link > to the discussion section that I put after the straw format so wiki > readers can find their way to the full discussion? Or you could just > move the discussion section onto the issues page, so long as the links > from the format to the discussions still work... > > Thanks, > -mike Mike, erm... I've already exhausted my wiki energy for the day. so if take a look now, you'll see what I've done. I'm not sure I did what you wanted, but hopefully it's a starting point others can build on. -Ben From tmbdev at gmail.com Sun Apr 8 18:05:45 2007 From: tmbdev at gmail.com (Tom) Date: Sun Apr 8 18:06:01 2007 Subject: citation issues was: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> References: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> Message-ID: Thanks for the response > Instead, I'm re-organizing them as issues, I don't understand. Are you asserting that my requirements are "issues" in the standard software engineering sense (http:// en.wikipedia.org/wiki/Issue_%28computers%29 and http:// en.wikipedia.org/wiki/Requirement, or are you simply using different terminology? > In order to > support the assertions, eg the importance of preserving the typeface > of the original citation, you'll need to provide examples from the > web. > (FWIW, html does not make any promises to preserve the presentation > of a resource by design, so I doubt this will really be a > requirement here.) As should have been clear from my comments, I'm not talking about "preserving presentation" or "typefaces" in HTML. I don't primarily care about what the citations look like on the web; it would be nice if they looked right, but that's secondary. I care about what citations look like in published papers, and citations in published papers can contain mathematics, chemical formulas, and other typographic phenomena. Citations in published papers also have a complex ontology: what fields need to be present in what kinds of publications, how they are represented, etc. Consider the citation records for my publications. Right now, users see a citation on the web, then they need to click on a separate link to get the BibTeX or Endnote citation, and then incorporate that into their bibliography manager. What a citation microformat should achieve is that people can simply use the information embedded in the HTML to accomplish the same thing. That's what other microformats like hCard achieve. What does that mean for a citation microformat? It means that I put my BibTeX or Endnote citations into some web citation system, which converts it into a microformat. A user then uses Operator or selects the HTML and puts it into their citation manager. That user should obtain an exact representation of my BibTeX or Endnote citation, without manual editing and without losing formatting relative to the original BibTeX or Endnote entry. I think at this point you have to support your assertion that the "strawman" citation microformat on the Wiki satisfies my requirements; alternatively, you can argue that my requirement is either unfulfillable or not important, or that you just don't want to debate the issue and I should go away (in which case, we'll simply continue independently or push for DC adoption). > and I'll let those more familiar > with this work comment further. In addition, I'm going to scan > through the > citation documents and move anything that can easily be rephrased > as an issue > to the issues page. Hopefully have them concentrated in one place > will help, and people won't mind me moving things around too much. Well, I have pretty much said what I have to say. I urge you to consider my arguments carefully. I'll be happy to answer specific questions or to respond to specific arguments. Thomas. From alexandrevandesande at gmail.com Sun Apr 8 18:45:42 2007 From: alexandrevandesande at gmail.com (Alexandre Van de Sande) Date: Sun Apr 8 18:45:46 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <1175880497.2742.45.camel@localhost.localdomain> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <1175715543.23767.27.camel@localhost.localdomain> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> <46150E0B.3030304@digitalbazaar.com> <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> <1175855815.30323.51.camel@localhost.localdomain> <461669A7.7080605@digitalbazaar.com> <5F08935F-905D-4923-A9DB-DF4813100A1D@makedatamakesense.com> <1175880497.2742.45.camel@localhost.localdomain> Message-ID: <8608a69a0704081845y6893a4bej2d4ef1e7a1f374d@mail.gmail.com> Hello, i have been reading this discussion for some time now and I think I would love to opinate. I think we are losing the bigger picture of microformats, by finding the quicker fix for a not-so-complicated-as-it-seems problem. I believe that more importantly than creating a microformat to describe a downloadable audio file, we should think that the track comes first, the information about the music comes first, and the .mp3 file itself (or it's location) is just another description of it. Also hAtom is a great microformat to describe any "sindicated" content, but it's job is not to describe in details that content. hAtom has an "author" field, but it does not describes that author: instead it uses a hCard inside the field to do it. In the same manner, I believe the most scalable way to add information about what's being syndicated is to add another microformat inside the "content" field of hAtom. Today it can be a media-info or an audio-info (or a hGeo for syndicating places i like, hCard to sindicate people available for a job), but tomorrow it could be as well be a hComicBook, an hSelfHelpPresentation or a hCheesyJoke. The best way to extend hAtom is to use another microformat inside it, not to publicy discuss a change to the standard every time somebody wants to syndicate something new. Therefore I believe the best, in the long term , is the option 2, to complete the media-info format and the sindicate it using hAtom. If that seems a difficult job then we should break that one in pieces, and solve the media-info for pop music/spoken audio first, because most of it's solutions will be reusable to grow media-info into a microformat that can describe most medias on the web. But again, it's just a first poster opinion and I might have missed the boat. Alexandre Van de Sande ? ? ? interaction designer wanderingabout.com On 4/6/07, Martin McEvoy wrote: > On Fri, 2007-04-06 at 11:32 -0500, Scott Reynen wrote: > > On Apr 6, 2007, at 10:39 AM, Manu Sporny wrote: > > > > > 1. Extend hAtom/hReview to support a very small subset of Marian and > > > your problem description, solving a simple problem, but potentially > > > bloating a Microformat when a new microformat is needed. > > > > I don't think extending hAtom is an option. Music is not fundamental > > to the purpose of hAtom. But we could still use hAtom with the > > addition of music-specific properties that aren't part of hAtom. > > > > > 2. Complete media-info - which will solve both your and Marian's > > > problem > > > descriptions, but could take a really long time to solve a complex > > > problem. > > > 3. Create a very simple hAudio microformat, which can then be > > > integrated > > > into media-info, solving your problem and Marian's problem. It would > > > also lay some foundation for media-info, which I know Scott was > > > concerned about. The downside being YAuF - yet another Microformat. > > Marian's problem is very involved, its a bid to allow music players and > web players to view media info without actually having to download part > of the file first to read the info contained in the download.? > > containing this information in hAtom seems logical to me because the > data can be re-used in many ways on all platforms. The content relates > to what you are reading on the screen It can be used to contain factual > information about the file that matches the tag information. I suggested > rel enclosure because of its wide usage in podcasting, its already > reasonably well known Microformat > > hReview is just another way to extend this theory further It could > contain official reviews or announcements about the track or album or > maybe not included at all. > > extending hAtom or hReview may not be wise or practical doing it this > way can make your code very bloated, but it seems we have to explore > existing paths fist before we go a head and create the hAudio/media-info > microformat. > > > > > These are mutually exclusive options in name only. The same > > properties can be 1) used with hAtom, 2) used in media-info, and 3) > > used outside both hAtom and media-info. The semantics of something > > like class="album-title" don't change when we use them with a > > different microformat, as long as we define them clearly. That's the > > "modularity / embeddability" principle: > > > > http://microformats.org/about/ > > > > I suspect the music downloads problem can be solved by using some > > semantics from hAtom and introducing other new HTML semantics (e.g. > > album title) that may be part of media-info in the future. But I see > > no reason we need to give those new semantics a separate microformat > > name, and no reason we need to wait for all of media-info to be > > complete before we start using them. The point is solving the > > problem. If we solve this problem without creating a whole new > > microformat with a whole new name, that's still a successful outcome. > > > > -- > > Scott Reynen > > MakeDataMakeSense.com > > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From tantek at cs.stanford.edu Sun Apr 8 18:45:49 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Apr 8 18:46:25 2007 Subject: what things are like on the web (was Re: citation issues was: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats)) In-Reply-To: Message-ID: On 4/8/07 6:05 PM, "Tom" wrote: > I don't primarily > care about what the citations look like on the web; You should, as the treatment of information on the Web is the primary design center of microformats. All other destinations (print, etc.) are secondary. Tantek From msporny at digitalbazaar.com Sun Apr 8 18:48:58 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Apr 8 18:49:00 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <4CD9728D-17F6-450F-AA7A-57CB953A0FCD@makedatamakesense.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> <461674D5.3000603@digitalbazaar.com> <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> <4616AA72.9080606@digitalbazaar.com> <4CD9728D-17F6-450F-AA7A-57CB953A0FCD@makedatamakesense.com> Message-ID: <46199B8A.3020406@digitalbazaar.com> Charles, Scott, Does the fact that we are having a discussion on file format instead of somebody being able to point to a Microformats wiki page and state "It's been discussed before, and here's the link" indicate that we need a new page for exploratory discussion? If so, I can create one and we can start brainstorming. Right now, we seem to have two proposed approaches to the problem: Example markup: The Gorge - MPEG video (22MB, MP3 192Kbps audio, MPEG-2 video) 1. Use the 'type' field in the anchor element for file format, example: The Gorge - MPEG video (22MB, MP3 192Kbps audio, MPEG-2 video) 2. Create a file-format uF, example:
The Gorge - MPEG video (22MB, MP3 192Kbps audio, MPEG-2 video)
Any objections to creating a file-format-example page? -- manu From bewest at gmail.com Sun Apr 8 19:20:20 2007 From: bewest at gmail.com (Benjamin West) Date: Sun Apr 8 19:20:23 2007 Subject: citation issues was: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: References: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> Message-ID: <8ad71be30704081920k5d577dd1mb915d57627447f4d@mail.gmail.com> On 4/8/07, Tom wrote: > Thanks for the response > > > Instead, I'm re-organizing them as issues, > > I don't understand. Are you asserting that my requirements are > "issues" in the standard software engineering sense (http:// > en.wikipedia.org/wiki/Issue_%28computers%29 and http:// > en.wikipedia.org/wiki/Requirement, or are you simply using different > terminology? > Requirements emerge from iterating over the process we've outlined. Top down assertions can be integrated into the process by being treated as issues, as they are in other standards processes. My usage of issues is related to the TAG findings: http://www.w3.org/2001/tag/issues.html . > I think at this point you have to support your assertion that the > "strawman" citation microformat on the Wiki satisfies my > requirements; alternatively, you can argue that my requirement is > either unfulfillable or not important, or that you just don't want to > debate the issue and I should go away (in which case, we'll simply > continue independently or push for DC adoption). > Microformats standards follow the process ( http://www.microformats.org/wiki/process ). All of the actions you suggest are subject to that process. The best way to do that is to phrase them as questions that can be answered by applying them to real world examples. I look forward to continued feedback from interested parties, including you. I hope that clears things up a bit. -Ben From scott at makedatamakesense.com Sun Apr 8 20:06:30 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Sun Apr 8 20:06:35 2007 Subject: [uf-new] Separating File Content from File Format In-Reply-To: <46199B8A.3020406@digitalbazaar.com> References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> <461674D5.3000603@digitalbazaar.com> <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> <4616AA72.9080606@digitalbazaar.com> <4CD9728D-17F6-450F-AA7A-57CB953A0FCD@makedatamakesense.com> <46199B8A.3020406@digitalbazaar.com> Message-ID: On Apr 8, 2007, at 8:48 PM, Manu Sporny wrote: > Any objections to creating a file-format-example page? I think that's a good idea. I'd suggest file-format-examples (with "s"), following the wiki naming conventions. -- Scott Reynen MakeDataMakeSense.com From tmbdev at gmail.com Sun Apr 8 20:58:47 2007 From: tmbdev at gmail.com (Tom) Date: Sun Apr 8 20:58:53 2007 Subject: citation issues was: process, [citation] (was Re: [uf-new] announcing the hOCR and hBIB microformats) In-Reply-To: <8ad71be30704081920k5d577dd1mb915d57627447f4d@mail.gmail.com> References: <8ad71be30704081705q550ec6e9rcc0dc31889bb8d87@mail.gmail.com> <8ad71be30704081920k5d577dd1mb915d57627447f4d@mail.gmail.com> Message-ID: I On Apr 8, 2007, at 7:20 PM, Benjamin West wrote: > On 4/8/07, Tom wrote: >> Thanks for the response >> >> > Instead, I'm re-organizing them as issues, >> >> I don't understand. Are you asserting that my requirements are >> "issues" in the standard software engineering sense (http:// >> en.wikipedia.org/wiki/Issue_%28computers%29 and http:// >> en.wikipedia.org/wiki/Requirement, or are you simply using different >> terminology? >> > > Requirements emerge from iterating over the process we've > outlined. Top down > assertions can be integrated into the process by being treated as > issues, as > they are in other standards processes. My usage of issues is > related to the > TAG findings: http://www.w3.org/2001/tag/issues.html . > >> I think at this point you have to support your assertion that the >> "strawman" citation microformat on the Wiki satisfies my >> requirements; alternatively, you can argue that my requirement is >> either unfulfillable or not important, or that you just don't want to >> debate the issue and I should go away (in which case, we'll simply >> continue independently or push for DC adoption). >> > > Microformats standards follow the process ( > http://www.microformats.org/wiki/process ). All of the actions you > suggest > are subject to that process. The best way to do that is to phrase > them as > questions that can be answered by applying them to real world > examples. I > look forward to continued feedback from interested parties, > including you. > > I hope that clears things up a bit. > > -Ben > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From davidjanes at blogmatrix.com Mon Apr 9 00:21:29 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Apr 9 00:21:31 2007 Subject: [uf-new] Microformat for Music Downloads In-Reply-To: <8608a69a0704081845y6893a4bej2d4ef1e7a1f374d@mail.gmail.com> References: <7e51d15d0703280025n5922a6b8h27c9a5774126d077@mail.gmail.com> <46141F01.1070600@digitalbazaar.com> <1175727991.25172.20.camel@localhost.localdomain> <46150E0B.3030304@digitalbazaar.com> <307A4432-575A-4A56-B64F-4C4D41B85481@makedatamakesense.com> <1175855815.30323.51.camel@localhost.localdomain> <461669A7.7080605@digitalbazaar.com> <5F08935F-905D-4923-A9DB-DF4813100A1D@makedatamakesense.com> <1175880497.2742.45.camel@localhost.localdomain> <8608a69a0704081845y6893a4bej2d4ef1e7a1f374d@mail.gmail.com> Message-ID: <21e523c20704090021j38727034m3deb6dc2d4f2081f@mail.gmail.com> On 4/8/07, Alexandre Van de Sande wrote: > The best way to extend hAtom is to use another microformat inside it, > not to publicy discuss a change to the standard every time somebody > wants to syndicate something new. Yes, exactly. Whatever you create will/can/should overlay with hAtom (or whatever uF is chosen as an appropriate base). Regards, etc... David -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From msporny at digitalbazaar.com Mon Apr 9 07:52:39 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Apr 9 07:52:43 2007 Subject: [uf-new] Help: Need File Format examples (was: Separating File Content from File Format) In-Reply-To: References: <46150D55.2080401@digitalbazaar.com> <84ce626f0704051144m2f3f328wc783cc032656af23@mail.gmail.com> <84ce626f0704051149j7aa78423y780cf51ca9ad74d6@mail.gmail.com> <45D2C26C-CC3D-4D16-B63B-3018EC953986@makedatamakesense.com> <84ce626f0704051256o65a8abe9weaa8b9c8311f4e2c@mail.gmail.com> <84ce626f0704051346h405cdb4cuf35681e1f9739c8f@mail.gmail.com> <461674D5.3000603@digitalbazaar.com> <84ce626f0704061203m4e0bb9bdl424a9f0302bb98bc@mail.gmail.com> <4616AA72.9080606@digitalbazaar.com> <4CD9728D-17F6-450F-