Re: [uf-new] Document Sources/References
Hi Jamie, On 29 Jun 2009, at 15:44, Jamie Rumbelow wrote: Is there a semantic, POSH way of linking to a document's source or reference. There's no finalised microformat, but a lot of research has been done for a Citations format, see http://microformats.org/wiki/citation Regards, Ben P.S. Additionally, enquiry/discussion threads should be directed to the microformats-discuss@ mailing list, please; microformats-new is focused on the actual development of the new formats. Thanks! ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Using external Data with Flash
Hi Konrad, Thanks for getting interested in microformats! First up, query and discussion threads should be directed to the microformats-disc...@microformats.org mailing list, please; [microformats-new] is focused on the actual development of new formats, so your question won't necessarily have reached the right audience here. Thanks! I'm crossposting this over to microformats-discuss for you, so any future replies should please drop µf-new from the reply header. Thanks! On 27 Jun 2009, at 17:08, Konrad Röpke wrote: I want to program a possibility to access an external file online on a server with a Flashfile. Would that be possible also with an hCalender file? Thanks for any help or recommendations. Could you clarify a little what you want to do? If you're trying to parse hCalendar within a Flash application, you might be able to reuse some of the JavaScript code from the Operator parser to create JavaScript objects. See http://microformats.org/wiki/operator Cheers, Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: One issue per thread
I am a very pro-wiki person; not just in microformats.org, but everywhere else, too. Also, moving this discussion to microformats-discuss, since this is not discussing the creation of new microformats. On 28 Feb 2009, at 07:49, Manu Sporny wrote: The only problem with this approach is that it would take a very long time to develop/implement. I think I would class that problem as ‘fatal’ to an otherwise beautiful vision of interoperating technologies. Nice try though ;-) On 28 Feb 2009, at 09:47, Scott Reynen wrote: For what it's worth, I've always considered email a tool for discussion and the wiki a tool for documentation. But I don't think that's worth much. I somewhat agree, in that regardless of how the content is compromised, the content of the wiki *must* function as a piece of documentation. It's all the documentation we have, of specs, brainstorms, and so forth. Certainly within this community it is regarded as ‘truth’ — “wiki or it didn't happen”. As such, no matter where discussion takes place, the knowledge from it *must* go on the wiki, or it will be lost. If anything has dragged this community down in the past, it's not being able to accurately refer to past events. Using the wiki thoroughly is what prevents that. The importance of using it as part of spec and related developments here cannot be played down. I think it's well suited to editorially driven content, which is the primary output of microformats.org. * The problem with the lists is that if an issue discussed is not documented on the wiki, you raise an ever increasing barrier to entry for someone else to join that discussion, particularly as time passes and the thread is buried under subsequent unrelated discussions. * Conversely, the problem with the wiki is that a piece of documentation can be spoiled by interjections of disagreement in every other paragraph. I find value in lists for humanising discussion too. Writing this email I'm able to be a little more verbose with mannerisms and language that, hopefully, means everyone appreciates me as a human being rather than a Robot Overlord Admin Robot (additional robot for benefit of awesome ‘ROAR’ abbreviation). I think that's important to everyone here being able to work together, and the depersonalised nature of documentation on the wiki is the opposite; highly-optimised issues are vital for documentation, but bad for interacting in a friendly manner with the people that contributed. (Issue documented: http://is.gd/laIn) The result is a certain amount of duplicity to having lists. As I say, I have no issue just ignoring list content that should go on the wiki. But, somewhere it shifts a burden: Either to individuals who must ensure their point of view is documented twice, or onto specification editors to pull every discussion together. The latter editorial burdon is not going to be acceptable in most cases; expecting a spec editor to create permanent wiki documentation of every discussion is an unreasonable waste of their time. I'm not anti-email. But I support the idea that everyone contributing must ensure their knowledge is documented. I don't have a clear idea on precisely where the line between different sorts of discussion sits to reduce duplication. B ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio/Audio RDF clarification (possible admin moderation request)
On 15 Sep 2008, at 17:50, Martin McEvoy wrote: Martin McEvoy wrote: I will be adding Myself as Editor on the Version 1.0 format, because I don't have some other agenda other than completing haudio. In fact forget that its not very diplomatic, I will Invite Tantek, or Brian to edit the 1.0 version of hAudio they are the two admin's that have had the most input in haudio, haudio may gain a little of its credibility in this way, and I think that it is the best. I will be emailing the admin's airing your total disregard of microformat's principles, and of the damage you are causing the Microformats Community, in particular hAudio http://microformats.org/wiki/haudio and currency http://microformats.org/wiki/currency to which you had no hand in authoring. Obviously the admins are open to email from anyone about any issue, but I for one would prefer that as much of this complaint is resolved in public, please. And, of course, the personal issues are more complex and it's up to individual judgement if you think it's more appropriate to take something offlist. I'm just emphasising that as much as can be resolved openly in this community and through process adherence should be, please. Additionally, my feeling is that I'm not involved enough in hAudio to comment on specifics, so what follows is quite general. That said, a few things regarding the process/development side of this seem quite clear to me. I want to know if the alleged process violations can be handled within the development process itself, rather than being an admin issue. Please consider these points: • All issues with hAudio, be they problems to solve, capabilities to add, incompatibilities with the Process or anything else should be tracked as issues on the microformats wiki. (http://microformats.org/wiki/haudio-issues ). For a format to advance, issues need to be resolved. If issues are not resolved, the format can't be moved to its next stage (be that draft or spec) • If an issue is ‘resolved’ in a way that is incompatible with the process (regardless of who resolves the issue), that issue cannot be resolved without addressing that breach of the process. Addressing that could be: Changing the issue resolution or changing the Process if the process were to be found to be broken. Either way, issues against formats cannot be resolved whilst in unaddressed violation of the process. These two points *should* prevent any individual ever pushing through a format in a manner which is incompatible with the process. If issue resolutions are insufficient, the issue must be reopened. Martin, if enforcing the process in the manner I describe here is insufficient to avoid/revert the issues you've raised, I'd be very grateful for elaboration or example of where these two checks have been avoided. Where the above is sufficient, anyone involved in hAudio development should be able to reopen issues that haven't been adequately addressed. Again I emphasise that I'm not endorsing any side of this personal argument at this point, and I'm speaking generally for that purpose. What I am trying to do is jump in quickly to apply the Process to the development problems raised, and avoid the personal aspects of this complaint being tangled with hAudio process issues. Thanks all, Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hProduct: Shipping
On 10 Sep 2008, at 14:36, Paul Lee (이기수) wrote: I'm fine with that - Jay? 2008/9/9 Jason Hale [EMAIL PROTECTED] I also agree that shipping information doesn't belong to a product, it belongs to that transaction and shouldn't be tackled within hproduct. This would also go along with taxes or any other sales fees associated with a transaction, they should not be apart of hproduct. It makes more sense to me that taxes, shipping information and so forth would be part of a product listing, and thus hListing. Price of a product would, presumably, be the ‘recommended retail price’? B ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Recipe proposal
On 5 Jun 2008, at 14:17, Thomas Yde wrote: I therefore suggest that we change entry-title to title and entry- summary to summary. We've had issues with ‘title’ before, as it is already defined for a different purpose (effectively ‘job-title’) in hCard. Using it in a more general way that would allow it to be ‘entity-title’ or ‘object- title’ as well would require redefining it, and there's been a lot of heated disagreement about doing that previously. Changing ‘entry-summary’ to ‘summary’ causes a similar clash of semantics, since ‘summary’ is used in hCalendar/Review/Listing in more of a titular manner. I'm not sure about basing Recipe off hAtom semantics; I need to think more about the situations where you would be using both at the same time to see if that would cause conflicts. B ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
OK, this is getting a bit wild. Can everyone please take a little stock. I shall try to lay out what I see are the ‘facts’ of this situation, which are being debated at length, but can't actually be altered. So: • ‘title’ is specified as something else. • ‘fn’ is perceived as too generic and counter intuitive in the context of audio My elaboration on those ‘facts’: 'Title' came from vcard, and trying to bodge its semantics into hAudio is just going to create a mess. Even if there's a tenuous way to make the definition fit both, it's just a bad idea to generalise two things which are very clearly not the same. ‘title’ a desirable, valuable field name, but it's gone. In our µf world, it's got a definition (which is not the most common English usage, it's true) and if it doesn't map to a usage in another proposed format then we'll have to use something else. Regarding FN, I happen to agree. It's very generic and works in place of something-called-title, but the name is unintuitive. I don't think that helps publishers. On the basis of those two things, there is very little to debate. TITLE is out of bounds because it doesn't mean what you want it to mean in the context of microformats. If ‘FN’ is agreed to be undesirable, then the only debate should be regarding what the alternative field name should be. For my 2¢, I think the ‘audio-title’ route is OK, and has no ‘namespacing’ consequences at all. The ‘audio-’ prefix is precision and clarification. It's not a grouping. ‘audio-title’ makes perfect sense in natural language, and it's a field that it's necessary to be more precise on. If there's some phrase that could be more transferrable (something synonymous with ‘media-title’) maybe that should be considered too. End of the day, though, ‘TITLE’ is gone, and if you don't like ‘FN’ then you need to find an alternative. Perhaps the current debate would be more productive if it focused on solving that problem, rather than thrashing around the cement base of the issue. Cheers, Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio Specification Page is published
On 4 Nov 2007, at 00:53, Martin McEvoy wrote: 1, http://microformats.org/wiki/haudio#Price span class=price should this not be... span class=money ? as per the Currency Proposal http://microformats.org/wiki/currency-proposal No. Should the currency microformat be completed, then that class name would be used in addition. As per existing patterns (such as class=author vcard in hReview), you might end up with span class=price hcurrency or something. My view is that with currency still being a proposal, it should not be used in examples. That risks causing confusion and may inadvertently push a sub-optimal currency pattern into mainstream usage without it going through the process. I'd like to see that simplified to the text form of price, ala: span class=price$14.00/span Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio Examples (was: hAudio Specification Page is published)
On 3 Nov 2007, at 15:42, Manu Sporny wrote: The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio I've been through and edited the examples to fix issues with validation and incorrect closing tags. I have the following issues with them: • class=price should not include mark-up from a currency proposal. It could endorse, promote and spread use of mark-up that is later discarded as sub-optimal. I don't think the hAudio spec should advocate use of an unfinished microformat at all. span class=price£1/span should be sufficient for these examples at the moment. • All uses of the ABBR pattern for dates and times should use hyphenated separators. We're still in an accessibility grey spot with regards to the whole thing, but it was noted that splitting dates with hyphens made it acceptable in some cases (2007-11-03 over 20071103). I don't know what the effect is of your new duration abbreviations. It's important that someone with access to the right equipment tests those expansions with assistive technology. If it's appropriate to hyphenate the expansions in the time formats, then they should be. • I'm of the view that whilst use of HTML elements should be neutral wherever possible (SPAN, DIV), use of presentational elements such as BR should not feature in our examples. Some of the examples are using BR to change the presentation. These should be reworked somehow. Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] [hAudio] Contributor as an hCard
On 3 Nov 2007, at 15:42, Manu Sporny wrote: The hAudio Draft Specification has a new home: http://microformats.org/wiki/haudio Contributor: “The contents of the element should include a valid hCard Microformat.” Results in: span class=contributorspan class=vcard This is different from the pattern used in hReview for reviewer, which results in: span class=reviewer vcard The hReview form is superior, and already in use. I suggest the hAudio wording be changed to say: A contributor _should_ be an hCard Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[Audio] Playlists and Albums (was: Re: [uf-new] item property)
On 15 Oct 2007, at 10:44, Julian Stahnke wrote: album-title is NOT mandatory. It is only mandatory when you're listing one or more TRACKs. Tracks can be grouped by more than just albums. I'd say album- title should never be mandatory Playlists or charts come to my mind, for example. I'm very out of touch with hAudio development, but this touches on something I've not seen addressed lately. In the context of hAudio what is the difference between a ‘Playlist’ and an ‘Album’? How is an ‘Album’ not just a specialised kind of playlist? Answers by way of links to previous discussions are fine. Thank you, Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Pattern: Presence of Property
Out of the Recipe format development happening on uf-new I came across an interested concept that hasn't come up yet in previous microformats: Quoting Andy Mabbett, then myself: Whether an ingredients is optional or required is important (again, consider the ingredients to hand use case). Agreed, that's a very good use-case. Needs to be included in a language-agnostic manner but writing ‘3 sprigs of parsley (optional)’ is familiar. I would think that ‘Required’ is implied by the absence of ‘Optional’. In this case, we have a property established for the format which is either present or absence. An ingredient is either optional or not. So, lets say you have this in English: span class=ingredient3 Strawberries span class=optional (optional)/span/span Or this in French: span class=ingredient lang=fr3 Le Strawberries span class=optional(en option)/span/span From a parsing POV, we're only interested in whether ‘optional’ is present or not. If it's absent, we'd be assuming ‘required’. We'd be using a pattern whereby the property value is determined from presence or absence of the element, not by the value of it. Now of course this application is early days and we may yet find further requirements or different ways of doing it, but I like the idea of the pattern as it's language agnostic. Also, I think ‘Presence of Property’ is a pretty snappy name. What would people think about this sort of parsing rule being added to the microformats cannon? Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Recipe
On 27 Sep 2007, at 13:51, Andy Mabbett wrote: We can't expect people to use precise measurements for quantities, nor even to explicitly mark up the order of their steps in anything more than flowing paragraphs. But we can allow them to. Fact is, once such a microformat is available, people will use it for whatever recipes they see fit, whatever our intentions. Both of these points are true, and I'm not saying we should actively prevent more flexible use of any format that is developed here, but I think the development of recipe should be focused on food. The brainstorm of nutritional information such as calorie counts is useful but doesn't apply to the aforementioned bomb making. Of course people could use just the required parts of Recipe to define instructions for anything, that's fine. But I don't think we should exclude anything specific to food for the sake of other uses. I maintain that we should build the re-usable microformats (measurement, currency, citation) first; then those that will use them. I completely disagree with this. A Recipe format can be useful and improve publishing without explicit mark-up for measurements and citations. We should not delay development of a format that shows so much existing publishing and interest from publishers because of missing compound microformats which are not attracting the same levels of interest. In the case of Recipe, I maintain that both quantity and ‘source’ would be usefully represented as strings. ‘10g’, ‘One handful’, ‘Three Tablespoons‘ is workable and useful. Similarly, span class=sourceReal Food by Nigel Slater/span is perfectly useful in that form. I think it's a reality of the way in which development currently moves in this community; that development and interest comes in waves. It means to me that forcing dependencies on undeveloped compound microformats, which currently have little interest and backing, will in effect kill development of this format which people are interested in. I think it is much more productive to accept that Recipe is capable of representing quantities and sources well enough with strings, and know that future, more precise microformats (or other technologies developed elsewhere, such as MathML) _may_ come in the future that can enhance the work we're doing now. Price in hListing will be enhanced by a future currency microformat, but even as a string ‘price’ is useful in Listing. The same is true of quantities and citations now. Measurement System (U.S., Imperial etc) I don't see this being useful. Recipes do not use consistent measurements: There are combinations of metric weights and approximate ‘handfuls’ and ‘pinches’. Some recipes publish both metric and imperial measurements alongside each other. In that case, perhaps only one system should be microformatted, to avoid confusing parsers? That would work for situations where two different measurement formats are placed next to a single ingredient, but does not handle different measurements being used in the same recipe for single ingredients. I'm not quite sure which issue you were addressing there. Imagine you want a parser to compile a shopping list based on a selection of recipes; or that you want to provide a web service with a list of the potential ingredients you have to hand; and for it to return suitable recipes? In those cases, four eggs is more meaningful than eggs; and 500g sugar is more meaningful than sugar. Absolutely. Quantity is present throughout examples and all common practice I've ever seen (bar the ingredients listing on the backs of packaging, but that is ‘nutritional information’ rather than a ‘recipe’). The presence of quantity as a sub-part of ingredients is certain for me. My points about the precision of quantity is already laid out above. Whether an ingredients is optional or required is important (again, consider the ingredients to hand use case). Agreed, that's a very good use-case. Needs to be included in a language-agnostic manner but writing ‘3 sprigs of parsley (optional)’ is familiar. I would think that ‘Required’ is implied by the absence of ‘Optional’. Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Recipe
On 25 Sep 2007, at 10:29, Frances Berriman wrote: Just wondered who was last working on the recipe research, how it's going, and what's caused the current stand still? I'm quite keen to pick it back up again. I've a passing interest actually, would be happy to contribute to try and keep ideas rolling. Not sure how much concrete work I can produce since I'm not really going to be publishing anything, but BBC Food sounds like a pretty awesome base for you on that side of things. Regarding the Brainstorm: I'm a bit concerned by the current state of recipe brainstorming. I'll work through it and give some thoughts of where it's gone awry and my view on what I think is feasible and useful as a goal. As the -examples page shows, recipes are published in a huge variety of different ways. As such, I don't think we can expect to create a useful format with very many ‘required’ fields. We can't expect people to use precise measurements for quantities, nor even to explicitly mark up the order of their steps in anything more than flowing paragraphs. We don't seem to be able to expect people to keep ingredients segregated from the instructions or use consistent measurements. But I think if we accept that fluidity, we can still come up with something simple, but robust and useful. I don't think we should get too ambitious nor too generic. Talk on the brainstorming page about being used for recipes for spells in computer games, or for making bombs seems silly to me. I think better to focus on food and maybe some future microformat for those things will be heavily based on this recipe format (much like hListing is on hReview). Going through the proposed fields, which are based somewhat on RecipeML, I'll try to highlight where we've run too far, need to take a breath and step back a little. Recipe_Title Summary Description (one liner) Author (Person) (hcard?) Date (of Publication) License/rights (Copyright or other) Photo (optional, multiple) All are common in all the other formats. That's to be expected here. hCards and rel-licenses abound! Submitter (Person) (hcard?) I don't understand what this is for. It seems superfluous. Source (Book Title etc) Again, I'm not sure if there's a strong case for this. It just be cited in the Summary of the recipe, using a future citeation microformat if/when one exists. Measurement System (U.S., Imperial etc) I don't see this being useful. Recipes do not use consistent measurements: There are combinations of metric weights and approximate ‘handfuls’ and ‘pinches’. Some recipes publish both metric and imperial measurements alongside each other. I don't think there's a reliable way to lock this down and it would be expecting publishers to provide precise information that they don't currently. Instead, I think that parsers that require knowledge of the measurement system should be expected to derive the measurement system from the quantity with each ingredient. ‘10g’ as grams, ‘10oz’ and ounces and so on. Ingredients (each one a separate item rather than block text with count/amount/range/unit broken out too) ‘Ingredient’ is pretty clear to me. The sub-parts are woolier though, as follows: Units need separate microformat: see measure No it doesn't! One day there might be a dedicated measurement format but right now there isn't. Therefore I think that the ‘quantity’ of an ingredient should be considered the same way as ‘price’ in hListing: Just a string which parsers may attempt to understand as required. One day there might be a currency microformat, in which case hListings will naturally adopt it within ‘price’. The same attitude should be used here. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. Ingredient Preparation: such as diced, chopped, sliced, grated, minced, etc. Ingredient importance (e.g. Main, Required, Optional) should be listed as an attribute of each entry. I think all of this is trying to get too specific. For each ingredient it seems appropriate to have an additional descriptive string alongside the name and quantity, which may contain preparation instructions and requirement. You might call it a ‘note’ or ‘description’. Background Information - Optional section to encapsulate information that is useful but not necessarily required for a successful recipe. I think the ‘summary’ would be an appropriate place for this information. I don't see that it needs to be separated. Yield Quantity and Unit (4 pancakes or 5 servings) Preparation Time (overall time) Calories per serving All are reasonable pieces of metadata to optionally include Calories per ounce Seems too specific, and is tied to a measurement format there isn't a reasonable way to represent. Maybe better that ‘calories’ be represented as free text and again the
Re: [uf-new] Currency: symbols and units (Was: microformat granularity: currency and measure)
On 19 Jul 2007, at 23:30, Scott Reynen wrote: span class=money¢abbr title=0.021 class=amount2.1/abbr span class=currencyUSD/span/span I don't agree that ‘0.021’ can be a valid abbreviation of ‘2.1’. The abbreviation pattern still needs to be fixed as is, but there seems to be a common mindset of wanting an ‘alternate representation pattern’, something akin to the current ABBR pattern, with similar applications but without such specific semantics. Ben ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
