From andy at pigsonthewing.org.uk Fri Feb 1 01:00:00 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 1 01:01:08 2008 Subject: [uf-new] hAudio FN or Title In-Reply-To: <18050cf90801312019h58b8734frb45baa9b28965461@mail.gmail.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A21AE0.6060501@digitalbazaar.com> <21e770780801311330n1b62197dm99be90db133b462e@mail.gmail.com> <18050cf90801312019h58b8734frb45baa9b28965461@mail.gmail.com> Message-ID: In message <18050cf90801312019h58b8734frb45baa9b28965461@mail.gmail.com>, Paul Wilkins writes >On Feb 1, 2008 12:26 PM, Andy Mabbett >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 "" 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 From info at weborganics.co.uk Fri Feb 1 05:07:11 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Fri Feb 1 05:07:24 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Thu, 2008-01-31 at 18:39 +0000, Martin McEvoy wrote: > Hello All > > This is in Response to Manu's suggestion that maybe we should talk about > changing hAudio "FN" to "Title" > > > I've never been happy with the choice of FN instead of TITLE in hAudio > (TITLE means "job title" in Microformats). This could offer a good > compromise if people are interested? > > http://microformats.org/discuss/mail/microformats-discuss/2008-January/011446.html > > Manu I for Once Agree with you ;) and I'm not too happy with it either. > Feedback I have had about haudio seem to all have the same answer audio > has a title too lets call it that. > > I am unsure If we should re-use "title" directly from hcard "Job title" > and "audio title" are both functions I guess? maybe someone can have > more input on this. > > If the above Is impossible maybe an answer may be a talk about maybe a > htitle Microformat or something. > > Anyway anyone who is Interested lets get the ball rolling. > > Thanks > > Martin McEvoy > Here Is a Proposal Most popular media syndication formats use *title* to describe the name of a playlist or track eg: RSS2 - title http://cyber.law.harvard.edu/rss/rss.html#hrelementsOfLtitemgt Atom - title http://www.atomenabled.org/developers/syndication/#requiredEntryElements M3U PLS - Title http://forums.winamp.com/showthread.php?threadid=65772 XSPF - Title http://www.xspf.org/xspf-v1.html#rfc.section.4.1.1.2.1 iTunes Podcast - title http://www.apple.com/itunes/store/podcaststechspecs.html Vorbis Comments - title http://www.xiph.org/vorbis/doc/v-comment.html ASX - Title http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/samples/internet/imedia/netshow/simpleasx/default.asp media-rss - media:title http://search.yahoo.com/mrss It is desirable that we use "Title" altough We can not use "title" directly because of the conflicts it causes with hcard "title", I also think it may be difficult to re-define "title" across all microformats Proposed solution use a class prefix, I am proposing that we use *audio-title* the main reason is because the title we are trying to describe is an audio title. an example of how this may look taken from http://microformats.org/wiki/haudio#Multi-part_Podcast_Example

DigitalPlanet Podcast 29 Oct 07

Forensic computing: is it really possible to delete data from your machine?
Grand plans for getting broadband into Africa
,
checking out the sky at night via the internet
and
answering your emails
to the programme.

Download MP3

Thanks Comments, Thoughts other solutions welcome Martin McEvoy From tantek at cs.stanford.edu Fri Feb 1 08:58:34 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Fri Feb 1 08:57:04 2008 Subject: [uf-new] hAudio FN or Title In-Reply-To: <21e770780801311330n1b62197dm99be90db133b462e@mail.gmail.com> Message-ID: On 1/31/08 1:30 PM, "Brian Suda" wrote: > 2008/1/31, Manu Sporny : >> The thought about porting the Dublin Core names over to Microformats was >> mentioned on the uf-discuss list. Having a Dublin Core Microformat, may >> be a solution that works for everybody. > > --- we just have to be careful of creating a solution to a non-issue. > Microformats model established publishing practices and solve simple > problems. > >> The main disagreement seemed to be in DC's choice of class names... That's only one problem with DC. The other problem is that DC itself is more theoretical rather than based on any actual content publishing research/behaviors. >> This approach has two benefits: >> >> * It uses Microformat-like names. > > --- it might be microformat-like, and that is fine, but it doesn't > need to be a microformat. It can be POSH or RDFa or eRDF, or others. > Having a pseudo namespace DC-foobar has been discouraged before. Agreed. 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 by itself is not the answer. http://microformats.org/wiki/citation >> * 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. It's not really got much support of tools that support it and do something useful with it - mostly academic projects. > --- this is good we want to re-use not re-invent, but we also don't > want to re-use whole-sale when possible, simply copying all of dublin > core seems to be a solution to a non-problem. > > As new formats are created, we can look to existing formats like > dublin core, we have done that with hAudio and attempted to reuse > terms such as CONTRIBUTER, IMHO this is the proper way to proceed. Not > a new dc-kitchen-sink-and-more approach. Agreed, I just wrote up this process FAQ entry regarding "re-use whole-sale" Brian, feel free to expand on it, as you also have been around in the community long enough to remember some of these old discussions. Thanks, Tantek From andy at pigsonthewing.org.uk Fri Feb 1 11:54:45 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 1 11:56:14 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: In message <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com>, Martin McEvoy writes >an example of how this may look >taken from >http://microformats.org/wiki/haudio#Multi-part_Podcast_Example > >
>

> DigitalPlanet Podcast > 29 Oct 07 >

>

>

> Forensic computing: is it really possible to >delete data from your machine? >
>
> Grand plans for getting broadband into >Africa >
[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: -- Andy Mabbett From andy at pigsonthewing.org.uk Fri Feb 1 12:39:10 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 1 12:40:40 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: References: <21e770780801311330n1b62197dm99be90db133b462e@mail.gmail.com> Message-ID: In message , Tantek ?elik 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" > >rom_another_format_vocabulary> There is a requirement on the wiki that opinions are marked up as such - see point 4 on: Background: Folks new to DC might like to read: 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:

DigitalPlanet Podcast 29 Oct 07

[...]
could, using a wrapper class to encompass the item to which the DC metadata applies, become:

DigitalPlanet Podcast 29 Oct 07

[...]
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 From info at weborganics.co.uk Fri Feb 1 13:35:32 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Fri Feb 1 13:35:38 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Fri, 2008-02-01 at 19:54 +0000, Andy Mabbett wrote: > "audio-title" is more appropriate than title; but I'm still concerned > that "item" is both vague and insufficiently granular. It is isn't it, again feedback I have had from would be users is "why not track" track seems to say what haudio means. > > What happens when a podcast is reviewed, or includes reviews, and the > review(s) (or some other microformat) use "item"? I have been testing haudio quite extensively using xslt, haudio embeds in hAtom for example pretty well, but 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. anyway can I suggest that we think about changing Item too? we keep on referring to "track" In our discussions (as many people do) so lets call it that. maybe:

DigitalPlanet Podcast 29 Oct 07

Forensic computing: is it really possible to delete data from your machine?
I think parsing rules would be pretty easy on this and above all no conflicts with other uF's and its keeping it simple. > > Similarly, this still doesn't address the confusion between hAudio's > fn > and hCard (or whatever's) fn, as raised previously: True ;) Thanks Martin McEvoy From andy at pigsonthewing.org.uk Fri Feb 1 14:09:04 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 1 14:10:20 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: In message <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com>, Martin McEvoy 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 From info at weborganics.co.uk Fri Feb 1 16:03:56 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Fri Feb 1 16:10:52 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Fri, 2008-02-01 at 22:09 +0000, 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 (makes your head spin trying to explain that to people), in hreview it is the name of the thing that is under review and the name of the reviewer, kind of devalues the semantics of "fn" don't you think? instead of being something specific its turned into something more general. So yes in light of the above maybe we shouldn't re-use class names so willingly, most of the community that spend a lot of time working these things out, the only time we should is if what we are trying to describe has the exact same meaning, only then would it make sense to re-use. Thanks Martin McEvoy From guillaume at lebleu.org Fri Feb 1 17:33:52 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Fri Feb 1 17:34:00 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <47A3C880.3000902@lebleu.org> Martin McEvoy wrote: > On Fri, 2008-02-01 at 22:09 +0000, 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 (makes your head > spin trying to explain that to people), in hreview it is the name of the > thing that is under review and the name of the reviewer, kind of > devalues the semantics of "fn" don't you think? instead of being > something specific its turned into something more general. So yes in > light of the above maybe we shouldn't re-use class names so willingly, > most of the community that spend a lot of time working these things out, > the only time we should is if what we are trying to describe has the > exact same meaning, only then would it make sense to re-use. > Wouldn't you say that this is equivalent to saying that what is really important is that the meaning of class names be context-insensitive, i.e. a class name like fn's meaning should not change when used within an haudio or an hcard ? By the way, about "fn", as you know, it stands for "formatted name", i.e. how the name is displayed, which is really a useful distinction to make when: * on one hand the name exists in other representations not intended for display, i.e. "structured" "tokenized"representations useful for indexing/searching in particular, where honorific title, given name, family name, etc. are distinguished, * and on the other hand, the actual representation used for display (meaning really for serial representation, i.e. printed on a letter) must be kept handy b/c the formatting rules vary widely from locale to locale, and finding them out, representing in code, and running them each time you want to print does not make sense. Assuming this more precise meaning, I don't think it applies to a song name, which does not have to my knowledge a tokenized form. (BTW, assuming this meaning, "fn" may not even be always appropriate even for all displayable by nature HTML-based representations of a person's name: take the particular case of an HTML table where a person's name is typically in a tokenized representation, which may not correspond to the localized serial representation a.k.a. "formatted name") Guillaume From info at weborganics.co.uk Sat Feb 2 03:11:41 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 2 03:11:52 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <47A3C880.3000902@lebleu.org> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A3C880.3000902@lebleu.org> Message-ID: <1201950702.10786.45.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Fri, 2008-02-01 at 17:33 -0800, Guillaume Lebleu wrote: > Martin McEvoy wrote: > > On Fri, 2008-02-01 at 22:09 +0000, 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 (makes your head > > spin trying to explain that to people), in hreview it is the name of the > > thing that is under review and the name of the reviewer, kind of > > devalues the semantics of "fn" don't you think? instead of being > > something specific its turned into something more general. So yes in > > light of the above maybe we shouldn't re-use class names so willingly, > > most of the community that spend a lot of time working these things out, > > the only time we should is if what we are trying to describe has the > > exact same meaning, only then would it make sense to re-use. > > > > Wouldn't you say that this is equivalent to saying that what is really > important is that the meaning of class names be context-insensitive, > i.e. a class name like fn's meaning should not change when used within > an haudio or an hcard ? correct I think :) > > By the way, about "fn", as you know, it stands for "formatted name", > i.e. how the name is displayed, which is really a useful distinction to > make when: > > * on one hand the name exists in other representations not intended > for display, i.e. "structured" "tokenized"representations useful > for indexing/searching in particular, where honorific title, given > name, family name, etc. are distinguished, > * and on the other hand, the actual representation used for display > (meaning really for serial representation, i.e. printed on a > letter) must be kept handy b/c the formatting rules vary widely > from locale to locale, and finding them out, representing in code, > and running them each time you want to print does not make sense. > > Assuming this more precise meaning, I don't think it applies to a song > name, which does not have to my knowledge a tokenized form. No it doesn't, not really, suppose we take this: Start Wearing Purple If we were to assume the precise meaning, in context or hcard the above example would be a first name "given-name", a secondary name "additional-name" and a last name "family-name" applications that may index the above example may take it to mean precisely that! which is of course incorrect. A thing I may add is, is the above example the formatted name of and album, a track, a person or an organization? and is "fn" appearing in the correct context? hcard has the ability to expand the meaning of "fn" haudio does not. Do you not think that context is an important factor in microformats? you could use a bit of posh instead an example may be: Start Wearing Purple and not even trouble ourselves with the meaning of "fn", of course our haudio title does mean a little more than just a cited source or reference but the semantics are correct is not appearing out of context as "fn" is currently in haudio. > (BTW, > assuming this meaning, "fn" may not even be always appropriate even for > all displayable by nature HTML-based representations of a person's name: > take the particular case of an HTML table where a person's name is > typically in a tokenized representation, which may not correspond to the > localized serial representation a.k.a. "formatted name") > > Guillaume Thanks Martin McEvoy > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Sat Feb 2 11:20:48 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Feb 2 11:20:51 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <47A4C290.5000306@digitalbazaar.com> Martin McEvoy wrote: > On Fri, 2008-02-01 at 22:09 +000-, 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: http://en.wikipedia.org/wiki/Namespace I have always been in favor of using namespaces, but it seems as if the rest of the Microformats community are against the concept because of the added complexity (and there certainly is added complexity). Andy, Martin - are you proposing 'context-aware vocabularies' or something similar to that? Brian, Tantek - 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. -- manu From bjonkman at sobac.com Sat Feb 2 11:41:50 2008 From: bjonkman at sobac.com (Bob Jonkman) Date: Sat Feb 2 11:42:21 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: References: , <47891E3F.6010604@klml.de>, Message-ID: <47A4812E.7007.64D341A@bjonkman.sobac.com> This is what Jonas Pfenniger said about "Re: [uf-new] New proposed microformat: hProject" on 12 Jan 2008 at 23:45 > it seems > to me that time is not necessarily central to a project. Yes, you > have a start date and maybe a location but I don't see more > correlations. Two cents, two weeks late: As a Project Manager, having calendar data is only a small part of project planning. As a "project resource" (ie. the grunt that does the work) it is extremely valuable to have my calendar application automatically populated with the project's tasks. It's tough enough finding OS project management software; getting microformat support for project management software would be a great thing. --Bob. -- -- -- -- Bob Jonkman http://sobac.com/sobac/ SOBAC Microcomputer Services Voice: +1-519-669-0388 6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413 Software --- Office & Business Automation --- Consulting From andy at pigsonthewing.org.uk Sat Feb 2 11:54:46 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Feb 2 11:56:23 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <47A4C290.5000306@digitalbazaar.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> Message-ID: <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> In message <47A4C290.5000306@digitalbazaar.com>, Manu Sporny 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: 1 A microformat, or microformat-like system, for marking up DC metadata in published content; about which I wrote yesterday: (aka ) 2 Re-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: * Free Our Data: * Are you using Microformats, yet: ? From info at weborganics.co.uk Sat Feb 2 12:01:17 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 2 12:01:27 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <47A4C290.5000306@digitalbazaar.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> Message-ID: <1201982477.15377.25.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sat, 2008-02-02 at 14:20 -0500, Manu Sporny wrote: > > This is the start of an argument for namespaces: > > http://en.wikipedia.org/wiki/Namespace I think microformats already DO support limited namespaces, not fully loaded namespaces like RDFa does, but kind of micro-namespaces, its difficult for me to explain what I mean but here goes... "...since we were reusing the semantics of the IETF Atom standard, we very much wanted to reuse the vocabulary as well to minimize confusion and mean precisely the same semantics as defined in the Atom RFC 4287, and thus a few of the hAtom properties appear to be prefixed (entry-title, entry-content, entry-summary) in order to literally reuse those terms from the RFC (title, content, summary)." http://microformats.org/wiki/hatom-faq#Why_does_hAtom_use_class_name_namespaces Interesting I think? This Is why earlier in the tread I suggested we use "audio-title" it is mimicking the concept of "entry-title" hAudio does not follow any RFC standard like hAtom does, but in my view it does in a way because it is being built to a Microformats standard using the "process". hAudio will (eventually) be an audio "standard" so it makes sense to use a class namespace like "audio-[...]". What do you think? Martin McEvoy From guillaume at lebleu.org Sat Feb 2 12:32:24 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Sat Feb 2 12:32:31 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201982477.15377.25.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <1201982477.15377.25.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <47A4D358.7090403@lebleu.org> Martin McEvoy wrote: > On Sat, 2008-02-02 at 14:20 -0500, Manu Sporny wrote: > >> This is the start of an argument for namespaces: >> >> http://en.wikipedia.org/wiki/Namespace >> > > I think microformats already DO support limited namespaces, not fully > loaded namespaces like RDFa does, but kind of micro-namespaces, its > difficult for me to explain what I mean but here goes... > I agree that they seem to in some instances. For instance in: http://www.mail-archive.com/microformats-discuss@microformats.org/msg09243.html in a reply to my question why fn isn't enough, why we always need to wrap it up with vcard, Andy argued: "the classes "fn" and/or "n" might already be used, with different (or no) semantic meaning" [than the "fn" used under a vcard] I replied in: http://www.mail-archive.com/microformats-discuss@microformats.org/msg09248.html "what I'm reading here is that classname "fn" may have different meaning if used outside of an element of class "vcard". Saying this is to me equivalent to saying the "vcard" classname syntax is syntactic sugar for the concept of a namespace (as is "vcard-fn" or "vcard:fn"). My understanding was that the concept of namespace, not just its xml syntax, was an antipattern in microformats. Am I mistaken?" The discussion ended here unfortunately. AFAIC, I think that class names should not have context-sensitive meaning (i.e. different meaning depending on why class wrap them), except if the parent meaning precise its meaning. In other words, "fn" should always be used for "formatted names", but if "fn" is used for a song's name as it is today, then it may be inferred, that fn is not just a name, but the title of the song, since "title" is the word of choice for a work of art's name (see http://www.answers.com/title&r=67). Namespaces allows the same word to mean different things under different NS. I think this is bad and my understanding is that is what microformats are trying to avoid, not just the XML ns syntax. On the other hand, allowing more precise meaning to be inferred from a class name and the context where it appears makes sense to me. Guillaume From info at weborganics.co.uk Sat Feb 2 12:38:01 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 2 12:38:08 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> Message-ID: <1201984681.15377.39.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sat, 2008-02-02 at 19:54 +0000, Andy Mabbett wrote: > >Andy, Martin - are you proposing 'context-aware vocabularies' or > >something similar to that? > > I don't know what you mean by that term. I think he means "Context-Aware Information" its a concept of workflow, context, vocabulary or ontology, profile and Aggregation or syndication. "context-aware vocabularies" I would say are a part of this RDF and OWL and RDFa spring to mind. And to answer Manu's no I don't think its necessary, Microformats already ARE context aware? Thanks Martin McEvoy From info at weborganics.co.uk Sat Feb 2 14:50:33 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 2 14:50:44 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <47A4D358.7090403@lebleu.org> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <1201982477.15377.25.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4D358.7090403@lebleu.org> Message-ID: <1201992633.15377.86.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Hello Guillaume... On Sat, 2008-02-02 at 12:32 -0800, Guillaume Lebleu wrote: > "what I'm reading here is that classname "fn" may have different > meaning > if used outside of an element of class "vcard". Saying this is to me > equivalent to saying the "vcard" classname syntax is syntactic sugar > for > the concept of a namespace (as is "vcard-fn" or "vcard:fn"). My > understanding was that the concept of namespace, not just its xml > syntax, was an antipattern in microformats. Am I mistaken?" It is what I personaly am beginning to believe, I will say that not all "anti-patterns" are a bad thing in my experience and shouldn't be understood as such, HTML Standards make a publisher in html program their pages correctly with all factors taken into consideration. Things that can be viewed as cool and desirable such as in-line java-script, Flash movies hidden metadata, and even include software applications Such as Dreamweaver and FrontPage ALL create "anti-patterns" and should be avoided and "labeled" as such. The "real-word" of course will ignore my above ravings :) HTML standards make most people get back to their roots so to speak, make them understand html, css, xml from the beginning, how it should be in html. namespaces in standards are a good thing just because we don't say ...etc doesn't mean we are not?. hAtom is a very good example I think of microformats making their OWN namespace by "mimicking" another Atom http://atomenabled.org/developers/syndication/ "bridging the gap" http://microformats.org/wiki/hatom#Format so to speak referencing or citing standards as a reference are "invoking" these standards and namespaces in html. so when we say lets use "fn" from vcard invoking the rfc2426 standard http://www.ietf.org/rfc/rfc2426.txt i dont think it is possible for us to change "FN"'s meaning?. Anyway just philosiphising Thanks Thanks Martin McEvoy From info at weborganics.co.uk Sat Feb 2 14:59:43 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 2 14:59:52 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201992633.15377.86.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <1201982477.15377.25.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4D358.7090403@lebleu.org> <1201992633.15377.86.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1201993183.15377.93.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sat, 2008-02-02 at 22:50 +0000, Martin McEvoy wrote: > > Anyway just philosiphising ended the only way I could ;) idiot typo sorry "philosophizing" Thanks Martin McEvoy From info at weborganics.co.uk Sat Feb 2 15:29:00 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 2 15:29:10 2008 Subject: [uf-new] Re: hAudio FN or Title In-Reply-To: <1201992633.15377.86.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <1201982477.15377.25.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4D358.7090403@lebleu.org> <1201992633.15377.86.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1201994940.16628.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sat, 2008-02-02 at 22:50 +0000, Martin McEvoy wrote: > Hello Guillaume... > > On Sat, 2008-02-02 at 12:32 -0800, Guillaume Lebleu wrote: > > "what I'm reading here is that classname "fn" may have different > > meaning... Guillaume... http://lebleu.org/blog/2008/02/02/the-meaning-of-vcards-fn/ Good point. Thanks Martin McEvoy From msporny at digitalbazaar.com Sun Feb 3 11:39:14 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Feb 3 11:39:17 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: References: <478CDCDC.2070407@digitalbazaar.com> <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> <478CED6B.1010503@digitalbazaar.com> Message-ID: <47A61862.80802@digitalbazaar.com> Andy Mabbett wrote: > 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 - could you please list the issues that you have with hAudio on the audio-info-issues page so that we can track them. I remember seeing 3 distinct issues that you raised in the past month (although, there may be more). I've been meaning to document them for several weeks, but haven't gotten around to doing so. You'd be the best person to word it in a way that you agree with: http://microformats.org/wiki/audio-info-issues -- manu From msporny at digitalbazaar.com Sun Feb 3 11:31:50 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Feb 3 11:39:18 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <1201984681.15377.39.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> <1201984681.15377.39.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <47A616A6.6090903@digitalbazaar.com> Martin McEvoy wrote: > I think he means "Context-Aware I > And to answer Manu's no I don't think its necessary, Microformats > already ARE context aware? Yes! This is my point exactly. If Microformats ARE context aware, then there is the concept of namespaces in Microformats. Namespaces are NOT an anti-pattern afterall. Guillaume wrote: > "what I'm reading here is that classname "fn" may have different > meaning if used outside of an element of class "vcard". Saying this is > to me equivalent to saying the "vcard" classname syntax is syntactic > sugar for the concept of a namespace (as is "vcard-fn" or "vcard:fn"). > My understanding was that the concept of namespace, not just its xml > syntax, was an antipattern in microformats. Am I mistaken?" No, you're not mistaken. You've just pointed out one of the logical fallacies in the Microformats community. The community keeps repeating that namespaces are bad and that we shouldn't use them, all the while using them in each and every Microformat that we put out. Here's an example of this logical fallacy: "What is the semantic meaning of FN outside of any Microformat markup?" The undeniable answer is: "There is no semantic meaning outside of any Microformat." FN doesn't mean anything useful until it is "wrapped" by a Microformat - hCard, or hAudio, for example. This means that the wrapping Microformat brings context into the equation. That is the core definition of a namespace: "In general, a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allowing disambiguation of items having the same name (residing in different namespaces)."[1] FN in hAudio is really marking up "the audio recording's title", FN in hCard is really marking up "the person or organization's formatted name". FN means two different things when used in hCard and hAudio. So does TITLE, if we were to adopt it for hAudio. It is as if we're defaulting to hCard to define the meaning of TITLE instead of defaulting to the English language to define the meaning of TITLE. Yes, the English language has ambiguous terms, but that is why we have the concept of context in the English language and programming languages have the concept of namespaces. It is time for this community to realize that ambiguity is fine as long as we have a method of disambiguation - namespaces, and more specifically, context... which is already used, even though it is listed as an anti-pattern. We should be using TITLE for the title of audio recordings. hCard shouldn't prevent us from doing so because of a narrow definition for TITLE that was entered into the wiki several years back by one person. The reason we aren't using title right now is because the Microformats wiki defines "TITLE" as "job title" - which goes against the English definition of the word. So, who is going to make an argument against using TITLE in hAudio? -- manu [1]http://en.wikipedia.org/wiki/Namespace From info at weborganics.co.uk Sun Feb 3 12:09:54 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun Feb 3 12:16:23 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A616A6.6090903@digitalbazaar.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> <1201984681.15377.39.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A616A6.6090903@digitalbazaar.com> Message-ID: <1202069394.32654.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sun, 2008-02-03 at 14:31 -0500, Manu Sporny wrote: > FN doesn't mean anything useful until it is "wrapped" by a Microformat > - > hCard, or hAudio, for example. This means that the wrapping > Microformat > brings context into the equation. The same as if we use "title" outside of hcard IT "doesn't mean anything useful", wrap it in "haudio" the function of the object "title" would then become an audio "title", nothing at all to do with hcard? Thanks Martin McEvoy From info at weborganics.co.uk Sun Feb 3 12:24:19 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun Feb 3 12:31:41 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <1202069394.32654.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> <1201984681.15377.39.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A616A6.6090903@digitalbazaar.com> <1202069394.32654.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1202070259.32654.6.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sun, 2008-02-03 at 20:09 +0000, Martin McEvoy wrote: > wrap it in "haudio" the function of the object "title" well... kind of but you get what I am driving at? :) Thanks Martin From tantek at cs.stanford.edu Sun Feb 3 22:34:01 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Sun Feb 3 22:32:48 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A616A6.6090903@digitalbazaar.com> Message-ID: On 2/3/08 11:31 AM, "Manu Sporny" wrote: > Martin McEvoy wrote: >> I think he means "Context-Aware I >> And to answer Manu's no I don't think its necessary, Microformats >> already ARE context aware? > > Yes! This is my point exactly. If Microformats ARE context aware, then > there is the concept of namespaces in Microformats. Namespaces are NOT > an anti-pattern afterall. Manu, context is not the same as namespaces. namespaces provide one form of context, but not all contexts are namespaces. in the case of compound microformats, the context that is used is hierarchical containment. "fn" *does* have meaning - it means "formatted name". Inside an hCard it means the formatted name of either a person, organization, or location (depending on the specifics of the hCard). Inside an hReview item it means the formatted name of an item. > So, who is going to make an argument against using TITLE in hAudio? The problem of such use of the term "title" is twofold. 1) it's already used to mean "job title" in the context of microformats. 2) the concept that it is being proposed to represent is the *name* of an audio item. "fn" already means the name of an item. we should not introduce a new term to mean the same thing as an existing term. Tantek From info at weborganics.co.uk Mon Feb 4 02:30:49 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 02:31:01 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: References: Message-ID: <1202121049.4203.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Sun, 2008-02-03 at 22:34 -0800, Tantek =?ISO-8859-1?B?xw==?=elik wrote: > 1) it's already used to mean "job title" in the context of > microformats. > 2) the concept that it is being proposed to represent is the *name* of > an > audio item. "fn" already means the name of an item. we should not > introduce a new term to mean the same thing as an existing term. "fn" in vcard rfc 2426[1] [1] http://www.ietf.org/rfc/rfc2426.txt inherits its semantics from X.520[2] (2001) ?commonName.? attribute [2] http://www.itu.int/ITU-T/asn1/database/itu-t/x/x520/2001/SelectedAttributeTypes.html [3] "[...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 may be more desirable to use "cn" meaning "common-name" instead of "fn" the semantics are more precise and we are not confusing anyone with using "fn" Thanks Martin McEvoy From JOttevanger at museumoflondon.org.uk Mon Feb 4 02:47:34 2008 From: JOttevanger at museumoflondon.org.uk (Ottevanger, Jeremy) Date: Mon Feb 4 02:47:28 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: Message-ID: Hi. Coming out of lurk mode, I must say that I'm in complete agreement with Andy. Thanks to Jim, by the way, for kicking this one off. When a while back I mooted (rather wrong-headedly, I think) the possibility of a microformat for museum objects, I was considering (and had suggested to me, by Andy for one) using DC or perhaps something like CDWALite as the basis for the class names for parts of it. I've subsequently rethought the way in which one might achieve the various aspects of what I want to see possible, and the microformat-relevant part of that is clearly capturable using DC. It might, of course, be enhanced by the use of a profile, but the starting point is DC. As Andy says, DC is widely established and yes, Tantek, it is a metadata format that is at present used only in hidden parts of HTML documents, but it would be so much more useful if this wasn't the case - precisely why a microformat would be a big boon. Apart from anything else, one can describe more than one "object" on the page with a microformat, and give it some structure. This cannot be achieved with elements - or at least I don't know how to. I recognise that The Process wisely advocates that formats should where possible build upon those that exist already, and that a DC microformat might tread on some toes in this respect by creating classes that overlap with existing classes in hCalendar, hCard and so on. I hope this needn't interfere unnecessarily, there's simply too much to be gained from making this suggestion happen. There is a ton of content out there that could readily be put into a DC microformat. DC Simple may be limiting in some ways, and personally I'd also like to see Qualified DC in use as a microformat (in due course - perhaps we should wait for DC v.2), but there are a lot of contexts in which it would be useful. To me, now, it makes a lot of sense to pull DC out as a microformat of its own and then think about building more specific applications based on it. I don't really know where the citation proposal fits in, but there is certainly more to DC than citations. There are also a large number of people out there already that understand DC, that know its role and benefits and the correct way to use the elements (well, sort of), and that would not need to be sold it in the way that they may need to be sold other microformats. Seems sensible to me to tap into that. All the best, Jeremy PS sorry if this is a little behind the discussion. Could only webmail at the weekend which means HTML format, which bounced. Jeremy Ottevanger Web Developer, Museum Systems Team Museum of London Group 46 Eagle Wharf Road London. N1 7ED Tel: 020 7410 2207 Fax: 020 7600 1058 Email: jottevanger@museumoflondon.org.uk www.museumoflondon.org.uk Museum of London is changing; our lower galleries will be closed while they undergo a major new development. Visit www.museumoflondon.org.uk to find out more. London's Burning - explore how the Great Fire of London shaped the city we see today www.museumoflondon.org.uk/londonsburning -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Andy Mabbett Sent: 01 February 2008 20:39 To: For discussion of new microformats. Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In message , Tantek ?elik 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" > >mes_f >rom_another_format_vocabulary> There is a requirement on the wiki that opinions are marked up as such - see point 4 on: Background: Folks new to DC might like to read: 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:

DigitalPlanet Podcast 29 Oct 07

[...]
could, using a wrapper class to encompass the item to which the DC metadata applies, become:

DigitalPlanet Podcast 29 Oct 07

[...]
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 From info at weborganics.co.uk Mon Feb 4 03:53:18 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 03:53:32 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: References: Message-ID: <1202125999.3098.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Mon, 2008-02-04 at 10:47 +0000, Ottevanger, Jeremy wrote: > Hi. > > Coming out of lurk mode, I must say that I'm in complete agreement > with Andy. Thanks to Jim, Is GRDDL not a solution to this whole dc question? "W3C Completes Bridge Between HTML/Microformats and Semantic Web" http://www.w3.org/2007/07/grddl-pressrelease Thanks Martin McEvoy From brian.suda at gmail.com Mon Feb 4 03:59:42 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 4 03:59:45 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: References: Message-ID: <21e770780802040359s2f528ff5paa26831997bf0417@mail.gmail.com> 2008/2/4, Ottevanger, Jeremy : > Hi. > > Coming out of lurk mode, --- welcome to the list, and thanks for your thoughts. > I recognise that The Process wisely advocates that formats should where possible build upon those that exist already, and that a DC microformat might tread on some toes in this respect by creating classes that overlap with existing classes in hCalendar, hCard and so on. I hope this needn't interfere unnecessarily, there's simply too much to be gained from making this suggestion happen. --- the process also states: "There must be a problem to be solved (i.e. a real world use case). No problem, no microformat." The idea is NOT to make a generic Dublin Core microformats, but to address a specific problem. People, Places, Events, Music, Books, etc. If there is something specific, then we can get a use-case and develop a format from that. Just making mapping the DC Ontology to class names, doesn?t get us much. We still need a data format to apply it too. > There is a ton of content out there that could readily be put into a DC microformat. --- then we shouldn't look at DC, we should look at that content and model that, either using existing microformats, or find common attributes across the examples in the wild, then move through the process that way. Jumping straight to making a generic OBJECT DC format is not the best approach. Microformats are designed to address very specific common problems. That is not to say that the resulting format can not reuse DC properties, but to jump straight to a conclusion does not help model commonly published behaviours. > To me, now, it makes a lot of sense to pull DC out as a microformat of its own and then think about building more specific applications based on it. --- this would be backwards to microformats. First we find the specific real-world commonly published content and give structure to them. > ... There are also a large number of! people out there already that understand DC, that know its role and benefits and the correct way to use the elements (well, sort of), and that would not need to be sold it in the way that they may need to be sold other microformats. Seems sensible to me to tap into that. --- it certainly does, but it should be in the context of a problem that needs to be solved, not just picking a format and mapping to it. Properties in other RDF languages map to DC without using the DC namespace. 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 you or others have a specific idea for a format, then the process is the best way to move forward. If there is no specific problem that needs to be solved, then we shouldn't spend the time making a global solution to non-issues. Ultimately, microformats are meant to be a simple solution to common problems. Microformats were not designed to solve every last possible problem and that is OK. Making a generic DC microformat is attempting to do this, instead of addressing specific problems. If the issue can not be solved with existing microformats, then there are a few options. 1) break it into smaller pieces and see if a format exists? 2) gather data for a new microformat 3) mark-up what you can, and use POSH in other places 4) use something else, like RDFa, eRDF, GRDDL or others. -brian -- brian suda http://suda.co.uk From info at weborganics.co.uk Mon Feb 4 03:55:25 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 04:20:17 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <1202125999.3098.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1202125999.3098.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1202126125.3098.5.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Sorry forgive my ignorance "Welcome Ottevanger" On Mon, 2008-02-04 at 11:53 +0000, Martin McEvoy wrote: > On Mon, 2008-02-04 at 10:47 +0000, Ottevanger, Jeremy wrote: > > Hi. > > > > Coming out of lurk mode, I must say that I'm in complete agreement > > with Andy. Thanks to Jim, > > Is GRDDL not a solution to this whole dc question? > > "W3C Completes Bridge Between HTML/Microformats and Semantic Web" > > http://www.w3.org/2007/07/grddl-pressrelease > > Thanks > > Martin McEvoy From andy at pigsonthewing.org.uk Mon Feb 4 04:49:18 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 04:49:23 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <1202121049.4203.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1202121049.4203.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <52162.80.249.57.38.1202129358.squirrel@www.gradwell.com> 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: (aka ) 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 ** From andy at pigsonthewing.org.uk Mon Feb 4 04:58:19 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 04:58:22 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <1202125999.3098.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1202125999.3098.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <5177.80.249.57.38.1202129899.squirrel@www.gradwell.com> On Mon, February 4, 2008 11:53, Martin McEvoy wrote: > On Mon, 2008-02-04 at 10:47 +0000, Ottevanger, Jeremy wrote: > >> Hi. >> >> >> Coming out of lurk mode, I must say that I'm in complete agreement >> with Andy. Thanks to Jim, > > Is GRDDL not a solution to this whole dc question? How do use GRDDL to mark up published content about, say, a play or a sculpture? -- Andy Mabbett ** via webmail ** From andy at pigsonthewing.org.uk Mon Feb 4 04:56:02 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 05:09:54 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <21e770780802040359s2f528ff5paa26831997bf0417@mail.gmail.com> References: <21e770780802040359s2f528ff5paa26831997bf0417@mail.gmail.com> Message-ID: <3665.80.249.57.38.1202129762.squirrel@www.gradwell.com> 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 ** From info at weborganics.co.uk Mon Feb 4 05:52:56 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 05:53:07 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <5177.80.249.57.38.1202129899.squirrel@www.gradwell.com> References: <1202125999.3098.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <5177.80.249.57.38.1202129899.squirrel@www.gradwell.com> Message-ID: <1202133176.3891.13.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Mon, 2008-02-04 at 12:58 +0000, Andy Mabbett wrote: > On Mon, February 4, 2008 11:53, Martin McEvoy wrote: > > On Mon, 2008-02-04 at 10:47 +0000, Ottevanger, Jeremy wrote: > > > >> Hi. > >> > >> > >> Coming out of lurk mode, I must say that I'm in complete agreement > >> with Andy. Thanks to Jim, > > > > Is GRDDL not a solution to this whole dc question? > > How do use GRDDL to mark up published content about, say, a play or a > sculpture? > You would have to build a custom HTML-based Dialect such as ones here: http://esw.w3.org/topic/CustomRdfDialects?highlight=%28CategoryGrddl%29 or try RDFa http://www.w3.org/TR/xhtml-rdfa-primer/ It supports DC metadata and namespaces "out of the box" If its not possible then come back to the table and say "we need" dc to be ported to microformats. How many people have tried the alternatives first? Thanks Martin McEvoy From msporny at digitalbazaar.com Mon Feb 4 07:38:23 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 07:38:27 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: References: Message-ID: <47A7316F.4020500@digitalbazaar.com> Tantek ?elik wrote: > context is not the same as namespaces. namespaces provide one form of > context, but not all contexts are namespaces. in the case of compound > microformats, the context that is used is hierarchical containment. Tantek, The issue is not that cut and dry - and the definition of namespace as it relates to Microformats has been twisted to mean something different than it does in the rest of the world. Just so that we're on the same page, everyone should read the standard definition of a namespace[1] and the computer science definition of a namespace[2]. More specifically, the following line is quite clear about the relationship of a namespace[1] and a context and is in direct conflict with your definition: "A namespace is also called a context, as the valid meaning of a name can change depending on what namespace applies." If you meant, "fully qualified namespaces" instead of "namespace", then I would agree with you. "Context is not the same as a fully qualified namespace" is true - however, this is not what you said and I believe this to be a very long-running issue with Microformats: Oversimplification of the namespace problem. What Microformats have an issue with is "fully qualified namespaces", which is fair - that concept adds unnecessary complexity as far as the community is concerned. However, that is not what is written up on the wiki in the anti-pattern section on namespaces[4]. The anti-pattern makes it sound like Microformats don't use namespaces at all - which is where all the confusion arises. Microformats use "emulated namespaces"[3], for proof, we need only look to hAtom[5]: * entry-title * entry-content * entry-summary In this example, "entry" is an "emulated namespace". This community has been mis-using the word "namespace" for several years now, and it's causing too many problems for those that are attempting to understand why we allow "entry-title", but don't allow "namespaces". The definition that the Microformats community uses for 'namespace' is flawed and thus the logic becomes flawed - this needs to be fixed. > "fn" *does* have meaning - it means "formatted name". No, that is what "FN" expands to, "Formatted Name" - the semantic meaning of that is useless without context... without a namespace. I am asserting that very few of us, if any, mark up all the FNs on a page just because we can - names of buildings, cities, people, animals, countries. "FN" is semantically void without context, without a higher-level Microformat to encapsulate it, without a namespace. > Inside an hCard it means the formatted name of either a person, > organization, or location (depending on the specifics of the hCard). > > Inside an hReview item it means the formatted name of an item. So, it *DOES* have different meaning when used in a different context? The object (what you are naming) of the FN changes based on context. >> So, who is going to make an argument against using TITLE in hAudio? > The problem of such use of the term "title" is twofold. > 1) it's already used to mean "job title" in the context of microformats. Wait, what!? So FN can have two slightly different meanings based on it's context, but TITLE cannot? Why is that? This is exactly the issue: FN's meaning changes slightly based on if it is used in hCard or hReview. TITLE's meaning is locked in to mean "job title" in all Microformats. There is a glaring lack of consistency here, would anybody like to elaborate on why we're OK with that inconsistency? > 2) the concept that it is being proposed to represent is the *name* of an > audio item. "fn" already means the name of an item. we should not > introduce a new term to mean the same thing as an existing term. Incorrect, the concept that it is being proposed to represent is the *title* of an audio recording. TITLE is widely used for that purpose in the english language. We should not restrict that word to mean "job title", when the English language is fairly clear that "TITLE" can mean a variety of things[6] based on the context in which it is used. -- manu PS: This is also the reason that I don't spend more time on Microformats - these discussions are very unsatisfying... I've never had to argue about what the meaning of a word such as "TITLE" actually means at the W3C or any of the other communities that we work with. If we are unsure, we look it up in a dictionary and that is usually the end of the discussion. Microformat's seem to redefine key words like "namespace" and "title" as a means to an end, which is wholly frustrating as you need to re-learn parts of the English language in an attempt to contribute to the community. [1]http://en.wikipedia.org/wiki/Namespace [2]http://en.wikipedia.org/wiki/Namespace_%28computer_science%29 [3]http://en.wikipedia.org/wiki/Namespace_%28computer_science%29#Emulating_namespaces [4]http://microformats.org/wiki/namespaces [5]http://microformats.org/wiki/hatom#Entry_Title [6]http://wordnet.princeton.edu/perl/webwn?s=title From scott at makedatamakesense.com Mon Feb 4 08:25:07 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Feb 4 08:25:17 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A7316F.4020500@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> Message-ID: On Feb 4, 2008, at 8:38 AM, Manu Sporny wrote: >> The problem of such use of the term "title" is twofold. >> 1) it's already used to mean "job title" in the context of >> microformats. > > Wait, what!? So FN can have two slightly different meanings based on > it's context, but TITLE cannot? Why is that? TITLE can have different meanings, but those different meanings can not contradict the meaning within the larger context of microformats, which is currently "job title". If audio segments had job titles, we could use TITLE to indicate those, creating a derived meaning of "audio job title" vs. "person job title" in hCard. This would be analogous to "item formatted name" in hReview vs. "person formatted name" in hCard. The meaning of "formatted name" or "job title" does not change between microformats; it only gains *additional* meaning with additional context. On a more meta-level, if past decisions don't appear to make sense, please ask for explanations of the thought behind them rather than assuming there was no thought. The latter can come off as somewhat insulting to those who made the decisions and create unnecessarily inflammatory discussions. > Incorrect, the concept that it is being proposed to represent is the > *title* of an audio recording. TITLE is widely used for that purpose > in > the english language. We should not restrict that word to mean "job > title" We've *already* done that, out of deference for the semantics of RFC 2426. Regardless of how we feel about that decision in hindsight, the question now is whether or not we should, or even could, change it now. Even if the change makes sense on an abstract level, we now need to ask: what are the practical consequences of redefining TITLE to mean simply "title" instead of the current meaning of "job title"? It's no longer merely an issue of which abstract semantics are more accurate. -- Scott Reynen MakeDataMakeSense.com From JOttevanger at museumoflondon.org.uk Mon Feb 4 08:29:46 2008 From: JOttevanger at museumoflondon.org.uk (Ottevanger, Jeremy) Date: Mon Feb 4 08:30:08 2008 Subject: [no sig]RE: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <21e770780802040359s2f528ff5paa26831997bf0417@mail.gmail.com> Message-ID: Brian, thank you for your response. Martin, too - I'll bundle my reply to you into this, hope that's OK. I appreciate it that people take my confused ramblings seriously enough to take the time to give a considered response! The reason I hopped into this discussion is that I do have a specific purpose in mind, one that I'd spent some time trying to develop but had let stagnate due to (a) lack of time and (b) confusion in the face of the plethora of options other than microformats (which you list below). Ironically it was the specific nature of the problem that I wanted to do tackle that seemed to be the problem when I first talked about it on this list and the discussion list, last May/June (the scenario: identifying objects in museums and galleries on the page, attaching core metadata to them). I now agree - what I wanted to do was too domain-specific. The most useful uFs, it seems to me, are broad in applicability and narrow in scope (e.g. dates, location data). I can undestand that the idea of DC as a microformat trips people up with because it is not narrow in scope (i.e. dates, agents, locations, descriptions around a "thing" are all in there), but it's certainly broad in its applicability. What I wanted to do was pretty narrow in both respects. I did, as you suggest, break it down and use other uFs where possible, but the need for a wrapper for the object as a whole still existed. It strikes me that a DC microformat would be cool because it could offer a broadly useful way to wrap up information about an object. The fact that it would NOT be narrow in its applicability would be a good thing, I think. No current uF, as far as I know, provides a wrapper I can use for a generic object. Why do we want to be so specific that a book, an audio recording etc. all have to have different containers? That's very useful in certain contexts, and clearly the case for microformats for these has been made and won and I wouldn't refute their utility. But if I want to put some other kind of object up there then these wrappers are no use. I just want to be able to identify a thing on a page, and I can't right now - what's out there is TOO specific. That specificity is probably what made it easy to come up with use cases for them, but it's also why they fail to work for loads of stuff. With a "thing" uF, built around DC, you could use the same format to represent a document in an archive, an axe head in a museum, a book in a library, a photo or a video online. And I guess this may be where the problems mainly lie: this means that such a format would tread onto the ground currently covered by other microformats (such cross-over isn't exactly unprecedented but it's not ideal, of course), and I appreciate your point, too, that DC lies behind other uFs (or they can be mapped to it). But for me, in an institution that holds data about a wide variety of objects, I would rather have a single format to output (having done all the semantic mapping internally), whether the object I am describing is an audio recording, a book, an axe head or a digital artwork. A domain-specific (I mean, museum and gallery) GRDDL profile or some extra bit of POSH might also be useful for some of the extra bits of data I'd quite like to enable, but overall I would much rather NOT use my earlier "museum object" microformat to hold this metadata - I'd prefer to use (and possibly extend) a widely applicable DC uF in the knowledge that people outside museums will be using something similar. I understand the need for use cases, so here are some: - a user collects (records of) documents held in The National Archives for her history project. Her user agent gathers titles, source, thumbnails, authors, dates and home URLs for these. She can pool them with other material she's found and feed them into Zotero. - a bronze age specialist searches several museum websites, "collecting" a set of artefacts. The add-in in his browser finds objects from the relevant period and geographic area, of the type "sword". Through the add-in he feeds these objects into his collection, a web-based, taggable "delicious" for museum things. His peers in the "bronze-age weaponry" user group see what he has found and get to annotate it. - a search engine spiders museum, library and archive websites across the UK/Europe/world and gathers data on items in their collections, building a cross-collections search independent that points to each source site Perhaps these aren't good use-cases, I'm an amateur, and these are very museum-focused. I hope they at least show the itch I'm trying to scratch: letting users grab and play with data about our collections. Yes, like any other microformat you could choose to try eRDF, GRDDL etc. to achieve this. But I still wonder, why on earth should there NOT be a generic microformat out there to capture outline information about all sorts of "things" that fall through the cracks left by other, very specific "thing-related" uFs. Frankly without one there's far less in it for me - I have only so much use for events and locations in the abstract, with no way to wrap them up and attach them to things; museums and galleries tend to deal in material culture (as do shops, though I guess they're not too hot on DC) and if I can't use microformats to capture data about this then microformats start to lose their appeal. OK, I know you had more challenges for me, but I know my limits! I really wanted to stick my hand up and vote for the idea that was being batted about re DC, but I'm sticking to the shallow end. And talking about it at excessive length...apologies! All the best, Jeremy -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Brian Suda Sent: 04 February 2008 12:00 To: For discussion of new microformats. Subject: Re: [uf-new] Dublin Core (was: hAudio FN or Title) 2008/2/4, Ottevanger, Jeremy : > Hi. > > Coming out of lurk mode, --- welcome to the list, and thanks for your thoughts. > I recognise that The Process wisely advocates that formats should where possible build upon those that exist already, and that a DC microformat might tread on some toes in this respect by creating classes that overlap with existing classes in hCalendar, hCard and so on. I hope this needn't interfere unnecessarily, there's simply too much to be gained from making this suggestion happen. --- the process also states: "There must be a problem to be solved (i.e. a real world use case). No problem, no microformat." The idea is NOT to make a generic Dublin Core microformats, but to address a specific problem. People, Places, Events, Music, Books, etc. If there is something specific, then we can get a use-case and develop a format from that. Just making mapping the DC Ontology to class names, doesn?t get us much. We still need a data format to apply it too. > There is a ton of content out there that could readily be put into a DC microformat. --- then we shouldn't look at DC, we should look at that content and model that, either using existing microformats, or find common attributes across the examples in the wild, then move through the process that way. Jumping straight to making a generic OBJECT DC format is not the best approach. Microformats are designed to address very specific common problems. That is not to say that the resulting format can not reuse DC properties, but to jump straight to a conclusion does not help model commonly published behaviours. > To me, now, it makes a lot of sense to pull DC out as a microformat of its own and then think about building more specific applications based on it. --- this would be backwards to microformats. First we find the specific real-world commonly published content and give structure to them. > ... There are also a large number of! people out there already that understand DC, that know its role and benefits and the correct way to use the elements (well, sort of), and that would not need to be sold it in the way that they may need to be sold other microformats. Seems sensible to me to tap into that. --- it certainly does, but it should be in the context of a problem that needs to be solved, not just picking a format and mapping to it. Properties in other RDF languages map to DC without using the DC namespace. 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 you or others have a specific idea for a format, then the process is the best way to move forward. If there is no specific problem that needs to be solved, then we shouldn't spend the time making a global solution to non-issues. Ultimately, microformats are meant to be a simple solution to common problems. Microformats were not designed to solve every last possible problem and that is OK. Making a generic DC microformat is attempting to do this, instead of addressing specific problems. If the issue can not be solved with existing microformats, then there are a few options. 1) break it into smaller pieces and see if a format exists? 2) gather data for a new microformat 3) mark-up what you can, and use POSH in other places 4) use something else, like RDFa, eRDF, GRDDL or others. -brian -- brian suda http://suda.co.uk _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From info at weborganics.co.uk Mon Feb 4 08:54:57 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 08:55:14 2008 Subject: [no sig]RE: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: References: Message-ID: <1202144097.6318.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Mon, 2008-02-04 at 16:29 +0000, Ottevanger, Jeremy wrote: > why on earth should there NOT be a generic microformat out there to > capture outline information about all sorts of "things" that fall > through the cracks left by other I think there is a thing microformat "item" http://microformats.org/wiki/item It may be an idea to try and expand this? see if it fits? Thanks Martin McEvoy From davidjanes at blogmatrix.com Mon Feb 4 09:29:39 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Feb 4 09:29:41 2008 Subject: [no sig]RE: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <1202144097.6318.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1202144097.6318.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <21e523c20802040929q78e20066o2b7cc8b48462709c@mail.gmail.com> There's been information collected about how an "item" microformat would work, though by no means consider this official, blessed, voted upon, or even official proposed. If anyone is really serious about going down this road, I suggest going back though the mailing list archives, especially around the time hAudio was getting to 0.1. For the record, my idea (now) of hItem would work is: - as the _intersection_ of item attributes, roughly ;-) - as a building block for use in other uFs, following the process I'm still lurking at hAudio discussions to see how this is all working out. Regards, etc... On Feb 4, 2008 11:54 AM, Martin McEvoy wrote: > > On Mon, 2008-02-04 at 16:29 +0000, Ottevanger, Jeremy wrote: > > why on earth should there NOT be a generic microformat out there to > > capture outline information about all sorts of "things" that fall > > through the cracks left by other > > I think there is a thing microformat "item" > > http://microformats.org/wiki/item > > It may be an idea to try and expand this? see if it fits? > > Thanks > > Martin McEvoy > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From msporny at digitalbazaar.com Mon Feb 4 09:34:48 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 09:34:52 2008 Subject: [uf-new] hAudio TITLE vs. hAudio FN (was: Namespace anti-pattern and hAudio TITLE) In-Reply-To: References: <47A7316F.4020500@digitalbazaar.com> Message-ID: <47A74CB8.8090703@digitalbazaar.com> Scott Reynen wrote: >>> The problem of such use of the term "title" is twofold. >>> 1) it's already used to mean "job title" in the context of microformats. >> >> Wait, what!? So FN can have two slightly different meanings based on >> it's context, but TITLE cannot? Why is that? > > TITLE can have different meanings, but those different meanings can not > contradict the meaning within the larger context of microformats, which > is currently "job title". What I'm challenging is the idea that TITLE should mean "job title". I'm asserting that it should be the definition of TITLE as used in the English language. TITLE means "job title" because it was defined in Microformats by re-using the meaning in RFC 2426, which is a narrow definition of TITLE. I realize that circumstances change and I wasn't implying that there was "no thought" behind those decisions. However, those decisions happened in a Microformats community that was far smaller than it is now. It happened in one that was attempting to solve problems without the constraint of the vocabularies that we have now. > If audio segments had job titles, we could > use TITLE to indicate those, creating a derived meaning of "audio job > title" vs. "person job title" in hCard. This would be analogous to > "item formatted name" in hReview vs. "person formatted name" in hCard. > The meaning of "formatted name" or "job title" does not change between > microformats; it only gains *additional* meaning with additional context. Yes, and if we were to change TITLE to mean "title" as defined by the English language, then it would gain additional context in hCard to mean "job title", and additional context in hAudio to mean "audio recording title". I don't think that concept is that revolutionary, even though it has been treated as that in the past. > On a more meta-level, if past decisions don't appear to make sense, > please ask for explanations of the thought behind them rather than > assuming there was no thought. The latter can come off as somewhat > insulting to those who made the decisions and create unnecessarily > inflammatory discussions. I wholeheartedly did not mean to imply that there was no thought put into the decision. I have always attempted to use a very respectful tone in e-mails to the list. I assert that you would find it difficult to find any one of my e-mails that attack anybody on this list personally. I will always attempt to keep a respectful tone and feel that I have done that in the majority of my communication to the list. I did ask for explanations for the TITLE decision[1], I started asking back in June of 2007[2], and have not been satisfied with the arguments for keeping TITLE the same. Since it seems as if my intentions were misunderstood - I am criticizing an idea here, not the people that made the decision. As a general rule, I never criticize people. Ideas, however, are fair game. I am challenging the idea that TITLE should mean "job title". Apologies if it seemed if I was doing anything other than that. >> Incorrect, the concept that it is being proposed to represent is the >> *title* of an audio recording. TITLE is widely used for that purpose in >> the english language. We should not restrict that word to mean "job >> title" > > We've *already* done that, out of deference for the semantics of RFC > 2426. Regardless of how we feel about that decision in hindsight, the > question now is whether or not we should, or even could, change it now. I would love to have that conversation, so let's begin... > Even if the change makes sense on an abstract level, we now need to ask: > what are the practical consequences of redefining TITLE to mean simply > "title" instead of the current meaning of "job title"? It's no longer > merely an issue of which abstract semantics are more accurate. Then let's talk about the ramifications of changing TITLE to mean "title" instead of "job title". After putting a significant amount of thought into this, I am asserting that it will not affect any legacy Microformats page for the following reasons: * TITLE is not used outside of hCard. Additionally, it will greatly reduce context collisions between hAudio and hCard: * There can be an FN conflict between hAudio and hCard already. Since TITLE would be used far less than FN when combining hCards and hAudios, the chances of a hAudio.TITLE confliciting with an hCard.TITLE in hAudio are far lower than an hAudio.FN conflicting with an hCard.FN. TITLE is rarely used in hCards that are included in hAudios. Are there any other ramifications of changing the definition of TITLE from "job title" to "title" that I am not seeing? -- manu [1]http://microformats.org/discuss/mail/microformats-new/2008-February/001414.html [2]http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html From davidjanes at blogmatrix.com Mon Feb 4 09:43:49 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Mon Feb 4 09:43:51 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A7316F.4020500@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> Message-ID: <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> On Feb 4, 2008 10:38 AM, Manu Sporny wrote: > Microformats use "emulated namespaces"[3], for proof, we need only look > to hAtom[5]: > > * entry-title > * entry-content > * entry-summary > > In this example, "entry" is an "emulated namespace". This community has > been mis-using the word "namespace" for several years now, and it's > causing too many problems for those that are attempting to understand > why we allow "entry-title", but don't allow "namespaces". > No, it just looks like it uses an "emulates namespace" - please see the hAtom discussions from two years ago if you're interested in the gory details. Essentially, the definition of those three items _is so specific to the problem domain_ that we invented names specifically for that. e.g. "entry-title" isn't any old title, it's specifically the Atom concept of a title. You could imagine a blog post semantically marked up where a "fn" is around the entry-title with some more information ("David Janes says...") Regards, etc... -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From guillaume at lebleu.org Mon Feb 4 10:14:07 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Mon Feb 4 10:14:10 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: References: <47A7316F.4020500@digitalbazaar.com> Message-ID: <47A755EF.7050700@lebleu.org> Scott Reynen wrote: > if past decisions don't appear to make sense, please ask for > explanations of the thought behind them rather than assuming there was > no thought. Good point. So, I have a question: what is the explanation for generalizing the use of "formatted name" outside of the context of the name of a person? my understanding is that "formatted name" is useful when there are names that also exist "unformatted", i.e. structured format, such as first name, last name, etc. I don't see the use of "formatted name" as relevant for a track name or an item name, etc. since these typically aren't stored in tokenized form. More on this: http://lebleu.org/blog/2008/02/02/the-meaning-of-vcards-fn/ Even vcard does not reuse "fn" for the name of an organization. Calling something that most English speaking people I know call "track name" or "song title" something else that noone else I know uses outside of microformats ("formatted name") is confusing to me and other people on this list. Thanks in advance for the explanation. Guillaume From msporny at digitalbazaar.com Mon Feb 4 10:48:58 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 10:49:03 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> Message-ID: <47A75E1A.4000604@digitalbazaar.com> David Janes wrote: > On Feb 4, 2008 10:38 AM, Manu Sporny wrote: >> Microformats use "emulated namespaces"[3], for proof, we need only look >> to hAtom[5]: >> >> * entry-title >> * entry-content >> * entry-summary >> >> In this example, "entry" is an "emulated namespace". This community has >> been mis-using the word "namespace" for several years now, and it's >> causing too many problems for those that are attempting to understand >> why we allow "entry-title", but don't allow "namespaces". > > No, it just looks like it uses an "emulates namespace" There's no such thing as "looking like you use an emulated namespace"... just like there is no such thing as "looking like you use a context". You either do or you don't. :) If you can find an example of "looking like you're using an emulated namespace" in any published linguistics, computer science, or programming/language theory literature then please post that as I am unaware of the concept. Here are more examples of Microformats using "emulated namespace"s: country-name (hCard) organization-name (hCard) organization-unit (hCard) > please see > the hAtom discussions from two years ago if you're interested in the > gory details. Got a link? I'd like to know how the thought process went. > Essentially, the definition of those three items _is so > specific to the problem domain_ that we invented names specifically > for that. Names were invented that have a common base stem, in the case of hAtom, you used 'entry-'. That's my point. When you use a common base stem, it is an indicator that you are using a form of namespacing - you are creating context for what comes after the base stem. I'm not stating that I think it was a bad decision. I'm stating that we do stuff like that in Microformats while touting this "no namespaces!" rhetoric, which is confusing to on-lookers. We should be saying: 1. "No fully qualified namespaces!" 2. "Emulated namespaces are strongly discouraged!" > e.g. "entry-title" isn't any old title, it's specifically the Atom > concept of a title. You could imagine a blog post semantically marked > up where a "fn" is around the entry-title with some more information > ("David Janes says...") I'm not asking that you rip it out - I'm asking that we be more consistent in how we discuss namespaces. Here's what I think the community is for: 1. No "fully qualified namespaces" in Microformats. 2. "Emulated namespaces" in very specific cases, such as hCard and hAtom. 3. Context is used to determine more specific semantic meaning for class names such as FN and TITLE. #3 is what we're specifically talking about right now, but knowing #1 and #2 exist is also important to the discussion. -- manu From ehs at pobox.com Mon Feb 4 10:50:14 2008 From: ehs at pobox.com (Ed Summers) Date: Mon Feb 4 10:50:20 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <3665.80.249.57.38.1202129762.squirrel@www.gradwell.com> References: <21e770780802040359s2f528ff5paa26831997bf0417@mail.gmail.com> <3665.80.249.57.38.1202129762.squirrel@www.gradwell.com> Message-ID: On Feb 4, 2008 7:56 AM, Andy Mabbett wrote: > Given the negative, almost hostile, response to the idea here, I wonder if > it might be better discussed in a DC forum? The DC folks actually have regular and open online meetings [1] and discussion lists where you can ask questions about accepted ways of expressing DC in HTML, XML, RDF, etc. If I'm remembering right the DC Architecture Forum is currently finalizing recommendations on expressing DC in HTML...and they are actively looking for participation and input. I've definitely seen lots of RDFa and DC examples in the latest RDFa Primer [2]. //Ed [1] http://dublincore.org/architecturewiki/ [2] http://www.w3.org/TR/xhtml-rdfa-primer/ From brian.suda at gmail.com Mon Feb 4 11:13:45 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 4 11:13:50 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A75E1A.4000604@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> Message-ID: <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> 2008/2/4, Manu Sporny : > Here are more examples of Microformats using "emulated namespace"s: > > 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. -brian -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Mon Feb 4 12:12:54 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 12:14:17 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> Message-ID: In message <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com>, Brian Suda writes >008/2/4, Manu Sporny : >> Here are more examples of Microformats using "emulated namespace"s: >> >> 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 From msporny at digitalbazaar.com Mon Feb 4 12:17:56 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 12:18:01 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> Message-ID: <47A772F4.4090005@digitalbazaar.com> Brian Suda wrote: > 2008/2/4, Manu Sporny : >> Here are more examples of Microformats using "emulated namespace"s: >> >> country-name (hCard) >> organization-name (hCard) >> organization-unit (hCard) > > --- i do not consider these namespaces. Then, I assert that your definition of what is and isn't a namespace is out of step with the common definition of a namespace[1] and it is causing confusion to those that are familiar with the common definition of a namespace[2][3][4][5]. > 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. Even if there was no attempt to do any sort of "emulated namespace", and even if you were attempting to just concatenate space-separated-terms so they could be used in the class attribute, the end result is an "emulated namespace". Let me try and put it another way. If we have this (EX1): organization-name organization-unit We have a root, a separator, and a suffix. The root is 'organization', the separator is '-' and the suffixes are 'name' and 'unit'. If we have this (EX2): organization/name organization/unit We have a root, a separator and a suffix. The root is 'organization', the separator is '/' and the suffixes are 'name' and unit'. If we have this (EX3): http://organization.org/name http://organization.org/unit We have a root, a separator and a suffix. The root is "http://organization.org", the separator is '/', and the suffixes are 'name' and 'unit'. So why are we saying that EX1 doesn't have a namespace and EX3 definitely has a namespace (for those that are new to RDF - EX3 is how RDFa declares namespaces)[6]. Regardless of what those that put hCard together meant to do, a side effect of choosing to use '-' to separate elements and using the same root creates an "emulated namespace". This same argument applies to hAtom. To create an "emulated namespace" and then to claim that it isn't one creates an inconsistency in the Microformat community's stance against namespaces. -- manu [1]http://en.wikipedia.org/wiki/Namespace [2]Programming and Problem Solving with C++, By Nell B. Dale, Chip Weems, p.369 [3]History of Programming Languages II, By Thomas J. Bergin , Richard G. Gibson, p.265 [4]Computer-Aided Verification '90: Proceedings of a DIMACS Workshop, June 18-21, 1990. p.571 [5]Handbook of Object Technology By Saba Zamir, p.15 [6]http://www.youtube.com/watch?v=ldl0m-5zLz4 From andy at pigsonthewing.org.uk Mon Feb 4 12:25:55 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 12:27:04 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A616A6.6090903@digitalbazaar.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> <1201984681.15377.39.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A616A6.6090903@digitalbazaar.com> Message-ID: <5fjPTZ2TT3pHFw5S@pigsonthewing.org.uk> In message <47A616A6.6090903@digitalbazaar.com>, Manu Sporny 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: Meddle One of These Days 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 From brian.suda at gmail.com Mon Feb 4 13:05:52 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 4 13:05:56 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A772F4.4090005@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> Message-ID: <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> 2008/2/4, Manu Sporny : > Even if there was no attempt to do any sort of "emulated namespace", and > even if you were attempting to just concatenate space-separated-terms so > they could be used in the class attribute, the end result is an > "emulated namespace". > > We have a root, a separator, and a suffix. The root is 'organization', > the separator is '-' and the suffixes are 'name' and 'unit'. > > If we have this (EX2): > > organization/name > organization/unit > > We have a root, a separator and a suffix. The root is 'organization', > the separator is '/' and the suffixes are 'name' and unit'. --- but your argument falls down with your other citation of country-name. This is NOT: country/name This is part of the ADR microformat and is not: adr-country-name adr-locality adr-region I still do not consider this any sort of namespacing each term stands on it's own by itself. > Regardless of what those that put hCard together meant to do, a side > effect of choosing to use '-' to separate elements and using the same > root creates an "emulated namespace". --- this was never the intent of hCard, and i still no do not believe having a hyphen denotes namespaces of any kind. People who hypenate their surnames, jones-smith is NOT a namespace of jones/smith. > To create an "emulated namespace" and then to claim that it isn't one > creates an inconsistency in the Microformat community's stance against > namespaces. Agreed, and this is why i do not consider this any sort of "emulated namespace" had it his been CamelCase would you still argue Namespace? getUser() is not namespaced, nor is smith-jones or country-name or e-mail. We must be talking past one another with our definitions, it is probably best to start a wiki page and the discussion will not get lose between posts and threads. It will also make it easier for anyone to reference later. Continuing this thread will not be productive for very long. -brian -- brian suda http://suda.co.uk From ckstjohn at gmail.com Mon Feb 4 13:20:15 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Mon Feb 4 13:20:20 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> Message-ID: <8ba906450802041320g6d31d0b7i6e248ef4deee9713@mail.gmail.com> On Feb 4, 2008 4:05 PM, Brian Suda wrote: > > We must be talking past one another with our definitions, it is > probably best to start a wiki page and the discussion will not get > lose between posts and threads. It will also make it easier for anyone > to reference later. Continuing this thread will not be productive for > very long. > Actually, I've found it quite useful. Manu has brought up several points that I've been concerned about. I've almost chimed in a couple of times but Manu has beaten me to it and I've been reluctant to just post "me too" :-) Just because one person doesn't find a long and interesting thread productive doesn't mean it isn't productive for others. And, for the record, for most of Manu's comments: "Me too." -cks -- Christopher St. John http://artofsystems.blogspot.com From andy at pigsonthewing.org.uk Mon Feb 4 13:22:39 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 13:24:15 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <47A61862.80802@digitalbazaar.com> References: <478CDCDC.2070407@digitalbazaar.com> <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> <478CED6B.1010503@digitalbazaar.com> <47A61862.80802@digitalbazaar.com> Message-ID: In message <47A61862.80802@digitalbazaar.com>, Manu Sporny writes >Andy Mabbett wrote: >> Items 1-5 have different meanings; that's why you were able to list fire "five" >> 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? You seem to have overlooked the above. >Andy - could you please list the issues that you have with hAudio on the >audio-info-issues page so that we can track them. I remember seeing 3 >distinct issues that you raised in the past month (although, there may >be more). > >I've been meaning to document them for several weeks, but haven't gotten >around to doing so. You'd be the best person to word it in a way that >you agree with I agree it would be useful, and will do so if and when I have time; don't let that stop you if you have free time first! That said, I have previously found the placing of issues on with wiki to be pointless exercise, as they are often ignored, or rejected out-of-hand, with no adequate discussion. -- Andy Mabbett From info at weborganics.co.uk Mon Feb 4 13:25:00 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 13:25:12 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A772F4.4090005@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> Message-ID: <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Hello Manu On Mon, 2008-02-04 at 15:17 -0500, Manu Sporny wrote: > Then, I assert that your definition of what is and isn't a namespace > is > out of step with the common definition of a namespace If "namespaces" did exist in microformats? it would make it impossible to re-use other objects such as "title" in other microformats because names in namespaces can only be declared once and only have one contextual meaning? No one actually will admit to the existence of a namespace in microformats but there is lots of evidence suggesting otherwise. either intentional or not, Microformats MAY have created their own "namespace" of a kind I think? Microformats declare a formal profile[1] in their proposals[2] [1] http://gmpg.org/xmdp/ [2] http://microformats.org/wiki/haudio#XMDP_Profile and then do this... very GRDDL Like Maybe someone can explain to me why declare a profile if their isn't some kind of metadata description at the end? http://gmpg.org/xfn/11 Thanks Martin McEvoy From info at weborganics.co.uk Mon Feb 4 13:34:25 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 13:34:40 2008 Subject: [uf-new] hAudio vS hTrack? Message-ID: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> 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... Thanks Martin McEvoy From andy at pigsonthewing.org.uk Mon Feb 4 14:01:28 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 14:02:32 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: References: <478CDCDC.2070407@digitalbazaar.com> <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> <478CED6B.1010503@digitalbazaar.com> <47A61862.80802@digitalbazaar.com> Message-ID: In message , Andy Mabbett writes >>Andy - could you please list the issues that you have with hAudio on the >>audio-info-issues page so that we can track them. I remember seeing 3 >>distinct issues that you raised in the past month (although, there may >>be more). >I agree it would be useful, and will do so if and when I have time; >don't let that stop you if you have free time first! What the hell; done. there are six at: Don't say I'm not good to you ;-) -- Andy Mabbett From scott at makedatamakesense.com Mon Feb 4 14:06:26 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Feb 4 14:06:34 2008 Subject: [uf-new] hAudio vS hTrack? In-Reply-To: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: On Feb 4, 2008, at 2:34 PM, Martin McEvoy wrote: > 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... It looks like most of that was done by Lucas Gonze, who back on 2006 wrote: > I don't personally do my microformat-related work on the wiki, and I > don't plan to start. As I understand it, Lucas would prefer microformats.org mostly aggregate work on microformats done elsewhere rather than keeping that work in a central location. So I don't think Lucas was ever waiting on hAudio in the first place, as he sees fundamental problems with the way it was developed. Also, there's no technical reason for a "vs." relationship between microformats and anything else and we should avoid creating political reasons; class="htrack haudio" will work just fine. -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Mon Feb 4 14:14:17 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 14:16:01 2008 Subject: [uf-new] hAudio vS hTrack? In-Reply-To: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: In message <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com>, Martin McEvoy 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 From info at weborganics.co.uk Mon Feb 4 14:20:22 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 14:20:33 2008 Subject: [uf-new] hAudio vS hTrack? In-Reply-To: References: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1202163622.8705.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Mon, 2008-02-04 at 15:06 -0700, Scott Reynen wrote: > As I understand it, Lucas would prefer microformats.org mostly > aggregate work on microformats done elsewhere rather than keeping > that > work in a central location. So I don't think Lucas was ever waiting > on hAudio in the first place, as he sees fundamental problems with > the > way it was developed. ... That sounds bad! What are the problems?, or can you not divulge? > Also, there's no technical reason for a "vs." > relationship between microformats and anything else and we should > avoid creating political reasons; class="htrack haudio" will work > just > fine. My thoughts entirely Thanks Martin McEvoy From msporny at digitalbazaar.com Mon Feb 4 14:38:54 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 14:38:58 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: References: <478CDCDC.2070407@digitalbazaar.com> <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> <478CED6B.1010503@digitalbazaar.com> <47A61862.80802@digitalbazaar.com> Message-ID: <47A793FE.8060907@digitalbazaar.com> Andy Mabbett wrote: >> I've been meaning to document them for several weeks, but haven't gotten >> around to doing so. You'd be the best person to word it in a way that >> you agree with > > I agree it would be useful, and will do so if and when I have time; > don't let that stop you if you have free time first! > > That said, I have previously found the placing of issues on with wiki to > be pointless exercise, as they are often ignored, or rejected > out-of-hand, with no adequate discussion. Can't speak for other initiatives, but it would be a shame to ignore any constructive criticism on issues surrounding hAudio. We didn't ignore input for the pre-draft hAudio, and we shouldn't start ignoring input now, either. > What the hell; done. there are six at: > > Don't say I'm not good to you ;-) Awww... thanks Andy, you shouldn't have =P Looks like we're currently dealing with hAudio Issue #D2[1] -- manu [1]http://microformats.org/wiki/haudio-issues#2008 From danny.ayers at gmail.com Mon Feb 4 14:56:53 2008 From: danny.ayers at gmail.com (Danny Ayers) Date: Mon Feb 4 14:57:04 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> No, you're all wrong! :-) Ok, you're all right too. The way the uF antipattern looks to me is the intention of "ugly URI-based XML namespaces and prefixes simply aren't necessary". Which, in a lot of senses, is probably on the nail. Manu's point seems reasonable, to the extent that parts of the markup hierarchy (vcard etc) do in effect delimit a namespace, though I'm not sure this applies to the hyphenated terms mentioned - I'd read those as names which happen to have hyphens in them. 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. 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. Forget namespaces. Think of a follow-your-nose chain of information to the information the publisher or consumer might need to communicate. After all, the string "title" only has a well-known meaning to a minority of the global population. Why isn't it "titel" or "titulo"? Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/ From tantek at cs.stanford.edu Mon Feb 4 15:05:30 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Feb 4 15:03:54 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: On 2/4/08 1:25 PM, "Martin McEvoy" wrote: > Hello Manu > > On Mon, 2008-02-04 at 15:17 -0500, Manu Sporny wrote: >> Then, I assert that your definition of what is and isn't a namespace >> is out of step with the common definition of a namespace > > If "namespaces" did exist in microformats? it would make it impossible > to re-use other objects such as "title" in other microformats because > names in namespaces can only be declared once and only have one > contextual meaning? > > No one actually will admit to the existence of a namespace in > microformats but there is lots of evidence suggesting otherwise. > > either intentional or not, Microformats MAY have created their own > "namespace" of a kind I think? The problem is with this loose use of term "namespace" or "namespace of a kind", not with microformats usage thereof which will result in endless semantic arguments which are not useful. Frankly, this entire thread is one of the reasons we have this mailing list guideline: http://microformats.org/wiki/mailing-lists#Bad_topics_for_discussion > Microformats declare a formal profile[1] in their proposals[2] > > [1] http://gmpg.org/xmdp/ > [2] http://microformats.org/wiki/haudio#XMDP_Profile > > and then do this... > > > > very GRDDL Like > > The uses are quite different actually. XMDP uses the profile attribute for defining terms, and GRDDL uses the profile attribute for defining how to transform. > Maybe someone can explain to me why declare a profile if there isn't > some kind of metadata description at the end? > > http://gmpg.org/xfn/11 XMDP provides a simple description mostly just to define the terms. So far we've resisted additional metadata similar to DTDs or XML Schema docs. Another big difference is the way XMDP overrides work, linked from [1] cited previously above: http://gmpg.org/xmdp/description Note that if two different profiles define the same term, only the first definition is used. Thus they are not "namespaces" in any data/programming functional way (like XML namespaces), as such namespaces make such multiple references exist simultaneously and distinctly by keeping them in their own silos. I have added both of these to the XMDP FAQ: http://microformats.org/wiki/xmdp-faq Tantek From tantek at cs.stanford.edu Mon Feb 4 15:08:28 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Feb 4 15:06:50 2008 Subject: namespaces bad topic for uf mailing lists reminder (was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)) In-Reply-To: <8ba906450802041320g6d31d0b7i6e248ef4deee9713@mail.gmail.com> Message-ID: On 2/4/08 1:25 PM, "Martin McEvoy" wrote: > Hello Manu > > On Mon, 2008-02-04 at 15:17 -0500, Manu Sporny wrote: >> Then, I assert that your definition of what is and isn't a namespace >> is out of step with the common definition of a namespace > > If "namespaces" did exist in microformats? it would make it impossible > to re-use other objects such as "title" in other microformats because > names in namespaces can only be declared once and only have one > contextual meaning? > > No one actually will admit to the existence of a namespace in > microformats but there is lots of evidence suggesting otherwise. > > either intentional or not, Microformats MAY have created their own > "namespace" of a kind I think? The problem is with this loose use of term "namespace" or "namespace of a kind", not with microformats usage thereof which will result in endless semantic arguments which are not useful. and On 2/4/08 1:20 PM, "Christopher St John" wrote: > On Feb 4, 2008 4:05 PM, Brian Suda wrote: >> >> We must be talking past one another with our definitions, it is >> probably best to start a wiki page and the discussion will not get >> lose between posts and threads. It will also make it easier for anyone >> to reference later. Continuing this thread will not be productive for >> very long. >> > > Actually, I've found it quite useful. Manu has brought up several points > that I've been concerned about. I've almost chimed in a couple of times > but Manu has beaten me to it and I've been reluctant to just post "me > too" :-) > > Just because one person doesn't find a long and interesting thread > productive doesn't mean it isn't productive for others. That may be true, however, we decided long ago, that this wasn't a good forum for having such discussions about namespaces - there are other forums where you may find more others that find long discussions about namespaces interesting. http://microformats.org/wiki/mailing-lists#bad-topic-namespaces Thanks, Tantek From andy at pigsonthewing.org.uk Mon Feb 4 15:26:02 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Feb 4 15:27:23 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> Message-ID: In message <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com>, Danny Ayers 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 From scott at makedatamakesense.com Mon Feb 4 15:35:21 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Feb 4 15:52:51 2008 Subject: [uf-new] hAudio vS hTrack? In-Reply-To: <1202163622.8705.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> References: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1202163622.8705.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <866CFD96-DE1A-4F6D-BEA5-969D7024453D@makedatamakesense.com> On Feb 4, 2008, at 3:20 PM, Martin McEvoy wrote: > On Mon, 2008-02-04 at 15:06 -0700, Scott Reynen wrote: >> As I understand it, Lucas would prefer microformats.org mostly >> aggregate work on microformats done elsewhere rather than keeping >> that >> work in a central location. So I don't think Lucas was ever waiting >> on hAudio in the first place, as he sees fundamental problems with >> the >> way it was developed. > ... > That sounds bad! What are the problems?, or can you not divulge? I don't know anything about Lucas' views beyond what you can find in the email archives: http://search.gmane.org/?author=lucas+gonze&group=gmane.comp.web.microformats.general -- Scott Reynen MakeDataMakeSense.com From info at weborganics.co.uk Mon Feb 4 16:02:50 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon Feb 4 16:03:04 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: References: Message-ID: <1202169770.3190.18.camel@weborganicscouk> On Mon, 2008-02-04 at 15:05 -0800, Tantek =?ISO-8859-1?B?xw==?=elik wrote: > Note that if two different profiles define the same term, only the > first > definition is used. Thus they are not "namespaces" in any > data/programming > functional way (like XML namespaces), as such namespaces make such > multiple > references exist simultaneously and distinctly by keeping them in > their own > silos. Really! that seems bad is it?, it makes little sense to re-use other parts like "fn" eg: unless their context is exact "fn" in the above case would be bound to a hcard definition not an audio definition which when you think about it means something else...? Thanks Martin McEvoy From ckstjohn at gmail.com Mon Feb 4 16:27:54 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Mon Feb 4 16:27:58 2008 Subject: namespaces bad topic for uf mailing lists reminder (was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)) In-Reply-To: References: <8ba906450802041320g6d31d0b7i6e248ef4deee9713@mail.gmail.com> Message-ID: <8ba906450802041627v54c13ffay1968aaa766b1a15f@mail.gmail.com> On Feb 4, 2008 5:08 PM, Tantek ?elik wrote: > On 2/4/08 1:25 PM, "Martin McEvoy" wrote: > > > Actually, I've found it quite useful. Manu has brought up several points > > that I've been concerned about. I've almost chimed in a couple of times > > but Manu has beaten me to it and I've been reluctant to just post "me > > too" :-) > > > > Just because one person doesn't find a long and interesting thread > > productive doesn't mean it isn't productive for others. > > That may be true, however, we decided long ago, that this wasn't a good > forum for having such discussions about namespaces - there are other forums > where you may find more others that find long discussions about namespaces > interesting. > > http://microformats.org/wiki/mailing-lists#bad-topic-namespaces > (Much of) the discussion isn't about that kind of namespaces. It's about trying to clarify how the word used on the Wiki (in a very specific sense) has a more broadly accepted meaning that differs in important ways. The fact that "no namespaces" dogma makes little sense to people familiar with the general meaning suggests that clarification is important. Manu's post with references to the various meanings is probably something that should go up on the wiki. It's a productive contribution to the issue and a demonstration that dogmas should occasionally be pulled out from their glass case and given a good shaking. -cks -- Christopher St. John http://artofsystems.blogspot.com From walter at psybernet.co.nz Mon Feb 4 19:13:40 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Mon Feb 4 19:23:53 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE In-Reply-To: References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> Message-ID: <47A7D464.805@psybernet.co.nz> Hi all, I am jumping in, new here, new to microformats, looking for a solution to a problem, but more on that later. This thread has helped me understand a few things, though I would not want to have endless debates about the meta-language used. People mean different things by "namespace", as they do with God. Just because someone has defined it formally that does not mean there is no debate, but I think I know more about the varieties of use here. ~ Do I have this right then, within hAudio it would be possible to have "title" or "fn"? I'd prefer "title", it makes more intuitive sense to me. Would there also be tag name for "file name"? fn could get confusing ... > What if the page includes profiles for hAudio *and* hCard? Hmmm I am a total newby, I just looked at my hCard thinking there would be a
, but no it is
??? So does every microformat, regardless of the "context" need to be unique? I am hoping to mix hCard, xfn and "hArt" if it were there, I saw a start on it? I will start some new threads. Walter http://psyberspace.wordpress.com PS I have a question in the last post on my blog re xfn, would love some comment. From msporny at digitalbazaar.com Mon Feb 4 19:46:28 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 19:46:32 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> Message-ID: <47A7DC14.30001@digitalbazaar.com> Brian Suda wrote: >> If we have this (EX2): >> >> organization/name >> organization/unit >> >> We have a root, a separator and a suffix. The root is 'organization', >> the separator is '/' and the suffixes are 'name' and unit'. > > --- but your argument falls down with your other citation of > country-name. This is NOT: > > country/name Does it? If 'country-name' isn't namespaced, then we could get rid of country and 'name' by itself would have an unambiguous meaning. However, if we were to do that in practice, 'name' wouldn't mean 'country name' anymore... it would be more ambiguous. By being more ambiguous, we're stating that the prefix that we removed, 'country', actually does have semantic meaning. 'country' is a namespace that gives scope to the following 'name' by specifying that we are talking about a 'country name' and not a 'person name'. But even with that argument, let's get rid of country-name - we're still left with: entry-title entry-summary entry-description organization-name organization-unit My argument still stands - we're providing a specific scope to 'title', 'summary' and 'description' - that scope is 'entry'. We are also providing a specific scope to 'name', and 'unit' - that scope is 'organization'. >> Regardless of what those that put hCard together meant to do, a side >> effect of choosing to use '-' to separate elements and using the same >> root creates an "emulated namespace". > > --- this was never the intent of hCard, and i still no do not believe > having a hyphen denotes namespaces of any kind. People who hypenate > their surnames, jones-smith is NOT a namespace of jones/smith. We're not talking about people who hyphenate their surnames - we are talking about the use of TITLE in hAudio and the inconsistency in the Microformat community's definition of 'namespace'. >> To create an "emulated namespace" and then to claim that it isn't one >> creates an inconsistency in the Microformat community's stance against >> namespaces. > > Agreed, and this is why i do not consider this any sort of "emulated > namespace" had it his been CamelCase would you still argue Namespace? Yes! You don't need a separator for namespaces to occur, you just need the root to be the same. > getUser() is not namespaced, nor is smith-jones or country-name or > e-mail. I agree that smith-jones is not namespaced, it is hyphenated. However, every other one of your examples is a form of scoping/namespacing: getUser() implies that there are other getters on the object - the implied namespace/scope is "the set of getter methods for the object/module". country-name is namespaced/scoped - the named scope is 'country'. This differentiates it from 'audio-name', which implies a named scope of 'audio'. If we were to remove 'country' and 'audio' from these two examples, we would be left with 'name' and 'name' - which are indistinguishable from each other. The prefixes define a scope - a scope that is named is called a "namespace". > We must be talking past one another with our definitions Just to be clear - this isn't /my/ definition - it is the definition that is widely accepted in Computer Science. The definition on the Microformats page is, at best, vague, at worst, inconsistent with the definition that is widely accepted in Computer Science. > it is > probably best to start a wiki page and the discussion will not get > lose between posts and threads. It will also make it easier for anyone > to reference later. Sure thing - the page is up: http://microformats.org/wiki/namespaces-inconsistency -- manu From msporny at digitalbazaar.com Mon Feb 4 21:01:07 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 21:23:52 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE In-Reply-To: <47A7D464.805@psybernet.co.nz> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> <47A7D464.805@psybernet.co.nz> Message-ID: <47A7ED93.7000401@digitalbazaar.com> Walter Logeman wrote: > I am jumping in, new here, new to microformats, looking for a solution > to a problem, but more on that later. Welcome to Microformat's, Walter :) > This thread has helped me understand a few things, though I would not > want to have endless debates about the meta-language used. Just a small pointer - "microformats-new" is for the design/debate/discussion for new Microformats under development. It's a pretty harsh place to start out learning about Microformats - you can learn a great deal from this list, but it's not meant as an introductory discussion group. You might want to check out microformats-discuss if you wanted to discuss the use of pre-existing Microformats in your website: http://microformats.org/mailman/listinfo/microformats-discuss/ That being said - if you could stomach the discussion about namespaces, you should do fine on this list :) > Do I have this right then, > > within hAudio it would be possible to have "title" or "fn"? Well, that is what we're currently debating. The current draft specification for hAudio uses FN, which several of us are contesting as a bad choice. Some of us would like to use TITLE, but previously when we had suggested that, some on this list nixed the idea because TITLE is already used in hCard to mean "job title". Since TITLE was defined to mean "job title" in Microformats, that precludes us from using it for hAudio. We're attempting to change the Microformats definition of TITLE to mean "title" instead of "job title". It sounds like a no-brainer, but we're making sure it doesn't have any other ramifications before doing so. The best thing about this community is that we debate the merits and drawbacks of an idea in an open environment before coming to a conclusion. This helps everybody weigh in on the issues before a decision is made. Some also argue that this open debate is the worst part about this community :) > I'd prefer "title", it makes more intuitive sense to me. Good to know, thanks Walter - that helps us understand what would be most intuitive to somebody starting out in Microformats. We've been immersed in this stuff long enough that it's hard to see the forest for the trees at times. > Would there also be tag name for "file name"? fn could get confusing ... There isn't a proposal for filename at the moment, other than using the ENCLOSURE class in @rel. Filenames, sizes, bitrates, etc. are outside of the scope of what hAudio is attempting to address (naming audio recordings). >> What if the page includes profiles for hAudio *and* hCard? > > I am a total newby, I just looked at my hCard thinking there would be a >
, but no it is
??? Yes, that certainly is confusing. VCARD was used as the class name for historical reasons - hCard is based on the VCARD format by Netscape: http://www.ietf.org/rfc/rfc2426.txt That is why the name of the class is VCARD instead of hCard. > So does every microformat, regardless of the "context" need to be unique? It depends on what you mean by "unique". If you mean, do the class names have to be unique, then yes, they do have to be unique. > I am hoping to mix hCard, xfn and "hArt" if it were there, I saw a start > on it? I will start some new threads. Yes, you can mix hCard and xfn on the same page, and even in the same paragraph. -- manu From msporny at digitalbazaar.com Mon Feb 4 20:01:26 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 4 21:23:53 2008 Subject: namespaces bad topic for uf mailing lists reminder (was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)) In-Reply-To: References: Message-ID: <47A7DF96.5000005@digitalbazaar.com> Tantek ?elik wrote: >> No one actually will admit to the existence of a namespace in >> microformats but there is lots of evidence suggesting otherwise. >> >> either intentional or not, Microformats MAY have created their own >> "namespace" of a kind I think? > > The problem is with this loose use of term "namespace" or "namespace of a > kind", not with microformats usage thereof which will result in endless > semantic arguments which are not useful. Is that why you "RESOLVED" the issue without consulting the list first? http://microformats.org/wiki?title=namespaces-inconsistency-issue&diff=25462&oldid=25450 If Andy did something like that, he'd be up for another ban... With all due respect, Tantek - I was attempting to make the definition of "namespace" that the Microformats community uses far more accurate - to clarify the "no namespaces" stance that the community has. By shutting down the discussion, you've single-handedly pre-empted that improvement to the wiki. An improvement that would help new comers to this list and Microformats understand what we mean by "no namespaces". It was an improvement that the community largely agrees with, but the namespaces page doesn't express[1]. You even agree to this sentiment in the e-mail you quote in the "RESOLUTION" section[2]. I'm disappointed that this discussion is being pre-emptively shut down... just when it seemed as if we were making progress. -- manu [1]http://microformats.org/wiki/namespaces [2]http://microformats.org/wiki/namespaces-inconsistency-issue#Resolution From tantek at cs.stanford.edu Mon Feb 4 15:21:51 2008 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Feb 4 23:18:22 2008 Subject: (edited) Re: XMDP/GRDDL was Re: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: Message-ID: Apologies, this email sent from my outbox as I was editing it and unintentionally duplicated some text sent in another email. It should have had its subject updated and been edited down to: On 2/4/08 3:05 PM, "Tantek ?elik" wrote: >> Microformats declare a formal profile[1] in their proposals[2] >> >> [1] http://gmpg.org/xmdp/ >> [2] http://microformats.org/wiki/haudio#XMDP_Profile >> >> and then do this... >> >> >> >> very GRDDL Like >> >> > > The uses are quite different actually. XMDP uses the profile attribute for > defining terms, and GRDDL uses the profile attribute for defining how to > transform. > > >> Maybe someone can explain to me why declare a profile if there isn't >> some kind of metadata description at the end? >> >> http://gmpg.org/xfn/11 > > XMDP provides a simple description mostly just to define the terms. So far > we've resisted additional metadata similar to DTDs or XML Schema docs. > > Another big difference is the way XMDP overrides work, linked from [1] cited > previously above: > > http://gmpg.org/xmdp/description > > Note that if two different profiles define the same term, only the first > definition is used. Thus they are not "namespaces" in any data/programming > functional way (like XML namespaces), as such namespaces make such multiple > references exist simultaneously and distinctly by keeping them in their own > silos. > > I have added both of these to the XMDP FAQ: > http://microformats.org/wiki/xmdp-faq > > Tantek > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From danny.ayers at gmail.com Tue Feb 5 00:42:51 2008 From: danny.ayers at gmail.com (Danny Ayers) Date: Tue Feb 5 00:42:53 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: References: <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> Message-ID: <1f2ed5cd0802050042m3ea230d7j2ad7bb8dffeda025@mail.gmail.com> On 05/02/2008, Tantek ?elik wrote: > > > > The uses are quite different actually. XMDP uses the profile attribute for > defining terms, and GRDDL uses the profile attribute for defining how to > transform. Although I may be alone in this opinion, I'd view them as being very similar: the XMDP provides a human-oriented interpretation of the terms used in the source document, GRDDL provides a machine-oriented interpretation. Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/ From walter at psybernet.co.nz Tue Feb 5 02:01:30 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Tue Feb 5 02:01:42 2008 Subject: [uf-new] Introduction to Microformats In-Reply-To: <47A7ED93.7000401@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> <47A7D464.805@psybernet.co.nz> <47A7ED93.7000401@digitalbazaar.com> Message-ID: <47A833FA.6030803@psybernet.co.nz> Manu, In a thread Re: [uf-new] Namespace anti-pattern and hAudio TITLE Manu wrote: > Welcome to Microformat's, Walter :) > Just a small pointer - "microformats-new" is for the > design/debate/discussion for new Microformats under development. It's a > pretty harsh place to start out learning about Microformats - you can > learn a great deal from this list, but it's not meant as an introductory > discussion group. Is the workofart one of the ones under development? It looks a bit lost: http://www.microformats.org/wiki/workofart-formats Could that be revived here on this list? ~ > http://microformats.org/mailman/listinfo/microformats-discuss/ Ok, I will join microformats-discuss I need to do that to see if I am on the right track for my situation, I will go there for that. I am looking here at the moment at following the steps here: http://www.microformats.org/wiki/process > That being said - if you could stomach the discussion about namespaces, > you should do fine on this list :) I am a programming virgin but a Philosophy graduate so this sort of thing is quite fun, but I can see it could go off-topic. I am going to POSHify my site, I'll learn by doing, and return here later. Walter From walter at psybernet.co.nz Tue Feb 5 02:01:47 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Tue Feb 5 02:02:01 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE In-Reply-To: <47A7ED93.7000401@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> <47A7D464.805@psybernet.co.nz> <47A7ED93.7000401@digitalbazaar.com> Message-ID: <47A8340B.6030206@psybernet.co.nz> Manu Sporny wrote: >> So does every microformat, regardless of the "context" need to be unique? > > It depends on what you mean by "unique". If you mean, do the class names > have to be unique, then yes, they do have to be unique. I suppose you mean it depends on what I mean by Microformat? Are FN and "title" class names? I presume not as I understand it so far, FN is not unique and potentially "title" is not? >> I am hoping to mix hCard, xfn and "hArt" if it were there, I saw a start >> on it? I will start some new threads. > > Yes, you can mix hCard and xfn on the same page, and even in the same > paragraph. Good. Walter From hober0 at gmail.com Tue Feb 5 00:00:06 2008 From: hober0 at gmail.com (Edward O'Connor) Date: Tue Feb 5 02:05:09 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> <47A7DC14.30001@digitalbazaar.com> Message-ID: Manu wrote: > Does it? If 'country-name' isn't namespaced, then we could get rid of > country and 'name' by itself would have an unambiguous meaning. I think you're missing the distinction between 'namespace' and 'context', like Tantek suggested. Basically, you're stating the reductio for your own position -- you're basically saying that all adjectives are namespaces, and that's clearly incorrect. > However, if we were to do that in practice, 'name' wouldn't mean > 'country name' anymore... it would be more ambiguous. By being more > ambiguous, we're stating that the prefix that we removed, 'country', > actually does have semantic meaning. *Of course* 'country' has semantic meaning. It's an adjective that provides context for 'name'. But context does not a namespace make... > 'country' is a namespace that gives scope to the following 'name' by > specifying that we are talking about a 'country name' and not a > 'person name'. No, country does that because of its adjective-ness, not its namespace-ness. Ted -- Edward O'Connor hober0@gmail.com Ense petit placidam sub libertate quietem. From info at weborganics.co.uk Tue Feb 5 02:12:58 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 5 02:13:10 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title) In-Reply-To: <47A7DC14.30001@digitalbazaar.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> <47A7DC14.30001@digitalbazaar.com> Message-ID: <1202206378.6271.27.camel@weborganicscouk> Hello Manu On Mon, 2008-02-04 at 22:46 -0500, Manu Sporny wrote: > My argument still stands - we're providing a specific scope to > 'title', > 'summary' and 'description' - that scope is 'entry'. > > We are also providing a specific scope to 'name', and 'unit' - that > scope is 'organization'. So microformats DO "scope" after all! "title" in hcard is in the "scope" of "job" it just doesn't say it, in haudio it would be in the "scope" of audio but we would say it Maybe an Idea would be for hcard to say what it means and stop being so vague and confusing, and in my opinion "wrong" change in hcard to can be easily explained as "the function of the object the vcard represents" or simply their "job title" which is how its often explained. None need never have this discussion about "title" again? the community would say "yes of course you can use title in your new microformat it makes sense too, although it must be scoped like *foo-title* in order to give it context" Thanks Martin McEvoy From JOttevanger at museumoflondon.org.uk Tue Feb 5 02:25:06 2008 From: JOttevanger at museumoflondon.org.uk (Ottevanger, Jeremy) Date: Tue Feb 5 02:24:57 2008 Subject: [no sig]RE: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <21e523c20802040929q78e20066o2b7cc8b48462709c@mail.gmail.com> Message-ID: Thank you David, that's very interesting. It would fill a pretty important gap in describing basic phenomena - time, place, and agents have their uF but not things, in the general sense. Even the simplest container, DC questions aside, would be a very useful step. Cheers, Jeremy -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of David Janes Sent: 04 February 2008 17:30 To: For discussion of new microformats. Subject: Re: RE: [uf-new] Dublin Core (was: hAudio FN or Title) There's been information collected about how an "item" microformat would work, though by no means consider this official, blessed, voted upon, or even official proposed. If anyone is really serious about going down this road, I suggest going back though the mailing list archives, especially around the time hAudio was getting to 0.1. For the record, my idea (now) of hItem would work is: - as the _intersection_ of item attributes, roughly ;-) - as a building block for use in other uFs, following the process I'm still lurking at hAudio discussions to see how this is all working out. From andy at pigsonthewing.org.uk Tue Feb 5 03:13:38 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 5 03:14:44 2008 Subject: [uf-new] hAudio vS hTrack? In-Reply-To: <866CFD96-DE1A-4F6D-BEA5-969D7024453D@makedatamakesense.com> References: <1202160870.6563.47.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1202163622.8705.3.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <866CFD96-DE1A-4F6D-BEA5-969D7024453D@makedatamakesense.com> Message-ID: <2wc8omGiTEqHFwT7@pigsonthewing.org.uk> In message <866CFD96-DE1A-4F6D-BEA5-969D7024453D@makedatamakesense.com>, Scott Reynen writes >I don't know anything about Lucas' views beyond what you can find in >the email archives: 2005-07-29 05:42:14 GMT: > This has been proposed before and rejected for several > reasons: It was rejected? By who, and under what authority? Sounds familiar. His question appears to have gone unanswered. Perhaps that contributed to his disenchantment? -- Andy Mabbett From davidjanes at blogmatrix.com Tue Feb 5 04:26:02 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Tue Feb 5 04:54:17 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE In-Reply-To: <47A8340B.6030206@psybernet.co.nz> References: <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> <47A7D464.805@psybernet.co.nz> <47A7ED93.7000401@digitalbazaar.com> <47A8340B.6030206@psybernet.co.nz> Message-ID: <21e523c20802050426r7d66ad20s3fc5c69968a832a9@mail.gmail.com> I'm going to vote with Tantek on this one. I'm sympathetic to what you're saying Manu, but after 2 or 3 years on this list and seeing the same topics come up over and over that really aren't going to change. Not because they're not (necessarily) bad ideas, but that they're outside of almost the core definitions of microformats at this point. Based on this discussion, I've added a "but hAtom uses namespaces, doesn't it" section to the namespaces page. Regards, etc... On Feb 5, 2008 5:01 AM, Walter Logeman wrote: > > Manu Sporny wrote: > > >> So does every microformat, regardless of the "context" need to be unique? > > > > It depends on what you mean by "unique". If you mean, do the class names > > have to be unique, then yes, they do have to be unique. > > I suppose you mean it depends on what I mean by Microformat? Are FN > and "title" class names? I presume not as I understand it so far, FN > is not unique and potentially "title" is not? > > > >> I am hoping to mix hCard, xfn and "hArt" if it were there, I saw a start > >> on it? I will start some new threads. > > > > Yes, you can mix hCard and xfn on the same page, and even in the same > > paragraph. > > Good. > > Walter > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From msporny at digitalbazaar.com Tue Feb 5 10:21:09 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 5 10:53:55 2008 Subject: [uf-new] Namespace anti-pattern and hAudio TITLE In-Reply-To: <21e523c20802050426r7d66ad20s3fc5c69968a832a9@mail.gmail.com> References: <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> <47A7D464.805@psybernet.co.nz> <47A7ED93.7000401@digitalbazaar.com> <47A8340B.6030206@psybernet.co.nz> <21e523c20802050426r7d66ad20s3fc5c69968a832a9@mail.gmail.com> Message-ID: <47A8A915.8080405@digitalbazaar.com> David Janes wrote: > I'm going to vote with Tantek on this one. I'm sympathetic to what > you're saying Manu, but after 2 or 3 years on this list and seeing the > same topics come up over and over that really aren't going to change. I'm not asking the community to change it's stance on fully qualified namespaces. I'm asking the community to clarify their position based on their implementation history in hCard and hAtom: http://microformats.org/wiki/namespaces-inconsistency-issue The reason these topics keep coming up over and over again is because they are defined vaguely and inconsistently on the wiki. That leads to confusion. Confusion leads to the discussion we just had. -- manu From msporny at digitalbazaar.com Tue Feb 5 10:16:17 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 5 10:53:56 2008 Subject: [uf-new] Introduction to Microformats In-Reply-To: <47A833FA.6030803@psybernet.co.nz> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> <47A7D464.805@psybernet.co.nz> <47A7ED93.7000401@digitalbazaar.com> <47A833FA.6030803@psybernet.co.nz> Message-ID: <47A8A7F1.5090202@digitalbazaar.com> Walter Logeman wrote: > Is the workofart one of the ones under development? It currently has nobody pushing the format forward. > It looks a bit lost: > http://www.microformats.org/wiki/workofart-formats > Could that be revived here on this list? It could be revived - but be ready to do a ton of work if you pick it up. It took around 500+ hours of work by the editor and around 250+ hours (estimated) of work by list participants to get hAudio to where it is today. Pushing a Microformat forward is not for the faint of heart... but if you're okay with doing that sort of work for the public good, by all means, push hArt forward. >> That being said - if you could stomach the discussion about namespaces, >> you should do fine on this list :) > > I am a programming virgin but a Philosophy graduate so this sort of > thing is quite fun, but I can see it could go off-topic. Good :) - there is quite a bit of borrowed philosophy from a variety of disciplines wrapped up in Microformats. It's interesting to see the intersection of the philosophies of linguistics, computer science, working for the public domain, and what people find easy and intuitive implement. > I am going to POSHify my site, I'll learn by doing, and return here later. That's the best place to start... :) -- manu From msporny at digitalbazaar.com Tue Feb 5 09:59:30 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 5 10:53:56 2008 Subject: [uf-new] namespaces-inconsistency-issue page updated Message-ID: <47A8A402.5070402@digitalbazaar.com> The namespaces inconsistency issue page has been updated with the current state of this discussion. I'm going to drop the issue (once again) since it seems to be making several people uncomfortable. http://microformats.org/wiki/namespaces-inconsistency-issue Please read the page and update the page if you see something that is factually inaccurate or needs re-wording. More importantly, if you would like to see the Microformats community address this issue (and not ignore it like we've been doing), please sign the "Sympathetic to the Cause" section of the page: http://microformats.org/wiki/namespaces-inconsistency-issue#Sympathetic_to_the_Cause To sign, just log into the wiki and use "~~~~" or "/Your Name/". -- manu From msporny at digitalbazaar.com Tue Feb 5 09:47:44 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 5 10:53:57 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE In-Reply-To: References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <21e770780802041305p6afb702dl7ca3e55697cb9a9c@mail.gmail.com> <47A7DC14.30001@digitalbazaar.com> Message-ID: <47A8A140.3020801@digitalbazaar.com> Edward O'Connor wrote: > Manu wrote: > >> Does it? If 'country-name' isn't namespaced, then we could get rid of >> country and 'name' by itself would have an unambiguous meaning. > > I think you're missing the distinction between 'namespace' and > 'context', like Tantek suggested. I assure you, I am not missing the distinction. I have quoted the definitions in the literature to back up what I'm asserting. Please read the namespace-inconsistency-issue page before making statements to that effect (I have updated it to reflect your comments): http://microformats.org/wiki/namespaces-inconsistency-issue All definitions are clearly cited - note that nobody else is citing definitions to what "namespace" means in this discussion. If you would like to cite some examples that support your viewpoint, that would be great. :) > Basically, you're stating the reductio > for your own position -- you're basically saying that all adjectives are > namespaces, and that's clearly incorrect. This is what I'm saying: context/scope provide "an enclosing structure that provides semantic meaning to the elements that it encloses."[1] When you name a context/scope, it is called a namespace.[2] > *Of course* 'country' has semantic meaning. It's an adjective that > provides context for 'name'. But context does not a namespace make... No, but a named context is a namespace. It's right there in your first semester programming languages text book (which I've cited several of them on the namespaces-inconsistency-issue page). >> 'country' is a namespace that gives scope to the following 'name' by >> specifying that we are talking about a 'country name' and not a >> 'person name'. > > No, country does that because of its adjective-ness, not its > namespace-ness. In this case, they're the same thing. In general, I would go as far to say that adjectives and adverbs, by definition, are namespaces because they provide finer context for the subject that they describe AND they are named. A named context is... a namespace. -- manu [1]http://wordnet.princeton.edu/perl/webwn?s=context [2]http://en.wikipedia.org/wiki/Scope_%28programming%29 From bbtommorris at gmail.com Tue Feb 5 11:18:59 2008 From: bbtommorris at gmail.com (Tom Morris) Date: Tue Feb 5 11:19:02 2008 Subject: [no sig]RE: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: References: <21e523c20802040929q78e20066o2b7cc8b48462709c@mail.gmail.com> Message-ID: On Feb 5, 2008 10:25 AM, Ottevanger, Jeremy wrote: > Thank you David, that's very interesting. It would fill a pretty > important gap in describing basic phenomena - time, place, and agents > have their uF but not things, in the general sense. Even the simplest > container, DC questions aside, would be a very useful step. > I think this approach of having a generic 'thing' in microformats is probably not one that is consistent with the principles of microformats. It steps too far away from documents and too far into the abstract. There already exists a format for describing 'things' - RDF and OWL. owl:Thing is the implicit superclass for all classes in OWL, and RDF allows you to describe resources that point to 'things' in a more abstract sense. This is all fine, and you can use eRDF/RDFa to represent this more abstract semantic model in HTML - but for ease of authorship, the whole point of Microformats is that they are simpler than this and represent common uses. If you want to represent 'things', may I suggest you work on using consistent HTML semantics between pages and then maybe model that to a custom RDF model using GRDDL. If the HTML model you use is worth reusing across a bulk of websites, then perhaps suggest that as a microformat. -- Tom Morris http://tommorris.org/ From andy at pigsonthewing.org.uk Tue Feb 5 15:07:52 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 5 15:09:20 2008 Subject: [uf-new] Resolution of issues (was: namespaces bad topic for uf mailing lists reminder) In-Reply-To: <47A7DF96.5000005@digitalbazaar.com> References: <47A7DF96.5000005@digitalbazaar.com> Message-ID: In message <47A7DF96.5000005@digitalbazaar.com>, Manu Sporny 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 and: have been responded to, by any of the "admins". -- Andy Mabbett From danny.ayers at gmail.com Wed Feb 6 05:11:03 2008 From: danny.ayers at gmail.com (Danny Ayers) Date: Wed Feb 6 07:01:19 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: References: <21e770780801311330n1b62197dm99be90db133b462e@mail.gmail.com> Message-ID: <1f2ed5cd0802060511v4df6dd7cy147fb12aec64e8cb@mail.gmail.com> On 01/02/2008, Andy Mabbett wrote: > in an hAudio; whereas an hReview would have: > > class="dtreviewed dc-date-created" fyi, there's an existing (community) convention to be found in Embedded RDF (eRDF): [[ For example:
Ian Davis
wrote this
would be equivalent to the following triple: <> dc:creator "Ian Davis" . (<> is the current document) ]] http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml To be able to get RDF interpretation automatically, you'd want the profile URI as well as a pointer to DC: - but the convention (class="dc-creator" etc) should work ok out of that context, as POSH or whatever. Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/ From info at weborganics.co.uk Wed Feb 6 07:04:31 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed Feb 6 07:04:42 2008 Subject: [uf-new] GRDDL Profiles and XMDP (was: Namespace anti-pattern ...) In-Reply-To: <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> Message-ID: <1202310271.17757.18.camel@weborganicscouk> Hello Danny, All On Mon, 2008-02-04 at 23:56 +0100, Danny Ayers wrote: > By using a > profile URI and putting a description of the terms used in the profile > on the Web You have got me thinking (ohoh!) Do you not think that these profiles eg: http://www.w3.org/2006/03/hcard *should* or *could* be GRDDL profiles too. XMDP is good for humans but the profiles could also be good for machines by embedding a GRDDL profile in there too? useful I would say? instead of this.. which is ugly and tentatively poor or even invalid markup, we can do this Looks a lot more practical to me! Thoughts? Thanks Martin McEvoy From JOttevanger at museumoflondon.org.uk Wed Feb 6 07:28:00 2008 From: JOttevanger at museumoflondon.org.uk (Ottevanger, Jeremy) Date: Wed Feb 6 07:27:53 2008 Subject: [uf-new] Dublin Core (was: hAudio FN or Title) In-Reply-To: <1f2ed5cd0802060511v4df6dd7cy147fb12aec64e8cb@mail.gmail.com> Message-ID: Thanks, Danny. That's really useful and I'm going to follow that one up. I guess we may have to settle for POSH without the stamp of approval of the uF community, but it's good to know that other groups are settling on workable conventions for POSH DC. Cheers, Jeremy Jeremy Ottevanger Web Developer, Museum Systems Team Museum of London Group 46 Eagle Wharf Road London. N1 7ED Tel: 020 7410 2207 Fax: 020 7600 1058 Email: jottevanger@museumoflondon.org.uk www.museumoflondon.org.uk Museum of London is changing; our lower galleries will be closed while they undergo a major new development. Visit www.museumoflondon.org.uk to find out more. London's Burning - explore how the Great Fire of London shaped the city we see today www.museumoflondon.org.uk/londonsburning -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Danny Ayers Sent: 06 February 2008 13:11 To: For discussion of new microformats. Subject: Re: [uf-new] Dublin Core (was: hAudio FN or Title) On 01/02/2008, Andy Mabbett wrote: > in an hAudio; whereas an hReview would have: > > class="dtreviewed dc-date-created" fyi, there's an existing (community) convention to be found in Embedded RDF (eRDF): [[ For example:
Ian Davis
wrote this
would be equivalent to the following triple: <> dc:creator "Ian Davis" . (<> is the current document) ]] http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml To be able to get RDF interpretation automatically, you'd want the profile URI as well as a pointer to DC: - but the convention (class="dc-creator" etc) should work ok out of that context, as POSH or whatever. Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/ _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From JOttevanger at museumoflondon.org.uk Wed Feb 6 07:31:50 2008 From: JOttevanger at museumoflondon.org.uk (Ottevanger, Jeremy) Date: Wed Feb 6 07:32:43 2008 Subject: [uf-new] workofart (was: Introduction to Microformats) In-Reply-To: <47A8A7F1.5090202@digitalbazaar.com> Message-ID: Hi Walter, Last spring I asked the same Q about workofart. There was limited interest in it, it seemed, although I did get some encouraging (partly off-list) feedback and suggestions. I went off and had a rethink. In the last few days there have been some posts around the idea of a Dublin Core microformat, which idea has been pretty much dismissed or ignored, I think (as it was last year, when again it was mooted for describing works of art) but which has got me interested again. My feeling now, as I wrote on Monday, is that something broader than simply works of art is useful (hence the case for a uF based on DC), but it looks like the leading lights of this community generally favour something extremely specific. Maybe, then, workofart could be revived. I'm still bemused, though, that the broadly applicable seems to be rejected in favour of the narrow. As I understand it, new microformats should where possible build upon existing uFs, but if these start off very narrow rather than generic then it makes it that much more awkward to do this - which it strikes me is the root of most of the problems in the hAudio debate. Had there been more broadly-aimed uFs to build it upon then rows over the meaning of "title" or "contributor" might never have arisen. Cheers, Jeremy Jeremy Ottevanger Web Developer, Museum Systems Team Museum of London Group 46 Eagle Wharf Road London. N1 7ED Tel: 020 7410 2207 Fax: 020 7600 1058 Email: jottevanger@museumoflondon.org.uk www.museumoflondon.org.uk Museum of London is changing; our lower galleries will be closed while they undergo a major new development. Visit www.museumoflondon.org.uk to find out more. London's Burning - explore how the Great Fire of London shaped the city we see today www.museumoflondon.org.uk/londonsburning -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Manu Sporny Sent: 05 February 2008 18:16 To: For discussion of new microformats. Subject: Re: [uf-new] Introduction to Microformats Walter Logeman wrote: > Is the workofart one of the ones under development? It currently has nobody pushing the format forward. > It looks a bit lost: > http://www.microformats.org/wiki/workofart-formats > Could that be revived here on this list? It could be revived - but be ready to do a ton of work if you pick it up. It took around 500+ hours of work by the editor and around 250+ hours (estimated) of work by list participants to get hAudio to where it is today. Pushing a Microformat forward is not for the faint of heart... but if you're okay with doing that sort of work for the public good, by all means, push hArt forward. >> That being said - if you could stomach the discussion about >> namespaces, you should do fine on this list :) > > I am a programming virgin but a Philosophy graduate so this sort of > thing is quite fun, but I can see it could go off-topic. Good :) - there is quite a bit of borrowed philosophy from a variety of disciplines wrapped up in Microformats. It's interesting to see the intersection of the philosophies of linguistics, computer science, working for the public domain, and what people find easy and intuitive implement. > I am going to POSHify my site, I'll learn by doing, and return here later. That's the best place to start... :) -- manu _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Wed Feb 6 10:06:57 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Feb 6 10:23:54 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE Message-ID: <47A9F741.2060801@digitalbazaar.com> It is difficult for Microformat newbies to understand the reasoning behind the choice of FN for hAudio titles. Similarly, its semantic meaning is questionable when used with hAudio to name song, album and audio recording title's in general. There does not seem to be any legacy issues with using TITLE from hCard, other than the definition would have to change from "job title" to "title". Since hCard is the only Microformat that uses TITLE, and since TITLE has a more specific meaning in hCard to mean "job title", it can be said that TITLE, much like FN, becomes more specific given the context. FN in hCard means "the formatted name of a person or orgainzation". FN in hAudio currently means "the formatted name of an audio recording". If this proposal were adopted, the following would hold: TITLE in hCard means "job title" TITLE in hAudio means "audio recording title" It was asserted that this change would have no ill-effects to any other Microformat[1]. That assertion has yet to be challenged. The reasons for this change include: - TITLE is more semantically accurate, we are trying to describe the title of the audio recording. - TITLE makes more sense to Microformats newbies than FN does. - There can be conflicts between hAudio FN and hCard FN - these conflicts are more prevalent that hAudio TITLE and hCard TITLE conflicts because TITLE is used less in hCard than FN. Oppositions to changing from FN to TITLE include: - It is already defined as "job title" in hCard. If you are in support of this proposal, please speak up, even if it is a "+1". If you are opposed to this proposal, please let us know the reasoning to your opposition. -- manu [1]http://microformats.org/discuss/mail/microformats-new/2008-February/001419.html From msporny at digitalbazaar.com Wed Feb 6 09:17:46 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Feb 6 10:23:55 2008 Subject: [uf-new] workofart In-Reply-To: References: Message-ID: <47A9EBBA.1010503@digitalbazaar.com> Ottevanger, Jeremy wrote: > In the > last few days there have been some posts around the idea of a Dublin > Core microformat, which idea has been pretty much dismissed or ignored, I think there is more support for re-using DC terms than you might think. As Danny stated, there is "an existing (community) convention to be found in Embedded RDF (eRDF)", namely - prefixing "dc-" before each term. If we want to re-use Dublin Core, we should adopt that thinking. Don't let the loud opposition of a few members in the community lead you to believe that there is no support for DC in this community. I should point out that hAudio RDFa makes heavy re-use of Dublin Core: http://wiki.digitalbazaar.com/en/hAudio_RDFa > I'm still bemused, though, that the broadly applicable seems to be > rejected in favour of the narrow. As I understand it, new microformats > should where possible build upon existing uFs, but if these start off > very narrow rather than generic then it makes it that much more awkward > to do this - which it strikes me is the root of most of the problems in > the hAudio debate. Had there been more broadly-aimed uFs to build it > upon then rows over the meaning of "title" or "contributor" might never > have arisen. Yes, that's true. It's a shame that we waste so much time convincing others of things that are openly accepted in other communities - things like the semantic meaning of "title". -- manu From walter at psybernet.co.nz Wed Feb 6 13:54:36 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Wed Feb 6 13:54:46 2008 Subject: [uf-new] workofart In-Reply-To: References: Message-ID: <47AA2C9C.9030402@psybernet.co.nz> Hi Jeremy, I notice there is an hItem. Could that be the broader thing you are thinking of? What would happen if workofart was a subcategory of Item? I hope my na?ve questions are of some use! Walter ~ Ottevanger, Jeremy wrote: > Hi Walter, > > Last spring I asked the same Q about workofart. There was limited > interest in it, it seemed, although I did get some encouraging (partly > off-list) feedback and suggestions. I went off and had a rethink. In the > last few days there have been some posts around the idea of a Dublin > Core microformat, which idea has been pretty much dismissed or ignored, > I think (as it was last year, when again it was mooted for describing > works of art) but which has got me interested again. > > My feeling now, as I wrote on Monday, is that something broader than > simply works of art is useful (hence the case for a uF based on DC), but > it looks like the leading lights of this community generally favour > something extremely specific. Maybe, then, workofart could be revived. > I'm still bemused, though, that the broadly applicable seems to be > rejected in favour of the narrow. As I understand it, new microformats > should where possible build upon existing uFs, but if these start off > very narrow rather than generic then it makes it that much more awkward > to do this - which it strikes me is the root of most of the problems in > the hAudio debate. Had there been more broadly-aimed uFs to build it > upon then rows over the meaning of "title" or "contributor" might never > have arisen. > > Cheers, Jeremy > > > > Jeremy Ottevanger > Web Developer, Museum Systems Team > Museum of London Group > 46 Eagle Wharf Road > London. N1 7ED > Tel: 020 7410 2207 > Fax: 020 7600 1058 > Email: jottevanger@museumoflondon.org.uk > www.museumoflondon.org.uk > Museum of London is changing; our lower galleries will be closed while they undergo a major new development. Visit www.museumoflondon.org.uk to find out more. > London's Burning - explore how the Great Fire of London shaped the city we see today www.museumoflondon.org.uk/londonsburning > > > -----Original Message----- > From: microformats-new-bounces@microformats.org > [mailto:microformats-new-bounces@microformats.org] On Behalf Of Manu > Sporny > Sent: 05 February 2008 18:16 > To: For discussion of new microformats. > Subject: Re: [uf-new] Introduction to Microformats > > Walter Logeman wrote: >> Is the workofart one of the ones under development? > > It currently has nobody pushing the format forward. > >> It looks a bit lost: >> http://www.microformats.org/wiki/workofart-formats >> Could that be revived here on this list? > > It could be revived - but be ready to do a ton of work if you pick it > up. It took around 500+ hours of work by the editor and around 250+ > hours (estimated) of work by list participants to get hAudio to where it > is today. > > Pushing a Microformat forward is not for the faint of heart... but if > you're okay with doing that sort of work for the public good, by all > means, push hArt forward. > >>> That being said - if you could stomach the discussion about >>> namespaces, you should do fine on this list :) >> I am a programming virgin but a Philosophy graduate so this sort of >> thing is quite fun, but I can see it could go off-topic. > > Good :) - there is quite a bit of borrowed philosophy from a variety of > disciplines wrapped up in Microformats. It's interesting to see the > intersection of the philosophies of linguistics, computer science, > working for the public domain, and what people find easy and intuitive > implement. > >> I am going to POSHify my site, I'll learn by doing, and return here > later. > > That's the best place to start... :) > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > > __________ NOD32 2853 (20080206) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > From danny.ayers at gmail.com Wed Feb 6 09:06:36 2008 From: danny.ayers at gmail.com (Danny Ayers) Date: Wed Feb 6 16:13:18 2008 Subject: [uf-new] GRDDL Profiles and XMDP (was: Namespace anti-pattern ...) In-Reply-To: <1202310271.17757.18.camel@weborganicscouk> References: <47A7316F.4020500@digitalbazaar.com> <21e523c20802040943y223d241bo90aa00cb51071cf7@mail.gmail.com> <47A75E1A.4000604@digitalbazaar.com> <21e770780802041113w648fd040l641a335292dfdb4a@mail.gmail.com> <47A772F4.4090005@digitalbazaar.com> <1202160300.6563.44.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1f2ed5cd0802041456u6eaafdd2q65f9bfc53a914e2d@mail.gmail.com> <1202310271.17757.18.camel@weborganicscouk> Message-ID: <1f2ed5cd0802060906o3262d948mdee901e48c23038a@mail.gmail.com> On 06/02/2008, Martin McEvoy wrote: > Hello Danny, All > > On Mon, 2008-02-04 at 23:56 +0100, Danny Ayers wrote: > > By using a > > profile URI and putting a description of the terms used in the profile > > on the Web > > You have got me thinking (ohoh!) > > Do you not think that these profiles eg: > > http://www.w3.org/2006/03/hcard > > *should* or *could* be GRDDL profiles too. Er, yes - that one is :-) I'm not sure, but the only reason the other microformats don't have GRDDLable profiles is lack of interest by the microformats core group. I (and others) pushed a lot to try and get profiles for the microformats, but the best response we got was the suggestion of using the Wiki URIs as profile URIs. Which would be fine, but to support GRDDL would need one of the Wiki administrators to make the appropriate changes...and there doesn't seem any enthusiasm. > > > which is ugly and tentatively poor or even invalid markup, Ugly, yes, but I think perfectly valid according to the html spec. > we can do this > > > > > > Looks a lot more practical to me! > > Thoughts? Right, that kind of thing would be an improvement. An even neater one was (I think) sugested by Dan Connolly. Make a joint profile for all the common microformats, so all you'd need is: Not sure about the current status, whether anyone's actually working on this. Will check. Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/ From info at weborganics.co.uk Thu Feb 7 03:28:01 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 7 03:28:25 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47A9F741.2060801@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> Message-ID: <1202383682.22200.31.camel@weborganicscouk> On Wed, 2008-02-06 at 13:06 -0500, Manu Sporny wrote: > It is difficult for Microformat newbies to understand the reasoning > behind the choice of FN for hAudio titles. Similarly, its semantic > meaning is questionable when used with hAudio to name song, album and > audio recording title's in general. > > There does not seem to be any legacy issues with using TITLE from hCard, > other than the definition would have to change from "job title" to > "title". Since hCard is the only Microformat that uses TITLE, and since > TITLE has a more specific meaning in hCard to mean "job title", it can > be said that TITLE, much like FN, becomes more specific given the context. > > FN in hCard means "the formatted name of a person or orgainzation". > FN in hAudio currently means "the formatted name of an audio recording". > > If this proposal were adopted, the following would hold: > > TITLE in hCard means "job title" > TITLE in hAudio means "audio recording title" > > It was asserted that this change would have no ill-effects to any other > Microformat[1]. That assertion has yet to be challenged. I think that many people, by the above statement, may think this has something to do with hcard, we can draw comparisons to hcard (if you like) but that is not what is meant. Title in the context of this proposal means (amongst a plethora of other terms): Atom title, Contains a human readable title for the entry. This value should not be blank. http://atomenabled.org/developers/syndication/#requiredEntryElements RSS2 title, The title of the item. Venice Film Festival Tries to Quit Sinking http://cyber.law.harvard.edu/rss/rss.html#hrelementsOfLtitemgt html Title, Authors should use the TITLE element to identify the contents of a document. http://www.w3.org/TR/html401/struct/global.html#h-7.4.2 Dublin Core dc:title, A name given to the resource. http://dublincore.org/documents/dcmi-terms/#terms-title XSPF Title, Human-readable name of the track.. (garbage after this I think someone needs to look at the spec and amend it) http://www.xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.3 and http://www.xspf.org/xspf-v0.html#title (for a cleaner definition) Ogg Vorbis Comment, TITLE, "the work", whether a symphony, or a pop song. http://reactor-core.org/ogg-tagging.html +1 By the way nice proposal. Kind regards Martin McEvoy PS: Its interesting to note that "Title's" in classical music generally get their names from the "sheet music titles", cant find any reliable sources that say this, but I would say kind of relevant. > > The reasons for this change include: > > - TITLE is more semantically accurate, we are trying to describe the > title of the audio recording. > - TITLE makes more sense to Microformats newbies than FN does. > - There can be conflicts between hAudio FN and hCard FN - these > conflicts are more prevalent that hAudio TITLE and hCard TITLE > conflicts because TITLE is used less in hCard than FN. > > Oppositions to changing from FN to TITLE include: > > - It is already defined as "job title" in hCard. > > If you are in support of this proposal, please speak up, even if it is a > "+1". If you are opposed to this proposal, please let us know the > reasoning to your opposition. > > -- manu > > [1]http://microformats.org/discuss/mail/microformats-new/2008-February/001419.html > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From Michael.Smethurst at bbc.co.uk Thu Feb 7 03:55:42 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu Feb 7 03:55:51 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1202383682.22200.31.camel@weborganicscouk> Message-ID: >> If you are in support of this proposal, please speak up, even if it is a >> "+1". If you are opposed to this proposal, please let us know the >> reasoning to your opposition. +1 ;-) 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. From guillaume at lebleu.org Thu Feb 7 09:26:14 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Thu Feb 7 09:26:21 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47A9F741.2060801@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> Message-ID: <47AB3F36.8070702@lebleu.org> Manu Sporny wrote: > If you are in support of this proposal, please speak up, even if it is a > "+1". If you are opposed to this proposal, please let us know the > reasoning to your opposition. > > +1 Guillaume From guillaume at lebleu.org Thu Feb 7 09:19:49 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Thu Feb 7 09:37:17 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1202383682.22200.31.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <1202383682.22200.31.camel@weborganicscouk> Message-ID: <47AB3DB5.3050705@lebleu.org> Martin McEvoy wrote: > PS: Its interesting to note that "Title's" in classical music generally > get their names from the "sheet music titles", cant find any reliable > sources that say this, but I would say kind of relevant. > > Not sure I understand what you mean here. Can you elaborate? Guillaume From info at weborganics.co.uk Thu Feb 7 13:02:15 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 7 13:02:28 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47AB3DB5.3050705@lebleu.org> References: <47A9F741.2060801@digitalbazaar.com> <1202383682.22200.31.camel@weborganicscouk> <47AB3DB5.3050705@lebleu.org> Message-ID: <1202418136.24774.66.camel@weborganicscouk> On Thu, 2008-02-07 at 09:19 -0800, Guillaume Lebleu wrote: > Martin McEvoy wrote: > > PS: Its interesting to note that "Title's" in classical music generally > > get their names from the "sheet music titles", cant find any reliable > > sources that say this, but I would say kind of relevant. > > > > > > Not sure I understand what you mean here. Can you elaborate? sure, well I will try ;) "sheet music" is music in its paper form, can either be handwritten or printed musical notation, "sheet" is used so you know the difference between music on paper and a music presentation (audio), Both are more generally called just "music". Its what people used to buy before recorded music came about. This is why Tin Pan Alley in New York became famous (1900's) Early sheet music came in the form of manuscripts written on parchment, Later sheet music came in book form (song books), Now more often than not It comes in PDF format, There is an XML Vocabulary for Digital "Sheet Music" called MusicXML http://www.musicxml.org/ I would Guess the reason why we use "title" ie: "song title" and "title track" when referring to an audio composition is because the written/printed form of music "sheet" also uses "title" As I said above I don't have any good citations or sources (yet) but it is an interesting theory. There may be others on the list that can expand this theory further as I am not an expert :) Thanks Marin McEvoy > > Guillaume > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From info at weborganics.co.uk Thu Feb 7 14:44:21 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 7 14:44:35 2008 Subject: [uf-new] hAudio rel-license [issue] Message-ID: <1202424261.26772.13.camel@weborganicscouk> Hello all rel-license was raised by Andy Mabbett as an issue because of some wording in the notes part of the hAudio Proposal: "...By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content MAY be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using rel-license as specified above" http://microformats.org/wiki/haudio#Notes Andy Mabbett quite rightly said "that is the first and only reference to rel-license on the page" http://microformats.org/discuss/mail/microformats-discuss/2008-January/011345.html What I am wondering is Should this bit of text be re-worded by just removing "...as specified above", or should rel="licence" be part of the proposal? Thanks Martin McEvoy From info at weborganics.co.uk Thu Feb 7 15:33:57 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 7 15:34:12 2008 Subject: [uf-new] hAudio [issue] D4: rel-enclosure does not allow for links to streaming files Message-ID: <1202427238.28999.17.camel@weborganicscouk> Hello all http://microformats.org/wiki/haudio-issues#2008 D4 Andy Mabbbett said: "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 rel="enclosure" is reused from Atom: "enclosure: a related resource which is potentially large in size and might require special handling, for example an audio or video recording" http://atomenabled.org/developers/syndication/#link It doesn't say anything about the caching the file (although in a later conversation I suggested as such) just that it may be "large" and it requires "special handling" Seems Appropriate! Close this Issue? or Discuss? Thanks Martin McEvoy From andy at pigsonthewing.org.uk Thu Feb 7 16:17:58 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 7 16:19:24 2008 Subject: [uf-new] hAudio [issue] D4: rel-enclosure does not allow for links to streaming files In-Reply-To: <1202427238.28999.17.camel@weborganicscouk> References: <1202427238.28999.17.camel@weborganicscouk> Message-ID: In message <1202427238.28999.17.camel@weborganicscouk>, Martin McEvoy 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: ? -- Andy Mabbett From info at weborganics.co.uk Thu Feb 7 16:31:21 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 7 16:31:33 2008 Subject: [uf-new] hAudio [issue] D4: rel-enclosure does not allow for links to streaming files In-Reply-To: References: <1202427238.28999.17.camel@weborganicscouk> Message-ID: <1202430681.29797.0.camel@weborganicscouk> On Fri, 2008-02-08 at 00:17 +0000, Andy Mabbett wrote: > Thanks for the extra "b"; I'll save it for the next time someone calls > me "Andy Mabett". LOL sorry ;) Martin From info at weborganics.co.uk Thu Feb 7 16:39:47 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 7 16:40:00 2008 Subject: [uf-new] hAudio [issue] D4: rel-enclosure does not allow for links to streaming files In-Reply-To: References: <1202427238.28999.17.camel@weborganicscouk> Message-ID: <1202431187.29797.8.camel@weborganicscouk> On Fri, 2008-02-08 at 00:17 +0000, Andy Mabbett wrote: > Did you read that e-mail, and the page it cites: > > ? Yes I did http://microformats.org/wiki/rel-enclosure#Abstract needs to be changed, its wrong in my view, and needs to be in line with the Atom definition as I think this is what rel="enclosure" is trying to reproduce. http://microformats.org/wiki/rel-enclosure#Informative_References says nothing about caching files. Thanks Martin McEvoy From JOttevanger at museumoflondon.org.uk Fri Feb 8 08:40:24 2008 From: JOttevanger at museumoflondon.org.uk (Ottevanger, Jeremy) Date: Fri Feb 8 11:12:19 2008 Subject: [uf-new] workofart In-Reply-To: <47AA2C9C.9030402@psybernet.co.nz> Message-ID: Walter, sorry for the slow reply. Yes, I was just this week alerted to the proposed hItem format, and perhaps this is the one to push forward, really. If that existed it could fill a phenomenological gap (oops, I know I'm asking for trouble using words like that if you're a philosophy graduate!). hItem looks simple and pretty much ready to go and unlike workofart, where the proposer has gone AWOL, Andy and David are still very active on these lists. Perhaps they know why it seems to have gone off the boil at the end of '06? Once a uF like hItem was out there we could decide how adequate or otherwise it was for more specific kinds of things (artworks or whatever). Personally I'd be happy enough to use some un-branded POSH within hItem to do the extra stuff I want - at least part of the contents would make sense to an hItem parser. Cheers, Jeremy Jeremy Ottevanger Web Developer, Museum Systems Team Museum of London Group 46 Eagle Wharf Road London. N1 7ED Tel: 020 7410 2207 Fax: 020 7600 1058 Email: jottevanger@museumoflondon.org.uk www.museumoflondon.org.uk Museum of London is changing; our lower galleries will be closed while they undergo a major new development. Visit www.museumoflondon.org.uk to find out more. London's Burning - explore how the Great Fire of London shaped the city we see today www.museumoflondon.org.uk/londonsburning -----Original Message----- From: microformats-new-bounces@microformats.org [mailto:microformats-new-bounces@microformats.org] On Behalf Of Walter Logeman Sent: 06 February 2008 21:55 To: For discussion of new microformats. Subject: Re: [uf-new] workofart Hi Jeremy, I notice there is an hItem. Could that be the broader thing you are thinking of? What would happen if workofart was a subcategory of Item? I hope my na?ve questions are of some use! Walter From msporny at digitalbazaar.com Fri Feb 8 10:04:06 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Feb 8 11:23:53 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47A9F741.2060801@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> Message-ID: <47AC9996.1010602@digitalbazaar.com> Manu Sporny wrote: > If you are in support of this proposal, please speak up, even if it is a > "+1". If you are opposed to this proposal, please let us know the > reasoning to your opposition. Someone has e-mailed me asking that I clarify this last bit. It should have probably read: """ If you are in support of this proposal, please speak up, even if it is a "+1 for the reasons you listed in the proposal". If you are opposed to this proposal, please speak up, even if it is a "-1 for the reasons you listed in the proposal". If you have any other thoughts on the issue that have not been expressed in the discussion thread, please do a "+/- 1" and add the reasoning for your support or opposition. """ I feel that the above paragraph is more or less implied for all proposals, since that is what this community is all about, but it seems that one person doesn't think that is the case. To be fair to that person, and any others that thought I was asking something that was unfair to ask, the above paragraph states what I intended more clearly. -- manu From walter at psybernet.co.nz Fri Feb 8 16:06:09 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Fri Feb 8 16:06:22 2008 Subject: [uf-new] Re: Namespace anti-pattern and hAudio TITLE In-Reply-To: <5fjPTZ2TT3pHFw5S@pigsonthewing.org.uk> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201871231.7915.4.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201901732.3913.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <1201910646.5289.30.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A4C290.5000306@digitalbazaar.com> <2wW8IAlGqMpHFwrf@pigsonthewing.org.uk> <1201984681.15377.39.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A616A6.6090903@digitalbazaar.com> <5fjPTZ2TT3pHFw5S@pigsonthewing.org.uk> Message-ID: <47ACEE71.5030700@psybernet.co.nz> In the Proposal put forward by Manu [1] would the distinction you propose Andy be allowed? possible? encouraged? needed? Walter - Andy Mabbett wrote: >> 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: > > > > Meddle > > > > > > One of These Days > > > > 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. [1]http://microformats.org/discuss/mail/microformats-new/2008-February/001468.html From msporny at digitalbazaar.com Mon Feb 11 16:24:04 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Feb 11 16:24:08 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47A9F741.2060801@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> Message-ID: <47B0E724.8060602@digitalbazaar.com> Manu Sporny wrote: > The reasons for this change include: > > - TITLE is more semantically accurate, we are trying to describe the > title of the audio recording. > - TITLE makes more sense to Microformats newbies than FN does. > - There can be conflicts between hAudio FN and hCard FN - these > conflicts are more prevalent that hAudio TITLE and hCard TITLE > conflicts because TITLE is used less in hCard than FN. > > Oppositions to changing from FN to TITLE include: > > - It is already defined as "job title" in hCard. 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 -- manu From ellulpatrick at gmail.com Mon Feb 11 18:54:28 2008 From: ellulpatrick at gmail.com (Patrick Ellul) Date: Mon Feb 11 18:54:33 2008 Subject: [uf-new] A Microformat for Classified Ads Message-ID: Hi all, There are so so many classified ad websites around. Some of them free, some of them not, the biggest being e-bay. Wouldn't it be good if there was a standard way of marking up classified advertisements? Then all these classified websites could provide feeds of their ads in this standard format. It would then become much more easy to find what you're looking for across multiple websites using syndication and aggregators. I like how microformats emphasize the practical side of markup. I think that a microformat for classified ads could be very practical. What do you guys/girls think? Regards, Patrick www.patrickellul.com From brian.suda at gmail.com Mon Feb 11 23:33:02 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Feb 11 23:33:04 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B0E724.8060602@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> Message-ID: <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> 2008/2/12, Manu Sporny : > 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. -brian -- brian suda http://suda.co.uk From bhawkeslewis at googlemail.com Tue Feb 12 00:01:34 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Tue Feb 12 00:01:40 2008 Subject: [uf-new] A Microformat for Classified Ads In-Reply-To: References: Message-ID: <47B1525E.8000805@googlemail.com> Patrick Ellul wrote: > There are so so many classified ad websites around. Some of them free, > some of them not, the biggest being e-bay. > > Wouldn't it be good if there was a standard way of marking up > classified advertisements? A microformat for this has already been proposed: http://microformats.org/wiki/hlisting-proposal -- Benjamin Hawkes-Lewis From andy at pigsonthewing.org.uk Tue Feb 12 01:14:39 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 12 01:16:00 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> Message-ID: In message <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com>, Brian Suda writes >2008/2/12, Manu Sporny : >> 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 From lee.jordan at gmail.com Tue Feb 12 03:58:12 2008 From: lee.jordan at gmail.com (Lee Jordan) Date: Tue Feb 12 03:58:19 2008 Subject: [uf-new] hRecipe (repost from microformats-dev) Message-ID: Hi Folks, I've marked up an example recipe with a possible hRecipe draft. Example: http://www.leejordan.org.uk/microformats/hrecipe/ Based on RecipeML from the mF wiki. Up for discussion, there has been some discussion on the dev list already, but hope it helps bash out a draft for hrecipe, something I added in was dietary requirements as I didn't see a way of marking that up currently. The measure microformat needs some more thought I think, not sure if the abbr pattern is backwards to what we need here? But extra spans is messy. I did find it useful when playing with the DOM to go right to the measures marked up with a class name. I thought the dev list was the first place to discuss development of microformats, lol, sorry guys. Regards, Lee -- HTML | CSS | Javascript http://www.leejordan.org.uk From info at weborganics.co.uk Tue Feb 12 04:59:15 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 12 04:59:23 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> Message-ID: <1202821155.12382.13.camel@weborganicscouk> On Tue, 2008-02-12 at 07:33 +0000, Brian Suda wrote: > --- 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. Which are?... > > 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. > > I would kindly ask that you rollback your changes until this can be > discussed further 4 people in a community is not consensus. How would YOU address this issue, haudio needs a "title" 94% of our use case examples say so, what is the point of "the process" if you cant work to it? A little guidance would be nice, instead of just saying this is wrong please offer a resolution, some guidance even? Thanks Martin From andy at pigsonthewing.org.uk Tue Feb 12 05:21:00 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Feb 12 05:21:03 2008 Subject: [uf-new] Governance and process (Was: PROPOSAL: Replace hAudio FN with TITLE) In-Reply-To: <1202821155.12382.13.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> Message-ID: <45322.80.249.57.38.1202822460.squirrel@www.gradwell.com> On Tue, February 12, 2008 12:59, Martin McEvoy wrote: > On Tue, 2008-02-12 at 07:33 +0000, 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 ** From brian.suda at gmail.com Tue Feb 12 05:37:57 2008 From: brian.suda at gmail.com (Brian Suda) Date: Tue Feb 12 05:38:01 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1202821155.12382.13.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> Message-ID: <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> 2008/2/12, Martin McEvoy : > On Tue, 2008-02-12 at 07:33 +0000, Brian Suda wrote: > > --- 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. --- i volunteer with the community and have not have much time in the last 6 days to properly give it the thought and discussions it deserves. I would rather send a single email, then several continual ones. Everyone benefits from a long hard thing rather than "shooting from the hip" sorts of emails. > as usual in this community If someone sees something they DON'T like > they just ignore it and hope it will go away. --- i would disagree. There are several reasons people do not answer. Maybe it was covered by someone else, maybe they are busy, maybe they personally are not interested. > 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. --- this is certainly not the first time this discussion has come-up. I know i have personally had a long phone call with Manu about hAudio and several aspects of it. I would and do not jump up and down for every change, only ones which i feel are bad choices. People are pretty fatigued from having this debate over and over again without gaining any ground. The alternatives which have been discussed before are, do nothing and use FN or use something like audio-title. Neither of which break existing formats. Why TITLE was propose and (i feel) rushed through with 4 +1?s is what i am not happy about - that is not community. > > I would kindly ask that you rollback your changes until this can be > > discussed further 4 people in a community is not consensus. > > How would YOU address this issue, haudio needs a "title" 94% of our use > case examples say so, what is the point of "the process" if you cant > work to it? --- i believe it was solved with FN. My biggest concern is that fact that by usurping the term TITLE you are breaking all the previous hCards. I?m not saying we don?t NEED a term to represent the title of a work, just don?t re-define terms that already have meaning. > A little guidance would be nice, instead of just saying this is wrong > please offer a resolution, some guidance even? --- i am very close to the original hCard work, so i was not trying to involve myself early in this discussion and sway the thought process. I purposely (what i thought was the impartial thing to do) let some discussion move forward without my "interference". That discussion was a few "+1"s and and an re-explanation of the original question. That isn't a discussion. The original logic in the question is flawed. The first portion is correct > FN in hCard means "the formatted name of a person or orgainzation". > FN in hAudio currently means "the formatted name of an audio recording". It is the next portion which is misleading and wrong: > TITLE in hCard means "job title" > TITLE in hAudio means "audio recording title" It should be TITLE in hCard means the Job Title of the person or organization TITLE in hAudio means the Job Title of the audio recording The correct logic is completely fine, but that is not what the proposal is trying to do. It is attempting to undo the definition of TITLE across all microformats, which has been discussed before and rejected in such formats as the citation. Due to lack of any sort of discussion, decent or any massive support, i was not expecting to see such an important edit to the wiki page. i?m not against haudio or having some sort of title property for the format, what i do not like is attempting to break any format with any property that has already been defined. I believe this issue is already solved with FN, (IMHO) there is no need for this proposal to use TITLE. So now you have my -1. -brian -- brian suda http://suda.co.uk From info at weborganics.co.uk Tue Feb 12 07:31:34 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 12 07:32:08 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> Message-ID: <1202830294.13351.27.camel@weborganicscouk> On Tue, 2008-02-12 at 13:37 +0000, Brian Suda wrote: > 2008/2/12, Martin McEvoy : > > On Tue, 2008-02-12 at 07:33 +0000, Brian Suda wrote: > > > --- 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. > > --- i volunteer with the community and have not have much time in the > last 6 days to properly give it the thought and discussions it > deserves. I would rather send a single email, then several continual > ones. Everyone benefits from a long hard thing rather than "shooting > from the hip" sorts of emails. We all volunteer our time here, I apologize if my email seemed like it was "shooting from the hip" it was never intended that way. > > > as usual in this community If someone sees something they DON'T like > > they just ignore it and hope it will go away. > > --- i would disagree. There are several reasons people do not answer. > Maybe it was covered by someone else, maybe they are busy, maybe they > personally are not interested. fair comment... > > > 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. > > --- this is certainly not the first time this discussion has come-up. > I know i have personally had a long phone call with Manu about hAudio > and several aspects of it. > > I would and do not jump up and down for every change, only ones which > i feel are bad choices. People are pretty fatigued from having this > debate over and over again without gaining any ground. which means it needs to be addressed not ignored as it has. > > The alternatives which have been discussed before are, do nothing and > use FN or use something like audio-title. Neither of which break > existing formats. Why TITLE was propose and (i feel) rushed through > with 4 +1?s is what i am not happy about - that is not community. > > > > I would kindly ask that you rollback your changes until this can be > > > discussed further 4 people in a community is not consensus. > > > > How would YOU address this issue, haudio needs a "title" 94% of our use > > case examples say so, what is the point of "the process" if you cant > > work to it? > > --- i believe it was solved with FN. I don't think it was "solved" we settled for second best. > My biggest concern is that fact > that by usurping the term TITLE you are breaking all the previous > hCards. I don't understand "how" it breaks hCard? > > I?m not saying we don?t NEED a term to represent the title of a work, > just don?t re-define terms that already have meaning. Terms that SHOULD have been thought of more before they became a specification, hcard hogging the class name "title" seems a little short sighted to me particularly when the word title has a vast amount of OTHER meanings none of which have anything to do with "job-titles" > > > A little guidance would be nice, instead of just saying this is wrong > > please offer a resolution, some guidance even? > > --- i am very close to the original hCard work, so i was not trying to > involve myself early in this discussion and sway the thought process. I think your thoughts would have been warmly received being on of the "respected" members of our community... > I purposely (what i thought was the impartial thing to do) let some > discussion move forward without my "interference". That discussion was > a few "+1"s and and an re-explanation of the original question. That > isn't a discussion. No It was ignored on the whole because of the hcard issues which is too much for a lot of people to think about so it gets left to the ones who can or want to "deal" with the question... > > The original logic in the question is flawed. The first portion is correct > > > FN in hCard means "the formatted name of a person or orgainzation". > > FN in hAudio currently means "the formatted name of an audio recording". > > It is the next portion which is misleading and wrong: > > > TITLE in hCard means "job title" I dont think that is an accurate description, simply the "function of the object" would be more correct and "generic" and not *break* anything > > TITLE in hAudio means "audio recording title" Consider this example Beethoven's Turkish March the "function of the object", the music that gets played through your speakers of headphones is a "Turkish March" > > It should be > TITLE in hCard means the Job Title of the person or organization > TITLE in hAudio means the Job Title of the audio recording > > The correct logic is completely fine, but that is not what the > proposal is trying to do. It is attempting to undo the definition of > TITLE across all microformats, which has been discussed before and > rejected in such formats as the citation. No I disagree there "should" be a serious discussion about changing the meaning of "title" in hcard (just a little) in order to allow "title" to be used in other uf's in a more accurate way, I very much doubt this would happen though do you? > > Due to lack of any sort of discussion, decent or any massive support, > i was not expecting to see such an important edit to the wiki page. > i?m not against haudio or having some sort of title property for the > format, what i do not like is attempting to break any format with any > property that has already been defined. I believe this issue is > already solved with FN, (IMHO) there is no need for this proposal to > use TITLE. > > So now you have my -1. Thank You 4 -1 > > -brian > From msporny at digitalbazaar.com Tue Feb 12 14:48:46 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 12 14:48:53 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> Message-ID: <47B2224E.5080005@digitalbazaar.com> Brian Suda wrote: > 2008/2/12, Martin McEvoy : >> On Tue, 2008-02-12 at 07:33 +0000, Brian Suda wrote: >>> --- 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. > > --- i volunteer with the community and have not have much time in the > last 6 days to properly give it the thought and discussions it > deserves. To say that this discussion has only been going on for 6 days is simply not true. This discussion has been here since June 2007 (some would say even earlier than that), here's the start of this discussion: http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html It is misleading to state that there hasn't been discussion on this topic. > --- i would disagree. There are several reasons people do not answer. > Maybe it was covered by someone else, maybe they are busy, maybe they > personally are not interested. Let's not assume anything about the people that do or do not answer as anybody could mis-use intentions of those that stay silent to bolster their position. Rather, let's look at the people that weighed in on the issue. > I would and do not jump up and down for every change, only ones which > i feel are bad choices. People are pretty fatigued from having this > debate over and over again without gaining any ground. And I agree with Martin - let's deal with the debate rather than ignore it, like we did in June 2007. > --- i believe it was solved with FN. No, as Martin said, we settled for second best. > My biggest concern is that fact > that by usurping the term TITLE you are breaking all the previous > hCards. You stated this back in June, you stated it again this month, and I asserted that it doesn't break any hCards. How does it break hCard? How does it break Operator? How does this decision have any impact on any hCard that is out in the field right now? > I?m not saying we don?t NEED a term to represent the title of a work, > just don?t re-define terms that already have meaning. How about don't re-define terms to mean something different from the English language, which is what hCard did. If you're defending that decision, please tell us why TITLE should have a meaning that is different than what is published in every English dictionary? > The original logic in the question is flawed. The first portion is correct > >> FN in hCard means "the formatted name of a person or orgainzation". >> FN in hAudio currently means "the formatted name of an audio recording". > > It is the next portion which is misleading and wrong: > >> TITLE in hCard means "job title" >> TITLE in hAudio means "audio recording title" You missed the point, then. The point was this: FN in hCard means "X of a person or organization" FN in hAudio means "X of an audio recording" See the parallel? X changes from hCard to hAudio, but the tail of the statement stays the same. Where X is "job" in hCard, X is "audio recording" in hAudio. If we want to be consistent, we MUST be able to do the same for TITLE. TITLE in hCard means "X title" TITLE in hAudio means "X title" Where X is "job" in hCard, and where X is "audio recording" in hAudio. If we argue for anything else, we are being inconsistent. If we are inconsistent, it will be much harder for people to understand Microformats and take them seriously. > It should be > TITLE in hCard means the Job Title of the person or organization > TITLE in hAudio means the Job Title of the audio recording Why should it be that? Because you have decided that TITLE should not follow the standard English definition and instead follow the definition that is put forth in RFC 2426? Furthermore, anybody that uses Microformats should be banned from using the English definition of TITLE? > The correct logic is completely fine, but that is not what the > proposal is trying to do. It is attempting to undo the definition of > TITLE across all microformats, which has been discussed before and > rejected in such formats as the citation. Then it should be easy to outline the logic behind why it was rejected for citation. I'm surprised nobody else on this list has referenced that discussion if it was pertinent. > i?m not against haudio or having some sort of title property for the > format, what i do not like is attempting to break any format with any > property that has already been defined. I believe this issue is > already solved with FN, (IMHO) there is no need for this proposal to > use TITLE. There is quite a bit of FUD being thrown around here. You're asserting that this will "break hCard", but have not provided any proof to back up that claim. Please, back this statement up with something. All of us are listening. You're claiming that the issue is already solved when the primary editors of hAudio are claiming that it most definitely has not been. > So now you have my -1. Thank you, noted. Four shows of support for TITLE in hAudio, one against. Note that I do not mean any disrespect with this e-mail. If the tone comes off as that, it is entirely unintended. I am pushing the issue because you have not provided enough evidence to support your major points of contention. -- manu From scott at makedatamakesense.com Tue Feb 12 15:26:34 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Feb 12 15:26:41 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B2224E.5080005@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> Message-ID: <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> 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. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Tue Feb 12 15:30:49 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 12 15:30:51 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> Message-ID: <47B22C29.7040902@digitalbazaar.com> Scott Reynen wrote: > 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. That is a very wise interjection... I agree, we should be asking "is it safe to say TITLE means title?" -- manu From info at weborganics.co.uk Tue Feb 12 17:32:20 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue Feb 12 17:32:27 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B22C29.7040902@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> Message-ID: <1202866340.4573.16.camel@weborganicscouk> 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" A principle that I have always liked is Occam's Razor it says: "For a given set of observations or data, there is always an infinite number of possible models explaining those same data." it goes on further to explain what this means in layman's terms: "For example, through two data points in a diagram you can always draw a straight line, and induce that all further observations will lie on that line. However, you could also draw an infinite variety of the most complicated curves passing through those same two points, and these curves would fit the empirical data just as well. Only Occam's razor would in this case guide you in choosing the "straight" (i.e. linear) relation as best candidate model" http://pespmc1.vub.ac.be/OCCAMRAZ.html If we applied this principle to "title" which has many different meaning's as we all know the definition would simply be "The title of the object the hCard represents" which could then be re-used as simply "The title of the object" I dont think this will "break" hcard in any way It would enhance it further in my mind. I may be just rambling again does this make any sense to any one else? Thanks Martin McEvoy From ryan at theryanking.com Tue Feb 12 17:46:19 2008 From: ryan at theryanking.com (Ryan King) Date: Tue Feb 12 17:46:26 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1202866340.4573.16.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> Message-ID: <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> On Feb 12, 2008, at 5:32 PM, Martin McEvoy wrote: > 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" I'd like to reiterate scott's point about avoiding polarizing language. Decisions made about hCard (4 years ago) can't easily be undone, so making remarks about their merits are counter-productive. > ... > > If we applied this principle to "title" which has many different > meaning's as we all know the definition would simply be "The title of > the object the hCard represents" which could then be re-used as simply > "The title of the object" I dont think this will "break" hcard in any > way It would enhance it further in my mind. In the interest of precision, the hcard definition we're talking about comes from vCard, section 3.5.1: > Type purpose: To specify the job title, functional position or > function of the object the vCard represents. and > Type special notes: This type is based on the X.520 Title > attribute. > > Type example: > > TITLE:Director\, Research and Development I can't seem to find any source for the semantics of X.520's title. -ryan From msporny at digitalbazaar.com Tue Feb 12 19:13:45 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 12 19:13:49 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> Message-ID: <47B26069.2000009@digitalbazaar.com> Ryan King wrote: >> Type special notes: This type is based on the X.520 Title attribute. >> >> Type example: >> >> TITLE:Director\, Research and Development > > I can't seem to find any source for the semantics of X.520's title. For those that are unfamiliar with X.520, it is an: """ ... International Standard, together with other International Standards, ... to facilitate the interconnection of information processing systems to provide directory services. A set of such systems, together with the directory information which they hold, can be viewed as an integrated whole, called the Directory. The information held by the Directory, collectively known as the Directory Information Base (DIB), is typically used to facilitate communication between, with or about objects such as application entities, people, terminals, and distribution lists. """[1] The semantics of X.520 TITLE attribute, from "ITU-T Rec. X.520, 1993E"[1]: """ 5.4.3 Title The Title attribute type specifies the designated position or function of the object within an organization. An attribute value for Title is a string. Example: T = ?Manager, Distributed Applications? title ATTRIBUTE ::= { SUBTYPE OF name WITH SYNTAX DirectoryString {ub-title} ID id-at-title } """ and since the above references the X.520 NAME attribute[1]: """ 5.2.1 Name The Name attribute type is the attribute supertype from which string attribute types typically used for naming may be formed. name ATTRIBUTE ::= { WITH SYNTAX DirectoryString { ub-name } EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID id-at-name } """ The semantics of all of X.520 are clearly in the realm of directory services, which deal with "application entities, people, terminals, and distribution lists". Let's not forget that this was back in 1993... waaay before they invented the Internet, citations and music. =P -- manu [1]http://64.233.169.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps+%2B%22X.520%22+specification+%2BTITLE&hl=en&ct=clnk&cd=3&gl=us&client=iceweasel-a From andy at pigsonthewing.org.uk Wed Feb 13 01:14:50 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 13 01:16:24 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> Message-ID: In message <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com>, Scott Reynen 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 From andy at pigsonthewing.org.uk Wed Feb 13 01:20:26 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Feb 13 01:21:28 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1202866340.4573.16.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> Message-ID: In message <1202866340.4573.16.camel@weborganicscouk>, Martin McEvoy 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 From info at weborganics.co.uk Wed Feb 13 05:22:05 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed Feb 13 05:22:18 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> Message-ID: <1202908925.7271.66.camel@weborganicscouk> Hello Ryan On Tue, 2008-02-12 at 17:46 -0800, Ryan King wrote: > On Feb 12, 2008, at 5:32 PM, Martin McEvoy wrote: > > 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" > > I'd like to reiterate scott's point about avoiding polarizing > language. Decisions made about hCard (4 years ago) can't easily be > undone, I realize this fact.. > so making remarks about their merits are counter-productive. This is what we do as a community isnt it? we tell people how badly they are marking up their websites, inform people of anti-patters, discourage any talk of namespaces because they have failed? we must therefore be able to show integrity and consistency and be able to criticize our own behavior. (this is not an attack by the way just an observation) > > > ... > > > > If we applied this principle to "title" which has many different > > meaning's as we all know the definition would simply be "The title of > > the object the hCard represents" which could then be re-used as simply > > "The title of the object" I dont think this will "break" hcard in any > > way It would enhance it further in my mind. > > In the interest of precision, the hcard definition we're talking about > comes from vCard, section 3.5.1: > > Type purpose: To specify the job title, functional position or > > function of the object the vCard represents. can I just think this bit through with you its the end bit that interests me...*OR* "function of the object the vCard represents" If we are referring to "objects" not people they do not have "job-titles" so we must be referring to the functional title of of the object eg: People => Vice President, General manager, => their functional titles are Job titles or Corporate titles, Property => Allodial, Freehold, => their functional tiles are Land Titles. Books => The Lord Of the Rings, Treasure Island => their functional tiles are Book Titles. Music => The White Album, Point of Know Return => their functional tiles are Album Titles. Paintings => The Path of Life, Stuppach Madonna => their functional titles are Art titles. If you applied Occam's Razor to the above examples they all come under a general term *title* hcard does not need to change, we are not RE Defining anything "title" is used correctly as a "job title" In haudio we are proposing that "title" means "audio title" again perfectly valid when referring to the "object" not a person. The Only Minor change/enhancement that would be made is here: http://microformats.org/wiki/existing-classes "Title hCard Job title or functional position of the object." would change to.. "Title hCard Job title or functional position. hAudio Audio title. Generally the title of the object" There is nothing earth shattering about that is there? HOW exacly would that *break* the definition of hcard? I am sorry if i am misunderstanding anything, Please take the time to explain to me anything that is incorrect or wrong?. > > and > > Type special notes: This type is based on the X.520 Title > > attribute. > > > > Type example: > > > > TITLE:Director\, Research and Development > > I can't seem to find any source for the semantics of X.520's title. > -ryan Thanks Martin McEvoy From scott at makedatamakesense.com Wed Feb 13 12:29:28 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Feb 13 12:29:33 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1202908925.7271.66.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <47B0E724.8060602@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> Message-ID: On Feb 13, 2008, at 6:22 AM, Martin McEvoy wrote: > This is what we do as a community isnt it? we tell people how badly > they > are marking up their websites, inform people of anti-patters, > discourage > any talk of namespaces because they have failed? I think a key factor in microformats' success is that we generally forego the standard approach to promoting better semantics, i.e. chastising bad markup, and instead focus on establishing clear benefits around good markup. So I'd like to see that same approach applied more to examinations of our own work, to make such examinations more productive. I also think it would be good for us to rewrite all anti-patterns as proactive patterns, as people are more likely to follow suggestions to do something right than suggestions to avoid doing something wrong. -- Scott Reynen MakeDataMakeSense.com From brian.suda at gmail.com Thu Feb 14 00:29:59 2008 From: brian.suda at gmail.com (Brian Suda) Date: Thu Feb 14 00:30:05 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1202908925.7271.66.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> Message-ID: <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> 2008/2/13, Martin McEvoy : > If we are referring to "objects" not people they do not have > "job-titles" so we must be referring to the functional title of of the > object eg: --- I don?t think we can say MUST be referring too. We do not know the intent of the vCard authors. > hcard does not need to change, we are not RE Defining anything "title" > is used correctly as a "job title" --- yes we would be effecting the definition TITLE in hCard. When there is an hCard with a title nested inside and hAudio as a contributor or other, TITLE now has two different meaning. Which MEANING of TITLE should i use? Is this instance of TITLE meant for the hCard or for the hAudio? > In haudio we are proposing that "title" means "audio title" again > perfectly valid when referring to the "object" not a person. > > "Title hCard Job title or functional position of the object." > > would change to.. > > "Title hCard Job title or functional position. > hAudio Audio title. > Generally the title of the object" > > There is nothing earth shattering about that is there? HOW exacly would > that *break* the definition of hcard? Now you have two DIFFERENT meaning for the same term. When you have overlapping microformats, there is no way to know which MEANING to use. Terms that have the SAME meaning are not effected because the property used can overlap and not have any disambiguation. > I am sorry if i am misunderstanding anything, Please take the time to > explain to me anything that is incorrect or wrong?. --- this does seem to be coming up more and more, so i began to look around the wiki to see if there was already a page. i did find this: http://microformats.org/wiki/naming-principles There is a section for anti-patterns but it is blank. Rather than start a new page, i think this might be the best place to document why giving a property two different meanings is a bad idea, just like giving two different properties the same meaning. We could also start a separate page, and probably should separate discussion thread about this topic. This is and will be a common problem. For instance, hAudio makes use of the term TRACK. One argument about TITLE is that it is not the "Common English definition" therefore we should change it. The meaning of TRACK in hAudio is the 14th most common definition in the English language[1]. Now it would be silly to stop hAudio from using that. In the future, if hWine or hModelTrainEnthusist ever surfaces, they will have this same argument. TRACK doesn't mean what it should mean - just like we have TITLE does not mean what it should mean! I would say that hAudio was here first, they used the term TRACK and defined its meaning for microformats, just as TITLE has been defined by vCard. Trying to point to the ever-changing English language as a reference point, is probably not a good idea. To have TRACK and TITLE and XYZ have multiple meaning at the same time, causes all sorts of semantic problems when you begin to overlap the trees. How do you know which meaning to choose? This inability to determine the exact meaning is the core of the problem. I will try to get some information up on the wiki, if someone wants to create stubs or FAQs, i (or someone else) will help document and answer them. The mailing list is not the best place to reference our answers when these questions come-up again. -brian [1] - http://dictionary.reference.com/browse/track -- brian suda http://suda.co.uk From info at weborganics.co.uk Thu Feb 14 04:32:08 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Feb 14 04:32:23 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> Message-ID: <1202992329.15688.101.camel@weborganicscouk> On Thu, 2008-02-14 at 08:29 +0000, Brian Suda wrote: > 2008/2/13, Martin McEvoy : > > If we are referring to "objects" not people they do not have > > "job-titles" so we must be referring to the functional title of of the > > object eg: > > --- I don?t think we can say MUST be referring too. We do not know the > intent of the vCard authors. You are correct "We do not know the intent of the vCard authors" but we do know where "title" gets its semantics from it is cited in the vcard "This type is based on the X.520 Title attribute". X.520 5.4.3 Title The Title attribute type specifies the designated position or function of the object within an organization. An attribute value for Title is a string. www.dante.net/np/ds/osi/9594-6-X.520.A4.ps or http://tinyurl.com/27yb33 vCard refers to a person "job title", X.520 says nothing about a person just and "object" however the semantics ARE similar: "function of the object" in hcard is a Job title. "function of the object" in haudio is an Audio title. The truth is we are ALL missing the point hAudio does NOT re-use "title" from hcard, because hcard was NOT built using "the process" it would break our data model. hAudio has however vigorously used "the microformats process" to determine its meaning these are based upon "current usage" Thus It would be IMPOSSIBLE for haudio to cite a source based upon a single definition made back in 1993. > > > hcard does not need to change, we are not RE Defining anything "title" > > is used correctly as a "job title" > > --- yes we would be effecting the definition TITLE in hCard. When > there is an hCard with a title nested inside and hAudio as a > contributor or other, TITLE now has two different meaning. Which > MEANING of TITLE should i use? Is this instance of TITLE meant for the > hCard or for the hAudio? ... > > In haudio we are proposing that "title" means "audio title" again > > perfectly valid when referring to the "object" not a person. > > > > "Title hCard Job title or functional position of the object." > > > > would change to.. > > > > "Title hCard Job title or functional position. > > hAudio Audio title. > > Generally the title of the object" > > > > There is nothing earth shattering about that is there? HOW exacly would > > that *break* the definition of hcard? > > Now you have two DIFFERENT meaning for the same term. When you have > overlapping microformats, there is no way to know which MEANING to > use. Terms that have the SAME meaning are not effected because the > property used can overlap and not have any disambiguation. ... > > > I am sorry if i am misunderstanding anything, Please take the time to > > explain to me anything that is incorrect or wrong?. > > --- this does seem to be coming up more and more, so i began to look > around the wiki to see if there was already a page. i did find this: > > http://microformats.org/wiki/naming-principles > > There is a section for anti-patterns but it is blank. Rather than > start a new page, i think this might be the best place to document why > giving a property two different meanings is a bad idea, just like > giving two different properties the same meaning. > > We could also start a separate page, and probably should separate > discussion thread about this topic. ... > > This is and will be a common problem. For instance, hAudio makes use > of the term TRACK. One argument about TITLE is that it is not the > "Common English definition" therefore we should change it. The meaning > of TRACK in hAudio is the 14th most common definition in the English > language[1]. Now it would be silly to stop hAudio from using that. In > the future, if hWine or hModelTrainEnthusist ever surfaces, they will > have this same argument. TRACK doesn't mean what it should mean - just > like we have TITLE does not mean what it should mean! > > I would say that hAudio was here first, they used the term TRACK and > defined its meaning for microformats, just as TITLE has been defined > by vCard. Trying to point to the ever-changing English language as a > reference point, is probably not a good idea. Quite some time ago we chose "item" INSTEAD if "track" because of the exact same reasons as you noted... > > To have TRACK and TITLE and XYZ have multiple meaning at the same > time, causes all sorts of semantic problems when you begin to overlap > the trees. How do you know which meaning to choose? I read somewhere quite recently that nested hcards are not allowed to read information from their parents... "When parsing an hCard, if a parser finds a nested hCard, it should treat that hCard as its own object, and treat properties of the nested hCard as only belonging to the nested hCard, not the containing hCard." http://microformats.org/wiki?title=hcard-parsing&diff=next&oldid=25563 If a hcard DID occur within an hAudio I presume that it will be treated as its own object or is that not what it means?. Anyway I wouldn't worry Not many Microfomats built using the process actually make it to Specification... I think we should start a new discussion about "grandfathering" some microformats or at least see if they go through the process and bring them up to date with current practices what do you think? > > This inability to determine the exact meaning is the core of the > problem. I will try to get some information up on the wiki, if someone > wants to create stubs or FAQs, i (or someone else) will help document > and answer them. > > The mailing list is not the best place to reference our answers when > these questions come-up again. > > -brian > > [1] - http://dictionary.reference.com/browse/track .... Thanks Martin McEvoy > From walter at psybernet.co.nz Thu Feb 14 04:34:11 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Thu Feb 14 04:34:20 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> Message-ID: <47B43543.2080009@psybernet.co.nz> Brian Suda wrote: > To have TRACK and TITLE and XYZ have multiple meaning at the same > time, causes all sorts of semantic problems when you begin to overlap > the trees. How do you know which meaning to choose? Maybe one needs to take care in how to combine Microformats? Is there anything wrong with the following? (I really don't know!) John Lennon Composer, Writer, Performer Imagine Walter From davidjanes at blogmatrix.com Thu Feb 14 05:12:36 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Feb 14 05:12:38 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B43543.2080009@psybernet.co.nz> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B43543.2080009@psybernet.co.nz> Message-ID: <21e523c20802140512r6b0493ear795050873c29666b@mail.gmail.com> Can we make a "microformats-old" group to endlessly discuss things that were settled more than 12 months ago? -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From andy at pigsonthewing.org.uk Thu Feb 14 06:21:36 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Feb 14 06:21:39 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e523c20802140512r6b0493ear795050873c29666b@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B43543.2080009@psybernet.co.nz> <21e523c20802140512r6b0493ear795050873c29666b@mail.gmail.com> Message-ID: <53599.80.249.57.38.1202998896.squirrel@www.gradwell.com> 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 ** From msporny at digitalbazaar.com Thu Feb 14 11:55:21 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Feb 14 11:55:27 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> Message-ID: <47B49CA9.4030209@digitalbazaar.com> Brian Suda wrote: >> hcard does not need to change, we are not RE Defining anything "title" >> is used correctly as a "job title" > > --- yes we would be effecting the definition TITLE in hCard. When > there is an hCard with a title nested inside and hAudio as a > contributor or other, TITLE now has two different meaning. Which > MEANING of TITLE should i use? Is this instance of TITLE meant for the > hCard or for the hAudio? You could use the same argument for arguing against FN in hAudio. "When there is an hCard with a FN nested inside an hAudio as the name, FN now has two different meanings. Which MEANING of FN should I use? Is this instance of FN meant for the hCard or for the hAudio?" This is a limitation of Microformats - we don't do object opacity by default. Although, even that comes into question because of the recent hCard edit that Tantek made. This statement makes it seem like you're missing the point - FN has a slightly different meaning between hCard and hAudio already, are you arguing for or against that? If you are arguing for keeping FN in hAudio, that's a slippery slope, as CATEGORY has the same issue in hCard and hCalendar: CATEGORY in hCard means "person or organization category" CATEGORY in hCalendar means "event category" Those are two different meanings. Microformats have more examples of this occurring - if you'd like more examples, I'd be happy to give them. I'm fine with this - I would guess that most are fine with this because it has happened time and time again in the Microformats specs. >> In haudio we are proposing that "title" means "audio title" again >> perfectly valid when referring to the "object" not a person. >> >> "Title hCard Job title or functional position of the object." >> >> would change to.. >> >> "Title hCard Job title or functional position. >> hAudio Audio title. >> Generally the title of the object" >> >> There is nothing earth shattering about that is there? HOW exacly would >> that *break* the definition of hcard? > > Now you have two DIFFERENT meaning for the same term. When you have > overlapping microformats, there is no way to know which MEANING to > use. Terms that have the SAME meaning are not effected because the > property used can overlap and not have any disambiguation. No, when you have overlapping Microformats that share the same term, you have issues, period. This holds for FN and it would also hold for TITLE. > There is a section for anti-patterns but it is blank. Rather than > start a new page, i think this might be the best place to document why > giving a property two different meanings is a bad idea, just like > giving two different properties the same meaning. You keep saying that we're giving the property two different meanings... would you want us to extend that to every Microformat, if so - we should all have issues with CATEGORY, and ITEM. > We could also start a separate page, and probably should separate > discussion thread about this topic. > > This is and will be a common problem. Yes, it is and will ALWAYS be a common problem because this community made the decision to not use namespaces. That's fine by me, but that comes with a trade-off and that trade-off is ambiguity. It should be quite apparent to everyone at this point that this community spends more time arguing about which word to use than creating new standards. These arguments occur because we keep trying to re-define words that have multiple meanings in the English language to have only one meaning. > For instance, hAudio makes use of the term TRACK. No, it doesn't - hAudio doesn't use TRACK at all. > One argument about TITLE is that it is not the > "Common English definition" therefore we should change it. The meaning > of TRACK in hAudio is the 14th most common definition in the English > language[1]. Now it would be silly to stop hAudio from using that. In > the future, if hWine or hModelTrainEnthusist ever surfaces, they will > have this same argument. TRACK doesn't mean what it should mean - just > like we have TITLE does not mean what it should mean! I'd rather not have a philosophical debate on a theoretical future Microformat - the discussion will lead nowhere. Let's stick to the problem at hand: TITLE in hAudio and hCard and the implications of having TITLE mean what it does in the English language. Just for the record: I would hate if hAudio stopped the hModelTrainEnthusiast Microformat from picking the correct name because we had incorrectly re-defined TRACK to mean something narrower than the definition in the English language. As for TRACK in hWine, I think you mean TRACT (as in of land). > I would say that hAudio was here first, they used the term TRACK and > defined its meaning for microformats, just as TITLE has been defined > by vCard. Trying to point to the ever-changing English language as a > reference point, is probably not a good idea. When was the last time that the meaning of TITLE was changed in the English language? > To have TRACK and TITLE and XYZ have multiple meaning at the same > time, causes all sorts of semantic problems when you begin to overlap > the trees. How do you know which meaning to choose? Show me a place where this happens, and I'll show you that FN has the same issue. I don't understand what you are proposing in changing? > This inability to determine the exact meaning is the core of the > problem. I agree wholeheartedly. That is at the core of why we get into these long drawn out discussions. Don't you see - it's at the core of Microformats - that's the weakness of not using namespaces and having document processing rules that ignore HTML scope. This issue isn't going anywhere because it is at the core of what we do. We're not trying to boil the oceans here - there will always be corner cases that won't fit into Microformats... that's why we have the 80/20 rule. You still haven't addressed what is being broken? What will stop functioning as a result of us using TITLE in both hCard and hAudio? -- manu From tjameswhite at gmail.com Thu Feb 14 17:20:12 2008 From: tjameswhite at gmail.com (Tim White) Date: Thu Feb 14 17:20:15 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B49CA9.4030209@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> Message-ID: On Thu, Feb 14, 2008 at 2:55 PM, Manu Sporny wrote: .... > We're not trying to boil the oceans here - there will always be corner > cases that won't fit into Microformats... that's why we have the 80/20 rule. > > You still haven't addressed what is being broken? What will stop > functioning as a result of us using TITLE in both hCard and hAudio? > > -- manu This is the same problem that the citation efforts ran across. Following the microformats process, I helped collect *existing* examples of how books are marked up on the web. If you look (and I know Brian helped formulate this) at the results, TITLE gets used quite often. [1] The same argument was made back then: "hCard came first so you can't reuse TITLE." What if citation or hAudio came first? Would the same argument be made? Would hCard have been prevented from using TITLE? Somehow I doubt it (yes, complete supposition on my part, made only because hCard is based on vCard which uses TITLE and that is the prior art issue that is holding this up). We need to resolve this because, as Manu points out, it will continue to happen. I don't write parsers or pretend to know how to, but... (yes, here I go again) it seems to me that if you have this:
Name of Album
Bob, Composer
the parser should be able to determine that the "title" contained directly inside "haudio" is an album name and that the "title" nested inside "vcard" inside "haudio" belongs to the vcard and not haudio. I'm sure cases exist (or could exist) where it won't be this simple, but shouldn't this cover the 80%? Certainly if we agree that microformats are a way to extend meaning to content, TITLE is much more meaningful (and easier for authors to adopt) than FN. I'm tired and sick, so I hope this makes sense. Tim [1] http://microformats.org/wiki/citation-examples-markup From walter at psybernet.co.nz Thu Feb 14 17:55:04 2008 From: walter at psybernet.co.nz (Walter Logeman) Date: Thu Feb 14 18:15:16 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B49CA9.4030209@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> Message-ID: <47B4F0F8.6060904@psybernet.co.nz> The question concerning FN & TITLE (and FN as well) has an underlying more general question. Are Microformats broken when terms are repeated across different formats? How is this answered? By a rule? Is there one? Should there be one? And what is (would be) the reasoning behind such a rule? Here is what I have gathered from the discussion: The main reason to allow repeating terms is proximity to natural use of language, human friendly - that is a Microformat principle. The main reason for not repeating terms is that it breaks Microformats. Machine friendly. These are both compelling principles. As I understand it that guidelines would favour the people first approach. However the question here is not one of priorities, it is more that Microformats would not work at all then they would not be people friendly either! ~ What does "work" mean? What does "broken" mean? At present my vCards seems to work for Outlook, they do not work as well in "Tail Export" the Firefox add-on. In either approach regarding the repetition (or not) of terms, the guidelines for developing parsers need to make it clear how the format should be parsed. Are there such guidelines? If there are such guidelines or principles (even if they a currently contravened) they would read either: Any term used in Microformats is unique and can be correctly rendered into a specific use. For example: The term "title" always refers to the job title of a person. OR Terms used in Microformats can be correctly rendered into a specific use by reference to the class they are nested in. For example: The term "title" refers to the job title of a person in vCard, and to the audio recording title in hAudio. ~ Does my summary make sense? Walter From msporny at digitalbazaar.com Thu Feb 14 21:24:40 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Feb 14 21:24:44 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: References: <47A9F741.2060801@digitalbazaar.com> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> Message-ID: <47B52218.3030700@digitalbazaar.com> Tim White wrote: > I don't write parsers or pretend to know how to, but... Then let me help by underscoring your point, which is an excellent one. I DO write parsers[1] and have quite a bit of experience in reading standards and implementing them in code. > (yes, here I go again) it seems to me that if you have this: > >
> Name of Album >
> Bob, Composer >
>
> > the parser should be able to determine that the "title" contained > directly inside "haudio" is an album name and that the "title" nested > inside "vcard" inside "haudio" belongs to the vcard and not haudio. 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:
The Composer named Bob created Awesome Song
Which gives this: haudio title "Composer" . vcard fn "Bob" ; title "Composer" . Every time you overlap two Microformats that share a common property, you could have this issue. That shouldn't scare us off from re-using common properties, though! > I'm sure cases exist (or could exist) where it won't be this simple, > but shouldn't this cover the 80%? Yes, you are correct. There are cases that exist that could mess up the data that you're generating, but that's the trade-off that Microformats took a long time ago (and it's a good trade-off, IMHO). > Certainly if we agree that microformats are a way to extend meaning to > content, TITLE is much more meaningful (and easier for authors to > adopt) than FN. So, does that mean you're a +1 for using TITLE over FN in hAudio as well? -- manu [1] http://rdfa.digitalbazaar.com/librdfa/ From msporny at digitalbazaar.com Thu Feb 14 22:32:52 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Feb 14 22:32:58 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B4F0F8.6060904@psybernet.co.nz> References: <47A9F741.2060801@digitalbazaar.com> <21e770780802112333q4f6de443lea8db3e6a18eede4@mail.gmail.com> <1202821155.12382.13.camel@weborganicscouk> <21e770780802120537w52ea8972t49ee72f838b444f5@mail.gmail.com> <47B2224E.5080005@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> Message-ID: <47B53214.703@digitalbazaar.com> Walter Logeman wrote: > The question concerning FN & TITLE (and FN as well) has an underlying > more general question. > > Are Microformats broken when terms are repeated across different formats? "broken" isn't the right word in this case, "not scalable" is closer to the mark. They are broken if we don't know what we are doing and this happened accidentally. The reality is quite the contrary, this trade-off was made knowing that there would be situations like this. It prevents Microformats from scaling... but those in the community know that as well. We're trying to create solutions that work for most people now... not in some hypothetical future that is going to mark up everything on a web page with various semantic vocabularies (that's what RDFa is for). > How is this answered? By a rule? Is there one? Should there be one? In general, this community is averse to rules that are rigid... they don't allow the community to grow with the rapid changes of the web. That's why we have so much debate here - we aren't afraid to question what we're doing. That is the sign of a healthy community - can it be critical of itself and not devolve into name calling and pseudo-political in-fighting? We try to focus on: "Here's the semantically right way to do things (if you're interested in doing them the right way)". Some just aren't in some cases. > The main reason to allow repeating terms is proximity to natural use > of language, human friendly - that is a Microformat principle. Instead of using the word "repeating", I think you mean "reusing"? > The main reason for not repeating terms is that it breaks > Microformats. Machine friendly. Again, not "repeating", "reusing". It doesn't always "break" Microformats... it causes greater difficulty when marking data up that overlaps. This may be more fair: As the number of Microformats increases, and as the rate of re-use of terms increases, the likely hood that two Microformats will clash with each other on a single page increases. WHEN this clash occurs is a known unknown. Brian Suda is concerned (please correct me if I'm wrong, Brian) that hAudio TITLE may be the first step towards a clash-heavy future. We have several principles that are at odds with one another (which is not a bad thing, it forces us to make hard decisions): 1. Microformats should re-use terms from other Microformats. 2. Microformats should not use fully qualified namespaces. 3. Microformats should use emulated namespaces as a last resort. 4. Microformats have one scope, either you're in a Microformatted block, or you're not. (For example, TITLE is inside an HAUDIO or it is not). #1 is at odds with #2 and #3. #2 is what allows vocabularies to scale (and is what RDFa allows). #3 is a stop-gap measure when you don't have the option of #2. #4 makes scaling more difficult as well. > However the question here is not one of priorities, it is more that > Microformats would not work at all then they would not be people > friendly either! While true, Microformats also has a principle to try and address 80% of publishing practices out there. We will never meet everybody's publishing goals - we're not trying to do that. You'll see people talking about "boiling the oceans" from time to time on here and this is what they mean by that - we can't solve everybody's publishing problems. Because we are using markup that is limited, there will always be corner cases that won't be addressable using Microformats. The reason we use simple markup is to help people publish semantic information in a much easier fashion. > In either approach regarding the repetition (or not) of terms, the > guidelines for developing parsers need to make it clear how the format > should be parsed. Are there such guidelines? They are here and there, sprinkled throughout the wiki and buried deep inside the heads of people that have been with this community from the beginning. Really, Mike Kaply (the guy that wrote and maintains Operator) is one of the few that really knows what all of the rules are... Tantek being the other one. Is there anyone else? It would be nice if we could create a "Microformats Processing Rules" document or a "Microformats Syntax Specification" document. RDFa has one and while it is ridiculously verbose, it's hard to misinterpret: http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080125/ > Any term used in Microformats is unique and can be correctly rendered > into a specific use. For example: The term "title" always refers to > the job title of a person. This is what I'm currently arguing against. > Terms used in Microformats can be correctly rendered into a specific > use by reference to the class they are nested in. For example: The > term "title" refers to the job title of a person in vCard, and to the > audio recording title in hAudio. This is what I'm currently arguing for, albeit - we still need to look at these things on a case-by-case basis. But the general guideline that you wrote above should hold. Ideally, we would note that the Oxford English dictionary would be the document determining the possible definitions of a word and precise meaning would be acquired by examining the context of the word (hCard or hAudio). > Does my summary make sense? It does... not bad at all for somebody that just joined the community and claims to have no formal background in these linguistics/computer sciencey things :) ... or are you a spy sent by a rival semantic community?* =P -- manu * as if there were such a thing... :) From csarven at gmail.com Thu Feb 14 23:10:45 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Thu Feb 14 23:10:47 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B53214.703@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> Message-ID: Some of this was already mentioned but here are my thoughts for whatever it's worth: I think that FN is more likely to cause a conflict then TITLE for audio title simply because FN is more likely ('must' have in hCard) to occur in hCard then TITLE if and where hAudio uses FN instead of TITLE. Based on this I would simply favour using TITLE over FN in hAudio. Perhaps I do not understand this bit fully but I wanted to mention the 'contributor' in hAudio where it may contain FN; wouldn't this further complicate things if we use FN instead of TITLE for the audio title? If TITLE is not the way to go -- for reasons because we don't agree or have not explored enough -- then I think using something like AUDIO-TITLE would be the next logical option. (IMHO) At this point, this issue can be either resolved (as more voices appear to be in favour of TITLE in hAudio *and* as we seem to have explored 'this' branch) or it can be kept open for some (?) time to give some of the community members to catchup or formulate their own line of thoughts. How and where do we draw the line in order to move on? +1 for using TITLE in hAudio. -Sarven From tjameswhite at gmail.com Fri Feb 15 04:59:11 2008 From: tjameswhite at gmail.com (Tim White) Date: Fri Feb 15 04:59:15 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B52218.3030700@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B52218.3030700@digitalbazaar.com> Message-ID: On Fri, Feb 15, 2008 at 12:24 AM, Manu Sporny 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: > >
>
> The Composer named > Bob created > Awesome Song > >
>
... > Every time you overlap two Microformats that share a common property, > you could have this issue. That shouldn't scare us off from re-using > common properties, though! Thank you for the example. You are right, it doesn't scare me from using it, just something for those that write parsers to worry about. > > Certainly if we agree that microformats are a way to extend meaning to > > content, TITLE is much more meaningful (and easier for authors to > > adopt) than FN. > > So, does that mean you're a +1 for using TITLE over FN in hAudio as well? Absolutely +1 (can I be +10?) Tim From andy at pigsonthewing.org.uk Fri Feb 15 06:14:01 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Feb 15 06:14:04 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B52218.3030700@digitalbazaar.com> Message-ID: <54143.80.249.57.38.1203084841.squirrel@www.gradwell.com> On Fri, February 15, 2008 12:59, Tim White quoted: > On Fri, Feb 15, 2008 at 12:24 AM, Manu Sporny > 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: >> >>
>>
>> The Composer named >> Bob created >> Awesome Song >> >> >>
>>
[Manu's e-mail has not reached here yet] Wait 'til you try to mark up: The Beatles' eponymous album. Surely: The Beatles' eponymous album. or: The Beatles' eponymous album. are better? -- Andy Mabbett ** via webmail ** From chucka at hr-xml.org Fri Feb 15 09:04:27 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Fri Feb 15 09:04:56 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> Message-ID: <47B5C61B.6080500@hr-xml.org> Sarven Capadisli wrote: > AUDIO-TITLE would be the next logical option. A completely peanut gallery comment from someone has been following this thread -- One would think that as Microformats flourish across other domain areas, you'll run into this again. So thinking about a rationale/approach for when and how you fully qualify a "property term" with a pre-fixed "object class term" (as Sarven suggests) is likely a good thing. Chuck From guillaume at lebleu.org Fri Feb 15 11:42:40 2008 From: guillaume at lebleu.org (Guillaume Lebleu) Date: Fri Feb 15 11:42:43 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B5C61B.6080500@hr-xml.org> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> Message-ID: <47B5EB30.9010007@lebleu.org> Chuck Allen wrote: > Sarven Capadisli wrote: >> AUDIO-TITLE would be the next logical option. > > A completely peanut gallery comment from someone has been following > this thread -- One would think that as Microformats flourish across > other domain areas, you'll run into this again. So thinking about a > rationale/approach for when and how you fully qualify a "property > term" with a pre-fixed "object class term" (as Sarven suggests) is > likely a good thing. It looks to me that the problem described by many can be either solved by: * recognizing root class value as name qualifiers (and possibly parent property class value). * using explicitly-qualified names. Both solutions are technically equivalent, but have pros/cons. In other words: ... is the same as: ... The former option reduces the overall number of names, and it has less of a namespace flavor. The second option is more concise but has more of a namespace prefix feel, and may encourage people to over-use them, just like they did in the XML community, to guarantee that naming collisions are avoided but losing at the same time the only incentive they had to encourage semantic reuse across communities. My preference is for the former. My 2 cents, Guillaume From lists at ben-ward.co.uk Fri Feb 15 16:34:16 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Fri Feb 15 16:34:21 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47B5EB30.9010007@lebleu.org> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> Message-ID: <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> OK, this is getting a bit wild. Can everyone please take a little stock. I shall try to lay out what I see are the ?facts? of this situation, which are being debated at length, but can't actually be altered. So: ? ?title? is specified as something else. ? ?fn? is perceived as too generic and counter intuitive in the context of audio My elaboration on those ?facts?: 'Title' came from vcard, and trying to bodge its semantics into hAudio is just going to create a mess. Even if there's a tenuous way to make the definition fit both, it's just a bad idea to generalise two things which are very clearly not the same. ?title? a desirable, valuable field name, but it's gone. In our ?f world, it's got a definition (which is not the most common English usage, it's true) and if it doesn't map to a usage in another proposed format then we'll have to use something else. Regarding FN, I happen to agree. It's very generic and works in place of something-called-title, but the name is unintuitive. I don't think that helps publishers. On the basis of those two things, there is very little to debate. TITLE is out of bounds because it doesn't mean what you want it to mean in the context of microformats. If ?FN? is agreed to be undesirable, then the only debate should be regarding what the alternative field name should be. For my 2?, I think the ?audio-title? route is OK, and has no ?namespacing? consequences at all. The ?audio-? prefix is precision and clarification. It's not a grouping. ?audio-title? makes perfect sense in natural language, and it's a field that it's necessary to be more precise on. If there's some phrase that could be more transferrable (something synonymous with ?media-title?) maybe that should be considered too. End of the day, though, ?TITLE? is gone, and if you don't like ?FN? then you need to find an alternative. Perhaps the current debate would be more productive if it focused on solving that problem, rather than thrashing around the cement base of the issue. Cheers, Ben From ckstjohn at gmail.com Fri Feb 15 17:45:52 2008 From: ckstjohn at gmail.com (Christopher St John) Date: Fri Feb 15 17:46:11 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47A9F741.2060801@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> Message-ID: <8ba906450802151745s6f0107dft634aae8594c23fca@mail.gmail.com> On Feb 6, 2008 12:06 PM, Manu Sporny wrote: > > If you are in support of this proposal, please speak up, even if it is a > "+1". If you are opposed to this proposal, please let us know the > reasoning to your opposition. > +1. I find Manu's reasoning (in his original posting and especially later in the thread) compelling. -cks -- Christopher St. John http://artofsystems.blogspot.com From scott at makedatamakesense.com Fri Feb 15 21:42:15 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri Feb 15 21:42:24 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> Message-ID: <72F8BE37-3E73-4B36-8D38-BB588391D249@makedatamakesense.com> On Feb 15, 2008, at 5:34 PM, Ben Ward wrote: > For my 2?, I think the ?audio-title? route is OK I agree. I was just looking back over how we got here on this issue, and I'm afraid it may be largely my fault. When AUDIO-TITLE was widely accepted, Brian said "what about FN?" and then Manu raised an issue with FN and then I suggested a resolution for that issue, and Manu agreed. So we moved forward with FN, but in retrospect I think it was a mistake to treat the resolution of one issue with FN as a reason to go with FN over AUDIO-TITLE without ever really comparing the alternatives. I never saw a problem with AUDIO-TITLE. I think I just got so into defending FN that I stopped openly considering the alternatives. Now that I reconsider them, I agree with Ben that AUDIO- TITLE looks OK. -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Fri Feb 15 22:09:51 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Feb 15 22:09:56 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> Message-ID: <47B67E2F.5090206@digitalbazaar.com> Ben Ward wrote: > OK, this is getting a bit wild. Woooo! Do we know how to party or what!? Look, look... Andy Mabbet's so toasted he's wearing a lampshade on his head! =P > Can everyone please take a little stock. > I shall try to lay out what I see are the ?facts? of this situation, > which are being debated at length, but can't actually be altered. A fact is a concept whose truth can be rigorously proven. I hope that you don't mind that I ask you to prove these "facts", then. > My elaboration on those ?facts?: > > 'Title' came from vcard, and trying to bodge its semantics into hAudio > is just going to create a mess. The first part is a fact, the second part is certainly not a fact. It is a statement of opinion. I'm making this distinction not to be pedantic, but to point out that it poisons the discourse of the conversation when one starts to claim statements of opinion as fact. Could you please explain how "bodging it's semantics is going to create a mess"? > ?title? a desirable, valuable field name, but it's gone. Argumentum ad antiquitatem[1]. That is a logical fallacy - it is not "gone". You're arguing that we continue doing this for historical reasons - "TITLE has always meant 'job title' and we should keep it that way because that's the way it's always been." We're talking about removing "job" from "job title" - how is that going to hurt anything? > Regarding FN, I happen to agree. It's very generic and works in place of > something-called-title, but the name is unintuitive. I don't think that > helps publishers. Also, not a fact. It is a statement of opinion. I agree with that statement of opinion, but what you have is a hypothesis, not a fact. > On the basis of those two things, there is very little to debate. That is a non sequitur[4], another logical fallacy. You cannot chain together two statements of opinion and come to the conclusion that you have without first making stronger arguments for the first two hypotheses. For example, you'd have to demonstrate the reasoning behind why "TITLE" is gone, for starters. Why are we disallowed from talking about TITLE? > TITLE is out of bounds because it doesn't mean what you want it to > mean in the context of microformats. I know you probably didn't mean this to sound as harsh as it does, but this looks like you're attempting to impose your opinion on the rest of us by claiming that something is "out of bounds" when it is not. Bernays would be proud[2][3]. Using dogma and stigmatizing those that step outside of those bounds to support an argument certainly does glean strong emotional responses. > If ?FN? is agreed to be undesirable, then the > only debate should be regarding what the alternative field name should be. We are having that debate, and it looks like more people are coming out of the woodwork to support TITLE in hAudio. > For my 2?, I think the ?audio-title? route is OK, and has no > ?namespacing? consequences at all. The ?audio-? prefix is precision and > clarification. It's not a grouping. Would you consider naming it 'haudio-title' namespacing or grouping? > Perhaps the current debate would be more productive if it focused on > solving that problem, rather than thrashing around the cement base of > the issue. Let me point out that the current debate has resulted in more people supporting TITLE than not supporting it. The current count is 7 for TITLE, 2 opposed (this includes counting you in the opposed category). It should be noted that there are many decisions in this community that have been passed with less feedback on an issue than that. I am also starting to repeat myself, so I'm going to stop responding to anything that is a repetition of something that has already been stated. -- manu [1]http://www.csun.edu/~dgw61315/fallacies.html#Argumentum%20ad%20antiquitatem [2]http://www.youtube.com/watch?v=9Kp24ZeHtv4 [3]http://www.youtube.com/watch?v=FsZ8UkkVAdM [4]http://www.csun.edu/~dgw61315/fallacies.html#Non%20sequitur From tjameswhite at gmail.com Sat Feb 16 05:56:53 2008 From: tjameswhite at gmail.com (Tim White) Date: Sat Feb 16 05:57:00 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> References: <47A9F741.2060801@digitalbazaar.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> Message-ID: On Feb 15, 2008 7:34 PM, Ben Ward wrote:> > 'Title' came from vcard, and trying to bodge its semantics into > hAudio is just going to create a mess. > > Regarding FN, I happen to agree. It's very generic and works in place > of something-called-title, but the name is unintuitive. I don't think > that helps publishers. If this is the argument for not using 'title' ("it came from vcard") then the same holds true for 'fn': "3.1.1 FN Type Definition Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents." [1] FN can *not* be reused because it has already been defined as part of vCard. We shall now have to extend that to all formats -- if the name exists in one is off limits for others. I have pointed out in a prior email that the 'title' issue holds true for citations, it will also hold true for works of art, media, etc. Based on mf practices of looking at how items are currently published, 'title' is already being used. People first, machines second. To me that means create easy-to-understand-and-adopt formats and let the parsers (and those who build them) figure out what the 'title' (or other property) belongs to. Manu, please correct my logic. : ) Tim [1] From http://www.ietf.org/rfc/rfc2426.txt; referenced from http://microformats.org/wiki/rfc-2426 From tjameswhite at gmail.com Sat Feb 16 06:00:41 2008 From: tjameswhite at gmail.com (Tim White) Date: Sat Feb 16 06:00:45 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: References: <47A9F741.2060801@digitalbazaar.com> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> Message-ID: Almost forgot one point: FN is required by hCard. 'Title' is not required. I would argue that a *required* attribute is off limits to other formats more than an optional attribute. Tim On Feb 16, 2008 8:56 AM, Tim White wrote: > On Feb 15, 2008 7:34 PM, Ben Ward wrote:> > > 'Title' came from vcard, and trying to bodge its semantics into > > hAudio is just going to create a mess. > > > > Regarding FN, I happen to agree. It's very generic and works in place > > of something-called-title, but the name is unintuitive. I don't think > > that helps publishers. > > If this is the argument for not using 'title' ("it came from vcard") > then the same holds true for 'fn': > > "3.1.1 FN Type Definition > Type purpose: To specify the formatted text corresponding to the name > of the object the vCard represents." [1] > > FN can *not* be reused because it has already been defined as part of vCard. > > We shall now have to extend that to all formats -- if the name exists > in one is off limits for others. > > I have pointed out in a prior email that the 'title' issue holds true > for citations, it will also hold true for works of art, media, etc. > Based on mf practices of looking at how items are currently published, > 'title' is already being used. > > People first, machines second. To me that means create > easy-to-understand-and-adopt formats and let the parsers (and those > who build them) figure out what the 'title' (or other property) > belongs to. > > Manu, please correct my logic. : ) > > Tim > > [1] From http://www.ietf.org/rfc/rfc2426.txt; referenced from > http://microformats.org/wiki/rfc-2426 > From info at weborganics.co.uk Sat Feb 16 08:38:31 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 16 08:38:53 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> Message-ID: <1203179911.348.24.camel@weborganicscouk> Hello Ben, Nice of you to join us. On Sat, 2008-02-16 at 00:34 +0000, Ben Ward wrote: > 'Title' came from vcard, and trying to bodge its semantics into > hAudio is just going to create a mess. haudio does not "Bodge" anything but thanks for the detrimental comment. The Only place on the Microformats wiki I can find any "definition" of what "title" in hcard actually means are: Job title or functional position of the object. http://microformats.org/wiki/existing-classes and See section 3.5.1 of RFC 2426. http://microformats.org/wiki/hcard-profile How do "objects" have titles? hAudio does NOT reuse "title" from hcard, because its actual meaning seems deliberately vague and inaccurate to say the least. we mean: "title" "what is to be used as a title for the object" and can be expanded into "Contents are a short textual description used to identify the object among interested parties" Its deliberately backwards compatible with the definition in hcard but also can be re used in the FUTURE in: Recipies http://microformats.org/wiki/recipe-examples Things http://microformats.org/wiki/item-examples Products http://microformats.org/wiki/product-examples Books http://microformats.org/wiki/book-info-examples Film http://microformats.org/wiki/video-info-examples Works of art http://microformats.org/wiki/workofart-brainstorming Media on a whole http://microformats.org/wiki/media-info-examples Jobs? http://microformats.org/wiki/job-listing-examples Citations http://microformats.org/wiki/citation-examples Blog Posts http://microformats.org/wiki/blog-post-examples I think the benefits far outweigh any "theoretical" chance that it might break hcard, have you actually studied how many publishers actually use "title" in their markup? have a look at your "real world" examples and get back to me. http://microformats.org/wiki/hcard-examples-in-wild-reviewed http://microformats.org/wiki/hcard-examples-in-wild-with-problems Thanks Martin McEvoy > Even if there's a tenuous way > to make the definition fit both, it's just a bad idea to generalise > two things which are very clearly not the same. ?title? a desirable, > valuable field name, but it's gone. In our ?f world, it's got a > definition (which is not the most common English usage, it's true) > and if it doesn't map to a usage in another proposed format then > we'll have to use something else. From info at weborganics.co.uk Sat Feb 16 10:47:47 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 16 10:48:25 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <1203179911.348.24.camel@weborganicscouk> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <1203179911.348.24.camel@weborganicscouk> Message-ID: <1203187667.652.8.camel@weborganicscouk> On Sat, 2008-02-16 at 16:38 +0000, Martin McEvoy wrote: > Hello Ben, Nice of you to join us. > > On Sat, 2008-02-16 at 00:34 +0000, Ben Ward wrote: > > 'Title' came from vcard, and trying to bodge its semantics into > > hAudio is just going to create a mess. > > haudio does not "Bodge" anything but thanks for the detrimental > comment. Oh!! I have just read my above comments, and as pointed out by one of our most esteemed members on the list that the above seems sarcastic... it does doesn't it?, I apologize if they are, It was no way meant in a personal or in my own words "detrimental" way. Kind Regards Martin McEvoy From greg at grabb.it Tue Feb 19 14:35:02 2008 From: greg at grabb.it (Gregory Borenstein) Date: Tue Feb 19 14:35:18 2008 Subject: [uf-new] Grabb.it support for hAudio In-Reply-To: <47B67E2F.5090206@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <47B67E2F.5090206@digitalbazaar.com> Message-ID: <889F4379-49C7-4FC0-857C-3C1BAE7573C9@grabb.it> Hello, I'm one of the founders of Grabb.it, an online music player and search engine. With Martin's help, Grabb.it recently switched all of our user pages to use hAudio markup. These pages aggregate each user's comments and favorite songs. For example, here's mine: http://grabb.it/users/greg In addition to using hAudio, we also designed our markup to integrate with the Yahoo Media Player (http://yahoomediaplayer.wikia.com). It was nice to discover that the two formats are compatible (all that was required to achieve YMP compatibility was an additional class on the enclosure link and some strategic use of its title attribute). Grabb.it has a large database of tracks found online and a few thousand users producing mp3 blogs based on them. I don't know quite how many tracks this adds up to marked up in hAudio but it's definitely in the thousands. And, obviously, with an account anyone can now easily produce hAudio markup of any of our songs simply by marking it as a favorite or writing a comment on it. I've also submitted a patch to the maintainers of Mofo, a Ruby library for parsing microformats that adds hAudio support to that library. Hopefully, I'll be able to notify this list soon of its acceptance. At that point, Grabb.it will also read hAudio markup wherever we come across it. Thanks for your work on this format. yours, Greg Borenstein --- http://grabb.it/users/greg http://urbanhonking.com/ideasfordozens http://atduskmusic.com From msporny at digitalbazaar.com Tue Feb 19 16:25:54 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Feb 19 16:29:22 2008 Subject: [uf-new] Grabb.it support for hAudio In-Reply-To: <889F4379-49C7-4FC0-857C-3C1BAE7573C9@grabb.it> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <47B67E2F.5090206@digitalbazaar.com> <889F4379-49C7-4FC0-857C-3C1BAE7573C9@grabb.it> Message-ID: <47BB7392.4090905@digitalbazaar.com> Gregory Borenstein wrote: > I'm one of the founders of Grabb.it, an online music player and search > engine. With Martin's help, Grabb.it recently switched all of our user > pages to use hAudio markup. These pages aggregate each user's comments > and favorite songs. For example, here's mine: > > http://grabb.it/users/greg Fantastic work Greg - and Martin for doing the advocacy. Looked through the site - really cool idea and exactly the type of use case we were thinking of when putting hAudio together. Greg, if you have any constructive criticism on the hAudio format, we'd love to hear it. :) -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: RDFa Basics (video) http://blog.digitalbazaar.com/2008/01/07/rdfa-basics From greg at grabb.it Fri Feb 22 12:08:50 2008 From: greg at grabb.it (Gregory Borenstein) Date: Fri Feb 22 12:15:41 2008 Subject: [uf-new] Grabb.it support for hAudio In-Reply-To: <47BB7392.4090905@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <47B67E2F.5090206@digitalbazaar.com> <889F4379-49C7-4FC0-857C-3C1BAE7573C9@grabb.it> <47BB7392.4090905@digitalbazaar.com> Message-ID: <30FC8CC0-D828-4872-93CC-CAC8760CF516@grabb.it> Thanks, Manu! The summary of my main suggestions gleaned from implementing hAudio goes like this: (1) the item option may be unnecessary, (2) it would be great to formalize htrack compatibility as a minimal, hand-codeable option. Here are the details: (1) The playlisting case for which the hAudio/item option in the spec was designed wasn't flexible enough to handle my situation, i.e. I needed to put other data inside each blog item that doesn't adhere to the spec (for example, the actual blog posts themselves and some embedded player stuff). That's why I ended up marking up each post as an independent hAudio despite the fact that they are very clearly an ordered playlist. From a parser point-of-view, though, the order is still retained by position on page so I'm not even sure where the item option would be useful outside of the rare case where you've got multiple _separate_ playlists on a single page. (2) It would be great if there was a super simple minimal version of the spec that people could actually write up by hand. While it was a breeze to write code to programmatically markup a bunch tracks in hAudio, I can't imagine ever actually writing any hAudio by hand, i.e. if I was a regular blogger hand-writing links. For my part, I'd love to see the hAudio-hTrack compatibility I accidentally stumbled across in this process encouraged by basing a minimal version of the spec on the work the Yahoo guys have already done. If you guys could figure out a way to get the contributor name into that simple anchor markup semantically and the YMP adopted it (and maybe the del.icio.us playtagger as well), that would push a lot of adoption by the bloggers who need the utility of actual playing tools as a motivator. For reference, here's the relevant part of Grabb.it's track markup: Download MP3: Heretics - Andrew Bird The rel="enclosure" bit is solely there for hAudio compatibility. the "download" class is Grabb.it legacy that we'll eventually pull out now that we can depend on "htrack" being on there. YMP uses the title attribute in their player display, which makes me very tempted to put the artist in there too like title="Heretics - Andrew Bird", but that reduces the semantic coherence. If there was some other really easy place to put the artist that YMP would pick up, I'd definitely do it. And I'm pretty sure you'll never see an mp3 blogger using type="audio/ mpeg" which I technically don't need here since my mp3 urls always end in .mp3, but doesn't hurt. Finally, a minor note on a discussion you've been having: -I definitely prefer 'title' to 'fn'. It's much more semantic and perfectly easy to parse (from my point of view working on Mofo). ('fn' strikes me as an example of how being a programmer can make us inured to things having names which are arbitrary relative to the context we're using them in, which is definitely not a common skill for 'normals'). Anyway, I hope that's helpful for you guys. Thanks for you work on this format and thanks again to Martin for helping me implement it! yours, Greg --- http://grabb.it/users/greg http://urbanhonking.com/ideasfordozens http://atduskmusic.com On Feb 19, 2008, at 4:25 PM, Manu Sporny wrote: > Gregory Borenstein wrote: >> I'm one of the founders of Grabb.it, an online music player and >> search >> engine. With Martin's help, Grabb.it recently switched all of our >> user >> pages to use hAudio markup. These pages aggregate each user's >> comments >> and favorite songs. For example, here's mine: >> >> http://grabb.it/users/greg > > Fantastic work Greg - and Martin for doing the advocacy. Looked > through > the site - really cool idea and exactly the type of use case we were > thinking of when putting hAudio together. > > Greg, if you have any constructive criticism on the hAudio format, > we'd > love to hear it. :) > > -- manu > > -- > Manu Sporny > President/CEO - Digital Bazaar, Inc. > blog: RDFa Basics (video) > http://blog.digitalbazaar.com/2008/01/07/rdfa-basics > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From ryan at theryanking.com Fri Feb 22 12:38:04 2008 From: ryan at theryanking.com (Ryan King) Date: Fri Feb 22 12:38:14 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <72F8BE37-3E73-4B36-8D38-BB588391D249@makedatamakesense.com> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <72F8BE37-3E73-4B36-8D38-BB588391D249@makedatamakesense.com> Message-ID: <6524380D-35E8-4A31-B521-C21BAB5FEFAC@theryanking.com> On Feb 15, 2008, at 9:42 PM, Scott Reynen wrote: > On Feb 15, 2008, at 5:34 PM, Ben Ward wrote: > >> For my 2?, I think the ?audio-title? route is OK > > I agree. I was just looking back over how we got here on this > issue, and I'm afraid it may be largely my fault. When AUDIO-TITLE > was widely accepted, Brian said "what about FN?" and then Manu > raised an issue with FN and then I suggested a resolution for that > issue, and Manu agreed. So we moved forward with FN, but in > retrospect I think it was a mistake to treat the resolution of one > issue with FN as a reason to go with FN over AUDIO-TITLE without > ever really comparing the alternatives. I never saw a problem with > AUDIO-TITLE. I think I just got so into defending FN that I stopped > openly considering the alternatives. Now that I reconsider them, I > agree with Ben that AUDIO-TITLE looks OK. This sounds like a good way forward to me. Any reason why audio-title shouldn't be reconsidered? -ryan From msporny at digitalbazaar.com Fri Feb 22 13:25:57 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Feb 22 13:26:13 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <6524380D-35E8-4A31-B521-C21BAB5FEFAC@theryanking.com> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <72F8BE37-3E73-4B36-8D38-BB588391D249@makedatamakesense.com> <6524380D-35E8-4A31-B521-C21BAB5FEFAC@theryanking.com> Message-ID: <47BF3DE5.40904@digitalbazaar.com> Ryan King wrote: > On Feb 15, 2008, at 9:42 PM, Scott Reynen wrote: > > This sounds like a good way forward to me. Any reason why audio-title > shouldn't be reconsidered? I'd like Ben Ward and Brian Suda to clarify their positions before we move on. Of those that have given their position on FN vs. TITLE, Brian and Ben are the only ones that were opposed to the idea of using TITLE. I'm attempting to arrange a phone call with each of them to understand their positions in more depth. Namely: - What exactly will be hurt by generalizing TITLE's definition? - How could this break hCard? If the decision is between AUDIO-TITLE and TITLE, I'd still argue for TITLE. IMHO, it is easier to author, can be re-used, makes more sense to those new to Microformats, and is still coherent with the English language. We must be fair to all involved in this discussion. I believe that we have learned much by talking about this, and should let Brian and Ben respond before we move on. Namely, because this decision is dependent on their responses. :) -- manu From chucka at hr-xml.org Fri Feb 22 14:20:44 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Fri Feb 22 14:21:06 2008 Subject: [uf-new] PROPOSAL: Replace hAudio FN with TITLE In-Reply-To: <47BF3DE5.40904@digitalbazaar.com> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <72F8BE37-3E73-4B36-8D38-BB588391D249@makedatamakesense.com> <6524380D-35E8-4A31-B521-C21BAB5FEFAC@theryanking.com> <47BF3DE5.40904@digitalbazaar.com> Message-ID: <47BF4ABC.7000803@hr-xml.org> Manu Sporny wrote: > - What exactly will be hurt by generalizing TITLE's definition? > - How could this break hCard? > If parsers can disambiguate (can anyone say with confidence that this is so?), perhaps it is okay to leave the value just "title" rather than the fully qualified "audio-title". However, even if you are comfortable with this -- i.e., that parsers can adequately discern a title in an hCard from one in hAudio -- I'd steer clear of a "generalized TITLE definition". Handling the definitions that way quickly results in a compilation of useless information. What you want to do, even if you can leave your property name unqualified (title instead of audio-title), is to use a fully qualified dictionary entry name for each definition in the wiki. Something like below: haudio. title The name or label of an audio work hcard. title The name of a position held by the person Handling these as two different entries seems strange, but if it makes sense if in fact humans and parsers discern two different concepts based on context. This sort of an ISO 15000-lite way of constructing these dictionary names. Chuck Allen From info at weborganics.co.uk Sat Feb 23 07:23:05 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 23 07:23:17 2008 Subject: [uf-new] Grabb.it support for hAudio In-Reply-To: <30FC8CC0-D828-4872-93CC-CAC8760CF516@grabb.it> References: <47A9F741.2060801@digitalbazaar.com> <5A250881-1448-4FA4-814E-2F66C5E6E7D8@makedatamakesense.com> <47B22C29.7040902@digitalbazaar.com> <1202866340.4573.16.camel@weborganicscouk> <9113EB65-69B3-4E31-B635-C6868A751B0B@theryanking.com> <1202908925.7271.66.camel@weborganicscouk> <21e770780802140029u170147c7if2fb3b1de2870eda@mail.gmail.com> <47B49CA9.4030209@digitalbazaar.com> <47B4F0F8.6060904@psybernet.co.nz> <47B53214.703@digitalbazaar.com> <47B5C61B.6080500@hr-xml.org> <47B5EB30.9010007@lebleu.org> <6C3C7CF0-FF8A-447C-9EA0-6F11742F2C72@ben-ward.co.uk> <47B67E2F.5090206@digitalbazaar.com> <889F4379-49C7-4FC0-857C-3C1BAE7573C9@grabb.it> <47BB7392.4090905@digitalbazaar.com> <30FC8CC0-D828-4872-93CC-CAC8760CF516@grabb.it> Message-ID: <1203780185.16304.2.camel@weborganicscouk> Hello Greg On Fri, 2008-02-22 at 12:08 -0800, Gregory Borenstein wrote: > > Thanks for you work on this format Thanks to you too :) > and thanks again to Martin for > helping me implement it! You are very welcome it was a pleasure. Martin McEvoy. From mail at tobyinkster.co.uk Sat Feb 23 09:26:00 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Feb 23 09:26:08 2008 Subject: [uf-new] figure microformat Message-ID: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Sent this a couple of days ago, but was rejected from the list because of a problem with my subscription. Here we go again... 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 What do people think? Is it ready to go onto the drafts list or do you think it needs a little extra work? -- Toby A Inkster From csarven at gmail.com Sat Feb 23 10:15:32 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Feb 23 10:15:35 2008 Subject: [uf-new] figure microformat In-Reply-To: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: I suppose since the http://microformats.org/wiki/figure now exist, would I have to bring it up here before making any changes to the Wiki? Using the TITLE attribute may be confusing to publishers considering the ALT attribute is a requirement. I do not think FIGURE and LEGEND should be set on the same element. Hierarchy should exist. I would instead propose: If FIGURE contains IMAGE and LEGEND is not present, then parsers should use the ALT attribute value for legend. This is the most basic and common approach for s today and might as well stick to it instead of bringing TITLE into the picture. e.g.
The quick brown fox
-Sarven On 2/23/08, Toby A Inkster wrote: > Sent this a couple of days ago, but was rejected from the list > because of a problem with my subscription. Here we go again... > > 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 > > What do people think? Is it ready to go onto the drafts list or do > you think it needs a little extra work? > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From csarven at gmail.com Sat Feb 23 10:46:23 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Feb 23 10:46:25 2008 Subject: [uf-new] figure microformat In-Reply-To: References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: re: http://microformats.org/wiki/figure "The subject, credit, tags and licence may be children of the legend, in which case the text within them forms part of the legend as well as part of the child elements." This suggests that the CAPTION that was mentioned in http://microformats.org/wiki/figure-examples is no longer needed. I think in this case it would be appropriate to suggest that subject, credit, tags, license *should* be a child of LEGEND. Hence: * figure ** image ** legend *** credit *** subject -Sarven On 2/23/08, Sarven Capadisli wrote: > I suppose since the http://microformats.org/wiki/figure now exist, > would I have to bring it up here before making any changes to the > Wiki? > > Using the TITLE attribute may be confusing to publishers considering > the ALT attribute is a requirement. > I do not think FIGURE and LEGEND should be set on the same element. > Hierarchy should exist. > > I would instead propose: > If FIGURE contains IMAGE and LEGEND is not present, then parsers > should use the ALT attribute value for legend. This is the most basic > and common approach for s today and might as well stick to it > instead of bringing TITLE into the picture. > > e.g. >
> The quick brown fox >
> > > > -Sarven > > > > On 2/23/08, Toby A Inkster wrote: > > Sent this a couple of days ago, but was rejected from the list > > because of a problem with my subscription. Here we go again... > > > > 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 > > > > What do people think? Is it ready to go onto the drafts list or do > > you think it needs a little extra work? > > > > -- > > Toby A Inkster > > > > > > > > > > > > _______________________________________________ > > microformats-new mailing list > > microformats-new@microformats.org > > http://microformats.org/mailman/listinfo/microformats-new > > > From bhawkeslewis at googlemail.com Sat Feb 23 11:13:52 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sat Feb 23 11:14:06 2008 Subject: [uf-new] figure microformat In-Reply-To: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: <47C07070.9090300@googlemail.com> Toby A Inkster wrote: > Sent this a couple of days ago, but was rejected from the list because > of a problem with my subscription. Here we go again... > > 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 > > What do people think? Is it ready to go onto the drafts list or do you > think it needs a little extra work? I suspect ALT="", as featured in your Einstein example, is suboptimal for content images that people might want to find, bookmark, save, or otherwise manipulate. The general behavior of text browsers and screen readers is to ignore images with ALT="". On the whole, ALT="" is best reserved for genuinely decorative images when you want to indicate that search engines, text browsers, voice browsers, and screen readers should completely ignore an image. For example: For a captioned photo I'd recommend either using a concise label (alt="Einstein") or a brief description of what you can see, depending on your editorial focus and what information is provided by text elsewhere. ALT="Einstein photographed at 68, eyebrow arched as he looks out to the camera, face creased with wrinkles, with an impressive mustache and a scraggy mane of white hair." would be one attempt to provide an actual text equivalent for (say): http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg If you'd like to provide a lengthy description but feel it would clog up non-visual renderings, put it in another document and reference it via LONGDESC. Where a caption describes a content image, there's a good case for making it the target of the LONGDESC attribute via its fragment identifier. The general principle is to label the content image and provide the same critical information to all users, minimizing information in ALT in so far as the same information is provided by text elsewhere in the document. Whatever you think of the necessity of alternative text for content images, such supplementary uses of ALT and LONGDESC need (it seems to me) to have some sort of place in the proposed draft. Compare (and contrast): http://www.w3.org/TR/html401/struct/objects.html#h-13.2 http://www.w3.org/QA/Tips/altAttribute http://www.w3.org/TR/WCAG20/#text-equiv http://www.bbc.co.uk/guidelines/newmedia/accessibility/text_equivs.shtml http://joeclark.org/book/sashay/serialization/Chapter06.html http://www.isolani.co.uk/blog/access/FallacyOfTooMuchAccessibility http://googlewebmastercentral.blogspot.com/2007/12/using-alt-attributes-smartly.html http://blog.whatwg.org/omit-alt http://blog.whatwg.org/the-longdesc-lottery http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-the-rise-and-fall-of-the-longdesc/ -- Benjamin Hawkes-Lewis From andy at pigsonthewing.org.uk Sat Feb 23 12:07:24 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Feb 23 12:08:55 2008 Subject: [uf-new] figure microformat In-Reply-To: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: In message <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk>, Toby A Inkster 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 From bhawkeslewis at googlemail.com Sat Feb 23 12:10:00 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sat Feb 23 12:17:03 2008 Subject: [uf-new] figure microformat In-Reply-To: <47C07070.9090300@googlemail.com> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> <47C07070.9090300@googlemail.com> Message-ID: <47C07D98.606@googlemail.com> I wrote: > For a captioned photo I'd recommend either using a concise label > (alt="Einstein") or a brief description of what you can see, depending > on your editorial focus and what information is provided by text elsewhere. > > ALT="Einstein photographed at 68, eyebrow arched as he looks out to the > camera, face creased with wrinkles, with an impressive mustache and a > scraggy mane of white hair." > > would be one attempt to provide an actual text equivalent for (say): > > http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg You may have noticed that my example features a different photograph than that referred to in the draft's example. This was because there was more than one photograph of Einstein by Ehrenfest, and there wasn't enough equivalent text to identify which one was indicated. It occurred to me afterwards that this is actually a rather nice example of how the example markup /didn't/ provide enough text equivalence, at least not for this reader. :) > Whatever you think of the necessity of alternative text for content > images, such supplementary uses of ALT and LONGDESC need (it seems to > me) to have some sort of place in the proposed draft. To rephrase this in a (sightly) more actionable way: if we're talking about extracting content images and information about them from web documents, then we either need to try to dictate how authors should provide text equivalents for images or we need to cater for the different ways they already do (and don't) provide text equivalents. The first is hard because it's hard to achieve consensus (see the differing opinions in the original reading list I provided) and the second is hard because practice is variable. -- Benjamin Hawkes-Lewis From info at weborganics.co.uk Sat Feb 23 12:52:06 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 23 12:52:20 2008 Subject: [uf-new] figure microformat In-Reply-To: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: <1203799926.3716.37.camel@weborganicscouk> On Sat, 2008-02-23 at 17:26 +0000, Toby A Inkster wrote: > Sent this a couple of days ago, but was rejected from the list > because of a problem with my subscription. Here we go again... > > 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 > > What do people think? Is it ready to go onto the drafts list or do > you think it needs a little extra work? It needs a little more work :) although this looks interesting I am unsure about what are you trying to do? Are you trying to reproduce the figure tag in html 5? or are you trying to mark up images with captions? Are you trying to do both? The lack of context on the alt attribute may need rethinking as it will cause accessibility issues, and what If I have images turned off? unless you are trying to make a screen readers and old browsers ignore your image? if so why? this is ok but maybe you should try to re-use other ufs a bit: http://microformats.org/wiki/figure#Example

of Albert Einstein by Paul Ehrenfest (photographer)

could be changed to:
Albert Einstein of Albert Einstein by Paul Ehrenfest (photographer)
photo from hcard to replace image http://microformats.org/wiki/hcard#Property_List cite is just posh ;) this would replace Subject by citing the object? http://www.w3.org/TR/REC-html40/struct/text.html#edef-CITE contributor from haudio, the photographer is someone who takes part in the production of the image? http://microformats.org/wiki/haudio#Contributor I don't think legend is necessary as it seems to be acting as a container uF? but until I can understand a little more about what you are proposing I wont know. Thanks Martin McEvoy > From csarven at gmail.com Sat Feb 23 12:56:29 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Feb 23 12:56:37 2008 Subject: [uf-new] figure microformat In-Reply-To: References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: On 2/23/08, Andy Mabbett wrote: > 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. +1 for bringing the include pattern back. Even if the suitable caption is not used somewhere else on the page, it would be appropriate to /connect/ the reference point (context) with the figure itself. For instance, without the include pattern, the following is common (examples need to be cited):

Photo 1 shows Einstein riding a motorcycle.

...
> > Finally I'd like to see one or more use-cases explained - what will > parsers actually /do/ with this information? If I understand this correctly, one possible use for parsers is to list figures with their context in the document. Similar to footnotes? (http://microformats.org/wiki/footnotes-examples) -Sarven From mail at tobyinkster.co.uk Sat Feb 23 13:01:13 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Feb 23 13:01:24 2008 Subject: [uf-new] Re: figure microformat In-Reply-To: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: In answer to a few messages... Sarven Capadisli wrote: > If FIGURE contains IMAGE and LEGEND is not present, then parsers > should use the ALT attribute value for legend. Benjamin Hawkes-Lewis wrote: > I suspect ALT="", as featured in your Einstein example, is suboptimal > for content images that people might want to find, bookmark, save, or > otherwise manipulate. There's two main reasons I decided against using alt as a legend in the draft. Firstly, the simplest reason, this counts as invisible data -- except in Internet Explorer which displays alt attributes as a roll-over tooltip. Secondly, and more importantly, accessibility issues with the ABBR pattern have shown that we shouldn't hijack accessibility-related elements and attributes without a lot of thought. Otherwise we may end up with results like:
Picture of a crazy foo Picture of a crazy foo
Where the result in a screen reader or text browser is actually far worse than leaving blank alt text:
Picture of a crazy foo
I did actually intend to include an example with non-empty alt text, and will edit the draft now to correct this oversight. > Whatever you think of the necessity of alternative text for content > images, such supplementary uses of ALT and LONGDESC need (it seems to > me) to have some sort of place in the proposed draft. I think these attributes are very important, and that's why we should avoid overloading them, and allow authors to use them for the very important purpose for which they were designed. Sarven Capadisli wrote: > This suggests that the CAPTION that was mentioned in > http://microformats.org/wiki/figure-examples is no longer needed. The "caption" and "legend" classes appeared to be semantically identical. Can anyone think of a reason for both to be included? Out of the two, I chose the name "legend" rather than "caption", as "legend" is the name used in the HTML5 draft. Sarven Capadisli wrote: > I think in this case it would be appropriate to suggest that subject, > credit, tags, license *should* be a child of LEGEND. Hence: Perhaps *should*, but certainly not *must* as that would prevent convenient uses like:

(credits)

All photography by Toby Inkster.

Andy Mabbett wrote: > Turning to specifics, I think the dismissal of the "include > pattern" is > unfortunate and needs to be reversed The draft has always explicitly said that the include pattern *may* be used. It suggests that the ABBR pattern *should not* be used, because frankly I can't see any reason why it *should* be used. The ABBR pattern is useful when you want parsers to have a long string available, one that would be too long to be appropriate to show to human readers. For legends, credits and subjects, there's no need to do that -- it is always appropriate to show humans the full string. Besides which, it's a *should not* and not a *must not*. Hopefully that answers all the questions that have been brought up. -- Toby A Inkster From mail at tobyinkster.co.uk Sat Feb 23 13:15:23 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Feb 23 13:15:30 2008 Subject: [uf-new] Re: figure microformat In-Reply-To: <845AC021-79AE-44F6-A19A-2BBA4AB5A70B@tobyinkster.co.uk> References: <845AC021-79AE-44F6-A19A-2BBA4AB5A70B@tobyinkster.co.uk> Message-ID: Sarven Capadisli wrote: > +1 for bringing the include pattern back. It's never been away! Honest! ;-) > If I understand this correctly, one possible use for parsers is to > list figures with their context in the document. Similar to footnotes? > (http://microformats.org/wiki/footnotes-examples) That's my main motivation, but I can imagine other uses for it. Explicitly associating tags (with rel-tag) with an image could help smart search engines to find images by keyword. If we add rel-license into the fold as well, then we could also search be licence (e.g. public domain, requires attribution, etc). Martin McEvoy wrote: > I don't think legend is necessary as it seems to be acting as a > container uF? but until I can understand a little more about what you > are proposing I wont know. The legend provides a caption for the image. -- Toby A Inkster From andy at pigsonthewing.org.uk Sat Feb 23 13:36:23 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Feb 23 13:37:51 2008 Subject: [uf-new] figure microformat In-Reply-To: <1203799926.3716.37.camel@weborganicscouk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> <1203799926.3716.37.camel@weborganicscouk> Message-ID: In message <1203799926.3716.37.camel@weborganicscouk>, Martin McEvoy writes >
> Albert Einstein > > of Albert Einstein by > > Paul Ehrenfest > (photographer) > >
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 From andy at pigsonthewing.org.uk Sat Feb 23 13:44:13 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Feb 23 13:46:22 2008 Subject: [uf-new] Re: figure microformat In-Reply-To: References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: In message , Toby A Inkster writes >There's two main reasons I decided against using alt as a legend in the >draft. Firstly, the simplest reason, this counts as invisible data -- >except in Internet Explorer which displays alt attributes as a >roll-over tooltip. Considering "alt" as invisible is a very graphical-browser centric view of the web. >Secondly, and more importantly, accessibility issues with the ABBR >pattern have shown that we shouldn't hijack accessibility-related >elements and attributes without a lot of thought. No, but we shouldn't ignore them, either. > Otherwise we may end up with results like: > >
> Picture of a crazy foo > Picture of a crazy foo >
That's bad alt text, even without the contents of the span. >The "caption" and "legend" classes appeared to be semantically >identical. "caption" appears to be what is meant here. Os is this another US vs. UK English issue? >Andy Mabbett wrote: >> Turning to specifics, I think the dismissal of the "include pattern" >>is >> unfortunate and needs to be reversed > > >The draft has always explicitly said that the include pattern *may* be >used. But only in limited circumstances. >It suggests that the ABBR pattern *should not* be used You don't appear to be answering me, here... >because frankly I can't see any reason why it *should* be used. ...but I don't agree that that's a good premise to exclude something, even as a "should not". -- Andy Mabbett From info at weborganics.co.uk Sat Feb 23 14:45:45 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sat Feb 23 14:46:01 2008 Subject: [uf-new] figure microformat In-Reply-To: References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> <1203799926.3716.37.camel@weborganicscouk> Message-ID: <1203806745.4542.31.camel@weborganicscouk> Hello Andy On Sat, 2008-02-23 at 21:36 +0000, Andy Mabbett wrote: > In message <1203799926.3716.37.camel@weborganicscouk>, Martin McEvoy > writes > > >
> > Albert Einstein > > > > of Albert Einstein by > > > > Paul Ehrenfest > > (photographer) > > > >
> > Doesn't Albert deserve his own vcard, too? Do you think? is that not a bit much? would you wrap a vcard around this? "Colored drinking fountain" http://en.wikipedia.org/wiki/Image:ColoredDrinking.jpg > > >photo from hcard to replace image > >http://microformats.org/wiki/hcard#Property_List > > Not all images are photos. Let's please preserve semantics. agreed just trying to re-use ;) > > >cite is just posh > > Albert Einstein is not being cited, in the above example. If anyone is, > it's Ehrenfest. No its the contents that is the subject of a cite. > > >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. agreed > > >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"? Anyway as it Is I think I misunderstood what "figure" was trying to do I thought it was just about annotating all images with captions or attributions. as it happens I don't think it is. Figure is just about decorative or functional images? Ignore anyway :) Thanks Martin McEvoy > From mail at tobyinkster.co.uk Sat Feb 23 17:18:32 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Feb 23 17:18:41 2008 Subject: [uf-new] Re: figure microformat Message-ID: Andy Mabbett wrote: > Toby A Inkster writes > > >The draft has always explicitly said that the include pattern > *may* be > >used. > > But only in limited circumstances. The exact wording is: The include pattern may be used within figures. That is the only mention of the include pattern on the entire page. No mention of any "limited circumstances". Indeed, I'd envisaged the include pattern as being a core part of the microformat -- it may be very useful to provide the legend, or credits as part of the running commentary rather than a separate block underneath the picture. > "caption" appears to be what is meant here. Os is this another US > vs. UK > English issue? It's a practical one. I chose "legend" rather than "caption" because that's what's used in the HTML5 equivalent markup. The HTML5 guys chose to use the element rather than the element because will trigger table-like behaviour in legacy HTML4 browsers. "caption" would otherwise be slightly preferable. Martin McEvoy wrote: > Figure is just about decorative or functional images? It's for marking up the sort of images that might be listed in a "table of figures" at the front of a text book. From the top of the draft spec: > Introduction > > Many HTML documents include supporting images, such as photographs, > flow charts, graphs, blueprints or screen captures. These are > usually incorporated using the HTML element, however this > offers no way of differentiating between such supplementary content > and mere decorative images. > > Authors often wish to annotate these images with captions or > attributions. Currently there is no markup to explicitly associate > such text with an image and readers must rely on the proximity of > the image and text on the finished rendered page. > > This specification aims to allow authors to mark up captions and > credits, explicitly associating them with an image. > -- Toby A Inkster From andy at pigsonthewing.org.uk Sun Feb 24 01:07:01 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 24 01:08:16 2008 Subject: [uf-new] Re: figure microformat In-Reply-To: References: Message-ID: <8xMqRlM1OTwHFwSU@pigsonthewing.org.uk> In message , Toby A Inkster writes >Andy Mabbett wrote: >> Toby A Inkster writes >> >> >The draft has always explicitly said that the include pattern >> *may* be >> >used. >> >> But only in limited circumstances. > >The exact wording is: > The include pattern may be used within figures. > >That is the only mention of the include pattern on the entire page. No >mention of any "limited circumstances". My apologies; I mis-read the following text as being about "include". I suggest a paragraph break be inserted after the above wording; better still, split the section into two, with a heading for each. -- Andy Mabbett From andy at pigsonthewing.org.uk Sun Feb 24 01:15:16 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 24 01:16:20 2008 Subject: [uf-new] Re: figure microformat In-Reply-To: References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> Message-ID: <6horVcNkWTwHFwSf@pigsonthewing.org.uk> In message , Toby A Inkster writes >> Whatever you think of the necessity of alternative text for content >> images, such supplementary uses of ALT and LONGDESC need (it seems to >> me) to have some sort of place in the proposed draft. > >I think these attributes are very important, and that's why we should >avoid overloading them, and allow authors to use them for the very >important purpose for which they were designed. Looking at the example added here: (aka ) it seems foolhardy to discard the alt text. If it is not used as the legend, why not simply mandate a non-null value (i.e. not alt="" or alt=" ") becomes part of the microformat as a property in its own right, so that the example is parsed as: Image: salesdata.png Legend: January sales data Alt: Widget sales have fallen slightly, but widget repair kits have sold well. and similarly with a URL value for "longdesc"? -- Andy Mabbett From andy at pigsonthewing.org.uk Sun Feb 24 01:18:33 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Feb 24 01:19:42 2008 Subject: [uf-new] figure microformat In-Reply-To: <1203806745.4542.31.camel@weborganicscouk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> <1203799926.3716.37.camel@weborganicscouk> <1203806745.4542.31.camel@weborganicscouk> Message-ID: <9xbqh8NpZTwHFwyF@pigsonthewing.org.uk> In message <1203806745.4542.31.camel@weborganicscouk>, Martin McEvoy writes >On Sat, 2008-02-23 at 21:36 +0000, Andy Mabbett wrote: >> In message <1203799926.3716.37.camel@weborganicscouk>, Martin McEvoy >> writes >> >> >
>> > Albert Einstein >> > >> > of Albert Einstein by >> > >> > Paul Ehrenfest >> > (photographer) >> > >> >
>> >> Doesn't Albert deserve his own vcard, too? > >Do you think? is that not a bit much? Yes; and no; respectively. hCards are for "people places and venues". I would warp all such data in an hCard (at least on the first occurrence on the page). >would you wrap a vcard around this? > >"Colored drinking fountain" >http://en.wikipedia.org/wiki/Image:ColoredDrinking.jpg No, because that's not a (named) person, place of venue. [...] >> Albert Einstein is not being cited, in the above example. If anyone is, >> it's Ehrenfest. > >No its the contents that is the subject of a cite. I don't follow what you mean, here. -- Andy Mabbett From davidjanes at blogmatrix.com Sun Feb 24 01:56:31 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Feb 24 01:56:39 2008 Subject: [uf-new] Re: figure microformat In-Reply-To: <6horVcNkWTwHFwSf@pigsonthewing.org.uk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> <6horVcNkWTwHFwSf@pigsonthewing.org.uk> Message-ID: <21e523c20802240156o6feff7e4u9c92dde5538598c3@mail.gmail.com> (1) Not to be a process-prick, but shouldn't all the various ideas not be bandied about as brainstorming options [1] rather than starting with a spec [2]. (2) Any thoughts as to whether using LABEL [3] would work for you ... it's stretching the definition only a little, but validators don't seem to mind. Regards, etc... [1] http://microformats.org/wiki?title=figure-brainstorming&action=edit -- doesn't even exist! [2] http://microformats.org/wiki/figure [3] http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com http://www.onamine.com From info at weborganics.co.uk Sun Feb 24 03:38:13 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun Feb 24 03:38:24 2008 Subject: [uf-new] figure microformat In-Reply-To: <9xbqh8NpZTwHFwyF@pigsonthewing.org.uk> References: <90BDFC58-9A87-46F9-9427-282B13BA19EC@tobyinkster.co.uk> <1203799926.3716.37.camel@weborganicscouk> <1203806745.4542.31.camel@weborganicscouk> <9xbqh8NpZTwHFwyF@pigsonthewing.org.uk> Message-ID: <1203853093.9589.3.camel@weborganicscouk> On Sun, 2008-02-24 at 09:18 +0000, Andy Mabbett wrote: > >No its the contents that is the subject of a cite. > > I don't follow what you mean, here. > no it didn't make much sense did it? Forgive me, you would probably want to cite the author. Please Ignore anyway. Thanks