[uf-new] JSON-LD - Universal Linked Data markup for Web Services
Just in case there are people in this community that haven't seen this yet: On May 29th 2010, Manu Sporny tweeted: Just published JSON-LD: http://rdfa.digitalbazaar.com/specs/source/json-ld/ Universal markup of #rdfa #microdata and #microformats via lightweight JSON. #html5 #json #lod - Abstract Developers that embed structured data in their Web pages can choose among a number of languages such as RDFa, Microformats and Microdata. Each of these structured data languages, while incompatible at the syntax level, can be easily mapped to RDF. JSON has proven to be a highly useful object serialization and messaging replacement for SOAP. In an attempt to harmonize the representation of Link Data in JSON, this specification outlines a common JSON representation format for Linked Data that can be used to represent objects specified via RDFa, Microformats and Microdata. -- There is currently some discussion going on in the RDFa Community on this markup mechanism (start of thread): http://lists.w3.org/Archives/Public/public-rdfa/2010May/0018.html A great amount of effort was made to ensure that the markup mechanism was compatible with Microformats. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP http://blog.digitalbazaar.com/2010/05/06/bitmunk-3-2-2/2/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: One issue per thread
Myers, Jay wrote: Would it be a reasonable request for a new discussion list for people who would like to address issues in this way, with the condition that they summarize discussions on the wiki? I thought that was what this mailing list was for? At least, that's how we were operating during hAudio development. Here's another idea (that would take months to implement), just thinking out loud: Problem: We are not capturing all of the conversations surrounding each Microformats spec in a way that: - Can be automatically associated with a specification on the wiki. - Can be searched quickly for answers. - Works with different workflows (IRC+wiki) and (e-mail+wiki) What would be really great is a mechanism where we could do sub-subscriptions, so that you could create a set of filters for things I am not interested in. So, you would subscribe to microformats-new and then provide filters for things that you are not interested in (hCard, hAudio, etc.) It would give us finer-grain control over what we're exposed to as mailing list participants. Tying this into IRC so that we could choose to get a daily log of IRC conversations related to each topic area would be great as well. That way, we get daily/weekly updates from IRC that have a good subscriber-specific signal-to-noise ratio. Perhaps if somebody could hack together an IRC-like mechanism (using HTML5's canvas feature) and tie it into the microformats.org wiki to provide a synchronous communication mechanism with logging support. The logs for all hAudio channels (IRC and mailing list) would be tied to the hAudio wiki page. People could filter out each sub-topic as they pleased and these discussions would be a part of the living documentation for the spec. All conversations are auto-sorted into their respective logging area on the wiki. The only problem with this approach is that it would take a very long time to develop/implement. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: One issue per thread
Tantek Çelik wrote: On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny mspo...@digitalbazaar.com wrote: Could you please explain why it's better to discourage per-issue threads on the mailing list and instead direct people to the wiki? Why are we discouraging one form of recorded communication over another? I have written up a page that explains some of the reasons behind the microformats community's preference for using the wiki instead of email: http://microformats.org/wiki/wiki-better-than-email I've noted various issues on the page. Most notably that the community shouldn't be forcing a particular workflow on community members. Some of us can't be distracted by IRC at all times and the people we need to talk to aren't always on IRC anyway. There's much more on the wiki page that I've commented on, so I'll leave it at that, I guess. On Sun, Feb 22, 2009 at 6:50 PM, Manu Sporny mspo...@digitalbazaar.com wrote: Tantek Celik wrote: Please follow-up on the wiki and also one email announcing a batch of new issues is sufficient. Let's try to keep emails to a minimum for notification only, and capture discussion/iteration on the wiki. The reason I put each of these in a separate e-mail is to separate issues out into manage-able threads of discussion. I do admit that it's a personal preference, but threaded discussion seems to be a fairly accepted method of working through spec issues. Email-centric threaded discussion is fairly accepted method in many other standards communities/organizations (W3C, IETF). Per http://microformats.org/wiki/wiki-better-than-email#tradition , this has been different in the microformats community from the start of microformats, and deliberately so. Tradition, in and of itself, is not a valid reason for doing something a certain way. I don't think it should be listed as a reason - distill out the reasoning that makes the tradition an acceptable practice, please. More on this on the wiki page. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Issue HP3 - BUY vs. PAYMENT in hProduct
Paul Lee (이기수) wrote: From the payment page: quote RelPayment is a microformat for making exchanges of support (be it financial or otherwise) possible. By adding rel=payment to a hyperlink a page indicates that the destination of that hyperlink provides a way to show or give support for the current page. For example to give financial support to the owner of the current page. One of the goals with this microformat is to give content aggregators such as RSS readers a way to extract these support links and give them special attention (such as displaying a standard button along with the content). /quote First, this seems like a simple exercise for blogs, etc.; but the transaction process for shopping sites is typically considerably more complex. Usually, the actual payment URI is toward the end of the cart checkout process, the entry to which buy is intended to direct to the beginning of. Hrm, I tend to disagree with your reading of payment. We use payment in the same way that you intend to use it in hAudio - to point to a URL that starts the purchase process. Second, there is the potential for confusion when using payment, since payment in the shopping space often refers to payment methods, e.g., credit card, check, etc. I think payment-method refers to the various payment methods, not payment. The argument for buy is a difficult one to make because there already exists something for the purpose that you describe in Microformats - payment. hAudio defines payment like so: http://microformats.org/wiki/haudio#Purchase_.28Payment.29 specifically, The URI MUST point to the beginning of a purchase process for the hAudio. I don't see why you can't re-use that term instead of minting a new one. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Issue HP7 - Abundance of vocabulary terms in hProduct
Paul Lee (이기수) wrote: The examples aren't necessarily an accurate reflection of how frequently attributes/data is used by retailers. In practice, model/mpn is used much more frequently than dimensions, both for retailer websites as well as retailer submissions to search and shopping engines. I would expect many people on this list would have an issue if I made the following statement: The hAudio examples aren't necessarily an accurate reflection of how frequently the ISRC is used by retailers. In practice, ISRC is used quite frequently and should be in the vocabulary. The reason uFers should have an issue with this statement is because I'm asserting something that isn't backed up by the examples that have been gathered for hAudio - there is no hard data behind it. In the Microformats community, if you can't show hard usage data for a vocabulary term, it should not be a part of the vocabulary. If you don't have enough data to prove that model/mpn is used more than 15% of the time, you are going to have a very hard time convincing this group that it belongs in a vocabulary. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct
Paul Lee (이기수) wrote: IIUC, part of the reason why hproduct has been under discussion for quite awhile is b/c of the debate between p-v vs. more defined attributes. p-v is quite helpful b/c the attributes users care about change over time. Take cameras, for instance. Did anyone care about megapixels 10 years ago? etc. Don't try to future-proof your vocabulary - if there isn't enough data to back up a vocabulary term, it doesn't belong in a Microformat. One of the principles that this whole community is built around is proving that vocabulary term usage in-the-wild has reached a critical mass and thus needs to be standardized. The nice thing about vocabulary development is that it is a continuous process... if you miss an important vocabulary term now, you can always put it in later. It's much more costly to remove vocabulary terms from a vocabulary if they are not used. For example, if printable becomes a reality for a large range of plastic products (due to the proliferation of high-quality, low-cost 3D printers), then the term can be added to the product vocabulary when that happens. Not before. I understand your argument for p-v, however, if every Microformat used it we would start to have a high number of collisions when interleaving Microformats on a page. There are two arguments against using p-v: 1. It is an attempt to future-proof a vocabulary that isn't based on any hard data. 2. It increases the likely-hood of vocabulary term collisions. To put it another way - if we are going to allow 'p-v', hAudio will have support for it immediately... and then people will have a nasty time interleaving hAudio+hProduct. If you'd like an example of this issue, I'd be happy to give one. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
One issue per thread (was: Re: [uf-new] hProduct issues HP1-HP7)
Tantek Celik wrote: Please follow-up on the wiki and also one email announcing a batch of new issues is sufficient. Let's try to keep emails to a minimum for notification only, and capture discussion/iteration on the wiki. The reason I put each of these in a separate e-mail is to separate issues out into manage-able threads of discussion. I do admit that it's a personal preference, but threaded discussion seems to be a fairly accepted method of working through spec issues. I realize that your preference is to edit the wiki and not respond via e-mail, but it's not clear to me how this is a better method of refining these specs, especially when we're just discussing things. I see that the mailing list rules have been updated as a result of my posts: http://microformats.org/wiki/mailing-lists#Avoid_sending_one_message_per_issue_raised Could you please explain why it's better to discourage per-issue threads on the mailing list and instead direct people to the wiki? Why are we discouraging one form of recorded communication over another? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. twitter: http://twitter.com/manusporny ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Issue HP2 - FN vs. N use in hProduct
http://microformats.org/wiki/hproduct-issues#HP2_-_FN_should_be_used_instead_of_N_for_product_title Why does hProduct use N instead of FN for the title of a product? I thought that the term that this community has settled on, after an excruciating amount of debate, was FN? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Issue HP3 - BUY vs. PAYMENT in hProduct
http://microformats.org/wiki/hproduct-issues#HP3_-_BUY_duplicates_functionality_of_PAYMENT_from_hAudio hProduct seems to create a new term called BUY instead of re-using PAYMENT. What's the reasoning behind creating the new term vs. using the one that has already been invented? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Issue HP7 - Abundance of vocabulary terms in hProduct
http://microformats.org/wiki/hproduct-issues#HP7_-_Lots_of_vocabulary_terms.2C_does_the_data_really_back_this_up.3F There are currently 15 vocabulary terms in hProduct, but some of the terms don't seem to be backed up in the hProduct analysis[1]. For example, MODEL shows up in 15% of the examples, but made it into the vocabulary. However, DIMENSIONS shows up in 51% of the examples, COLOR in 31% of the examples, but neither made it into the vocabulary. Why did that happen? Also - do we really think that VERSION is a good idea? Where on the page are we going to use this? Are we suggesting that page authors should version each of the hProduct instances? Does anybody actually use this in practice? -- manu [1]http://microformats.org/wiki/hproduct-examples#Analysis_of_Product.2FCommerce_Sites -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Issue HP6 - P-V seems like a catch-all for hProduct
http://microformats.org/wiki/hproduct-issues#HP6_-_P-V_seems_like_a_catch-all_for_hProduct hProduct currently allows the author to use the P-V pattern for anything that doesn't fit neatly into hProduct. While it is true that this is a nice way to expand hProduct and see where future versions of hProduct might need to be expanded, there is a danger that over-use of the P-V pattern will result in weird issues between future Microformats. For example, if hProduct lists a number of P-Vs and another Microformat starts using P-V heavily, there will be clashes between the overlapping Microformats. These clashes will result in the wrong P-Vs being assigned to the wrong object. It also seems a bit sloppy - using P-V may be a clear sign that the problem being solved isn't small enough, or that you're attempting to boil the oceans in a clever way. Anybody else have some thoughts about the use or abuse of P-V in Microformats? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Issue HP4 - Multiple formats for PRICE in hProduct
http://microformats.org/wiki/hproduct-issues#HP4_-_Are_all_of_the_formats_for_PRICE_in_hProduct_allowed The hProduct specification lists the following formats as allowable for PRICE: price. optional. floating point number. can be further refined by type (msrp, regular, sale, clearance), can use currency format. So, we can do the following in PRICE: Floating point number: -- span class=price3.40/span Currency format: span class=price abbr class=currency title=GBP£/abbr span class=amount4.99/span /span Further refined by type: $span class=price3.40 span class=typeMSRP/span/span Are all of these good ideas as an extension to PRICE? We don't allow the type to be refined in other uFs do we? Is the price specified as a regular floating point number useful without a currency? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Issue HP5 - SHIPPING term in hProduct is vague
http://microformats.org/wiki/hproduct-issues#HP5_-_The_format_for_the_contents_of_SHIPPING_are_vague The definition of shipping is: shipping:: the class name shipping MAY define the method, timeframe, and cost associated with shipping the product. MUST be singular. I realize that this is all important information, but why mash method, timeframe AND cost into one attribute? It would be nice if an application could use each of those pieces of information out without having to resort to some sort of natural language processing. For example, why don't we have: shipping-method, shipping-timeframe, and shipping-price? or something like this: div class=shipping div class=price abbr class=currency title=USD$/abbr span class=amount3.95/span /div span class=methodUPS Ground/span, expect span class=timeframe4-6 days/span for delivery. /div -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Scaling Past 100,000 Concurrent Web Service Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Blog post on HTML5, Microformats and RDFa
Mark Birbeck (the lead technical mind behind RDFa) has written an interesting piece about HTML5, Microformats and RDFa. In the piece, he explores distributed semantics extension (RDFa/XHTML2) vs. centralized semantics extension (uF/HTML5). It's an interesting post because it outlines the two philosophies at play and how they're affecting the next-generation of web semantics. http://webbackplane.com/mark-birbeck/blog/2009/01/rdfa-means-extensibility No surprises in his conclusion (he thinks RDFa is the way forward)... worth a read, even for the die-hard uFers, as several interesting points are made along the way. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Website Launch http://blog.digitalbazaar.com/2009/01/16/bitmunk-3-1-website-launch ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat. You continue to contradict yourself, which is why we're having such a hard time with your argumentation, Martin. Your statement above makes no sense. Let's break it down and use some real numbers to see why: Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, We'll call this Statement A. If we were to hold this true, then we would be left with these properties for hAudio. We would pick only the properties that were used in at least 80% of all sites: # album artist: 95.12% # track title: 90.24% # album title: 87.80% # album tracks: 80.49% then you go on to state this: Martin McEvoy wrote: this will result in the top 20% of all discovered properties making their way into the final Microformat. Let's call this Statement B. If we were to hold this true, then out of all discovered properties, of which there are 163 properties[1], we would be left with the top 32 properties: 20% of 163 = 32.6 More specifically, we would be left with these properties for hAudio: album artist : 95.12% track title: 90.24% album title: 87.80% album tracks : 80.49% album release date : 73.17% album cover image : 73.17% track number : 70.73% album label: 68.29% track sample : 68.29% track web-based purchase : 60.98% album web-based purchase : 60.98% album genre: 58.54% track artist : 56.10% track length : 51.22% track price: 51.22% album price: 48.78% description: 39.02% album format : 26.83% track release date : 26.83% album sample : 24.39% album length : 21.95% track album: 17.07% track genre: 14.63% album physical-based purchase : 14.63% track label: 14.63% track format : 14.63% album bitrate : 12.20% album number of tracks : 12.20% album reviews : 12.20% track rating : 9.76% track album title : 9.76% album license : 7.32% Quite clearly, Statement A and Statement B say two different things. However, you state that because of Statement A, Statement B follows - even though both statements are talking about the same thing and they contradict each other. You have to pick either Statement A OR Statement B - not both. We're stating that Statement B is the correct understanding of the Pareto Principle as applied to hAudio. You are saying that both of them are the correct understanding - again, a contradiction. Just to be clear, here's what you said: Martin McEvoy wrote: In Microformats this means that if a propery is used more than 80% of the time then it should be included in the format, this will result in the top 20% of all discovered properties making their way into the final Microformat. It is because you keep repeating statements like this that I don't think there is a good reason to remove category, description, sample, payment, or price from hAudio. The removal of all of these properties is based on the statement you have made above - which is a logical fallacy. -- manu [1]http://microformats.org/wiki/audio-info-services-ufa ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 1.0 Draft Release
Tantek Celik wrote: Additionally: in general I agree with the methodology of simplifying/reducing the schema and property set - hence the start as simple as possible principle as documented: In general, I agree with simplifying/reducing the schema and property set as long as it still addresses the problem shown via the examples. However, we should be careful not to over-simplify the problem. We did start with a much smaller set of terms for hAudio and grew into what we have now because of the audio-info-examples[1]. The changes that are currently being proposed ignore a great deal of the examples that were gathered. It over-simplifies the problem due to a mis-understanding of what the Pareto principle means. The audio-info-examples show that both individual audio recordings and collections of audio recordings are prevalent in the sites that were analyzed. Furthermore, the community has gone to great lengths to solve the single recording/multiple recording issues and has created something that seems to work for most of the audio-info-examples. The strongest case for removing the hard work that this community has done is based off of a possible mis-understanding of the Pareto principle (80-20). -- manu [1]http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio/Audio RDF clarification (possible admin moderation request)
Attached is a personal e-mail that I received today regarding my intentions towards hAudio and Audio RDF. I will be responding publicly to what I perceive as an attack on my efforts surrounding hAudio, Audio RDF, Microformats and RDFa. I am hesitant to make this a public issue as I don't want to waste anybody's time, but also do not want any sort of mis-information to be spread or assumptions made about my intentions with regard to hAudio, Audio RDF, the Microformats community or RDFa. This is a way of documenting this issue publicly, so that there is no question with regard to insinuations of non-transparency. I feel that I must respond to these allegations, even though I deem them to have no merit, to prevent people from getting the wrong impression. This conversation started on the RDFa mailing list: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Sep/0037.html Attached is a private e-mail I received a little over an three hours ago from Martin McEvoy. I'm surprised as it is out of character for him to be this aggressive, but I certainly don't want this to get out of hand. I'll publicly respond to his comments, as he has asked me to do, in case anybody else has been under the same mistaken set of impressions. -- manu -- Subject: Re: RDFa and Microformats From: Martin McEvoy [EMAIL PROTECTED] Date: Mon, 15 Sep 2008 22:19:47 +0100 To: Manu Sporny [EMAIL PROTECTED] This is off list Manu Martin McEvoy wrote: Manu Sporny wrote: Martin McEvoy wrote: Talking of hacks why is this NOT a hack : http://wiki.digitalbazaar.com/en/HAudio_RDFa? it looks like a direct rip from the Microformats wiki, That's because it started out as a direct rip from the Microformats wiki it still is - the fact that it is so close to hAudio was deliberate. The intention was to create a cross-community vocabulary that would work for people jumping between RDFa and Microformats. what people? hAudio is not yet even a draft proposal, and all these Publisher were Jumping around between vocabularies, that's interesting show me where? The outcome of that research was this: By the W3C, the Microformats Community...? http://purl.org/media/audio The Audio RDF Vocabulary above has a clean/direct mapping to/from Microformats hAudio. Yo may be wandering about all the retaliation about audio rdfa Manu when you Microformats New mailing list with hAudio RDFa you received little support for your endeavour, in fact it was explicitly stated that: --- this is one of the things that microformats wants to prevent... http://microformats.org/discuss/mail/microformats-new/2007-July/000716.html basically because it causes a drift in semantics. you received no feedback from the list because we didn't want you to do it. you read Brian's email right? it was an incidental concern. It goes a little further than that, basically Manu You ripped the hAudio Microformat against the wishes of the Microformats Community and thus seriously damaged the haudio process in fact you almost killed it dead. if I could have stopped you I would. lets get hAudio out the door first eh! I request that you refrain from Editing the hAudio wiki further until I can be sure you are not serving your own needs. I cant believe you became an invited expert over your efforts. how did you deserve that. I will be adding Myself as Editor on the Version 1.0 format, because I don't have some other agenda other than completing haudio. Manu If you Ignore this email like you seem to conveniently do, I will post this email to the list because I think you will be ignoring me and I really would like some answers this time publicly or privately . Best Wishes Martin McEvoy ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request)
Martin McEvoy wrote: Yo may be wandering about all the retaliation about audio rdfa Manu when you Microformats New mailing list with hAudio RDFa you received little support for your endeavour, in fact it was explicitly stated that: --- this is one of the things that microformats wants to prevent... http://microformats.org/discuss/mail/microformats-new/2007-July/000716.html basically because it causes a drift in semantics. you received no feedback from the list because we didn't want you to do it. you read Brian's email right? it was an incidental concern. The reason the hAudio RDFa effort was started was because a number of us were concerned about what would happen if folks from this community wanted to do hAudio markup using RDFa, or vice versa. We wanted there to be nearly parallel ways of marking up semantics about audio in both RDFa and Microformats. We wanted there to be a clear mapping between the two. That is of secondary importance, however. I'm disturbed by what you are implying - that research projects must get the approval of this community before proceeding. I don't think that anybody in this community believes that is the best way to proceed - it would lead to a chilling effect on semantics research if one had to get approval from the Microformats community before using the basic work that all of us have done here. Do you think that scientists should be required to get approval before doing research on web semantics? That seems to be what you are implying with the statements you have made above. It goes a little further than that, basically Manu You ripped the hAudio Microformat against the wishes of the Microformats Community I certainly take issue with this - it sounds as if you're accusing me of plagiarism or something equally evil. We have gone out of our way to let everyone know that hAudio RDFa and Audio RDF was based[1][2][3] upon work done on the Microformats community (check the diff-logs and date/time stamps in the wiki - we have stated this from the beginning). In addition, it is clearly stated in the patents/copyright section of each vocabulary document that Digital Bazaar has authored[4][5][6][7]: This document and all ideas and patentable material outlined in the document are hereby placed into the public domain. It is our intent that all future additions, modifications and contributions will be placed into the public domain as well. We have released our copyright and control of this vocabulary for the good of the community and the betterment of the world in the name of open standards. We kindly ask that proper credit is given when using the vocabulary. A line like the following is sufficient: The Media/Audio/Video/Commerce RDF Vocabulary is an initiative lead by Digital Bazaar, Inc. and collaborated on by a number of people from the Web at large, the World Wide Web Consortium, the RDFa community and the Microformats community. We have released every vocabulary that we have into the public domain. Microformats has done the same with hAudio. I fail to see how one community is ripping the other one off? The whole purpose we have placed things into the public domain is to ensure that the work we do here and at Digital Bazaar can be re-used in other places without fear of copyright restrictions. and thus seriously damaged the haudio process in fact you almost killed it dead. if I could have stopped you I would. lets get hAudio out the door first eh! Getting hAudio to Draft and beyond has always been a high priority and will continue to be one. hAudio and Audio RDF are pragmatic approaches to the problem of audio identification. My hope is that they will be used by the general public to discover new artists via semantic web techniques. I don't believe that we should bet on one approach or one technology. I vehemently reject the notion that I am acting against its best interests or against the best interests of the 60,000+ artists whose music we distribute. In addition - my entire family is composed of artists (sculptors, painters, architects, writers, musicians, etc.). I grew up watching many artists languish in obscurity while those with better means (money) could market their creations with relative ease. I view the web, and web semantics as a great equalizer of cultural control. I have a deep personal commitment to improve the lives of artists and creators of all walks of life - I founded Digital Bazaar to stand behind that goal and it is what I have dedicated a very large part of my life to achieving. Not only for myself, but for the hundreds of thousands of people that want to make a living creating and bettering our global culture. Why would I want to stop that? It goes against everything that we're trying to achieve. I request that you refrain from Editing the hAudio wiki further until I can be sure you are not serving your own needs. Elaborate on what personal needs that I am serving. If you are going to accuse me of doing something
Re: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request)
Ben Ward wrote: Obviously the admins are open to email from anyone about any issue, but I for one would prefer that as much of this complaint is resolved in public, please. I would prefer that this complaint is resolved publicly as well. I want to know if the alleged process violations can be handled within the development process itself It would be helpful if Martin could list the process violations that he believes have been made. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: [hAudio issue] D2: hAudio Title was Overloading fn
Martin McEvoy wrote: I would like to propose that hAudio Issue D2:hAudio Title was Overloading fn[1] should be now marked as resolved. +1 to marking it as resolved. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
Martin McEvoy wrote: Resoulution 4: Change |title| back to |fn| . http://microformats.org/wiki/haudio-issues#D2:_2008-01-10_hAudio_Title_was_Overloading_.22fn.22. Please add your support to the wiki with a +1 or -1 +1 for changing hAudio TITLE back to FN. This assumes that we're going to deal with the mfo/hItem/scoping issue - which I hope we do soon. Just want to make it clear that I'm voting for this not because I believe it is the best solution, but because I believe that we've exhausted the options that do/don't work for those on this list and are having to compromise on this issue in order to get hAudio to Draft stage. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
Scott Reynen wrote: 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. Perhaps, and this would be the easiest way forward. However, if we move hAudio forward without fixing this issue, there will be less desire to fix the 'mfo' issue. The same thing that has happened every time this has happened will happen again: People won't have a desire to work on mfo because it's not blocking progress on anything. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Closing hAudio issues D1, D3 and D4
Martin McEvoy wrote: I will be closing issues D1, D3, and D4 today the solutions are outlined below. +1 to all of your proposed solutions, Martin. Great work on closing these last remaining issues! :) -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
Martin McEvoy wrote: - Resoulution 2: Use HTITLE [...] hTitle can then be reused in any microformat that needs a title property. hTitle has been given a root class name as it is intended to be used in conjunction with any other root class microformat and mirrors the association semantics expressed by hfeed = hentry in hAtom [...] A Proposal was made in an email on Aug 13th 2008 by Myself. http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html - +1 to your htitle proposal, Martin. I believe it is superior to all of the other proposals related to solving this problem, for the following reasons: - It can be re-used across all Microformats requiring a property to mark up future title information (hVideo, hBook, etc.). - It doesn't use a pseudo-namespace, like audio-title does. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D2 title
Tantek Celik wrote:
I agree with you that this is a larger issue impacting existing
and new microformats, however, trying to come up with new names
for the same meaning is not the answer, and will quickly fall apart.
*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.
1. any class name starting with an h should be treated as a
root microformat which introduces a new scope
So, now we're looking into ditching Microformats mostly scope-less
design? I'm fine with that, but why now - I pointed this issue out a
year ago and there seemed to be push-back on adding more scope to
Microformats parsing algorithm:
http://microformats.org/discuss/mail/microformats-new/2007-June/000582.html
I'll certainly support any effort to add more parsing scope to uFs... we
should have done this a year ago.
2. introduce a root microformat classname like hroot or hitem which
introduces a new scope and require its use in addition to any new
microformat root class name (eg class=hitem haudio) this is essentially
the mfo solution but with a friendlier generic root name. Feel free to
brainstorm additional friendly generic root names.
I believe that this approach would confuse the same people that find
namespaces scary - they won't understand why they need to provide
hroot beside their haudio. If we're going to do scoping, we should:
1. Depend on the structure of the HTML document to provide that scope -
web developers understand that elements can go inside other elements...
it's an easy concept to grok.
2. Re-use a solution that already exists instead of rolling our own for
this community, if possible.
3. same as 2 except don't introduce any other root microformat-specific
class names, and use some other mechanism to specify what type/kind
of microformat the item is. E.g. all new microformats would start
with class=hitem and then we come up with another way of typing them.
We could re-use RDFa's @typeof attribute - it does exactly that and is
defined in HTML4.01, XHTML1.1 and XHTML2.
We're working on extending RDFa to support just this very use case - it
would be a perfect fit.
4 ... ? Additional suggestions?
I suggest that we re-use RDFa's scoping rules since they have already
solved this problem for us. This dove-tails into my suggestion late last
week of working with the RDFa community to solve some of these
long-standing problems since both communities have much to gain from
working together:
http://microformats.org/discuss/mail/microformats-discuss/2008-August/012432.html
I'll post more when we have a more solid proposal together, but what we
have so far would solve the scoping issue for Microformats - opening the
possibility of re-using FN for hAudio. Here's how the markup would look
in practice:
html
body prefix=http://microformats.org/vocab#;
...
div typeof=haudio
span rel=contributor
div typeof=hcard
span property=fnMartin Luther King, Jr./span
/div
/span
span property=fnI Have a Dream/span, a
span property=typespeech/span by
/div
This would generate this Microformat object (JSON-ish encoding):
(haudio)
{
contributor(hcard) :
{
fn : Martin Luther King, Jr.
},
fn : I Have a Dream,
type : speech
}
We have the parsing rules for this if anybody is interested - it
definitely works, and we'd be happy to undertake a standardization push
for this via the W3C if this community was interested in doing so...
-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D5: 2008-01-10 there is no way of linking to an interim page
Martin McEvoy wrote: [...] div class=Title1a class=Album href=/music/album/-/Lost%20Angel/Psychosomatic/?id=7961Psychosomatic/a/div [...] The above is a link to another page where audio may be listened to or downloaded. -1 to class=url rel=bookmark would be a more POSH way of marking up that relationship: http://www.w3.org/TR/REC-html40/types.html#type-links rel=help is also an option - we should re-use pre-existing HTML LinkTypes where appropriate. However, I believe that there is also a problem with examples. Most of the hAudio examples deal with the final location of the hAudio data and rarely point elsewhere. We'd need more examples before adding this to hAudio (per the Microformats process). I'm not arguing that it's not useful, just arguing that we don't have enough examples to support adding that feature to hAudio right now. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] rel=license scoping and hAudio
Toby A Inkster wrote: With rel-license scoping has potentially major legal ramifications. Essentially it means that any rel=license link found needs to be manually checked to determine exactly what the licence applies to. And if one needs to manually inspect a page to determine its licence, then rel=license is adding no value. This is a very good point, Toby. It is an argument against using rel=license in the current version of hAudio since the semantics do not match up with what is intended. Namely: By adding rel=license to a hyperlink, a page indicates that the destination of that hyperlink is a license for the current page.[1] However, to give a counter-point, Creative Commons notes that rel=license should be used to specify what music a particular work is licensed under: http://creativecommons.org/license/music Their approach has the musical work(s) described on a page as the only content on that page, so rel=license makes a little more sense in their use case. This would also make sense in the hAudio case, but has a very high probability of abuse. The XHTML vocabulary also defines rel=license as applying to the current document and not to resources in the document. http://www.w3.org/1999/xhtml/vocab#license Keep in mind that this is a non-issue in RDFa since you always have a subject, which is why it is supported in Audio RDFa[2]. If we do want to specify the license for Microformatted objects in the future, we should pick something else, like rel=hlicense to specify the relationship between a Microformat object and it's license. However, hAudio does not have enough examples of specifying the license to warrant this addition to the Microformat. -- manu [1] http://microformats.org/wiki/rel-license#Abstract [2] http://purl.org/media/audio ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] rel=license scoping and hAudio
Tantek Celik wrote: Manu Sporny wrote: If we do want to specify the license for Microformatted objects in th future, we should pick something else, like rel=hlicense to specify the relationship between a Microformat object and it's license. Manu, Martin, in brief, please do not propose/introduce/suggest new formats (hlicense, rel copyright etc) without at a minimum checking the wiki for work in progress regarding the limitations of rel-license. Just to be clear, I wasn't attempting to propose/introduce/suggest a new format. I was attempting to state that we'd need something else, something other than rel=license if we are to address this issue for Microformats. I was also attempting to point out that this is a non-issue for hAudio at the present because there are not enough examples to warrant the need for stating the license of an hAudio object. The latter of the two statements should close hAudio Issue D6, we should not support rel=license in hAudio: http://microformats.org/wiki/haudio-issues#D6:_2008-01-10_hAudio_notes_inconsistency -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio Issue D1: 2008-01-10 Contributor. Resolution
I am forwarding a message that Andy Mabbett sent to a couple of us involved with hAudio development because it is a valid opposition to the proposed resolution to hAudio issue D1. In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes * The contributor's name SHOULD also be marked up as a valid hCard Microformat. http://microformats.org/wiki/hcard For the record; I do not regard the above as resolving (nor even addressing) the issue highlighted in the e-mail cited in the issue-log. * If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator. This does not work for collaborations: Paul Simon Art Garfunkel Robert Plant Alison Krause and does not work in prose or tables like: Simon Rattle / Beethoven's Fifth This applies to plain-text contributor markup as well. Really? How will parsers handle: Paul Simon Art Garfunkel Paul Simon and Art Garfunkel Paul Simon Art Garfunkel Paul Simon/ Art Garfunkel Paul Simon, Art Garfunkel Paul Simon und Art Garfunkel Paul Simon et Art Garfunkel and every other language (and character-set) variant; and how will they differentiate between: Paul Simon-Art Garfunkel and: John-Paul Jones [Other interested parties CCd] -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files
Andy Mabbett wrote: By adding rel=enclosure to a hyperlink, a page indicates that the destination of that hyperlink is intended to be downloaded and cached. I don't take issue with that definition; I simply don't believe that a streaming audio feed, (say, one running 24/7, like BBC Radio 4's) can ever be an enclosure. Consider the usage I have downloaded it and enclose it with this e-mail. Your issue has to do with the semantics of the word enclosure, which unfortunately means something a bit different in the English language as it does in the computing realm. It's a valid point - and I'm a bit torn as you could interpret it in different ways. Like you said, one could use it in the following sense: I have downloaded it and enclose it with this e-mail, which would be a valid use of enclosure. It all depends on what you're enclosing... are you enclosing the actual file or a reference to the file. My interpretation is that rel-enclosure states that you're enclosing a reference to a representation of what you are discussing. A better analogy would be: I have enclosed a device that will let you listen to this radio station., as well. Or... I have enclosed a portal to let you listen to this audio stream. I do admit, however, that this concept will be lost on those that don't know much about knowledge representation... so perhaps there is a better word than rel-enclosure? My preference is to resolve that rel-enclosure is applicable to both static and streaming files and note the decision on the rel-enclosure wiki page. In which case enclosure is a misnomer. Embedded might be better. It's better, but you can't really embed or enclose something that has no end or temporal boundary, can you? (unless we get into the realm of 5+ multi-dimensional physics). rel=manifestation, rel=download or rel=representation are more accurate. rel=download is basically what we decided to use for the Media RDFa vocabulary (which the Audio RDFa vocabulary is layered upon): http://purl.org/media So, that's an option if we'd like to keep both vocabularies in sync, or offer rel-download as an alternative to rel-enclosure. The down-side is that rel-enclosure already exists and we should re-use when possible. Thoughts from the community? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Issue D1: 2008-01-10 Contributor. Resolution
Martin McEvoy wrote: * If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator. This does not work for collaborations: Paul Simon Art Garfunkel Robert Plant Alison Krause and does not work in prose or tables like: Simon Rattle / Beethoven's Fifth I know it doesn't but would you mark up Multiple Contributors like this span class=haudio [] span class=contributorPaul Simon/span span class=contributorArt Garfunkel/span [] /span I dont think most savy microformat publishers would either. It seems that the issue that Andy has, Martin, is that if someone were to do that, the hAudio specification says that it's okay to assume that the first contributor is the primary artist. In this particular case, it would be wrong to do so because both Simon AND Garfunkel are each the primary artist. It might be best if we delete that entire bullet point. Would that resolve your issue, Andy? ***(Andy has replied off-list that this would address his issue)*** Proposal for resolving hAudio Issue D1: REMOVE: * If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator. That would leave it up to the application authors to make assumptions if they want to... we really shouldn't be making any assumptions in the specification that are not 100% positive. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio issue D3: position
Martin McEvoy wrote: I would Like to close Issue D3: 2008-01-10 raised by Andy Mabbett in http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html as it was resolved in this email http://microformats.org/discuss/mail/microformats-discuss/2008-January/011353.html +1 We should close issue haudio-D3 with Martin's edit. We would use the current text in the description of position: http://microformats.org/wiki/haudio#Position and add the following rule to the end: * The sequential identifier MAY be specified out-of-sequence. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Moving hAudio to Draft stage
We currently have 5 open issues for hAudio that should be fairly easy to resolve now that we have a proposal on the table, htitle by Martin McEvoy, to resolve the contentious title debate on hAudio. I'd like to set a goal to close all remaining hAudio issues in the next 2-4 weeks. I'm sending this e-mail out as a heads-up to those that are interested in helping to improve hAudio and to get it to the next step in the Microformats process: Draft Specification. Both Martin and I will be posting the remaining hAudio issues and will be asking for feedback from the community in order to resolve the issues. Please respond to each issue with a +1 or a -1 if you have input on each issue and we'll hopefully close each of these issues if we reach a reasonable amount of consensus. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Proposal: change haudio title to htitle.
Martin McEvoy wrote: The most desirable thing about a htitle microformat is that we dont have to invent new names that mean the same thing such as recipe-title, book-title, product-title etc... they can all use just one. +1 for what it's worth. and if the above doesn't pan out, +1 for audio-title if this doesn't pan out (mostly because this is the only thing that is holding up hAudio and we've been discussing it for over a year now). -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
Brian Suda wrote: 2008/2/12, Martin McEvoy [EMAIL PROTECTED]: On Tue, 2008-02-12 at 07:33 +, Brian Suda wrote: --- WOW, after 6 days we have made a community wide change effecting 3 years of effort with only 4 people weighing in! I am sorry i haven't been timely enough to offer my thoughts. --- i volunteer with the community and have not have much time in the last 6 days to properly give it the thought and discussions it deserves. To say that this discussion has only been going on for 6 days is simply not true. This discussion has been here since June 2007 (some would say even earlier than that), here's the start of this discussion: http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html It is misleading to state that there hasn't been discussion on this topic. --- i would disagree. There are several reasons people do not answer. Maybe it was covered by someone else, maybe they are busy, maybe they personally are not interested. Let's not assume anything about the people that do or do not answer as anybody could mis-use intentions of those that stay silent to bolster their position. Rather, let's look at the people that weighed in on the issue. I would and do not jump up and down for every change, only ones which i feel are bad choices. People are pretty fatigued from having this debate over and over again without gaining any ground. And I agree with Martin - let's deal with the debate rather than ignore it, like we did in June 2007. --- i believe it was solved with FN. No, as Martin said, we settled for second best. My biggest concern is that fact that by usurping the term TITLE you are breaking all the previous hCards. You stated this back in June, you stated it again this month, and I asserted that it doesn't break any hCards. How does it break hCard? How does it break Operator? How does this decision have any impact on any hCard that is out in the field right now? I´m not saying we don´t NEED a term to represent the title of a work, just don´t re-define terms that already have meaning. How about don't re-define terms to mean something different from the English language, which is what hCard did. If you're defending that decision, please tell us why TITLE should have a meaning that is different than what is published in every English dictionary? The original logic in the question is flawed. The first portion is correct FN in hCard means the formatted name of a person or orgainzation. FN in hAudio currently means the formatted name of an audio recording. It is the next portion which is misleading and wrong: TITLE in hCard means job title TITLE in hAudio means audio recording title You missed the point, then. The point was this: FN in hCard means X of a person or organization FN in hAudio means X of an audio recording See the parallel? X changes from hCard to hAudio, but the tail of the statement stays the same. Where X is job in hCard, X is audio recording in hAudio. If we want to be consistent, we MUST be able to do the same for TITLE. TITLE in hCard means X title TITLE in hAudio means X title Where X is job in hCard, and where X is audio recording in hAudio. If we argue for anything else, we are being inconsistent. If we are inconsistent, it will be much harder for people to understand Microformats and take them seriously. It should be TITLE in hCard means the Job Title of the person or organization TITLE in hAudio means the Job Title of the audio recording Why should it be that? Because you have decided that TITLE should not follow the standard English definition and instead follow the definition that is put forth in RFC 2426? Furthermore, anybody that uses Microformats should be banned from using the English definition of TITLE? The correct logic is completely fine, but that is not what the proposal is trying to do. It is attempting to undo the definition of TITLE across all microformats, which has been discussed before and rejected in such formats as the citation. Then it should be easy to outline the logic behind why it was rejected for citation. I'm surprised nobody else on this list has referenced that discussion if it was pertinent. i´m not against haudio or having some sort of title property for the format, what i do not like is attempting to break any format with any property that has already been defined. I believe this issue is already solved with FN, (IMHO) there is no need for this proposal to use TITLE. There is quite a bit of FUD being thrown around here. You're asserting that this will break hCard, but have not provided any proof to back up that claim. Please, back this statement up with something. All of us are listening. You're claiming that the issue is already solved when the primary editors of hAudio are claiming that it most definitely has not been. So now you have my -1. Thank you, noted. Four shows of support for TITLE in hAudio, one against. Note that I do not mean any
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
Scott Reynen wrote: 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. That is a very wise interjection... I agree, we should be asking is it safe to say TITLE means title? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
Ryan King wrote:
Type special notes: This type is based on the X.520 Title attribute.
Type example:
TITLE:Director\, Research and Development
I can't seem to find any source for the semantics of X.520's title.
For those that are unfamiliar with X.520, it is an:
... International Standard, together with other International Standards,
... to facilitate the interconnection of information processing systems
to provide directory services. A set of such systems, together with the
directory information which they hold, can be viewed as an integrated
whole, called the Directory. The information held by the Directory,
collectively known as the Directory Information Base (DIB), is typically
used to facilitate communication between, with or about objects such as
application entities, people, terminals, and distribution lists.
[1]
The semantics of X.520 TITLE attribute, from ITU-T Rec. X.520, 1993E[1]:
5.4.3 Title
The Title attribute type specifies the designated position or function
of the object within an organization.
An attribute value for Title is a string.
Example:
T = “Manager, Distributed Applications”
title ATTRIBUTE ::=
{
SUBTYPE OF name
WITH SYNTAX DirectoryString {ub-title}
ID id-at-title
}
and since the above references the X.520 NAME attribute[1]:
5.2.1 Name
The Name attribute type is the attribute supertype from which string
attribute types typically used for naming may be formed.
name ATTRIBUTE ::=
{
WITH SYNTAX DirectoryString { ub-name }
EQUALITY MATCHING RULE caseIgnoreMatch
SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
ID id-at-name
}
The semantics of all of X.520 are clearly in the realm of directory
services, which deal with application entities, people, terminals, and
distribution lists.
Let's not forget that this was back in 1993... waaay before they
invented the Internet, citations and music. =P
-- manu
[1]http://64.233.169.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps+%2B%22X.520%22+specification+%2BTITLEhl=enct=clnkcd=3gl=usclient=iceweasel-a
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
Manu Sporny wrote: The reasons for this change include: - TITLE is more semantically accurate, we are trying to describe the title of the audio recording. - TITLE makes more sense to Microformats newbies than FN does. - There can be conflicts between hAudio FN and hCard FN - these conflicts are more prevalent that hAudio TITLE and hCard TITLE conflicts because TITLE is used less in hCard than FN. Oppositions to changing from FN to TITLE include: - It is already defined as job title in hCard. After a week, there have been 4 supporting e-mails for the hAudio TITLE instead of FN proposal, and 0 opposing e-mails, I have updated the hAudio specification to note the use of TITLE instead of FN: http://microformats.org/wiki/haudio -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
Manu Sporny wrote: If you are in support of this proposal, please speak up, even if it is a +1. If you are opposed to this proposal, please let us know the reasoning to your opposition. Someone has e-mailed me asking that I clarify this last bit. It should have probably read: If you are in support of this proposal, please speak up, even if it is a +1 for the reasons you listed in the proposal. If you are opposed to this proposal, please speak up, even if it is a -1 for the reasons you listed in the proposal. If you have any other thoughts on the issue that have not been expressed in the discussion thread, please do a +/- 1 and add the reasoning for your support or opposition. I feel that the above paragraph is more or less implied for all proposals, since that is what this community is all about, but it seems that one person doesn't think that is the case. To be fair to that person, and any others that thought I was asking something that was unfair to ask, the above paragraph states what I intended more clearly. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] PROPOSAL: Replace hAudio FN with TITLE
It is difficult for Microformat newbies to understand the reasoning behind the choice of FN for hAudio titles. Similarly, its semantic meaning is questionable when used with hAudio to name song, album and audio recording title's in general. There does not seem to be any legacy issues with using TITLE from hCard, other than the definition would have to change from job title to title. Since hCard is the only Microformat that uses TITLE, and since TITLE has a more specific meaning in hCard to mean job title, it can be said that TITLE, much like FN, becomes more specific given the context. FN in hCard means the formatted name of a person or orgainzation. FN in hAudio currently means the formatted name of an audio recording. If this proposal were adopted, the following would hold: TITLE in hCard means job title TITLE in hAudio means audio recording title It was asserted that this change would have no ill-effects to any other Microformat[1]. That assertion has yet to be challenged. The reasons for this change include: - TITLE is more semantically accurate, we are trying to describe the title of the audio recording. - TITLE makes more sense to Microformats newbies than FN does. - There can be conflicts between hAudio FN and hCard FN - these conflicts are more prevalent that hAudio TITLE and hCard TITLE conflicts because TITLE is used less in hCard than FN. Oppositions to changing from FN to TITLE include: - It is already defined as job title in hCard. If you are in support of this proposal, please speak up, even if it is a +1. If you are opposed to this proposal, please let us know the reasoning to your opposition. -- manu [1]http://microformats.org/discuss/mail/microformats-new/2008-February/001419.html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] workofart
Ottevanger, Jeremy wrote: In the last few days there have been some posts around the idea of a Dublin Core microformat, which idea has been pretty much dismissed or ignored, I think there is more support for re-using DC terms than you might think. As Danny stated, there is an existing (community) convention to be found in Embedded RDF (eRDF), namely - prefixing dc- before each term. If we want to re-use Dublin Core, we should adopt that thinking. Don't let the loud opposition of a few members in the community lead you to believe that there is no support for DC in this community. I should point out that hAudio RDFa makes heavy re-use of Dublin Core: http://wiki.digitalbazaar.com/en/hAudio_RDFa I'm still bemused, though, that the broadly applicable seems to be rejected in favour of the narrow. As I understand it, new microformats should where possible build upon existing uFs, but if these start off very narrow rather than generic then it makes it that much more awkward to do this - which it strikes me is the root of most of the problems in the hAudio debate. Had there been more broadly-aimed uFs to build it upon then rows over the meaning of title or contributor might never have arisen. Yes, that's true. It's a shame that we waste so much time convincing others of things that are openly accepted in other communities - things like the semantic meaning of title. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Namespace anti-pattern and hAudio TITLE
Edward O'Connor wrote: Manu wrote: Does it? If 'country-name' isn't namespaced, then we could get rid of country and 'name' by itself would have an unambiguous meaning. I think you're missing the distinction between 'namespace' and 'context', like Tantek suggested. I assure you, I am not missing the distinction. I have quoted the definitions in the literature to back up what I'm asserting. Please read the namespace-inconsistency-issue page before making statements to that effect (I have updated it to reflect your comments): http://microformats.org/wiki/namespaces-inconsistency-issue All definitions are clearly cited - note that nobody else is citing definitions to what namespace means in this discussion. If you would like to cite some examples that support your viewpoint, that would be great. :) Basically, you're stating the reductio for your own position -- you're basically saying that all adjectives are namespaces, and that's clearly incorrect. This is what I'm saying: context/scope provide an enclosing structure that provides semantic meaning to the elements that it encloses.[1] When you name a context/scope, it is called a namespace.[2] *Of course* 'country' has semantic meaning. It's an adjective that provides context for 'name'. But context does not a namespace make... No, but a named context is a namespace. It's right there in your first semester programming languages text book (which I've cited several of them on the namespaces-inconsistency-issue page). 'country' is a namespace that gives scope to the following 'name' by specifying that we are talking about a 'country name' and not a 'person name'. No, country does that because of its adjective-ness, not its namespace-ness. In this case, they're the same thing. In general, I would go as far to say that adjectives and adverbs, by definition, are namespaces because they provide finer context for the subject that they describe AND they are named. A named context is... a namespace. -- manu [1]http://wordnet.princeton.edu/perl/webwn?s=context [2]http://en.wikipedia.org/wiki/Scope_%28programming%29 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] namespaces-inconsistency-issue page updated
The namespaces inconsistency issue page has been updated with the current state of this discussion. I'm going to drop the issue (once again) since it seems to be making several people uncomfortable. http://microformats.org/wiki/namespaces-inconsistency-issue Please read the page and update the page if you see something that is factually inaccurate or needs re-wording. More importantly, if you would like to see the Microformats community address this issue (and not ignore it like we've been doing), please sign the Sympathetic to the Cause section of the page: http://microformats.org/wiki/namespaces-inconsistency-issue#Sympathetic_to_the_Cause To sign, just log into the wiki and use or /Your Name/. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE
David Janes wrote: I'm going to vote with Tantek on this one. I'm sympathetic to what you're saying Manu, but after 2 or 3 years on this list and seeing the same topics come up over and over that really aren't going to change. I'm not asking the community to change it's stance on fully qualified namespaces. I'm asking the community to clarify their position based on their implementation history in hCard and hAtom: http://microformats.org/wiki/namespaces-inconsistency-issue The reason these topics keep coming up over and over again is because they are defined vaguely and inconsistently on the wiki. That leads to confusion. Confusion leads to the discussion we just had. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Introduction to Microformats
Walter Logeman wrote: Is the workofart one of the ones under development? It currently has nobody pushing the format forward. It looks a bit lost: http://www.microformats.org/wiki/workofart-formats Could that be revived here on this list? It could be revived - but be ready to do a ton of work if you pick it up. It took around 500+ hours of work by the editor and around 250+ hours (estimated) of work by list participants to get hAudio to where it is today. Pushing a Microformat forward is not for the faint of heart... but if you're okay with doing that sort of work for the public good, by all means, push hArt forward. That being said - if you could stomach the discussion about namespaces, you should do fine on this list :) I am a programming virgin but a Philosophy graduate so this sort of thing is quite fun, but I can see it could go off-topic. Good :) - there is quite a bit of borrowed philosophy from a variety of disciplines wrapped up in Microformats. It's interesting to see the intersection of the philosophies of linguistics, computer science, working for the public domain, and what people find easy and intuitive implement. I am going to POSHify my site, I'll learn by doing, and return here later. That's the best place to start... :) -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
David Janes wrote: On Feb 4, 2008 10:38 AM, Manu Sporny [EMAIL PROTECTED] wrote: Microformats use emulated namespaces[3], for proof, we need only look to hAtom[5]: * entry-title * entry-content * entry-summary In this example, entry is an emulated namespace. This community has been mis-using the word namespace for several years now, and it's causing too many problems for those that are attempting to understand why we allow entry-title, but don't allow namespaces. No, it just looks like it uses an emulates namespace There's no such thing as looking like you use an emulated namespace... just like there is no such thing as looking like you use a context. You either do or you don't. :) If you can find an example of looking like you're using an emulated namespace in any published linguistics, computer science, or programming/language theory literature then please post that as I am unaware of the concept. Here are more examples of Microformats using emulated namespaces: country-name (hCard) organization-name (hCard) organization-unit (hCard) please see the hAtom discussions from two years ago if you're interested in the gory details. Got a link? I'd like to know how the thought process went. Essentially, the definition of those three items _is so specific to the problem domain_ that we invented names specifically for that. Names were invented that have a common base stem, in the case of hAtom, you used 'entry-'. That's my point. When you use a common base stem, it is an indicator that you are using a form of namespacing - you are creating context for what comes after the base stem. I'm not stating that I think it was a bad decision. I'm stating that we do stuff like that in Microformats while touting this no namespaces! rhetoric, which is confusing to on-lookers. We should be saying: 1. No fully qualified namespaces! 2. Emulated namespaces are strongly discouraged! e.g. entry-title isn't any old title, it's specifically the Atom concept of a title. You could imagine a blog post semantically marked up where a fn is around the entry-title with some more information (David Janes says...) I'm not asking that you rip it out - I'm asking that we be more consistent in how we discuss namespaces. Here's what I think the community is for: 1. No fully qualified namespaces in Microformats. 2. Emulated namespaces in very specific cases, such as hCard and hAtom. 3. Context is used to determine more specific semantic meaning for class names such as FN and TITLE. #3 is what we're specifically talking about right now, but knowing #1 and #2 exist is also important to the discussion. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
Tantek Çelik wrote: context is not the same as namespaces. namespaces provide one form of context, but not all contexts are namespaces. in the case of compound microformats, the context that is used is hierarchical containment. Tantek, The issue is not that cut and dry - and the definition of namespace as it relates to Microformats has been twisted to mean something different than it does in the rest of the world. Just so that we're on the same page, everyone should read the standard definition of a namespace[1] and the computer science definition of a namespace[2]. More specifically, the following line is quite clear about the relationship of a namespace[1] and a context and is in direct conflict with your definition: A namespace is also called a context, as the valid meaning of a name can change depending on what namespace applies. If you meant, fully qualified namespaces instead of namespace, then I would agree with you. Context is not the same as a fully qualified namespace is true - however, this is not what you said and I believe this to be a very long-running issue with Microformats: Oversimplification of the namespace problem. What Microformats have an issue with is fully qualified namespaces, which is fair - that concept adds unnecessary complexity as far as the community is concerned. However, that is not what is written up on the wiki in the anti-pattern section on namespaces[4]. The anti-pattern makes it sound like Microformats don't use namespaces at all - which is where all the confusion arises. Microformats use emulated namespaces[3], for proof, we need only look to hAtom[5]: * entry-title * entry-content * entry-summary In this example, entry is an emulated namespace. This community has been mis-using the word namespace for several years now, and it's causing too many problems for those that are attempting to understand why we allow entry-title, but don't allow namespaces. The definition that the Microformats community uses for 'namespace' is flawed and thus the logic becomes flawed - this needs to be fixed. fn *does* have meaning - it means formatted name. No, that is what FN expands to, Formatted Name - the semantic meaning of that is useless without context... without a namespace. I am asserting that very few of us, if any, mark up all the FNs on a page just because we can - names of buildings, cities, people, animals, countries. FN is semantically void without context, without a higher-level Microformat to encapsulate it, without a namespace. Inside an hCard it means the formatted name of either a person, organization, or location (depending on the specifics of the hCard). Inside an hReview item it means the formatted name of an item. So, it *DOES* have different meaning when used in a different context? The object (what you are naming) of the FN changes based on context. So, who is going to make an argument against using TITLE in hAudio? The problem of such use of the term title is twofold. 1) it's already used to mean job title in the context of microformats. Wait, what!? So FN can have two slightly different meanings based on it's context, but TITLE cannot? Why is that? This is exactly the issue: FN's meaning changes slightly based on if it is used in hCard or hReview. TITLE's meaning is locked in to mean job title in all Microformats. There is a glaring lack of consistency here, would anybody like to elaborate on why we're OK with that inconsistency? 2) the concept that it is being proposed to represent is the *name* of an audio item. fn already means the name of an item. we should not introduce a new term to mean the same thing as an existing term. Incorrect, the concept that it is being proposed to represent is the *title* of an audio recording. TITLE is widely used for that purpose in the english language. We should not restrict that word to mean job title, when the English language is fairly clear that TITLE can mean a variety of things[6] based on the context in which it is used. -- manu PS: This is also the reason that I don't spend more time on Microformats - these discussions are very unsatisfying... I've never had to argue about what the meaning of a word such as TITLE actually means at the W3C or any of the other communities that we work with. If we are unsure, we look it up in a dictionary and that is usually the end of the discussion. Microformat's seem to redefine key words like namespace and title as a means to an end, which is wholly frustrating as you need to re-learn parts of the English language in an attempt to contribute to the community. [1]http://en.wikipedia.org/wiki/Namespace [2]http://en.wikipedia.org/wiki/Namespace_%28computer_science%29 [3]http://en.wikipedia.org/wiki/Namespace_%28computer_science%29#Emulating_namespaces [4]http://microformats.org/wiki/namespaces [5]http://microformats.org/wiki/hatom#Entry_Title [6]http://wordnet.princeton.edu/perl/webwn?s=title ___
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
Brian Suda wrote: 2008/2/4, Manu Sporny [EMAIL PROTECTED]: Here are more examples of Microformats using emulated namespaces: country-name (hCard) organization-name (hCard) organization-unit (hCard) --- i do not consider these namespaces. Then, I assert that your definition of what is and isn't a namespace is out of step with the common definition of a namespace[1] and it is causing confusion to those that are familiar with the common definition of a namespace[2][3][4][5]. In the vCard RFC the value is called Country Name, Organization Name and Organization Unit with spaces. Since we could not use spaces in a class attribute we had two choices, CamelCase or hypens. We chose Hypes. There was no attempt to do any sorts of emulated namespace, more simply just concatenating space-separated-terms so they could be used in the class attribute. Even if there was no attempt to do any sort of emulated namespace, and even if you were attempting to just concatenate space-separated-terms so they could be used in the class attribute, the end result is an emulated namespace. Let me try and put it another way. If we have this (EX1): organization-name organization-unit We have a root, a separator, and a suffix. The root is 'organization', the separator is '-' and the suffixes are 'name' and 'unit'. If we have this (EX2): organization/name organization/unit We have a root, a separator and a suffix. The root is 'organization', the separator is '/' and the suffixes are 'name' and unit'. If we have this (EX3): http://organization.org/name http://organization.org/unit We have a root, a separator and a suffix. The root is http://organization.org;, the separator is '/', and the suffixes are 'name' and 'unit'. So why are we saying that EX1 doesn't have a namespace and EX3 definitely has a namespace (for those that are new to RDF - EX3 is how RDFa declares namespaces)[6]. Regardless of what those that put hCard together meant to do, a side effect of choosing to use '-' to separate elements and using the same root creates an emulated namespace. This same argument applies to hAtom. To create an emulated namespace and then to claim that it isn't one creates an inconsistency in the Microformat community's stance against namespaces. -- manu [1]http://en.wikipedia.org/wiki/Namespace [2]Programming and Problem Solving with C++, By Nell B. Dale, Chip Weems, p.369 [3]History of Programming Languages II, By Thomas J. Bergin , Richard G. Gibson, p.265 [4]Computer-Aided Verification '90: Proceedings of a DIMACS Workshop, June 18-21, 1990. p.571 [5]Handbook of Object Technology By Saba Zamir, p.15 [6]http://www.youtube.com/watch?v=ldl0m-5zLz4 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
Andy Mabbett wrote: I've been meaning to document them for several weeks, but haven't gotten around to doing so. You'd be the best person to word it in a way that you agree with I agree it would be useful, and will do so if and when I have time; don't let that stop you if you have free time first! That said, I have previously found the placing of issues on with wiki to be pointless exercise, as they are often ignored, or rejected out-of-hand, with no adequate discussion. Can't speak for other initiatives, but it would be a shame to ignore any constructive criticism on issues surrounding hAudio. We didn't ignore input for the pre-draft hAudio, and we shouldn't start ignoring input now, either. What the hell; done. there are six at: http://microformats.org/wiki/haudio-issues Don't say I'm not good to you ;-) Awww... thanks Andy, you shouldn't have =P Looks like we're currently dealing with hAudio Issue #D2[1] -- manu [1]http://microformats.org/wiki/haudio-issues#2008 ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
Brian Suda wrote: If we have this (EX2): organization/name organization/unit We have a root, a separator and a suffix. The root is 'organization', the separator is '/' and the suffixes are 'name' and unit'. --- but your argument falls down with your other citation of country-name. This is NOT: country/name Does it? If 'country-name' isn't namespaced, then we could get rid of country and 'name' by itself would have an unambiguous meaning. However, if we were to do that in practice, 'name' wouldn't mean 'country name' anymore... it would be more ambiguous. By being more ambiguous, we're stating that the prefix that we removed, 'country', actually does have semantic meaning. 'country' is a namespace that gives scope to the following 'name' by specifying that we are talking about a 'country name' and not a 'person name'. But even with that argument, let's get rid of country-name - we're still left with: entry-title entry-summary entry-description organization-name organization-unit My argument still stands - we're providing a specific scope to 'title', 'summary' and 'description' - that scope is 'entry'. We are also providing a specific scope to 'name', and 'unit' - that scope is 'organization'. Regardless of what those that put hCard together meant to do, a side effect of choosing to use '-' to separate elements and using the same root creates an emulated namespace. --- this was never the intent of hCard, and i still no do not believe having a hyphen denotes namespaces of any kind. People who hypenate their surnames, jones-smith is NOT a namespace of jones/smith. We're not talking about people who hyphenate their surnames - we are talking about the use of TITLE in hAudio and the inconsistency in the Microformat community's definition of 'namespace'. To create an emulated namespace and then to claim that it isn't one creates an inconsistency in the Microformat community's stance against namespaces. Agreed, and this is why i do not consider this any sort of emulated namespace had it his been CamelCase would you still argue Namespace? Yes! You don't need a separator for namespaces to occur, you just need the root to be the same. getUser() is not namespaced, nor is smith-jones or country-name or e-mail. I agree that smith-jones is not namespaced, it is hyphenated. However, every other one of your examples is a form of scoping/namespacing: getUser() implies that there are other getters on the object - the implied namespace/scope is the set of getter methods for the object/module. country-name is namespaced/scoped - the named scope is 'country'. This differentiates it from 'audio-name', which implies a named scope of 'audio'. If we were to remove 'country' and 'audio' from these two examples, we would be left with 'name' and 'name' - which are indistinguishable from each other. The prefixes define a scope - a scope that is named is called a namespace. We must be talking past one another with our definitions Just to be clear - this isn't /my/ definition - it is the definition that is widely accepted in Computer Science. The definition on the Microformats page is, at best, vague, at worst, inconsistent with the definition that is widely accepted in Computer Science. it is probably best to start a wiki page and the discussion will not get lose between posts and threads. It will also make it easier for anyone to reference later. Sure thing - the page is up: http://microformats.org/wiki/namespaces-inconsistency -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: namespaces bad topic for uf mailing lists reminder (was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title))
Tantek Çelik wrote: No one actually will admit to the existence of a namespace in microformats but there is lots of evidence suggesting otherwise. either intentional or not, Microformats MAY have created their own namespace of a kind I think? The problem is with this loose use of term namespace or namespace of a kind, not with microformats usage thereof which will result in endless semantic arguments which are not useful. Is that why you RESOLVED the issue without consulting the list first? http://microformats.org/wiki?title=namespaces-inconsistency-issuediff=25462oldid=25450 If Andy did something like that, he'd be up for another ban... With all due respect, Tantek - I was attempting to make the definition of namespace that the Microformats community uses far more accurate - to clarify the no namespaces stance that the community has. By shutting down the discussion, you've single-handedly pre-empted that improvement to the wiki. An improvement that would help new comers to this list and Microformats understand what we mean by no namespaces. It was an improvement that the community largely agrees with, but the namespaces page doesn't express[1]. You even agree to this sentiment in the e-mail you quote in the RESOLUTION section[2]. I'm disappointed that this discussion is being pre-emptively shut down... just when it seemed as if we were making progress. -- manu [1]http://microformats.org/wiki/namespaces [2]http://microformats.org/wiki/namespaces-inconsistency-issue#Resolution ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE
Walter Logeman wrote: I am jumping in, new here, new to microformats, looking for a solution to a problem, but more on that later. Welcome to Microformat's, Walter :) This thread has helped me understand a few things, though I would not want to have endless debates about the meta-language used. Just a small pointer - microformats-new is for the design/debate/discussion for new Microformats under development. It's a pretty harsh place to start out learning about Microformats - you can learn a great deal from this list, but it's not meant as an introductory discussion group. You might want to check out microformats-discuss if you wanted to discuss the use of pre-existing Microformats in your website: http://microformats.org/mailman/listinfo/microformats-discuss/ That being said - if you could stomach the discussion about namespaces, you should do fine on this list :) Do I have this right then, within hAudio it would be possible to have title or fn? Well, that is what we're currently debating. The current draft specification for hAudio uses FN, which several of us are contesting as a bad choice. Some of us would like to use TITLE, but previously when we had suggested that, some on this list nixed the idea because TITLE is already used in hCard to mean job title. Since TITLE was defined to mean job title in Microformats, that precludes us from using it for hAudio. We're attempting to change the Microformats definition of TITLE to mean title instead of job title. It sounds like a no-brainer, but we're making sure it doesn't have any other ramifications before doing so. The best thing about this community is that we debate the merits and drawbacks of an idea in an open environment before coming to a conclusion. This helps everybody weigh in on the issues before a decision is made. Some also argue that this open debate is the worst part about this community :) I'd prefer title, it makes more intuitive sense to me. Good to know, thanks Walter - that helps us understand what would be most intuitive to somebody starting out in Microformats. We've been immersed in this stuff long enough that it's hard to see the forest for the trees at times. Would there also be tag name for file name? fn could get confusing ... There isn't a proposal for filename at the moment, other than using the ENCLOSURE class in @rel. Filenames, sizes, bitrates, etc. are outside of the scope of what hAudio is attempting to address (naming audio recordings). What if the page includes profiles for hAudio *and* hCard? I am a total newby, I just looked at my hCard thinking there would be a div class=hCard, but no it is div class=vcard ??? Yes, that certainly is confusing. VCARD was used as the class name for historical reasons - hCard is based on the VCARD format by Netscape: http://www.ietf.org/rfc/rfc2426.txt That is why the name of the class is VCARD instead of hCard. So does every microformat, regardless of the context need to be unique? It depends on what you mean by unique. If you mean, do the class names have to be unique, then yes, they do have to be unique. I am hoping to mix hCard, xfn and hArt if it were there, I saw a start on it? I will start some new threads. Yes, you can mix hCard and xfn on the same page, and even in the same paragraph. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
Andy Mabbett wrote: Items 1-5 have different meanings; that's why you were able to list fire items, not just one. How would you mark up position in: At number two in the chart this week is Pink Floyd's Fearless, track 3 on their Meddle album. Or, rather, which of the two different kinds of position would you mark up? Andy - could you please list the issues that you have with hAudio on the audio-info-issues page so that we can track them. I remember seeing 3 distinct issues that you raised in the past month (although, there may be more). I've been meaning to document them for several weeks, but haven't gotten around to doing so. You'd be the best person to word it in a way that you agree with: http://microformats.org/wiki/audio-info-issues -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio FN or Title
Martin McEvoy wrote: On Fri, 2008-02-01 at 22:09 퍍, Andy Mabbett wrote: The more I consider this, the more I am convinced that class names should not be shared between microformats. For what its worth I think you may be right for example fn was only used in hcard this meant just the name of a person or organization, great stuff powerful and clearly defined. hAudio and hreview re-use fn to mean other things too, haudio it means, a title of a playlist, album, or track and the name of a contributor or organization This is the start of an argument for namespaces: http://en.wikipedia.org/wiki/Namespace I have always been in favor of using namespaces, but it seems as if the rest of the Microformats community are against the concept because of the added complexity (and there certainly is added complexity). Andy, Martin - are you proposing 'context-aware vocabularies' or something similar to that? Brian, Tantek - there is no need to pull in the entire Dublin Core metadata vocabulary set. For example, all we would need to pull in for hAudio would be 'dc-title' at this point. That or we would need to be allowed to use 'title' for hAudio, since that is the word that makes the most amount of sense for what we are describing. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio FN or Title
Martin McEvoy wrote: This is in Response to Manu's suggestion that maybe we should talk about changing hAudio FN to Title snip I've never been happy with the choice of FN instead of TITLE in hAudio (TITLE means job title in Microformats). This could offer a good compromise if people are interested? /snip http://microformats.org/discuss/mail/microformats-discuss/2008-January/011446.html Manu I for Once Agree with you ;) and I'm not too happy with it either. Feedback I have had about haudio seem to all have the same answer audio has a title too lets call it that. I am unsure If we should re-use title directly from hcard Job title and audio title are both functions I guess? maybe someone can have more input on this. The thought about porting the Dublin Core names over to Microformats was mentioned on the uf-discuss list. Having a Dublin Core Microformat, may be a solution that works for everybody. I'd be a very strong supporter of Dublin Core's use in Microformats, especially hAudio. Note that hAudio RDFa already re-uses the Dublin Core metadata vocabulary: http://wiki.digitalbazaar.com/en/HAudio_RDFa The main disagreement seemed to be in DC's choice of class names (DC.title, DC.contributor, DC.date). What about this for a Dublin Core Microformat: dc-title dc-date dc-description ... and on. This approach has two benefits: * It uses Microformat-like names. * It re-uses a vocabulary that is largely accepted in the web semantics community. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Intro to the Semantic Web in 6 minutes (video) http://blog.digitalbazaar.com/2007/12/26/semantic-web-intro ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
Michael Smethurst wrote: In terms of marking up acts and scenes and movements and works and etc I'd encourage hAudio to steer well clear. It's a hideous minefield and I suspect hAudio can solve 80% of the problem by avoiding this stuff. Hmmm... Perhaps I'm missing something, but hAudio can already mark up operatic pieces: http://microformats.org/wiki/haudio#Opera_Example POSITION is a loose descriptor of where the piece fits in if it is part of a collection of some kind. It is most useful when the other pieces are not listed on the same page. Position can be: 1. The position of the track on a CD. 2. Podcast # of the recording. 3. The position on a top-10 list. 4. The physical position on a CD set of an Operatic piece. 5. The side and track # of an LP (ie: A1, B2) 6. Specified in TABLE elements. 7. Can be specified out-of-sequence. I don't think we avoided the problem when putting position in there... it takes on the challenges of positional identifiers for audio recordings. If we take position out of the hAudio spec, we lose support for all of the use cases listed above. If you want further proof, look at the examples... or I can give examples of pages to prove my point. (I say that somewhat sarcastically, because you can almost always find examples online to prove a point in Microformats). For an idea of the complexity I'd point semweb minded people at the fine work of Yves Raimond on the music ontology (which incidentally it would be nice to see used in the rdf-a hAudio spec): http://musicontology.com/ There will probably be multiple OWL mappings from hAudio RDF to MusicOntology RDF... for example: owl:Class rdf:ID=Recording owl:equivalentClass rdf:resource=http://purl.org/ontology/mo/Recording/ /owl:Class I've been thinking about heavy re-use of MusicOntology (which is great, if you need to do more than just markup albums/tracks). The big mistake I think the MO folks made was putting properties in there that should have been just plain URIs: http://musicontology.com/#term_myspace http://musicontology.com/#term_amazon_asin http://musicontology.com/#term_musicmoz It's so incredibly heavyweight that it makes most people's heads spin when attempting to just simply mark up a song. That being said, there will still be mappings from one to the other (or re-use of some of the MO vocabulary in the hAudio RDF. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
Michael Smethurst wrote: Again I apologise. No need to... these discussions are very helpful to have... Just meant that in general haudio doesn't model works vs performances vs recordings etc. And again I don't think it should attempt to touch this complexity Which I think means we're in agreement?!? Yes, we are in agreement. :) -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
Andy Mabbett wrote: On Tue, January 15, 2008 16:18, Manu Sporny wrote: POSITION is a loose descriptor of where the piece fits in if it is part of a collection of some kind. It is most useful when the other pieces are not listed on the same page. Position can be: 1. The position of the track on a CD. 2. Podcast # of the recording. 3. The position on a top-10 list. 4. The physical position on a CD set of an Operatic piece. 5. The side and track # of an LP (ie: A1, B2) 6. Specified in TABLE elements. 7. Can be specified out-of-sequence. Isn't it overloading, to put so many meanings onto one attribute? They're all positions, aren't they? They all have the same meaning. I haven't seen a proposal yet that can do better than POSITION does currently... -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] New proposed microformat: hProject
I propose a new format called hProject. It's intent is to provide a simple structure that describes project. I suggest you take a look at DOAP, as the hProject concept already exists in the RDF world: http://www.ibm.com/developerworks/xml/library/x-osproj.html The initiative was started almost 4 years ago... -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
Julian Stahnke wrote: No misunderstandings, and easy to understand. I don't understand what benefits a publisher has using fn album over simply just album Microformats are supposed to use simple conventions and use brief, descriptive class names, sorry about the quotes I am just emphasising my Issue. Wouldn’t that be like trying to use just ‘org’ in an hcard to say that something is an organisation? Doing this is perfectly OK to do in the VCARD format, AFAIK. It would be up to the application to understand that since no other fields are present, the displayable name should be the same value as ORG and the VCARD is about an ORG. If we model this aspect of haudio after vcard, shouldn’t it behave the same? Jeez, this issue just won't die, will it :) How about this proposal: It takes everybody's input into account in this thread and follows the current hCard specification exactly. PROPOSAL: FN is required for hAudio. It is used to identify the name of the audio recording. ALBUM is optional. It is used to identify the name of the album that the audio recording belongs to. If both FN and ALBUM are present and the same, the application MUST deduce that the recording being discussed is an audio album. ALBUM SHOULD NOT exist unless FN is specified. Does that work for everybody? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] [hAudio] fn _or_ album
Martin McEvoy wrote: so why not call it hRecording and have done with it? Because video is a type of recording too... What is hRecording? A video recording or an audio recording? hAlbum is redundant, too specific, so is hAudio I think? but its too late for that now... It's not that it is too late for that... hRecording just doesn't make sense for what we're talking about. You could argue that we could name it: hVideoRecording and hAudioRecording... but then someone would make the argument that the recording part is redundant between the two microformat names... which means we end up with hVideo and hAudio using that line of reasoning as well. This thread is going a bit off track... we are talking about FN and ALBUM. Is everyone comfortable with the idea that hAudio is about audio recordings? -- manu PS: What Scott said is also very accurate... and I agree with him 100%. ___ 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
André Luís wrote: From what Sean is describing, if people wanted to display the information in the turtle/rdf format to normal users, they would have to write it twice in different languages. POSH and then hTurtle. See? Just there, I wasn't able to put hturtle and POSH in the same sack... Now, I don't mean to say there's no point in hTurtle. There is, I'm just not sure it fits in the microformats group. Can't we have something in between ufs and pure rdf? There already is something between uFs and pure RDF: RDFa http://www.w3.org/TR/xhtml-rdfa-primer/ Although, marking up Turtle using RDFa is a bit pedantic... :) Just curious... why didn't you use RDFa to do this, Sean? Scott and the rest on this thread are correct - what you have isn't a microformat as this community understands the term, it's something else... for what that's worth. What exactly is the use case behind hTurtle? What are you attempting to accomplish? There are so few in this world that understand the concept of N3, triples and RDF that I wonder how many people have the need for hTurtle? curiously, -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Closing outstanding hAudio issues
Manu Sporny wrote: The following hAudio issues have been resolved with the latest update to the hAudio proposal (hAudio v0.8). If there are no objections, I'd like to mark all of them as resolved. Seeing no objections, issues 2, 9, 10, 11 and 13 have been resolved. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk Launches World's First Open Music Recommendation Service http://blog.digitalbazaar.com/2007/09/09/bitmunk-music-recommendation/ ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio v0.8 updated (corrections)
Chris Newell wrote: 1) The Schema section states fn and/or album required but in the Field Details section for both Formatted Name and Album it states hAudio MUST have either fn or album. It would be good to use and/or throughout. Fixed. 2) The definition of the position field is currently a number or other sequential identifier which is rather vague for a machine readable field. I'd prefer to see this specified as an integer with a reminder that abbr can be used to provide an alternative human readable form. I'd be fine with that proposal, except that LPs and EPs are usually listed as having A and B sides. Opera acts are usually written using roman numerals. We would like to support these other forms of sequential identifier. Here's a real-world example: http://www.discogs.com/release/74366 A1 Figuras Frustradas Psychic Vacuum A2 Pametex Laque B1 Cosmic Force The Electric Vision B2 Blue Villa PeopleR.E.M. The question then becomes, is A1 position #1, or is B1 position #1? Can we support these varied methods using only integers, or are we going to have to focus on humans first and machines second. My inclination is to focus on humans first and machines second. No change has been made, yet. I'd like to keep that statement as-is until there is a compelling way to support roman numeral and LP/EP positional notation. Anybody have any great ideas on how to do this? 3) The category field is currently defined as text. Most of the examples I've examined a link which is effectively a tag. Can we adopt the approach used for the hCard category field and say: Categories in hAudio MAY be represented by tags with rel-tag. When a category property is a rel-tag, the tag (as defined by rel-tag) is used for that category. Apart from the benefit of using rel-tag, a consistent definition of category throughout microformats would be good. Done. I made some small editorial corrections, does the following statement work for you? # This element MAY be expressed using the rel-tag elemental microformat. When a category is expressed using rel-tag, the inner content of the element is used as the text for the category. For example: a class=category rel=tag href=/tags/rockRock and Roll/a would have Rock and Roll as the text for the category. 4) The Language section has an odd reference to reviews (cut and paste error from hReview?): hAudio processors which need to handle the language of reviews MUST process the standard (X)HTML 'lang' attribute as specified. Fixed. 5) This is probably not the time and place to say it but I regret the fact that there is no way to indicate the language used in the audio content, as opposed to the hAudio property values. We can always add it into future versions of hAudio if it becomes common place to specify the language of an audio recording. The reason hAudio doesn't have a way to indicate the language of audio content is because we didn't see that markup behavior while analyzing the examples. For the time being, the publisher can add a category property with the language listed, such as: span class=categoryspanish/span or a rel=tag class=category href=http://en.wikipedia.org/wiki/Burmese_language;burmese/a 6) Aren't the last three bullets in the informative Notes section now obsolete? Fixed. Thanks for the vetting, Chris :). If anybody else wants to take a look through hAudio and point out sections that are misleading, confusing or wrong, please do. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Closing outstanding hAudio issues
The following hAudio issues have been resolved with the latest update to the hAudio proposal (hAudio v0.8). If there are no objections, I'd like to mark all of them as resolved: ISSUE #2: audio-title Property http://microformats.org/wiki/audio-info-issues#audio-title_Property RESOLUTION: The latest proposal uses FN and most seem to be happy with that. ISSUE #9: album-title Property http://microformats.org/wiki/audio-info-issues#album-title_Property RESOLUTION: The latest proposal uses ALBUM and most seem to be OK with that approach. ISSUE #10: Collection names http://microformats.org/wiki/audio-info-issues#Collection_Names RESOLUTION: We seem to have settled on ALBUM as the only explicit collection type for now. ISSUE #11: TRACK does not work in tables http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables RESOLUTION: When we settled on ITEM containing hAudio properties, this problem went away. We have demonstrated that hAudio v0.8 works in tables. ISSUE #13: Container property naming http://microformats.org/wiki/audio-info-issues#Problem:_Container_property_naming RESOLUTION: The latest proposal uses ITEM to denote containers. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio v0.8 updated
Martin McEvoy wrote: When do you plan a move to draft ? haha... good question :). I don't really know the process of moving from where we are now to draft... I've never seen it happen before =P We should probably: 1. Close up most of the remaining hAudio issues (this is where we are currently). 2. Take another round of comments on whether people think hAudio is ready to go to draft. 3. Update the hAudio implementation for Operator. 4. Make a formal request to move hAudio to the Draft Specification stage. Perhaps a gray-beard on the list would like to comment on if the above is a rational way to move forward? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
Martin McEvoy wrote: Scott Reynen wrote: also I dont believe fn and album together serve any real benefit as they both seem to mean the equivalent of a title Not true. OK? .. Scott's correct - FN and ALBUM are used to identify two completely different things. On Oct 21, 2007, at 12:20 PM, Scott Reynen wrote: FN does *not* mean album name. It means *audio* name. Whether or not that's the same as the album name determines whether or not we're talking about an album. That Is YOUR definition Not really... it's the definition that we've settled on after a very long discussion regarding AUDIO-TITLE and FN. It is not Scott's definition - it is the definition that is in hCard. We are probably going to re-use it in hAudio because we won't have to invent a new word (AUDIO-TITLE) and we will be re-using the proper semantics. The wiki is a little misleading at the moment but off the audio-info-proposal page... Would anybody have a problem with me taking the time to update the hAudio page? It is badly out of date at this point and it is leading to more confusion than helping. I could integrate the ITEM proposal and the FN proposal and fix up some very outdated language. The hAudio page is in grave need of an update. Album The title of a collection of audio recordings that are represented as a CD, album or LP. The text should be a short textual description used to identify the work among interested parties. This can be the title of a CD, album title, or the name of a collection of audio recordings. * The element is identified by the class name |album-title|. * hAudio /MUST/ have either |album-title| or |audio-title|. http://microformats.org/wiki/audio-info-proposal#Album How has the definition changed from the above? The only change is to the bullet points: * The element is identified by the class name ALBUM. * hAudio /MUST/ have either ALBUM or FN. All I am suggesting is that we should forget about any fn album optimization for now and keep it simple. Now that item / fn has been accepted to described hAudio tracks, there is no real need to complicate hAudio any more than saying that audio-title is the main hAudio title and fn is a track title and leave it there. As Scott pointed out, it is not an optimization. Remember, we have the following rules for hAudio that allow us to describe the type of a recording: * If only ALBUM is specified, the hAudio is an album. * If FN and ALBUM are specified and different, the hAudio is a song in an album. * IF FN and ALBUM are both specified and are identical, the hAudio is an album. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio ITEM debate proposal #3
This is a follow-up to a previous attempt at resolving the hAudio track/item debate: http://microformats.org/discuss/mail/microformats-new/2007-October/001150.html Brian Suda and I spent quite a bit of time talking about alternatives and it seems that his disagreement with the previous approach was largely due to implementation requirements. The end result of our discussion had more to do with implementation than a change in markup. While we didn't agree on everything, there was a common thread in the ideas that allow us to move forward. Namely, if we focus on the following, we should reach agreement: * Not prematurely optimizing hAudio. * Use ITEM and not ITEM+HAUDIO. PROPOSAL: HAUDIO parts are denoted by ITEM: span class=itemspan class=fnTrack Name/span/span EXAMPLES: Album with two tracks, simple example: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span div class=item span class=fnHokkaido Dream/span /div div class=item span class=fnTokyo Groove/span /div /span Album with two tracks, more detailed: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span span class=item span class=fnTokyo Groove/span abbr class=duration title=PT4M46S4:46/abbr /span /span 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? This is the last blocking issue with hAudio before we can move it to Draft status. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
Brian, it sounds like you have several misconceptions about hAudio, some of them are from recent changes that we have discussed on the list, some of them are from discussions that we have had long ago. I am going attempt to address the ones that are most poignant and explain why we are where we are right now. First, let me state that hAudio is about audio recordings, of which tracks and albums are a subset. I think you were under the impression that hAudio was primarily about Albums and containing tracks. It is not. While we have borrowed some design elements from hReview and hCard, we should not get confused between the various Microformats and hAudio. We should draw parallels to hReview and hCard when it is applicable, but to say that hAudio is EXACTLY like hReview or hCard is a mistake. It is not. At this point, we are not discussing what properties should be a part of the hAudio specification. It seems that everybody is more or less agreed on what properties should be a part of the specification. We are discussing: - Naming those properties (specifically, tracks in audio albums) - The structure of hAudio as a container. Specifically, we are talking about tracks in albums, and what should denote the track container in hAudio. 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. I personally don't like ALBUM, because then we get an enumerated list of people's pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another discussion. We have too many examples to ignore ALBUM. We also have too many examples to ignore FN. We are not discussing PODCASTs or other pet projects because we don't have enough data yet. However, the latest proposal would be able to markup both podcasts and collections. See above. If you still think it's wrong to use hAudio for both album and track, please explain why you think this should differ from hCard's model. because hCard doesn't have class=vcard for the root and class=vcard item again to specific all the people or orgs that it may contain. I think i agree with you, if i understand your model of the assumption being a track, with an explicit album name. I don't think i agree with having nested types of the same object... a TRACK that has an album, but actually then has multiple tracks inside it... to me that isn't ideal. I think there is a disconnect between what was proposed and how you interpreted it. We are not saying that you can have a track that has an album with multiple tracks inside of it - that is an abuse of the hAudio spec. Just like somebody specifying a review having to do with 6 items that are completely different from one another. Or #3, we could recognize that when the audio's name is the same as the album's name, the audio is an album, without requiring an explicit statement from publishers. This solution removes the main problem with both #1 and #2 above: unnecessary declaration of containers or items that may not even exist. You are assuming that the current proposal requires you to unnecessarily declare containers. It does not. vCard is ever ONLY about 1 object at a time, just like hAudio should be about 1 object at a time, (either a track or an album). Attempting to squeeze multiple things inside should either be out-of-scope or looked at later, we don;t have a format, yet we are attempting something no other microformat does. 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. We are already at later - we have solved the atomic recording problem for hAudio. We are now attempting to solve the recording with multiple parts problem for hAudio. Why is attempting to do something that no other microformat does a bad thing? It is true that no other Microformat does sections/collections/parts. I would argue that is so because no other Microformat has collections as an inherent part of it's structure... hAudio does. That's pretty much exactly what everyone's agreed to, except we're using album instead of collection. If you think this should change, please explain why. --- i don't really care what it is called, but if we choose ALBUM, then all the podcasters complain, if we choose ALBUM then all the people who release it in
Re: [uf-new] hAudio ITEM/TRACK debate resolution
Martin McEvoy wrote: Could It be done Like this? div class=haudio div class=item span class=type title=Release span class=fnBest Before 1984/span /span By: span class=contributorCrass/span /div div class=item span class=fnNagasaki Nightmare/span span class=duration4:46/span /div div class=item span class=fnBig A, Little A/span span class=duration6:13/span /div /div type titles can be Album, Release, Podcast, Chart, Toplist, even Episode and Track but would this be too restrictive? I think It may be a more flexible approach than having class names for all these properties. While I am a fan of doing it this way, it goes against one of the primary Microformat principles: No hidden data! This is one of the main things that separate the Microformats approach from the RDFa approach. hAudio in RDFa[1] would mark up the previous example like so: div about=#best-before-1984 instanceof=hmedia:Album span property=dc:titleBest Before 1984/span By: span property=dc:contributorCrass/span /div ... span about=#best-before-1984 rel=hmedia:contains resource=#nagasaki-nightmare div about=#nagasaki-nightmare instanceof=hmedia:Recording span property=dc:titleNagasaki Nightmare/span span property=hmedia:duration content=PT4M46S4:46/span /div /span ... span about=#best-before-1984 rel=hmedia:contains resource=#big-a-little-a div about=#big-a-little-a instanceof=hmedia:Recording span property=dc:titleBig A, Little A/span span property=dc:duration content=PT6M13S6:13/span /div /span Note that with the RDFa approach: - The type is explicitly stated using @instanceof. - There is slightly more hidden data with the RDFa approach. - RDFa is more verbose. - There is no need for nesting in RDFa to express containment. - Items can be related to one another without nesting in RDFa. So, while it is a good argument, Martin... it is an argument for RDFa, not an argument for the Microformats community. The closest we can get to specifying type in the Microformats community is by either: a) explicitly stating it, which we can't do with hAudio, or b) implicitly stating it, which is why we have ALBUM -- manu [1] http://wiki.digitalbazaar.com/en/HAudio_RDFa ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ITEM/TRACK debate resolution
Brian Suda wrote: I would also press for requiring ATLEAST an FN or ALBUM, not span class=haudioA string/span. We can discuss this in a later itteration as an optimization. That's fine... we can avoid talking about that for now since it will simplify the discussion. I recognize it as an optimization in your model. It is not an optimization in the item haudio approach, but we'll get there eventually. The main reason that was in there was to ease the burden on publishers. If somebody wants to be even more specific and mark up an audio recording that is a part of an album, they can do this: div class=haudio span class=fnA Sound Recording/span found in span class=albumAn Audio Album/span /div --- yes, that is fine. FN could be your display-name in something like Operator, but Album is the name of the title of the album. If you WANTED these could be the same class=fn album, but to me that doesn't make any semantic compound. Just that the display name happens to be the same string as the album. Just to be crystal clear, I think we agree... with one clarification. FN is not display name, FN is the formatted name of the audio recording. fn album doesn't make a semantic compound, I don't think anybody was saying that it did. Let's not say display name as it will lead to confusion. FN is the formatted name of the audio recording. Here are the rules we defined earlier this month, which have been updated to match the discussions over the past two weeks: # If only FN is specified, then the hAudio is a general audio recording. # If only ALBUM is specified, then the hAudio is an album. # If both ALBUM and FN is specified, then the hAudio is a song/track that is part of an album. # If ALBUM and one or more ITEMs are specified, the hAudio is an album containing tracks. Each track is assumed to be an hAudio, unless specified otherwise. None of the track properties should implicitly be added to the containing hAudio. In other words, the parser shouldn't parse the contents of the ITEM hAudio into the higher-level, non-track hAudio object. But as i understand, the ITEM could recursively be more audio-objects. Yes, in the item haudio proposal it can. It is assumed that item can contain anything that hAudio can contain, including more items. But instead haudio is attempting //haudio == track name We should probably stop using track name - it seems to be causing confusion. Use audio recording instead. We aren't as specific as a track using that markup all we know is that it is an audio recording... we don't know if it is an album and we don't know if it is a track, nor do we know if it is a podcast. We don't know anything other than it is an audio recording. --- i agree, i have been under the assumption that it would have been a TRACK name, but you are right it should be re-defined as just a string that describes the audio object, which is optional. Again, to be crystal clear - FN or ALBUM is required, it is not optional. If you can't name what you are talking about, you can't talk about it. This is very specific to hAudio - people refer to audio recordings by name... the examples prove that, thus it is not optional. //haudio/fn == track name We still only know the name of the audio recording, nothing else. It is definitely not a track at this point. --- ok, i can agree with this. So we do NOT know this is a TRACK, just an audio object with a title of some sorts? Yes, that is correct. If you don't disagree with any of the statements above, please explain why you believe nesting to be a bad design choice. It seems like that is the big disagreement, here. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio ITEM/TRACK debate resolution
This e-mail is a proposed resolution to the hAudio ITEM/TRACK debate. The list has seemed to have calmed down a bit, so I have gone back through and attempted to address each post's concerns about using either ITEM or TRACK. The proposed resolution is a mix of Martin, Scott, Andy, Julian, Michael, David, Tantek, Brian, and Ben's input. It is a solution that will hopefully work for everyone. GOALS: The primary goal is to create a mechanism for listing hAudio tracks within hAudio albums. The secondary goal is to create a mechanism that is expandable. We know we might want to support classical music, opera, parts of podcasts, top-lists and other forms of audio eventually, so the solution should not prevent this from happening. PROPOSAL: 1. HAUDIO can contain plain text to specify the FN property: span class=haudioSong Name/span 2. HAUDIO parts are denoted by ITEM+HAUDIO: span class=item haudioTrack Name/span EXAMPLES: Album with two tracks, simple example: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item haudioHokkaido Dream/span span class=item haudioTokyo Groove/span /span Album with two tracks, more detailed: span class=haudio span class=fn albumBest Before 1984/span span class=contributorCrass/span span class=item haudio span class=fnHokkaido Dream/span abbr class=duration title=PT3M24S3:24/abbr /span span class=item haudio span class=fnTokyo Groove/span abbr class=duration title=PT4M46S4:46/abbr /span /span REASONING: TRACK seems to be far too controversial of a name to use for the property. There seem to be people on both sides of the debate and rather than try and convince each other, let's re-frame the discussion to see if we can agree on something else. The proposal above gives us the following benefits: * Re-use of an existing Microformat property. * Not creating a new TRACK property (a Good Thing). * Pairing HAUDIO with ITEM solves the problem of ITEM being too generic and not specific (Andy and my primary problem with ITEM). * We are creating a number of short-hand markup approaches will allow publishers to write hAudio in a much easier way. * It enables marking up opera, classical music, and other singular recordings with movements, parts, sections, etc. * It allows the publisher to do infinite nesting (not that we have identified that as a need... but it also doesn't prevent it from happening, which is good). * We seem to have cracked the hSet/hBag/hContainer/item container problem. These are the drawbacks that have been identified for the following approach: * ITEM HAUDIO isn't as specific as TRACK. If there isn't much push-back for this approach, we should probably change the hAudio draft to reflect it and create an implementation in Operator to test it. Thoughts, comments, suggestions? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
Martin McEvoy wrote: The first thing I spotted was that someone seems to have spammed the word track 100's of times all over our model examples and results, making them as far as i can see unusable, Vandalized almost Martin, I wish you had said something before going and doing all that hard work (not that it wasn't useful). The site is not vandalized, I used those names when merging from the old, manual way of doing things to the new Microformalyze way of doing things. There was no data loss. There were numerous namespace collisions between the terms we were using to identify properties for albums and tracks. For example, we had used title to denote the name for albums and tracks... obviously, if we merged both records, we wouldn't be able to tell which one was the album title and which one was the track title... so I wrote a script to convert it to album title and track title. There is no foul play going on here... however, if you think there is, you're more than welcome to quadruple check the work (it has already been triple checked). Whether track or choon is used on the examples page, however, is of no consequence to the discussion. The names on the examples pages have almost nothing to do with the names that we pick for the actual proposal. When analyzing websites on any examples page, we must ensure that we use common property names when performing the analysis of the data. We need to perform apples-to-apples comparisons. In other words, if we say that websites A and B have PROPERTY_FOO, then we will use PROPERTY_FOO across analysis write-ups to denote if the websites do or do not have PROPERTY_FOO. I decided to use track because it was the most obvious choice (to me) at the time... however, that decision has no bearing on the current discussion. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
Martin McEvoy wrote: Im truthfully appaled that Our Model that we found all our debates on Is wildly inaccurate? It is not. :) I stand by the examples, the analysis and the research performed to date by myself and several others (including you, Martin). I also challenge you to prove its wild inaccuracy. Many people have looked at the data and helped to analyze it numerous times. All the data is there for the world to see. I Really dont think that we can have a clear Idea of what hAudio is Until our our examples are re-studied without the use of a program. Why do you think this approach is going to help us? That program, Microformalyze[1], merely is an application and a database that helps the user track the properties on each page. It can automatically calculate statistics and helped the process of analysis immensely. All of the analysis is still done by a human. There is no automatic anything in Microformalyze. Have you ever used the application? Once again, all of the source code is there as well as the data files. Feel free to go over them as many times as you want to... please report your findings back to the mailing list, I believe you will not be disappointed. -- manu [1] http://microformats.org/wiki/microformalyze-software ___ 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)
Michael Smethurst wrote: In these cases track would be plain wrong Also nested items/haudios would allow you to mark up classical works/opera (as opposed to perfomances/recordings). In the case of an opera: Haudio - opera haudio - act haudio - scene haudio - aria Or is this too much of a corner case? Marking up collections of live performances is outside of the scope of the current discussion. The current scope of the discussion (and of hAudio) is how to handle albums and tracks, specifically. That being said, with all of the known nuances in the examples and haudio proposals, you could do the above like so with the current ITEM+HAUDIO proposal (which uses mfo - any item haudio is opaque to the containing hAudio): div class=haudio - opera div class=item haudio - act div class=item haudio - scene div class=item haudio - aria TRACK+HAUDIO wouldn't make semantic sense above. The above example is, however, a bit contrived as I've never seen an opera described online and none of the examples have Opera in there. That is not to say that it doesn't exist... but it definitely isn't as mainstream as music blogs or music service websites. It is outside of the scope of this discussion, but the current ITEM+HAUDIO, TRACK and TRACK+HAUDIO proposals work for Opera markup. The semantics do make more sense with ITEM+HAUDIO, FWIW. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
Michael Smethurst wrote: 3 quick questions: 1. how would this work for a tracklist for a radio/tv programme. Like this?: span class=haudio span class=fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span span class=haudio span class=fnThe Classical/span span class=albumHex Enduction Hour/span span class=contributorThe Fall/span /span Keep in mind that live performances are outside of the current scope of discussion. Exactly like you've marked up above, OR: span class=haudio span class=fnName of Radio Program/Tracklist/span span class=item haudio span class=fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span span class=item haudio span class=fnThe Classical/span span class=albumHex Enduction Hour/span span class=contributorThe Fall/span /span /span Assuming that we drop the requirement for ALBUM to be mandatory if there are tracks. Your argument above is a good reason to drop the mandatory requirement. Or should the whole thing be wrapped in an haudio with haudio items? 2. how would it work for a live performance by a single artist span class=haudio span class=contributorThe Fall/span span class=itemThe Classical/span span class=itemFrenz/span span class=itemContainer Drivers/span /span You're missing the name of the performance, which is required, but other than that, the above would work. The argument is the same as above, but it is another reason to drop the mandatory requirement for ALBUM being specified. In which case should album be mandatory for a top level haudio with items? 3. can you have infinite nesting of item/haudios to handle the modelling of classical music? With the current proposal of ITEM+HAUDIO with mfo for sub-haudios, yes, you can. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
Ben Ward wrote: On 15 Oct 2007, at 10:44, Julian Stahnke wrote: album-title is NOT mandatory. It is only mandatory when you're listing one or more TRACKs. Tracks can be grouped by more than just albums. I'd say album-title should never be mandatory Playlists or charts come to my mind, for example. I'm very out of touch with hAudio development, but this touches on something I've not seen addressed lately. In the context of hAudio what is the difference between a ‘Playlist’ and an ‘Album’? How is an ‘Album’ not just a specialised kind of playlist? Most of the examples that were gathered for hAudio were from music service websites and music blogs. To help us make progress, this round of haudio focuses on just albums and tracks. We tried talking about playlists, podcasts, top-lists and others, but those were slowing the discussion down. There is a clear answer to how we support playlists, podcasts, and top-lists in the future... we add the property to haudio. haudio has been designed in such a way as to support that if it is ever needed. We can support playlists, podcasts and top-lists with the current ITEM+HAUDIO or ITEM+TRACK or TRACK+HAUDIO proposals, as long as we don't make ALBUM mandatory (which is the direction in which the discussion is going): span class=haudio span class=fnMy Playlist/span span class=item haudio span class=position1/span span class=fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span span class=item haudio span class=position2/span span class=fnThe Classical/span span class=albumHex Enduction Hour/span span class=contributorThe Fall/span /span /span However, that is beyond the scope of the current discussion, which is just albums and the contents of those albums (tracks). -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
Scott Reynen 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. We could also make the argument that there is no reason to restrict hAudio to two levels of nesting. There are no ill side-effects by not restricting it. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio duration syntax
Scott Reynen wrote: The complete representation of the expression for duration in the alternative format is as follows: Basic format: PMMDDThhmmss or PDDDThhmmss Extended format: P-MM-DDThh:mm:ss or P-DDDThh:mm:ss That section also includes several references to other sections defining date and time formats, including reduced accuracy formats (i.e. removing segments with values of zero). So I believe PT04:46 is a valid ISO 8601 duration. I still don't think it is, Scott. After reading through the spec, I am getting the impression that reduced accuracy means the trailing digits (the more accurate ones, such as seconds and minutes), not the leading digits (the less accurate ones, such as hour), can be avoided. To quote the spec (Section 4.4.3.2): For reduced accuracy or decimal representations of this representation, the following rules apply. a) If necessary for a particular application, the lowest order components may be omitted to represent duration with reduced accuracy. The following is ambiguous without a specific interpretation (which is included in the specification): PT04:46 Is that 4 hours and 46 minutes, or 4 minutes and 46 seconds? If I'm interpreting the spec correctly, it is the prior - 4 hours and 46 minutes. The following would be the correct use of ISO-8601 for the example you gave: PT00:04:46 or PT4M46S Martin McEvoy wrote: Duration Is not however expressed in seconds T268S unless you had something that was 0 minutes 46 seconds T46S I think you are correct Martin... apologies for the crappy markup. Clearly, I didn't understand the nuances of ISO-8601 until just recently :) -- manu ___ 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)
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. The meaning that you have understood was not the intent of that text... it needs to be clarified on the wiki. I was attempting to state that if you want to use multiple tracks in one hAudio, you should name the album. If you don't want to name the album single hAudios should be used, for example: div class=haudio span class=fn album contributorCelldweller/span contains span class=trackSwitchback/span and span class=trackSymbiont/span. /div We don't want people doing the following: div class=haudio span class=trackSwitchback/span and span class=trackSymbiont/span. /div The above should be marked up like this: Two songs that I like are div class=haudio span class=fnSwitchback/span /div div class=haudio and span class=fnSymbiont/span. /div -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio proposal: ITEM/TRACK
The problem: We need some sort of container to hold track/song information in an hAudio album. The contents of this container will be another hAudio chunk or text (which will be the FN of an hAudio object). There are two proposals that are on the table right now. The end result and semantics for hAudio are the same, the only thing that we are discussing is the name of that container. TRACK or ITEM Using TRACK means creating a new Microformat property that, while specific, is not re-using ITEM. There is also contention over whether this accurately describes a part of an album. Using ITEM means that we will be changing the current definition of ITEM: --- item - hReview - The item that the object exists for. For example, a review about Coca-Cola would list Coca-Cola as the item.[1] item info:: This required field MUST have at a minimum the name (fn - the formatted text corresponding to the name, except for an event item which MUST have the summary property inside the respective hCalendar vevent) of the item (an hReview describes only one item), SHOULD provide at least one URI (url) for the item, and MAY provide at least one URL to a photo or depiction (photo) of the item. For items of type person or business, the item info (fn, url, photo) MUST be encapsulated in an hCard. For items of type event, the item info SHOULD be encapsulated in an hCalendar vevent. Non-URL unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN (url) for the item. Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g. class=item vcard). However, when using item info subproperties (fn, url, photo), they MUST be nested inside the item element.[2] item info:: This required field MUST have at a minimum the name (fn - the formatted text corresponding to the name) of the item , SHOULD provide at least one URI (url) for the item, and MAY provide at least one URL to a photo or depiction (photo) of the item. For items of type person or business, the item info (fn, url, photo) SHOULD be encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN (url) for the item.[3] --- However, it seems that there is support from a number of people to re-use ITEM because it achieves two things (moves hAudio forward AND simultaneously creates a generic bag/hset/container concept for Microformats... something that we've been attempting to do for over a year. We don't want to break backwards compatability, so we have to work with the current definitions of item for hReview and hListing by defining ITEM as the following, which can be used across all Microformats: --- ITEM - A generic method that Microformats use for unordered containment of other Microformat properties or objects. This property MUST have, at a minimum, the name of the item. The name of the item can be specified using either: a) plain-text, if the property contains only the name of the item. b) fn, if the property contains multiple Microformat properties. ITEM MAY contain other properties/Microformats, but anything other than FN must be defined by the Microformat that is using ITEM. --- The above definition doesn't require hReview or hListing to change at all. It also means that we can use it like so in hAudio: 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=itemNagasaki Nightmare/span span class=itemHokkaido Dream/span span class=itemTokyo Groove/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=item haudiospan class=fnNagasaki Nightmare/span – abbr class=duration title=P268T4:46/abbr/span span class=item haudiospan class=fnNagasaki Nightmare/span – abbr class=duration title=P268T4:46/abbr/span span class=item haudiospan class=fnNagasaki Nightmare/span – abbr class=duration title=P268T4:46/abbr/span /span -- manu PS: Andy, Martin - I'm just as frustrated with this approach as I'm sure both of you are, especially since it was deemed that we couldn't change TITLE from hCard... but now we're changing
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
Justin Maxwell wrote: and i thought i was helping define a microformat, not practicing my skill in public debate. so, we're even. :) You must be new here. This is the New Microformats Community. We don't actually create Microformats, instead we endlessly debate the meaning of words and their implied semantics. Sometimes we argue with one another just for the hell of it. We are at our best on the weekends, when sane people are outside, enjoying their time off from work. :) If people refer to a songs or other recording as a track - as the evidence [1] shows they do - then we should use that. Andy, Martin, Justin, and everyone else that is asserting that TRACK has multiple, different meanings: You are all correct. TRACK has multiple definitions, nobody is arguing that it doesn't. ITEM is also not as semantically accurate as TRACK in hAudio. This thread has been identified as hAudio ISSUE #13 and has been recorded on the wiki. Please go and leave your feedback/preference for TRACK or ITEM if you have been involved in this conversation: http://microformats.org/wiki/audio-info-issues#Problem:_Container_property_naming -- manu ___ 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
Scott Reynen wrote: 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. 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... this is fantastic! Thank you for proving me wrong! :) I think this is our front-runner for replacing audio-title and album-title. Finally! It re-uses FN without being ambiguous about the difference between a single audio recording and an album. We simultaneously remove the need for audio-title. Does this also work for the Suda-nator (Brian Suda)? Martin, can you post some markup for the same 5 examples above using your proposal? We'll weigh the pros/cons for Scott's proposal and your proposal... I'm dropping my proposal in preference of Scott's. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Closing several hAudio issues
There are several hAudio issues that seem to have been resolved in the past several weeks that should be marked as Resolved. PROPOSAL: We close the following issues as each problem seems to have been addressed. hAudio ISSUE #1: image-summary Property is redundant - PHOTO has been used to replace image-summary in the latest proposal, reusing a previous Microformat property, which is a Good Thing(tm). - http://microformats.org/wiki/audio-info-proposal#Photo hAudio ISSUE #3: published-date Property is redundant - PUBLISHED has been used to replace published-date in the latest proposal, reusing a previous Microformat property, which is a Good Thing (tm). -http://microformats.org/wiki/audio-info-issues#published-date_Property hAudio ISSUE #6: Summary Property is Missing - DESCRIPTION has been added to the latest proposal. - http://microformats.org/wiki/audio-info-proposal#Description hAudio ISSUE #7: Track Number is Missing - POSITION has been added to the hAudio proposal, thus resolving this issue. - http://microformats.org/wiki/audio-info-proposal#Position hAudio ISSUE #8: hAlbum is redundant - We now have the ALBUM-TITLE and TRACK elements in hAudio, there is no longer a need for hAlbum. - http://microformats.org/wiki/audio-info-proposal#Schema hAudio ISSUE #12: CONTRIBUTOR and TRACK are not publisher friendly - Short forms for CONTRIBUTOR and TRACK are proposed in the newest proposal and doesn't seem to cause any parsing problems or compatibility issues with other Microformats. - http://microformats.org/wiki/audio-info-proposal#Contributor - http://microformats.org/wiki/audio-info-proposal#Track If there are no objections, I would like to mark each as a Resolved Issue -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Closing several hAudio issues
Julian Stahnke wrote: Martin McEvoy wrote: I think the proposition should simply say * hAudio MAY have zero or more tracks * Track titles MAY be defined by using the class name *audio-title* it is recommended that a hAudio track SHOULD have an audio-title * This would enable Greater flexibility when publishing hAudio. as long as audio-title is present in the haudio element, it would be a track. This is correct... as long as audio-title is present in the hAudio element, it is semantically indistinguishable from a track. The processing rules have been updated to make this more clear: http://microformats.org/wiki/audio-info-proposal#More_Semantic_Equivalents If only album-title was present, it would be an album. If both audio-title and album-title were present, it would be a single track from an album. Also correct. The benefit with the current hAudio proposal is that you don't need to specify TRACK to identify the hAudio as a singular item... all you have to do is specify AUDIO-TITLE. It's easier on publishers because there is less HTML to write (you don't have to specify TRACK for individual recordings). To address your other concern, Martin, we might not have to specify track haudio. Instead, we could have: 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. Perhaps others that have been involved with Microformats for longer than I have been can point out the benefits or drawbacks of such an approach. Here are the ones that I can see: Pros: * Less mark-up for publishers. * Less confusing? Cons: * The type must be assumed from the parent container type. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio: audio-title/album-title vs. recording/album
One of the last remaining (and most pedantic) issues for hAudio is the naming of the audio-title and album-title properties. This includes the following issues (we could close them all if we can finally decide on these two names): hAudio ISSUE #2: audio-title Property http://microformats.org/wiki/audio-info-issues#audio-title_Property hAudio ISSUE #9: album-title Property http://microformats.org/wiki/audio-info-issues#album-title_Property hAudio ISSUE #10: Collection Names http://microformats.org/wiki/audio-info-issues#Collection_Names The primary issue that I have with audio-title and album-title is that they are not orthogonal in the programming language sense: http://www.lrdev.com/lr/frequently-asked-questions.html#programming-language-orthogonality audio-title is the title of a singular/atomic audio expression. It is a rather general term used to identify a singular work. album-title is the title of an audio album. It is a specific term used to identify a collection of singular works that are in an album/track format. To add to the complexity of the semantics behind these two terms, they not only denote the title, but the type of the hAudio as well. The question is: Can we make these terms more orthogonal to publishers. Can we choose terms that denote both title and type. The first attempt was to name them something like the following: recording-title and album-title The use of -title seemed a bit redundant, so it was dropped to form: recording and album Speaking and reading the words in context makes sense: hAudio recording hAudio album whereas speaking and reading what we have currently doesn't really make sense: hAudio audio-title (specifies the recording title AND the hAudio type) hAudio album-title (specifies the album title AND the hAudio type) There is also only one example to back-up using the *-title pattern in Microformats, that being ENTRY-TITLE in hAtom. There are, however, loads of examples of taking the other approach, which is using nouns to denote title (type): author (Person), item (Thing), label (Identifier), locality (Place), logo (Image), note (Text), photo (Image), summary (Text), region (Place), reviewer (Person), sound (Sound), and title (Text) are a handful of examples of nouns being used to denote title and type. The best that we've been able to do has been RECORDING and ALBUM. Any suggestions on addressing these issues? -- manu PS: Keep in mind that RECORDING can be re-used in hVideo. ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
Julian Stahnke wrote: If you want to push your proposal above, you will have to make the following arguments: 1. Why Ambiguity is not an issue for TRACK. 2. Why we should introduce a new property called TRACK-TITLE. 3. Why we should require CONTRIBUTOR to be marked up via a VCARD. About tracks inside hAudio/hVideo: What about assuming that the track has the same media type as its parent element unless declared otherwise? That is a rule that we could certainly enforce via the parser... and it would reduce the markup that a publisher would have to do. Just to add a bit of implementation detail to your proposal: An hAudio parser would then assume that the contents of TRACK is an hAudio object if it is inside of an hAudio container. This means that any uF markup inside of TRACK could be any of the properties of hAudio. hAudio parsers, when seeing TRACK would create another hAudio object and stuff the properties found in TRACK into the newly created hAudio object for the TRACK. Scott Reynen 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. I was attempting to think ahead to hVideo, but it seems to be causing more confusion than helping. Scott's right... we should concentrate on hAudio. Okay. If that’s the case, then I don’t see why ‘track’ could not be just plain text? We could easily give publishers both options without complicating the parser that greatly. Both of the examples below would be proper uses of hAudio: div class=haudio h3 class=albummy album title/h3 by strong class=contributorthe artist/strong ol li class=trackmy track title/li li class=trackmy track title/li li class=trackmy track title/li /ol /div div class=haudio h3 class=album3 live bands at my local venue/h3 by strong class=contributorvarious artists/strong ol li class=track span class=recordingfirst track title/a by span class=contributorfirst artist/span /li li class=track span class=recordingsecond track title/a by span class=contributorsecond artist/span /li li class=track span class=recordingthird track title/a by span class=contributorthird artist/span /li /ol /div Even though the tracks aren’t marked up as hAudio element and hence have no ‘position’ attribute, should ‘position’ be implied by the position of the track in the ol? My thoughts are that it should be... but with the ability to override the li numbering scheme. What happens if somebody only wants to list 3 of the items in the album... song 3, 5, and 8? It should also be noted that the POSITION and DESCRIPTION concepts are disputed additions to the proposal. I still need to go back through and re-analyze the examples to prove that there is enough evidence in the examples to add POSITION and DESCRIPTION to hAudio. 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. It also seems that RECORDING (was audio-title) is a disputed name change, per Martin. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio position and description properties
Most of the day today was spent re-analyzing all of the music service and podcast websites in audio-info-examples using Microformalyze. The raw analysis data is available here: http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files The analysis is available here: http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts The new analysis shows very strong support for POSITION. This property is displayed in 70.73% of 41 music service websites analyzed and 100% of the 8 podcast websites analyzed. There is also enough support to meet the 80/20 rule for DESCRIPTION. This property is displayed in 39.02% of 41 music service websites analyzed and 100% of the 8 podcast websites analyzed. PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since there are enough examples to warrant their inclusion into the Microformat. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Measurement brainstorming
Chris Newell wrote: Note that I said or whatever is [the] standard for representing square-metres. I'm not sure there is a standard for representing the superscripts used within SI units using plain text. We may have to specify something. These are all good discussions, but I'm afraid that the second we get into We might have to specify something, we're going to get into philosophical debates about how we represent prefixes, units and the combinations thereof... thereby killing the discussion :) In an attempt to avoid those philosophical debates, let's build on the work of great people. Namely, the ISO and SI standards of measurement used by the international community. I have put up Straw Man 2 on the wiki in an attempt to outline basic markup that hmeasure could support: http://microformats.org/wiki/measure-brainstorming#Straw_man_2 The Strawman includes the following new concepts: - The proposal only uses abbr to avoid the but the parsers are going to be so complicated! argument. Let's focus on what we can represent using abbr - what we can support in span will naturally come out of that discussion. - This is a first cut and is missing things like measurements for cups, feet, etc. - SI-prefixes should be used when applicable. - It attempts to simplify and focus the discussion on abbr -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Measurement brainstorming
Chris Newell wrote: The Strawman includes the following new concepts: - The proposal only uses abbr to avoid the but the parsers are going to be so complicated! argument. Let's focus on what we can represent using abbr - what we can support in span will naturally come out of that discussion. - This is a first cut and is missing things like measurements for cups, feet, etc. - SI-prefixes should be used when applicable. - It attempts to simplify and focus the discussion on abbr Looks good. Chris, just to clarify - those were my suggestions, not Andy's. I don't know if Andy agrees with this approach or not. If he does, then that's great... but I don't want to put any words into his mouth. :) We could also reference http://en.wikipedia.org/wiki/SI_derived_unit and http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI which expand the number of units in a controlled way. I have included the SI derived units and the Non-SI accepted units. Even so, these references don't provide a suitable unit for bit-rate so I'd like to add bit as a supported unit, for use with the other entities you've defined e.g. kbit/s. I have also added 'bit' under Units Defined by Microformats.org. Changes can be found here: http://microformats.org/wiki/measure-brainstorming#Supported_Derived_SI_Units http://microformats.org/wiki/measure-brainstorming#Supported_Non-SI_Units http://microformats.org/wiki/measure-brainstorming#Units_Defined_by_Microformats.org -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
Martin McEvoy wrote: On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote: So this simpler proposal makes perfect sense to me. at least someone on the list Is starting to make sense. Criticize the ideas, not the people, please. :) I have been wrestling with the current proposal of hAudio since Manu made his announcement [1] And frankly the current proposal is starting to make less and less sense to me, With each different proposal the concept of hAudio gets more and more vague. and honestly I dont like it at all the way hAudio stands now. What happened to keep it Simple, and *Meaningful*? We are attempting to keep it simple... remember, if we don't have ALBUM and TRACK - we have to have the hAlbum Microformat. hAlbum is an order of magnitude more complicated than what is currently being proposed. What part of the mark-up isn't meaningful to you? Please be very explicit as I'm having a hard time following what part of the hAudio specification you don't like. Preface your statements with This concerns hAudio ISSUE #N... So let Keep it simple eh? PROPOSAL: div class=haudio span class=audio-titleAlbum Title/span span class=contributor vcard[...]Artist[...]/span div class=track1 span class=track-titleTrack One/span [...] /div div class=track2 span class=track-titleTrack Two/span [...] /div /div Notice no need to Reiterate hAudio over and over again, hAudio only=20 needs to be declared *ONCE* because the entire contents *ARE* hAudio Please take a bit more time to outline your objection more clearly. Which one of the hAudio ISSUES is this about? http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables I'm guessing that you don't like the fact that you must define both TRACK and HAUDIO? The reason that we're doing this is because we might want to re-use TRACK (or whatever we end up calling it) in hVideo. Content has sections: Albums have Tracks Television Series have Episodes DVDs have Chapters Books have Chapters We could end up re-using TRACK to describe DVDs like so: div class=hvideo ... span class=dvdThe Matrix/span ... span class=track hvideoChapter 27: The Lobby/span ... span class=track haudioChinese Audio Track/span ... /div If we don't specify hvideo for the video track and haudio for the audio track, how would the parser determine the difference? We would have ambiguity, which is one of the reasons all of the other Microformats do this as well. If you want to push your proposal above, you will have to make the following arguments: 1. Why Ambiguity is not an issue for TRACK. 2. Why we should introduce a new property called TRACK-TITLE. 3. Why we should require CONTRIBUTOR to be marked up via a VCARD. I feel the more we bloat hAudio with *not* well thought of semantic class names such as *Album* (a container class or object not a title) ALBUM is not a container class, it defines two things: - the name of an audio album - the type of the hAudio The examples require us to have something like this, so is your opposition to it's name... or the concept that we need something to denote the name and type of an hAudio? and *Podcast* (which is also a container class and not a title) the less PODCAST will probably not make it in unless somebody other than me starts supporting it. Let me point out that we have plenty of podcast examples: http://microformats.org/wiki/audio-info-examples#Music_Podcasting I'd like hAudio to be completed sooner than later and if PODCAST is going to cause push-back, then I'd much rather drop it and move on... even though we have a number of examples to support putting podcast in hAudio. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)
Julian Stahnke wrote: I’d like to point out that the currently proposed spec (http://microformats.org/wiki/audio-info-proposal#Complete_Album_Examplet) of nesting an haudio element in a track element to mark up albums is incompatible with using tables for the track listings. In a table, you only have one element per track that wraps all the information (the table row). So both track and haudio would need to be the same element. Julian, you are absolutely, 100% correct! Crap! :) We hadn't considered the limitations of HTML tables, thanks for catching that rather glaring problem with the new hAudio proposal. I have a feeling that the following proposed solution is going to ruffle a few feathers, but it seems to be the simplest way to address the problem - make the hAudio parser do the heavy lifting. 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. EXAMPLE: table trth#/ththTrack/ththLength/th/tr tr class=track haudio td1./td td class=recordingSanity/td tdabbr class=duration title=P348S5:48/abbr/td /tr tr class=track haudio td2./td td class=recordingHighway To Hell/td tdabbr class=duration title=P219S3:39/abbr/td /tr /table 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 remember there being opposition to placing properties (TRACK) and types (HAUDIO) together in the same CLASS attribute, but can't remember what the logic was behind the argument. If there is no opposition to this approach, we could adopt it and make the parser do the hard work. Thoughts? Below is a more complete, validated XHTML 1.0 document demonstrating the fix. You can copy and paste it into the following URL to verify that it is a valid XHTML 1.0 document: http://validator.w3.org/#validate_by_input -- manu -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en head titlehAudio Table Example/title /head body pThis is an example of an hAudio in a table:/p div class=haudio img class=photo alt=Live Phish Album Image src=images/live_phish_vol_15.jpg / p span class=albumLive Phish, Volume 15/span span class=contributor span class=vcard span class=fn orgPhish/span /span /span /p p Released on: abbr class=published title=20023110October 31, 2002/abbr /p p Acquire: a rel=sample href=/samples/live_phish_vol_15_sample.mp3Sample/a, a rel=enclosure href=/live/phish_live_phish_vol_15.mp3Live Recording/a, a rel=payment href=/buy/phish_live_phish_vol_15Buy High Quality Track/a /p p Category: span class=categorylive/span /p p Duration: abbr class=duration title=P8727S145 minutes, 27 seconds/abbr /p p Price: span class=money abbr class=currency title=USD$/abbr span class=amount14.99/span /span /p p Tracks: /p table trth#/ththTrack/ththLength/th/tr tr class=track haudio td1./td td class=recordingSanity/td tdabbr class=duration title=P348S5:48/abbr/td /tr tr class=track haudio td2./td td class=recordingHighway To Hell/td tdabbr class=duration title=P219S3:39/abbr/td /tr /table /div /body /html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/table incompatibility
Scott Reynen wrote: 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? Yes, I agree. We are talking about a track that *is* audio. Based on that suggestion, perhaps we can change the rules for processing TRACK to be even more publisher-friendly. PROPOSAL: TRACK can be either plain text or marked up using HAUDIO. This approach would make the following markup valid: div class=haudio ... span class=albumAlbum Title/span ... span class=trackSong Name/span ... /div the following would also be valid: div class=haudio ... table trth#/ththTrack/ththLength/th/tr tr class=track haudio td1./td td class=recordingSanity/td tdabbr class=duration title=P348S5:48/abbr/td /tr tr class=haudio track td2./td td class=recordingHighway To Hell/td tdabbr class=duration title=P219S3:39/abbr/td /tr /table ... /div These issues have been noted in hAudio ISSUE #11 and ISSUE #12: http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly 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? It shouldn't work differently from hCalendar, and I agree again. We should bring hAudio more in line with hCalendar. Do the following two examples work for everybody? This would be valid: span class=contributor vcard span class=fn orgPhish/span /span and so would this: span class=contributorPhish/span This has been noted in hAudio ISSUE #12: http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
Martin McEvoy wrote: ...listening to div class=haudio div class=item span class=media-titleMay the Rain/span /div found on span class=haudio-titlePaper Tigers/span /div by... *Item* works here as a root class on its own and is used as a semantic finger pointing out the interesting or important parts... Sorry Martin, I missed this e-mail for some reason until just now. I agree with you in concept, we need /something/ to point out that one haudio is a part of another haudio (containers and items in those containers). We are, however, barred from using 'item' because it was previously defined as this in hReview and we can't change it's definition: item info. required. fn (url || photo ) | hCard (for person or business) | hCalendar (for event) That means that we cannot put an hAudio in ITEM. Got any other suggestions? The best we've been able to come up with thus far has been TRACK or SECTION. I am also suggesting parts that can be reused in other media related uF's, item and media-title. Again, I agree with you in principle... it's just a matter of word choice. We can re-use TRACK in CDs, albums, and possibly DVDs. However, we can't do that in movies, podcasts, or other container formats. That is why I suggested that we use SECTION instead of TRACK. We can use SECTION in CDs, albums, movies, television episodes, podcasts and other container formats. hItem technically I would say already exists as a uF on its own wouldn't you? Nope, I wouldn't go that far. ITEM does exist, but it already has pre-defined semantics that, while we would like to change, attempting to do so in the past has been disastrous[1]. What about using SECTION instead of TRACK? It could be used in hVideo and hAudio. SECTION makes sense for albums, podcasts, clips, television, movies... but doesn't really work for charts or playlists. ...how do you summarise section? You could use the proposed DESCRIPTION element, if it is approved and if there is enough evidence for it. http://microformats.org/wiki/audio-info-proposal#Description -- manu [1]http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
Scott Reynen 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? Here is the premise: It is important to be able to differentiate between types of audio collections. At least three different types of audio are backed up by the audio-info-examples: audio recordings, audio albums and audio podcasts. Here are our goals: - Eliminate hAlbum, but support its functionality in hAudio. - Add as little as possible to hAudio to support audio collections. This thread has been split into three issues: hAudio ISSUE #8: http://microformats.org/wiki/audio-info-issues#Problem:_hAlbum_is_redundant hAudio ISSUE #9: http://microformats.org/wiki/audio-info-issues#album-title_Property hAudio ISSUE #10: http://microformats.org/wiki/audio-info-issues#Collection_Names We should continue to talk about ISSUE #8 in this thread. ISSUE #9 and ISSUE #10 are in regard to what we call these new classes. What we name these new classes should be in a different thread of conversation and should happen after we decide what to do with hAlbum. Issue 9 and 10 become rather easy decisions if we decide not to go forward with the proposed solution to issue 8. How would a hypothetical application treat two documents differently if they were otherwise identical, but one said album-title and the other podcast-title? Here are the parsing rules. I will use the existing hAudio terms (audio-title, album-title) in an attempt to not confuse this issue with issue #9 or issue #10: * If only 'album-title' is specified, then the hAudio is an album. * If only 'audio-title' is specified, then the hAudio is a song/speech or other singular work. * If both 'album-title' and 'audio-title' is specified, then the hAudio is a song that is part of an album. * If 'album-title' and one or more 'track's are specified, the hAudio is an album containing tracks. Each track is an hAudio. None of the track properties should be added to the hAudio album. In other words, the parser shouldn't parse the contents of the TRACK hAudio into the non-track hAudio object, TRACK operates similarly to the 'mfo' proposal[1]. The issue is that of semantics. None of the examples explicitly state this is an album or this is a track, however, they implicitly state this fact. This is the reason putting a TYPE class into hAudio doesn't make sense. Only a few of the examples ever explicitly state that they're talking about an album, a single recording or a podcast. It is implied by the context in the page. Since Microformats do not allow hidden data, we can't propose the use of TYPE - there is no text on the page to mark up even if we did use TYPE. Thus, in order to get the concept of an album, a single audio recording, or a track across we must figure out a clever way to imply these semantics without having the publisher explicitly state this is an album in their HTML. The current proposal is an attempt to imply the type of the hAudio without requiring the publisher to put album in their HTML. For software, it is important to know the semantic difference between an audio recording, an album, and a podcast. For example - it could determine which search service you use to find more information about the recording, album or podcast. On Bitmunk, our REST XML Web API allows one to specify whether the title that you're sending it is an album, or a song. The results you get back can be heavily dependent on the type of media that you're sending it. Another use case is for the Operator plug-in. How you display an album, a podcast, and a single song to a user could (and probably would) use a slightly different UI layout. It is not enough just to call something an audio object and be done with it. The type of audio object has a great deal of semantic meaning to human beings, and that is what we're trying to encapsulate with this proposal. 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? Not, it has not and it should not... it seems that I've done a bad job of explaining that. :) By bringing up podcast-title and toplist-title, I was attempting to outline how we would go about naming these other types of hAudio. I was attempting to demonstrate that this naming mechanism and approach scales well. We don't end up with a Microformat for each type, we just end up with the lesser of two evils, one more class in hAudio. At the very least, we're talking about adding the following to hAudio: album-title track Does that help clarify hAudio ISSUE #8? -- manu [1] http://microformats.org/wiki/mfo ___ microformats-new mailing
Re: [uf-new] The Process
Frances Berriman wrote: On 12/09/2007, Manu Sporny [EMAIL PROTECTED] wrote: I think we should call it what it is: The Accepted Limitations of Microformats Yeah, that would work. I have created the wiki page, everyone please feel free to note issues and add other sections on the page: http://microformats.org/wiki/accepted-limitations-of-microformats -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
Michael Smethurst wrote: Can I suggest release instead of album? It just captures albums, singles, eps better... Your idea has been noted on the wiki, Michael: http://microformats.org/wiki/audio-info-issues#album-title_Property I'm somewhat opposed to changing 'release' to 'album-title' at the moment. album-title is more inline with where we're going with hAudio, hVideo and the media-info discussion in general. However, you've mentioned something that could be re-used quite heavily between all of the media Microformats. I think it makes a great deal of sense and it wouldn't take much to convince me to drop album-title in favor of 'release' if you can answer the following: What do we use for 'podcast-title', 'toplist-title', and other collection names? Andy made a good point before, the names should be simple and narrow in definition. I think right now, we're leaning towards 'album', 'podcast', and 'toplist' as the collection class names. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] video-info-examples page clarifications
Mary Hodder wrote: Appreciate the clarifications. Very helpful. I will get one of my engineers to run some queries, to see what percentages we have across 27 mil videos and then post them here and in the wiki. Make sure to ask them to not duplicate data sources. Don't analyze 400 URLs from the same site. Instead, analyze 400 URLS from different sites. Make sure that they generate a machine-readable data file (tab delimited, comma separated, or XML) and that you can show that data file to the Microformats community. We need hard, demonstrable numbers so nobody can assert that the data is not legitimate. More importantly, we need to be able to verify any findings and prove their existence to others in the community. Also, regarding terminology, i think having as close to real meaningful terms as possible is best. Agreed. For example, I'd suggest date published and date released because at least they are clear and require no explanation. Thanks for the suggestions, I'll update all the Microformalyze data files tonight or tomorrow and upload your suggested changes to the wiki. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
Martin McEvoy wrote: I vote we use something more generic and call audio-title, album-title or in fact any media related title just media-title, you can re-use it for albums, podcasts, toplists, downloads, charts, video, images. Martin, If we do that, we will lose the ability to differentiate between an album, podcast, toplist, download, and chart. These are differentiations that we need to make because of the examples discovered thus far. By using something like podcast or album we not only define the type of the hAudio, but the collection property as well. We address two issues (how do we specify hAudio type, and how do we specify hAudio collections) with one class name. -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Launching the hVideo exploratory discussion!
Mary Hodder wrote: Is the video microformat use case one that is about video hosters or about what users do, or both? Both... we're going for general video metadata markup. :) At Dabble, as we take in metadata from both sources, we see users and hosters publishing titles, thumbnail (users don't call it image summary and actually, the hosters don't either much), category AND tags, uploader, director or creator, license, description, duration, sometimes size, and almost always, urls for html page, with some people giving multiple download and streaming urls. Just to be clear, those names are property names... they are not the official Microformat class name that we are going to use in hVideo. It is too early to decide on a vocabulary yet... expect most of those names to change (re-used from other Microformats if possible, created if there is no other choice). We do, however, define what every one of those property names mean on the video-info-examples page: http://microformats.org/wiki/video-info-examples#Properties In fact there is almost always a permalink url (how did you come up with 58% on that one?) The Permalink URLs are for sites that explicitly state a Permalink URL on the page. Believe it or not, only 58% of the examples had permalinks. I was surprised as well, but it shows us why we collect examples. because no one would be able to get to it if that didn't exist. What we never see is published (what does that mean?) or email video url in a feed or api.. All definitions of property names are listed on the video-info-examples page: http://microformats.org/wiki/video-info-examples#Properties published - The Published Date specifies the date that a video file was made available to the public. Examples include: The airing date of a video podcast, the air date of a television show, or the release date of a movie. sometimes that's on a page and often buried in flash or dhtml .. but it wouldn't be very helpful, as it's actually the same as the html url usually with extra code for email. If the data is in the DOM somewhere, we included the property. If the data doesn't reside in the DOM, then we did not include the property. Also most individual users never publish popularity rating or number of views etc. Got a list of examples that we could merge into the video-info-examples page? That would be very helpful... I thought the point of the microformat was for users and publishing companies to be able to put out data that would be easily readable in both an RSS feed and via spidering an html page, that was commonly published online? It is! Most users are publishing video via MySpace, Yahoo Video, Google Video and YouTube... service websites. However, if you have another subculture that we should examine, please give us some links so that we may analyze those sites as well. I think the basic set of commonly published items includes: title html url (sometimes same and sometimes different from the url to embed, or link directly to the video) video url (if existing - could be multiple, see Blip or Revver or soon to be Youtube) category and / or tags description license creator or uploader or both (many youtube videos have both, with director as the creator designation) embed code size duration We see these all elements highly published. We need your examples, then! :) Also, the sense I get from your write up here: http://microformats.org/wiki/video-info-examples is that you are more interested in the use-case of microformats for selling video or other content. Nope... in fact, what we're finding is that most of the video sites do not sell content! Bummer, as we were hoping we'd find that they do... :) but since we can't find many examples of this happening, it nullifies the idea that this is a use-case for selling video or other content. Thanks for the input Mary, always appreciated :). Do these statements help clarify matters? -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
