Re: [uf-new] Question About Magazine Article microformat.
On Wed, July 7, 2010 22:55, Sunburned Surveyor wrote: I've been poking aroung the Microformats web site and wiki looking for a microformat for magazine articles posted online. I haven't been able to find anything. I'd like to ask if there has been any work or discussion on a microformat for this purpose. See: http://microformats.org/wiki/citation and: http://ocoins.info/ (the latter not a microformat, but still useful). -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] figure microformat
In message [EMAIL PROTECTED], Toby A Inkster [EMAIL PROTECTED] writes I spent a couple of hours today summarising some of the suggestions people have made on the figure-examples page and condensing it down into a draft microformat: http://microformats.org/wiki/figure You last edit to that page was two days ago. Did you mean something else? What do people think? Is it ready to go onto the drafts list or do you think it needs a little extra work? I think that's premature and should have been on a *-brainstorming page before a draft spec was written. Perhaps you might move it to one, where it can be discussed and alternatives proposed? Turning to specifics, I think the dismissal of the include pattern is unfortunate and needs to be reversed (not least because text suitable for use as a caption might be buried in a paragraph else where on the page); and more attention needs to be paid to the proper use of alt and longdesc attributes. Finally I'd like to see one or more use-cases explained - what will parsers actually /do/ with this information? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] figure microformat
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes div class=figure img class=photo src=photo.jpeg alt=Albert Einstein/ a rel=tag href=http://en.wikipedia.org/wiki/Photography;Photo/a of citeAlbert Einstein/cite by span class=contributor vcard span class=fnPaul Ehrenfest/span (span class=rolephotographer/span) /span /div Doesn't Albert deserve his own vcard, too? photo from hcard to replace image http://microformats.org/wiki/hcard#Property_List Not all images are photos. Let's please preserve semantics. cite is just posh Albert Einstein is not being cited, in the above example. If anyone is, it's Ehrenfest. contributor from haudio There is, as yet, no hAudio to take that from, Only a draft, in which the use of contributor is contentious. Also, credit would be more appropriate than contributor for a photo agency, for example. I don't think legend is necessary as it seems to be acting as a container uF? Isn't legend a key to the symbols or pictures in a map? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
On Fri, February 15, 2008 12:59, Tim White quoted: On Fri, Feb 15, 2008 at 12:24 AM, Manu Sporny [EMAIL PROTECTED] wrote: Yes, you are correct. Usually, each Microformat states how this should be handled. So far, the general parsing rule has been use whatever value you hit first if the Microformat can only have one value for the given property. While the example above shows it going right, the example below shows how it can go wrong: div class=haudio div class=vcard The span class=titleComposer/span named span class=fnBob/span created span class=titleAwesome Song/span /div !-- end vcard -- /div !-- end haudio -- [Manu's e-mail has not reached here yet] Wait 'til you try to mark up: span class=vcard haudio span class=fn orgThe Beatles/span' eponymous album. /span Surely: span class=vcard haudio span class=fn org titleThe Beatles/span' eponymous album. /span or: span class=vcard haudio span class=fn org albumThe Beatles/span' eponymous album. /span are better? -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
On Thu, February 14, 2008 13:12, David Janes wrote: Can we make a microformats-old group to endlessly discuss things that were settled more than 12 months ago? First you'd need to define settled. -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Tue, 2008-02-12 at 18:30 -0500, Manu Sporny wrote: That is a very wise interjection... I agree, we should be asking is it safe to say TITLE means title? Yes it is. hcard broke itself when it was decided that title should be defined as Job title or functional position of the object its very specific and really only has something to do with a person when really should have been referring to the object vCard effectively uses job-title, but omits the job- prefix because it is redundant /in that context/. By way of illustration, Lord Peter Piper, Chief Pepper Picker has a title of Lord and a job-title of Chief Pepper Picker (though vCard bundles titles and other honorific prefixes under the latter designation). If we remember that title in vCard is really job-title; we can use title in hAudio to mean [album or track]-title; or we can be more explicit, and use audio-title; or offer a choice of album-title, track-title etc. I favour the latter, for its enhanced semantics. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes Without weighing in on this issue, I'd like to interject a meta-note: While the two are loosely related, was it good to say TITLE means job title? is now a useless question, whereas is it safe to say TITLE means title? is a useful question. In the interest of progressing the discussion, I'd encourage everyone to make more effort to focus on the relevant and avoid polarizing the discussion around the irrelevant. The past can not be undone; let's try to move forward from where we are now. Those who do not understand history are doomed to repeat it. The former questions is both useful and pertinent. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] PROPOSAL: Replace hAudio FN with TITLE
In message [EMAIL PROTECTED], Brian Suda [EMAIL PROTECTED] writes 2008/2/12, Manu Sporny [EMAIL PROTECTED]: After a week, there have been 4 supporting e-mails for the hAudio TITLE instead of FN proposal, and 0 opposing e-mails, I have updated the hAudio specification to note the use of TITLE instead of FN: http://microformats.org/wiki/haudio --- WOW, after 6 days we have made a community wide change effecting 3 years of effort with only 4 people weighing in! I am sorry i haven't been timely enough to offer my thoughts. Just because no one publicly disagrees doesn't mean that everyone agrees to the proposal and that it is acceptable to move forward. I would kindly ask that you rollback your changes until this can be discussed further 4 people in a community is not consensus. Then I'm sure you will ask for the same roll back on the recent change to hCard, which has much wider implications for existing published microformats. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Governance and process (Was: PROPOSAL: Replace hAudio FN with TITLE)
On Tue, February 12, 2008 12:59, Martin McEvoy wrote: On Tue, 2008-02-12 at 07:33 +, Brian Suda wrote: Just because no one publicly disagrees doesn't mean that everyone agrees to the proposal and that it is acceptable to move forward. as usual in this community If someone sees something they DON'T like they just ignore it and hope it will go away. Only when things change do people jump up and down and say how wrong it is! usually without offering any reasons why or any alternatives. That's the way this community has worked since I first came across it; not least because the problems with governance are generally treated in just the way you describe. A few admins have the ability to force through their view of how things should be (up to and including editing published specifications with previously undocumented rules, claimed to have been decided in camera some years ago); the rest of us must, it seems, await their pleasure. Anyone challenging this status quo faces opprobrium, while valid suggestions and reasonable questions are quietly ignored. Some time sooner or later, though, the wider web community will cotton on... -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] hAudio [issue] D4: rel-enclosure does not allow for links to streaming files
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes http://microformats.org/wiki/haudio-issues#2008 D4 Andy Mabbbett said: Thanks for the extra b; I'll save it for the next time someone calls me Andy Mabett. The required use of rel-enclosure does not allow for links to streaming files, which are not cacheable, and are thus outside the scope of rel-enclosure. http://microformats.org/discuss/mail/microformats-discuss/2008-January/ 011344.html Did you read that e-mail, and the page it cites: http://microformats.org/wiki/rel-enclosure ? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Resolution of issues (was: namespaces bad topic for uf mailing lists reminder)
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Is that why you RESOLVED the issue without consulting the list first? What proportion of resolved (sic) issues are debated here first? If Andy did something like that, he'd be up for another ban... Speaking of which I note, with disappointment but no surprise, that none of the issues I raised in http://microformats.org/discuss/mail/microformats-discuss/2007-December/011032.html and: http://microformats.org/discuss/mail/microformats-discuss/2007-December/011033.html have been responded to, by any of the admins. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Dublin Core (was: hAudio FN or Title)
On Mon, February 4, 2008 11:59, Brian Suda wrote: the process also states: There must be a problem to be solved (i.e. a real world use case). No problem, no microformat. The problem has already been stated. Jumping straight to making a generic OBJECT DC format is not the best approach. It is the best - the only - approach for solving the stated problem. Foaf maps properties in it's namespace to Dublin Core. Microformat can easily do the same thing, there is no prohibition against this, as long as the meaning is the same. Just because it is called fn or creator or something else, doesn t mean it can't become Dublin Core properties. If the issue can not be solved with existing microformats, then there are a few options. [...] 4) use something else, like RDFa, eRDF, GRDDL or others. ...or DC. That's what we're discussing. Given the negative, almost hostile, response to the idea here, I wonder if it might be better discussed in a DC forum? -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
On Mon, February 4, 2008 10:30, Martin McEvoy wrote: fn in vcard rfc 2426 inherits its semantics from X.520[2] (2001) 'commonName.' attribute [...The Common Name attribute type specifies an identifier of an object. A Common Name is not a directory name; it is a (possibly ambiguous)...] http://sec.cs.kent.ac.uk/x500book/Chapter.3/Chapter3b.htm It's worth understanding the meaning and usage of object in that context: http://sec.cs.kent.ac.uk/x500book/Chapter.2/Chapter2.htm#2.2%20OBJECTS%20AND%20ENTRIES (aka http://tinyurl.com/35tpfu) as well as remembering that X500 is a standard for distributed telephone directory databases, not intended for film reviews, employment histories, audio recordings or other use cases. -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes We should be using TITLE for the title of audio recordings. So, who is going to make an argument against using TITLE in hAudio? I'm not, but I do think we should allow for distinction between the titles of tracks, albums, works and similar. This could take the form of: album-title track-title etc. or it could be: foo class=album fooclass=title Meddle /foo /foo foo class=track fooclass=title One of These Days /foo /foo The former, hyphenated, pattern could again borrow the DC qualified model, and be treated by parsers as equivalent to title for some purposes, but distinguished from each other, for other purposes. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
In message [EMAIL PROTECTED], Brian Suda [EMAIL PROTECTED] writes 008/2/4, Manu Sporny [EMAIL PROTECTED]: Here are more examples of Microformats using emulated namespaces: country-name (hCard) organization-name (hCard) organization-unit (hCard) --- i do not consider these namespaces. In the vCard RFC the value is called Country Name, Organization Name and Organization Unit with spaces. Since we could not use spaces in a class attribute we had two choices, CamelCase or hypens. We chose Hypes. There was no attempt to do any sorts of emulated namespace, more simply just concatenating space-separated-terms so they could be used in the class attribute. OK, so let's use, say, track title, song title and/ or album title. Oh, they have spaces, so we have two choices... -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio vS hTrack?
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes what does anyone think of this: http://yahoomediaplayer.wikia.com/wiki/How_to_link do you think people are getting bored of waiting for hAudio... Interesting. +1 for their recognition of track as an important label +1 for their use of 'HTTP content-type'; the hAudio spec should suggest this, at least informatively. -1 for their abuse of tabindex, which is an accessibility tool for in-page navigation if they must use it, they could, perhaps, use 1001 as the first track, 1002 as the second, and so on; but that supposes only one album per page. (I'm no expert on the use of tab index; further advice should be sought.) -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)
In message [EMAIL PROTECTED], Danny Ayers [EMAIL PROTECTED] writes I would personally have no objection whether e.g. a song title was marked up with title or fn, as long as this was adequately documented, and the definition easily discoverable. I think we also need to think about the convenience of publishers; not all of whom are very interested in the mechanics of microformats. What will be easiest for them to learn, remember and understand? Which leads me to something Martin mentioned - if HTML Meta Data profiles are used, the whole question becomes a non-issue. By using a profile URI and putting a description of the terms used in the profile on the Web, it's possible for people (and machines) to easily discover the intended meaning. What if the page includes profiles for hAudio *and* hCard? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio FN or Title
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Martin McEvoy wrote: On Fri, 2008-02-01 at 22:09 , Andy Mabbett wrote: The more I consider this, the more I am convinced that class names should not be shared between microformats. For what its worth I think you may be right for example fn was only used in hcard this meant just the name of a person or organization, great stuff powerful and clearly defined. hAudio and hreview re-use fn to mean other things too, haudio it means, a title of a playlist, album, or track and the name of a contributor or organization This is the start of an argument for namespaces: While namespaces are one possible solution, this is not necessarily an argument for that solution to be employed. Andy, Martin - are you proposing 'context-aware vocabularies' or something similar to that? I don't know what you mean by that term. there is no need to pull in the entire Dublin Core metadata vocabulary set. For example, all we would need to pull in for hAudio would be 'dc- title' at this point. That or we would need to be allowed to use 'title' for hAudio, since that is the word that makes the most amount of sense for what we are describing. I think we should be warn of conflating two different issues: 1A microformat, or microformat-like system, for marking up DC metadata in published content; about which I wrote yesterday: http://microformats.org/discuss/mail/microformats-new/2008-February/001385.html (aka http://tinyurl.com/2ut5w9) 2Re-using terms from DC, as a deciding vote, when there is no obvious choice among several possibilities, as with the current debate around hAudio. -- Andy Mabbett * Say NO! to compulsory UK ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio FN or Title
In message [EMAIL PROTECTED], Paul Wilkins [EMAIL PROTECTED] writes On Feb 1, 2008 12:26 PM, Andy Mabbett [EMAIL PROTECTED] wrote: The problem is that people using CMS-hosted pages (including blogs and wikis) can't add DC metadata to page in such systems, where they can't edit the HEAD of the page. That is not a valid problem of the current proposal. The current proposal is not about implementing DC. It's about porting DC over the microformats and using the microformats version of DC instead. Eh? Whatever makes you think that? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio FN or Title
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes an example of how this may look taken from http://microformats.org/wiki/haudio#Multi-part_Podcast_Example div class=haudio p span class=audio-titleDigitalPlanet Podcast/span abbr class=published title=2007102929 Oct 07/abbr /p p div class=item span class=fnForensic computing: is it really possible to delete data from your machine?/span /div div class=item span class=fnGrand plans for getting broadband into Africa/span /div [etc] audio-title is more appropriate than title; but I'm still concerned that item is both vague and insufficiently granular. What happens when a podcast is reviewed, or includes reviews, and the review(s) (or some other microformat) use item? Similarly, this still doesn't address the confusion between hAudio's fn and hCard (or whatever's) fn, as raised previously: http://microformats.org/discuss/mail/microformats-discuss/2008-January/011342.html -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Dublin Core (was: hAudio FN or Title)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes The main disagreement seemed to be in DC's choice of class names... That's only one problem with DC. You fail to explain why you think DC's class (sic) names are a problem. The other problem is that DC itself is more theoretical rather than based on any actual content publishing research/behaviors. On the contrary: DC is based on a deep understanding of the metadata published by the type of organisations for which (and by whom) it was intiially designed. Anyone that wants to look at re-using DC should instead look into helping move the citation microformat effort forward, which has documented DC as one of many previous formats that relate to citations. DC is not only for citations. DC by itself is not the answer. Before you can assert that, you should, at the least, state which question you think applies. http://microformats.org/wiki/citation My above comments not withstanding, more effort towards completing the 'citation' work (and that for several other of the much-needed, pending, microformats) would be a good thing. If this community does not do it, some other group probably will. * It re-uses a vocabulary that is largely accepted in the web semantics community. It's been mostly used to publish hidden metadata in pages that is either ignored or polluted. If so, a facility for using it on visible metadata would be an improvement, would it not? It's not really got much support of tools that support it and do something useful with it There *is* support and there *are* tools, not least in the fields for which it was intended. It is even government-mandated in some quarters. - mostly academic projects. That's not necessarily a bad thing (after all, HTML was first designed for academic projects!). I just wrote up this process FAQ entry regarding re-use whole-sale http://microformats.org/wiki/process-faq#Can_a_microformat_be_class_names_f rom_another_format_vocabulary There is a requirement on the wiki that opinions are marked up as such - see point 4 on: http://microformats.org/wiki/how-to-play Background: Folks new to DC might like to read: http://en.wikipedia.org/wiki/Dublin_core and note in particular the distinctions between simple and qualified DC, and that the former has just 12 properties: 1. Title 2. Creator 3. Subject 4. Description 5. Publisher 6. Contributor 7. Date 8. Type 9. Format 10. Identifier 11. Source 12. Language 13. Relation 14. Coverage 15. Rights (By way of illustration, Qualified DC takes a property, such as date, from Simple DC and makes properties like date.created and date.modifed.) A method of applying DC using HTML class names on published data would be 'A Good Thing', and could be used alongside existing microformats. For example: div class=haudio p span class=audio-titleDigitalPlanet Podcast/span abbr class=published title=2007102929 Oct 07/abbr /p [...] /div could, using a wrapper class to encompass the item to which the DC metadata applies, become: div class=haudio dc-wrapper p span class=audio-title dc-title DigitalPlanet span class=dc-typePodcast/span /span abbr class=published dc-date-created title=2007-10-29 29 Oct 07 /abbr /p [...] /div which could then be parsed by DC consumers, without the need for such consumers to be updated each time a new microformat emerges. Note, for example, the use of: class=published dc-date-created in an hAudio; whereas an hReview would have: class=dtreviewed dc-date-created and an hListing might use: class=dtlisted dc-date-created Whether such usage is called a microformat, POSH or some other term is really a matter of bike-shed colouration. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio FN or Title
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes when, as you say, I try to embed haudio in a hreview, say an album review with more than one track marked up in item things do get messy both in marking up the page and xsl rules. I would say that it IS desirable for hAudio to exist with hreview and although it pains me to say this (In my experience) item and fn are problematic. The more I consider this, the more I am convinced that class names should not be shared between microformats. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Andy Mabbett wrote: On Tue, January 15, 2008 16:18, Manu Sporny wrote: POSITION is a loose descriptor of where the piece fits in if it is part of a collection of some kind. It is most useful when the other pieces are not listed on the same page. Position can be: 1. The position of the track on a CD. 2. Podcast # of the recording. 3. The position on a top-10 list. 4. The physical position on a CD set of an Operatic piece. 5. The side and track # of an LP (ie: A1, B2) 6. Specified in TABLE elements. 7. Can be specified out-of-sequence. Isn't it overloading, to put so many meanings onto one attribute? They're all positions, aren't they? They all have the same meaning. Items 1-5 have different meanings; that's why you were able to list fire items, not just one. How would you mark up position in: At number two in the chart this week is Pink Floyd's Fearless, track 3 on their Meddle album. Or, rather, which of the two different kinds of position would you mark up? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
On Wed, January 16, 2008 10:20, Paul Wilkins wrote: On Jan 16, 2008 10:11 PM, Andy Mabbett [EMAIL PROTECTED] wrote: How would you mark up position in: At number two in the chart this week is Pink Floyd's Fearless, track 3 on their Meddle album. Or, rather, which of the two different kinds of position would you mark up? I would use an include pattern for the information that belongs in multiple sections, which neatly resolves such issues. That's not information that belongs in multiple sections, but - apparently - multiple information that belongs in one section. But please feel free to post an example. -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
On Tue, January 15, 2008 10:08, Michael Smethurst wrote: I suspect I've thrown a red herring into the mix with the mention of classical music... apologies I don't think it is a red herring; I think it's quite important that classical music is taken into account (there is plenty of evidence to show that it's published, after all); otherwise we'll have hPop, not hAudio. My point was really that when a track from an album is played in isolation from that album (so on a radio episode tracklist or in a personal playlist) the track position on the album is still important data. Which means encoding this data as a property of the list ordering wouldn't work here. So I'd vote to keep position as a separate attribute Where's the evidence to show that this is published? I threw classical into the mix cos sometimes multiple tracks on an album can have the same title (dependent on how the record company has segmented the audio). In this case the track number is necessary to disambiguate which track was played Perhaps, but that's also true of pop, rock and other genres, albeit less common - though there is an album, The Best of Louie Louie (Rhino Records) comprising nothing but versions of 'Louie Louie'. In terms of marking up acts and scenes and movements and works and etc I'd encourage hAudio to steer well clear. It's a hideous minefield Surely that shouldn't put us off? Not least because lack of such a facility may impact on uptake. According to the process, we should find a way to mark up what the evidence shows us is published; not just the easy bits. and I suspect hAudio can solve 80% of the problem by avoiding this stuff. I've never been satisfied that it's OK for 1 in 5 cases to be ignored, or, worse, wrong. For an idea of the complexity I'd point semweb minded people at the fine work of Yves Raimond on the music ontology (which incidentally it would be nice to see used in the rdf-a hAudio spec): http://musicontology.com/ Thanks; I'll read that later. -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
On Tue, January 15, 2008 16:18, Manu Sporny wrote: POSITION is a loose descriptor of where the piece fits in if it is part of a collection of some kind. It is most useful when the other pieces are not listed on the same page. Position can be: 1. The position of the track on a CD. 2. Podcast # of the recording. 3. The position on a top-10 list. 4. The physical position on a CD set of an Operatic piece. 5. The side and track # of an LP (ie: A1, B2) 6. Specified in TABLE elements. 7. Can be specified out-of-sequence. Isn't it overloading, to put so many meanings onto one attribute? I don't think we avoided the problem when putting position in there... it takes on the challenges of positional identifiers for audio recordings. If we take position out of the hAudio spec, we lose support for all of the use cases listed above. I don't think anyone wants to not support those use-cases; but to do so in a way which encourages people to drop good, semantic mark-up and use bad, non-semantic mark-up isn't supportable. -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio issue: position
On Mon, January 14, 2008 17:19, Michael Smethurst wrote: In the case of classical music identifying the track played by ordinality on the release is extremely useful. So a way to markup ordinality other than as a list would be preferable In the following, for piece read piece, sequence or some other term: foo class=item start-piecePiece 1, part 1/foo foo class=itemPiece 1, part 2/foo foo class=itemPiece 1, part 3/foo foo class=item end-piecePiece 1, part 4/foo foo class=item start-piecePiece 2, part 1/foo foo class=itemPiece 2, part 2/foo foo class=itemPiece 2, part 3/foo foo class=item end-piecePiece 2, part 4/foo or: foo class=piece foo class=itemPiece 1, part 1/foo foo class=itemPiece 1, part 2/foo foo class=itemPiece 1, part 3/foo foo class=itemPiece 1, part 4/foo /foo foo class=piece foo class=itemPiece 2, part 1/foo foo class=itemPiece 2, part 2/foo foo class=itemPiece 2, part 3/foo foo class=itemPiece 2, part 4/foo /foo though the latter again causes problems in tables (unless a TBODY is used for each piece; which is arguably good practice). Item is an absolutely awful (and semantically-barren) name; it might be best to use piece and subpiece or something like that, assuming that the piece's name is shown (unlike the above examples). Perhaps you have some real examples in mind? How any levels of sub-division are there? I have recently posted links to others' efforts to solve the problem of codifying the structure of disparate types of music: http://tinyurl.com/2uval5 on the wiki. In particular, see: http://oakroadsystems.com/genl/itunes.htm -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: hAudio issue: position
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Hello Andy On Fri, 2008-01-11 at 20:27 +, Andy Mabbett wrote: I think that providing an alternative to OL in that manner, not to mention encouraging people to use it by having it as an example in the spec, is no better then p class=heading By which I meant ...than p class=heading I am not going to argue with you on that point I agree in principle, but unlucky for us the real world is much different to the world we are trying to create, you know as well as I that a lot of designers still use tables for layouts, most are not interested in validating their documents, or understand semantics beyond web3.0(yuck) or twine(lol), I really don't think we should accord such bad behaviour credit by catering for it at the expense of good practise. so hAudio has to fit in I don't think that's a given. , in order to be adopted, this is why the compromise, allow authors to publish hAudio in tables (If they so wish) and so making hAudio easier to adopt. hAudio in tables is a separate issue to bad mark-up, Tables may well be valid, semantically-correct and the best way to mark up a page about number of audio recordings. The use of microformats in tables is itself an issue in need of further thought. For example (this is an illustrative question, not a proposal), should: th class=fn scope=rowName/fn indicate that each cell in that column is to be treated as an FN if there is, say, a vCard across that cell's row? If not, how else might that be achieved? -- Andy Mabbett * Say NO! to compulsory UK ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: [uf-discuss] hAudio issue: position
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes I have cross posted this email to microformats new as I believe hAudio is still in development and any Issues anyone may have with haudio should really be posted there. Fair enough. On Thu, 2008-01-10 at 23:35 +, Andy Mabbett wrote: The recommended use of position in hAudio: http://microformats.org/wiki/haudio#Complete_Album_Example is contrary to the good practice, semantic use of ordered lists (OL). Position was a late addition because most of the examples we were studying used tables in the design of their web pages, we also found that XOXO or OL doesn't work in tables http://microformats.org/discuss/mail/microformats-new/2007-June/000482.html Is position needed to sequence items, or to signify their position of the track on the original album. If the former, then surely order in the source code (in a list, table or whatever) should suffice. If the latter then what's the use case, and which examples support it? Where are the examples of tracks listed out of sequence, in the source code, but with a sequence indicated in content?? so now you can do both, use an ordered list without marking up position and also use hAudio in tables with the ability to markup position. I think that providing an alternative to OL in that manner, not to mention encouraging people to use it by having it as an example in the spec, is no better then p class=heading -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio rel-enclosure linking issues
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Fri, 2008-01-11 at 21:00 +, Andy Mabbett wrote: *download *stream I think rel-enclosure is still suitable for the above two examples rel-enclosure is [...] any single object, thing that can be downloaded and cached to a users hard drive, or portable device In addition to my previous comments about off-site files, I'm not convinced that a stream is (as the rel-enclosure spec has it) intended to be cached. *source for links to .html files, etc., which link in turn to one of the above. you may be on to something here a link pointing to a page where a file may be downloaded but is not a rel=payment url Even if it is a payment URL. The payment page may not link directly to the file. if you are pointing to a html file you can use a bit of POSH rel=section may be a better way of indicating that the following page is to be considered part or the referencing document and we are not inventing something new? If site A links to a page on site B which inks to file C, that does not make the page on B a section of that on A. If rel-license becomes part of hAudio (a no-brainer, surely?), I think the use of rel-licence already implicitly exists in haudio it just hasn't been discussed yet, i don't see anything wrong with adopting rel-licence +1 from me anyway ;) Though of course, current practise may not be to have license terms as links. The text: pThe following mp3 is in the public domain./p requires a CLASS, not a REL. I think there is a general issue with requiring @rels where publishers normally use text, not links; contrary to: http://microformats.org/wiki/microformats microformats are not... an attempt to get everyone to change their behavior... and: http://microformats.org/wiki/principles adapt to current behaviors. Though I see no reason why microformats should not use both, with the same value. In other words foo class=value == a rel=value That would also be beneficial for Wikis such as ours, where rel values cannot be used by editors. [Issue logged at http://microformats.org/wiki/rel-issues#Open_issues ] -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hCalendar: opening hours
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes Recurring events are largely uncharted territory in hCalendar, but it has been discussed. See, for example: http://microformats.org/wiki/hcalendar-brainstorming#Recurring_Events http://www.xfront.com/microformats/hCalendar_part2.html The later references an example recurring event: http://www.xfront.com/microformats/examples/hCalendar/example02/revised-PTI.html which Operator parses but X2V does not (yet); and a second example, specifying multiple dates, which Operator does not recognise: http://www.xfront.com/microformats/examples/hCalendar/example03/XML-conference.html Do any other parsers yet recognise such mark-up? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes TRACK in the way Some on the list mean it is current popular slang for what is a composition or a song the stuff you actually hear through your speakers or read about on the Internet, very nice in your retro 50s to 80s world when you were buying the latest groovy track by Cliff Richard but... the world has moved on Apparently not, according to the evidence presented. what will a track be in the near future? To me as non-existent as Vinyl and CD's Your personal hypothesis of some future development carries no weight. If we are going to use Slang to mark up hAudio why not class=choon its as good a word as any? Do we have any evidence that people, in the wild, are using choon to refer to individual pieces of music, on their web pages? No. Do we have any evidence that people, in the wild, are using track to refer to individual pieces of music, on their web pages? Yes. all I have to go on is the Field definition on the wiki http://microformats.org/wiki/audio-info-proposal#Track and the principles of designing microformats http://microformats.org/wiki/principles and the evidence. [...] a container that means nothing Let's use a term that means something. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
On Mon, October 15, 2007 10:07, Michael Smethurst wrote: I need to mark up performance/set lists for Glastonbury, the Proms etc In these cases track would be plain wrong How so? Also nested items/haudios would allow you to mark up classical works/opera (as opposed to perfomances/recordings). In the case of an opera: Haudio - opera haudio - act haudio - scene haudio - aria Or is this too much of a corner case? I don't think so; though the current evidence probably doesn't cover them; and more should be gathered. (I have previously commented on the problem that our evidence collecting, in general, may be deficient and unrepresentative; but that's a whole other debate.) -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes It's my understanding that item in microformats was intended purely as a delimiter, with the same - empty - semantic value as SPAN and DIV in HTML. It is a container for subproperties (or a submicroformat) , in hReview, similar to how adr is a container for subproperties. Quite, we use adr not item, because adr (meaning address) is a more precise, and thus more semantically meaningful, container - it names the thing it contains. The hReview spec is unhelpful in this regard, specifying it thus: item info. required. fn (url || photo ) | hCard (for person or business) | hCalendar (for event) where item is in CODE tags but info. is not, and is not explained. What help were you expecting? Perhaps I can add it either in the specification or in a tutorial / authoring page. A definition of item, in the context of the review microformat, without the apparently stray textual fragment of info. The use of pipe separators and parentheses, without a clear statement of their meaning, is also unhelpful. The subsequent definition gives: [...] and the use of item in the examples is not consistent: Could you provide a specific explanation of which example is inconsistent with which statement in the prose of the specification? Now you're asking me to provide examples of something I haven't stated. The examples below are consistent with the specification quoted above but not with each other. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Apologies for the reply to my own message but I wanted to make sure the tone was not misunderstood. Thank you, but unnecessary; it wasn't. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes I support re-use of item as well, rather than inventing a new term that has apparently the same semantics, which would violate one of our naming principles: re-use the same name to mean the same thing (instead of using two names to mean the same thing). The two names do not mean the same thing. item means a thing track (for example) names that thing, and distinguishes it from other things. And regardless of the number of people, if you can point to a principle supporting your position, your position is stronger. Science is not a democracy. Nether is science the act of citing made-up principles. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Sun, 2007-10-14 at 08:50 -0500, David Janes wrote: Note that a did a moderate amount of work on this last year [1] yes I did notice that you have done a lot of work already to support an item design pattern or submicroformat [1] http://microformats.org/wiki/item In which, David Janes said: hItem should [...] not be a general purpose dumping ground for attributes -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Justin Maxwell [EMAIL PROTECTED] writes Track is familiar and common. However, it's nothing more than a distortion of meaning through popular usage -- tracks in a vinyl record (similar to the use of patch for electronic musical instrumentation stemming from the days of patch cables). The CD industry picked up this term as well as it replies to physical sectors on the disc itself. However, there is no track in data and we should eliminate an unnecessary literal abstraction (one that will eventually require explanation) by calling it as such. What do you mean by there is no 'track' in data? I thought we created microformats by looking at evidence, not considering personal opinions and supposition about what may be understood at dome unknown point in the future. If people refer to a songs or other recording as a track - as the evidence [1] shows they do - then we should use that. [1] - http://tinyurl.com/yvekd2 http://tinyurl.com/ywg8qu http://tinyurl.com/2kq96z -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Julian Stahnke [EMAIL PROTECTED] writes I don’t think you can make album-title mandatory. Unless you can tell me what album Martin Luther King’s ‘I have a dream’ speech is on ;) 'Great Speeches of the 20th Century', issues free with the Guardian newspaper this summer (I have a copy right here next to my PC): http://blogs.guardian.co.uk/podcasts/2007/04/newsdesk_notes_for_friday_apri_4.html Do I get a prize? ;-) -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Justin Maxwell [EMAIL PROTECTED] writes my initial reaction is that an album without a name shouldn't be assigned one for the sake of microformats Again: what do publishers do? *Amazon uses a title: http://tinyurl.com/34gfjo *Play.com uses a title: http://tinyurl.com/2pzznr *HMV uses a title: http://tinyurl.com/34z9pm and so on... -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes If people refer to a songs or other recording as a track - as the evidence [1] shows they do - then we should use that. [1] - http://tinyurl.com/yvekd2 http://tinyurl.com/ywg8qu http://tinyurl.com/2kq96z Seems like you are NOT making your point Thank you, but my point was stated explicitly. [1] http://tinyurl.com/2vzag4 [2] http://tinyurl.com/2jvbms [3] http://tinyurl.com/2lj5x2 [4] http://tinyurl.com/2lbs9a [5] http://tinyurl.com/343jjy [6] http://tinyurl.com/2tc9ch I could go on all night giving you different examples of different meanings of TRACK, I hope I don't have to. Please don't feel you have do something so pointless on my account. Am I making My point? Not clearly, no. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Justin Maxwell [EMAIL PROTECTED] writes On Oct 14, 2007, at 12:10 PM, Andy Mabbett wrote: What do you mean by there is no 'track' in data? I thought we created microformats by looking at evidence, not considering personal opinions and supposition about what may be understood at dome unknown point in the future. and i thought i was helping define a microformat, not practicing my skill in public debate. so, we're even. :) Given that this is a debate, carried out in public, I can't see why you were under the misapprehension that you're not doing both. moving on... there is no 'track' in data. I wrote that thinking it was self- explanatory and obvious, so, sorry if it seemed too abstract. a track refers to a physically demonstrable track in a recording medium, whether that track is a set of continuous grooves divided by physical markers, or a series of sectors on a CD/DVD divided by start and end markers. In short, track is a term reserved for physical, tangible media. And now used to refer to a song or other piece of music. We're concerned with current usage, not etymology. If people refer to a songs or other recording as a track - as the evidence [1] shows they do - then we should use that. [1] - http://tinyurl.com/yvekd2 http://tinyurl.com/ywg8qu http://tinyurl.com/2kq96z good point! however, people also refer to items as songs, Some tracks are songs, others are not. All songs, though, are tracks. but a google search on 'spoken word' songs (and similar variations of non- musical recorded genres, such as audiobook +songs) gives evidence that popular usage is incorrect as well. I don't see what it is, that leads you to that conclusion. So it's easy to find evidence of people using both track and song, but neither are correct. If we have the opportunity to define a standard, why not go with one -- item -- that is universally correct? Because it's semantically barren. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio proposal: ITEM/TRACK
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes the way Manu phrased this gave me an idea for a third solution to this problem: use class=haudio alone. Any hAudio without an album property is already assumed to be a single track. If the only reason we're specifying this with an additional class name of track or item is to allow for track listings in name-only shorthand, why don't we just allow that shorthand with hAudio itself? I.e. make the following semantically identical: span class=haudiospan class=fnMy Way/span/span span class=haudioMy Way/span How would you show the artist and duration of that track, using the latter model? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes [1] http://microformats.org/wiki/item In which, David Janes said: hItem should [...] not be a general purpose dumping ground for attributes Item suits our type purpose definition I'm not clear whether you're just expressing an opinion; or speaking on behalf of some undeclared group, when you use our. The definition of item on: http://microformats.org/wiki/existing-classes does NOT match the use proposed for item in hAudio. I also think that if we go ahead and use TRACK then we WILL be causing huge problems when it comes to future microformats as TRACK has more than one meaning not many of which match out Definition TRACK has many meaning and no single meaning in the real world As do class, contact, experience, key, label, latitude, note, profile, region, sound and many other class names already used in microformats. I don't see the relevance of track's other meanings, to this issue. How would you feel when it comes to marking up hRacetrack, or hTraintrack and you find that hAudio has already defined TRACK to mean A container for another hAudio item Perfectly relaxed; unless you intended to wrap hRacetrack or hTraintrack (!) in hAudio. Are you suggesting we should use album-track instead of just rack. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Single Track album known span class=haudio span class=item trackNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span What is item telling us there, that track isn't already telling us? Album with a couple of tracks, more detailed: span class=haudio span class=albumBest Before 1984/span span class=contributorCrass/span span class=itemspan class=trackNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=itemspan class=trackNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=itemspan class=trackNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span /span Why is track nested in item in the latter example, but not the former? Single Track album known span class=haudio span class=item fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span What is item telling us there, that fn isn't already telling us (or vice versa)? Album with a couple of tracks, more detailed: span class=haudio span class=albumBest Before 1984/span span class=contributorCrass/span span class=itemspan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=itemspan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=itemspan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span /span 4:46, in plain English, is not an abbreviation of P268T. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] I propose a new microformat for poems.
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes l span class=l line and span class=line would be better. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Single Track album known span class=haudio span class=item fnNagasaki Nightmare/span span class=albumBest Before 1984/span span class=contributorCrass/span /span What is item telling us there, that fn isn't already telling us (or vice versa)? Item is being used as a composite http://microformats.org/wiki/item#3._As_a_composite not as a formatted name or title I believe that that item composite pattern is just a brainstorm, and not agreed practice. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Many of us on the list agree with Tantek (including Me) that we SHOULD use FN, the trouble is Some on the list want to use *Track* and *audio-title* or *recording* because they believe the properties we are trying to describe SHOULD mean something specific, which I tend to disagree with, as the way I have proposed hAudio, *Item* contained within hAudio is a *track* fn is fine, so long as it's clear (from a higher-level attribute) what is being named, as in this pseudocode: litrackfnSpeak to me/fn/track/li litrackfnBreathe/fn/track/li litrackfnOn the Run/fn/track/li litrackfnTime/fn/track/li Whereas that may be OK, this: lifnSpeak to me/fn/li lifnBreathe/fn/li lifnOn the Run/fn/li lifnTime/fn/li is not. Would we use fn, though, if hCard had been created before vCard? I wonder though if we could maybe use item instead of track somehow span class=haudio span class=albumBest Before 1984/span span class=contributorCrass/span span class=itemspan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=itemspan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span span class=itemspan class=fnNagasaki Nightmare/ span – abbr class=duration title=P268T4:46/abbr/span /span Item is semantically empty, other than as a container. We might as well say thing. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes On Oct 13, 2007, at 10:13 AM, Andy Mabbett wrote: I think we should resolve the abbr-accessibility elephant in the room, once and for all, before introducing any new mis-uses of abbr. After all, it was identified over a year ago... And it could easily go unresolved for another year. It could well do. For shame. Can anyone here give an undertaking not to loose their sight, during that time? Does everyone here think disability only happens to other people? Any resolution to abbr problems can be applied to hAudio in the future just as easily as every other microformat already using abbr. Yeah, who cares about cripples. What are they doing using our web, anyway? Let 'em wait. That shouldn't slow down hAudio progress. In this case, someone wrote P268T as a long form of 4:46, when it should have been P286T. Typo aside, that follows established microformat use of abbr and ISO 8601. I didn't even notice the typo; 4:46, in plain English, is no more an abbreviation of P286T than it is of P268T. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: audio-title/album-title vs. recording/album
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Item is semantically empty, other than as a container. We might as well say thing. what is a track on your CD? Just a space, gap or marker nothing more On the contrary, it has a distinct meaning, which defines it as being apart from the other items on a CD, such as an index, the performer, its catalogue number, or whatever. -- Andy Mabbett * Say NO! to compulsory UK ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio current thinking?
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes I am proposing that we re-use *item* from hListing, hReview and hItem instead of creating another microformat *track* the status of this is still unknown Does this sit well with everybody? No. You seem to have overlooked my concerns about the semantic impotence of item. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Sat, 2007-10-13 at 19:47 +0100, Andy Mabbett wrote: In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Item is semantically empty, other than as a container. We might as well say thing. what is a track on your CD? Just a space, gap or marker nothing more On the contrary, it has a distinct meaning, which defines it as being apart from the other items on a CD, such as an index, the performer, its catalogue number, or whatever. Perhaps I am thinking to literally Item is just an Item? its the contents of which that describe just what kind of item it is? It's my understanding that item in microformats was intended purely as a delimiter, with the same - empty - semantic value as SPAN and DIV in HTML. The hReview spec is unhelpful in this regard, specifying it thus: item info. required. fn (url || photo ) | hCard (for person or business) | hCalendar (for event) where item is in CODE tags but info. is not, and is not explained. The subsequent definition gives: item info:: This required field MUST have at a minimum the name (fn - the formatted text corresponding to the name, except for an event item which MUST have the summary property inside the respective hCalendar vevent) of the item (an hReview describes only one item), SHOULD provide at least one URI (url) for the item, and MAY provide at least one URL to a photo or depiction (photo) of the item. For items of type person or business, the item info (fn, url, photo) MUST be encapsulated in an hCard. For items of type event, the item info SHOULD be encapsulated in an hCalendar vevent. Non-URL unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN (url) for the item. Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g. class=item vcard). However, when using item info subproperties (fn, url, photo), they MUST be nested inside the item element. and the use of item in the examples is not consistent: *div class=description item vcard p span class=fn orgCrepes on Cole/span is one of the best little creperies in span class=adr span class=localitySan Francisco/span /span. Excellent food and service. Plenty of tables in a variety of sizes for parties large and small. Window seating makes for excellent people watching to/from the N-Judah which stops right outside. I've had many fun social gatherings here, as well as gotten plenty of work done thanks to neighborhood WiFi. /p /div *div class=item vcard div class=fn org summaryCafe Borrone/div span class=adr span class=street-address1010 El Camino Real/span, span class=localityMenlo Park/span, span class=regionCA/span span class=postal-code94025/span, /span span class=tel+1-650-327-0830/span; a class=url href=http://cafeborrone.com;cafeborrone.com /a /div *span class=item a class=url fn href=http://www.amazon.com/exec/obidos/ASIN/B89CJI/; img src=http://images.amazon.com/images/P/B89CJI.01._SCT HUMBZZZ_.jpg alt=Album cover photo: The Postal Service: Give Up. class=photo / The Postal Service: Give Up /a /span *div class=item a lang=zh class=url fn href=http://www.imdb.com/title/tt0299977/; Ying Xiong (span lang=enHERO/span) /a /div -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: hAudio current thinking?
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes [1] Single Track album known span class=haudio span class=track span class=fnNagasaki Nightmare/span /span span class=albumBest Before 1984/span span class=contributorCrass/span /span [5] Album with a couple of tracks, more detailed: span class=haudio span class=albumBest Before 1984/span span class=contributorCrass/span span class=track span class=fnNagasaki Nightmare/span – span class=duration4:46/span /span span class=track span class=fnNagasaki Nightmare/span – span class=duration4:46/span /span span class=track span class=fnNagasaki Nightmare/span – span class=duration4:46/span /span /span How would these work, for tracks on a compilation album, by different artists? Or tracks on a one-album artist, but where one features a guest vocalist? -- Andy Mabbett * Say NO! to compulsory UK ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Video, Closed Captions, and Audio Description Tracks
The BBC iPlayer apparently uses three downloads: 1. Standard. 2. BSL. 3. Audio described (almost twice the size of Standard). All three have closed-captioning. Source: http://www.bbc.co.uk/blogs/access20/2007/05/audio_description_on_the_iplay.shtml How can the proposed microformat(s) for TV streaming and video downloads cater for captioning? -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Pattern: Presence of Property
On Tue, October 9, 2007 13:43, Ben Ward wrote: say you have this in English: span class=ingredient3 Strawberries span class=optional (optional)/span/span Surely: span class=ingredient optional3 Strawberries (optional)/span ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Measurement brainstorming (was: Measure currency)
On Fri, October 5, 2007 15:31, Chris Newell wrote: That would be: abbr class=hmeasure title=2m22msup2/sup/abbr using m2, or whatever is that standard for representing square-metres. Given that parsers must accept the formats includes [unit-code][number] would: span class=hmeasurem23/span represent 23 metres or 3 square-metres? Note that I said or whatever is [the] standard for representing square-metres. -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming
On Fri, October 5, 2007 15:38, Chris Newell wrote: If we applied a similar restriction to the measure strawman proposal There is a separate thread for discussion of that proposal. e.g. [number][space][unit-code] I would withdraw my concerns about the potential parsing problems. People publish measurements, without spaces, such as 4cm in the wild. -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Measurement brainstorming (was: Measure currency)
In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes Taylor Cowan's eelgant sugegstion in the Currency discussion: http://microformats.org/discuss/mail/microformats-new/2007-September /000915.html talkes the form: abbr class=currency title=USD100one hundred bucks/abbr abbr-accessibility issues notwithstanding, I think we can apply that to measurements, also I've posted a new measurement microformat straw-man on th wiki: http://microformats.org/wiki/measure-brainstorming#Straw_man comments and suggested amendments welcome! -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming
In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes In message [EMAIL PROTECTED], Taylor Cowan [EMAIL PROTECTED] writes Pretending to forget all that we've know up till now about microformats, what if we just wanted a way for web page designers to make their currency amounts unambiguous with respect to currency denomination and amount? That's certainly what I want; and to be able to include dates). I've posted a new money microformat straw-man on th wiki: http://microformats.org/wiki/currency-brainstorming#Straw_man comments and suggested amendments welcome! -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] I propose a new microformat for poems.
In message [EMAIL PROTECTED], Michael Walker [EMAIL PROTECTED] writes I can't seem to find a microformat for poetry. What would be the use-case? In other words, what would parsers (browsers or browser plug-ins; other websites) do with poems marked up that way? You should also look at the work which has been done on a proposed citation microformat: http://microformats.org/wiki/citation since a poem on a website is, effectively, cited. Then you should compile examples of poems published on the web: what data is commonly included? You might find, for example, that most poems published are dated, or cre4dit the author. But what else? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes IMO, we must conceptually distinguish the notion of *money amount* and the notion of *price*. A money amount is an amount of a given number of units of currency. A price is an equivalence relationship typically between a money amount and another amount in any measurement unit. Some prices are expressed without using currencies. Some prices are prices of one currency in another one (as in 1 euro = 1.41 dollars). The amount+unit is not a relation and does not change over time, and does not have to be dated. A price does change over time, and should be dated. In Andy's example above, the date is not a property of the hmoney class, but of a TBD hprice class. I don't see any advantage in making such a distinction, nor any problem in not doing so, Perhaps you could enlighten me, with real-world published examples? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Finishing Currency
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Andy Mabbett wrote: My preference would be to use the previously-described [[title-trigger]] solution: span class=hmoney title-trigger title=USD 0.1 10 cents /span In the latter, the rule for the title is that it MUST contain only an ISO 4217 currency code and a numeric value, (in either order) separated by a space. Another solution, conceptually, would be to use the ideas used in XBRL, and markup on a separate page/footnote/legend the definition 1 cent is 1/100th of a US dollar, and then refer to that definition using the include pattern from the page containing the 10 cents content (I haven't figured the XHTML yet, though). Can you provide examples of people publishing such a legend, alongside prices and other such monetary amounts? Of the two models, which do you think would be easier, for publishers? Which do you think would be more efficient - +/- 1 million publishers make that statement, including it in the code of, say, 100 parsers? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Alternatively, money could be a subset of hMeasure, with ISO 4217 codes as units: span class=hmeasure abbr class=currency title=USD$/abbr span class=amount5/span /span It could be... but I'd rather not go down the hMeasure route until examples have been collected. We have enough examples for currency via hAudio to come up with the first draft of currency. Perhaps in the future, currency will be a subset of hMeasure... but that is getting ahead of ourselves. I think it's an either/ or choice; not one of do one now them incorporate it in the other. *sub-divisions (cents, pennies, etc.) I think we should, perhaps, set aside archaic currencies for now. +1 - no need to address archaic currencies right now... don't even know if regular publishers even mark up these figures. Do we have any non-niche examples of that happening? Yes (for some value of non-niche). It may even be necessary, for the first draft, to also set aside the use of subdivisions. I think the currency-issues page has a good proposal for how we deal with subdivisions[1]. I'm fine with setting this aside for right now, but I think it something that could be agreed upon within a week or two. Since writing the above, I've made another post addressing this; there are issues relating to abbr-accessibility; I'd like to see the latter resolved, but fear how long that will take... -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Recipe
In message [EMAIL PROTECTED], Ben Ward [EMAIL PROTECTED] writes On 28 Sep 2007, at 13:03, Andy Mabbett wrote: Then we run the risk of allowing the higher level microformats to de-facto define the lower -level, (As hAudio is doing with currency); effectively outside the process. I mean: If Listing was to not only specify a place for ‘price’ but also to identify the ‘currency’ of that price, that would be wrong in my view and would be encroaching on work that I totally agree should be done on a dedicated format. I referred to hAudio, not hListing, which is doing just that. I'm all for trying to revive development of the other formats. Definitely a Good Thing. But I don't think it should be blocker on Recipe in the event that it developed sooner. I didn't suggest that anything be blocked; I just recommended the way in which we should focus our efforts. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Finishing Currency (was: Recipe)
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes There only seems to be one issue with the current proposal: http://microformats.org/wiki/currency-issues#Problem That's the issue of 10 cents having no whole-currency identifier. Some of the solutions there, including my own, are sub-optimal, not least because their abuse of abbr causes accessibility problems. Since my last post on the matter, I have given this extra thought. We could use: abbr class=hmoney title=USD 0.110 cents/abbr which has the problem that GBP is, itself, an abbreviation. This could be expanded thus: abbr title=10 cents abbr class=hmoney title=USD 0.110 cents/abbr /abbr though I have yet to ascertain the accessibility of that model. My preference would be to use the previously-described [[title-trigger]] solution: span class=hmoney title-trigger title=USD 0.1 10 cents /span In the latter, the rule for the title is that it MUST contain only an ISO 4217 currency code and a numeric value, (in either order) separated by a space. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming (was: Measure currency)
In message [EMAIL PROTECTED], Frances Berriman [EMAIL PROTECTED] writes On 28/09/2007, Andy Mabbett [EMAIL PROTECTED] wrote: Also, I've previously explained why historic amounts should be dated. This could be achieved by: span class=hmoney ...which cost abbr class=currency title=USD$/abbr span class=amount5/span in abbr class=date title=1923-10October 1923/abbr. /span though a more specific class-name (money-date, say) might be advisable. Interesting. Would date/time sensitive money in the case of stocks and shares apply in this way too, do you think? I don't see why the date couldn't serve both purposes: span class=hentry hmoney Google shares were at abbr class=currency title=USD$/abbr span class=amount12.34/span as at abbr class=updated money-date title=2007-09-28T11:20+01:00 6pm, 28 September 2007 /abbr. /span (accessibility issues not withstanding) If the date occurs once on the page, it could be included as an object. Or would that be reliant on publish date of where the information is displayed? (Not that I know much about SS, just occurred to me it's a much more common varying value) The publish date would be unreliable, as a news site, say, might be published, reporting yesterday's stock prices. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Recipe
In message [EMAIL PROTECTED], Ben Ward [EMAIL PROTECTED] writes 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. Then we run the risk of allowing the higher level microformats to de-facto define the lower -level, (As hAudio is doing with currency); effectively outside the process. A Recipe format can be useful and improve publishing without explicit mark-up for measurements and citations. Useful to a degree, but less so than with semantic markup for those items. 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. Then we're in danger of letting populism override good practise. 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. Again, useful to a degree, but less so than with semantic markup within that span and the strings. 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. Or we could just encourage more participation in developing those microformats. Why do you think there is little apparent interest, given that such data types vastly out number recipes, audio downloads, listings or whatever? Are people doing the fun stuff and neglecting the housework? I think we could, if we put our collective mines to it, have first-draft currency (even if only for current, decimal currencies) and measurement (even if only for metric values) microformat in a few weeks (and, again, doing so before Firefox 3 goes live would be A Good Thing [TM]). Surely no-one can deny the evidence that such data is widely published? 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. Then we have to revise the Recipe spec, and update all the parsers... 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. I meant the former (add 125g or 4oz of butter). 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’. Agreed. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Finishing Currency
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Another solution, conceptually, would be to use the ideas used in XBRL, and markup on a separate page/footnote/legend the definition 1 cent is 1/100th of a US dollar, and then refer to that definition using the include pattern from the page containing the 10 cents content Andy Mabbett wrote: Can you provide examples of people publishing such a legend, alongside prices and other such monetary amounts? See http://investor.google.com/fin_data.html - top legend. These are very common in tabular reporting. I don't see anything like 1 cent is 1/100th of a US dollar on that page. Of the two models, which do you think would be easier, for publishers? I think in your example, the easiest for publisher would be to mark up cent as the unit/denomination and as the currency as in: span class=hmoney10 span class=unit title=centspan class=currency title=USDcents/span/span/span You didn't answer my question; and your example has titles on spans. How do you think they would work? Which do you think would be more efficient - +/- 1 million publishers make that statement, including it in the code of, say, 100 parsers? A parser can embed in its implementation the definition that a cent = one 100th of a dollar. Or, this definition can be declared somewhere, ideally marked up via POSH so that the parser is generic. So are you now retracting your suggestion that publishers include such statements on their pages? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes In Andy's example above, the date is not a property of the hmoney class, but of a TBD hprice class. I don't see any advantage in making such a distinction, nor any problem in not doing so, Perhaps you could enlighten me, with real-world published examples? The advantage is less confusion. If I'm a publisher and I need to mark up POSH the following The Euro stood at 1.41 US dollars in September 2007, We don't want publishers to mark up: The Euro stood at span class=money1.41 span class=currency title=USDUS dollars/span in span class=dateSeptember 2007/span /span. I'm not aware that anyone has suggested that that is what we want. Of course that is, unless you think the following is not better a better reflection of the intent of the author: span class=exchangerate [...] Nor do I see any proposal for marking up exchange rates. This is a proposal for marking up amounts of money in single currencies (which could I agree, be combined into an exchange rate microformat at some later date. I looked at most of the historic prices examples you presented: http://microformats.org/wiki/currency-examples#Historic_prices For what I can see, in most of these examples, the datetime near a money amount usually related to the relationship between a currency and another, or a currency and a commodity, not to the currency itself. For some value of commodity: In 1950 the average weekly wage was X The Beatles first single sold for one shilling The last Monet painting to be auctioned fetched $95 million in 2005 When a datetime is nearby, it usually refers to the datetime of the posting, or of the general context in which the events described must be taken. The latter is what's being discussed here. In other words, in most cases and example shown, the datetime of the money amount is implicit, inferred from the context, not explicit. I don't follow. Theses date time should not be marked up as part of the money amount, but as part of a price class, article class, or exchangerate class. There is no proposal or such classes; if you are making such a proposal, then I'm afraid your reasoning is still not clear to me; and neither is your claimed reduction in confusion (in fact the reverse). sA datetime explicitly linked to a money amount is much rarer. The only case I can think of where a date is directly related to a currency is in Damage in Bay County, Florida alone totaled US$50 million (1975 dollars) http://en.wikipedia.org/wiki/Hurricane_Eloise. In this example, you are correct, we should have: Florida alone totaled span class=hmoneyspan class=currency title=USDUS$/spanspan class=value title=500050 million/pan span class=date(1975 dollars)/span/span 1975 dollars is not a meaningful date (I'm not even sure it's meaningful English). So, while I can find an example that support your feature suggestion, I believe the above example where the date of the currency is not implicit is rare enough to be left aside for now for the purpose of moving this proposal forward and avoiding confusion within publishers. I don't believe it is rare; I could provide many further examples, but they would just involve repetitions of the models already discovered. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency brainstorming
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes I believe the above example where the date of the currency is not implicit is rare enough to be left aside for now for the purpose of moving this proposal forward and avoiding confusion within publishers. +1 - this seems like a fairly rare case (hardly any examples to date) Examples of such usage have been provided; past experience is that quantitative evidence is of little interest to the community. -- 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)
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] hAudio ISSUE #8: hAlbum is redundant
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Most of hAlbum's properties overlap with hAudio. In fact, the only two properties that do not overlap with hAudio are 'album-title' and 'track'. It has been proposed that we merge these two properties into hAudio You prose: # If only 'album-title' is specified, then the hAudio is an album. # If only 'audio-title' is specified, then the hAudio is a song/speech or other singular work. # If both 'album-title' and 'audio-title' is specified, then the hAudio is a song that is part of an album. I think those names are confusing; they should be: albunm-title + track-title or simply: album + track I'm also not clear why, for two tracks on one album, three hAudio microformats are required. Why not: div class=haudio span class=albumLive Phish, Volume 15/span span class=contributorPhish/span span class=track span class=track-titleSanity/span (abbr class=duration title=3485:48/abbr) /span span class=track span class=track-titleHighway To Hell/span (abbr class=duration title=2193:39/abbr) /span /div Finally, please note that 3:39 is not an abbreviation of 219. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #8: hAlbum is redundant
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes - It would address an issue that the Songbird folks had with hAudio (not being to specify album-title in an hAudio). We need to also address and discuss descriptions for this to become complete. I've also asked before for a note property to be included. I'm also not clear why the property for sleeve artwork is called image-summary and not just image. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAlbum concerns
On Thu, August 30, 2007 15:57, Justin Maxwell wrote: I would recommend Discogs as a massive source of useful examples: http://discogs.com Impressive, thanks. If there is any way I can help expedite or assist your process, or perhaps join the contributors roster, please let me know. For the latter, just add your name to the list on the relevant wiki page. I've been using class=identifier for the catalog number Which is your site? and class=position for the track number. What do you do for the tracks on the second or subsequent disc of a multi-disc set? We should also be careful to distinguish /types/ of identifier (catalogue number, UID, ISBN, Amazon-ASIN, etc.) Since those other than catalogue number are proprietary identification methods, i.e., identifers for external systems, the role of identifier should go to the primary source, the record label or publisher. ISBN is not proprietary, neither are International Standard Music Number: http://en.wikipedia.org/wiki/International_Standard_Music_Number and the other, related identifiers listed at the foot of that page. Perhaps we need type/ value pairs for them? -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Re: Microformat for implementing RFC2119
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes I've collected W3C's markup/styling and Ted's suggestions here: http://microformats.org/wiki/rfc-2119 I've created templates to deliver the RFC 2119 keywords in the recommended markup, and listed them at the above page, although the title attributes seemed to cause problems with the Wiki markup, so I've hyphenated-them-like-this as a work around. If someone can add the necessary styling to the Wiki's CSS, then the in-line styles can be removed. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAlbum concerns
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Sat, 2007-08-25 at 01:06 -0700, Justin Maxwell wrote: Hi all, Regarding hAlbum (http://microformats.org/wiki/audio-album-proposal), I believe it would be beneficial to include fields referencing catalog number (identifier) and publisher (publisher), both optional. Is there any compelling objection to this? You can specify roles in the contributor vcard [1] e.g span class=contributor vcard span class=rolePublisher/span...etc roles are: artist, publisher, guitarist, vocalist, violinist, lead singer, backup singer, bassist, drummer, manager, roadie... etc Care should be taken not to confuse publisher (e.g. Northern Songs, Boozey and Hawkes) and the label (EMI, Deutsche Gramaphon). Publishers deal with the rights in compositions; labels issue recordings. An album may have more than one publisher; a single recording may appear on more than one label. As for specifying an Identifier well unfortunately the from the examples we used [2] there wasnt much evidence of any kind of Identifier other than the url's themselves. It seems to me that your examples concentrate on sites publishing downloadable or streaming audio files, and that you (or we, collectively) haven't examined sites publishing descriptions of recordings on CD, vinyl or whatever (which would seem to be covered by both the problem statement and the purpose on the brainstorming page, and certainly should be within the scope of this microformat). Once you do, you'll find plenty of examples of catalogue numbers being published. For example: http://www.jazzdisco.org/miles/dis/c/ http://ourworld.compuserve.com/homepages/PFArchives/DUKLP.htm http://www.naxos.com/catalogue/item.asp?item_code=8.553406 We should also be careful to distinguish /types/ of identifier (catalogue number, UID, ISBN, Amazon-ASIN, etc.) -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #3: published-date is redundant
On Fri, August 17, 2007 13:41, Martin McEvoy wrote: Consider this pseudo-xhtml: div class=hentry haudio div class=entry-contentThis song is great/div Shouldn't that be an hReview? -- Andy Mabbett ** via webmail ** ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio ISSUE #1: image-summary is redundant
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes Do you think the use of PHOTO may interfere with the hCard that is already part of the hAudio proposal, Suppose I wanted to mark up my hAudio hcard's with Photos of the band members? [...] If it becomes a significant problem, it will be solved by clarifying parsing rules. If it doesn't become a significant problem, it's not worth worrying about. Either way, it needn't influence our choice of property names. The issue isn't so much one of property /names/, as of property name /granularity/. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency: symbols and units (Was: microformat granularity: currency and measure)
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes I would suggest this: span class=money¢abbr title=0.021 class=amount2.1/abbr span class=currencyUSD/span/span 0.021 is not an abbreviation of 2.1. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Currency: more non-USD examples needed
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes I was going to continue discussion about a currency microformat, but I realized that the examples collected and analyzed so far are nearly all USD. Look again. There are also GBP, Canadian dollars unspecified dollars, Euros, Deutschmark, and Jamaican money. Are there any modern day currenscies which are not decimal? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] microformat granularity: currency and measure
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Andy Mabbett wrote: In the case of currency, I think we should polish and publish: http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal I had came up with http://microformats.org/wiki/currency-proposal as a cleaned up version of the straw man proposal. I believe the only difference between the straw man proposal and this cleaned up version was that I removed the date and the symbol class names. The reason for the date removal was due to the lack of strong consensus on the value of the date class name for two reasons: * Occurrence of dated money amounts is judged rare: See http://microformats.org/discuss/mail/microformats-discuss/2006-September /005802.html ...for some value of rare. I have provided evidence of widespread use f historical monetary values. Five dollars today does not have the same value as five dollars did a hundred, or even twenty, years ago. * Date is not a property of the money amount, but of a currency rate: See http://microformats.org/discuss/mail/microformats-discuss/2006-September /005927.html I don't follow your reasoning there, at all. This lack of consensus was confirmed by the poll I had sent. See results: http://www.vizu.com/res/Business/Technology/microformats/currency/poll-r esults.html?n=15067formBean=com.productengine.vizu.model.poll.PollNonvo ters%401aca8cc I don't believe that that poll has any value; not least because only nine people participated. symbol suffered the same lack of consensus, possibly due to a lack of understanding of the benefits. Maybe a more detailed explanation of the benefits of such a class name would be worth writing. If I understood correctly, the main value would be for a user agent to be able to replace it with the symbol of the currency that the amount is converted to. If that's the case, I would argue that a user agent may not want to replace the content, since it may fool the user into believing that these amounts are guaranteed by the publisher/merchant, where in fact, they would be mere estimates, which may differ from the actual rate charged by the merchant or the financial intermediary. That's hypothetical argument backed with no evidence. In the case of measurement, we can use your examples: http://microformats.org/wiki/measure-brainstorming#Guillaume_Lebleu as a straw-man, but the chief unresolved issue is what to do about the plethora of non-SI units, and which we should include. I think Bogdan and Emil came with some solutions using composition of SI units and scaling, in line with some of the practices I had identified (ex. XBRL). This could work for unusual units, when coded shortcurts for common compositions (ex. square meters) are not available from standard bodies such ISO or UNECE. Using standard codes for common compositions of units and allowing custom compositions for unusual units should hopefully be in line with a simple things simple, complex things possible principle. I don't see what you're saying here - please clarify. I suggest that I come up with a draft proposal based on the current suggestions that we can start the discussion from. Sure. Please excuse my brevity - I'm late leaving home. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hMovie?
In message [EMAIL PROTECTED], Mary Hodder [EMAIL PROTECTED] writes There are two things that I've noticed that may be in conflict: 1. the example in the email yesterday gave a list of IMDB like types of metadata around video from that perspective, that few people other than IMDB publish online. Most people to not put up a video they've made, either on their own blogs, or embedded from a hoster, and list all those categories of metadata around the video. 2. most people (and hosters) tend to publish video and give a limited set of data: title description url tags duration other formats via url thumbnail of the 100 million videos online now, that is maybe 95% if not more. Microformats are supposed to reflect what is actually in practice online, not what you want people to do that they don't do now. I think you're comparing apples and pears. people *are* already publishing movie credits, such as on IMDb; and movies are /not/ simply video clips. There may well be a valid case for there being a microformat for each - though I'd like to see the use-case for a movie microformat, as it's not clear from this thread. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hMovie?
In message [EMAIL PROTECTED], Patrick Aljord [EMAIL PROTECTED] writes That's what I want to do this with microformats, movie credits that is. Yes, but what will you - or people in general - do with the data once it's marked up? With hCard, for example, you can add people to address books; and hCalendar events can be added to calendars. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] microformat granularity: currency and measure
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Andy Mabbett wrote: For instance, in ¢2.1 USD, the currency is USD, and the unit is ¢, but ¢ is not the symbol of currency USD. How would you mark those up? Here is a try, using the value class name: span class=moneyabbr class=unit title=cent¢/abbrspan class=value2.1/span span class=currencyUSD/span/span Unless we're expecting parsers to understand every sub-unit of every currency, that'll cause problems. I read it as saying the amount is 2.1 dollars. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] microformat granularity: currency and measure
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Andy Mabbett wrote: For that reason, I'd like to see work done to make the currency and measurement microformats complete - at least as usable drafts. I'm willing to contribute more time on these. What do you see as specific work items that need to be done to move forward? Thank you. In the case of currency, I think we should polish and publish: http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal In the case of measurement, we can use your examples: http://microformats.org/wiki/measure-brainstorming#Guillaume_Lebleu as a straw-man, but the chief unresolved issue is what to do about the plethora of non-SI units, and which we should include. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Use of img in rel-* (with analyzed data)
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Our experience with this in practice has been quite good, and in fact, this is the first that *anyone* has raised any issues with it I've raised the matter previously. I would assert [...] that new cases regarding this being raised now have the burden of proof Surely, by your own standards, the burden is on you, to provide evidence to support your assertions? I note that you have not replied to my previous suggestion that you do so. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] img alt content statistics
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes The percentages below are the percentages of img tags that contained non-empty attributes: src:99% height: 66% width: 66% alt:41% title: 5% id: 4% In general, only 41% of 'img' tags list non-empty 'alt' attributes. In other words - most websites are not using 'alt' attributes for 'img' tags. That's a bogus conclusion - empty alt attributes are perfectly valid, and are appropriate in many cases; and you're counting tags but making conclusions about most websites. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Microformat for article/document?
In message [EMAIL PROTECTED], Charles Iliya Krempeaux [EMAIL PROTECTED] writes On 7/13/07, Henrik Kraft [EMAIL PROTECTED] wrote: Ive been looking but cant seem to find a mf for a document. Perhaps I'm missing the point, but... isn't html considered to be a document. And thus html is your article. title is your header. And you can include some class names on various elements inside of body for your preamble and bodytext. That's one way of looking at it; but in: http://www.westmidlandbirdclub.com/biblio/SuAScene/2-15.htm for example, the 2006 article (i.e. the whole page) contains and describes a 1948 article. Then again, the latter, and the original enquirer's document, could, perhaps, by wrapped in a citation microformat. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag))
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes On 7/9/07 7:30 PM, Manu Sporny [EMAIL PROTECTED] wrote: Mike, would it be possible to write a parseTagTextFromImages() function that would extract the 'alt' text from images? Therefore, running it over the following HTML: a class=fn url href=http://www.mikekaply.com/; img src=uf.png alt=Michael / Kaply /a Would yield the text Michael Kaply for 'fn'. Using this approach would also solve the hAudio problem as well as the problems that have been raised thus far in this thread. This would be non-compliant with hCard parsing and thus should be AVOIDED. http://microformats.org/wiki/hcard-parsing In other words, the microformat parsing rules are non-compliant with the HTML specification. I think that's something which should be fixed. -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] title vs. summary (was: Third attempt at hAudio)
In message [EMAIL PROTECTED], Joe Andrieu [EMAIL PROTECTED] writes If audio-title or audiotitle violates namespace principles here, then I think we are seriously hitting one of the scaling problems of uF. We have a precedent in honorific-prefix honorific-suffix (ironically, the former might be called title!) Of course, it has been argued that uF isn't supposed to scale and perhaps this is one of those areas where the namespace and scoping principles induce a boundary on scale. If that's really the point we are at, can someone explain why this is a good thing again? I think it was not invented here. In other words, hCard parsers would have to be re-written to handle contained hAudios. Am I following that argument correctly? If so, I don't quite understand the problem because hCard's don't contain hAudio. Or can they? Suppose I make my autobiographical web page an hCard, using: class=vcard That's valid. then suppose I decide to include on my page an mp3 of my new hit single... -- Andy Mabbett * Say NO! to compulsory UK ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] title vs. summary (was: Third attempt at hAudio)
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes You can enhance this further if you want to create extra meaning to one of our hAudio's by using a bit of POSH div class=haudio span class=summary title=Blonde on Blonde dfnBlonde on Blonde/dfn /span If you were approaching this bottom (POSH) up, rather than top (microformat) down, you would NEVER call that a summary; you would call it title, or record or album-name, or something like that. When did you last walk into a shop and say something like do you have a Bob Dylan CD? I can't recall the *summary*, but it was something like Blood on the Macs? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio: relevant UIDs
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes http://www.google.co.uk/search?q=elgar That has 6,120,000 results. http://www.google.co.uk/search?q=elgar+ISRC That has 27,500 results. http://www.google.co.uk/searchq=beethoven+ISWC That has 13,400 results. http://www.google.co.uk/search?q=beethoven That has 24,400,000 results. This cursory skim of real world publishing suggests to me that these ISO standards account for a very small portion (less than 1%) of our problem set. You're using a bogus comparison, calculating the proportion of sites mentioning Elgar/ Beethoven which use ISO codes, instead of the proportion of sites publishing downloadable Elgar/ Beethoven audio (or whatever) which use ISO codes. If anyone is interested, obviously a more detailed analysis would provide more accurate information, but I don't personally see much cause for interest. Besides, they're *ISO* international standards. That doesn't mean people are actually using them. ISO don't write standards to keep themselves busy. Of course people are using them. How much of our evidence is obtained from b2b sites? How many people with professional experience of music retailing, licensing or related fields have contributed to the discussion? How much effort was made to contact such people, in the fora they're likely to be using as part of their work? And are Google results acceptable as evidence of lack of use, if they're not allowed - by the process - as evidence of use ? -- Andy Mabbett * Say NO! to compulsory UK ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Third attempt at hAudio
In message [EMAIL PROTECTED], Brian Suda [EMAIL PROTECTED] writes Please make yourself aware of the process. If we are going to get through this proposal, you MUST read the process and understand it. What if Manu (or anyone else) has read it, and fully understands it, but disagrees with it? -- Andy Mabbett ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
[uf-new] Re: [uf-discuss] Work-of-art/Tim Gambell
In message [EMAIL PROTECTED] .uk, Ottevanger, Jeremy [EMAIL PROTECTED] writes The role I envisage for a museum object microformat would be: - to identify a unique object on the web, tied (ideally) to an institution - to enable the capture of a very basic set of metadata about that object - optionally, to point at a source of fuller, structured metadata, thereby making a bridge between the light, author-friendly and flexible microformatted semantic web and the stricter, machine-facing Semantic Web And the use-case? Catalogue pages like this: http://www.museumoflondon.org.uk/English/Collections/OnlineResources/X2 0L/objects/record.htm?type=objectid=742656. Thank you. I don't wish to dissuade you from continuing, but I'm really having difficulty seeing how this would be used. A simple example use-case would be, for hCard: a user can add contact details to their address book, or look up places with coordinates or postal codes on an on-line map. For the Currency proposal: a user agent can convert an amount of money, encoded in one currency, into an alternative currency, by looking up the exchange rate open a nominated website. In the case of an art object, surely there will only be one primary source of information, and that can simply be linked to? Can you provide examples of webmasters or software, currently delivering the kind of services which you envisage that a microformat would facilitate? BTW, this conversation probably ought to be taking place on the new microformats mailing list; I've cross-posted and set follow-ups, so please reply there. Thank you. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] Receipt Microformat
In message [EMAIL PROTECTED], Joe Osowski [EMAIL PROTECTED] writes [hReceipt] TotalCost [hPackage] DeliveryCost [hPurchase] Cost Without wishing to endorse or deprecate this proposal; please be aware of the proposed currency microformat, when discussing amounts of money. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] hAudio 'acquire' re-naming (Microformats should use nouns for properties)
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes On May 8, 2007, at 10:22 AM, Chris Griego wrote: rel-enclosure was ruled out because it's not always a download, but sometimes a way to purchase, right? What if hAudio suggested the use of rel-enclosure for downloads and rel-payment for ways to purchase? I think this is an excellent idea. In addition to re-using existing microformats, knowing whether a link is a direct download or a purchase form would allow tools to provide more useful options to users. I can foresee problems. Suppose a publisher links to a third-party site, offering an audio track as a free sample (or vice versa). Later, that latter site decides to start charging for the track - how would the publisher know that their site is no longer correct? -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] renaming work-title to fn in hAudio (was: An argument against 'fn' in hAudio)
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Scott's argument was the final nail in the 'work-title' coffin. Work title has been changed to 'fn' Thereby giving us: div class=haudio span class=contributor hcard span class=fn !-- fn #1 -- Roy Harper /span /span span class=fn!-- fn #2 -- Bullinamingvase /span /div -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] First draft of hAudio proposal
In message [EMAIL PROTECTED], David Janes [EMAIL PROTECTED] writes hAudio (haudio) - title. required. text. title is already taken to mean something else, so TITLE is not an option. hCard uses TITLE for job-title. I would suggest FN instead. We could use FN, but 'work-title' is far more accurate. If you mean what most people do by title, then FN is the correct thing to use. How does that square with the principle of making things easier for publishers? title (or movie-title or job-title, or whatever) is surely easier for publisher to remember, and more obvious when updating code, than the awful FN! How is FN supported, in preference to title or *-title by the evidence gathered? genre. optional. text. genre sounds alot like TAGS or CATEGORIES to me? we should recycle terms in existing microformats What Andy Mabbett said... not all authors want to mark up genres as URLs. There are enough examples that don't mark up the genre to not require the use of a URL-based TAGS/CATEGORIES approach. While (very) sympathetic to Andy's point about this, we're getting to the danger point of semantically forking rel-tag. Tagging serves a particular purpose. Not every label on the web is published as a tag Where is the evidence supporting your position? In how many of the sites cited as evidence, is the genre currently presented as a link to a tag name-space, or some other page of that ilk? The liking some microformat activists tagging does not mandate the sue of tags for all labels; and should not be allowed to become a requirement for publishers to change their current behaviour in that regard I suspect you will get strong pushback on this one, because the current approach is to use rel-tag for this, and if that needs to be fixed, it needs to be fixed and the problem should be addressed there. It quite probably does, though that horse has, perhaps, already bolted. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] First attempt at hAudio proposal
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] writes length - new class=length, or defer in first draft Should be a measure format price - new class=price, or defer in first draft Should be a currency format -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
Re: [uf-new] First draft of hAudio proposal
In message [EMAIL PROTECTED], David Janes [EMAIL PROTECTED] writes On 5/2/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], David Janes [EMAIL PROTECTED] writes If you mean what most people do by title, then FN is the correct thing to use. How does that square with the principle of making things easier for publishers? title (or movie-title or job-title, or whatever) is surely easier for publisher to remember, and more obvious when updating code, than the awful FN! How is FN supported, in preference to title or *-title by the evidence gathered? Did you even read what I wrote Andy? Yes; you asserted that, in a certain circumstance, ' FN is the correct thing to use'. I then asked you justify that; in relation to making things easy for publishers, and in relation to the evidence gathered so far. You appear to have done neither. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
