Re: [uf-discuss] added hReview-aggregate and rel-author as drafts, archived a few others, uf2 for new ufs
On 08/03/2012 08:32 PM, Tantek Çelik wrote: 2. Archived drafts/spec In addition, I created a new section Archived (Ben Ward's suggestion) to collect microformats that haven't really taken off, that is appear to lack any major publishing/consuming support and have moved the following there: http://microformats.org/wiki/#Archived * hAudio What constitutes haven't really taken off? Since when do we have a timeframe for taking off? Where are these definitions and time-frames documented on the site? I couldn't find it. Wikipedia is currently marking up over 119,555 songs and albums with hAudio markup - why is that not enough? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: Which is better - RDFa Lite or Microdata? http://manu.sporny.org/2012/mythical-differences/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Google announces Microformats/RDFa support!
The subject line says it all - Google just announced support for various Microformats and RDFa! Here's the Google FAQ page on structured data: http://google.com/support/webmasters/bin/answer.py?hl=enanswer=99170 Here's the announcement on the RDFa mailing list: http://lists.w3.org/Archives/Public/public-rdfa/2009May/0011.html Congrats to everyone in the community and everyone that has helped create a Microformat! -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: A Collaborative Distribution Model for Music http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Bioformats - microformats for biology
André Luís wrote: http://bioformats.org/ Why is this being developed outside of this community? Possibly because they don't quite understand how the Microformats Process works. I know our first impression was that we didn't need to perform any sort of centralized development through the Microformats community. We believed that Microformats could be developed by anybody on the web and there was no stamp of approval necessary to call what you were doing a Microformat. At first blush, it wasn't clear that there was a process behind what this community does... Has anyone heard of this before and/or have contacted the founders of this project? I've notified them of this thread. Bottom line is.. should we care about this? Yes, we should. They have demonstrated buy-in to the semantic web at some level, interest in Microformats, the ability to do some work and publish in a way that is open, and they're backed by an institute - which means that probably have more time and interest than most to work on this stuff. Try to invite them to join the community and discuss the pros and cons of their proposals? Or just leave them be? It would be a mistake to not invite them to join and let them decide if this community is the best avenue forward. We shouldn't assume what the interests of this community are - this mailing list has over 1,000 readers and all you really need is 2-3 highly motivated individuals to push some of these initiatives forward. -- 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-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Bioformats - microformats for biology
li...@ben-ward.co.uk wrote: This community very intentionally doesn't try create specifications for everything. Previous pure-science efforts such as species died because it fell way outside the area of active interest of most of this community's participants. I don't think that's the defining reason (Andy's banning, as Toby stated, is probably the primary reason that the species uF is currently not under development). While I do agree that it's important that this community is careful about what it works on, we shouldn't be exclusive and we shouldn't assume that we know where certain community members want to focus their attention. If a couple of people want to come into the Microformats community to develop their vocabularies, we shouldn't say that there isn't a place for them. I, for one, would be interested to see how a bioformats discussion would evolve *ba-dum-bum* =P. We're talking about the bits and pieces that make us who we are! Allowing us to identify and process that information could help us better understand how we're connected to each other as a species. That seems like a fairly noble endeavor. Ever played around with 23andme.com[1]? Being able to mark up your personal genome on 23andme and have the browser cross-link against SNPedia[2] automatically would be really awesome. In short, we could help them work through some of the more subtle language and vocabulary issues while helping an initiative that could very well benefit the human condition. The discussion may come to nothing, but let's give it a chance before shutting it down prematurely. -- manu [1] https://www.23andme.com/about/ [1] http://www.snpedia.com/index.php/SNPedia -- 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-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hProduct draft now available
Myers, Jay wrote: After several months of diligent work, I'm happy to announce the draft spec of the hProduct microformat, linked from the front page of the wiki. I look forward to your constructive feedback in order to better the format for eventual adoption. Hi Jay, Glad to see that you have decided to take the lead on moving the hProduct uf forward :) I haven't been following the hProduct discussion that closely and this was really the first time I took a look at the draft. I'd like to draw your attention to a particular Microformat Process issue that you may or may not know about... As per the process, we have included appropriate wiki pages for issues, faqs and examples. The hProduct examples page[1], including all example pages that it links to[2][3], include around 11 example sites, with no mention to the number of sites that were analyzed. One of the first steps that should be completed before a Draft is proposed is extensive analysis of existing websites providing products. To put hProduct's 11 examples into perspective, hAudio had close to 84 examples for the online music store section alone. If you have the analysis data that led to the current version of hProduct, please put it on the wiki. We can't know if the vocabulary terms are a good choice unless we have the data to back up the draft. For example, here's the analysis of terms utilized in audio sites: http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services Is there an equivalent for hProduct? If not, is there a full set of analysis data that backs up the vocabulary generated for hProduct? -- manu [1]http://microformats.org/wiki/hproduct-examples [2]http://microformats.org/wiki/product-examples [3]http://microformats.org/wiki/hlisting-extended-examples [4]http://microformats.org/wiki/audio-info-examples -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: POSIX Threads Don't Scale Past 100K Concurrent Web Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 blog: Fibers are the Future: Scaling Past 100K Concurrent Requests http://blog.digitalbazaar.com/2008/10/21/scaling-webservices-part-2 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Announcing Oomph: A Microformats Toolkit
On Wed, Oct 22, 2008 at 10:46 AM, Karsten Januszewski [EMAIL PROTECTED] wrote: Greetings - I'm excited to announce the release of Oomph: A Microformat Toolkit, which just went live at http://visitmix.com/lab/oomph. Great stuff, Karsten! Looking forward to seeing where this goes... what are the next steps, if you're allowed to elaborate? Where are you putting your efforts for the next 3-6 months regarding Oomph? Supporting more Microformats? Doing more stuff like Ubiquity[1]? What are the future goals for Oomph? -- manu [1] http://labs.mozilla.com/2008/08/introducing-ubiquity/ -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: POSIX Threads Kill: Scaling Past 100K Concurrent Web Requests http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1 blog: Fibers are the Future: Scaling Past 100K Concurrent Web Requests http://blog.digitalbazaar.com/2008/10/21/scaling-webservices-part-2 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] How about adding aRecipe, an RDFa serialization of hRecipe?
Thomas Loertsch wrote: I'm not sure that an RDFa serialization is something that needs endorsement or hosting by microformats.org. Once hRecipe is formalised, RDF/RDFa-based work that uses the hRecipe vocabulary needs no input from microformats.org. The syntax for the RDFa is derived simply from the RDF/OWL model - there's nothing there that needs deciding on. There are still things that can go wrong - you confirm that below when you propose to draft a mapping and post that as N3-Draft on the web to solicit comments. My question is if microformats wouldn't be a good place to do just that. It's the question if we need another site, another organisation to develop vocabularies and/or serializations in a community-process or if, at least if a proposal with a microformats-syntax is already active, can add a RDFa-serialization project to it? Clearly stating the RDFa equivalent of Microformat markup would be beneficial to website authors. This would also halt duplication of work in both the Microformats and RDFa communities and thus would be something that is beneficial to the semantics community at large. We don't want other communities duplicating work done in this community. I'd like to point out that hAudio has gone through this already and it would be really nice if we could clearly state what the RDFa equivalent of hAudio is without having to host the RDFa vocabulary elsewhere. What would be even better is a unified syntax for expressing both Microformats and RDFa, as described here: http://rdfa.info/wiki/RDFa_Vocabularies#Creating_a_document_that_uses_microformat_terms_via_RDFa If the preceding proposal were pushed forward and adopted, it would mean that any Microformats vocabulary would automatically be RDFa-izable and that we would have a unified syntax for expressing both RDFa and Microformats. Food for thought. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Today, Tomorrow, and Someday Problems
Martin McEvoy wrote: http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html Thanks Manu for an interesting post, I have made some comments ;-) I am a bit worried about Shane's other post Shane wrote: Unlike microformats, the idiom for annotating your content does not conflict with the normal semantics of (X)HTML (e.g., the class attribute, the title attribute, and abbr). Sound's like a declaration of war from a community who wants to bring Microformats to the fold. I've been working with Shane to get this Microformats expression using RDFa mechanism operational. I can assure you that his statements are absolutely not any sort of declaration of war. Please refrain from using loaded language - it mis-characterizes and over-dramatizes his post. We're not talking about a terrible conflict involving loss of life. We're talking about a difference in opinion regarding web semantics expression - it's really geeky stuff. :) Shane has spent the most amount of time out of all of us in the RDFa and Microformats communities writing up our thoughts on Microformats expression using RDFa: http://rdfa.info/wiki/RDFa_Vocabularies He wouldn't be doing that if he wanted to harm this community in any way. We're trying to bring the two communities together - not push them apart. Why would you want to use RDFa? For the same reason you want to use microformats. Because you care about machines understanding what is on your page, not just humans. Is it not the other way around in the microformats community? As Sarven stated, the RDFa community and the Microformats community goals are the same - to enable widespread use of semantics in web documents. While the paths that both communities have taken are different, the destination is the same. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Today, Tomorrow, and Someday Problems
Tantek Celik wrote: eventually decided that it was time that someone started to experiment with the broad semantic HTML *today* work being done by modern web designers, solving today's real world web problems, with shared vocabularies based on existing standards. I met up with Kevin Marks who had similar ideas and microformats was started. That being said, I owe a great debt to this community and the people that started it and continue to contribute, including you and the other uF founders, because it is here that I first saw that the semantic web was achievable in the near term. With over a 1,900 directly involved in this community, it is clear that the idea behind Microformats is something that resonates with us! The issue I had was with the execution of Microformats - most notably, the process and the parsing rules. It was only after hAudio ground to a halt (the second time) due to the many arguments revolving around the decision to not use TITLE, pseudo-namespacing, scoping, accessibility, etc., that I followed up with the W3C as I became increasingly frustrated with the process. Our start-up had a problem to solve (mark-up of audio on web pages) and we wanted to do it right, through a standards body of some kind, instead of forcing our view on the world. We were determined to start an initiative to make the W3C take semantics in HTML more seriously. To our surprise, we found the RDFa Task Force who were doing just that. That was years ago (2003-2004). In the meantime, microformats adoption has taken off much faster than any of us could have hoped for, while XHTML2 is largely ignored. XHTML2 wasn't a tomorrow technology 5 years ago [1], and it still isn't today. You could say there may be some bitterness/resentment/jealousy/denial about that. I joined the W3C as someone who was bitter about many of the standards that had passed the process. The nastiest scar that we held was a system-wide implementation of SOAP as our messaging protocol only to find out that the entire protocol was horrifically over-engineered. It came from the W3C, it must be good, we thought. Similarly, we had issues with HTML 4.01 and a variety of other W3C technologies throughout the late 1990s and early 2000s. I don't take a strong position on XHTML2 or HTML5 because I have learned enough to know that there are too many people that want too many things out of both technologies to say that either standard is good or bad, or solving today/tomorrow/someday problems. Everybody has different priorities and depending on one technology to solve all of our problems is never the answer. It's going to be a mix (HTML5, XHTML2, Javascript, Microformats, RDFa, etc.) like it has always been on the web. Anyway, I'm largely ignoring it, as I'm trying to do my best to ignore the microformats vs RDFa baiting / artificial-dichotomy that so many have pursued. We have too much productive work to do to be distracted by such drama. Agreed. There is too much work to be done and that getting involved in the perceived drama is distracting. When I hear someone talk about the drama between XHTML2 and HTML5, or Microformats and RDFa, it is usually in the form of false perceptions that one community has about the other. This is interesting because it breaks down into two categories: - People that think there is drama due to false perceptions on the positions that the other community holds. The RDFa community is waging war on the Microformats community - I read about it in a blog post, or The Microformats community thinks RDFa is just a repeat of RDF/XML. - People that have been burned by one community or the other in the past, usually during a design argument, which clouds their desire to work with the community ever again. So rather than actual drama, we have perceived drama because the communities aren't talking. We are letting false perceptions or negative experiences that we have had in the past cloud our ability to work with each other. This isn't directed at you, Tantek, as I know you strive to make your reasoning and thinking as fair and logical as possible. It's directed more at the general community (both RDFa and Microformats). There are a number of very good thinkers in each community and it is a shame that they continue to be separated because of false perceptions and clouded judgement. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Today, Tomorrow, and Someday Problems
Interesting blog post by Shane McCarron of XHTML2 fame. He has been involved in the standards community since 1985. His name is on just about every major HTML standard to come out of the W3C - if you use HTML 4.01, XHTML1.0, XHTML 1.1, or will use XHTML2 (to name a few), you're using specs that he had a direct hand in creating or maintaining. It's interesting to see his take on how the W3C and the Microformats community fits into the ecosystem of solving the problems of today, tomorrow and someday. The post discusses Microformats and RDFa: http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force
Ben Ward wrote: It will take a couple of weeks to give examples of how this will all work, but I wanted to get feedback from this community before proceeding. We have a fantastic opportunity in front of us now - who in this community thinks that we should work with the W3C on this endeavor? I'm not sure I completely see the benefit in this, and seeing your examples would be very helpful in getting a better idea of what you're proposing. I'll get a set of examples written up soon, then. From your bullet points, it seems to suggest taking microformat vocabularies and expressing them in RDFa, rather than HTML? It seems redundant for publishers. No, the markup would still happen in HTML, using Microformat properties, but instead of using @class, we MAY (not MUST) use @typeof, @property, and @content (in the case of machine-readable data) to express Microformats. The key being that these attributes are specifically designed to contain semantic data. Here's a brief example showing how we could get rid of the ABBR design problem by re-using RDFa's @content attribute. Note that this would work in HTML 4.01, XHTML1.1 and XHTML2: div typeof=haudio span property=titleStart Wearing Purple/span by span property=contributorGogol Bordello/span span property=published content=20020514May 14th, 2002/span /div However, I do have a somewhat related issue that you might consider part of this effort. Some discussions I've had lately revealed usefulness in being able to _map_ microformats into RDF, for the purpose of combining microformats with other RDF vocabularies in a back-end somewhere (so, conversion for processing, rather than publishing. Publishing remains in HTML where it is most effective). Publishing would stay in HTML, where it is most effective. Nobody is suggesting that it move elsewhere - RDFa follows the same principles as Microformats in this case. As for the mapping between uF/RDF Vocabularies, I started a page to do just that back in October 2007: http://wiki.digitalbazaar.com/en/Mapping-ufs-to-rdfa Want me to move it to Microformats.org? I'm told that RDF ‘versions’ of vcard and icalendar are out of date compared to the microformats. I don't think they are, but could be mistaken... The last update to VCARD was on 22 February 2001: http://www.w3.org/TR/vcard-rdf and the vocabulary: http://www.w3.org/2001/vcard-rdf/3.0# The last update to iCalendar was on 29 September 2005 http://www.w3.org/TR/rdfcal/ and the vocabulary: http://www.w3.org/2002/12/cal# As such, it strikes me that rather than maintaining duplicate specifications, it would instead make sense to develop a set of standard transformations so that any microformat can be transformed from HTML to RDF, without requiring duplicate effort to maintain another spec. This I'm sure would relate closely to GRDDL, since that already deals with transformation. Yes, agreed, that would be useful. Note, I'm talking about mapping rules, not separate specs. For example, we have the ‘jCard’ page on the wiki, which I still feel should be more generic ‘JSON Mapping Rules’ page that can cover parsing from any format, not just hcard. We're also working on that in our company, but internally for now. There is the issue of a generic object representation format for semantic data objects. We have a generalized RDF-based representation for RDFa and Microformats now... but didn't think this community would be interested in such a solution. Should a wiki-page be started on various JSON Mapping Rules between uF/RDFa to JSON? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Potential for Microformats.org to work with W3C andRDFa Task Force
Tantek Celik wrote: Completely agreed w all of Ben Ward's points. Even the ones that seem to state that RDFa does not operate in the realm of HTML? The reason I raise this point is that RDFa will be a W3C standard, applicable to XHTML1.1 and XHTML2 by the end of October 2008 (roughly). We're in the process of working out a HTML4+RDFa DTD and validator for HTML 4.01 as well. This will cover all current HTML family languages, so stating that RDFa is outside of HTML will only be accurate until the end of October 2008. After that, RDFa will be a part of all deployed HTML family languages. In addition - I would be very concerned that the microformats principles would be compromised by any such efforts as Manu suggests, and efficiency of parsing/parsers and other points listed are not worth compromising the principles. Nobody is suggesting that anybody compromise their principles. What I'm suggesting is that we may have figured out a way to bring a unified semantic data processing mechanism to RDFa and the Microformats community, across all current HTML family languages, without changing either community's approach to semantic data markup. If we're correct, it means a great deal of progress will have been made in both communities - all I'm asking for is that we cooperate with the W3C, are given the chance to do the work, and to see what falls out. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force
Scott Reynen wrote: That, or we'd compromise RDFa. I can almost guarantee that neither side is going to compromise their set of beliefs. The Microformats community is too hard headed to do so, and the RDFa community has a very long, arduous W3C process to consider when changing anything major in the RDFa specification. As the two efforts have somewhat divergent priorities, I don't see how we could combine them without compromising on one side or both. Let's give it a shot, give it a number of months, and see if either side feels like they're compromising on anything. I believe that approach is better than saying that it's impossible, throwing up our hands and giving up before we've even started. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] HTML5+RDFa discussion on WHATWG involves Microformats
Samuel Santos has started blogging about the HTML5 + RDFa/Microformats discussion that we've been having in WHATWG: http://www.samaxes.com/2008/08/29/the-semantic-web-and-rdfa/ -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML5, Microformats and RDFa
Scott Reynen wrote: I think comparing RDFa to microformats actually hurts your argument by suggesting they solve the same problem and reinforcing the notion that the wider problem RDFa seeks to solve is unimportant. Rather, I would interpret the mentions of microformats as an indication that people are missing the wider problem RDFa would solve, and focus on making that clearer, by talking about what RDFa does that microformats don't even attempt to do. Scott, Ben - thanks for the feedback, both of you make some very good points and I've adjusted my argumentation a bit to follow advice expressed by both of you. Things are being clarified in some ways on the HTML5 list and muddied in others. The one thing that is clear is that most of those on the list are not as up-to-speed with web semantics as either this community or the RDFa community would expect. Certainly, I was a bit blind-sided by some of the false assertions those on the list were making about semantics in general. The very long thread continues, RDFa Problem Statement and Features http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015957.html Intro to RDFa http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015974.html RDFa markup consistency http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015992.html CSS-based approach to semantic data on the Web (Microformats and RDFa) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015996.html Of particular note is the last thread - the CSS-based approach to semantic data markup. It's a proposal that, while interesting, ignores the hard work that this community and the RDFa community has done over the past several years. I could be mis-reading the various threads, so some feedback from this list would be appreciated. -- 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-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Potential for Microformats.org to work with W3C and RDFa Task Force
Hi uFers, RDFa is going to become an official W3C standard in the next 2-3 months. Martin McEvoy had posted something about two weeks ago on the RDFa mailing list stating that he'd like to use RDFa to express Microformats: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Aug/0081.html At first, I dismissed it as something this community would not be interested in, and even if they were, something that the RDFa community wouldn't be interested in doing. Shame on me for assuming without checking with both communities first! Over the past week, I've been thinking about some of the stuff Mark Birbeck (who started the RDFa initiative) said several months ago and what Martin re-iterated in his e-mail two weeks ago: There should be a way to provide Microformats-like markup using RDFa. Afterall, it would solve the unified parser/markup issue that some (both inside and outside this community) have with Microformats. So, I drew together a very quick proposal before the RDFa Task Force meeting this morning: It is possible to use RDFa attributes to replace/enhance usage of the @class attribute and the ABBR design pattern in Microformats. We should be able to do so without introducing the concept of namespaces to the author that is marking up content - keeping the simplicity of Microformats authoring intact. Doing so would provide a unified model of semantics expression between RDFa and Microformats. It would also provide one unified parser that could parse both namespaced RDFa and non-namespaced Microformats. Here's a link to the discussion: http://www.w3.org/2008/08/28-rdfa-minutes.html#item03 The group was very enthusiastic - they would like to work with the Microformats community to address some of these long standing issues in our community. If we are successful in this endeavor, it would mean: - 9 additional parsers that could parse Microformats. - A unified parsing model in addition to the ad-hoc one provided by Microformats. - A full test suite for the unified parsing model. - A unified method of Microformats and RDFa expression in HTML4, XHTML1.1, and XHTML2. - A painless upgrade path from Microformats to RDFa if the author so desired. - A solution to the ABBR accessibility problem. - A solution to the Microformats containment problem (class=item). - A solution to the mfo problem. - A unified method of semantics expression for the web. It will take a couple of weeks to give examples of how this will all work, but I wanted to get feedback from this community before proceeding. We have a fantastic opportunity in front of us now - who in this community thinks that we should work with the W3C on this endeavor? -- 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-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] HTML5, Microformats and RDFa
André Luís wrote: Manu, the css based approach is somethin that has come up in discussions about semantics with fellow workers. I believe it does not trash all of the hard work the communities have don so far. I never said the discussions trashed all of our hard work. I said that some of the discussions ignore (some) of the hard work performed by this community as well as the RDFa community. All it does, from what i gathered, is move the semantics from html and places it in a separate file/place. Right - which both this community and the RDFa community are opposed to: 1. We do not want semantics to be placed in separate files. 2. We do not want vocabularies to be re-defined from site to site. 3. We want semantic markup to be easy to author for regular people - CSS is /not/ easy to author. That's what I was attempting to point out with my statement. Apologies if I was not clear :) -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] HTML5, Microformats and RDFa
There have been several threads discussing Microformats, RDFa and HTML5 that are occurring on the WHATWG mailing list. The discussion relates to whether or not HTML5 should depend on the Microformats community to solve HTML5's semantic markup issues, or if both Microformats and RDFa should be considered for semantic web markup issues. The start of the discussion is here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015860.html and continues here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015875.html I have authored a blog reply, stating that HTML5 should not depend on the Microformats community to develop all semantic web vocabularies, the reasoning can be viewed here: http://blog.digitalbazaar.com/2008/08/23/html5-rdfa-and-microformats/ and my first response to the WHATWG mailing list http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015949.html Things start getting dicey here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015892.html and here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015950.html and my second response to the WHATWG mailing list, outlining some of the shortcomings of Microformats and stating what differentiates RDFa in it's approach: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015957.html Posting to this list because there are many on here that would be interested in the WHATWG's current position on web semantics: not important enough to consider as part of the HTML language. Note that the XHTML1.1 and XHTML2 workgroups have already accepted the position that: web semantics are important and a standard method of semantics expression is necessary for the future development of the web. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Mozilla Labs Aurora mock-up depends on RDFa/uF-like technology
Mozilla Labs announced a pretty cool new browser concept dubbed Aurora. It's pretty flashy and integrates some experimental UI concepts that are questionable. However, one of the fundamental, underlying principles of the browser is the concept of data portability. The idea that you own your data and can pipe, mix and match data from different websites was key to the browsing/collaboration experience. I caught myself thinking You'd use RDFa/uF to do that... and that... and that throughout each video. Here are the direct links to Vimeo WebHD content: Aurora - Part 1 - Collaboration, History, Data Objects, Basic Navigation http://www.vimeo.com/1450211 Aurora - Part 2 - Geo-location-based browsing http://www.vimeo.com/1476338 Aurora - Part 3 - Integrating Web w/ Physical Environment (also, sexism) http://www.vimeo.com/1481810 (non-WebHD) Aurora - Part 4 - Personal Data Portability (bonuses: copious diversity and the liberal agenda) http://www.vimeo.com/1488633 -- 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-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Audio/Video RDF Vocabulary Screencasts
Hi uFers, Based on work that was done in this community over a year ago, we've attempted to do a port of hAudio over to the RDFa world. The result is a set of 4 vocabularies for media, audio, video and commerce. We used a number of Microformats principles when porting the vocabularies and re-using pre-existing vocabulary terms. We re-use Dublin Core heavily. The vocabularies can be found here: http://purl.org/media/ http://purl.org/media/audio http://purl.org/media/video http://purl.org/commerce A small plugin, named Fuzzbot, has been put together to explore semantic web UI approaches and two demos are now up regarding the audio and video vocabularies: Intro to Fuzzbot and Audio Vocabulary http://www.youtube.com/watch?v=oPWNgZ4peuI Intro to Video Vocabulary http://www.youtube.com/watch?v=PVGD9HQloDI The intros are very rough, done in 1-2 takes, but hopefully they get the concept across. The next steps are going to be an attempt to use Firefox 3's Microformats functionality to pull uF metadata into Fuzzbot's RDFa triple store. Downloads and source for librdfa and Fuzzbot can be found here: http://rdfa.digitalbazaar.com/fuzzbot The Linux version is the only one that is up-to-date. I'll compile the Mac OS X and Windows versions when I get the time to do so. Feel free to comment/discuss the videos on here. We're looking for feedback on what would make the demos more enticing. Right now, it's just you can use metadata to construct more accurate searches. -- manu PS: I also mis-spoke at one point in the first video and said that before Fuzzbot it wasn't possible to do this sort of thing, which is not correct 'cause Operator has been around for a much longer time. Apologies to Mike Kaply, since he started blazing this trail some time ago. :) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats and RDFa not as far apart as previously thought
There have been some interesting blog posts by people at the BBC, Mozilla and W3C about Microformats and RDFa in the past two days. The first covers BBC's decision to drop support for the abbr-based design pattern written by Michael Smethurst (who worked with this community on hAudio among other things): Removing abbr-based Microformats from BBC http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml The second is a response from John Resig, of jQuery/Mozilla fame, here: BBC Removing Microformat Support http://ejohn.org/blog/bbc-removing-microformat-support/ The third is written by Mark Birbeck, who is the guy that proposed RDFa several years ago and is the primary one behind the processing rules and architecture for RDFa: Microformats and RDFa are not as far apart as people think http://internet-apps.blogspot.com/2008/06/microformats-and-rdfa-are-not-as-far.html We've had discussions that parallel the ones above last summer: http://microformats.org/discuss/mail/microformats-new/2007-July/000592.html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010850.html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010859.html http://microformats.org/discuss/mail/microformats-discuss/2007-October/010879.html I tend to agree with Edd Dumbill's post: http://times.usefulinc.com/2008/06/24-uf-rdfa Some are moving too quickly to dismiss both Microformats AND RDFa - the two communities are cross-pollinating and there has been significant lessons learned from both approaches. If you're going to blog about this or discuss it - please don't fuel the Microformats vs. RDFa fire by picking sides... it's detrimental to both communities. Like Edd stated in his post, we have a bug that we need to fix (abbr design pattern causing screen reader usability issues) and that has been hanging over our heads for some time now. BBC's decision is a lesson learned but is in no way some sort of sign that Microformats is on it's way out. Thoughts from the community? Anybody else blogging about this? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Blacksburg BarCamp 1.0 http://blog.digitalbazaar.com/2008/05/15/blacksburg-barcamp-10/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Practical Web Semantics - Talk at Rackspace
Hi all, I ended up giving a Tech Talk at Rackspace at the end of April on Practical Web Semantics. This included discussions concerning basic semantics, Microformats, RDFa, and demos including Operator and Fuzzbot. The overview page is here: http://wiki.digitalbazaar.com/en/practical-web-semantics Here are quick links to each section: Practical Web Semantics Part 1 of 4: Introduction to Digital Bazaar http://wiki.digitalbazaar.com/talks/practical-web-semantics/part1.html Practical Web Semantics Part 2 of 4: Basic Semantics and Microformats http://wiki.digitalbazaar.com/talks/practical-web-semantics/part2.html Practical Web Semantics Part 3 of 4: RDFa Concepts http://wiki.digitalbazaar.com/talks/practical-web-semantics/part3.html Practical Web Semantics Part 4 of 4: Demos and Questions http://wiki.digitalbazaar.com/talks/practical-web-semantics/part4.html -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Dynamic Spectrum Auctions and Digital Marketplaces http://blog.digitalbazaar.com/2008/04/24/dynamic-spectrum-auctions/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] My inactivity
Ben Ward wrote: Just a little note to explain that my µf tasks: hListing, ABBR-pattern, ‘This Week’ posts are on hold at the moment as I made a rather unexpected trip into hospital this week. No need to worry; after five days I've been released again (my appendix had gone rotten and has been removed). However, I'll be resting for most of this week Sorry to hear about your trip to the hospital. Hope all is going better and that you have a quick and speedy recovery. I'd be happy to put together a This Week blog post, who should I send it to? You, Tantek, or somebody else? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Dynamic Spectrum Auctions and Digital Marketplaces http://blog.digitalbazaar.com/2008/04/24/dynamic-spectrum-auctions/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Digg Rolls Out DataPortability Enhancements
Surprised the semantic story du jour hasn't been posted to this list yet. Congrats to the XFN, and hCard folks :) http://blog.digg.com/?p=120 PS: Steve Williams is a good guy - he really does care about this stuff. Digg Rolls Out DataPortability Enhancements by Steve Williams at 12pm, May 1st, 2008 in Digg Website Hey all, The Data Sharing Summit in San Francisco was a gas. It was a real pleasure to work with like-minded people from organizations, large and small, all supporting DataPortability. At the Summit I had the chance to show off Digg’s latest DataPortability enhancements. Although the enhancements are not visible on Digg.com, if you use Digg together with other social networks, these enhancements can make the Web more fun and useful. Among the recent enhancements: - We’ve added XFN to your user profile. XFN is an open standard that makes it easier for other social Web sites to recognize your Digg friends. - We’ve improved support for hCard, another open data format for communicating Digg user names, nicknames, and photos, so that your favorite friend-following tools can more easily display your friends’ activity. - We’ve added RDFa, making Digg part of the “semantic web” where Web pages become more sophisticated, beyond simply words and pictures. These efforts support our philosophy that you own your data. Thanks, sbw -- -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Fuzzbot - An embedded semantic data viewer
Fuzzbot is designed to detect RDFa and other semantic data formats and display them to the person browsing. RDFa is a way to embed machine-readable data into web pages, which helps computers help you interact with web pages in a smarter way. For example, Fuzzbot can show you information about people that it has found on a web page - helping you view only the data in which you're interested. The goal of Fuzzbot is to integrate Microformats and RDFa into a common format (JSON/RDF) which authors can then write Actions and UIs against. What this means is that Fuzzbot will deal with higher-level semantic concepts (People, Places, Events, Audio, Video, etc.), rather than formats (hCard, FOAF, etc.). Fuzzbot is primarily a test bed for UI concepts and is not a replacement for Operator - ideally, some of what we learn from Fuzzbot could be integrated into Operator. http://rdfa.digitalbazaar.com/fuzzbot/ Screenshots are available here, for those that don't want to install the plugin: http://rdfa.digitalbazaar.com/fuzzbot#screenshots Some of you might note that the primary UI concept behind Fuzzbot is based on Dmitri Glazkov's Margin Marks concept[1] that he posted to this mailing list about 3-4 months ago. It is a visual approach to displaying semantic data. The current release (v0.7.5) is a very preliminary version of the software. There will be UI bugs and perhaps some operational bugs (For example, parsing Digg.com is very slow). Firefox XPIs are available for both Linux and Windows, here: http://rdfa.digitalbazaar.com/fuzzbot/download/ All librdfa source code is released under LGPL v3, and the Fuzzbot plugin is released under the Mozilla Public License. Source code is available via GIT: git clone http://rdfa.digitalbazaar.com/fuzzbot.git git clone http://rdfa.digitalbazaar.com/librdfa.git If you have any thoughts or questions on the direction of this project, or where you'd like to see it headed, please discuss on the list and we'll try to work it into the project plan. -- manu PS: We're also looking into creating a native C library to do Microformats parsing, but wanted to make sure there wasn't anybody that had already done this. Is there anybody on here that has created a native C library for parsing Microformats? [1] http://glazkov.com/blog/margin-marks/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Unjust banning of Andy Mabbett
Drew McLellan wrote: The simple fact is that the microformats community is *not* a lot of work, save for the disruption Andy has caused. That we even seen to spend effort having this conversation rather than working on microformats is further evidence of that disruption. Drew, We are spending effort having this conversation because governance is vital to the health of this community. Talking about the method employed to execute this ban is certainly not a waste of time. Talking about contributions of community members is certainly not a waste of time, either. If nobody had a problem with the admins' decision, you would have seen my initial e-mail and silence thereafter. However, there have been a number of people that have voiced a similar concern. To date, 10 people have voiced concern about the length of Andy's ban and the methods used to ban him. That is a clear indicator that there is a disconnect between the admins and the community. This isn't just about Andy - it is also about the methods employed by the admins to come to this decision: - Lack of a documented process for bans. - Lack of proper documentation leading up to Andy's ban. - A vote count for the admins (for and against). At the very least, if we don't have a process in place, we should follow Wikipedia's ban procedure[2]. To place the blame of this disruption squarely on Andy's shoulders is to ignore the fact that the admins are the ones that brought about the 18 month ban. It also ignores the fact that proper due diligence was not performed before the ban. This would be happening if it were Andy, or anybody else on this list. We are spending the effort to have this conversation because we don't like what we're seeing. Just to be clear, here's what the expectations are: - The admins reply to each point in the initial e-mail that started this thread[1] - The admins create a procedure for banning individuals from the Microformats community. - The admins fully document Andy's ban, similar in scope to Wikipedia[2] If you want to focus on making this community run smoother, focus on those things and the next time something like this happens, we won't have to re-hash this discussion. -- manu [1]http://microformats.org/discuss/mail/microformats-discuss/2008-March/011713.html [2]http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Pigsonthewing -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: RDFa Basics (video) http://blog.digitalbazaar.com/2008/01/07/rdfa-basics ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Request for Microformats.org MediaWiki SQL data
This is a request for the Microformats.org MediaWiki MySQL database data. If one of the admins could do a mysqldump of the database (or selected tables) and place it onto a public HTTP/FTP site, that would be ideal. WARNING: Do not dump the password or e-mail field for the user table. I'd like to run an analysis on the number of contributions made by everyone involved in this community and attempt to write an algorithm to detect edit wars. This request is two-fold: 1. I'm curious to see who the most prolific wiki contributors are and if they have any correlation with the most prolific mailing list contributors. 2. It would be good to have an automatic process that could detect and log wiki edit wars, thus reducing the load on the admins and the rest of the community. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: RDFa Basics (video) http://blog.digitalbazaar.com/2008/01/07/rdfa-basics ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Unjust banning of Andy Mabbett
I just got back from vacation, otherwise this would have gone out sooner. It has come to my attention that Andy Mabbett has been banned by the admins for 18 months[1]. This is an unjust punishment, especially considering that he is one of the largest contributors to our community. Rather than make sweeping assertions and accusations, I'm going to back this post up with hard data. Here are the statements that will be addressed: - Andy is one of our most prolific contributors, this community will be harmed by such a long-term ban. - An 18 month ban does not fit Andy's behavior - it is an unjust punishment. - Andy was tried as guilty, without complete documentation. - Andy pushes the limits in this community, and because of him, we know what is and is not acceptable in this community. - Andy says what some of the rest of us are thinking, and he shouldn't be banned for such an extreme length of time for voicing his opinion. Andy is one of our most prolific contributors - Maybe most of you are unaware of Andy's contributions to this community. I took the time to write a script to download and analyze the entire history on Microformats.org's mailing lists (the script is attached to this e-mail). Here are the top contributors to the microformats-discuss mailing list: andy mabbett - 1133 posts - 9.68% of contributions ryan king - 885 posts - 7.56% of contributions tantek celik - 833 posts - 7.11% of contributions scott reynen - 504 posts - 4.30% of contributions brian suda - 467 posts - 3.99% of contributions david janes - 432 posts - 3.69% of contributions chris messina - 388 posts - 3.31% of contributions charles krempeaux - 233 posts - 1.99% of contributions mike schinkel - 193 posts - 1.65% of contributions dr. ernie prabhakar - 188 posts - 1.61% of contributions danny ayers - 171 posts - 1.46% of contributions kevin marks - 145 posts - 1.24% of contributions ciaran mcnulty - 135 posts - 1.15% of contributions frances berriman - 134 posts - 1.14% of contributions ben ward - 126 posts - 1.08% of contributions bruce d'arcus - 120 posts - 1.02% of contributions paul wilkins - 119 posts - 1.02% of contributions dimitri glazkov - 110 posts - 0.94% of contributions benjamin west - 107 posts - 0.91% of contributions Here are the top-10 contributors to the microformats-new mailing list: manu sporny - 298 posts - 19.13% of contributions martin mcevoy - 238 posts - 15.28% of contributions andy mabbett - 182 posts - 11.68% of contributions scott reynen - 148 posts - 9.50% of contributions brian suda - 62 posts - 3.98% of contributions tantek celik - 37 posts - 2.37% of contributions david janes - 36 posts - 2.31% of contributions guillaume lebleu - 27 posts - 1.73% of contributions frances berriman - 26 posts - 1.67% of contributions julian stahnke - 20 posts - 1.28% of contributions It is quite evident from this data that Andy has produced more than anyone else in this community, even assuming that 10% of the threads that he starts result in a ban on his account. I know of no other community that would treat one of their primary contributors in this manner. An 18 month ban doesn't fit Andy's behavior --- Banning somebody for 18 months is quite a serious amount of time, and while the admins might not have come to the decision lightly, I do question whether the punishment is justified. If you look at the documented rules that were added/changed due to Andy[2], you will note that a whopping 13 of the 17 are EDITORIAL rules. The other 4 are behavioral rules that Andy has broken in the past (as have several others on the mailing list). I am not defending bad behavior, just noting that part of the reason that Andy is being banned is due to these EDITORIAL rules that he has broken and I don't think that an 18 month ban is justified for breaking editorial rules. His behavior as of late has been much calmer and more respectful, so I see no reason why this ban has appeared, seemingly out of the blue, at this time. Andy was tried as guilty, without complete documentation There is still no documentation as to what Andy has done in the past to warrant this type of ban. In the admin's post to the list, the following was mentioned: As time permits, the admins will both hyperlink each of those annotations to the specific email in the archives or edit in the wiki history that caused it, as well as annotate any remaining rules with their causes as well. We believe this will help provide better transparency and accountability. The time to generate transparency and accountability is BEFORE a ban, not after. This is why people are tried
Re: [uf-discuss] Unjust banning of Andy Mabbett
Derrick, I'd like to address each of your statements as they seem to be assuming things that were not said in the post to the mailing list. Derrick Lyndon Pallas wrote: 1.) Quantity != Quality. (Maybe Web 2.0 decided otherwise, but I'm old school.) The argument that quantity == quality was never made. A set of data points were given noting Andy at the top of the lists. It would be quite daft to make an argument stating that quantity == quality. The point I was making was that one can't look at those numbers and write off Andy Mabbett's contributions to this community any more than they can write off Ryan King, Tantek, Scott Reynen, Brian Suda and David Janes's contributions. They have all had a large impact on this community. 2.) No one person is worth more than the cohesiveness of a community in the case of community development. Agreed. Nobody is arguing against that point. I fail to see how Andy Mabbett has single-handedly caused the cohesiveness of this community to be greatly diminished. If anything, I would fault the way these issues have been handled for causing harm to the cohesiveness of this community. Namely, lack of administrative transparency and undocumented banning of this community's members. Andy's not completely innocent, nor are the admins without fault. 3.) Andy != Gandhi. Overthrowing the rule of a foreign power is unrelated to anything that happens in the microformats community or as part of the process. Furthermore, it is a mistake to conflate pushing the limits of the microformats process and its community with pushing the limits of the purpose of the community or of civility. Ha! You are correct. Andy certainly isn't Gandhi. Far from it. Andy is no saint - he has his flaws, as do we all. Note that I am going to no trouble to argue against the prior 1-2 month bans that have been imposed on Andy. Those bans were short enough to not strike a nerve, even if they were not well documented. On the other hand, an 18 month ban raises several red flags. Andy's incivility has been primarily directed at the admins and has been focused on how they process administrative issues. He asks very important questions about how this community governs itself. He is often ignored by the admins, which results in heated arguments further resulting in a 1-2 month ban. We would like to believe that we are all equals here, that ideas are more important than the person behind the idea, and that the rules apply equally to all of us. Andy points out every occurrence of when the principles above are broken, especially when one of the admins are the ones that break the rules, and has thus gained the ire of the admins and some of the community. 4.) In August, Andy will no longer be banned from Wikipedia so at least he'll have something to do. Q.v. http://tinyurl.com/25y6y8 It is a shame that you so easily toss aside his many contributions to this community. I hope you didn't mean to be as snide as the language in the statement above conveys. The link to the Wikipedia ban is helpful, though. It is what I would have expected to see prior to Andy's 18 month ban. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: RDFa Basics in 8 minutes (video) http://blog.digitalbazaar.com/2008/01/07/rdfa-basics/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Major change to microformat specs without prior discussion or notification
Thom Shannon wrote: perhaps there was prior discussion and agreement that was just a long time ago? Have you searched the archives or asked Tantek directly? Here's the IRC log regarding the change to the wiki: http://rbach.priv.at/Microformats/IRC/2008-02-07#T010220 I agree with the change - I don't agree with not running it past the microformats-new list. It seems like a fairly far-reaching change/update. It invalidates the need for mfo in hcard, doesn't it? If it were applied to the rest of Microformats, it would invalidate the need for mfo entirely. There are logs - so it would be wrong to say the decision was made in private, it was done on IRC, without notification to microformats-new. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Robert O'Rourke wrote: Ah yes, so would you say 'performer', 'creator' and 'composer' are roles and not different to being a contributor? Yes, that is why 'contributor' was picked, rather than 'performer', 'creator', or 'composer'. :) It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. You can always specify multiple 'role's in hCard to state that the person had more than one role. I know you had a problem with it but if the role 'artist' is vague in so far as 'performer', 'composer' etc.. are concerned then perhaps it would be useful for exactly that reason. What do you think? I've got no problem adding more contributor types as convenience classes for composer, performer, publisher, label, etc. However, like all things Microformats - they've got to be backed up by examples. The issue isn't wouldn't these be really cool to have, but rather we need to demonstrate that there are enough of these on the web to justify adding more terms to hAudio. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. You can always specify multiple 'role's in hCard to state that the person had more than one role. One cannot always specify such things, because the page content (e.g. Beethoven's Fifth) does not always spell out such terms. Right, point taken. I know you had a problem with it but if the role 'artist' is vague in so far as 'performer', 'composer' etc.. are concerned then perhaps it would be useful for exactly that reason. What do you think? I've got no problem adding more contributor types as convenience classes for composer, performer, publisher, label, etc. However, like all things Microformats - they've got to be backed up by examples. The issue isn't wouldn't these be really cool to have, but rather we need to demonstrate that there are enough of these on the web to justify adding more terms to hAudio. Like I said a day or two ago: for the guidance of wise men and... Alright, wise-guy =P - put the terms that you would like included on the haudio-issues wiki and let's start tracking them. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: The example above is valid hAudio markup - is your issue with the word contributor instead of creator? Basically, yes :-) And it's not a huge issue, I was just wondering if there was justification for it being that way - which there is, it seems. We're also tracking this issue on the hAudio issues page now (Issue #D1): http://microformats.org/wiki/haudio-issues -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes If only one contributor is listed, it is assumed that he/she/it is also the creator of the hAudio. If multiple contributors are listed, it is assumed that the first contributor is the creator, and all subsequent contributors played supporting roles in the creation of the hAudio. That fails as soon as we want to mark up something like: Simon Rattle conducted the CBSO in a marvellous rendition of Beethoven's Fifth Yes, the use of 'contributor' falls apart completely when we have markup like that... which is uncommon. You should have noted that markup such as that is an edge case. Look at the audio-info-examples and you will be lucky if you find 1 or 2 instances of the markup you describe above. My point is that it is easy to manufacture words that break hAudio - but much harder to find actual examples online that break it. If you have issues with this approach, you can always use hAudio RDFa, which does make the distinction between dc:creator and dc:contributor. If you wanted to be even more specific, just include the Music Ontology vocabulary and mark it up using that. Thus, it can be said: Not all contributors are creators. Not all contributors are artists. That can certainly be said. However, it cannot be expressed in hAudio without requiring the publishers of such examples to re-order their content. It is a microformats principle to not do so. For the publishers that need to re-order their content to mark up hAudio, they are obviously stretching what hAudio uF can do, and should use hAudio RDFa. Thus, we should not narrow the who made it? behind hAudio down to those more narrow categories. Your conclusion is not supported by the forgoing claims. Then does doing this support my conclusion: *waves hands wildly in the air* =P More seriously: We don't have enough examples to split contributor into label, publisher, creator, and artist - which is what the examples showed to be the most prominently displayed contributors across the 93+ sites that we analyzed for hAudio. It doesn't seem to be based on established practice, as from the overview it looks like existing markup overwhelming uses 'artist'. http://microformats.org/wiki/audio-info-brainstorming#artist If we used artist, we would not have been able to mark up publishers, composers, audio technicians, etc. If we used *only* 'artist', perhaps, but not if we used 'artist' *AND* 'composer' + 'technician'. There aren't enough examples that list the composer or the technician to make the argument for adding those into hAudio. You're more than welcome to go back through the audio-info-examples and re-analyze all of the sites to prove your point, though. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: It seems strange that the microformat does not distinguish between the main contributor and others. It does - you list the main contributor first, if you care about that sort of thing. Otherwise, you can list them in any order. Both the Beatles and Geoff Emerick contributed to Sgt. Pepper's Lonely Hearts Club Band, for instance: http://en.wikipedia.org/wiki/Sgt._Pepper%27s_Lonely_Hearts_Club_Band but one is clearly more significant than the other. Sure - but what about this one: http://music.yahoo.com/release/115057 Which one is more significant than the other - the label or the artist? Are creators more important than contributors? These questions are philosophical in nature - you can't assume that creator should be used to note the significance of a contribution. There does seem to be a tendency in microformats, towards unduly low granularity; I find that strange. Why do you find that strange? We're working with lowest common denominator here. When you do that, you get low granularity. Although in classical music, the composer may be as-, or more-, prominent than the artist; likewise the conductor. Higher granularity would allow for such distinctions. Sure - now all you have to do is find enough examples online, (we'll need about 30 with the composer clearly denoted as well as the artist with the composer more prominently displayed than the artist) for us to make the argument for putting this feature into hAudio. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: It would work, but so would a number of very complicated things. My needs are essentially very simple: artistPrimal Scream/artist - albumScreamadelica/album so span class=creatorPrimal Scream/span - span class=albumScreamadelica/span Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div Per the hAudio spec, you have just marked up an album called Screamadelica, whose primary contributor (the artist) is Primal Scream. The example above is valid hAudio markup - is your issue with the word contributor instead of creator? If there really weren't enough examples that clearly listed anybody other than the creator, doesn't that make things easier? Sorry, that was badly worded on my part. What I meant to express was: There weren't enough examples that clearly showed that people were using the word artist, label, not mentioning the role, or using publisher more than the others. It was a mixed bag and what we saw at the end was the chance to support all of these by using contributor in the simple cases and contributor + hCard role in the complex cases. None of this seems to be an issue with what you're trying to mark up, though. If it is still an issue, could you please post some other data that you're attempting to markup where the hAudio spec doesn't let you mark it up in the way that you want to? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: How about this: * All contributors played a role in the creation of the audio. * If there's one or more creators, those entities played a primary role. We looked at that approach, and found that we didn't have the examples to back up the argument that we should make the distinction between creator and contributor because there weren't enough examples that clearly listed anybody other than the creator, and because hCard already has a role field. If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the role property[1]. But then I'm struggling to think of actual examples where your rule wouldn't be enough (though having to list the main contributor at the start of the list might be one problem). It just feels wrong not to be able to explicitly mark the primary creator(s) when, as you say, sometimes you do want to do just that. You can do this using role in hCard when describing the contributor. If this doesn't work for you, you can use hCard RDFa which does differentiate between the primary creator(s) and contributors. What if there are two primary creators (composer and performer, say) and the rest are just auxiliary contributors? You could mark up each primary creator's role using hCard to describe each creator. You could not specify the auxiliary contributors' roles, or you could specify them - it's up to you to determine how specific you want to be. Does that work for your needs? -- manu [1]http://microformats.org/wiki/haudio#Contributor ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div Per the hAudio spec, you have just marked up an album called Screamadelica, whose primary contributor (the artist) is Primal Scream. The example above is valid hAudio markup I thought fn was required. It isn't: http://microformats.org/wiki/haudio#Album You MUST use either FN or ALBUM, or both. In other words: If you ONLY use FN - you are talking about an audio recording. If you ONLY use ALBUM - you are talking about an audio album. If you use BOTH FN and ALBUM - you are talking about an audio recording from the specified audio album. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: I was looking at using haudio today, but stumbled on the 'contributor' field: is there a reason it's 'contributor' rather than 'creator', even for the main creator (artist, in music) of the piece of audio? We decided to not use creator because it would not be the proper semantic word for say, a publisher, or a composer. Most of the examples that we came across listed the publisher as well as the band that created the musical piece (CD). However, calling the publisher a creator would not be semantically correct. Dublin core makes this differentiation. There is a dc:creator field, which is a narrower concept from dc:contributor. Microformats try to use the most common subset of information among all examples. Some had artist, some had publisher, some had label, others had band - these are all contributors. hAudio allows for listing multiple contributors. If only one contributor is listed, it is assumed that he/she/it is also the creator of the hAudio. If multiple contributors are listed, it is assumed that the first contributor is the creator, and all subsequent contributors played supporting roles in the creation of the hAudio. Thus, it can be said: Not all contributors are creators. Not all contributors are artists. Thus, we should not narrow the who made it? behind hAudio down to those more narrow categories. It doesn't seem to be based on established practice, as from the overview it looks like existing markup overwhelming uses 'artist'. http://microformats.org/wiki/audio-info-brainstorming#artist If we used artist, we would not have been able to mark up publishers, composers, audio technicians, etc. Does that make sense? Does that explanation raise any further questions? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Digg joins DataPortability Project (Microformats mentioned)
Tantek Çelik wrote: Manu you are correct, MicroID is *not* a microformat. It did not follow the process, and violates numerous microformats principles. I've been in contact with Steve Williams, Digg's Technical Lead for Infrastructure Development, and he's been very open to discussion. We've since cleared up the fact that MicroID is not a Microformat and I explained a bit about the uF process. He was very open to discussing the issue and has since fixed the blog entry: http://blog.digg.com/?p=108 Steve got the impression that MicroID is a Microformat from the microid.org blog, which states: MicroID: A Microformat for Digital Identity I have contacted Jeremie Miller and Peter Saint-Andre (authors for the current MicroID IETF document) to politely let them know about the differences between a Microformat and the work that they have done. I have also invited them to put MicroID through the uF process or create an RDFa vocabulary. I'll let this list know when I have gotten a reply from them. -- 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-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Firefox 3 (was: Icons of MF wiki)
Michael Smethurst wrote: On 11/1/08 10:31, Alex Faaborg [EMAIL PROTECTED] wrote: do you have any plans to support rdf-a in the interface? In 4.0, 5.0, 6.0? We haven't decided yet, and I would love to hear people's opinions both in favor of and against including RDFa support in a future release of Firefox. +1 for me. +1 for our company. It would be a real shame if only one way of extracting semantics from a web page were supported in Firefox. If Firefox is serious about the semantic web, it would be nice to see support for all the methods of expressing semantics on web pages. Note the recent proposal on creating a unified representation for semantic objects (uF, RDFa, eRDF): http://microformats.org/discuss/mail/microformats-dev/2008-January/000410.html This would make it much easier for Firefox to support semantics in pages. It isn't technically difficult to support all of them, so I see no reason not to do so. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RDFa Basics video (8 minutes)
Finished an RDFa Basics video this weekend. It attempts to explain RDF, CURIEs, N3 and basic RDFa in 8 minutes: http://www.youtube.com/watch?v=ldl0m-5zLz4 Thought some of you would want to learn about some of the upcoming features of XHTML2 as well as compare and contrast how RDFa differs from Microformats. Constructive feedback would be great, as I'll probably be doing the advanced RDFa tutorial in a month or so, and will need to know what worked and what didn't in the RDFa Basics video. A high-bitrate version, along with all source material, will be uploaded and put on the Digital Bazaar wiki tomorrow: http://wiki.digitalbazaar.com/en/rdfa-basics -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Intro to semantic web (video)
Happy Holidays, all :) I've had a hard time explaining what the semantic web is about in a concise manner over the past several months, so I decided to focus on answering that for people that don't really know much about the web. I spent the last couple of days playing around with the video creation suites in Linux (Blender, Cinelerra, Gimp, xvidcap and a borrowed wacom tablet). Here's the result of a couple of hours of mucking about - does this explain what the semantic web is all about? Is it simple enough? Too simple? Too long? Too short? http://www.youtube.com/watch?v=OGg8A2zfWKg The entire thing, including all source material, is under a Creative Commons Attribution-Share-Alike license (including remixing and distribution). All source material is available here: http://wiki.digitalbazaar.com/en/semantic-web-intro -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
Benjamin Hawkes-Lewis wrote: http://www.w3.org/TR/html401/struct/global.html#adef-title title = text [CS] This attribute offers advisory information about the element for which it is set. However, I do agree that PT2M23S is stretching the rules a bit. Can information that readers are probably not going to understand be classed as advisory? We could argue it both ways based on how we define advisory and the pattern recognition and cognitive abilities of the general Internet population. Since we have a potentially better solution on the table, let's not go down this path yet. What I was proposing was this. When all the information required is available in the content of the element in Arabic numeral form, and all a parser would need to know is what units are being used, we should prefer to mark up the units rather than attempt hide an ISO format of the same data with the TITLE hack. Agreed. So, to adopt your milliseconds example, we could avoid TITLE and just use: span class=durationspan class=milliseconds2/span milliseconds/span Sure, we could do that... although, we should be careful to address all of the problems... we would still need to address some of the non-standard cases that you outline below. We might prefer to specify abbreviations like s and ms, I'm not sure. If we're going to put s and ms in @class, then I don't think that would be a good idea. If we were to, however, place that information in title... that would be fine, IMHO. To illustrate: This would be a bad idea: span class=durationspan class=s3/span seconds/duration This would be acceptable: span class=durationspan class=seconds3/span seconds/span Or if we wanted to use the hMeasurement approach: span class=duration title=3sthree seconds/span span class=duration title=2min 3stwo minutes, three seconds/span span class=duration title=2y 35htwo years, 35 hours/span span class=duration title=3sthree seconds/span Obviously, if this principle were to be extended to other sorts of measurements, it could get more complicated for two reasons: Take a look at the hMeasurement strawman... there's been a great deal of thought put into the issues that you describe: http://microformats.org/wiki/measure-brainstorming#Straw_man 1. People might want to use variations on the SI units that cannot be expressed with the SI prefixes e.g. 10^26 s. We can do this if we use hMeasurement: span class=duration10^26 s/spaneconds. 2. People might want to use non-SI, non-global units like inches and quarts. Then they will need to convert it to SI units: span class=weight title=95.2543977 kg15 stones/span Now, it might be that we could adapt the principle to serve in some of those situations too: 1. Perhaps we could allow class names like seconds/10^26 (it's ugly but legible and conforming). We can already do this in hMeasurement: span class=duration title=10^26s10^26 seconds/span Or, alternatively they could convert it to another representation format: span class=duration title=100Ys10^26 seconds/span 2. Perhaps we could think about specifying class names for widely-used, non-SI units like inches. Like this (in the current hMeasurement proposal): span class=length title=4ft 4infour feet, four inches/span 1. Obscure units (5 chains wide) Boiling the oceans - we should make them convert it into a more popular measurement. 2. Use of non-Arabic numerals (III HORA) Boiling the oceans - make them convert it into a more popular measurement. 3. Use of words instead of digits (three seconds long) I think addressing this was outlined above. 4. Fuzzy representations where not all the information required is implicit in the human-friendly content (about three miles) There is room for error metrics in hMeasurement too, although, it hasn't been worked out quite how we do that. For these cases, we would /still/ need an expansion pattern. I wasn't particularly thinking of the expansion pattern you suggest, since it's still attempting to put tortured data-showing requirements over the needs of human end-users. Do SI measurements constitute tortured data? Is displaying 2min 23s, or 2 minutes 23 seconds better than displaying PT2M23S? The point of my suggestion is to reduce the number of cases where we need an expansion pattern, since expansion patterns are proving problematic. Let's address the actual problem of precise expansion patterns for measurements. So we could do one of the following: 1. Use hMeasurement and add h for hours and y for years. 2. Define second, minute, hour, year classes. 3. Create second, minute, hour, and year aliases in to the hMeasurement units s, min, h, and y, respectively. Use hMeasurement. I suggest doing the 3rd thing, which would give us all of the following, valid, markup:
Re: [uf-discuss] Re: Precise Expansion Patterns
Paul Wilkins wrote: Another possible solution is to provide greater detail for the time itself. abbr title=00:23:002:23/abbr This I understand is an acceptable title for screen readers, it expands suitably on 2:23 (which could be 2 hours 23 minutes or 2 minutes 23 seconds) and it's computer understandable in an ISO 8601 manner. If you are suggesting that we use the hh:mm:ss time format for expressing duration, we cannot. That would be an abuse of the ISO 8601 standard. The standard is very specific about specifying TIME and about specifying DURATION. Duration MUST be in one of the following formats, where 0-values can be omitted: PnnYnnMnnDTnnHnnMnnS PnnYnnWnnDTnnHnnMnnS PdateTtime This is correct for a duration of 2 minutes, 23 seconds: PT2M23S This is not: 00:02:23 Here's what the various approaches thus far look like when you put them on an HTML page: http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html There are really two questions that we're attempting to answer here: 1. Can we make screen readers not read the @title, of whatever element we choose, out loud? 2. Do we care that PT2M23S will appear if the person browsing hovers their cursor over the text denoting the duration, if that is the only way we can successfully utilize ISO standards in the Microformats community? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
Paul Wilkins wrote: span class=duration title=PT2M23S2:23/span With this it is not possible to prevent the title from being used by screen readers and other people who hover their mouse over the time value. This is not true. You can set several, of not all, screen readers to not read titles of SPAN elements. It is important for us to focus on the reason this discussion started in the first place: http://microformats.org/discuss/mail/microformats-discuss/2007-December/011035.html The issue was accessibility, specifically, how accessible is the ABBR design pattern for those that use screen readers. At this point, it's really just a matter of testing the examples we have so far: http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html Against the list of screen reader packages on the market: http://en.wikipedia.org/wiki/List_of_screen_readers I'll volunteer to check out Orca and JAWS and report the findings to the list, and document them in the wiki. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
Benjamin Hawkes-Lewis wrote: Here's another question that needs asking. How much real-world value does the use of the ISO standard for date time representations actually add in this /particular/ case (hAudio duration)? How often do these reasons apply to hAudio duration? These questions are dangerously short-sighted, focusing on just hAudio will hurt the Microformats community in the long run... I'll explain why below. The impression I get is that the majority of cases would be served fine by: span class=durationspan class=minutes2/span:span class=s25/span/span This would be a giant pain to author, IMHO. Then again, it fixes our accessibility/usability issues - placing much of the load on the authors. If we make it this verbose to mark up this sort of information, do we think authors are going to mark up DURATION? For sites like ours that are automated, we would have no problem adopting the approach listed above... but think about the blog author that has to mark up DURATION. Are they going to take the time, or skip it? What happens when somebody wants to specify a time duration as twenty-three minutes? Or a measurement as two stones? Your proposal above doesn't solve those problems. Andy Mabbett wrote: On Sun, December 16, 2007 19:14, Manu Sporny wrote: Paul Wilkins wrote: Another possible solution is to provide greater detail for the time itself. abbr title=00:23:002:23/abbr If you are suggesting that we use the hh:mm:ss time format for expressing duration, we cannot. That would be an abuse of the ISO 8601 standard. We can, becasue we are not mandated to use the ISO 8601 standard. So assume that we do that today... We're locking in DURATION to have a very specific meaning a length of time. To denote that length of time, you have hours, minutes and seconds HH:MM:SS. Some time further down the line, somebody has another Microformat that needs to specify a time duration. Their time durations, however, are in years. The problem comes in when the second person wants to denote their time duration in years. We've already said that DURATION is a length of time and specified a format HH:MM:SS. So now, authors have to translate years into hours... quite a pain, but it gets worse. Later yet, in a future Microformat far, far away, somebody comes along and wants to specify time in fractions of a second. Once again, they can't use DURATION because there is no space for fractions of a second (which you can specify in ISO8601). Remember, this same thing happened with the TITLE tag in Microformats. TITLE is used to specify a job title in hCard. This meant that we couldn't use TITLE in hAudio because it meant a job title, not the title of an object, such as, but not limited to, a book, movie, album, or person. By constricting DURATION to have a restrictive format, HH:MM:SS, we are being short-sighted and are not thinking about the other Microformats that are still to come that will need to specify DURATION. 00:02:23 is being shortsighted. Let's learn from our past and not make the same mistake again... let's not be short-sighted about this decision. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Precise Expansion Patterns
Paul Wilkins wrote: The hAudio time should be denoted in seconds. If 3:23 is given it's to be seen as three minutes and twenty two seconds. If hours are needed it should be 1:3:23 (0 prefix optional) to denote 1 hour three minutes and twenty two seconds. This way the hAudio standard can work without needing to modify the text, the abbr pattern isn't required and everybody can go home and sleep restfully for the night. You may sleep restfully with that approach, but I can't imagine that many others on here would... :) You are effectively making the argument that we should forget about using ISO standards, which is one of the microformats principles - re-use, and replace it with our own. I can guarantee you that if we take that approach, we'll be having this same argument with the next ISO standard that gets used by the uF community. I'm not stating that the solution we have for hAudio at the moment is ideal, but re-inventing the wheel isn't necessarily the best approach either. What was the problem with the SPAN approach, again? span class=duration title=PT3M23S3:23/span - You can set most, if not all, screen readers to not verbalize @title in SPAN. - We're not abusing ABBR. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: [uf-new] Mapping Microformats to RDFa
Brian Suda wrote: Also, there is the same discussion on going on the RDFa mailing list: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0113.html As Ivan Herman replied on that list, GRDDL handles much of what you are looking for as well and much of those Microformats - RDF conversions already exist. Great! Where are they? Are the transformations only available as XSL stylesheets? If so, they're not very useful as a quick-reference for publishers... are they? Are you talking about this: http://esw.w3.org/topic/CustomRdfDialects In which case: The hcard2rdf.xsl is licensed under CC-non-commercial, which makes it useless to any company wanting to implement this stuff in their products. hreview2rdfxml.xsl is a 404. There are no mappings for hCalendar, hAtom, or hResume, etc... what am I missing? Apologies - I'm not that familiar with GRDDL tools that are available... do you have some good links to GRDDL tools? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Firefox 3 Javascript Semantic Data UI Control (was: Microformats and Firefox 3)
Dimitri Glazkov wrote: I really like the idea of allowing additional control over presentation via pseudo-classes, but I am worried that :target isn't quite right, at least if we follow the spec to the letter (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically since this pseudo-class is not dynamic and there may or may not be a fragment identifier on the microformat. There is another option available. Songbird has released a specification for a Javascript object that can be used to control some of the functionality in the browser. http://developer.songbirdnest.com/documentation/trunk/webpageapi/files/sbIRemotePlayer-idl.html Operator/Firefox could provide something along the same lines to allow publishers to disable the browser UI and provide their own via CSS. Here's how it could work: The SemanticDataUI object would be accessible, from Javascript, using the “semanticDataUI” global variable attached to the currently loaded document. A publisher could disable the semantic data UI in any browser by running the following line of Javascript: semanticDataUI.disableUI(); Users could control whether or not they allow web pages to disable the Semantic Data UI. Most would probably allow web pages to disable the semantic data UI. Publishers could manually disable the Semantic Data UI and use CSS to mark up their hCards, hCalendars, and hAudios. This would give cross-browser UI control to both the users and the publishers without having to do any CSS magic. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and Firefox 3
Dimitri Glazkov wrote: This is not particularly transient, but it addresses #2, methinks: http://glazkov.com/blog/margin-marks/ Mike, Alex - I think you should take a very serious look at Dimitri's Margin Marks idea. Check out the screen mock-ups here: http://flickr.com/photos/dglazkov/sets/72157601860335196/ Implementation would be a bit of a headache, but he has proposed a very elegant solution on, IMHO, the right way to display semantic data items on a web page. It is the best approach that I've seen so far, over all of the UI concepts for Microformats in Firefox 3. This is the same way that Eclipse shows the developer warnings, comments and errors via the code editor. It would do well as a transient UI AND wouldn't be intrusive on the browsing experience when the UI is active. Exciting stuff... -- manu -- Manu Sporny http://wiki.digitalbazaar.com/en/haudio-case-study ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Need for plain-language intros for each microformat
Andy Mabbett wrote: I think it's time we moved the specs to *-spec or *-specification, and used the root page for each microformat, such as the above, for a plain-language introduction, taking care to avoid jargon as much as possible. +1 for this idea. There have been several times where I've pointed somebody to a uF specification page to give them an overview and they just come back claiming that the page didn't really tell them anything... or worse, it confused them. http://en.wikipedia.org/wiki/Hcard The page should be a short introduction and shouldn't overwhelm the reader. Perhaps a 1-2 paragraph introduction, a very simple example, and links to other wiki pages at the bottom with more information. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats UI in Firefox 3
Alex Faaborg wrote: Yes, while previous Firefox designs have focused on the browser injecting UI into the page, this discussion is about how the content creator should provide links and buttons for acting on microformatted content. I'm probably being a bit dense, but it looks like we're entering into a philosophical debate. Without taking sides, it looks like the philosophical rift is this: Side A: Publishers should be able to specify UI elements for their Microformatted content in their HTML. Side B: The browser should be solely responsible for injecting UI into the page? This debate has been tracked on the wiki: http://microformats.org/wiki/audio-info-issues#Historical:_Graphic_buttons_in_rel-patterns The current resolution is to leave implementation for user actions up to the browser and uF plug-ins. Without going into the nasty details, which are fully documented on the wiki, there is opposition to directly specifying UI through uF markup. Microformats are about data, not UI. That being said, if there is a desire to add generic UI actions to any sort of semantic data (keep in mind eRDF and RDFa), the one idea that seems to be most compatible with Microformats are about data but able to give the publishers of any semantic data some control over the UI is the uf:// protocol idea. Perhaps a generic set of actions that are defined by all semantic data communities (uF, eRDF, RDFa, etc.). The assumption is that some sort of ID mechanism is utilized. So for data like this: div id='alex-faaborg' class='vcard'.../div Something like the following: a href=action://addressbook/add/alex-faaborgAdd to address book/a a href=action://addressbook/mail/alex-faaborgE-mail Alex/a Here are some other examples: action://map/find/eiffel-tower action:// The above mechanism would allow people to specify default behaviors for actions. Some could specify that action://map/ is handled by Yahoo Maps, while others might choose Google Maps or Microsoft Streets and Trips. It is important that the Firefox developers not only think of Microformats, but eRDF, RDFa, and other semantic markup technologies that are coming down the pipeline. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats UI in Firefox 3
Manu Sporny wrote: Here are some other examples: action://map/find/eiffel-tower action:// Sorry, here are the other examples: action://location/find/eiffel-tower action://license/fulltext/Harry-Potter-and-the-Order-of-the-Phoenix action://feed/subscribe/cool-hatom-feed action://audio/play/haudio-punk-rock-song action://resume/findjob/my-hresume -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Getting legal help (was: inappropriate behaviour)
Scott Reynen wrote: The microformats admins have decided to ban Andy Mabbet from this community (both email lists and wiki) for one week, due to continued failure to adhere to the be nice guideline [1] after a private warning. I don't condone Andy's tone when replying to the thread that started all of this. I think it is important to note that he is one of the more frequent contributors to this community and constantly challenges the ideas and concepts that are just accepted around here without explanation. While I don't always agree with Andy, he does have a knack for making logically sound arguments. It is vital to have people that can challenge the status quo, people such as Andy, involved in a community such as this. His replies reflect reservations that several members of this community choose not to express out of fear of retaliation. In this case the topic is: the insistence that we should not raise legal matters on the mailing list. The reasoning for not discussing legal matters on the list is not clear. It is ironic that in an open community, such as this, that we have any taboo topics... but here we are. The only attempt at explaining this why we cannot speak about legal matters is that nobody on here is a legal expert, including the admins. If that is the case, I think there is something that we can do to solve that issue. I propose that we get the Electronic Frontier Foundation involved. If not the EFF, then Creative Commons. Each of those organizations believe in the open exchange of information and have lawyers on the payroll. I volunteer to get the ball rolling if necessary. Thoughts and suggestions? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Mediawiki accesskey shortcut usage instructions
Paul Wilkins wrote: From: Andy Mabbett [EMAIL PROTECTED] Paul Wilkins [EMAIL PROTECTED] writes It could be a lot better if it said Accesskeys differ according to your browser. which links off to a page that explains about Accesskeys, followed by use ACCESSKEY S to save It would be better still to say nothing. We don't say move your mouse pointer here and press the button to go to the page about... Can we please kill this thread? It's a humble request. The signal to noise at this point is horrible. I don't think anybody on here joined the list to discuss access key issues on our wiki. Please discuss it among yourselves off-list if you must. Again - just a humble request to stop spamming the list with access key issues. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats gets strong showing in Firefox 3 UI
Things can still change, but after talking a bit with the Firefox 3 folks - Microformats are starting to look more and more like they're going to be supported in a big way in the next major release of the browser. http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/ -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Legal implications of using Microformats
M. Jackson Wilkinson wrote: If a patent were granted, then the holders could approach users of the now-patented process and hold them accountable for royalties and licensing fees. All of a sudden, anyone from Microsoft to your small business can be threatened with, at minimum, a long legal battle. Exactly the point - the Microformats community is not doing enough to protect the implementors of their technology. This fear can be soothed fairly simply by releasing all work on the wiki into the public domain, or something of the sort. All wiki pages could be under the LGPL, the GDL, or some other open licenses if not in the public domain. There are several options here. Right on the money, again. The challenge now is that every editor of the wiki would, I believe, need to either approve of the change in license, or their work would need to be stripped out of the wiki. This kind of process has happened several times in open source software projects. The microformats wiki may be sufficiently young as to make this somewhat possible, but it would certainly involve significant effort. It's one of those things that really needs to be handled right at the beginning. Another brilliant statement! Deal with the problem now while it is manageable - or later, when there are going to be multi-million dollar lawsuits being bandied about. The Microformats community WILL be blamed for not performing proper due diligence before placing their standards online. Again, this is all just based on my personal experience and research, and is not legal advice, but may be useful as a way of understanding why some may be concerned. The reason this issue was raised was because we have authored and filed several patents and know what we are talking about regarding the dangers of submarine patents. If you want an official letter from a legal firm specializing in copyright and patent law, stating how tenuous the Microformats community's copyright and patent policy is - we could arrange that. However, it is going to cost us a sizeable chunk of change and we wanted to make sure that the community was listening before we went out and arranged to have that happen. -- manu -- Manu Sporny President/CEO, Digital Bazaar, Inc. http://blog.digitalbazaar.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] video-metadata-models
Andy Mabbett wrote: /video-metadata-models /microshow That's incredibly strange - both of these links appear under the Related and See Also sections of those pages. Should red-link items be placed under each of those sections? There isn't anything at the end of the links to relate to or see? The media-info examples page is the only one that is current. I see no reason to keep blank pages attached to abandoned/out-of-date initiatives around, especially since these red links are over 2 years old. Especially since there is no information that is being destroyed. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Fwd: [uf-discuss] Legal implications of using Microformats
Brian Suda wrote: --- if you can give-us any other information, who exactly the company is, etc and any other information from the legal team we can attempt to work around these problems or debunk the FUD. Our company is Digital Bazaar, Inc. we provide digital content delivery services (buying and selling music, TV, film and books online) and want to use several Microformats in development for Bitmunk as well as integration into Firefox, Songbird, and Democracy Media Player (we're currently talking with each team about Microformats). Bitmunk website: http://www.bitmunk.com/news/ DB corporate website: http://www.digitalbazaar.com/ For those of you that don't know where this discussion started - it was started by Guy Fraser on microformats-new: http://microformats.org/discuss/mail/microformats-new/2007-April/000241.html The concern is that there is no standard copyright or patent statement or policy that applies to the entire Microformats website. Specifically the examples, formats, brainstorming, proposal, draft and specification pages have a mix of copyright statements (some not at all). This can cause problems if an individual authors a Microformat without releasing copyright or patent claims. Microformats can stick around in the draft process for a long time. Often they have a statement of intent to release it under a certain copyright/royalty-free licensing model. Intent to provide under no restrictions is very different from provide under no restrictions. This could affect anybody implementing Microformats like so: 1. Author pulls together examples, formats, brainstorming, proposal and draft of a Microformat with intent to release royalty-free. 2. Author applies for patent without notifying Microformats community. 3. Invented Microformat gets very popular over the next 2 years. 4. Author decides not to follow through with intent and instead decides to sue for patent infringement. OR Author decides not to relinquish copyright and becomes a nuisance to the community. While this will probably not happen, a simple change to the Microformats wiki can ENSURE that it doesn't happen. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
