From andy at pigsonthewing.org.uk Tue Jan 8 15:02:50 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Jan 8 15:03:56 2008 Subject: [uf-new] hCalendar: opening hours In-Reply-To: References: <47670428.9000809@klml.de> Message-ID: In message , Scott Reynen writes >Recurring events are largely uncharted territory in hCalendar, but it >has been discussed. See, for example: > >http://microformats.org/wiki/hcalendar-brainstorming#Recurring_Events >http://www.xfront.com/microformats/hCalendar_part2.html The later references an example recurring event: which Operator parses but X2V does not (yet); and a second example, specifying multiple dates, which Operator does not recognise: Do any other parsers yet recognise such mark-up? -- Andy Mabbett From martin at weborganics.co.uk Fri Jan 11 08:37:11 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Jan 11 08:34:44 2008 Subject: [uf-new] Re: [uf-discuss] hAudio issue: position In-Reply-To: References: Message-ID: <1200069431.3565.15.camel@localhost.localdomain> Hello Andy I have cross posted this email to microformats new as I believe hAudio is still in development and any Issues anyone may have with haudio should really be posted there. On Thu, 2008-01-10 at 23:35 +0000, Andy Mabbett wrote: > The recommended use of "position" in hAudio: > > > > is contrary to the good practice, semantic use of ordered lists ("OL"). > > The mark up on the wiki: > >
> 1. > Sanity > (5:48) >
>
> 2. > Highway To Hell > (3:39) >
> > should be: > >
    >
  1. > Sanity > (5:48) >
    2. >
  2. > Highway To Hell > (3:39) >
    3. >
> > leaving no numerals to be marked up. Position was a late addition because most of the examples we were studying used tables in the design of their web pages, we also found that XOXO or OL doesn't work in tables http://microformats.org/discuss/mail/microformats-new/2007-June/000482.html so now you can do both, use an ordered list without marking up "position" and also use hAudio in tables with the ability to markup position. Thanks Martin McEvoy > From martin at weborganics.co.uk Fri Jan 11 08:46:58 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Jan 11 09:09:39 2008 Subject: [uf-new] Re: [uf-discuss] hAudio rel-enclosure & linking issues In-Reply-To: <8bnVv5j98shHFwpG@pigsonthewing.org.uk> References: <8bnVv5j98shHFwpG@pigsonthewing.org.uk> Message-ID: <1200070018.3565.26.camel@localhost.localdomain> Hello Andy > It would also seem to be inadvisable to use rel="enclosure" for links to > off-site files. Please can you explain a little further why you have an issue with this? It seems sound enough to me :) I have found more often than not that a purchased audio track is rarely downloaded from the website you actually buy the track from. rel="encloseure" simply means that the hyperlink destination is something that can be downloaded or cached? Thanks Martin McEvoy p.s I posted this one too to microformats new ;) the same reasons as before. From andy at pigsonthewing.org.uk Fri Jan 11 12:27:29 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Jan 11 12:29:07 2008 Subject: [uf-new] Re: [uf-discuss] hAudio issue: position In-Reply-To: <1200069431.3565.15.camel@localhost.localdomain> References: <1200069431.3565.15.camel@localhost.localdomain> Message-ID: In message <1200069431.3565.15.camel@localhost.localdomain>, Martin McEvoy writes >I have cross posted this email to microformats new as I believe hAudio >is still in development and any Issues anyone may have with haudio >should really be posted there. Fair enough. >On Thu, 2008-01-10 at 23:35 +0000, Andy Mabbett wrote: >> The recommended use of "position" in hAudio: >> >> >> >> is contrary to the good practice, semantic use of ordered lists ("OL"). >Position was a late addition because most of the examples we were >studying used tables in the design of their web pages, we also found >that XOXO or OL doesn't work in tables >http://microformats.org/discuss/mail/microformats-new/2007-June/000482.html Is position needed to sequence items, or to signify their position of the track on the original album. If the former, then surely order in the source code (in a list, table or whatever) should suffice. If the latter then what's the use case, and which examples support it? Where are the examples of tracks listed out of sequence, in the source code, but with a sequence indicated in content?? >so now you can do both, use an ordered list without marking up >"position" and also use hAudio in tables with the ability to markup >position. I think that providing an alternative to OL in that manner, not to mention encouraging people to use it by having it as an example in the spec, is no better then "p class="heading"> -- Andy Mabbett From andy at pigsonthewing.org.uk Fri Jan 11 13:00:05 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Jan 11 13:01:21 2008 Subject: [uf-new] Re: hAudio rel-enclosure & linking issues In-Reply-To: <1200070018.3565.26.camel@localhost.localdomain> References: <8bnVv5j98shHFwpG@pigsonthewing.org.uk> <1200070018.3565.26.camel@localhost.localdomain> Message-ID: In message <1200070018.3565.26.camel@localhost.localdomain>, Martin McEvoy writes >> It would also seem to be inadvisable to use rel="enclosure" for links to >> off-site files. > >Please can you explain a little further why you have an issue with >this? If I set an agent to cache: which linked to: and: I would expect it to cache the former, but not the latter; any more than I would expect the agent, set to cache: to cache all the myriad pages linked to from there. >It seems sound enough to me :) I have found more often than not that a >purchased audio track is rarely downloaded from the website you >actually buy the track from. If site "A" acts as an agent for site "B", you would not expect a cached version of "A" to include all of the content from "B". The content is not "cacheable", and thus outside the scope of rel-enclosure. Not least if "A" is McEvoy's hobby pages and "B" is MegaCorp Records! >rel="encloseure" simply means that the hyperlink destination is >something that can be downloaded or cached? No; as I indicated previously: By adding rel="enclosure" to a hyperlink, a page indicates that the destination of that hyperlink is intended to be downloaded and cached. I take that to mean that the "enclosure" is an intrinsic part of the document represented by the page; you would expect to find them together. Otherwise, why not mark up every href as an enclosure? I think we need three classes; say: * download for direct links to .mp3 or .wav files, etc. * stream for direct links to .ram files, etc. * source for links to .html files, etc., which link in turn to one of the above. In the use case: User issues instruction to a user-agent to "scan pages until you find one which discusses Beethoven's 'Clair de Lune', then find me a downloadable version so I can put it on my pocket device". the agent should ignore the second type, and use the first or third to find an mp3 or wav. If rel-license becomes part of hAudio (a no-brainer, surely?), along with "type", then the use case could include "find me a freely-downloadable mp3 version..." -- Andy Mabbett From martin at weborganics.co.uk Fri Jan 11 16:11:17 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Jan 11 16:08:49 2008 Subject: [uf-new] Re: hAudio rel-enclosure & linking issues In-Reply-To: References: <8bnVv5j98shHFwpG@pigsonthewing.org.uk> <1200070018.3565.26.camel@localhost.localdomain> Message-ID: <1200096677.5162.33.camel@localhost.localdomain> On Fri, 2008-01-11 at 21:00 +0000, Andy Mabbett wrote: > Otherwise, why not mark up every href as an enclosure? > > > > I think we need three classes; say: > > * download > > for direct links to .mp3 or .wav files, etc. > > * stream > > for direct links to .ram files, etc. I think rel-enclosure is still suitable for the above two examples hAudio rel-enclosure is supposed to have the exact semantic equivalent of an atom:rel-enclosure rel-enclosure is not exclusive to audio files, its any single object, thing that can be downloaded and cached to a users hard drive, or portable device this is a good example of different types of enclosure (mp3 and bit-torrent) http://www.ibm.com/developerworks/xml/library/x-atom10.html#code4 and also the following section (PDF) http://www.ibm.com/developerworks/xml/library/x-atom10.html#code5 > > * source > > for links to .html files, etc., which link in turn to one of > the > above. you may be on to something here a link pointing to a page where a file may be downloaded but is not a rel="payment" url if you are pointing to a html file you can use a bit of POSH rel="section" may be a better way of indicating that the following page is to be considered part or the referencing document and we are not inventing something new? > > In the use case: > > User issues instruction to a user-agent to "scan pages until > you > find one which discusses Beethoven's 'Clair de Lune', then > find > me a downloadable version so I can put it on my pocket > device". > > the agent should ignore the second type, and use the first or third to > find an mp3 or wav. > > If rel-license becomes part of hAudio (a no-brainer, surely?), I think the use of rel-licence already implicitly exists in haudio it just hasn't been discussed yet, i don't see anything wrong with adopting rel-licence +1 from me anyway ;) > along > with "type", rel enclosure does already support a type value File -- audio/mpeg -- application/octet-stream -- application/ogg -- audio/x-ms-wma -- audio/vnd.rn-realaudio Are just a few available types. I KNOW, you know all this just going through it with you :) > then the use case could include "find me a > freely-downloadable mp3 version..." with the inclusion of rel-licence that would be possible don't you think? I do however think we have overlooked how we specify (in Atom) the required length of an enclosure, length as in size of the file on disk. Thanks Martin McEvoy From martin at weborganics.co.uk Fri Jan 11 16:30:34 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Jan 11 16:56:19 2008 Subject: [uf-new] Re: [uf-discuss] hAudio issue: position In-Reply-To: <1200097737.5162.50.camel@localhost.localdomain> References: <1200069431.3565.15.camel@localhost.localdomain> <1200097441.5162.47.camel@localhost.localdomain> <1200097737.5162.50.camel@localhost.localdomain> Message-ID: <1200097834.5162.51.camel@localhost.localdomain> On Sat, 2008-01-12 at 00:29 +0000, Martin McEvoy wrote: > Sorry for cross posting my last two emails It wasn't Intended, will > keep > this discussion to microformats new. > > Thanks > > Martin McEvoy I am a clutz... Ignore... Thanks Martin From martin at weborganics.co.uk Fri Jan 11 16:28:57 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Jan 11 17:24:54 2008 Subject: [uf-new] Re: [uf-discuss] hAudio issue: position In-Reply-To: <1200097441.5162.47.camel@localhost.localdomain> References: <1200069431.3565.15.camel@localhost.localdomain> <1200097441.5162.47.camel@localhost.localdomain> Message-ID: <1200097737.5162.50.camel@localhost.localdomain> Sorry for cross posting my last two emails It wasn't Intended, will keep this discussion to microformats new. Thanks Martin McEvoy On Sat, 2008-01-12 at 00:24 +0000, Martin McEvoy wrote: > Hello Andy > > On Fri, 2008-01-11 at 20:27 +0000, Andy Mabbett wrote: > > I think that providing an alternative to OL in that manner, not to > > mention encouraging people to use it by having it as an example in > > the > > spec, is no better then "p class="heading"> > > I am not going to argue with you on that point I agree in principle, but > unlucky for us the "real world" is much different to the world we are > trying to create, you know as well as I that a lot of designers still > use tables for layouts, most are not interested in validating their > documents, or understand semantics beyond "web3.0"(yuck) or > "twine"(lol), so hAudio has to fit in, in order to be adopted, this is > why the compromise, allow authors to publish hAudio in tables (If they > so wish) and so making hAudio easier to adopt. > > > Thanks > > Martin McEvoy From martin at weborganics.co.uk Fri Jan 11 16:24:01 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Jan 11 17:58:49 2008 Subject: [uf-new] Re: [uf-discuss] hAudio issue: position In-Reply-To: References: <1200069431.3565.15.camel@localhost.localdomain> Message-ID: <1200097441.5162.47.camel@localhost.localdomain> Hello Andy On Fri, 2008-01-11 at 20:27 +0000, Andy Mabbett wrote: > I think that providing an alternative to OL in that manner, not to > mention encouraging people to use it by having it as an example in > the > spec, is no better then "p class="heading"> I am not going to argue with you on that point I agree in principle, but unlucky for us the "real world" is much different to the world we are trying to create, you know as well as I that a lot of designers still use tables for layouts, most are not interested in validating their documents, or understand semantics beyond "web3.0"(yuck) or "twine"(lol), so hAudio has to fit in, in order to be adopted, this is why the compromise, allow authors to publish hAudio in tables (If they so wish) and so making hAudio easier to adopt. Thanks Martin McEvoy From andy at pigsonthewing.org.uk Fri Jan 11 18:06:23 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Fri Jan 11 18:07:52 2008 Subject: [uf-new] Re: hAudio rel-enclosure & linking issues In-Reply-To: <1200096677.5162.33.camel@localhost.localdomain> References: <8bnVv5j98shHFwpG@pigsonthewing.org.uk> <1200070018.3565.26.camel@localhost.localdomain> <1200096677.5162.33.camel@localhost.localdomain> Message-ID: In message <1200096677.5162.33.camel@localhost.localdomain>, Martin McEvoy writes >On Fri, 2008-01-11 at 21:00 +0000, Andy Mabbett wrote: >> * download >> * stream >I think rel-enclosure is still suitable for the above two examples >rel-enclosure is [...] > any single object, >thing that can be downloaded and cached to a users hard drive, or >portable device In addition to my previous comments about off-site files, I'm not convinced that a stream is (as the rel-enclosure spec has it) "intended to be cached". >> * source >> >> for links to .html files, etc., which link in turn to one of >> the >> above. > >you may be on to something here a link pointing to a page where a file >may be downloaded but is not a rel="payment" url Even if it is a payment URL. The payment page may not link directly to the file. >if you are pointing to a html file you can use a bit of POSH >rel="section" may be a better way of indicating that the following page >is to be considered part or the referencing document and we are not >inventing something new? If site A links to a page on site "B" which inks to file "C", that does not make the page on "B" a section of that on "A". >> If rel-license becomes part of hAudio (a no-brainer, surely?), > >I think the use of rel-licence already implicitly exists in haudio it >just hasn't been discussed yet, i don't see anything wrong with adopting >rel-licence > >+1 from me anyway ;) Though of course, current practise may not be to have license terms as links. The text:

The following mp3 is in the public domain.

requires a CLASS, not a REL. I think there is a general issue with requiring @rels where publishers normally use text, not links; contrary to: "microformats are not... an attempt to get everyone to change their behavior..." and: "adapt to current behaviors". Though I see no reason why microformats should not use both, with the same value. In other words == That would also be beneficial for Wikis such as ours, where rel values cannot be used by editors. [Issue logged at ] -- Andy Mabbett From zimbatm at oree.ch Sat Jan 12 09:39:14 2008 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Sat Jan 12 10:08:19 2008 Subject: [uf-new] New proposed microformat: hProject Message-ID: Hello, I propose a new format called hProject. It's intent is to provide a simple structure that describes project. Work has already been started[1] but I would like your input, especially by semantic web experts. -- Cheers, zimbatm [1] : http://microformats.org/wiki/hproject From jeff at jeffmcneill.com Sat Jan 12 10:44:26 2008 From: jeff at jeffmcneill.com (Jeff McNeill) Date: Sat Jan 12 10:44:30 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: References: Message-ID: <519fa62f0801121044j6df8f10bh81c40f664e012661@mail.gmail.com> Hello Jonas, This is an interesting area, but I haven't seen anything about it on these lists before. It may be good to start the discussion as per the http://microformats.org/wiki/process Cheers, -- Sincerely, Jeff McNeill http://jeffmcneill.com/ On 1/12/08, Jonas Pfenniger wrote: > Hello, > > I propose a new format called hProject. It's intent is to provide a > simple structure that describes project. Work has already been > started[1] but I would like your input, especially by semantic web > experts. > > -- > Cheers, > zimbatm > > [1] : http://microformats.org/wiki/hproject > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From m at klml.de Sat Jan 12 12:08:31 2008 From: m at klml.de (Klaus Mueller) Date: Sat Jan 12 12:08:35 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: References: Message-ID: <47891E3F.6010604@klml.de> Hi Jonas, > I propose a new format called hProject. It's intent is to provide a > simple structure that describes project. It seems to me, you mean "hproject" in the meaning of software projects. But there are many other kinds of products or services http://en.wikipedia.org/wiki/Project imho the most important attribute is the temporary character, so you should include hCalendar as an basic format. Or you make an undergroup of hCalendar. just my 2cents Klaus From msporny at digitalbazaar.com Sat Jan 12 12:17:45 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Jan 12 12:17:49 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: <47891E3F.6010604@klml.de> References: <47891E3F.6010604@klml.de> Message-ID: <47892069.6040605@digitalbazaar.com> > I propose a new format called hProject. It's intent is to provide a > simple structure that describes project. I suggest you take a look at DOAP, as the hProject concept already exists in the RDF world: http://www.ibm.com/developerworks/xml/library/x-osproj.html The initiative was started almost 4 years ago... -- manu From andy at pigsonthewing.org.uk Sat Jan 12 12:48:17 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sat Jan 12 12:49:28 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <1200097441.5162.47.camel@localhost.localdomain> References: <1200069431.3565.15.camel@localhost.localdomain> <1200097441.5162.47.camel@localhost.localdomain> Message-ID: <1g$nhX1ReSiHFwTw@pigsonthewing.org.uk> In message <1200097441.5162.47.camel@localhost.localdomain>, Martin McEvoy writes >Hello Andy > >On Fri, 2008-01-11 at 20:27 +0000, Andy Mabbett wrote: >> I think that providing an alternative to OL in that manner, not to >> mention encouraging people to use it by having it as an example in >> the >> spec, is no better then "p class="heading"> By which I meant ...than

>I am not going to argue with you on that point I agree in principle, >but unlucky for us the "real world" is much different to the world we >are trying to create, you know as well as I that a lot of designers >still use tables for layouts, most are not interested in validating >their documents, or understand semantics beyond "web3.0"(yuck) or >"twine"(lol), I really don't think we should accord such bad behaviour credit by catering for it at the expense of good practise. >so hAudio has to fit in I don't think that's a given. >, in order to be adopted, this is why the compromise, allow authors to >publish hAudio in tables (If they so wish) and so making hAudio easier >to adopt. hAudio in tables is a separate issue to bad mark-up, Tables may well be valid, semantically-correct and the best way to mark up a page about number of audio recordings. The use of microformats in tables is itself an issue in need of further thought. For example (this is an illustrative question, not a proposal), should: Name indicate that each cell in that column is to be treated as an FN if there is, say, a vCard across that cell's row? If not, how else might that be achieved? -- Andy Mabbett * Say "NO!" to compulsory UK ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From zimbatm at oree.ch Sat Jan 12 14:25:24 2008 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Sat Jan 12 14:25:28 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: <519fa62f0801121044j6df8f10bh81c40f664e012661@mail.gmail.com> References: <519fa62f0801121044j6df8f10bh81c40f664e012661@mail.gmail.com> Message-ID: 2008/1/12, Jeff McNeill : > Hello Jonas, > > This is an interesting area, but I haven't seen anything about it on > these lists before. It may be good to start the discussion as per the > http://microformats.org/wiki/process Sorry, I missed that page. I'll try to conform to it for the next steps. From martin at weborganics.co.uk Sat Jan 12 14:30:48 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Jan 12 14:28:21 2008 Subject: [uf-new] Re: hAudio rel-enclosure & linking issues In-Reply-To: References: <8bnVv5j98shHFwpG@pigsonthewing.org.uk> <1200070018.3565.26.camel@localhost.localdomain> <1200096677.5162.33.camel@localhost.localdomain> Message-ID: <1200177048.5785.27.camel@localhost.localdomain> On Sat, 2008-01-12 at 02:06 +0000, Andy Mabbett wrote: > In message <1200096677.5162.33.camel@localhost.localdomain>, Martin > McEvoy writes > > >On Fri, 2008-01-11 at 21:00 +0000, Andy Mabbett wrote: > > >> * download > > >> * stream > > >I think rel-enclosure is still suitable for the above two examples > > >rel-enclosure is > [...] > > any single object, > >thing that can be downloaded and cached to a users hard drive, or > >portable device > > In addition to my previous comments about off-site files, I'm not > convinced that a stream is (as the rel-enclosure spec has it) "intended > to be cached". > Streams still have to be cached to be played even if it is only in part, most of the files we talk about are encapsulated streams of some sort? > >> * source > >> > >> for links to .html files, etc., which link in turn to one of > >> the > >> above. > > > >you may be on to something here a link pointing to a page where a file > >may be downloaded but is not a rel="payment" url > > Even if it is a payment URL. The payment page may not link directly to > the file. > True! > > >if you are pointing to a html file you can use a bit of POSH > >rel="section" may be a better way of indicating that the following page > >is to be considered part or the referencing document and we are not > >inventing something new? > > If site A links to a page on site "B" which inks to file "C", that does > not make the page on "B" a section of that on "A". > No it doesn't: Section Refers to a document serving as a section in a collection of documents. http://www.w3.org/TR/html401/types.html#type-links rel values have implied meanings not actual meanings, they also help navigation through a collection of documents. > > > >> If rel-license becomes part of hAudio (a no-brainer, surely?), > > > >I think the use of rel-licence already implicitly exists in haudio it > >just hasn't been discussed yet, i don't see anything wrong with adopting > >rel-licence > > > >+1 from me anyway ;) > > Though of course, current practise may not be to have license terms as > links. The text: > >

The following mp3 is in the public domain.

> > requires a CLASS, not a REL. > Again I AM inclined to agree with you Andy, but class="licence" is something specific maybe:
...hereby either (a) certifies that, to the best of his knowledge, the work of authorship identified... blah..
maybe just:
© 2008 my record company
In the case of cc licences would you put a rel value in there too?
cc Public Domain Licence
there seems to be a conflict of values licence => href => licence class licence seems to be redundant as the href value already describes a link to where a licence may be read? this maybe needs to be an exploratory discussion? into a licence microformat? more expanded than the one cc-licences generally use ie rel="licence"? © 2008 Sub Pop Records, All rights Reserved > > > > I think there is a general issue with requiring @rels where publishers > normally use text, not links; contrary to: > > > > "microformats are not... an attempt to get everyone to change > their behavior..." > > and: > > > > "adapt to current behaviors". > > > Though I see no reason why microformats should not use both, with the > same value. > > In other words > > == > > > That would also be beneficial for Wikis such as ours, where rel values > cannot be used by editors. > > [Issue logged at ] Wiki's are another matter entirely to the general web, most wiki's (including our own) are built with all external links using rel="nofollow" this is purely for SEO purposes (This is my view). Contributors cite relevant external sources, pertinent to the subject or original source that it cites, and no weight is added to the link?, the source gets no credit as far as ranking is concerned (PR), I cant imagine any wiki will ever remove this restriction as it deters SEO's, Spammers, builds Internal linking, thus enhancing ranking (PR). Maybe this is one anti-pattern (that our wise community created) that needs to be dealt with before you start thinking about HOW to work round it? maybe some evangelism in correct usage. Thanks Martin McEvoy From zimbatm at oree.ch Sat Jan 12 14:45:53 2008 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Sat Jan 12 14:45:56 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: <47891E3F.6010604@klml.de> References: <47891E3F.6010604@klml.de> Message-ID: Hi Klaus, thanks for your input. > It seems to me, you mean "hproject" in the meaning of software projects. > But there are many other kinds of products or services > http://en.wikipedia.org/wiki/Project It is right that I have a software-inclined vision of a Project but I hope that other people here will help me to keep it right :) > imho the most important attribute is the temporary character, so you > should include hCalendar as an basic format. Or you make an undergroup > of hCalendar. I don't know. I am not really familiar with hCalendar but 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. For example, the "attending/participating" people often have a hierarchy and a role in a software project. This is something external people could be interested in. I never say a calendar software with such features because you probably already know the place of your boss if you have an appointment with :) -- Cheers, zimbatm From zimbatm at oree.ch Sat Jan 12 14:52:59 2008 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Sat Jan 12 14:53:02 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: <47892069.6040605@digitalbazaar.com> References: <47891E3F.6010604@klml.de> <47892069.6040605@digitalbazaar.com> Message-ID: Hi Manu, 2008/1/12, Manu Sporny : > > I propose a new format called hProject. It's intent is to provide a > > simple structure that describes project. > > I suggest you take a look at DOAP, as the hProject concept already > exists in the RDF world: > > http://www.ibm.com/developerworks/xml/library/x-osproj.html > > The initiative was started almost 4 years ago... Thanks. I already am aware of DOAP. From my judgment, it is an ill-designed and bloated format. Actually, I have only seen a couple of websites using it despite it's 4 year age. It may be a lack of publicity or interest but I think that it also shows that it's too complicated. -- Cheers, zimbatm From davidjanes at blogmatrix.com Sun Jan 13 05:10:07 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun Jan 13 05:10:09 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: References: <47891E3F.6010604@klml.de> <47892069.6040605@digitalbazaar.com> Message-ID: <21e523c20801130510k702e8baes8e5e392fb6c0f86d@mail.gmail.com> Hi Jonas, DOAP is by Python Cheeseshop, so it has at least some deployment [1]. As a broad statement, microformats are more about learning what's out there and using that as a basis for standardization than inventing new standards. Regards, etc... David [1] http://pypi.python.org/pypi/ng.skin.neural/1.0.1 On Jan 12, 2008 5:52 PM, Jonas Pfenniger wrote: > Hi Manu, > > 2008/1/12, Manu Sporny : > > > > I propose a new format called hProject. It's intent is to provide a > > > simple structure that describes project. > > > > I suggest you take a look at DOAP, as the hProject concept already > > exists in the RDF world: > > > > http://www.ibm.com/developerworks/xml/library/x-osproj.html > > > > The initiative was started almost 4 years ago... > > Thanks. I already am aware of DOAP. From my judgment, it is an > ill-designed and bloated format. Actually, I have only seen a couple > of websites using it despite it's 4 year age. It may be a lack of > publicity or interest but I think that it also shows that it's too > complicated. > > -- > Cheers, > zimbatm > > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From danny.ayers at gmail.com Sun Jan 13 10:07:48 2008 From: danny.ayers at gmail.com (Danny Ayers) Date: Sun Jan 13 10:07:51 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: <47892069.6040605@digitalbazaar.com> References: <47891E3F.6010604@klml.de> <47892069.6040605@digitalbazaar.com> Message-ID: <1f2ed5cd0801131007l303a15a9w90d1acd496d6c136@mail.gmail.com> On 12/01/2008, Manu Sporny wrote: > > I propose a new format called hProject. It's intent is to provide a > > simple structure that describes project. > > I suggest you take a look at DOAP, as the hProject concept already > exists in the RDF world: > > http://www.ibm.com/developerworks/xml/library/x-osproj.html also http://usefulinc.com/doap/ I've been (kind-of) working on a general-purpose RDF vocabulary for projects (i.e. not just software) for a while now: http://purl.org/stuff/project/ I'm hoping to get around to (kind-of) finishing it sometime soon, as I'm using parts of it on a daily basis: http://dannyayers.com/2007/11/02/more-dogfood The idea of a project microformat has been raised before (and I presumably posted similar links :-) - At the time I think it was Tantek pointed to the TODO construct in iCalendar. I'm not sure if this ever made it into hCalendar, but the thing is pretty much ready to use. (I'd map it to instances of prj:Task). As Klaus suggested, the date constructs from hCalendar would also be useful, along with people from hCard. Cheers, Danny. -- http://dannyayers.com From jeff at jeffmcneill.com Sun Jan 13 10:35:25 2008 From: jeff at jeffmcneill.com (Jeff McNeill) Date: Sun Jan 13 10:35:27 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: <1f2ed5cd0801131007l303a15a9w90d1acd496d6c136@mail.gmail.com> References: <47891E3F.6010604@klml.de> <47892069.6040605@digitalbazaar.com> <1f2ed5cd0801131007l303a15a9w90d1acd496d6c136@mail.gmail.com> Message-ID: <519fa62f0801131035w307b0950kea07bb17c33805d5@mail.gmail.com> Hello, Re: projects: - Dependencies and budgets would be helpful to generate things like PERT and GANNT charts. -- Sincerely, Jeff McNeill http://jeffmcneill.com/ From danny.ayers at gmail.com Sun Jan 13 10:36:46 2008 From: danny.ayers at gmail.com (Danny Ayers) Date: Sun Jan 13 10:36:49 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: References: <47891E3F.6010604@klml.de> <47892069.6040605@digitalbazaar.com> Message-ID: <1f2ed5cd0801131036u6000186g79f11ecb00f869e@mail.gmail.com> Oops, I just remembered hDOAP - my projection of DOAP into HTML. It's not an official microformat because it hasn't been through the process. But it's already deployed on at least one site, so I guess that's part of the process started... http://dannyayers.com:88/xmlns/hdoap/profile/hdoap-index.html (the URL should be http://purl.org/stuff/hdoap but I appear to have messed up my Apache config) http://doapspace.org/ > Thanks. I already am aware of DOAP. From my judgment, it is an > ill-designed and bloated format. Actually, I have only seen a couple > of websites using it despite it's 4 year age. It may be a lack of > publicity or interest but I think that it also shows that it's too > complicated. It doesn't especially complicated to me, in fact if something like this example were expressed in HTML I'm pretty sure it'd look a whole lot worse: http://doapspace.org/view_source/sf/jpen The criticism of bloat doesn't hold - you should only use the terms you need, you can ignore the rest (that's the general case with RDF). Not sure about being ill-designed, the docs on the IBM site put together a pretty good case I'd say. There's no doubt that most RDF/XML does look complicated, but the important part of DOAP (and other RDF vocabularies) is the domain model, the serialization format is secondary. If you *must* look at the raw data, then RDF's Turtle syntax is clearer, e.g. from the sample above: @prefix : . [ a :Project; :name "jpen"; :description "Java library for accessing pen/digitizer tablets and pointing devices" ; :homepage ] But then tools can save you even that complication: http://crschmidt.net/semweb/doapamatic/ Cheers, Danny. -- http://dannyayers.com From Michael.Smethurst at bbc.co.uk Mon Jan 14 09:19:34 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Mon Jan 14 09:19:39 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <1g$nhX1ReSiHFwTw@pigsonthewing.org.uk> Message-ID: On 12/1/08 20:48, "Andy Mabbett" wrote: > In message <1200097441.5162.47.camel@localhost.localdomain>, Martin > McEvoy writes > >> Hello Andy >> >> On Fri, 2008-01-11 at 20:27 +0000, Andy Mabbett wrote: >>> I think that providing an alternative to OL in that manner, not to >>> mention encouraging people to use it by having it as an example in >>> the >>> spec, is no better then "p class="heading"> > >> I am not going to argue with you on that point I agree in principle, >> but unlucky for us the "real world" is much different to the world we >> are trying to create, you know as well as I that a lot of designers >> still use tables for layouts, most are not interested in validating >> their documents, or understand semantics beyond "web3.0"(yuck) or >> "twine"(lol), > > I really don't think we should accord such bad behaviour credit by > catering for it at the expense of good practise. > >> , in order to be adopted, this is why the compromise, allow authors to >> publish hAudio in tables (If they so wish) and so making hAudio easier >> to adopt. > > hAudio in tables is a separate issue to bad mark-up, Tables may well be > valid, semantically-correct and the best way to mark up a page about > number of audio recordings. The use of microformats in tables is itself > an issue in need of further thought. > > For example (this is an illustrative question, not a proposal), should: > > Name > > indicate that each cell in that column is to be treated as an FN if > there is, say, a vCard across that cell's row? If not, how else might > that be achieved? Marking up audio in tables makes perfect sense in many cases Given a tracklist for a radio programme it's a tuple of artist, track name, release title, label, possibly track position on release. Which looks like a table to me. Even if marked up as an ordered list the implied ordinality would be that of the track in the programme episode, not that of the track on the release In the case of classical music identifying the track played by ordinality on the release is extremely useful. So a way to markup ordinality other than as a list would be preferable http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From andy at pigsonthewing.org.uk Mon Jan 14 09:43:53 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Jan 14 09:43:55 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: References: <1g$nhX1ReSiHFwTw@pigsonthewing.org.uk> Message-ID: <29605.80.249.57.38.1200332633.squirrel@www.gradwell.com> On Mon, January 14, 2008 17:19, Michael Smethurst wrote: > In the case of classical music identifying the track played by ordinality > on the release is extremely useful. So a way to markup ordinality other > than as a list would be preferable In the following, for "piece" read "piece", "sequence" or some other term: Piece 1, part 1 Piece 1, part 2 Piece 1, part 3 Piece 1, part 4 Piece 2, part 1 Piece 2, part 2 Piece 2, part 3 Piece 2, part 4 or: Piece 1, part 1 Piece 1, part 2 Piece 1, part 3 Piece 1, part 4 Piece 2, part 1 Piece 2, part 2 Piece 2, part 3 Piece 2, part 4 though the latter again causes problems in tables (unless a TBODY is used for each piece; which is arguably good practice). "Item" is an absolutely awful (and semantically-barren) name; it might be best to use "piece and "subpiece" or something like that, assuming that the piece's name is shown (unlike the above examples). Perhaps you have some real examples in mind? How any levels of sub-division are there? I have recently posted links to others' efforts to solve the problem of codifying the structure of disparate types of music: on the wiki. In particular, see: -- Andy Mabbett ** via webmail ** From m at klml.de Mon Jan 14 10:35:40 2008 From: m at klml.de (Klaus Mueller) Date: Mon Jan 14 10:35:46 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: References: <47891E3F.6010604@klml.de> Message-ID: <478BAB7C.8000800@klml.de> Hi all, > I don't know. I am not really familiar with hCalendar but 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. Yes, you are right, time is a important thing, but not the only > For > example, the "attending/participating" people often have a hierarchy > and a role in a software project. This is something external people > could be interested in. I never say a calendar software with such > features because you probably already know the place of your boss if > you have an appointment with :) > > ok, i added some of your ideas and others to the wiki http://microformats.org/wiki/project greetz klml From Michael.Smethurst at bbc.co.uk Tue Jan 15 02:08:37 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Tue Jan 15 02:08:43 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <29605.80.249.57.38.1200332633.squirrel@www.gradwell.com> Message-ID: I suspect I've thrown a red herring into the mix with the mention of classical music... apologies My point was really that when a track from an album is played in isolation from that album (so on a radio episode tracklist or in a personal playlist) the track position on the album is still important data. Which means encoding this data as a property of the list ordering wouldn't work here. So I'd vote to keep position as a separate attribute I threw classical into the mix cos sometimes multiple tracks on an album can have the same title (dependent on how the record company has segmented the audio). In this case the track number is necessary to disambiguate which track was played The same is also true of audio books which often have multiple tracks per chapter all having the same chapter title. Somewhat embarrassingly my ipod currently contains Alan Bennett reading The Wind in the Willows were: Track 1 = The River Bank Track 2 = The River Bank Track 3 = The Open Road Track 4 = The Open Road Etc In terms of marking up acts and scenes and movements and works and etc I'd encourage hAudio to steer well clear. It's a hideous minefield and I suspect hAudio can solve 80% of the problem by avoiding this stuff. For an idea of the complexity I'd point semweb minded people at the fine work of Yves Raimond on the music ontology (which incidentally it would be nice to see used in the rdf-a hAudio spec): http://musicontology.com/ On 14/1/08 17:43, "Andy Mabbett" wrote: > On Mon, January 14, 2008 17:19, Michael Smethurst wrote: > >> In the case of classical music identifying the track played by ordinality >> on the release is extremely useful. So a way to markup ordinality other >> than as a list would be preferable > > > In the following, for "piece" read "piece", "sequence" or some other term: > > Piece 1, part 1 > Piece 1, part 2 > Piece 1, part 3 > Piece 1, part 4 > Piece 2, part 1 > Piece 2, part 2 > Piece 2, part 3 > Piece 2, part 4 > > or: > > > Piece 1, part 1 > Piece 1, part 2 > Piece 1, part 3 > Piece 1, part 4 > > > Piece 2, part 1 > Piece 2, part 2 > Piece 2, part 3 > Piece 2, part 4 > > > though the latter again causes problems in tables (unless a TBODY is used > for each piece; which is arguably good practice). > > "Item" is an absolutely awful (and semantically-barren) name; it might be > best to use "piece and "subpiece" or something like that, assuming that > the piece's name is shown (unlike the above examples). > > Perhaps you have some real examples in mind? How any levels of > sub-division are there? > > I have recently posted links to others' efforts to solve the problem of > codifying the structure of disparate types of music: > > > > on the wiki. In particular, see: > > http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From zimbatm at oree.ch Tue Jan 15 03:13:55 2008 From: zimbatm at oree.ch (Jonas Pfenniger) Date: Tue Jan 15 03:13:58 2008 Subject: [uf-new] New proposed microformat: hProject In-Reply-To: <478BAB7C.8000800@klml.de> References: <47891E3F.6010604@klml.de> <478BAB7C.8000800@klml.de> Message-ID: Thank you all for your inputs. I'll now start filling the blanks and come back when something's done. -- Cheers, zimbatm From andy at pigsonthewing.org.uk Tue Jan 15 05:16:46 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Jan 15 05:16:53 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: References: <29605.80.249.57.38.1200332633.squirrel@www.gradwell.com> Message-ID: <39783.80.249.57.38.1200403006.squirrel@www.gradwell.com> On Tue, January 15, 2008 10:08, Michael Smethurst wrote: > I suspect I've thrown a red herring into the mix with the mention of > classical music... apologies I don't think it is a red herring; I think it's quite important that classical music is taken into account (there is plenty of evidence to show that it's published, after all); otherwise we'll have hPop, not hAudio. > My point was really that when a track from an album is played in > isolation from that album (so on a radio episode tracklist or in a > personal playlist) the track position on the album is still important > data. Which means encoding this data as a property of the list ordering > wouldn't work here. So I'd vote to keep position as a separate attribute Where's the evidence to show that this is published? > I threw classical into the mix cos sometimes multiple tracks on an album > can have the same title (dependent on how the record company has segmented > the audio). In this case the track number is necessary to disambiguate > which track was played Perhaps, but that's also true of pop, rock and other genres, albeit less common - though there is an album, "The Best of Louie Louie" (Rhino Records) comprising nothing but versions of 'Louie Louie'. > In terms of marking up acts and scenes and movements and works and etc > I'd encourage hAudio to steer well clear. It's a hideous minefield Surely that shouldn't put us off? Not least because lack of such a facility may impact on uptake. According to the "process", we should find a way to mark up what the evidence shows us is published; not just the easy bits. > and I suspect hAudio can solve 80% of the problem by avoiding this stuff. I've never been satisfied that it's OK for 1 in 5 cases to be ignored, or, worse, wrong. > For an idea of the complexity I'd point semweb minded people at the fine > work of Yves Raimond on the music ontology (which incidentally it would be > nice to see used in the rdf-a hAudio spec): > > http://musicontology.com/ Thanks; I'll read that later. -- Andy Mabbett ** via webmail ** From msporny at digitalbazaar.com Tue Jan 15 08:18:36 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Jan 15 08:18:40 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: References: Message-ID: <478CDCDC.2070407@digitalbazaar.com> Michael Smethurst wrote: > In terms of marking up acts and scenes and movements and works and etc I'd > encourage hAudio to steer well clear. It's a hideous minefield and I suspect > hAudio can solve 80% of the problem by avoiding this stuff. Hmmm... Perhaps I'm missing something, but hAudio can already mark up operatic pieces: http://microformats.org/wiki/haudio#Opera_Example POSITION is a loose descriptor of where the piece fits in if it is part of a collection of some kind. It is most useful when the other pieces are not listed on the same page. Position can be: 1. The position of the track on a CD. 2. Podcast # of the recording. 3. The position on a top-10 list. 4. The physical position on a CD set of an Operatic piece. 5. The side and track # of an LP (ie: A1, B2) 6. Specified in TABLE elements. 7. Can be specified out-of-sequence. I don't think we avoided the problem when putting position in there... it takes on the challenges of positional identifiers for audio recordings. If we take position out of the hAudio spec, we lose support for all of the use cases listed above. If you want further proof, look at the examples... or I can give examples of pages to prove my point. (I say that somewhat sarcastically, because you can almost always find examples online to prove a point in Microformats). > For an idea of > the complexity I'd point semweb minded people at the fine work of Yves > Raimond on the music ontology (which incidentally it would be nice to see > used in the rdf-a hAudio spec): > > http://musicontology.com/ There will probably be multiple OWL mappings from hAudio RDF to MusicOntology RDF... for example: I've been thinking about heavy re-use of MusicOntology (which is great, if you need to do more than just markup albums/tracks). The big mistake I think the MO folks made was putting properties in there that should have been just plain URIs: http://musicontology.com/#term_myspace http://musicontology.com/#term_amazon_asin http://musicontology.com/#term_musicmoz It's so incredibly heavyweight that it makes most people's heads spin when attempting to just simply mark up a song. That being said, there will still be mappings from one to the other (or re-use of some of the MO vocabulary in the hAudio RDF. -- manu From Michael.Smethurst at bbc.co.uk Tue Jan 15 08:46:01 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Tue Jan 15 08:46:05 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <478CDCDC.2070407@digitalbazaar.com> Message-ID: On 15/1/08 16:18, "Manu Sporny" wrote: > Michael Smethurst wrote: >> In terms of marking up acts and scenes and movements and works and etc I'd >> encourage hAudio to steer well clear. It's a hideous minefield and I suspect >> hAudio can solve 80% of the problem by avoiding this stuff. > > Hmmm... Perhaps I'm missing something, but hAudio can already mark up > operatic pieces: > > http://microformats.org/wiki/haudio#Opera_Example > > POSITION is a loose descriptor of where the piece fits in if it is part > of a collection of some kind. It is most useful when the other pieces > are not listed on the same page. > > Position can be: > > 1. The position of the track on a CD. > 2. Podcast # of the recording. > 3. The position on a top-10 list. > 4. The physical position on a CD set of an Operatic piece. > 5. The side and track # of an LP (ie: A1, B2) > 6. Specified in TABLE elements. > 7. Can be specified out-of-sequence. > > I don't think we avoided the problem when putting position in there... > it takes on the challenges of positional identifiers for audio > recordings. If we take position out of the hAudio spec, we lose support > for all of the use cases listed above. > Again I apologise. I didn't mean that hAudio doesn't handle positioning in these groups. It does and again I vote to retain position as is Just meant that in general haudio doesn't model works vs performances vs recordings etc. And again I don't think it should attempt to touch this complexity Which I think means we're in agreement?!? > >> For an idea of >> the complexity I'd point semweb minded people at the fine work of Yves >> Raimond on the music ontology (which incidentally it would be nice to see >> used in the rdf-a hAudio spec): >> >> http://musicontology.com/ > > There will probably be multiple OWL mappings from hAudio RDF to > MusicOntology RDF... for example: > > > rdf:resource="http://purl.org/ontology/mo/Recording"/> > cool > > I've been thinking about heavy re-use of MusicOntology (which is great, > if you need to do more than just markup albums/tracks). The big mistake > I think the MO folks made was putting properties in there that should > have been just plain URIs: > > http://musicontology.com/#term_myspace > http://musicontology.com/#term_amazon_asin > http://musicontology.com/#term_musicmoz I'll let yves fight his own corner here ;-) > > It's so incredibly heavyweight that it makes most people's heads spin > when attempting to just simply mark up a song. That being said, there > will still be mappings from one to the other (or re-use of some of the > MO vocabulary in the hAudio RDF. Smashing! > > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From yves.raimond at gmail.com Tue Jan 15 08:51:33 2008 From: yves.raimond at gmail.com (Yves Raimond) Date: Tue Jan 15 08:51:36 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <478CDCDC.2070407@digitalbazaar.com> References: <478CDCDC.2070407@digitalbazaar.com> Message-ID: <82593ac00801150851sa95e8eal6d4060c634c077bc@mail.gmail.com> Hello! (Waking up after a long, long lurking on this list - so hello everyone! and congratulations for the great job you've done!! :) ) > Position can be: > > 1. The position of the track on a CD. > 2. Podcast # of the recording. > 3. The position on a top-10 list. > 4. The physical position on a CD set of an Operatic piece. > 5. The side and track # of an LP (ie: A1, B2) > 6. Specified in TABLE elements. > 7. Can be specified out-of-sequence. > > I don't think we avoided the problem when putting position in there... > it takes on the challenges of positional identifiers for audio > recordings. If we take position out of the hAudio spec, we lose support > for all of the use cases listed above. I agree the POSITION descriptor provides a loose descriptor for such information, and will be ok for a good number of use cases. However, I think that Michael was more referring to was how several "parts" relate to each other - eg. how could we relate the third act 3 of "La Boheme" (the work) and two performances of this act (which may not have the same POSITION, within their whole - the performance). > > If you want further proof, look at the examples... or I can give > examples of pages to prove my point. (I say that somewhat sarcastically, > because you can almost always find examples online to prove a point in > Microformats). > > > For an idea of > > the complexity I'd point semweb minded people at the fine work of Yves > > Raimond on the music ontology (which incidentally it would be nice to see > > used in the rdf-a hAudio spec): > > > > http://musicontology.com/ > > There will probably be multiple OWL mappings from hAudio RDF to > MusicOntology RDF... for example: > > > rdf:resource="http://purl.org/ontology/mo/Recording"/> > > > I've been thinking about heavy re-use of MusicOntology (which is great, > if you need to do more than just markup albums/tracks). The big mistake > I think the MO folks made was putting properties in there that should > have been just plain URIs: > > http://musicontology.com/#term_myspace > http://musicontology.com/#term_amazon_asin > http://musicontology.com/#term_musicmoz > > It's so incredibly heavyweight that it makes most people's heads spin > when attempting to just simply mark up a song. That being said, there > will still be mappings from one to the other (or re-use of some of the > MO vocabulary in the hAudio RDF. Hmm - I don't really get this point... These properties are similar in spirit than the foaf:homepage one (they actually subsume it), and are here to link an URI identifying an artist to a web document one (hence the foaf:Document range). So from the URI of an artist, you can relate to different web documents in different places about him (try the Musicbrainz dataset for examples of this one). Although I do agree that if this document was GRDDL-able, we could use a owl:sameAs relationship here, or directly reuse the URI. Cheers! y From andy at pigsonthewing.org.uk Tue Jan 15 08:57:27 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Jan 15 08:57:30 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <478CDCDC.2070407@digitalbazaar.com> References: <478CDCDC.2070407@digitalbazaar.com> Message-ID: <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> On Tue, January 15, 2008 16:18, Manu Sporny wrote: > POSITION is a loose descriptor of where the piece fits in if it is part > of a collection of some kind. It is most useful when the other pieces are > not listed on the same page. > > Position can be: > 1. The position of the track on a CD. > 2. Podcast # of the recording. > 3. The position on a top-10 list. > 4. The physical position on a CD set of an Operatic piece. > 5. The side and track # of an LP (ie: A1, B2) > 6. Specified in TABLE elements. > 7. Can be specified out-of-sequence. Isn't it overloading, to put so many meanings onto one attribute? > I don't think we avoided the problem when putting position in there... > it takes on the challenges of positional identifiers for audio recordings. > If we take position out of the hAudio spec, we lose support > for all of the use cases listed above. I don't think anyone wants to not support those use-cases; but to do so in a way which encourages people to drop good, semantic mark-up and use bad, non-semantic mark-up isn't supportable. -- Andy Mabbett ** via webmail ** From msporny at digitalbazaar.com Tue Jan 15 08:59:51 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Jan 15 09:28:07 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: References: Message-ID: <478CE687.4080208@digitalbazaar.com> Michael Smethurst wrote: > Again I apologise. No need to... these discussions are very helpful to have... > Just meant that in general haudio doesn't model works vs performances vs > recordings etc. And again I don't think it should attempt to touch this > complexity > > Which I think means we're in agreement?!? Yes, we are in agreement. :) -- manu From msporny at digitalbazaar.com Tue Jan 15 09:29:15 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue Jan 15 14:58:07 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> References: <478CDCDC.2070407@digitalbazaar.com> <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> Message-ID: <478CED6B.1010503@digitalbazaar.com> Andy Mabbett wrote: > On Tue, January 15, 2008 16:18, Manu Sporny wrote: > >> POSITION is a loose descriptor of where the piece fits in if it is part >> of a collection of some kind. It is most useful when the other pieces are >> not listed on the same page. >> >> Position can be: > >> 1. The position of the track on a CD. >> 2. Podcast # of the recording. >> 3. The position on a top-10 list. >> 4. The physical position on a CD set of an Operatic piece. >> 5. The side and track # of an LP (ie: A1, B2) >> 6. Specified in TABLE elements. >> 7. Can be specified out-of-sequence. > > Isn't it overloading, to put so many meanings onto one attribute? They're all positions, aren't they? They all have the same meaning. I haven't seen a proposal yet that can do better than POSITION does currently... -- manu From andy at pigsonthewing.org.uk Wed Jan 16 01:11:23 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Jan 16 01:12:59 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <478CED6B.1010503@digitalbazaar.com> References: <478CDCDC.2070407@digitalbazaar.com> <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> <478CED6B.1010503@digitalbazaar.com> Message-ID: In message <478CED6B.1010503@digitalbazaar.com>, Manu Sporny writes >Andy Mabbett wrote: >> On Tue, January 15, 2008 16:18, Manu Sporny wrote: >> >>> POSITION is a loose descriptor of where the piece fits in if it is part >>> of a collection of some kind. It is most useful when the other pieces are >>> not listed on the same page. >>> >>> Position can be: >> >>> 1. The position of the track on a CD. >>> 2. Podcast # of the recording. >>> 3. The position on a top-10 list. >>> 4. The physical position on a CD set of an Operatic piece. >>> 5. The side and track # of an LP (ie: A1, B2) >>> 6. Specified in TABLE elements. >>> 7. Can be specified out-of-sequence. >> >> Isn't it overloading, to put so many meanings onto one attribute? > >They're all positions, aren't they? They all have the same meaning. Items 1-5 have different meanings; that's why you were able to list fire items, not just one. How would you mark up position in: At number two in the chart this week is Pink Floyd's "Fearless", track 3 on their Meddle album. Or, rather, which of the two different kinds of position would you mark up? -- Andy Mabbett From pmw57 at xtra.co.nz Wed Jan 16 02:20:33 2008 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Wed Jan 16 02:20:35 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: <18050cf90801160220j41cbe870y46a332a09e8a7c02@mail.gmail.com> On Jan 16, 2008 10:11 PM, Andy Mabbett wrote: > How would you mark up position in: > > At number two in the chart this week is Pink Floyd's "Fearless", > track 3 on their Meddle album. > > Or, rather, which of the two different kinds of position would you mark > up? I would use an include pattern for the information that belongs in multiple sections, which neatly resolves such issues. -- Paul Wilkins From andy at pigsonthewing.org.uk Wed Jan 16 03:05:29 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Jan 16 04:37:53 2008 Subject: [uf-new] Re: hAudio issue: position In-Reply-To: <18050cf90801160220j41cbe870y46a332a09e8a7c02@mail.gmail.com> References: <478CDCDC.2070407@digitalbazaar.com> <50479.80.249.57.38.1200416247.squirrel@www.gradwell.com> <478CED6B.1010503@digitalbazaar.com> <18050cf90801160220j41cbe870y46a332a09e8a7c02@mail.gmail.com> Message-ID: <53476.80.249.57.38.1200481529.squirrel@www.gradwell.com> On Wed, January 16, 2008 10:20, Paul Wilkins wrote: > On Jan 16, 2008 10:11 PM, Andy Mabbett wrote: > >> How would you mark up position in: >> >> >> At number two in the chart this week is Pink Floyd's "Fearless", >> track 3 on their Meddle album. >> >> Or, rather, which of the two different kinds of position would you mark >> up? > > I would use an include pattern for the information that belongs in > multiple sections, which neatly resolves such issues. That's not "information that belongs in multiple sections", but - apparently - "multiple information that belongs in one section". But please feel free to post an example. -- Andy Mabbett ** via webmail ** From info at weborganics.co.uk Thu Jan 31 10:39:52 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Jan 31 10:39:59 2008 Subject: [uf-new] hAudio FN or Title Message-ID: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> 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 From msporny at digitalbazaar.com Thu Jan 31 11:00:48 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Jan 31 12:58:22 2008 Subject: [uf-new] 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: <47A21AE0.6060501@digitalbazaar.com> Martin McEvoy wrote: > 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. 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. I'd be a very strong supporter of Dublin Core's use in Microformats, especially hAudio. Note that hAudio RDFa already re-uses the Dublin Core metadata vocabulary: http://wiki.digitalbazaar.com/en/HAudio_RDFa The main disagreement seemed to be in DC's choice of class names (DC.title, DC.contributor, DC.date). What about this for a Dublin Core Microformat: dc-title dc-date dc-description ... and on. This approach has two benefits: * It uses Microformat-like names. * It re-uses a vocabulary that is largely accepted in the web semantics community. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Intro to the Semantic Web in 6 minutes (video) http://blog.digitalbazaar.com/2007/12/26/semantic-web-intro From brian.suda at gmail.com Thu Jan 31 13:30:56 2008 From: brian.suda at gmail.com (Brian Suda) Date: Thu Jan 31 13:58:18 2008 Subject: [uf-new] hAudio FN or Title In-Reply-To: <47A21AE0.6060501@digitalbazaar.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A21AE0.6060501@digitalbazaar.com> Message-ID: <21e770780801311330n1b62197dm99be90db133b462e@mail.gmail.com> 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... > 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. > * It re-uses a vocabulary that is largely accepted in the web semantics > community. --- 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 coping 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. -brian -- brian suda http://suda.co.uk From info at weborganics.co.uk Thu Jan 31 13:55:47 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu Jan 31 14:02:39 2008 Subject: [uf-new] hAudio FN or Title In-Reply-To: <47A21AE0.6060501@digitalbazaar.com> References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A21AE0.6060501@digitalbazaar.com> Message-ID: <1201816547.21972.22.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> On Thu, 2008-01-31 at 14:00 -0500, Manu Sporny wrote: > Martin McEvoy wrote: > > 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. > > 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. three questions 1, Why? use dc-terms for hAudio? you could just as easily use RSS naming conventions, or XSPF and have relevant audio related information in the class names. 2, Is Inventing a whole dc related microformats vocab' really necessary, seems a bit overkill to me just to try and solve a title Issue 3, Do you think a DC microformat needs a separate discussion? then when that is finalized then talk about hAudio adopting it. > > I'd be a very strong supporter of Dublin Core's use in Microformats, > especially hAudio. Note that hAudio RDFa already re-uses the Dublin Core > metadata vocabulary: > > http://wiki.digitalbazaar.com/en/HAudio_RDFa Yes Great stuff manu.. the example is still Live http://weborganics.co.uk/files/hAudio-RDFa.xhtml > > The main disagreement seemed to be in DC's choice of class names > (DC.title, DC.contributor, DC.date). What about this for a Dublin Core > Microformat: > > dc-title > dc-date > dc-description > ... and on. > > This approach has two benefits: > > * It uses Microformat-like names. > * It re-uses a vocabulary that is largely accepted in the web semantics > community. This seems more like re-inventing microformats? Is there a problem case that says that a dc-microformat is needed? the only thing I can bring to mind is a "Licence" microformat that could contain dc naming terms. Thanks Martin > > -- manu > From andy at pigsonthewing.org.uk Thu Jan 31 15:26:51 2008 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Thu Jan 31 16:21:40 2008 Subject: [uf-new] hAudio FN or Title In-Reply-To: <21e770780801311330n1b62197dm99be90db133b462e@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> Message-ID: In message <21e770780801311330n1b62197dm99be90db133b462e@mail.gmail.com>, Brian Suda writes >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 pseudo namespace DC-foobar has been discouraged before. Quite aside from the fact that previous discouragement does not negate the current proposal; DC can be considered as "grandfathered". >simply coping all of dublin >core seems to be a solution to a non-problem. It's not a "non-problem". 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. -- Andy Mabbett From pmw57 at xtra.co.nz Thu Jan 31 20:19:52 2008 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Thu Jan 31 20:27:10 2008 Subject: [uf-new] hAudio FN or Title In-Reply-To: References: <1201804792.19587.16.camel@cpc3-blac3-0-0-cust324.manc.cable.ntl.com> <47A21AE0.6060501@digitalbazaar.com> <21e770780801311330n1b62197dm99be90db133b462e@mail.gmail.com> Message-ID: <18050cf90801312019h58b8734frb45baa9b28965461@mail.gmail.com> 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. -- Paul Wilkins