Re: [uf-new] The Process (was: hAudio case study)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Document the implicit schemas that the content examples imply. Every word in that sentence matters. On the contrary: implicit is redundant. The alternative: Document the schemas implied by the content examples. reads better. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] The Process (was: hAudio case study)
On Sep 12, 2007, at 4:33 AM, Brian Suda wrote: Quantity does not equate quality! Right. I think we tend to get caught up in whether or not the numbers are convincing to our fellow community members, and lose track of the important question: whether or not the end result is convincingly useful for publishers. Most publishers don't care if the examples we collect are statistically significant; they only care if it looks useful for them. More examples helps with that goal, but there's not really quantifiable finish line. I suspect much of this problem could be resolved with better scope definitions. When someone says these examples don't cover my needs, rather than collecting more examples to prove those needs are edge cases, we could be referring back to the scope definition and saying sorry, your needs are outside the defined scope of this microformat. But that only works when the scope is very clearly defined in advance. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] The Process
Frances Berriman wrote: On 12/09/2007, Manu Sporny [EMAIL PROTECTED] wrote: I think we should call it what it is: The Accepted Limitations of Microformats Yeah, that would work. I have created the wiki page, everyone please feel free to note issues and add other sections on the page: http://microformats.org/wiki/accepted-limitations-of-microformats -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] The Process (was: hAudio case study)
I'd second that. Even if users are just plopping blobs of data that is recognizable to humans when presented in a blog, but unstructured, we can still make sense of those blobs and structure them. Seeing what people want to do makes more sense that imposing from on high. That is typical of standard's bodies and in practice not often followed. For an example of this, where some standards from on high, are compared to some standards that emerged, in video metadata, see this: http://microformats.org/wiki/media-metadata-examples#Comparison_Table mary Mary Hodder Founder: Dabble Blogs: Dabble.com/blog Napsterization.org/stories On Sep 12, 2007, at 8:53 AM, Scott Reynen wrote: On Sep 12, 2007, at 9:24 AM, Michael Smethurst wrote: Would it not be better for ufs to standardise markup based on the domain model than waste time wading through flakey html? [Perhaps] I don't believe looking at current publishing practices is a waste of time at all. Much the opposite, I think it's the most important part of the process. Domain models that don't account for what is published on the real web tend to be less useful on the real web. -- Scott Reynen MakeDataMakeSense.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] The Process
I have to second this one as well. In fact I blogged about this some time ago: http://napsterization.org/stories/archives/000583.html nicely of course, but the reality was that for 2 years, I got slammed and treated badly by the folks who started it, and then once I made them sit down and explain the process, I was able to follow the rules. But it was harsh. Many people commented privately to me after the two blog posts on process that it helped them a lot because they had the same experience. I don't see why hazing helps the process. You can have high standards without being mean. mary On Sep 12, 2007, at 8:50 AM, Frances Berriman wrote: On 12/09/2007, Manu Sporny [EMAIL PROTECTED] wrote: I think we should call it what it is: The Accepted Limitations of Microformats Yeah, that would work. That harshness has also sent good people elsewhere... you don't have to be harsh to prevent frivolous formats or unwanted behavior. In fact, this goes against the Microformats be nice principle. I agree - and I think that these new pieces of documentation will help everyone be more supportive rather than exclusive in any way. -- Frances Berriman http://fberriman.com ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] The Process (was: hAudio case study)
Frances Berriman wrote: I imagine it will be valuable as a primer for those interested in creating some type of microformat (or wondering if microformats are indeed for them) and maybe how the process works. Good, as that is one of the goals of the document :) Talking of... I note that one of your encountered problems was with the process itself. Was it just the shifting/vague targets that were the main problem, or do you have others? Shifting/vague targets was the most frustrating part of the process. The idea that Microformat authors now are being held to a different standard than the ones that created hCard, hCalendar and hReview. For example, once we had collected around 30 examples for hAudio, we thought we had enough. After all, review-examples (hReview) only has 17 examples collected. However, some on the list kept going on about collecting more examples before a decision could be made. After we had 50 examples, the same issue was brought up that we needed more examples. Thus we went overboard and collected over 100 examples. To us it seemed like this was an unfair argument that was thrown out there whenever we disagreed with somebody that was more senior in the community. The argument came across as Well, you're just not analyzing the correct sites - otherwise, you'd see my point... so why don't you go and analyze more examples until you can prove us right. The person making the previous statement doesn't have to do anything to defend their viewpoint and the person creating the Microformat now has to spend tens of hours collecting more examples. In the end, it made hAudio better - but at the expense of frustrating the Microformat authors. The other issue seemed to deal with being surprised by things that you couldn't do with Microformats, as the wiki doesn't necessarily focus on what you can't do with a Microformat. For example: overlapping Microformats is a problem, so is the lack of namespaces, global identification on pages, and the scoping issue outlined in the hAudio case study. We felt that the community wasn't very upfront about these shortcomings of Microformats. We didn't even know that the community understood that Microformats had these shortcomings until we were 7 months into the process. I think we as a community should be very honest about what one can't do with Microformats. In an attempt to address these issues, I've authored the following document (with help from Martin McEvoy and Brian Suda): http://microformats.org/wiki/how-to-start-a-new-microformat The document attempts to outline The Process more clearly and in a step-by-step manner. We found ourselves missing steps or not understanding what needed to be accomplished at certain points in the process. Our general view of The Process when going through it the first time was that it seemed to be being made up as we went along. There are several community members that have their own take on each step of the process and their advice sometimes conflicted with what other members of the community advised us to do. In short - there didn't seem to be a consensus on the process, which led to frustration when attempting to get to the next step. I think the best thing that the community could do at this point regarding the creation of new Microformats is to smooth and refine The Process. It is not very easy to grok until you've been through it... and after you go through the New Microformat meat grinder, you really don't want to do it again. :) -- manu ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
