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.aye