Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Michael Smethurst [EMAIL PROTECTED] writes The problem for my work is I'm taking artist names out of musicbrainz. Musicbrainz does differentiate between artists singular and groups but the name field is a single string. I can use: span class=fn nicknameMadonna Louise Ciccone Ritchie/span And treat all artist names as nicknames or span class=fn orgMadonna Louise Ciccone Ritchie/span And treat all artists as organisations Both of which seem wrong It's a commonish problem I've found with ufs. If you're handcrafting html they can be made to work fine - if you're generating pages dynamically from a db it gets trickier I found the same problem on Wikipedia with addresses and names. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes not least because the alternative: foo class=fnPink Floyd/foo would be optimised (sic) to have a given name of Pink and a family name of Floyd. I don't disagree that groups/bands should be considered organisations. That said, I don't think the reason offered here is a strong one. Neither do I; that's why I said not least. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On 7/2/08 00:13, Guillaume Lebleu [EMAIL PROTECTED] wrote: I don't disagree that groups/bands should be considered organisations. This takes me back several months (June 2007) to a thread about whether both music:groups and music:artists_singular should be marked up as organisations: http://www.mail-archive.com/microformats-discuss@microformats.org/msg07887.h tml At the time Scott Reynen suggested: snip If it's just a generic contact that you know nothing about, I'd say just use fn, as adding org is potentially incorrect information. But if you know it's a music act, I think it makes sense to consider even an individual performer's name to be an organization name in that context. I'd say there's a difference, for example, between Norah Jones the person, who would be span class=fnNorah Jones/span, and Norah Jones the musical act, which would be span class=fn orgNorah Jones/span. /snip That said, I don't think the reason offered here is a strong one. The issue described is directly related to FN's (over?)reuse beyond its original vCard scope of person names, to cover any name. Agreed. The problem also arises with artists like Eminem, Madonna, Prince. How is fn optimisation supposed to work here? [Not only has this led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address] Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Thu, February 7, 2008 09:55, Michael Smethurst wrote: This takes me back several months (June 2007) to a thread about whether both music:groups and music:artists_singular should be marked up as organisations: http://www.mail-archive.com/microformats-discuss@microformats.org/msg07887.html Please use the canonical archives when citing mailing list posts; we can't know that third-arty archives are accurate or comprehensive, or that they will always be available. that post is: http://microformats.org/discuss/mail/microformats-discuss/2007-June/009850.html At the time Scott Reynen suggested: snip If it's just a generic contact that you know nothing about, I'd say just use fn, as adding org is potentially incorrect information. But if you know it's a music act, I think it makes sense to consider even an individual performer's name to be an organization name in that context. I'd say there's a difference, for example, between Norah Jones the person, who would be span class=fnNorah Jones/span, and Norah Jones the musical act, which would be span class=fn orgNorah Jones/span. /snip That strikes me as no more sensible now than it did then. If I cite her, as Norah Jones said, am I referring to her as a person, or an organisation? Would her hCard's date of both refer to the day she left her mother's womb, or the day the supposed organisation was founded? Does Mozart become an organisation if I refer to his symphonies, but not if I refer to his marriage? Do Winston Churchill or Ghandi suddenly become organisations if we refer to a recording of one of their speeches, but not one of their books? ...with artists like Eminem, Madonna, Prince. How is fn optimisation supposed to work here? Exactly as it does at present. Those are both formatted names and nicknames (and remain nicknames, if you also include the fn of Marshall Bruce Mathers III, Madonna Louise Ciccone Ritchie or Prince Rogers Nelson). -- Andy Mabbett ** via webmail ** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Thu, 2008-02-07 at 09:55 +, Michael Smethurst wrote: Agreed. The problem also arises with artists like Eminem, Madonna, Prince. How is fn optimisation supposed to work here? As we find a lot in music your above examples are people and Organizations. How it appears, I would guess is how you define it eg: [a] Buy the Single Like a Virgin by Madonna Madonna is the Organization, with Producers Artists Songwriters etc.. associated with it, fn org seems appropriate usage? [b] I Like Madonna's vocals on Like a Virgin You would be talking about Madonna the person in the above statement so just fn would be used. Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Thu, February 7, 2008 15:37, Scott Reynen wrote: On Feb 7, 2008, at 4:59 AM, Andy Mabbett wrote: If it's just a generic contact that you know nothing about, I'd say just use fn, as adding org is potentially incorrect information. But if you know it's a music act, I think it makes sense to consider even an individual performer's name to be an organization name in that context. I'd say there's a difference, for example, between Norah Jones the person, who would be span class=fnNorah Jones/span, and Norah Jones the musical act, which would be span class=fn orgNorah Jones/span. /snip That strikes me as no more sensible now than it did then. If I cite her, as Norah Jones said, am I referring to her as a person, or an organisation? Note I started that suggestion with if it's just a generic contact that you know nothing about... Which you then followed with But if you know it's a music act So in that context, there's no possible answer to your questions. I wasn't suggesting we treat all musicians as organizations when we *do* know they're individuals, just that our default assumption of musical acts is that they're organizations. If you mean that in the context of a musical act, where the publisher doesn't know whether that's a person or a group, then I agree that that would be the better default (in that no third, more ambiguous, distinction is yet available); but I don't think that that is how others are representing your suggestion. -- Andy Mabbett ** via webmail ** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Thu, February 7, 2008 14:33, Michael Smethurst wrote: At the time Scott Reynen suggested: snip If it's just a generic contact that you know nothing about, I'd say just use fn, as adding org is potentially incorrect information. But if you know it's a music act, I think it makes sense to consider even an individual performer's name to be an organization name in that context. I'd say there's a difference, for example, between Norah Jones the person, who would be span class=fnNorah Jones/span, and Norah Jones the musical act, which would be span class=fn orgNorah Jones/span. /snip That strikes me as no more sensible now than it did then. If I cite her, as Norah Jones said, am I referring to her as a person, or an organisation? Would her hCard's date of both refer to the day she left her mother's womb, or the day the supposed organisation was founded? Does Mozart become an organisation if I refer to his symphonies, but not if I refer to his marriage? Do Winston Churchill or Ghandi suddenly become organisations if we refer to a recording of one of their speeches, but not one of their books? I didn't say I supported this view. I just brought it back up cos it seemed relevant Noted; my response was not addressed to or directed at you personally. ...with artists like Eminem, Madonna, Prince. How is fn optimisation supposed to work here? Exactly as it does at present. Those are both formatted names and nicknames (and remain nicknames, if you also include the fn of Marshall Bruce Mathers III, Madonna Louise Ciccone Ritchie or Prince Rogers Nelson). Not sure I follow. The hcard wiki page says nickname optimisation happens when FN and ORG are not the same, and the value of the FN property is exactly one word. What would: span class=fnMadonna Louise Ciccone Ritchie/span Result in? No nickname; unlike the more comprehensive: span class=fnspan class=nicknameMadonna/span Louise Ciccone Ritchie/span Also what about artists like Plastic Bertram? I assume that's not a given + family name combination It would be,; however I suggest that marked up such as: span class=fn nicknamePlastic Bertram/span should be exempted from that optimisation rule - good call. I'll wiki it. -- Andy Mabbett ** via webmail ** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On 7/2/08 11:59, Andy Mabbett [EMAIL PROTECTED] wrote: On Thu, February 7, 2008 09:55, Michael Smethurst wrote: This takes me back several months (June 2007) to a thread about whether both music:groups and music:artists_singular should be marked up as organisations: http://www.mail-archive.com/microformats-discuss@microformats.org/msg07887.ht ml Please use the canonical archives when citing mailing list posts; we can't know that third-arty archives are accurate or comprehensive, or that they will always be available. Many, many apologies that post is: http://microformats.org/discuss/mail/microformats-discuss/2007-June/009850.ht ml At the time Scott Reynen suggested: snip If it's just a generic contact that you know nothing about, I'd say just use fn, as adding org is potentially incorrect information. But if you know it's a music act, I think it makes sense to consider even an individual performer's name to be an organization name in that context. I'd say there's a difference, for example, between Norah Jones the person, who would be span class=fnNorah Jones/span, and Norah Jones the musical act, which would be span class=fn orgNorah Jones/span. /snip That strikes me as no more sensible now than it did then. If I cite her, as Norah Jones said, am I referring to her as a person, or an organisation? Would her hCard's date of both refer to the day she left her mother's womb, or the day the supposed organisation was founded? Does Mozart become an organisation if I refer to his symphonies, but not if I refer to his marriage? Do Winston Churchill or Ghandi suddenly become organisations if we refer to a recording of one of their speeches, but not one of their books? I didn't say I supported this view. I just brought it back up cos it seemed relevant ...with artists like Eminem, Madonna, Prince. How is fn optimisation supposed to work here? Exactly as it does at present. Those are both formatted names and nicknames (and remain nicknames, if you also include the fn of Marshall Bruce Mathers III, Madonna Louise Ciccone Ritchie or Prince Rogers Nelson). Not sure I follow. The hcard wiki page says nickname optimisation happens when FN and ORG are not the same, and the value of the FN property is exactly one word. What would: span class=fnMadonna Louise Ciccone Ritchie/span Result in? Also what about artists like Plastic Bertram? I assume that's not a given + family name combination http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Feb 7, 2008, at 4:59 AM, Andy Mabbett wrote: If it's just a generic contact that you know nothing about, I'd say just use fn, as adding org is potentially incorrect information. But if you know it's a music act, I think it makes sense to consider even an individual performer's name to be an organization name in that context. I'd say there's a difference, for example, between Norah Jones the person, who would be span class=fnNorah Jones/span, and Norah Jones the musical act, which would be span class=fn orgNorah Jones/span. /snip That strikes me as no more sensible now than it did then. If I cite her, as Norah Jones said, am I referring to her as a person, or an organisation? Note I started that suggestion with if it's just a generic contact that you know nothing about... So in that context, there's no possible answer to your questions. I wasn't suggesting we treat all musicians as organizations when we *do* know they're individuals, just that our default assumption of musical acts is that they're organizations. You're of course welcome to publish under different assumptions; I wasn't suggesting we should all standardize on this. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes not least because the alternative: foo class=fnPink Floyd/foo would be optimised (sic) to have a given name of Pink and a family name of Floyd. I don't disagree that groups/bands should be considered organisations. That said, I don't think the reason offered here is a strong one. Neither do I; that's why I said not least. Sorry if I misinterpreted: I'm not a native english speaker. Doesn't not least because [reason] means that [reason] is not the least reason, i.e. a strong one? Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Thu, February 7, 2008 15:46, Guillaume Lebleu wrote: Sorry if I misinterpreted: I'm not a native english speaker. Doesn't not least because [reason] means that [reason] is not the least reason, i.e. a strong one? Literally, yes, but in colloquial use it can mean not the weakest, but far from the strongest, reason. Apologies for causing confusion. -- Andy Mabbett ** via webmail ** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On 7/2/08 15:30, Andy Mabbett [EMAIL PROTECTED] wrote: On Thu, February 7, 2008 14:33, Michael Smethurst wrote: Not sure I follow. The hcard wiki page says nickname optimisation happens when FN and ORG are not the same, and the value of the FN property is exactly one word. What would: span class=fnMadonna Louise Ciccone Ritchie/span Result in? No nickname; unlike the more comprehensive: span class=fnspan class=nicknameMadonna/span Louise Ciccone Ritchie/span The problem for my work is I'm taking artist names out of musicbrainz. Musicbrainz does differentiate between artists singular and groups but the name field is a single string. So there's no differentiation between: Madonna Louise Ciccone Ritchie Madonna Ciccone Madonna Plastic Bertram So I can use: span class=fn nicknameMadonna Louise Ciccone Ritchie/span And treat all artist names as nicknames or span class=fn orgMadonna Louise Ciccone Ritchie/span And treat all artists as organisations Both of which seem wrong It's a commonish problem I've found with ufs. If you're handcrafting html they can be made to work fine - if you're generating pages dynamically from a db it gets trickier http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Robert O'Rourke [EMAIL PROTECTED] writes How about removing the 'contributor' class from the key creator's vcard? It would make sense to me to group contributors separately to the creator. The vcard attached to the hAudio would denote the original creator. That would still not distinguish between creator as performer (Elvis Presley); as composer (Mozart); or as both (Bob Dylan). Ah yes, so would you say 'performer', 'creator' and 'composer' are roles and not different to being a contributor? It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. I know you had a problem with it but if the role 'artist' is vague in so far as 'performer', 'composer' etc.. are concerned then perhaps it would be useful for exactly that reason. What do you think? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Martin McEvoy wrote: Hello Robert Hi Martin, nice meeting you the other day On Tue, 2008-02-05 at 18:39 +, Robert O'Rourke wrote: For cover tracks you'd have something like: span class=contributor vcard span class=roleOriginal Artist/span - span class=fn orgPrimal Scream/span /span Here is the best action I have seen using roles, It may be useful to the discussion. from http://microformats.org/wiki/hcard-examples-in-wild-reviewed http://www.iowamilitaryveteransband.com/members/ their roles are the instruments that they play Roles are *NOT* defined in hAudio as such other than.. The role attribute SHOULD be used to specify the contributor's responsibility related to the audio recording if hCard is utilized http://microformats.org/wiki/haudio#Contributor the context comes from hcard Information regarding the role of the object http://microformats.org/wiki/existing-classes the object in most cases the person. whats good is, its user defined, we may be able to give sensible hints to what you put in there but really it's up to the publisher the choice is yours eg: groupie, or stage hand could be fun!. original artist, band, group, quartet are valid roles I would say so are vocalist, bassist, drummer, producer, artist for individuals If we had a hPunchup microformat you could have a role of looser ;) Ha! and a vevent for every punch. Never thought of marking up a boxing match until now! I AM worried that we should be using title instead of role in some cases... That depends if you look at a piece of music as having jobs associated with it. Is a piece of music some work that people were employed to create or only a creative endeavour?. It can be either, but as far as hAudio is concerned I would say role is most appropriate. Thoughts? Thanks Martin McEvoy Cheers, Rob ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Wed, 2008-02-06 at 12:29 +, Robert O'Rourke wrote: Martin McEvoy wrote: Hello Robert Hi Martin, nice meeting you the other day Well met too its surprising the places that you meet people ;) On Tue, 2008-02-05 at 18:39 +, Robert O'Rourke wrote: For cover tracks you'd have something like: span class=contributor vcard span class=roleOriginal Artist/span - span class=fn orgPrimal Scream/span /span Here is the best action I have seen using roles, It may be useful to the discussion. from http://microformats.org/wiki/hcard-examples-in-wild-reviewed http://www.iowamilitaryveteransband.com/members/ their roles are the instruments that they play Roles are *NOT* defined in hAudio as such other than.. The role attribute SHOULD be used to specify the contributor's responsibility related to the audio recording if hCard is utilized http://microformats.org/wiki/haudio#Contributor the context comes from hcard Information regarding the role of the object http://microformats.org/wiki/existing-classes the object in most cases the person. whats good is, its user defined, we may be able to give sensible hints to what you put in there but really it's up to the publisher the choice is yours eg: groupie, or stage hand could be fun!. original artist, band, group, quartet are valid roles I would say so are vocalist, bassist, drummer, producer, artist for individuals If we had a hPunchup microformat you could have a role of looser ;) Ha! and a vevent for every punch. Never thought of marking up a boxing match until now! It could be reused in hArgument? ...chuckle I AM worried that we should be using title instead of role in some cases... That depends if you look at a piece of music as having jobs associated with it. Is a piece of music some work that people were employed to create or only a creative endeavour?. In the case of manufactured bands I would say that all involved are employed and have Job Titles... as do professional musicians maybe. It can be either, but as far as hAudio is concerned I would say role is most appropriate. Thoughts? I agree Roles are more important than their job titles as the two may not be related or have any context in the making of a piece of audio. I think the problem with the above is quite often in audio roles and job titles are quite often the same.. Manu explained the differences quite nicley to me.. A role is what you do, where a title is what your official title is at the organization. Role is hardly ever used in hcard in the real world,and as a result not much info, I think maybe more information about role can be added to the hAudio wiki, perhaps even some good recommendations? Thanks Martin McEvoy Thanks Martin McEvoy Cheers, Rob ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Martin McEvoy wrote: On Wed, 2008-02-06 at 12:29 +, Robert O'Rourke wrote: Martin McEvoy wrote: I AM worried that we should be using title instead of role in some cases... That depends if you look at a piece of music as having jobs associated with it. Is a piece of music some work that people were employed to create or only a creative endeavour?. In the case of manufactured bands I would say that all involved are employed and have Job Titles... as do professional musicians maybe. It can be either, but as far as hAudio is concerned I would say role is most appropriate. Thoughts? I agree Roles are more important than their job titles as the two may not be related or have any context in the making of a piece of audio. I think the problem with the above is quite often in audio roles and job titles are quite often the same.. Manu explained the differences quite nicley to me.. A role is what you do, where a title is what your official title is at the organization. In that case in relation to hAudio role is defnitely more appropriate. Each individual's title is an arbritary thing - say when two people who fulfil the same roles at two different organisations have different titles. Everyone involved with a recording had a role to play but not necessarily an official title. As a side note, is title only really used if org has been indicated? And are groups/bands considered to be an organisation? Solo artists wouldn't have any particular org except maybe the record label, in which case their title would be Artist. A musician with no record label or contract has no employer and therefore no official title so the use of role would be better suited to the majority of cases. Role is hardly ever used in hcard in the real world,and as a result not much info, I think maybe more information about role can be added to the hAudio wiki, perhaps even some good recommendations? That would be good to see, there isn't a whole lot of detail about the use of role in hcard on the wiki. Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Robert O'Rourke wrote: Ah yes, so would you say 'performer', 'creator' and 'composer' are roles and not different to being a contributor? Yes, that is why 'contributor' was picked, rather than 'performer', 'creator', or 'composer'. :) It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. You can always specify multiple 'role's in hCard to state that the person had more than one role. I know you had a problem with it but if the role 'artist' is vague in so far as 'performer', 'composer' etc.. are concerned then perhaps it would be useful for exactly that reason. What do you think? I've got no problem adding more contributor types as convenience classes for composer, performer, publisher, label, etc. However, like all things Microformats - they've got to be backed up by examples. The issue isn't wouldn't these be really cool to have, but rather we need to demonstrate that there are enough of these on the web to justify adding more terms to hAudio. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes Role is hardly ever used in hcard in the real world I use it. In fact: http://www.westmidlandbirdclub.com/bardsey/ might include the first ever hCard with a role of Lighthouse keeper! -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. You can always specify multiple 'role's in hCard to state that the person had more than one role. One cannot always specify such things, because the page content (e.g. Beethoven's Fifth) does not always spell out such terms. I know you had a problem with it but if the role 'artist' is vague in so far as 'performer', 'composer' etc.. are concerned then perhaps it would be useful for exactly that reason. What do you think? I've got no problem adding more contributor types as convenience classes for composer, performer, publisher, label, etc. However, like all things Microformats - they've got to be backed up by examples. The issue isn't wouldn't these be really cool to have, but rather we need to demonstrate that there are enough of these on the web to justify adding more terms to hAudio. Like I said a day or two ago: for the guidance of wise men and... -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Robert O'Rourke [EMAIL PROTECTED] writes And are groups/bands considered to be an organisation? Yes: foo class=fn orgPink Floyd/foo not least because the alternative: foo class=fnPink Floyd/foo would be optimised (sic) to have a given name of Pink and a family name of Floyd. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Robert O'Rourke [EMAIL PROTECTED] writes would you say 'performer', 'creator' and 'composer' are roles and not different to being a contributor? They are all contributors, but they are sub-sets of the set of contributors (and hence are more granular). It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. Why would it? How is: foo class=contributorBob Dylan/foo more useful than: foo class=composer performerBob Dylan/foo The only time I can see the former class name being more useful is where the finer granularity is unknown or unavailable. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes It would be useful to have a more blanket term for instances where one person has multiple roles of that kind. You can always specify multiple 'role's in hCard to state that the person had more than one role. One cannot always specify such things, because the page content (e.g. Beethoven's Fifth) does not always spell out such terms. Right, point taken. I know you had a problem with it but if the role 'artist' is vague in so far as 'performer', 'composer' etc.. are concerned then perhaps it would be useful for exactly that reason. What do you think? I've got no problem adding more contributor types as convenience classes for composer, performer, publisher, label, etc. However, like all things Microformats - they've got to be backed up by examples. The issue isn't wouldn't these be really cool to have, but rather we need to demonstrate that there are enough of these on the web to justify adding more terms to hAudio. Like I said a day or two ago: for the guidance of wise men and... Alright, wise-guy =P - put the terms that you would like included on the haudio-issues wiki and let's start tracking them. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Robert O'Rourke [EMAIL PROTECTED] writes And are groups/bands considered to be an organisation? Yes: foo class=fn orgPink Floyd/foo not least because the alternative: foo class=fnPink Floyd/foo would be optimised (sic) to have a given name of Pink and a family name of Floyd. I don't disagree that groups/bands should be considered organisations. That said, I don't think the reason offered here is a strong one. The issue described is directly related to FN's (over?)reuse beyond its original vCard scope of person names, to cover any name. [Not only has this led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address] Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Manu Sporny wrote: Alf Eaton wrote: It would work, but so would a number of very complicated things. My needs are essentially very simple: artistPrimal Scream/artist - albumScreamadelica/album so span class=creatorPrimal Scream/span - span class=albumScreamadelica/span Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div Per the hAudio spec, you have just marked up an album called Screamadelica, whose primary contributor (the artist) is Primal Scream. The example above is valid hAudio markup - is your issue with the word contributor instead of creator? Basically, yes :-) And it's not a huge issue, I was just wondering if there was justification for it being that way - which there is, it seems. alf ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] haudio contributor
Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div That may be fine for someone who just wants to mark up some tracks they like on a personal blog ... but an artist or record store may want to be able to say who composed it, who performed it, who did studio production, who remixed it, who a guest instumentalist was, what label released it, and maybe even who distibutes it and want to be able to distinguish between them. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the role property That presumes that the roles are exposed in the page; they may be if or, say a producer, but often using the verb (produced by...), and frequently are not, We don't need to say that Beethoven is a composer, when saying Beethoven's fifth. That's clear to a human (well, mist humans of any western education!) from context; but not to a machine. Before anyone cries hidden metadata, how often to we explicitly say that Mabbett is my family name?, or that 21 High street is a street address? I agree with others that these are edge cases for microformats. Everything is an edge case, depending on which point you're looking from. I don't think you are correct when you say that only a human can infer Beethoven--(composerOf)--fifth, from Beethoven's fifth. As far as I've seen in other more lucrative domains than music, a well-trained semantic software extractor working off sufficient content, plain old grammatically-correct english and music metadata would do that job with less sweat than an editor will take to write the content and mark it up in hAudio or something else (not to say to come up with the markup that works in these edge cases in the first place). Well, clearly I was simplifying. But how many of us have access to a well-trained semantic software extractor, and what music metadata is widely used? By your argument, we wouldn't need microformats at all. Grammatically-correct english IS semantic markup, in a way. For some value of semantic. I think microformats' sweet spot is easing semantic extraction in cases where the level of structure is high, and the plain english context is low. If that's where you want to concentrate your use of microformats, that's fine, but that's not how I see them, and I see nothing in any of the specs or other defining documentation which restricts them in that way. The back of an album that lists tracks is such a case, its entry in Gracenote, a list of friends, electronic business cards, etc. are good examples as well. A plain english critics' review of an album on the other hand with lots of context, but little structure is a case that is economically much better handled using semantic analysis than with $1M markup. economically much better from whose perspective? I'm not saying that microformats should not try to make formats that work with plain old English or natural language (I've been trying myself), I'm just saying that we may consider the fact that the ROI will most likely be low and other technologies will compete better there, so we might just focus our time on where we have the biggest chance of straightforward adoption, then only look at solving the plain english cases, instead of trying to solve everything at once. I think that's an opinion - a restrictive one at that - not shared by everyone here, certainly not by me, and not supported by past experience of developing and using microformats. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Michael MD [EMAIL PROTECTED] writes Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div That may be fine for someone who just wants to mark up some tracks they like on a personal blog ... but an artist or record store may want to be able to say who composed it, who performed it, who did studio production, who remixed it, who a guest instumentalist was, what label released it, and maybe even who distibutes it and want to be able to distinguish between them. Not merely may want to; they do - see the Naxos examples I posted to the wiki in the last 24 hours, plus discography sites like: http://www.pf-roio.de/roio/roio-cd/british_winter_74.cd.html http://ourworld.compuserve.com/homepages/PFArchives/DUKCDLP.htm http://www.discogs.com/ http://www.discogs.com/search?type=allq=meddlebtn=Search not to mention Wikipedia: http://en.wikipedia.org/wiki/Meddle Some of us radicals also think it's a good idea to use hCard... -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Both the Beatles and Geoff Emerick contributed to Sgt. Pepper's Lonely Hearts Club Band, for instance: http://en.wikipedia.org/wiki/Sgt._Pepper%27s_Lonely_Hearts_Club_Band but one is clearly more significant than the other. Sure - but what about this one: http://music.yahoo.com/release/115057 Which one is more significant than the other - the label or the artist? From the point of view of the target audience of that page, the artist. Are creators more important than contributors? These questions are philosophical in nature - you can't assume that creator should be used to note the significance of a contribution. Perhaps not - we need greater granularity. There does seem to be a tendency in microformats, towards unduly low granularity; I find that strange. Why do you find that strange? Because we're all interested in making human-readable data available to machines. There seems little point in not doing so as well or as thoroughly as is possible, for little extra effort. (There is a pojnt of diminishing returns, but in this case as in many others discussed here ion recent months, we're nowhere near it yet). We're working with lowest common denominator here. When you do that, you get low granularity. Quite. Although in classical music, the composer may be as-, or more-, prominent than the artist; likewise the conductor. Higher granularity would allow for such distinctions. Sure - now all you have to do is find enough examples online, (we'll need about 30 with the composer clearly denoted as well as the artist with the composer more prominently displayed than the artist) for us to make the argument for putting this feature into hAudio. I don't *have* to do any such thing; though I happen to have already started doing so; and I certainly don't have to comply with some invented quantitative requirement (after all, it's well over a year since I attempted to do so for the taxonomic names of living things, and despite providing many millions, and having asked him numerous times, Tantek has yet to give a simple yes or no answer to my question as to whether that's sufficient). -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] haudio contributor
On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div That may be fine for someone who just wants to mark up some tracks they like on a personal blog ... but an artist or record store may want to be able to say who composed it, who performed it, who did studio production, who remixed it, who a guest instumentalist was, what label released it, and maybe even who distibutes it and want to be able to distinguish between them. Oh but you can... div class=haudio span class=albumScreamadelica/span span class=contributor vcard span class=roleArtist/span - span class=fn orgPrimal Scream/span /span span class=contributor vcard span class=roleProducer/span - span class=fnAndrew Weatherall/span /span span class=contributor vcard span class=roleVocals/span - span class=fnJah Wobble/span /span /div The only thing I might add is vcard looks redundant? as the context describes audio, not buisness cards? Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div That may be fine for someone who just wants to mark up some tracks they like on a personal blog ... but an artist or record store may want to be able to say who composed it, who performed it, who did studio production, who remixed it, who a guest instumentalist was, what label released it, and maybe even who distibutes it and want to be able to distinguish between them. Oh but you can... div class=haudio span class=albumScreamadelica/span span class=contributor vcard span class=roleArtist/span - span class=fn orgPrimal Scream/span /span 1) that's not the model referred to in Why doesn't the following work for you, then?, above. 2) Where is the evidence, in examples like that quoted at the top if this post, that people publish terms like Artist when referring to the key creator? span class=contributor vcard span class=roleProducer/span - span class=fnAndrew Weatherall/span /span How does that cater for people who use produced by instead of producer? span class=contributor vcard span class=roleVocals/span - span class=fnJah Wobble/span /span The role there is singer or vocalist, not vocals. The only thing I might add is vcard looks redundant? as the context describes audio, not buisness cards? hCard is not just for business cards. It's for people, organisations or places. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div That may be fine for someone who just wants to mark up some tracks they like on a personal blog ... but an artist or record store may want to be able to say who composed it, who performed it, who did studio production, who remixed it, who a guest instumentalist was, what label released it, and maybe even who distibutes it and want to be able to distinguish between them. Oh but you can... div class=haudio span class=albumScreamadelica/span span class=contributor vcard span class=roleArtist/span - span class=fn orgPrimal Scream/span /span 1) that's not the model referred to in Why doesn't the following work for you, then?, above. 2) Where is the evidence, in examples like that quoted at the top if this post, that people publish terms like Artist when referring to the key creator? From looking at a selection of ten online music shops and databases the 'key creator' is always implied by association. How about removing the 'contributor' class from the key creator's vcard? It would make sense to me to group contributors separately to the creator. The vcard attached to the hAudio would denote the original creator. For cover tracks you'd have something like: span class=contributor vcard span class=roleOriginal Artist/span - span class=fn orgPrimal Scream/span /span ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: The example above is valid hAudio markup - is your issue with the word contributor instead of creator? Basically, yes :-) And it's not a huge issue, I was just wondering if there was justification for it being that way - which there is, it seems. We're also tracking this issue on the hAudio issues page now (Issue #D1): http://microformats.org/wiki/haudio-issues -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
focus of microformats (was: Re: [uf-discuss] haudio contributor)
Andy Mabbett wrote: Everything is an edge case, depending on which point you're looking from. I'm conceding that I'm looking at these natural language examples from a particular perspective, the economic one, to decide what is an edge case or not, and that I'm just assuming that this economic perspective is the most important perspective to have when deciding where to focus the discussions. In particular, I'm looking at the following costs: - costs for the community to define a microformat that support these natural language, unstructured cases (this encompasses the include discussion). - costs for a human editor to understand the microformat and implement it. - costs for a software developer to implement a microformat parser. From what I have seen, these costs are high for the natural language examples in general, whether it's for hCard or hAudio. For other examples (structured content) these costs are low. The value is the same in both cases. Note that because these costs relate to unstructured content, they only apply to compound microformats which by nature imply structure, not elementary microformats. For instance, a microformat for a person's name (fn) is relatively easy to define, use and implement. Same thing for a money amount. A microformat for a person's complete contact information that works in all cases, not just the seminal blog's about box, has in comparison much higher costs of definition, use and implementation. A microformat for a resume, to the extent that a resume is highly structured is possible to define, use and implement. In comparison, a bio with the same content would most likely not be as easy. how many of us have access to a well-trained semantic software extractor, and what music metadata is widely used? It's not because I don't have something that others don't have it, and that I should ignore the fact that they have it in my decisions. Obviously, semantic extraction from the Web is of utmost importance for a lot of organizations, some with lots of resources, some with less, but all operating under the same economic rule: how can we lower the costs of understanding what people put on the Web with no/minimum costs/change of habits on their end. We all compete, and hopefully not a single one will win but some will be more successful for some classes of problems than others. Knowing what class of problems microformats are most likely to compete on is to me very important for the maximizing the returns on our time spent here. By your argument, we wouldn't need microformats at all. No. As I mentioned already, the costs listed above are the smallest in the case of structured content with little context. Guillaume Lebleu. T(W): 415 408 5856 has less context and more structure than My name is Guillaume Lebleu. My phone number at the office is 408-5856. My area code is 415.. The first example is a charm to microformat, the second one is less so. A semantic extractor will most likely do a poor job in first example and will do a better job at understanding the second example. As a result, it is my opinion that if microformats were officially focusing on structured content publishing (most known as blogging/social networking), we would have less discussions and probably more microformats. If that's where you want to concentrate your use of microformats, that's fine, but that's not how I see them, and I see nothing in any of the specs or other defining documentation which restricts them in that way. There are no written rules as of today, and in theory we don't need such. But I've seen a lot of discussions and time spent on cases that don't make economic sense. The it's on the Web, so it's relevant for microformats was excellent to avoid the known pitfalls of standard organzation (what if?) but also opened the can of worms in my opinion. It should in my opinion be: it's elementary pieces of data or structured content on the Web, so it's relevant for microformats, or something similar. I think that's an opinion - a restrictive one at that - not shared by everyone here, certainly not by me, and not supported by past experience of developing and using microformats. Restriction is the negative name of focus. Focus is key to success. I've yet to see someone successful at boiling the ocean. But I indeed don't know to what extent this opinion, or similar, is shared in this community. I only know you disagree with it. I'd be glad to see it put for a vote. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
On Tue, 2008-02-05 at 16:41 +, Andy Mabbett wrote: In message [EMAIL PROTECTED], Martin McEvoy [EMAIL PROTECTED] writes On Wed, 2008-02-06 at 01:56 +1100, Michael MD wrote: Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div That may be fine for someone who just wants to mark up some tracks they like on a personal blog ... but an artist or record store may want to be able to say who composed it, who performed it, who did studio production, who remixed it, who a guest instumentalist was, what label released it, and maybe even who distibutes it and want to be able to distinguish between them. Oh but you can... div class=haudio span class=albumScreamadelica/span span class=contributor vcard span class=roleArtist/span - span class=fn orgPrimal Scream/span /span 1) that's not the model referred to in Why doesn't the following work for you, then?, above. Roles can be used to expand contributor into something a bit more precise 2) Where is the evidence, in examples like that quoted at the top if this post, that people publish terms like Artist when referring to the key creator? span class=contributor vcard span class=roleProducer/span - span class=fnAndrew Weatherall/span /span How does that cater for people who use produced by instead of producer? span class=contributor vcard span class=roleVocals/span - span class=fnJah Wobble/span /span The role there is singer or vocalist, not vocals. Actually its Bassist on track 10 no less, sorry my fault ;) The only thing I might add is vcard looks redundant? as the context describes audio, not buisness cards? hCard is not just for business cards. It's for people, organisations or places. Thank You. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Hello Robert On Tue, 2008-02-05 at 18:39 +, Robert O'Rourke wrote: For cover tracks you'd have something like: span class=contributor vcard span class=roleOriginal Artist/span - span class=fn orgPrimal Scream/span /span Here is the best action I have seen using roles, It may be useful to the discussion. from http://microformats.org/wiki/hcard-examples-in-wild-reviewed http://www.iowamilitaryveteransband.com/members/ their roles are the instruments that they play Roles are *NOT* defined in hAudio as such other than.. The role attribute SHOULD be used to specify the contributor's responsibility related to the audio recording if hCard is utilized http://microformats.org/wiki/haudio#Contributor the context comes from hcard Information regarding the role of the object http://microformats.org/wiki/existing-classes the object in most cases the person. whats good is, its user defined, we may be able to give sensible hints to what you put in there but really it's up to the publisher the choice is yours eg: groupie, or stage hand could be fun!. original artist, band, group, quartet are valid roles I would say so are vocalist, bassist, drummer, producer, artist for individuals If we had a hPunchup microformat you could have a role of looser ;) I AM worried that we should be using title instead of role in some cases... Thanks Martin McEvoy ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Robert O'Rourke [EMAIL PROTECTED] writes How about removing the 'contributor' class from the key creator's vcard? It would make sense to me to group contributors separately to the creator. The vcard attached to the hAudio would denote the original creator. That would still not distinguish between creator as performer (Elvis Presley); as composer (Mozart); or as both (Bob Dylan). -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes If only one contributor is listed, it is assumed that he/she/it is also the creator of the hAudio. If multiple contributors are listed, it is assumed that the first contributor is the creator, and all subsequent contributors played supporting roles in the creation of the hAudio. That fails as soon as we want to mark up something like: Simon Rattle conducted the CBSO in a marvellous rendition of Beethoven's Fifth Yes, the use of 'contributor' falls apart completely when we have markup like that... which is uncommon. You should have noted that markup such as that is an edge case. Look at the audio-info-examples and you will be lucky if you find 1 or 2 instances of the markup you describe above. My point is that it is easy to manufacture words that break hAudio - but much harder to find actual examples online that break it. If you have issues with this approach, you can always use hAudio RDFa, which does make the distinction between dc:creator and dc:contributor. If you wanted to be even more specific, just include the Music Ontology vocabulary and mark it up using that. Thus, it can be said: Not all contributors are creators. Not all contributors are artists. That can certainly be said. However, it cannot be expressed in hAudio without requiring the publishers of such examples to re-order their content. It is a microformats principle to not do so. For the publishers that need to re-order their content to mark up hAudio, they are obviously stretching what hAudio uF can do, and should use hAudio RDFa. Thus, we should not narrow the who made it? behind hAudio down to those more narrow categories. Your conclusion is not supported by the forgoing claims. Then does doing this support my conclusion: *waves hands wildly in the air* =P More seriously: We don't have enough examples to split contributor into label, publisher, creator, and artist - which is what the examples showed to be the most prominently displayed contributors across the 93+ sites that we analyzed for hAudio. It doesn't seem to be based on established practice, as from the overview it looks like existing markup overwhelming uses 'artist'. http://microformats.org/wiki/audio-info-brainstorming#artist If we used artist, we would not have been able to mark up publishers, composers, audio technicians, etc. If we used *only* 'artist', perhaps, but not if we used 'artist' *AND* 'composer' + 'technician'. There aren't enough examples that list the composer or the technician to make the argument for adding those into hAudio. You're more than welcome to go back through the audio-info-examples and re-analyze all of the sites to prove your point, though. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: It seems strange that the microformat does not distinguish between the main contributor and others. It does - you list the main contributor first, if you care about that sort of thing. Otherwise, you can list them in any order. Both the Beatles and Geoff Emerick contributed to Sgt. Pepper's Lonely Hearts Club Band, for instance: http://en.wikipedia.org/wiki/Sgt._Pepper%27s_Lonely_Hearts_Club_Band but one is clearly more significant than the other. Sure - but what about this one: http://music.yahoo.com/release/115057 Which one is more significant than the other - the label or the artist? Are creators more important than contributors? These questions are philosophical in nature - you can't assume that creator should be used to note the significance of a contribution. There does seem to be a tendency in microformats, towards unduly low granularity; I find that strange. Why do you find that strange? We're working with lowest common denominator here. When you do that, you get low granularity. Although in classical music, the composer may be as-, or more-, prominent than the artist; likewise the conductor. Higher granularity would allow for such distinctions. Sure - now all you have to do is find enough examples online, (we'll need about 30 with the composer clearly denoted as well as the artist with the composer more prominently displayed than the artist) for us to make the argument for putting this feature into hAudio. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: It would work, but so would a number of very complicated things. My needs are essentially very simple: artistPrimal Scream/artist - albumScreamadelica/album so span class=creatorPrimal Scream/span - span class=albumScreamadelica/span Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div Per the hAudio spec, you have just marked up an album called Screamadelica, whose primary contributor (the artist) is Primal Scream. The example above is valid hAudio markup - is your issue with the word contributor instead of creator? If there really weren't enough examples that clearly listed anybody other than the creator, doesn't that make things easier? Sorry, that was badly worded on my part. What I meant to express was: There weren't enough examples that clearly showed that people were using the word artist, label, not mentioning the role, or using publisher more than the others. It was a mixed bag and what we saw at the end was the chance to support all of these by using contributor in the simple cases and contributor + hCard role in the complex cases. None of this seems to be an issue with what you're trying to mark up, though. If it is still an issue, could you please post some other data that you're attempting to markup where the hAudio spec doesn't let you mark it up in the way that you want to? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Manu Sporny wrote: Alf Eaton wrote: How about this: * All contributors played a role in the creation of the audio. * If there's one or more creators, those entities played a primary role. We looked at that approach, and found that we didn't have the examples to back up the argument that we should make the distinction between creator and contributor because there weren't enough examples that clearly listed anybody other than the creator, and because hCard already has a role field. If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the role property[1]. But then I'm struggling to think of actual examples where your rule wouldn't be enough (though having to list the main contributor at the start of the list might be one problem). It just feels wrong not to be able to explicitly mark the primary creator(s) when, as you say, sometimes you do want to do just that. You can do this using role in hCard when describing the contributor. If this doesn't work for you, you can use hCard RDFa which does differentiate between the primary creator(s) and contributors. What if there are two primary creators (composer and performer, say) and the rest are just auxiliary contributors? You could mark up each primary creator's role using hCard to describe each creator. You could not specify the auxiliary contributors' roles, or you could specify them - it's up to you to determine how specific you want to be. Does that work for your needs? It would work, but so would a number of very complicated things. My needs are essentially very simple: artistPrimal Scream/artist - albumScreamadelica/album so span class=creatorPrimal Scream/span - span class=albumScreamadelica/span is simpler than span class=contributor vcardabbr class=role title=creator/span class=fnPrimal Scream/span/span - span class=albumScreamadelica/span, hence I like it. If there really weren't enough examples that clearly listed anybody other than the creator, doesn't that make things easier? alf ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: How about this: * All contributors played a role in the creation of the audio. * If there's one or more creators, those entities played a primary role. We looked at that approach, and found that we didn't have the examples to back up the argument that we should make the distinction between creator and contributor because there weren't enough examples that clearly listed anybody other than the creator, and because hCard already has a role field. If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the role property[1]. But then I'm struggling to think of actual examples where your rule wouldn't be enough (though having to list the main contributor at the start of the list might be one problem). It just feels wrong not to be able to explicitly mark the primary creator(s) when, as you say, sometimes you do want to do just that. You can do this using role in hCard when describing the contributor. If this doesn't work for you, you can use hCard RDFa which does differentiate between the primary creator(s) and contributors. What if there are two primary creators (composer and performer, say) and the rest are just auxiliary contributors? You could mark up each primary creator's role using hCard to describe each creator. You could not specify the auxiliary contributors' roles, or you could specify them - it's up to you to determine how specific you want to be. Does that work for your needs? -- manu [1]http://microformats.org/wiki/haudio#Contributor ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div Per the hAudio spec, you have just marked up an album called Screamadelica, whose primary contributor (the artist) is Primal Scream. The example above is valid hAudio markup I thought fn was required. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Alf Eaton [EMAIL PROTECTED] writes If there really weren't enough examples that clearly listed anybody other than the creator, doesn't that make things easier? All that makes easier for me is the confidence to say that the evidence is too limited. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the role property That presumes that the roles are exposed in the page; they may be if or, say a producer, but often using the verb (produced by...), and frequently are not, We don't need to say that Beethoven is a composer, when saying Beethoven's fifth. That's clear to a human (well, mist humans of any western education!) from context; but not to a machine. Before anyone cries hidden metadata, how often to we explicitly say that Mabbett is my family name?, or that 21 High street is a street address? -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes I thought fn was required. It isn't: http://microformats.org/wiki/haudio#Album You MUST use either FN or ALBUM, or both. Thank you. I've updated the cheatsheet: http://microformats.org/wiki/haudio-issues to make that more clear. If you ONLY use FN - you are talking about an audio recording. If you ONLY use ALBUM - you are talking about an audio album. If you use BOTH FN and ALBUM - you are talking about an audio recording from the specified audio album. In that case, perhaps track rather than title is the more appropriate label to replace FN? -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes If there are insufficient examples of composer being listed, that itself is evidence that the examples are inadequate: More to consider here: http://pianosociety.com/ (also an excellent place for genuinely free mp3s!) -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes Why doesn't the following work for you, then? div class=haudio span class=contributorPrimal Scream/span - span class=albumScreamadelica/span /div Per the hAudio spec, you have just marked up an album called Screamadelica, whose primary contributor (the artist) is Primal Scream. The example above is valid hAudio markup I thought fn was required. It isn't: http://microformats.org/wiki/haudio#Album You MUST use either FN or ALBUM, or both. In other words: If you ONLY use FN - you are talking about an audio recording. If you ONLY use ALBUM - you are talking about an audio album. If you use BOTH FN and ALBUM - you are talking about an audio recording from the specified audio album. -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Andy Mabbett wrote: In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes If you really want to make the distinction between a publisher, a drummer, a singer, a technician, and someone else, you can always use an hCard and utilize the role property That presumes that the roles are exposed in the page; they may be if or, say a producer, but often using the verb (produced by...), and frequently are not, We don't need to say that Beethoven is a composer, when saying Beethoven's fifth. That's clear to a human (well, mist humans of any western education!) from context; but not to a machine. Before anyone cries hidden metadata, how often to we explicitly say that Mabbett is my family name?, or that 21 High street is a street address? I agree with others that these are edge cases for microformats. I don't think you are correct when you say that only a human can infer Beethoven--(composerOf)--fifth, from Beethoven's fifth. As far as I've seen in other more lucrative domains than music, a well-trained semantic software extractor working off sufficient content, plain old grammatically-correct english and music metadata would do that job with less sweat than an editor will take to write the content and mark it up in hAudio or something else (not to say to come up with the markup that works in these edge cases in the first place). Grammatically-correct english IS semantic markup, in a way. I think microformats' sweet spot is easing semantic extraction in cases where the level of structure is high, and the plain english context is low. The back of an album that lists tracks is such a case, its entry in Gracenote, a list of friends, electronic business cards, etc. are good examples as well. A plain english critics' review of an album on the other hand with lots of context, but little structure is a case that is economically much better handled using semantic analysis than with $1M markup. I'm not saying that microformats should not try to make formats that work with plain old English or natural language (I've been trying myself), I'm just saying that we may consider the fact that the ROI will most likely be low and other technologies will compete better there, so we might just focus our time on where we have the biggest chance of straightforward adoption, then only look at solving the plain english cases, instead of trying to solve everything at once. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Alf Eaton wrote: I was looking at using haudio today, but stumbled on the 'contributor' field: is there a reason it's 'contributor' rather than 'creator', even for the main creator (artist, in music) of the piece of audio? We decided to not use creator because it would not be the proper semantic word for say, a publisher, or a composer. Most of the examples that we came across listed the publisher as well as the band that created the musical piece (CD). However, calling the publisher a creator would not be semantically correct. Dublin core makes this differentiation. There is a dc:creator field, which is a narrower concept from dc:contributor. Microformats try to use the most common subset of information among all examples. Some had artist, some had publisher, some had label, others had band - these are all contributors. hAudio allows for listing multiple contributors. If only one contributor is listed, it is assumed that he/she/it is also the creator of the hAudio. If multiple contributors are listed, it is assumed that the first contributor is the creator, and all subsequent contributors played supporting roles in the creation of the hAudio. Thus, it can be said: Not all contributors are creators. Not all contributors are artists. Thus, we should not narrow the who made it? behind hAudio down to those more narrow categories. It doesn't seem to be based on established practice, as from the overview it looks like existing markup overwhelming uses 'artist'. http://microformats.org/wiki/audio-info-brainstorming#artist If we used artist, we would not have been able to mark up publishers, composers, audio technicians, etc. Does that make sense? Does that explanation raise any further questions? -- manu ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Manu Sporny [EMAIL PROTECTED] writes If only one contributor is listed, it is assumed that he/she/it is also the creator of the hAudio. If multiple contributors are listed, it is assumed that the first contributor is the creator, and all subsequent contributors played supporting roles in the creation of the hAudio. That fails as soon as we want to mark up something like: Simon Rattle conducted the CBSO in a marvellous rendition of Beethoven's Fifth or: Simon Rattle conducted a marvellous rendition of Ma Vlast or: EMI are pleased to announce a new downloadable version of the Beatles' 'Sgt Pepper...' or: EMI are pleased to announce a new downloadable version of 'Sgt Pepper...' Thus, it can be said: Not all contributors are creators. Not all contributors are artists. That can certainly be said. However, it cannot be expressed in hAudio without requiring the publishers of such examples to re-order their content. It is a microformats principle to not do so. Thus, we should not narrow the who made it? behind hAudio down to those more narrow categories. Your conclusion is not supported by the forgoing claims. It doesn't seem to be based on established practice, as from the overview it looks like existing markup overwhelming uses 'artist'. http://microformats.org/wiki/audio-info-brainstorming#artist If we used artist, we would not have been able to mark up publishers, composers, audio technicians, etc. If we used *only* 'artist', perhaps, but not if we used 'artist' *AND* 'composer' + 'technician'. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
In message [EMAIL PROTECTED], Alf Eaton [EMAIL PROTECTED] writes I was looking at using haudio today, but stumbled on the 'contributor' field: is there a reason it's 'contributor' rather than 'creator', even for the main creator (artist, in music) of the piece of audio? It seems strange that the microformat does not distinguish between the main contributor and others. Both the Beatles and Geoff Emerick contributed to Sgt. Pepper's Lonely Hearts Club Band, for instance: http://en.wikipedia.org/wiki/Sgt._Pepper%27s_Lonely_Hearts_Club_Band but one is clearly more significant than the other. I can find no evidence of any published website which does not make such distinctions (anyone is welcome to provide some). There does seem to be a tendency in microformats, towards unduly low granularity; I find that strange. It doesn't seem to be based on established practice, as from the overview it looks like existing markup overwhelming uses 'artist'. http://microformats.org/wiki/audio-info-brainstorming#artist Although in classical music, the composer may be as-, or more-, prominent than the artist; likewise the conductor. Higher granularity would allow for such distinctions. Here too, we might learn from the Dublin Core Simple + Qualified model [1]. We could have several classes: contributor then: contributor-artist contributor-composer contributor-conductor contributor-engineer etc. and agents may entitled to treat all the latter as equivalent to the first, but should preserve the full values when exporting. In practise, the latter set could omit the contributor- stem, and agents would then treat it as implied. Some people might argue instead for a 'contributor-type' property, but it is common usage to simply imply the main contributor's role: *The Joshua Tree by U2, produced by Brian Eno and Daniel Lanois *Beethoven's fifth Symphony, conducted by Simon Rattle *Smetana's Ma Vlast, performed by the London Philharmonic Orchestra (note also the common usage of the verbs produced, conducted and performed rather than the role-nouns of producer, conductor and performer. [1] A parallel might also be drawn with tel vs. tel-work, tel-cell, etc. -- Andy Mabbett ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] haudio contributor
Manu Sporny wrote: Alf Eaton wrote: I was looking at using haudio today, but stumbled on the 'contributor' field: is there a reason it's 'contributor' rather than 'creator', even for the main creator (artist, in music) of the piece of audio? We decided to not use creator because it would not be the proper semantic word for say, a publisher, or a composer. Most of the examples that we came across listed the publisher as well as the band that created the musical piece (CD). However, calling the publisher a creator would not be semantically correct. Dublin core makes this differentiation. There is a dc:creator field, which is a narrower concept from dc:contributor. Microformats try to use the most common subset of information among all examples. Some had artist, some had publisher, some had label, others had band - these are all contributors. hAudio allows for listing multiple contributors. If only one contributor is listed, it is assumed that he/she/it is also the creator of the hAudio. If multiple contributors are listed, it is assumed that the first contributor is the creator, and all subsequent contributors played supporting roles in the creation of the hAudio. How about this: * All contributors played a role in the creation of the audio. * If there's one or more creators, those entities played a primary role. But then I'm struggling to think of actual examples where your rule wouldn't be enough (though having to list the main contributor at the start of the list might be one problem). It just feels wrong not to be able to explicitly mark the primary creator(s) when, as you say, sometimes you do want to do just that. What if there are two primary creators (composer and performer, say) and the rest are just auxiliary contributors? alf ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
