Re: [uf-new] RFC: Proposal for a (book) title microformat
Hi Craig, This looks very similar to the citation work started here: http://microformats.org/wiki/citation I'd suggest building on the work there. It looks like you've already done much of the first to-do, identifying class names for reuse. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Question RE: The Process
On Jul 17, 2010, at 9:52 PM, Craig Shea wrote: I have read the process page (and its associated pages) but, I'm still confused. Do I start a proposal by mailing to this list, creating the suggested wiki pages, or both? It's pretty flexible, but generally the first step is to send a proposal to this list. Someone may have already started working on a similar project, so mailing the list is a good way to consolidate efforts early. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
On Nov 26, 2009, at 9:41 AM, Toby Inkster wrote: As I understand it, these limitations are what led the W3C to create RDF, which is cross-linked from the meta element in the HTML spec. And the complexity of RDF, is of course what led to the rise of microformats. This isn't very accurate. RDF was not created primarily as a response to HTML's limitations, nor microformats as a response to RDF's complexity. The two only rarely overlap on the same use case. It's generally pretty clear which tool is more appropriate for a given job. For example: Have you considered using RDFa? I agree, this seems much more in line with RDFa than microformats. To do this in microformats, we'd need to throw out the visible data requirement, and re-interpret all of the other guidelines to no longer presume visible data. And after a lot of work, the result would end up looking a lot like RDFa. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
On Nov 26, 2009, at 10:33 AM, Fiann O'Hagan wrote: Do you have any real-world examples of RDFa being published? It seems to me the scarcity of real-world examples is a drawback inherent in what you're trying to do, not specific to RDFa. I'd note you also have no real-world examples of your own data being published in HTML. You need to use something like RDFa because you have invisible data you want to put in HTML. RDFa is complex largely because it handles invisible data in HTML. People don't widely use RDFa because they find it too complex. Calling it a microformat wouldn't somehow remove the complexity of publishing invisible data in a format focused on visible data. If anything, it would just make things more difficult, because the microformats community is largely composed of people who have intentionally avoided the problem you're trying to solve, many of whom believe it to be unsolvable. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformats for hidden data
On Nov 26, 2009, at 2:56 PM, Fiann O'Hagan wrote: So when you say that it would end up looking like RDFa, do you mean in terms of syntax? Or do you mean in terms of the data being applied as attributes to elements that are otherwise visible, like the about attribute being added to a div? I meant the general extension of HTML beyond what makes sense to most HTML authors, which is what leads, I suspect, to lower adoption. Even microformats value class pattern starts to look a little like RDFa to me, in that the meaning of the markup is not particularly clear to someone who only knows HTML semantics. If it's the second one, then I was imaging something much simpler, which looks like any other microformat, but with some or all of the content in a CSS display:none region of the page. That to me still looks like a microformat, not like RDFa. To me that looks like neither microformats nor RDFa. I think putting non-content in HTML as content goes against HTML semantics in a pretty basic way that neither RDFa nor microformats allow. On Nov 26, 2009, at 4:40 PM, Tantek Çelik wrote: 2. use the data-* attributes in HTML5 which were explicitly created to handle the use case of data attributes for scripts/script libraries among other things. The prohibition of using data- attributes for public data seems to be a problem with this particular use case, as analytics engines are generally independent of the site being tracked and These attributes are not intended for use by software that is independent of the site that uses the attributes. http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data I've never understood why that restriction was added, as it seems to have zero benefit, but it's still there. Personally, I'd take another look at how far you can get with meta tags. If the only issue with those is that they refer to the whole document, there may be a way around that, e.g. using the scheme attribute to identify a section ID. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New proposal - replace custom web analytics markup with microformat(s)
On Oct 29, 2009, at 8:35 AM, Liam Clancy wrote: As part of this consultation we published a draft microformat we called 'hPage' (not to be confused with an earlier proposal to this list by the same name): https://jshub.org/hPage/ We are working full-time on this and other related projects at jsHub.org and I appreciate your time and am very much looking forward to hearing your opinions. I see several problems with hPage. Unfortunately, it looks like you've gone too far to correct these problems without a complete overhaul. This proposal was developed using the published microformats process as much as possible Can you maybe clarify how you accomplished each step of the process? For example, where are the real world examples? You've published some microformat principles, but you seem to have violated nearly all of them: - Solve a specific problem hPage explicitly models two different types of data: HTML pages and dynamic content fragments. The former is already modeled by HTML itself, and the latter is often not published within HTML documents. - Design for humans first, machines second. The data you're modeling is primarily for machines. - Reuse existing building blocks, such as semantic HTML and existing microformats You've circumvented title, among other existing building blocks. - Modularity / embeddability You've declared definitions for incredibly generic terms like name and type as specific to the context(s) of hPage, which would make them unusable by any other microformat. These are large enough problems that I'd suggest revisiting the beginning of the microformats process and walking through it all again. Let's talk about just the first step: what exactly is the problem you're trying to solve? I know you've stated this already, but it'll be hard for anyone to focus on the problem as long as you're stating it in the context of a specific solution. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New proposal: Elemental microformat for content boundaries
On [Apr 23], at [ Apr 23] 8:25 , Indus Khaitan wrote: Expanding on a simple example: twitter's public timeline page, consists of 20 individual content (can I say micro-content?) units (or twitter statuses). On an aggregate page, these status messages are uniquely identifiable units of content but there is no determinate way of discerning boundaries of the individual statuses and successfully parsing them without knowing the visual arrangement of markup. The same problem statement can be attached to other example situations. The current mechanisms do not provide any semantic cues to a search bot. Twitter already uses hentry [1] to separate individual posts. You seem to be describing something more generic than hentry, but I'd suggest starting with hentry anyway to see if it doesn't handle most of your use cases. [1] http://microformats.org/wiki/hatom -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: One issue per thread
On [Feb 28], at [ Feb 28] 4:55 , David Janes wrote: For many of us e-mail is a natural way of discussing ideas, working through issues and so forth For what it's worth, I've always considered email a tool for discussion and the wiki a tool for documentation. But I don't think that's worth much. It seems to me this discussion boils down to I like email vs. I don't, and all of the arguments about what's best for this community are just dressing for personal bias. We're not going to find what works best for this community until we actually start looking for it, which is hard to do when we're working toward pre-determined conclusions. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown
On [Feb 2], at [ Feb 2] 3:17 , Toby A Inkster wrote: JMesserly wrote: Of course I wouldn't have posted the inquiry to this list if I had the type of this information. If you don't know what level address parts are - street-address, locality, region, etc - then you can't (properly) use adr According to the wiki [1], adr has no required fields. By my reading, John knows the content is an address; he just doesn't know what exactly the individual parts of the address are. So he can properly use adr by labeling the content with class=adr and avoiding further (likely wrong) detail. That won't be useable in all adr tools, but it will still work in some. [1] http://microformats.org/wiki/adr-cheatsheet -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Comment Questions
On [Nov 16], at [ Nov 16] 2:33 , Toby A Inkster wrote: Imagine the following comments: - Comment A to the main article at 1:00 pm. - Comment B to the main article at 2:00 pm. - Comment C in reply to comment A at 3:00 pm. - Comment D in reply to comment B at 4:00 pm. Where did you see this on the web? I don't doubt such comments actually exist, but hypothetical examples prove a waste of everyone's time. This whole thread reminds me of the blind men and the elephant story [1]. Since everyone else seems certain they know what a comment typically looks like, please assume I don't, and provide the URLs of real world examples I would need to understand your points. [1] http://www.noogenesis.com/pineapple/blind_men_elephant.html -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Comment Questions
On [Nov 15], at [ Nov 15] 6:57 , David Janes wrote: I don't see the benefit in the later format, as we can add a Entry Replies wrapper around that whole h2Comments/h2(all the comments) section without presentation impact. It seems to me it's not practically useful to know that something is a reply, but rather we need to know to *what* it is a reply in order to solve the problem statement on comments-brainstorming. This example, I think, should be excluded as it makes that impossible: http://www.haloscan.com/comments/empirestatehuman/7424868678376349884/ There's no way to solve the problem statement with that example because a necessary piece of information (the subject of the comment) is missing for both people and machines. And I think we'd see the same problem with relying solely on a class=replies wrapper: for cross-URL (e.g. trackback) comments, it would make a critical piece of information (the subject of the comment) inaccessible to machines. That said, perhaps we should focus first on the simpler and common enough scope of comments appearing directly after the subject in the same document, and just be aware that we're not solving the whole problem (and that's okay). -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Comment Questions
On [Nov 15], at [ Nov 15] 9:07 , Martin McEvoy wrote: This is not a discussion of formats, it's a discussion of what people do. How can you discuss creating a microformat if you're not discussing what people are doing? I cant answer that David, the discussion needs to be consolidated and re-thought (the same as this discussion was) I suggest everyone go back and re-examine (and potentially re-state) their proposals in terms of how they address the problem statement for the collected examples. That common ground seems to have been largely lost in this discussion. It's easy to start talking around an assumed definition of something as common as a comment, but it's crucial to stay focused on real world examples. Before proposing markup for nested comments, we should look at examples to see if that's a common pattern. Before proposing markup for links back to the source, we should look at the examples to see if such links commonly exist. Maybe everyone has already done this, but it's hard to tell. Knowing how our own proposals are based in the examples is not enough; for this collaborative effort, we need to explain the connections to everyone else. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Comment Questions
On [Nov 15], at [ Nov 15] 1:01 , Martin McEvoy wrote: I and Sarven are both staying on topic ie: a comment and are just focusing on the real world examples Which real world examples? How do they relate to your proposals? The connections you see are apparently not as obvious to everyone else. Please explain more how you arrived at your proposals. Please do not make any proposals towards a nested comment, as this is off topic Please explain why it's off topic in terms of the examples and the problem statement. In a group discussion, being on topic doesn't help much if you're unable to get everyone on the same topic. The collected examples and problem statement establish a common basis for discussion. Let's use it. On [Nov 15], at [ Nov 15] 1:46 , David Janes wrote: I opened every single example in comment-examples [2] and every single one (excepting Haloscan, which seem to be utterly isolated from posting context) uses document structure to show the relationship. None that I noticed had a A.href link that a rel-in-reply-to could be hung on to. This is what I think we need to do more. Even if you still disagree, I hope you can see how David making his argument in terms of the examples makes his points easier for everyone to discuss. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hProduct draft schema
On [Oct 31], at [ Oct 31] 12:27 , Paul Lee (이기수) wrote: 2. name should reuse either fn from hCard or summary from hCalendar Hmm, looking at the hCard and hCalendar pages, it seems that name here is used a bit differently, since it is intended to be the product name/title. Is this really the same meaning at fn and summary? Or should we perhaps use title instead to disambiguate? We should base these discussions on the previous meaning of the class names, not the English words that make up those class names, nor the context which adds additional meaning (by defining the object we're describing). See the list of previously used class names for reference: http://microformats.org/wiki/class-names You'll find there that title means something more specific than you might assume, where fn and summary mean something more general. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
On [Oct 29], at [ Oct 29] 7:39 , Martin McEvoy wrote: The above information has been the crux of my issues with the audio- info process, because we haven't YET created a microformat for Music Downloads. The Proposal to create a Microformat for Music Downloads (If any one remembers) was first posted by Marian Steinbach in microformats- discuss[1], and later re-posted to microformats-new[2]: [1] http://microformats.org/discuss/mail/microformats-discuss/2007-February/008848.html [2] http://microformats.org/discuss/mail/microformats-new/2007-March/28.html It seems to me you're conflating two distinct efforts here, understandably as they have a lot in common. But they're not really the same. The emails you cited led to work on a media-info microformat, which seems to match your focus, but never went very far: http://microformats.org/wiki/media-info-brainstorming This has a problem statement that is clearly different from the problem statement of what ultimately came to be known as hAudio, found here: http://microformats.org/wiki/audio-info-examples The end of the latter problem statement explicitly rejects the focus on downloadable files you're seeking: The audio information need not be associated with a file. Note that audio content (The Payback by James Brown) is very different from the audio file format (192Kbps, stereo MP3). The goal of this discussion is to create a Microformat draft for marking up audio metadata and information. This has been the problem statement from the very beginning, and this problem attracted enough interest to push toward a solution. It doesn't seem to be a solution to the problem you want to solve, though. So if hAudio doesn't solve your problem, what do you do now? You tried earlier to start a new microformat with a new focus, but I think your framing of it in terms of hAudio distracted from what you actually wanted to do. It seems to me now that what you want to do is close enough to the previous media-info work that you should consider starting with what's already been done. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] A Download Microformat
On [Oct 20], at [ Oct 20] 12:33 , Martin McEvoy wrote: For me hAudio still didn't answer the question about an Audio Download itself (the file) I'm not clear on what problem you're trying to solve here; what exactly do you mean by the question about an Audio Download? And how, specifically, does hAtom's existing enclosure markup fall short of answering it? I think you're getting ahead of yourself in talking about markup before you've defined the problem. I know you're familiar with the process [1], but I really don't think you're following it here. [1] http://microformats.org/wiki/process -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] A Download Microformat
On [Oct 20], at [ Oct 20] 2:29 , Martin McEvoy wrote: The file itself the MP3 not the meta-data surrounding the File I got that. What I'm missing is what about the file you want to make machine-readable and why. And how, specifically, does hAtom's existing enclosure markup fall short of answering it? Nothing at all, accept hAtom does not support enclosure which I am sure you are aware of.. Actually I'm not. The See Also section of hAtom says: rel-enclosure - how to semantically reference enclosures (e.g. podcasts) in hAtom http://microformats.org/wiki/hatom#See_Also And rel-enclosure, of course, supports enclosures. But I gather it doesn't support everything you'd like to see. I'm just not clear on what's missing. Don't Patronise me I don't expect you'll believe this, but I didn't intend to do that. I still dont understand what particular points of the process you think I have missed It seems to me you've missed the part of the process where you describe the problem: http://microformats.org/wiki/process#Why.3F I was just trying to help, but it seems clear to me I failed at that the first time. If this likewise fails, please just pretend I said nothing rather than taking further insult. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
On [Oct 15], Martin McEvoy wrote: Sigh! Indeed. The content type should certainly be made explicit when known, but making it a class name is a mistake - the type attribute should be used as above. Making it into a class takes it away from the link, so you end up with stuff like this, which is meaningless: div class=haudio span class=fnExample/span a rel=enclosure href=foo1download 1/a span class=typeaudio/ogg/span a rel=enclosure href=foo2download 2/a /div Do you ever read any of my emails? ...don't you mean div class=haudio span class=fnExample/span a rel=enclosure href=foo1 type=audio/oggdownload 1/a a rel=enclosure href=foo2 type=audio/oggdownload 2/a /div You're both saying the same thing. In haudio Item is not Opaque Another imagined disagreement: Item [...] * The element MUST be processed opaquely. http://microformats.org/wiki/haudio#Item -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
On [Sep 1], at [ Sep 1] 6:39 , Manu Sporny wrote: *sigh* - and we were so close to getting hAudio to the draft stage... I sense another 3 month discussion coming down the pipe, prolonging the agonizing wait for hAudio to be finalized. Hopefully, I'm wrong I don't think this discussion necessarily needs to prolong finishing the initial version of hAudio. If we're agreed that we need a general mechanism for publishers to indicate relevant context of the assertions they're publishing, we should be able to move forward with hAudio while treating potential embedding issues as out-of-scope for hAudio. Calling it out-of-scope doesn't actually solve the problem, of course, but our evidence-based process means assuming it will be solved outside hAudio may be the best way to ensure it actually is. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
On [Sep 2], at [ Sep 2] 2:37 , Toby A Inkster wrote: In Cognition I support this with class=mfo, but if consensus forms around some other class name (e.g. hroot), then of course it's pretty easy to support that instead/as well. As this discussion seems to be gradually recreating the MFO proposal, I'd encourage everyone to build from the work already done there: http://microformats.org/wiki/mfo-examples -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
On [Sep 2], at [ Sep 2] 11:52 , David Janes wrote: hItem/item was intended to do more than that -- it was to bring in a number of commonly used class names (e.g. fn) so we don't have these year long discussions about how to do things that really the answer is already known. I completely misunderstood the intent of this proposal as being specific to physical objects and commerce. Now that I understand this proposal better, I prefer it to MFO, as it puts the emphasis on the content being published (where it belongs) rather than on parsing rules. I'll retract my earlier suggestion to build on the MFO work and instead suggest building on the item work: http://microformats.org/wiki/items-brainstorming Further, I propose merging the two, as they're basically the same proposal from two different angles. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
On [Sep 1], at [ Sep 1] 2:00 , Martin McEvoy wrote: fn was changed to title because it was over used in haudio, haudio title = fn haudio contributor = fn item title = fn and what If the author of the audio came first? This shouldn't be an issue. Every hAudio parser must understand contributors and items, so there's no room for confusion here. However, there *is* room for confusion when embedding hAudio in every other microformat using fn, as those parsers have no awareness of hAudio. And this is the problem mfo [1] seeks to solve. [1] http://microformats.org/wiki/mfo-examples -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Opacity (Was: change haudio title to htitle.)
On [Aug 14], at [ Aug 14] 5:22 , Martin McEvoy wrote: Is the item property in haudio MFO? Item *The element /MUST/ be processed opaquely. No sub-elements should be read from any hAudio contained in a track element. http://microformats.org/wiki/haudio#Item ... or am I misunderstanding the microformat object(opaque) problem. Item solves a small part of the problem MFO proposes to solve. Item has an opacity rule for embedding hAudio within hAudio. MFO would provide a similar rule for embedding anything within anything else. By detaching the opacity indicator from a specific microformat, MFO would have the advantages of being usable for embedding future microformats. For example, hAtom has no rule for opacity of embedded hAudio, and it couldn't possibly have such a rule because hAudio did not exist when hAtom was created. Because both use published, this leaves room for ambiguity MFO would remove. MFO also has the advantage of decoupling opacity from other semantics. Item makes it impossible to embed another hAudio with a shared name, but MFO would make that possible by giving the publisher more control over describing the meaning of their content. This could reduce unnecessary duplication, for example, in describing single- track album releases. The documented real-world examples with widely-published microformats are, of course, far more relevant than the above hypothetical examples with nascent hAudio: http://microformats.org/wiki/mfo#Examples -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Proposal: change haudio title to htitle.
On [Aug 13], at [ Aug 13] 2:19 , Toby A Inkster wrote: In my experience, from a practical point of view, it's not really needed - even if no microformats had any property names in common, parsers still need to take care over microformat opacity due to situations like: div class=vcard div class=agent vcard I don't think that's a similar situation at all. hCard parsers must know how to handle embedded agent hCards, because it's part of the hCard spec. On the other hand, hCard parsers not only don't need to know how to handle embedded hAudio, but in many cases they couldn't possibly know because they were written before hAudio even existed. And it doesn't seem to have proved a problem for 'url', which is defined fairly differently in RFC 2426 (vCard) and RFC 2445 (iCalendar). Untrue. Here are two documented real world examples (or rather two sites with thousands of examples) of exactly this problem: http://microformats.org/wiki/mfo#hCard_in_hCalendar This seems to be a solution to a problem which doesn't exist. Again, untrue. There are more examples on the MFO page. If it's a rare problem, that's because it only comes up when microformats are used in high density. Rather than being edge cases, these cases are the core of what we're trying to do with microformats. We're trying to encourage descriptive markup, and it's the sites with the most descriptive markup where existing parsing rules leave ambiguity. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New uF: Version
On [Aug 8], at [ Aug 8] 3:55 , Samuel Richter wrote: There could be a What's New section which would pop up in the application when a new version is found. I anticipate that this use case would follow existing processes with software update procedures, where the updater/installer periodically checks for the web page for updates, *or* subscribes to an RSS feed which contains the relevant information. Scenario: A higher version is found With the presentation of this information, a decision will be made: to install, or not. But, this would be configurable. For instance, the user may choose not to install alpha or beta software. Or, the user may want to review a list of changes for the new version, consider package size, dependencies, available space, etc. Thanks for this more detailed use case. Your mention of RSS made me realize hAtom has already solved much of this problem: http://microformats.org/wiki/hatom entry-title is version number, rel-bookmark is the download link, and entry-content is the change details. So I'd suggest starting with that and identifying gaps as they become evident. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New uF: Version
On [Aug 7], at [ Aug 7] 5:03 , Samuel Richter wrote: What about a version microformat. Something like this: snip for tagging versioned files. Keeping software up to date can be a major hassle. By placing version information on download websites, this process can be automated. Please respond. Let's talk about the general concept first. If it seems worth pursuing, we'll get into markup later. I guess I'm not yet convinced by your use case here. An application would periodically reload the web page for each application to see if it's been updated? How would the appropriate web pages be identified? Maybe you could walk us through the entire process of how you see this working? And how would this system compare to existing software update systems? Most of the software I use already checks for automatic updates. Also, do you have any additional use cases in mind for this? -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New uF: Version
On [Aug 8], at [ Aug 8] 8:28 , Ciaran McNulty wrote: On Fri, Aug 8, 2008 at 2:19 PM, Scott Reynen [EMAIL PROTECTED] wrote: I guess I'm not yet convinced by your use case here. An application would periodically reload the web page for each application to see if it's been updated? Plenty of applications 'dial home' to see if there are pending updates, and the same applications also have download links, so why not combine the two? I'm afraid you've misinterpreted my questions as rhetorical. I'm actually asking for the answers to those questions to better understand the use case, not making an argument about the merits of such a use case (I may do that after I understand it). When I said I'm not yet convinced, that's because I don't yet have enough information to convince me. To make this more concrete, here's a page that has a version number: http://www.panic.com/transmit/ The proposal seems to be to add descriptive markup around the 3.6 on that page. And how does this use case go after that? The Transmit application downloads that document periodically to check for updates? And if a higher version number is found, what happens next? And how does the process differ from how Transmit already checks for updates? And are there any other use cases for such markup? -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] ISO-31-1
On [Aug 7], at [ Aug 7] 3:25 , Glenn Jones wrote: Last but not least you have also just walked into the internalisation issue from the Human and machine readable data format debate. Not all languages use the Arabic numerals ie 0,1,2, 3 etc [1] http://en.wikipedia.org/wiki/Japanese_numerals Although most people will understand Arabic numerals and you find them mixed in with languages like Chinese, it's still an issue that need thought. I strongly disagree here. I think you'd have a hard time finding a single person in either Japan or China who both understands what a computer is (i.e. not counting extreme rural isolation) and is not very familiar with Arabic numerals. You can't buy a computer in either country without using either cash or credit cards covered in Arabic numerals. It's very likely you're also scanning a bar code with Arabic numerals and/or getting a receipt with Arabic numerals. Your clock, television, vehicle, phone, and ID card all use Arabic numerals. And when you turn your computer on, you'll see many more Arabic numerals (e.g. in the version number of your operating system). So I'd say a person looking at using microformats but unfamiliar with Arabic numerals goes well beyond an edge case. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Recipe proposal
On [Jun 5], at [ Jun 5] 10:34 , Charles Iliya Krempeaux wrote: It would make sense to be able to have the be marked up as optional ingredients. I believe there's been some discussion of this previously and it's not entirely straight-forward how to do this. I'd suggest we put this off for a future revision. It seems to me a recipe microformat could be useful without this information made machine-readable, and we should start as simple as possible. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hjob
On Mar 19, 2008, at 9:02 AM, Silviu Savin wrote: where are these 'job-listing' pages? Here: http://microformats.org/wiki/job-listing-examples http://microformats.org/wiki/job-listing-brainstorming I originally split job listings off from the hListing pages, and I now think I should have done more research into the limits of hListing before I did that. I'm no longer publishing job listings myself, but I'd encourage anyone who is to try out hListing and identify specifically where it falls short before continuing speculation about job listings. It seems to me it's already pretty far away from the start as simple as possible principle of microformats. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
Without weighing in on this issue, I'd like to interject a meta-note: While the two are loosely related, was it good to say TITLE means job title? is now a useless question, whereas is it safe to say TITLE means title? is a useful question. In the interest of progressing the discussion, I'd encourage everyone to make more effort to focus on the relevant and avoid polarizing the discussion around the irrelevant. The past can not be undone; let's try to move forward from where we are now. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hCalendar: opening hours
On Dec 17, 2007, at 4:20 PM, Klaus Mueller wrote: I want to describe opening hours of business, bars, doctores etc. I think I should solve this problem with hCalendar. But I think summary and description should be defined. And I got no really good idea how to describe repeating dates? Recurring events are largely uncharted territory in hCalendar, but it has been discussed. See, for example: http://microformats.org/wiki/hcalendar-brainstorming#Recurring_Events http://www.xfront.com/microformats/hCalendar_part2.html Summary is required, but could be as simple as open. Description is not required. I'd encourage you to post the actual HTML you're working with to the -discuss list and see what everyone thinks would be the best way to do it in hCalendar. This list, and starting a new microformat, should only be a last resort if hCalendar doesn't work. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 5, 2007, at 7:38 AM, Martin McEvoy wrote: where are the advantages of using span class=fn albumBest Before 1984/span over just span class=albumBest Before 1984/span ? The former indicates the album is the same as the audio (because they have the same name), whereas the latter may just be an album related to the audio. This allows publishers to focus primarily on individual songs or on albums as they do naturally. A track unknown album, detailed: span class=haudio span class=item span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span /span That adds an extra layer of container where none really exists. Item of what? We're only talking about a single song here, so why can't a publisher just focus on that song without wrapping a container around it? Not every song even belongs to an album, so it's not just unknown albums this would be forcing publishers to markup; it's also non- existent albums. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 5, 2007, at 4:24 PM, Martin McEvoy wrote: a single audio recording? Again, that depends what you mean by single. If you mean one item, then yes. An album is one piece of audio, a song is one piece of audio, an opera is one piece of audio, etc. If you mean contains no sub-items, then no. But of course that's not true of anything we markup with microformats. Events can be divided into sub-events, organizations into sub-organizations, a list into sub-lists, and so on. But why are you asking? Is there specific audio you're unsure of how to publish with the current hAudio proposal? If it's audio, put it in class=haudio. If it has sub-items, put them in class=item. Beyond that, it gets rather philosophical. Does anything really have meaning beyond the sum of its parts? We don't really need to answer that, so let's not. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 4, 2007, at 2:28 AM, Julian Stahnke wrote: div class=haudio span class=fnIn Rainbows/span /div No, that’d be a track. That would be an audio recording. It may be a track, or an album, or something else entirely, but there's not enough information in the markup to determine anything more than it's an audio recording. Oops, sorry. But why could it be an album, wouldn’t it need to be ‘fn album’ then? It would, but the lack of that doesn't make it not an album; it just makes it ambiguous. On Nov 4, 2007, at 3:16 AM, Martin McEvoy wrote: This is whats confusing about the whole fn album proposal fn album, means album album, means album fn means the name of the haudio object... which could be and album? Trying thinking of it like this: 1) class=album means name of album 2) class=fn means name of audio 3) If name of album and name of audio are same, audio is album. The third factor is not a re-definition of the property names when combined (there is no such thing in HTML); it's a consequence of two distinct properties having the same value (whether or not they're in the same element). -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hTurtle: A GRDDL-Compatible Microformat for Turtle-in-HTML
On Nov 4, 2007, at 2:41 PM, Sean B. Palmer wrote: 1. Invisible data. The data in comments is invisible. It's not invisible to the XML Infoset, or the DOM, or SAX parsers, or XSLT, or regular expressions, or so on, which is how hTurtle is able to meet its requirements. No, it's invisible to people, and focusing on data that's *visible* to people is a (maybe *the*) distinguishing characteristic of microformats. That's what people in this community mean when we say microformat, so coming here and using that term meaning something completely different is like going to China and speaking to everyone in English. There's little to be gained from this, and much to be lost. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 4, 2007, at 9:14 AM, Martin McEvoy wrote: 3) If name of album and name of audio are same, audio is album. fn album is being used to set a fn type of album No, it indicates the type of audio, not the type of name. There is no joint fn album property; that's two completely separate properties that happen to be classifying the same element. In HTML, one class name has no effect on the meaning of another. FN in HAUDIO *always* means name of audio. Imagine in real life someone asks you if you've heard Unicorns are Awesome. From that, you know Unicorns are Awesome is the name of some audio. Now imagine two weeks later someone asks you if you've seen the new album they bought, and you ask them what it's called, and they say Unicorns are Awesome. Now you know Unicorns are Awesome is the name of an album. You can put those two independent pieces of information together to infer a third piece of information: the album and the piece of audio are very likely the same thing because they have the same name. That third piece of information comes from the previous two pieces of information, but it doesn't change them at all. The name of the audio is still the name of the audio, and the name of the album is still the name of the album. Similarly, an hCard analogy: if you asked me who I work for, I might tell you John Deere, and give you the contact information for my employer (though that's not actually who I work for). Without any more information, you'd probably assume John Deere is a person, my boss. But then if someone told you there's an organization named John Deere, you'd probably put that together and realize my employer is actually an organization, because an organization and my employer have the same name. hAudio and hCard parsing is just requiring parsers to make this same sort of deduction from existing information. Now can you see why I am concerned about this proposal? I believe you're confused about the proposal and objecting to something that isn't actually proposed. I completely agree we shouldn't redefine FN, but because we're not talking about doing that, that's not really an objection to the hAudio proposal. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
On Nov 3, 2007, at 10:14 PM, Martin McEvoy wrote: You were a solid supporter of using audio-title and helped make the decision NOT to use FN That's not true. I think you have the order of events confused. ...We can't both re-use property names and ignore the context of those property names. My dog's FN is not my FN, and if the only way for me to make that clear is to use class=pet-name instead of FN, that's what will happen. http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html ? What changed your mind ?, this was the statement that made us support the use of audio-title Nothing changed my mind. I was not at all arguing against FN there, rather for the awareness of context that is necessary to use FN with embedded microformats. And I was arguing for that *after* FN was already discarded, because I thought it was unfortunate we had discarded FN rather than solving the context problem. Right now the necessary context is explicitly written into hAudio ITEM (The element must be processed opaquely). It still doesn't exist in other microformats, but the general consensus (arrived at on the -dev list despite my protest that it's more than a parsing issue) was that we shouldn't address this until it becomes a more widespread (and thus better documented) problem. Maybe it will never become a bigger problem, or maybe hAudio will force the issue. Either way, I'm for solving this problem with more explicit context rather than inventing new synonymous class names (e.g. audio-title) as a means of working around it. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM debate proposal #3
On Oct 28, 2007, at 8:23 PM, Manu Sporny wrote: Scott, I think you and I had the most adverse reactions to this approach. I've learned to live with it as this approach did not cause problems when marking up over 20 of the audio-info examples. Thoughts, suggestions, comments? As long as an ITEM within an HAUDIO is itself defined as an audio recording, I see no problem with leaving out the HAUDIO class name here. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] an equation/MathML/TeX microformat?
On Oct 26, 2007, at 9:58 AM, Paul Topping wrote: Also, I want to put the MathML or TeX in the page, not in separate documents. This seems to be the fundamental problem, and I doubt microformats can solve it. With microformats we can make maximum use of existing HTML tags, but we can't create new tags. And I don't think any existing HTML tags allow embedding of XML-based data directly in HTML documents. You could escape all the XML with entities, e.g. lt;mathgt;, but that would be far more work than a separate document. script can include XML, but implies the XML is a script, which MathML isn't really. If you're okay with such redefinition of HTML elements, you could do something like this: script type=text/mathml [MathML version] /script script type=text/tex [Tex version] /script noscript img src=[image version] alt=[text version] / /noscript Note that's just plain HTML, no microformat. You could also just wrap the XML in a comment, but HTML comments by definition don't have any semantics. You could wrap a container around the comment with semantics, but again you're getting into redefining HTML elements: div class=math img src=[image version] alt=[text version] class=photo / div class=mathml !-- [MathML version] -- /div div class=tex !-- [TeX version] -- /div /div That's closer to what microformats do, but not likely to be accepted by this community as it requires treating an HTML element as something completely different from what the HTML spec suggests. I believe anywhere else you put raw XML will cause it to be treated as (invalid) HTML. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] an equation/MathML/TeX microformat?
On Oct 25, 2007, at 10:23 AM, Paul Topping wrote: I'm trying to determine whether microformats is the right venue for developing a standard math representation within HTML. Thoughts? Is microformats the right place for this kind of thing? I don't know enough about math publishing to answer that question, but I would encourage you to try to answer it for yourself by familiarizing yourself with microformats. This is the first step of the microformats process: http://microformats.org/wiki/process That experience should give you a useful basis with which to evaluate the potential for a math microformat. You may already be aware of the ongoing discussion of including MathML in HTML 5, but if not, that's another avenue you may want to explore. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
On Oct 21, 2007, at 10:01 AM, Manu Sporny wrote: First, let me state that hAudio is about audio recordings, of which tracks and albums are a subset. This is a crucial point. As long as you continue to treat the root class meaning as something more specific than audio recording, it won't make much sense. While we have borrowed some design elements from hReview and hCard, we should not get confused between the various Microformats and hAudio. Indeed, I used other microformats as references for basic design structures, not to imply that anything about hAudio should affect those. That was apparently more confusing than helpful. The fact that it may make no sense to nest one hFeed inside another is completely irrelevant to whether or not it makes sense to nest one audio recording within another. The publishing examples suggest audio nesting makes sense, and any opposition to this model should be based on the real-world examples, not on hypothetical applications of the model to concepts that are completely out of scope. Brian Suda wrote: If that is so, then FN is NOT needed. FN is needed because the examples show that both album and song name are listed on a page next to each other. Such as when a blogger talks about a song that is a part of an album. This is done quite often on the hundreds of music blogs[1] on the 'net. For a specific example of this happening, check out Scissorkick[2], which usually lists songs and albums together. Additionally, ID3v1 and just about every other audio metadata tagging standard has the ability to specify the album name and the song name. We have plenty of examples[3] and metadata formats[4] that support this approach. We also have plenty of examples in which one audio element (album) is mentioned only once and treated as a container for several other audio elements (tracks). Both methods of organizing this information are common and the model needs to address both, as it currently does. It would be nice if we could simply use one or the other, but we shouldn't do that at the expense of not covering a significant portion of the examples. If you look at most popular applications for collecting audio (e.g. iTunes), you'll find both organization methods are present. In some views, tracks are listed with album names as a property, in others, albums are listed as containers for track names. Luckily HTML allows us to easily put one element inside another, so this duality of relationships between track and album isn't really complicated, unless of course you approach it assuming a simpler model than the examples actually imply. We are doing this because this structure is inherent in almost every audio example collected to date. hAudio is about audio recordings, audio recordings have parts that people specify, be it tracks, sections, movements, etc. hAudio is not hCard. At the risk of further confusing matters, hCard actually nests one person within another using the agent property, so it's not like this is a completely new concept. But hAudio is not a general proposal that anything should be nestable inside anything else. It's very specific to audio inside audio, and that nesting-inside-same- type is very specific to the nature of audio. Why is attempting to do something that no other microformat does a bad thing? Following precedent is important, but hAudio is very much doing that. The only things hAudio is attempting that are new are completely audio-specific, so there is of course no precedent in other microformats. We can take the *general* concept of nesting from other microformats (or more basically from HTML itself), but we can't take anything about the *specifics* of nesting audio within audio from them, nor does it make any sense to take that audio- specific proposal and apply it more generally. It is true that no other Microformat does sections/collections/parts. I disagree. XOXO does that. hAtom does that. hCalendar does that. No other microformat does that with audio within audio, of course, but that's an implied schema found in the audio publishing examples. We're not just making stuff up. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
assumed based on your previous experience in other unrelated contexts that a container could *never* be the same type as the contained items. I believe this assumption is false, specifically in the context of audio, and I challenge you to back up your assumption with some sort of rationale rather than just repeatedly stating it as if it were fact. !-- what is this? an album with a duration, or an un-named track in an album with a track duration? -- div class=haudio span class=item span class=albumAlbum 123/span abbr class=duration title=PT30M24S30:24/abbr /span /div That is incorrect markup. The parser would identify that as an album called Album 123 with a duration of 30 minutes and 24 seconds. --- how is that incorrect? what if that is exactly what i wanted? If you don't even know what it means, how could it possibly be exactly what you wanted? It is not the microformats process to start with markup and then try to figure out what it means. We start with publishing examples, and figure out how to structure them most easily for publishers. hAudio is about tracks and Albums correct? False. hAudio is about audio. --- no, i agree completely that hAudio is a SINGLE audio recording. My issue is mainly with your original example which no longer models hAudio as a SINGLE audio recording: Album with two tracks, more detailed: That an album is not a single audio recording is your *opinion*, not a fact. The examples have suggested this opinion is wrong. Which brings us back to the my more verbose default TRACK of: span class=haudio span class=item span class=fnHokkaido Dream/span /span /span This (for now until we discuss optimizations) is how you would need to write JUST a track. For now we're using a schema that everyone agreed to before you entered the discussion. You're welcome to try to question that schema and explain why you think a different schema would be better, based on real world examples. But you can't just declare a different schema. That's not how the microformats process works. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
could be class=item haudio, if necessary. That's what we were discussing, all under the assumption that the relationship between tracks and albums would be determined by HTML containment. Your proposal does not share this assumption, and I'm still not sure if that's because you see something wrong with it, or you just didn't understand it before. If the former, please explain. If the latter, I hope it's clear now. They would need to be two distinct haudio items because haudio models TRACKs not albums. hAudio models audio, which includes both tracks and albums. Similarly, hCard models contacts, which includes both people and organizations. The duplicate data could be solved with the include-pattern. It could be, but I think it's simpler to use HTML's existing containment semantics, as hAtom does. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: Microformalyze (was: Playlists and Albums (was: Re: [uf-new] item property))
On Oct 19, 2007, at 3:15 PM, Martin McEvoy wrote: I ticked both boxes in the GUI Baba and Flumps and outputted the data in the terminal Baba : 100.00% Flumps : 100.00% I looked at your page thinking Huh how can that be correct? It's not correct, but that's because you gave it incorrect information by clicking boxes for properties that weren't really there. The tool itself isn't determining what properties are there or not there at all; it only makes it easier for a person to do that. As Manu was the person who analyzed most of the hAudio sites, your suggestion that the data isn't trustworthy is essentially a suggestion that Manu isn't trustworthy. Obviously no one is perfect, so if you still think the analysis is wrong, please try to point out specifically where you see errors so we can correct them. So far I get the impression you're just using a different meaning of the word track than Manu. As long as everything Manu called track is relatively the same type of information, the specific name isn't particularly important at the schema analysis stage. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
On Oct 14, 2007, at 9:20 PM, Manu Sporny wrote: Scott, Andy - do each of you have further thoughts on approach #1 (assuming we can change the definition for ITEM)? Would it be acceptable to either of you? I don't have strong feelings either way on item vs. track. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
On Oct 15, 2007, at 7:28 AM, Michael Smethurst wrote: Not wanting to add to the confusion but would it not be possible to have infinitely nested haudios with neither item or track and use mfo when the markup enforces containment that you don't want to be reflected in the model? As much as I'd like to move forward a general MFO technique, that isn't necessary here as the hAudio proposal specifically makes all contained hAudio (currently called track) opaque [1]. The current proposal appears to only support two levels of nesting, but that may change. Examples of several levels of audio published on the web today would help support such a change. [1] http://microformats.org/wiki/audio-info-proposal#Track -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
On Oct 14, 2007, at 12:45 PM, Julian Stahnke wrote: A container for another hAudio item. Used in conjunction with album-title. [snip] * hAudio MAY have one or more tracks, but MUST have album- title defined. If album-title is not defined, track cannot be defined. Sorry to be jumping in late here, but I'm afraid this poses a problem with self-titled albums, of which there are many in existence. Unless the implementer is forced to input S/T or self-titled as album-name, which is still incorrect because that's not what the creator has named the album, the model fails. I don’t think you can make album-title mandatory. Unless you can tell me what album Martin Luther King’s ‘I have a dream’ speech is on ;) There are far too many mentions of tracks which include only artist name and track name to require album-title, in my opinion. Take a look at music blogs, for example. You should definitely not need to mention an album as it may be inconvenient, the track may not have an album yet or is not a music track but a speech or something hence not having an album at all. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new -- Scott Reynen, Web Developer 303-717-1543 [EMAIL PROTECTED] ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
On Oct 12, 2007, at 9:39 PM, Manu Sporny wrote: Martin, can you post some markup for the same 5 examples above using your proposal? Yeah, I'd like that too, Martin. It seems to me you're making several proposals at once, and I'm not able to conceptually separate them enough to understand and respond. Examples of the various types Julian posted earlier (single track with album, single track without album, single album without tracks, single album with simple tracks, and single album with detailed tracks) would help clarify for me exactly how you see it all fitting together. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
On Oct 13, 2007, at 8:32 AM, Martin McEvoy wrote: Why is track nested in item in the latter example, but not the former? where Item only has a single property it can be used: span class=item fnNagasaki Nightmare/span of course you can do it like this, span class=itemspan class=fnNagasaki Nightmare/span/span but I dont really see the point? The point is clear semantics. There's no way of knowing with class=item fn that the fn is a subproperty of the item. Merging properties and subproperties into the same element is not considered valid in any microformat for this reason. If you want to change that, please raise the issue in a thread outside the hAudio discussion, as it would be a major change affecting every single microformat. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
On Oct 13, 2007, at 8:00 AM, Martin McEvoy wrote: works for me too but without the haudio on every item, Please respond to the concerns Manu and I already raised about this, which I've updated below with our current naming preferences: On Oct 8, 2007, at 11:13 PM, Scott Reynen wrote: On Oct 8, 2007, at 9:33 PM, Manu Sporny wrote: I have to admit, though, that the above mark-up just doesn't sit well with me. We have to assume that properties inside of ITEM are of type hAudio and can use any of it's properties. In other words, we are assuming the type of the contents of ITEM is an hAudio based on the parent container, which is hAudio. Not only based on the parent container, but also based on the contained properties, because an item with no fn isn't hAudio. So someone looking at an element with class=item would need to look both at the parent elements and at the contents of the element to know what exactly item means. I think it's simpler for item to always mean the same thing, and use the hAudio class to clearly indicate whether or not it's actually hAudio. Similarly, hCard has an agent property, which can itself be another hCard, and we mark this with class=agent hcard. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
On Oct 12, 2007, at 2:01 PM, Manu Sporny wrote: If we were to use FN, it would be impossible to distinguish between an album (an concept that can contain more than one hAudio) and a song/speech (an individual hAudio). I don't think that's true. hCard uses FN for two different types of contacts: organizations and people. The main item's name is class=fn. If that main item is an organization, it's class=fn org. If the main item is a person within a stated organization, the person's name is class=fn and the organization's class=org. hAudio is only slightly more complicated because we can also have an album with several tracks, whereas we never use a single hCard to list an organization and several members. For that case we could still use track. Examples of how this might work based on Julian's earlier examples: Single track, with known album (same as putting text in the ‘album’ field of an ID3 tag): span class=haudio span class=fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span Single track, album unknown: span class=haudio span class=fnNagasaki Nightmare/span span class=contributorCrass/span /span Album: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span /span Album with a couple of tracks, simple example: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=trackNagasaki Nightmare/span span class=trackNagasaki Nightmare/span span class=trackNagasaki Nightmare/span /span Album with a couple of tracks, more detailed: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=track haudiospan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=track haudiospan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=track haudiospan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span /span -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Pattern: Presence of Property
On Oct 9, 2007, at 6:43 AM, Ben Ward wrote: span class=ingredient3 Strawberries span class=optional (optional)/span/span What would people think about this sort of parsing rule being added to the microformats cannon? I don't like how that reads. The HTML spec says of the class attribute the element may be said to belong to these classes [1], but I don't think that's true in this case. We would say 3 Strawberries (optional) belongs to the class of ingredient but we would not say (optional) belongs to the class of optional. 3 Strawberries belongs to that class, which would give us this: span class=ingredient optional3 Strawberries/span (optional) But that also gets into repeating ourselves. Alternatively, I think it may be better to say that (optional) belongs to a class of dispensability, giving us this: span class=ingredient3 Strawberries span class=dispensability (optional)/span/span And maybe some parsers could assume any amount of dispensability makes something entirely optional, but others may choose to present the specific level of dispensability to users directly, as it may contain more specific information. [1] http://www.w3.org/TR/html401/struct/global.html#h-7.5.2 -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Closing several hAudio issues
On Oct 8, 2007, at 9:33 PM, Manu Sporny wrote: div class=haudio div class=track span class=audio-titleNagasaki Nightmare/span abbr class=duration title=P268T4:46/abbr /div and span class=trackBloody Revolution/span taken from span class=album-titleBest Before 1984/span By span class=contributorCrass/span /div I have to admit, though, that the above mark-up just doesn't sit well with me. We have to assume that properties inside of TRACK are of type hAudio and can use any of it's properties. In other words, we are assuming the type of the contents of TRACK is an hAudio based on the parent container, which is hAudio. Not only based on the parent container, but also based on the contained properties, because a track with no audio-title isn't hAudio. So someone looking at an element with class=track would need to look both at the parent elements and at the contents of the element to know what exactly track means. I think it's simpler for track to always mean the same thing, and use the hAudio class to clearly indicate whether or not it's actually hAudio. Similarly, hCard has an agent property, which can itself be another hCard, and we mark this with class=agent hcard. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
So this simpler proposal makes perfect sense to me. at least someone on the list Is starting to make sense. Oh And thanks for Quoting me out of context.. Let's all try to clearly state what we mean without sarcasm and avoiding assumptions about what others mean, in the interest of clarifying disagreement and finding agreement. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
On Oct 6, 2007, at 12:24 PM, Julian Stahnke wrote: What does ‘track’ mean in the context of the hVideo format, though? I think we're getting distracted here. That's a good question for the hVideo discussion, but it's really irrelevant to the hAudio discussion. Audio tracks need to be clearly identified as audio tracks regardless of what happens with hVideo, so let's focus on how to do that and leave hVideo for a separate discussion. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
On Oct 6, 2007, at 4:54 PM, Manu Sporny wrote: PODCAST is disputed by Martin and since I'm the only person that is backing it based on the examples, it will probably be dropped unless somebody else wants to see the ability to mark up PODCASTs via hAudio. That's assuming those who don't want a podcast class don't want to be able to markup podcasts, which in my case is a false assumption. I don't want a podcast class because I think we can markup podcasts without it. Specifically, hAtom + hAudio = a podcast. If you see something missing there, please clarify what exactly. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)
On Oct 4, 2007, at 7:09 PM, Manu Sporny wrote: PROPOSAL: TRACK and HAUDIO can co-exist in the same CLASS attribute, but they must be specified in that order. It is the hAudio parsers job to detect the co-existence of these two properties and act accordingly. [...] The only reason I mention that order is important in the attribute list is because we might have 'track hvideo' in the future for DVD chapters, television episodes or other track-like items. I'm not sure l understand that reason. If you're saying that a class=track haudio should carry the same meaning as a class=haudio inside a class=track, I think that's a bad idea. It discards useful HTML container semantics and introduces container semantics to the class attribute where none have existed previously. But I also don't understand why we were ever treating those as separate elements. It seems to me we're not talking about a track that *contains* audio, but rather a track that *is* audio. If that's the case, why wouldn't they belong in the same element? On a similar topic, why does the contributor description say The contents of the element must *include* a valid hCard Microformat rather than The element must *be* a valid hCard Microformat (emphasis added)? In hCalender [1] we say ATTENDEE, CONTACT, and ORGANIZER in iCalendar may be represented by an hCard in hCalendar. So we use class=organizer hcard (or class=hcard organizer) because the organizer is exactly the same entity as the hcard. Why should contributor work differently? [1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Musician hCards (Was: hAudio ISSUE #8: hAlbum is redundant)
On Sep 28, 2007, at 2:20 PM, Julian Stahnke wrote: Secondly, is there any means of marking up *just* an artist? I guess that might be out of the scope of the haudio microformat, but it would be quite important to have this possibility. There certainly are pages out there who only mention an artist without naming any specific tracks, and the role property of hCard seems not very suitable for that task as very few people would write—in a blog post, for example—‘the artist so-and-so’. I’m sorry if the second thing doesn’t belong in this thread, I’ve never before used a mailing list. Should I open a separate issue for this? When you recognize something is out of scope for a given thread, yes, you should open a separate thread. I mark up musician hCards with class=band vcard, e.g.: http://playinghere.com/band/tylerjames/ You should start with semantic HTML (whether or not it matches what I've done). Then if you then see value in standardizing your semantic HTML among multiple publishers (with a microformat or otherwise), this publishing experience will serve as a useful guide. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming
On Sep 28, 2007, at 5:16 PM, Andy Mabbett wrote: I believe the above example where the date of the currency is not implicit is rare enough to be left aside for now for the purpose of moving this proposal forward and avoiding confusion within publishers. +1 - this seems like a fairly rare case (hardly any examples to date) Examples of such usage have been provided; past experience is that quantitative evidence is of little interest to the community. Per the guidelines [1], please cite URLs for the examples you're discussing (these? [2]) to ensure you're all at least in agreement about what exactly you're disagreeing about. [1] http://microformats.org/wiki/mail#General_guidelines [2] http://microformats.org/wiki/currency-examples#Historic_prices -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] The Process (was: hAudio case study)
On Sep 12, 2007, at 4:33 AM, Brian Suda wrote: Quantity does not equate quality! Right. I think we tend to get caught up in whether or not the numbers are convincing to our fellow community members, and lose track of the important question: whether or not the end result is convincingly useful for publishers. Most publishers don't care if the examples we collect are statistically significant; they only care if it looks useful for them. More examples helps with that goal, but there's not really quantifiable finish line. I suspect much of this problem could be resolved with better scope definitions. When someone says these examples don't cover my needs, rather than collecting more examples to prove those needs are edge cases, we could be referring back to the scope definition and saying sorry, your needs are outside the defined scope of this microformat. But that only works when the scope is very clearly defined in advance. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
On Sep 12, 2007, at 1:58 PM, Manu Sporny wrote: If we do that, we will lose the ability to differentiate between an album, podcast, toplist, download, and chart. Can you explain a bit more what exactly we gain with that ability, in terms of practical capabilities? How would a hypothetical application treat two documents differently if they were otherwise identical, but one said album-title and the other podcast-title? Everything else, I thought, was determined to be out of scope. You previously wrote [1]: There are only two things that are strongly supported by the audio-info-examples right now. Audio albums and audio podcasts (collections of audio). Has that since changed? [1] http://microformats.org/discuss/mail/microformats-new/2007-May/ 000442.html -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Analyzed collected receipt samples
On Aug 16, 2007, at 9:01 PM, Clay Newton wrote: There is significant overlap in the data elements for each of these records. It would seem to me that one microformat could support the sum of these phases. Thoughts? If the receipt microformat proposal ends up supporting your needs, that's great. But if it would need to be changed significantly to support those needs, that's a good indication that we're really dealing with two distinct types of information, in which case it would be a mistake to try to merge them together. Start simple. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #4: Display values for rel-patterns
On Aug 17, 2007, at 10:35 AM, Manu Sporny wrote: hAudio ISSUE #4: open issue! http://microformats.org/wiki/audio-info- issues#Problem:_Display_properties_of_rel-patterns The following markup summarizes this problem: a rel=purchase href=/buy/song/3742827384 title=Buy The Song img src=/images/buy_song.png alt=Buy Song Image / /a What value do you use for displaying the previous markup? Is it rel-purchase or rel-payment? I think each parser will need to determine this for themselves, within their own design constraints. It's not really a semantics issue to be defined in the microformat, as the semantics of @rel don't really tell us anything about the two URLs, only how they're related. That said, if I were writing a parser, I'd probably use [audio-title] [EMAIL PROTECTED], where [audio-title] is the value of the audio- title property and [EMAIL PROTECTED] is the value of the rel attribute, e.g. April In Paris enclosure or Kid A sample. Those seem like descriptive enough labels to me. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformat for implementing RFC2119
On Aug 9, 2007, at 11:04 AM, Dr Orlovsky MA wrote: I. Background and the problem -- I've been looking into the possibility to semantically markup RFC2119 [1] keywords (like MUST, SHOULD BE etc) in the HTML version of some technical specifications. The problem is that none of the existing HTML 4.10 and proposed HTML5 tags are suitable enough for this task. It sounds like you just want plain old semantic HTML, not a microformat. Search-ability and style-ability, the two clear use cases I see in your proposal, don't really require everyone to use the same class names. One person could use class=rfc-2119 and another class=rfc2119 and both would be style-able and both would be search-able (except that no existing search engines allow searching on class names, as far as I know). So I'm not clear why this needs to be a community effort vs. just approaching individual spec. publishers and asking them to improve their own markup. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Songbird/POTI requirements for hAudio
On Aug 8, 2007, at 10:40 AM, Manu Sporny wrote: If we can't deliver on that as a community - they won't have much interest in implementing Microformats in Songbird. We *can* deliver on that, but that doesn't mean we *should*. Support by any specific tool should always be a lower priority than covering what people are commonly publishing as simply as possible. It sounds like Songbird has very different priorities than microformats. That's okay. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformat for expressing uncertainty?
On Jul 31, 2007, at 11:26 AM, Manu Sporny wrote: So in other words, we're talking about uncertainty in more than one dimension, as expressed by a covariance matrix. Hi Charlie - to work on this, you would have to demonstrate a number of places on the web that already publish information like this. How many websites out there publish numbers with associated covariance matrices? Microformats don't try and invent new ways of publishing information. If you can't find at least 10-20 examples of this happening on the web, you are going to have a very hard time asking the community to spend time to create the Microformat that you're proposing. I agree that demonstrating broad community value is necessary if you want broad community participation. That's just how people seem to work, and microformats formalize this to reduce wasted time. But while it's naturally the focus of this community, broad community value isn't the only kind of value. Disinterest here shouldn't be taken as a sign that something is worthless, only that this community is probably not the best place to pursue it. There is plenty of value in standardizing HTML for individual people or organizations. And where this overlaps with the broader community efforts of microformats, i.e. where we can help, we're generally eager to do so. The subject quest here is Microformat for expressing uncertainty? It seems the answer to that is probably no. But rather than stopping there, I'd encourage you to ask a different question: Plain old semantic HTML for expressing uncertainty? I believe the answer to that is likely yes. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Currency: more non-USD examples needed
I was going to continue discussion about a currency microformat, but I realized that the examples collected and analyzed so far are nearly all USD. I don't think we can really make any knowledgeable proposals without more comprehensive examples, so I'm going to postpone further brainstorming and focus on collecting more examples. And I'd of course encourage others to do the same. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] microformat granularity: currency and measure
On Jul 19, 2007, at 1:23 AM, Andy Mabbett wrote: * Occurrence of dated money amounts is judged rare: See http://microformats.org/discuss/mail/microformats-discuss/2006- September /005802.html ...for some value of rare. I have provided evidence of widespread use f historical monetary values. Five dollars today does not have the same value as five dollars did a hundred, or even twenty, years ago. For what it's worth (I don't expect much), I share Guillaume's impression that historical values are not necessary for a useful simple-as-possible baseline version of currency. Also, have we explored alternative means of capturing this information, e.g. hCal? symbol suffered the same lack of consensus, possibly due to a lack of understanding of the benefits. Maybe a more detailed explanation of the benefits of such a class name would be worth writing. If I understood correctly, the main value would be for a user agent to be able to replace it with the symbol of the currency that the amount is converted to. If that's the case, I would argue that a user agent may not want to replace the content, since it may fool the user into believing that these amounts are guaranteed by the publisher/merchant, where in fact, they would be mere estimates, which may differ from the actual rate charged by the merchant or the financial intermediary. That's hypothetical argument backed with no evidence. As is the value of symbol, which I gather was Guillaume's point, and a larger concern. Until that value is explained more convincingly and gains more consensus, is there any harm in moving forward with the smaller set of properties everyone already supports? We can always add symbol later, right? Or is symbol so important that a currency microformat is useless without it? If so, that importance isn't yet apparent. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Currency: symbols and units (Was: microformat granularity: currency and measure)
On Jul 19, 2007, at 3:49 PM, Guillaume Lebleu wrote: How would you mark those up? Good question. Here is a try, using the value class name: span class=moneyabbr class=unit title=cent¢/abbrspan class=value2.1/span span class=currencyUSD/span/span I would suggest this: span class=money¢abbr title=0.021 class=amount2.1/abbr span class=currencyUSD/span/span I also don't see much value in unit as I think it would be simpler to standardize on a single unit for each currency (i.e. the primary unit defined for the given currency in ISO 4217) and use the abbr design pattern as above where necessary. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] acessibility problem with currency microformats
On Jul 18, 2007, at 4:38 PM, Alexandre Van de Sande wrote: it looks like again the currency is using a already documented acessibility problem of abusing the abbr tag. this costs div class=money abbr class=currency title=USD span class=amount42.67/span /abbr /div Where do you see this? I don't find it in currency-proposal nor currency-brainstorming. Wherever it is, I wouldn't worry about that becoming a standard, as it doesn't make any sense. screen readers are taught to , when encoutering and abbr, to read the title instead of the content, that's why abbr was created. This already happens in other microformats and is an error. I don't believe there are any microformats that encourage abbr for non-equivalent content such as above. If you know of any, please point them out specifically. The abbr-design-pattern [1] specifically says Avoiding using the abbr-design-pattern to re- encode human text or to hide data. There are known issues with abbr being used for content that doesn't read well in screen readers (e.g. ISO dates) [1], but we don't yet have consensus around an alternative, so for now, we use abbr. [1] http://microformats.org/wiki/abbr-design-pattern -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Fwd: [uf-discuss] Error messages
Begin forwarded message: From: Evan Prodromou [EMAIL PROTECTED] Date: July 14, 2007 5:28:02 AM MDT To: [EMAIL PROTECTED] Subject: [uf-discuss] Error messages Reply-To: Microformats Discuss [EMAIL PROTECTED] One of the most common HTML patterns in Web applications is error messages. We see them all the time on the Web: login errors, form validation errors, backend errors and user input errors. But what if this common pattern was standardized? If HTML error messages all followed a similar format, we could have browser plugins that recorded and analyzed the errors that come up. They could either feed back this structured error data when we needed it -- say, when filing a bug report or talking to a tech support rep -- or use the error data to help us find workarounds or documentation online. I brought the idea up in the #microformats channel on Freenode, and it got a good response, so I took the next step and created a list of examples and a brainstorming page on the microformats wiki. http://microformats.org/wiki/error-message-examples http://microformats.org/wiki/error-message-brainstorming I'd greatly appreciate the help of people on this list in collecting error messages from the wild, and hopefully in building up a draft microformat. ~Evan -- Evan Prodromou - [EMAIL PROTECTED] - http://evan.prodromou.name/ -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] audio-title proposal for haudio
On Jun 11, 2007, at 10:22 AM, Manu Sporny wrote: I am proposing that we use 'audio-title' and leave it at that. I'll work this into the haudio proposal at the end of this week unless there is strong opposition to this proposal. If you are strongly opposed to 'audio-title', please provide an alternative in your argument against it. I'm not sure my opposition is strong, but I would personally prefer working out parsing rules to allow for embedded microformats with shared property names, and then re-examining the alternatives without this as a constraint. But again, I think the wiki should reflect the diversity of views, and not be restricted to what is seen as consensus. Email archives are a poor medium in which to review decisions, as indicated by nearly every other message in this thread starting with we already talked about that... -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Reusing classes names in multiple formats
On Jun 8, 2007, at 10:01 AM, Brian Suda wrote: On 6/8/07, Scott Reynen [EMAIL PROTECTED] wrote: This is the same problem with re-using any class name in multiple microformats. As mentioned earlier, if we re-use summary in haudio (which I'm not arguing for nor against here), what if we want to embed haudio inside hreview? SUMMARY is defined as: A short summary or subject for the object. http://microformats.org/wiki/classes Right. There seem to be two issues here: 1) using the same term to apply two different meanings and 2) using the same term to apply the same meaning to two different concepts. Both are an issue with title, but the latter is still an issue with summary and entry- title. If we want to use any of those, we need to work out this issue, as hAudio is specifically designed to be contained in existing microformats. How do we keep the haudio summary from becoming the hreview summary? --- this is true, but sometime you want it to be both! Microformats are purposefully simple and MICRO, we are quickly getting to WHAT IF... Obviously everything with hAudio is a what if, as no one is using it yet. But using hAudio in hReview is one of the most obvious use cases. It's so obvious that we even considered foregoing hAudio entirely and just using hReview. So hoping it won't come up strikes me as foolish. Embedding hAudio in other microformats is a given. Modularity and micro go hand in hand. the original intent of microformats is NOT to boil the oceans I'm not suggesting we shouldn't use existing class names; I'm suggesting we should think about how that's going to work. Please don't waste my time reciting microformat principles to me; after two years, I have them memorized. More generally, I think we should be defining parsing rules based on the semantics, rather than vice versa. --- this is difficult because the semantics are meant to be the same, it is context that you want to look at, and sometimes you WANT it to be in both contexts at the same time. So let's account for that. Here's a simple rule to get the ball rolling: for properties that should only occur once, only the first occurrence should be parsed. This would allow us to use summary in hAudio within hReview, with the two values identical if there's only one, or separate as long as the haudio summary comes after the hReview summary. And it would work just as well with fn or entry- title or whatever we choose. So context collision is no longer a constraint on re-using existing classes (though semantic collision, of course, still is as it should be). IF we start to propose that every term be prefixed with hcard-title so it doesn't collide with media-title then we are no better off than RDFa and namespacing. I agree, and I don't believe I anywhere suggested a new hyphenated class name, so I'm not sure why you're bringing it up. firstly we should look at all the available properties[1] regardless of where they are used. I agree. And then we should figure out how we can actually use those properties without confusion. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] title vs. summary (was: Third attempt at hAudio)
On Jun 8, 2007, at 2:45 PM, Martin McEvoy wrote: I think at the time hCard was meant to be identical to the vCard Standard in every way and mach the scheme defined in http://www.ietf.org/rfc/rfc2426.txt there was no guess work or defining or anything just well established standards for us to use title from vCard would mean that our meaning in hAudio would have to match the title attribute in the vCard standard. Right. the only other microformat that does use Title is of course hAtom which is also built around rfc standards http://www.ietf.org/rfc/rfc4287 Atom hAtom actually uses entry-title. While that has a similar meaning to title in English, those two terms have completely distinct meanings in microformat definitions, because microformats definitions are by necessity more specific than English definitions. this is why we cant change hAtom to suit our needs because it is based on already well established standards. Right, but if we can re-use existing class names without changing the meaning, we should do so, as it makes things easier for publishers. Summary as Brian put it is the easiest fruit to pick from the tree as most or the established microformats hReview, hResume, and hCalendar already use summary to mean exactly what we want it to mean. There seems to be some disagreement over whether summary is actually what we want it to mean. I point this out not because I personally disagree, but because addressing this disagreement is required before moving forward, which I think we'd all like to do. The discussion around re-defining the vcard title to mean what we want it to mean may take a very long time to accomplish, and it would have to be via the microformat process. Right. I think trying to change hCard, one of the oldest microformats, before moving forward with hAudio is a good way to grind the hAudio discussion to a halt for a long time, so I think we should do whatever we can to avoid that. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] title vs. summary (was: Third attempt at hAudio)
and moving on, I expect most people interested in hAudio will opt to just choose a different name. Repeat that over every microformat, and you get where we are now. I believe the answer is that because existing parsers would have to be constantly updated to handle new uFs contained therein. In other words, hCard parsers would have to be re-written to handle contained hAudios. Am I following that argument correctly? Pretty much. With title, there's also an argument that we should neither use the same term to mean different things nor change the meaning of terms in already-published microformats. I expect even slightly expanding the meaning of a term in a microformat published as widely as hCard would be an uphill battle. If so, I don't quite understand the problem because hCard's don't contain hAudio. Or can they? They could. My hCard is here: http://typewriting.org/about/scott/ If you look at the source of that page, you'll see the hCard covers almost the entire page, because my name is at the top and my birthday is at the bottom. If I wanted to list my favorite song on that page, as I've previously done, I couldn't do it in hAudio without risking the song title would become my job title, as long as there are no rules to prevent that. This is still an edge case, but it's an edge case that grows exponentially every time we re-use an existing class name in a new microformat. Is there some way to embed arbitrary content into an hCard and have it actually be logically or semantically /embedded/ in the hCard? I know you can do it presentationally so it displays the data. But does the hCard data model have a place for arbitrary embedded content? If so, couldn't the parser simply ignore the children of that field when parsing for title? Notes, maybe. Ideally someone would be able to include an hAudio inside the node of an hCard without influencing the hCard at all. Also, it would be nice if there were a general solution that worked on any microformat embedded in any other. That's generally where this seems to be headed: http://microformats.org/wiki/mfo The idea there seems to be that the included hAudio could have the mfo class added, e.g. class=haudio mfo and that would indicate to any hCard parsers that they should ignore that section the surrounding hCard. The same would work for embedding hAudio in hReview if we decided to re-use summary, or with embedding hAudio in hAtom if we re-used entry-title. But there are several issues with that idea, and I haven't seen much interest in discussing it further. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On Jun 5, 2007, at 6:46 PM, Manu Sporny wrote: Scott Reynen wrote: On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote: A classical recording is a good example -- unlike popular music, the tracks on the album are often merely segments of a larger whole, f.e. Beethoven's Fifth is comprised of four movements. All of the same information that can be applied to a track can be applied to an album or playlist. They're really just divisions of a larger whole. The only information I could see an album of playlist needing that a track wouldn't would be: # of tracks and # of discs. If that's the case, what do we gain from using separate terms for album and track? Either it's useful to distinguish between the two with labels, or it's not. album, summary, and track, when combined with haudio, are more semantically accurate when describing audio albums. They add semantic specificity to haudio which is needed to differentiate haudio that describes an album, and an haudio that describes a track. We shouldn't need to combine terms to arrive at semantic accuracy. Each individual term should describe a specific, easily understood concept by itself. For example, fn describes a name. We all know what a name is. haudio, on the other hand, currently describes a collection of metadata about some type of audio. It's not clear what that really means outside the context of album or track. I don't think I'm going to publish an haudio on my website. I think I'm going to publish a track on my website or I'm going to publish an album on my website. Where are the examples of something that would be haudio being published with no album or track? I'm not finding any such examples in the wiki. I believe that Colin (and I) are arguing against complicating halbum any more than necessary: Right, me too. We just disagree about what is complicated. halbum title contributor image-summary duration payment Why should we do the above, when something much simpler would solve the problem: halbum summary haudio In my view, that's not simpler; it's just fewer concepts. haudio is a new concept, which publishers don't currently understand, so we'd need to explain what it means, which is basically title, contributor, image-summary, etc. I see no reason they should need to learn a new concept for the container of all those already- understood concepts. That you are able to look at haudio and understand title, contributor, etc. does not mean that anyone else will be able to do the same. What you're actually asking publishers to understand and publish is this: halbum summary haudio title contributor image-summary duration payment Which I think is clearly more work for publishers than the same schema without the additional layers of summary and haudio. Also, I think those layers are poor semantics. We're not talking about the title of an haudio of a summary of an album. We're talking about the title of an album, and the markup should clearly reflect that. On Jun 6, 2007, at 1:43 AM, Joe Andrieu wrote: Why don't we stop worrying about albums and just solve audio-info? I think this is a great idea. On Jun 6, 2007, at 8:22 AM, Manu Sporny wrote: The reason that we are focusing on albums right now is because the first draft of audio-info seems to be done. I disagree. Nobody seems to have raised any issues related to existing elements in the haudio draft in several weeks. I don't know how you can possibly think that. Multiple people have suggested changing the wiki entry in just the last few days, and you've said you don't think it should change because there's not enough consensus. Now you're saying there's complete consensus? I still don't understand what exactly class=haudio means. That's hardly a minor issue. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio - audio-album and audio-podcast
On Jun 5, 2007, at 4:50 AM, Martin McEvoy wrote: On Mon, 2007-06-04 at 20:42 -0600, Scott Reynen wrote: On Jun 4, 2007, at 6:33 PM, Joe Andrieu wrote: The alternative to the above that I thought you were going for was something like this: halbum playlist/XOXO haudio haudio haudio haudio That makes sense to me. How so? Well, I know what albums are, I know what playlists are, and I know what audio files are, so this is describing familiar concepts, specifically the concepts I thought we were trying to model. example of the proposed method: halbum haudio [album title,contributor,image-summary, duration, payment] xoxo track haudio [track 1, duration, sample] track haudio [track 2, duration, sample] track haudio [track 3 duration, sample] what doesn't make sense here? guys. The label haudio appears to be describing two distinct concepts here (1: album information, 2: individual track information), which I find confusing. That these two concepts share some properties, but that doesn't make them the same thing. I think there are two many layers of abstraction here. haudio should describe something specific, e.g. an audio recording, not a vague collection of metadata that could apply to a wide variety of things. The only possible argument here would be ... Here's the argument I'm making, impossible though you may deem it: I'm confused, and microformats should not be confusing. so Now it becomes useful to define which track is music and which is video or Images. I'd say if track isn't clearly specific to audio, haudio should use a different label which is clearly specific to audio, as that's all haudio is about. example halbum haudio [album title,contributor,image-summary, duration, payment] maybe you do have a point though in the context of just an album description hAudio becomes a little redundant as this is indeed nothing that is Audio just a description of audio maybe this is better: halbum summary [album title,contributor,image-summary, duration, payment] It seems to me we're talking about the title, contributor, etc. *of the album*, not of the summary of the album, nor of the haudio of the album. So I don't see the value of an intermediate container here. So I would suggest the following schema for album information, placing the properties directly within the album container: halbum title contributor image-summary duration payment http://www.xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.8 All of the terms there seem to be audio-specific. I think all of the terms in haudio should be similarly audio-specific. On Jun 5, 2007, at 7:58 AM, Manu Sporny wrote: hAudio describes information about an audio recording. I would suggest that an album is not an audio recording; it's a series of audio recordings. So if hAudio is about audio recordings, it shouldn't be used to describe albums. And I would also suggest that the term track describes an audio recording, so using both haudio and track seems largely redundant here. The first haudio describes the album - which is why it is encased in a 'summary' tag. If it describes the album, why isn't it encased in the halbum element? Isn't that the most obvious place to put something that describes the album? The summary class seems completely meaningless here. What exactly would we lose by taking it out? halbum is the grouping Microformat for audio albums specifically - it can aggregate a number of haudio recordings together. halbum is the grouping of albums? I'm guessing this is a miscommunication, as I've seen no previous discussion of groups of albums. Please clarify. With the current approach it would be like this: ol class=xoxo li div class=haudio span class=fnBlack Horse The Cherry Tree/span /div /li li div class=haudio span class=fnOne Day [Live]/span /div /li /ol I think the divs here are unnecessary markup, which we should avoid as much as possible. We can apply classes to lis: ol class=xoxo li class=haudio span class=fnBlack Horse The Cherry Tree/span /li li class=haudio span class=fnOne Day [Live]/span /li /ol A track is an entry in halbum. It is not specified in the haudio schema because we haven't had enough people agree/disagree with the concept. I disagree with the concept. Any haudio element within an halbum element should be considered part of the album. I see no need for an additional concept here. The album/track discussions are in far too great a state of flux to document it on the wiki. Once we come to some sort of rough consensus, we can put something up there. I disagree. The whole point of the wiki is to allow us to quickly iterate the documents. If there's
Re: [uf-new] hAudio - audio-album and audio-podcast
On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote: On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote: The label haudio appears to be describing two distinct concepts here (1: album information, 2: individual track information), which I find confusing. That these two concepts share some properties, but that doesn't make them the same thing. I think there are two many layers of abstraction here. haudio should describe something specific, e.g. an audio recording, not a vague collection of metadata that could apply to a wide variety of things. They're actually, IMO, almost entirely the same. A classical recording is a good example -- unlike popular music, the tracks on the album are often merely segments of a larger whole, f.e. Beethoven's Fifth is comprised of four movements. All of the same information that can be applied to a track can be applied to an album or playlist. They're really just divisions of a larger whole. The only information I could see an album of playlist needing that a track wouldn't would be: # of tracks and # of discs. If that's the case, what do we gain from using separate terms for album and track? Either it's useful to distinguish between the two with labels, or it's not. If it's not, we could just embed haudio inside haudio to indicate sub-sections of audio (as suggested in audio-info-proposal). If it is a useful distinction, we should clearly identify the difference. We shouldn't use unnecessary labels. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] How many examples is enough (was: hSet survey findings and future direction)
On May 30, 2007, at 7:31 PM, Joe Andrieu wrote: I think the non-voting by most of us on this list is voting that this issue isn't worth solving/dealing with at this time. I agree. On May 30, 2007, at 8:07 PM, Manu Sporny wrote: I really agree with this -- I don't particularly think grouping is a huge problem here, and I don't think tackling this up front without a whole ton of prior art is a good idea. How much prior art do we need to prove that there is a problem here? We already have 68 examples. I'd like to know how much a whole ton amounts to... Prior art and examples are two different things. Examples tell us what kinds of *content* has been published. Prior art tells us what kinds of *semantics* have been used in that publishing. Others have pointed out some successful prior art using task-specific grouping semantics, e.g hfeed, hcalendar, and unless I've missed something we have no prior art on the other side, suggesting that generic grouping semantics actually work in practice. Even XOXO is not especially popular, and that's a bit more specific than what's proposed as hSet. We're not doing if you build it, they will come standards here; we're focusing on low-hanging fruit, with a high likelihood of adoption due to widespread publishing (e.g. contact data), well- established semantics (e.g. vCard), and compelling use-cases (e.g. create vCards from web pages). Widespread publishing, while important, is not alone enough to suggest likely adoption. Without adoption, the best standard in the world is a waste of time. That said, here's a proposal for solving the hSet problem: use RDFa [1]. That gives you all the prior art and compelling use cases of the RDF world, and no need for new semantics, nor even new parsing tools. The drawbacks are pretty much the same drawbacks people have been pointing out with the hSet proposals. [1] http://www.w3.org/TR/xhtml-rdfa-primer/ -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] XFN - Professionals Network microformat
On May 10, 2007, at 7:08 PM, Guy Fraser wrote: Heh, don't even get me started on the process :p As for media wiki, I must simply be missing some key bit of navigation - is there actually an index to all pages or a site map somewhere that lists *all* pages? The only way I could find things that weren't directly linked from some other page I could find was to use the (almost unbelievable) Random Page link?! :) http://microformats.org/wiki/Special:Allpages I've since learnt that the IRC discussions are logged but I've not yet found a way to search them. Google seems to work okay for this, e.g.: http://www.google.com/search?q=site:http://rbach.priv.at/Microformats- IRC/%20hcard Again, the process hinders this. One can stare the obvious convergent solution in the face for a great deal of time, but will have to wait until real world examples of that solution are available before they can properly get through the process rather than just being a side-note lost in time. This is a common misunderstanding, and I recently added it to the FAQ: http://microformats.org/wiki/faq#Q._What_if_I_can.27t_find_real- world_examples_of_a_standard_I.27d_like_to_propose.3F We need to find real world examples of the *problem*, not necessarily the solution. If we can't find examples of the problem, that's often a good indication that it's not a widespread problem, so not a good candidate for a widespread solution. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Test
On May 10, 2007, at 6:57 PM, Martin McEvoy wrote:
It would be nice if someone could say they get what I am trying to
do or
that it doesn't make sense so comments and criticism are welcome.
http://weborganics.co.uk/haudio
!-- this is the unique id of our collection using MusicBrainz
release ID http://musicbrainz.org/release/235b1044-03ae-4dc3-
ba57-9f30230bba22.html , in my aural style sheet I have .uid{speak:
none;} --
Aural style sheets aren't supported by most screen readers, so this
will be read aloud. More generally, if data isn't appropriate for
humans, it doesn't belong in a microformat. Microformats are for
humans first.
span class=amount title=4.994.99/span
What is the purpose of the title here? It looks redundant.
!-- Title is the title of our collection. --
span class=title
a class=url href=http://www.downloadpunk.com/?
webaction=AlbumDetailamp;albumid=13202Fifty Million People Can't
Be Wrong/a
/span
It's also the job title of our hCard, which looks like an unintended
consequence to using an established class name to communicate a new
meaning.
div class=haudio hitem
This item-collection markup looks redundant, as the exact same
relationship can be inferred from song-album markup.
span class=note
Duration: span class=duration title=447dfn class=value
end3:41/dfn/span
!-- *note* title=447 this is marked as the end of the second
track and total time elapsed since the start of our tile it gives
an idea where an episode might begin and end on a long podcast --
I don't understand this. It looks like humans are being told one
thing and machines another. Also, why is this going into the note of
the hCard? Is this hCard for the song or the musician? Songs don't
need hCards, and musicians don't need song durations in their notes.
span class=vcard
span class=contributor rolePublisher/span:
This looks wrong. The contributor should be the hCard, not the role.
That's probably enough for now.
--
Scott Reynen
MakeDataMakeSense.com
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Test
On May 11, 2007, at 12:57 PM, Martin McEvoy wrote: span class=vcard span class=contributor rolePublisher/span: This looks wrong. The contributor should be the hCard, not the role. I don't agree. we have more than one contributor to an album Artists, Publishers, Distributors, Management, p.r., songwriters, the list goes on... Those are all people and organizations with different roles. The roles themselves are not contributing. this says the contributor role is the Publisher? Not exactly. What I'm suggesting is this: span class=contributor vcard span class=rolePublisher/span: span class=fn orgFerret Music/span /span This says the contributor is an organization named Ferret Music with a role of Publisher. Your current markup says is that the contributor is the role of Publisher. Roles don't contribute; organizations (and people) contribute. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio)
On May 9, 2007, at 9:57 AM, Martin McEvoy wrote: fn is good for the artist but not their art? as you would have two fn properties in one haudio. This is a parsing issue with a solution, so it shouldn't influence our choice of markup. Specifically, a solution is for parsers to recognize the context, i.e. hCard vs. hAudio, and apply the FN to the correct context. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties)
On May 8, 2007, at 10:22 AM, Chris Griego wrote: rel-enclosure was ruled out because it's not always a download, but sometimes a way to purchase, right? What if hAudio suggested the use of rel-enclosure for downloads and rel-payment for ways to purchase? I think this is an excellent idea. In addition to re-using existing microformats, knowing whether a link is a direct download or a purchase form would allow tools to provide more useful options to users. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties)
On May 8, 2007, at 10:22 AM, Brad Hafichuk wrote: As a runner-up, source seems to be acceptable, as we're used to using src for image (and embeded) media. SOURCE is already a property in vCard [1], though it's not currently used in hCard. In vCard, it's the source of the *information* in the container, e.g. an LDAP URI, which I think is a slightly different meaning than the source of the *subject* of the container. hCard's class=url is probably closer to the intended meaning here. SOURCE: information how to find the source for the [container] URL: To specify a uniform resource locator associated with the object that the [container] refers to. [1] http://www.ietf.org/rfc/rfc2426.txt -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] An argument against 'fn' in hAudio
On May 8, 2007, at 2:20 PM, Manu Sporny wrote: Brian Suda wrote: None of this applies to hAudio - and we don't want Microformat implementors confusing how to use 'fn' in hAudio and how to use 'fn' in hCard. --- these are two very different things. This is a non-issue. hCard parsers do onething, and you can defined Media parsers to do something completely different. FN is just a semantic value not defining parsing instructions, that is up to the format. You almost had me convinced until you said this. It seems very strange to me that something that is supposed to be 'semantically equivalent' is parsed in very different ways between two Microformats. If things are semantically equivalent, why aren't they parsed in the exact same way? span class=fnSome Name/span is parsed the same in any microformat. But names of people are more complex than names of songs, so they have additional parsing rules to account for the additional markup options. That doesn't change the meaning of span class=fnSome Name/span at all. To illustrate the implications of calling two things the same thing when they are different: Here's a duck, it quacks and floats on water. Here's another duck, it whinnies and gallops on land. Ducks and horses are two different things, but we use the same term, animal, to refer to both. FN is a similarly generic term. If two things have to be parsed in different ways, how can they be semantically equivalent? The meaning is determined by the markup, not the parsing. I would have no problem with using 'fn' if it didn't have all of the parsing cruft from hCard. It doesn't. If something is parsed differently, isn't it intrinsically different? No. Every browser parsers a given HTML document differently, but the HTML document still means the same thing. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties)
On May 8, 2007, at 3:55 PM, Andy Mabbett wrote: I can foresee problems. Suppose a publisher links to a third-party site, offering an audio track as a free sample (or vice versa). Later, that latter site decides to start charging for the track - how would the publisher know that their site is no longer correct? They wouldn't without re-checking the links. But the same is true of every link on the web. For example, I could link to a site about salmon with the text this is about fish and then the linked content can change to something about whales and I would look like I don't realize that whales aren't fish. I think the truthfulness of assertions (e.g. this is an audio file to download) over time is irrelevant to determining the best markup for making such assertions. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] First draft of hAudio proposal
On May 2, 2007, at 6:05 AM, David Janes wrote: While (very) sympathetic to Andy's point about this, we're getting to the danger point of semantically forking rel-tag. I suspect you will get strong pushback on this one, because the current approach is to use rel-tag for this, and if that needs to be fixed, it needs to be fixed and the problem should be addressed there. I think we may be extending the semantics of rel-tag beyond usefulness here. I don't think every open-ended list of grouping terms should be considered tags. Another similar example is hCard departments. Should those be using rel-tag too? I think there's actually a subtle semantic difference between tags and other grouping terms, though I'm not sure exactly what it is. Regardless, this is apparently not a point of consensus yet, and I'd suggest we proceed without genre for now, intending to add it later when rough consensus is reached, and still have a useful microformat before then. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] First attempt at hAudio proposal
On May 2, 2007, at 3:28 PM, Manu Sporny wrote: http://microformats.org/discuss/mail/microformats-new/2007-March/ 28.html http://microformats.org/discuss/mail/microformats-new/2007-April/ 96.html Can this be solved by extending an existing format? Maybe... but every attempt at doing so has been shot down to date. Read the previous threads. Please propose a solution if you think differently. The last message in those threads begins with hAtom as a transport for music-downloads makes loads of sense to me. I don't see where hAtom was shot down. Here's my proposal: work-title - hatom entry-title contributor - hatom author published-date - hatom published sample - rel-enclosure in hatom entry-summary acquire - rel-enclosure in hatom entry-content image-summary - hcard photo in hatom entry-summary genre - hcard category length - new class=length, or defer in first draft price - new class=price, or defer in first draft -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] First draft of hAudio proposal
On May 2, 2007, at 5:14 PM, Manu Sporny wrote: Note that the song should be grouped with the podcast AND the album. That understanding is clear from viewing the page: http://www.coverville.com/archives/2007/04/coverville_313.html The podcast can already use hAtom. Here's how we could do grouping on each individual album/song (with generic class names that are irrelevant here): tr class=album td class=track-titleHere Comes Your Man/td td class=artistKate Rogers/td tda href=http://www.amazon.com/gp/redirect.html% 3FASIN=B0007YMUS4%26tag=askbriancom%26lcode=xm2%26cID=2025% 26ccmID=165953%26location=/o/ASIN/B0007YMUS4% 253FSubscriptionId=02ZH6J1W0649DTNS6002 target=_blank class=album- titleSeconds/a/td td class=authorPixies/td /tr Again, note that there isn't clear hierarchy - songs belong to the podcast, shows and albums listed on the page. One song can be a part of three groups: http://www.mutantpop.net/radioclash/archives/2007/03/24/rc-113/ I'm not sure what the show is here outside the podcast (which can use hAtom). The album grouping could be marked up like so: div class=post album h2 id=post-531a href=http://www.mutantpop.net/radioclash/ archives/2007/03/24/rc-113/ rel=bookmark title=Permanent Link: Radio Clash 113: From Brussels With Love TWI 007 / Cuddle the Present mk2 class=album-titleRadio Clash 113: From Brussels With Love TWI 007 / Cuddle the Present mk2/a/h2 div class=entrytext [...] lispan class=artistKerrier District (aka Luke Vibert)/span - span class=track-titleDisco Nasty/span/li Note that descriptions on the page can have many different groupings of the content on the page. In this example, the band is related to or grouped with television shows (which are groups in and of themselves), bands are also groups with other bands: http://www.bitmunk.com/view/media/6068744 This is a page about a single album, and the same kind of album-track markup above would work. The TV shows don't specify which songs were played on which shows, so even if we considered that within scope here (which I think is a stretch) we couldn't mark up the show-track grouping at all, because it's not published. This one is especially important. Note that the album is described first, then the top songs as an ordered list, then what the listeners also bought, and then finally the songs that are related to the album mentioned at the very beginning of the page. http://www.misrolas.com/downloadmusic/album.php?id=1316 Each of those tracks from other albums and each of those albums could be microformatted on their own album pages, where more complete info is available. With only the tracks in the relevant album remaining, the same album-track grouping above would work. Does that help clarify the difference between a sparse grouping and a non-sparse grouping? Yes. I think what makes these all sparse is secondary information that can be left alone or microformatted on more relevant pages while we microformat enough useful information to address the audio-info problem statement. We shouldn't feel compelled to microformat everything. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespacing in hAudio (Was: First draft of hAudio proposal)
On May 1, 2007, at 1:20 PM, James Craig wrote: I'm curious why class namespacing is vehemently opposed in other Microformats, but proposed in hAudio. Namespacing was opposed in an audio microformat as well. That apparently didn't prevent it from being proposed anyway, but that shouldn't be taken as an indication of consensus support. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency Proposal (and Measurements)
On Apr 26, 2007, at 11:54 AM, Emil Thies wrote: To come back to microformats, what If I have an Idea (like for measurements) and I did not find a real world example I don't understand why we couldn't find real world examples of measurements. There are measurements published all over the web. If we're treating prices as measurements, it's difficult to find a web page that isn't an example of monetary measurements. Do you mean you can't find examples of the specific markup you're proposing? We don't need examples of that. We just need examples of the problem, not the solution. If we had examples of the solution, we'd be done already. Do you get my intension? I'm not sure. So what do you think about the approach to solve this by creating a measurement-design-pattern and to use this for creating the currency microformat? I don't know. I think it looks fine as an abstract idea, but how would it work in real web pages? We need to look at a lot of real web pages to evaluate whether something will work on the real web. It can be a lot of tedious work collecting and analyzing these examples, but I don't see any viable alternative. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] collection-design-pattern proposal
On Apr 25, 2007, at 10:47 AM, Manu Sporny wrote: If somebody has a proposal for doing so, please do speak up as Danny and several others have outlined this as an undesirable effect of the proposed methods thus far. I would be happy to make a proposal after we've documented and analyzed more real world examples. Woops! I didn't mean proposal in the official Microformat sense. I meant proposal in the suggest something that works for this very specific problem I outline din the paragraph sense. I don't personally care about any official Microformat sense. You're asking for something that works without the constraints of actual web pages. You couldn't possibly be working within those constraints before we've analyzed actual web pages. And I'm only interested in working within the constraints of actual web pages. I'm not interested in those constraints because that's what the microformats process says; I'm interested in the microformats process because I'm interested in those constraints. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformat for Music Downloads
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 a 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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Separating File Content from File Format
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: div div img src=http://www.comedycentral.com/images/shows/tds/videos/ wilmore/12044_wilmore_m1.jpg/ p3:32/p /div h1Frog Princess/h1 pLarry Wilmore explains that when you wish upon a star, it makes a difference who you are./p ul lia href=http://a1136.c.akamai.net/n/1136/9950/v001/ comedystor.download.akamai.com/9951/_!/com/dailyshow/wilmore/ wilmore_12044_480.flv? __gda__=1175813754_e1a844fd4dfd872bf13b8bc96b430a04Download Low Quality Flash Video File/a/li lia href=http://a1136.c.akamai.net/n/1136/9950/v001/ comedystor.download.akamai.com/9951/_!/com/dailyshow/wilmore/ wilmore_12044_480.flv? __gda__=1175813224_a83ec303f5e664e4f66c006e4deba362Download High Quality Flash Video File/a/li /ul /div 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
Re: [uf-new] Separating File Content from File Format
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformat for Music Downloads
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Proposal: wishlist microformat
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 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformat for Music Downloads
On Mar 14, 2007, at 7:46 PM, Andy Mabbett wrote: I personally don't see a lot of albums in the examples. Absence of evidence is not evidence of absence. Right, the microformat process is iterative, so we don't need to worry about any sort of finality. I was just sharing my current thoughts, in the interest of *avoiding* assumptions about what will be included, not of making such assumptions. I expect my current thoughts will change as I see more examples of the problem we're trying to solve. Speaking of which, it would probably help us focus if we had that problem formally stated in the wiki. I've added Marian's initial problem statement to the wiki: On Mar 7, 2007, at 1:44 AM, Marian Steinbach wrote: Provide users with the correct metadata about the audio files so users know who it's from and whether or not they want the file. http://microformats.org/wiki/music-examples#The_Problem -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
