From martin at weborganics.co.uk Fri Aug 1 01:42:40 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Aug 1 01:42:48 2008 Subject: [uf-new] hAudio - "sample" propagation from child to parent Message-ID: <4892CC80.609@weborganics.co.uk> Hey Toby, > I have a suggestion that the "sample" property microformats.org/wiki/hAudio#Sample> be made an exception and that > the spec suggest that parsers *MAY* propagate the sample property > from children to the parent. This is because a sample of music from a > track on an album may surely also be taken to be a sample of the album. > I agree, even if there are ten tracks on an album all with samples these should be regarded as samples from the album too. +1 Martin From martin at weborganics.co.uk Mon Aug 4 06:05:17 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 4 06:05:29 2008 Subject: [uf-new] hAudio contributor Issue Message-ID: <4896FE8D.4020105@weborganics.co.uk> There are not many hAudio issues to be resolved, most of which are pretty easy to deal with I think, most are just minor issues with the Specification. Issue 1 raised by Andy Mabbett in http://microformats.org/discuss/mail/microformats-discuss/2008-January/011340.html "the wording about |contributor| could be improved to facilitate more streamlined mark-up" The Point in question is this from http://microformats.org/wiki/haudio#Contributor > The contents of the element SHOULD include a valid hCard > Microformat > Andy Suggest that [...] or [...] Should be acceptable, as well as (I would imagine) this [...] Changing the spec to read > The contributor's *name* SHOULD also be marked up as a valid > hCard > Microformat Anyway I think this is a non issue because its more to do with parsing and not the actual spec itself I personally would not recommend that a haudio contributor be marked up like this [...] It expresses no semantics, however this does... [...] vcards are people and places and can be associated directly with the haudio tracks or albums they are embedded in. The only way the current specification could be clarified more is by adding ".. the contents of contributor MAY be specified in plain text" If this does not cause any problems I would like to close this issue. Thanks Martin McEvoy From martin at weborganics.co.uk Mon Aug 4 06:52:29 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 4 06:52:39 2008 Subject: [uf-new] hAudio Issue Duration Message-ID: <4897099D.8070306@weborganics.co.uk> The hAudio Duration issue has only really been raised on the list by Andy Mabbet and Ben Ward, basicaly this sucks! 3 minutes 23 seconds http://microformats.org/wiki/haudio#Duration why? 1, the obvious abbr abuse, which is shameful for a new microformat and I wont go into here 2, Its not human friendly, Its difficult for a human to understand 3, SoundCloud http://soundcloud.com/ which is a fantastic application with lots of audio were going to roll out haudio in a big way seemed to drop haudio support when I expained the haudio duration format to them, I guess they didn't want all that garbage in peoples faces :-( There are (in my view) only three real ways to resolve this issue 1, Drop haudio duration support only unlil the abbr design pattern issue is resolved. 2 Wait unlil HTML5 is published and use the element. 3 Support NLP (Natural Language Processing) 3 minutes 23 seconds. I personally am in favour of number 3 as I believe it is not too difficult to build a parser that will process just durations (hours minutes seconds) as long as there is an agreed format. Thanks Martin McEvoy From brian.suda at gmail.com Mon Aug 4 07:55:40 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Aug 4 07:55:45 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <4897099D.8070306@weborganics.co.uk> References: <4897099D.8070306@weborganics.co.uk> Message-ID: <21e770780808040755l671a058ei217fe2997914fdd8@mail.gmail.com> 2008/8/4, Martin McEvoy : > There are (in my view) only three real ways to resolve this issue > ... > 3 Support NLP (Natural Language Processing) 3 > minutes 23 seconds. > > I personally am in favour of number 3 as I believe it is not too difficult > to build a parser that will process just durations (hours minutes seconds) > as long as there is an agreed format. --- any sort of NLP is much harder than you think! If we are back to codifying something, either we build it in english (which people would disagree with) or having an list of all known way to spell, decline and abbreviate hours in all known human languages. Is is very much a boiling the oceans solution. -brian -- brian suda http://suda.co.uk From martin at weborganics.co.uk Mon Aug 4 08:40:33 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 4 08:40:53 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <21e770780808040755l671a058ei217fe2997914fdd8@mail.gmail.com> References: <4897099D.8070306@weborganics.co.uk> <21e770780808040755l671a058ei217fe2997914fdd8@mail.gmail.com> Message-ID: <489722F1.9000103@weborganics.co.uk> Hello Brian Brian Suda wrote: > 2008/8/4, Martin McEvoy : > >> There are (in my view) only three real ways to resolve this issue >> ... >> 3 Support NLP (Natural Language Processing) 3 >> minutes 23 seconds. >> >> I personally am in favour of number 3 as I believe it is not too difficult >> to build a parser that will process just durations (hours minutes seconds) >> as long as there is an agreed format. >> > > --- any sort of NLP is much harder than you think! If we are back to > codifying something, either we build it in english (which people would > disagree with) or having an list of all known way to spell, decline > and abbreviate hours in all known human languages. Is is very much a > boiling the oceans solution. > > -brian > > I disagree (slightly) consider this 1 hour 3 minutes 23 seconds or this 1 heures 3 minutes 23 secondes The parser already knows that this is a duration and the contents are a Numerical value and thus text (words) are striped as they are nothing to do with the value, they are only there for a human to understand would leave us with... 1 3 23 as long as we we know what format this is supposed to represent , the first number is an hour, the second minutes, and third seconds and this is documented as a decided format then it would be fairly straight forward after that to output any format you like. Thanks Martin McEvoy From mail at tobyinkster.co.uk Mon Aug 4 13:02:51 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Aug 4 13:03:23 2008 Subject: [uf-new] hAudio Issue Duration Message-ID: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> > 1 hour 3 minutes 23 seconds > or this > 1 heures 3 minutes 23 secondes [...] > Numerical value and thus text (words) are striped as they are nothing > to do with the value, they are only there for a human to understand > would leave us with... > 1 3 23 It becomes a bit more murky with: 1 quux 2 xyzzy This gets reduced to "1 2". But is this PT1H2M or PT1M2S? It could even be PT1H2S or a very long recording which is P1DT2H! NLP is not a nice solution for this kind of thing. And for reasons I've outlined before, a solution which *looks* like NLP will be mistaken for NLP by publishers and you'll end up with an NLP arms race between publishers and parsers. For people concerned with the accessibility of ISO durations, I'd suggest allowing duration to take *either* and ISO duration *or* a length in seconds, optionally followed by whitespace then "s", the SI abbreviation for seconds. e.g. the following would both be valid:

This song is 3 minutes, 23 seconds long.

This song is 3 minutes, 23 seconds long.

The limitation of course would be that this alternative syntax only allows times to be expressed in seconds, but I think that for many of the use cases of hAudio (i.e. songs) it would represent an improvement in accessibility. -- Toby A Inkster From martin at weborganics.co.uk Mon Aug 4 13:18:24 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 4 13:18:36 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> Message-ID: <48976410.4080805@weborganics.co.uk> Toby A Inkster wrote: >> 1 hour 3 minutes 23 seconds >> or this >> 1 heures 3 minutes 23 secondes > [...] >> Numerical value and thus text (words) are striped as they are nothing >> to do with the value, they are only there for a human to understand >> would leave us with... >> 1 3 23 > > > It becomes a bit more murky with: > 1 quux 2 xyzzy > > This gets reduced to "1 2". But is this PT1H2M or PT1M2S? It could > even be PT1H2S or a very long recording which is P1DT2H! NLP is not a > nice solution for this kind of thing. Thanks Toby for bringing this up you are of course correct, So are you Brian its much harder than I thought ;-) > And for reasons I've outlined before, a solution which *looks* like > NLP will be mistaken for NLP by publishers and you'll end up with an > NLP arms race between publishers and parsers. > > For people concerned with the accessibility of ISO durations, I'd > suggest allowing duration to take *either* and ISO duration *or* a > length in seconds, optionally followed by whitespace then "s", the SI > abbreviation for seconds. e.g. the following would both be valid: > >

This song is class="duration">3 minutes, 23 seconds long.

>

This song is 3 > minutes, 23 seconds long.

> > The limitation of course would be that this alternative syntax only > allows times to be expressed in seconds, but I think that for many of > the use cases of hAudio (i.e. songs) it would represent an improvement > in accessibility. A possible resolution is Duration can only be expressed in Minutes and Seconds or just Minutes eg: 3 minutes, 23 seconds or 0 minutes, 23 seconds or 120 minutes, 23 seconds or even 3 minutes What do you think? Thanks Martin McEvoy From brian.suda at gmail.com Mon Aug 4 14:28:01 2008 From: brian.suda at gmail.com (Brian Suda) Date: Mon Aug 4 14:28:06 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <48976410.4080805@weborganics.co.uk> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> Message-ID: <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> 2008/8/4, Martin McEvoy : > A possible resolution is Duration can only be expressed in Minutes and > Seconds or just Minutes eg: --- i think what is being discussed is an optimization rather than an encoding. Much like our FN nickname, FN == ORG optimizations, we are documenting short-cuts. This does not impact the actual encoding which stands true for all possibilities. -brian -- brian suda http://suda.co.uk From guillaume at lebleu.org Mon Aug 4 17:26:14 2008 From: guillaume at lebleu.org (Guillaume P. Lebleu) Date: Mon Aug 4 17:26:18 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> Message-ID: <893300A9-9685-4022-A305-C39957A04304@lebleu.org> On Aug 4, 2008, at 2:28 PM, Brian Suda wrote: > 2008/8/4, Martin McEvoy : >> A possible resolution is Duration can only be expressed in Minutes >> and >> Seconds or just Minutes eg: > > --- i think what is being discussed is an optimization rather than an > encoding. Much like our FN nickname, FN == ORG optimizations, we are > documenting short-cuts. This does not impact the actual encoding which > stands true for all possibilities. I've come to agree with others that "NLP" or "natural language formats" (better name IMO) should be avoided as much as possible in parsers. On the other hand, NLP or natural language formats could be used instead at editing time: NLP could assist content writers in microformatting semi-automatically their content at the time of writing, and solve the problem of manually microformatting being sort of a chore (see What we didn't do in [1]). I suggest the following alternative to the current abbr/ISO option (I'm saying alternative, because it would only be an additional option to those who don't want to use the abbr/ISO option, which would still be supported): 3:42 This approach would also work for datetime, and has already been discussed. I will document it on the wiki, unless there is a strong pushback for a reason I haven't anticipated. [1] http://www.brucelawson.co.uk/2008/standards-based-corporate-web-development/ From glenn.jones at madgex.com Tue Aug 5 02:43:23 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Tue Aug 5 02:43:30 2008 Subject: [uf-new] hResume missing qualifications and grades Message-ID: <36A319113CF910438942741C4727ADFF022C95A5@MOBY.Clarence.local> I have been marking up a number of CVs with hResume and believe that there is a major piece missing from the specification. Most CVs have some sort of educational history, which will contain information such as institution name, qualifications and grades. Some real life examples: a) 1987-1990, University of Bristol BSc (Hons) Degree in Computer Science b) Mathematics Higher B c) 1992: A levels Mathematics, Further Mathematics, Physics, Chemistry (all grade A) d) 5 O levels (Grades A-C) e) In 1999 I graduated with honours from a 4 year Hons BSc in Artificial Intelligence and Computer Science at the University of Edinburgh, Scotland. This degree is designed to give the student a firm grounding in the subjects of Artificial Intelligence and Computer Science while demonstrating how the two are related and how each can be used to supplement the other. Currently the education element of hResume is based on hCalendar which is great at dealing with the time elements of education item such as start date, end date and duration. It has also been expanded with an embedded hCard to help indicate the institution name, address etc. But this combination of hCalendar and hCard only addresses half of the common semantic information communicated about education history. How do we mark-up qualifications, subjects and grades? If I was to design a specification based on real world use and current schemas like HR-XML it would look something like this: Education Institution (hCard) dtstart dtend duration summary qualification (one or more) name subject grade description number Has anyone else come up against this problem. Is there interest in changing the current draft specification to make more representatives of real life publishing needs? Glenn Jones From brian.suda at gmail.com Tue Aug 5 02:57:13 2008 From: brian.suda at gmail.com (Brian Suda) Date: Tue Aug 5 02:57:18 2008 Subject: [uf-new] hResume missing qualifications and grades In-Reply-To: <36A319113CF910438942741C4727ADFF022C95A5@MOBY.Clarence.local> References: <36A319113CF910438942741C4727ADFF022C95A5@MOBY.Clarence.local> Message-ID: <21e770780808050257o1c4fe04fw6baaabd8869b3c5c@mail.gmail.com> 2008/8/5, Glenn Jones : > Has anyone else come up against this problem. Is there interest in > changing the current draft specification to make more representatives of > real life publishing needs? --- there was a discussion awhile ago with some of the LinkedIn findings as well (i had a quick look on the wiki and didn't see anything - but it might be there somewhere) Please do add this to the brainstorming page and I'll try to ping the linkedin guys to see if/where we can get their findings as well. http://microformats.org/wiki/resume-brainstorming We can then work on documenting issues and trends. -brian -- brian suda http://suda.co.uk From martin at weborganics.co.uk Tue Aug 5 06:21:42 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Aug 5 06:21:48 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <893300A9-9685-4022-A305-C39957A04304@lebleu.org> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> <893300A9-9685-4022-A305-C39957A04304@lebleu.org> Message-ID: <489853E6.70901@weborganics.co.uk> Hello Guillaume.... Guillaume P. Lebleu wrote: > I suggest the following alternative to the current abbr/ISO option > (I'm saying alternative, because it would only be an additional option > to those who don't want to use the abbr/ISO option, which would still > be supported): > > 3: class="seconds">42 Yes I think somewhere in the past this was discussed, although it makes sense to do as you say but... Microformats tend to be nouns not plurals as your example above, consider this 1:1 doesnt make sense, so in order to accept that we can mark up both 1 Minute 42 Minutes we would have to accept two microformats for one property. your Thought is Good however, how about... 1: 3: 42 Looks a bit strange But it is expressing duration in ISO 8601 format . PT1H3M42S Thanks Martin McEvoy From scott at makedatamakesense.com Tue Aug 5 09:12:45 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Aug 5 09:12:50 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <489853E6.70901@weborganics.co.uk> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> <893300A9-9685-4022-A305-C39957A04304@lebleu.org> <489853E6.70901@weborganics.co.uk> Message-ID: <052438DD-44F0-4420-A4D2-F56B0D305B2F@makedatamakesense.com> On [Aug 5], at [ Aug 5] 7:21 , Martin McEvoy wrote: > > 1: > 3: > 42 > > > Looks a bit strange But it is expressing duration in ISO 8601 > format . PT1H3M42S Keep in mind ISO 8601 durations use "M" to indicate both month and minute, with the latter preceded by a "T" (for time). Without that "T", the above "M" is ambiguous in terms of ISO 8601 durations. Ideally our duration markup would have no such ambiguity. -- Scott Reynen MakeDataMakeSense.com From chucka at hr-xml.org Tue Aug 5 09:16:43 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Tue Aug 5 09:16:55 2008 Subject: [uf-new] hResume missing qualifications and grades In-Reply-To: <36A319113CF910438942741C4727ADFF022C95A5@MOBY.Clarence.local> References: <36A319113CF910438942741C4727ADFF022C95A5@MOBY.Clarence.local> Message-ID: <48987CEB.8050101@hr-xml.org> Glenn, A couple reactions: 1. Based on some recent discussion/research in our community, I think the UK market presents some fairly unique requirements since it is one of the few countries with a relatively well-known, widely referenced national system of course accreditation for pre-university study. The wrinkle our "resume parsing" service providers find in UK resumes/CVs (and what you reference in your example) is the need to capture course accreditation level as well as grade. Here's a snippet example: > 1992-1994 SchoolName, UK > A Level: Mathematics (B), Physics (C), Economics (C) > AS Level: Electronics (A) > GCSE: Nine at grade C or above, including English, Mathematics & French. The HR-XML work group recently discussed a new component to handle representations like this within resumes. However, for right now, our rough consensus is to leave this as a localization for the UK market. Below is the draft model that we sketched out, but have not yet moved forward: AccreditedCourseWork -- CourseLevelCode (e.g., "AS," "A-Level," etc.) -- CourseCount -- TimePeriod -- EducationScoreDetails (reduced to Score/Mark) -- EducationOrganization -- Subject -- A Country Code or AcceditationSchemeID? 2. As with everything the microformat community considers (or HR-XML for that matter) there's a slippery slope here in terms of complexity. It seems what makes a good microformat is something simple and relatively flat versus hierarchical. HR-XML focuses a bit more on the back-office system-to-system communication of data, so we have a bit more leeway. However, on the particular topic of representing education, we certainly realize that we do not wish to be anything like a full "transcript" standard. However, I think there is a lot of value to some simple standardization of very basic concepts. "Grade" is an interesting one. There are easily a dozen consortia and standards organizations producing relevant standards/specifications and I don't think you'll find much consistency in terminology nor corresponding data type (grade, mark, score, score format, etc.) Being designed for humans first and computers second, the Microformats community isn't as concerned with data types and data validation as HR-XML. However, HR-XML is currently trying to advance a few ideas to better ensure interoperability with learning and education communities. We're using the term "Score" to refer to the numeric variety of "grades". Here's a draft proposal we've submitted to the UN/CEFACT core data type workgroup: http://docs.hr-xml.org/resources/CandidatePaper_NewCDT_Score_0p2-1-DRAFT.pdf I not yet sure about the name for the textual or symbolic variety of "grade". Perhaps, we'll just call this "Grade" or "Mark" or "ScoreFormat". Still having that "what's in a name" debate on this. I hope this information proves useful. I'd welcome feedback online or offline regarding any of the above. Chuck Allen ------------------------- HR-XML notes: > Discussed patterns in the UK relating to information about > accredited course work often found in CV's. This is usually > a course of secondary (ISCED 3) or pre-university study > > Questions: > -- Is this a UK localization? At the very least > it is safe to say that few other countries have > a system of secondary study accreditation and > credit transfer that is as consistent and widely > implemented as the NQF in the UK. See: > http://tinyurl.com/5sswg7 > http://en.wikipedia.org/wiki/National_Qualifications_Framework > http://en.wikipedia.org/wiki/GCSE > > -- Might some of this be mapped to competency > records and evidence? Yes. Yet at least in UK resumes > this type of accredited secondary course work is > commonly broken out in resumes and CVs. If you look > at the IMAP model for capturing NQF data, it does seem > like it was intended as a broader mechanism for > describing competencies than something designed around > this course-work communication issue. Glenn Jones wrote: > I have been marking up a number of CVs with hResume and believe that > there is a major piece missing from the specification. Most CVs have > some sort of educational history, which will contain information such as > institution name, qualifications and grades. Some real life examples: > > a) 1987-1990, University of Bristol BSc (Hons) Degree in Computer > Science > b) Mathematics Higher B > c) 1992: A levels Mathematics, Further Mathematics, Physics, > Chemistry (all grade A) > d) 5 O levels (Grades A-C) > e) In 1999 I graduated with honours from a 4 year Hons BSc in > Artificial Intelligence and Computer Science at the University of > Edinburgh, Scotland. This degree is designed to give the student a firm > grounding in the subjects of Artificial Intelligence and Computer > Science while demonstrating how the two are related and how each can be > used to supplement the other. > > Currently the education element of hResume is based on hCalendar which > is great at dealing with the time elements of education item such as > start date, end date and duration. It has also been expanded with an > embedded hCard to help indicate the institution name, address etc. > > But this combination of hCalendar and hCard only addresses half of the > common semantic information communicated about education history. How do > we mark-up qualifications, subjects and grades? If I was to design a > specification based on real world use and current schemas like HR-XML it > would look something like this: > > Education > Institution (hCard) > dtstart > dtend > duration > summary > qualification (one or more) > name > subject > grade > description > number > > Has anyone else come up against this problem. Is there interest in > changing the current draft specification to make more representatives of > real life publishing needs? > > Glenn Jones -- -- Chuck Allen --------------- +1 919 247 6881 --------------- Attend HR-XML's Partnering and Integration Summit http://www.partneringsummit.org --------------- From martin at weborganics.co.uk Wed Aug 6 02:43:50 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 6 02:43:59 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <052438DD-44F0-4420-A4D2-F56B0D305B2F@makedatamakesense.com> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> <893300A9-9685-4022-A305-C39957A04304@lebleu.org> <489853E6.70901@weborganics.co.uk> <052438DD-44F0-4420-A4D2-F56B0D305B2F@makedatamakesense.com> Message-ID: <48997256.5060405@weborganics.co.uk> Hello Scott Scott Reynen wrote: > On [Aug 5], at [ Aug 5] 7:21 , Martin McEvoy wrote: > >> >> 1: >> 3: >> 42 >> >> >> Looks a bit strange But it is expressing duration in ISO 8601 format >> . PT1H3M42S > > > Keep in mind ISO 8601 durations use "M" to indicate both month and > minute, with the latter preceded by a "T" (for time). Without that > "T", the above "M" is ambiguous in terms of ISO 8601 durations. > Ideally our duration markup would have no such ambiguity. No our markup shouldn't have no such ambiguity, you are right, It would require that "T" be marked up too... 1: 3: 42 but again we would have the same issues that "m" is ambiguous, It really is a shame that microformats (as is semantic html) are all lower case or case insensitive, because if we were able to accept upper case values as being different than lower we could say that "M" = month and "m" = minute there would be no issues, but this is Impossible because the UPPER CASE web is Pointless, why well the simplest answer I can give is, The main reasons people build website s the first is to talk about your hot product and make money or talk about things that make you tick, The second (an perhaps more importantly to some) to be indexed by search engines and rank highly in their results. Most search engines use a process called Stemming[1] or Porter 80 The Porter Stemming Algorithm[2] so this process can be done reliably first all html documents are converted to lower case (this makes it easier to determine term vectors[3]) so any "semantic meaning" you may have marked up in there in UPPER CASE is lost and means nothing. [1] http://en.wikipedia.org/wiki/Stemming [2] http://tartarus.org/~martin/PorterStemmer/ [3] http://www9.org/w9cdrom/159/159.html Anyway finished with my rant :-) This issue really needs to be addressed some how though ? Best wishes Martin McEvoy > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From guillaume at lebleu.org Wed Aug 6 11:45:25 2008 From: guillaume at lebleu.org (Guillaume P. Lebleu) Date: Wed Aug 6 11:45:28 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <48997256.5060405@weborganics.co.uk> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> <893300A9-9685-4022-A305-C39957A04304@lebleu.org> <489853E6.70901@weborganics.co.uk> <052438DD-44F0-4420-A4D2-F56B0D305B2F@makedatamakesense.com> <48997256.5060405@weborganics.co.uk> Message-ID: On Aug 6, 2008, at 2:43 AM, Martin McEvoy wrote: > Hello Scott > > Scott Reynen wrote: >> Keep in mind ISO 8601 durations use "M" to indicate both month and >> minute, with the latter preceded by a "T" (for time). Without that >> "T", the above "M" is ambiguous in terms of ISO 8601 durations. >> Ideally our duration markup would have no such ambiguity. > No our markup shouldn't have no such ambiguity, you are right, It > would require that "T" be marked up too... > > > 1: > 3: > 42 > > > but again we would have the same issues that "m" is ambiguous I think "m" here is no more ambiguous than "M" in the ISO8601. i.e. if "m" is contained by "time", then it means minute(s) and if "m" is contained by "date", it means month(s). Can someone remind me / point me to the rationale behind the principle that the meaning of a classname cannot be dependent of the containing classname? From jmyers at visi.com Wed Aug 6 14:59:06 2008 From: jmyers at visi.com (Jay Myers) Date: Wed Aug 6 14:59:17 2008 Subject: [uf-new] hProduct progress Message-ID: All, There is work being done on new standards and reviving the hProduct microformat. During the course of this effort, people have pointed to hListing as a more viable, mature format for displaying product data. We proponents of hProduct feel that a separate hProduct uF would be more granular, and provide more specifics around the products, which often are more complex and have important attributes that are outside of the scope of hListing and others. Please see the updated brainstorming and draft proposal wiki pages for more information on the updated schema. Nonetheless, there are still correlations between hListing and hProduct that can't be ignored. It has been suggested that hProduct be used in conjuction with hListing to enhance the semantics of that format, where hProduct would live under .item. This I agree with, but I would still propose it also be used separately. I would appreciate any thoughts or ideas you might have around the revival effort of hProduct. Thanks, Jay From martin at weborganics.co.uk Wed Aug 6 15:05:57 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 6 15:06:06 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> <893300A9-9685-4022-A305-C39957A04304@lebleu.org> <489853E6.70901@weborganics.co.uk> <052438DD-44F0-4420-A4D2-F56B0D305B2F@makedatamakesense.com> <48997256.5060405@weborganics.co.uk> Message-ID: <489A2045.8000409@weborganics.co.uk> Hello Guillaume Guillaume P. Lebleu wrote: [...] > > Can someone remind me / point me to the rationale behind the principle > that the meaning of a classname cannot be dependent of the containing > classname?_______________________________________________ [...] There is no rational in your above statement in truth all root Microformats depend on other properties to be present in order for them to express any semantics at all, haudio requires "title" or "album" to be present, hcard requires that at least "fn" be present and so on. The issue with "m" is when it comes to defining class names across all microformats if "m"=>month when contained in a "date" class and "m"=>minute when contained in a duration class this is where the problems arise, microformats are not ambiguous they mean very specific things so "m" cannot mean both month and minute its either one or the other, Another and I guess the more important issue is it goes against the microformats naming principles in particular > Using others' names to mean different things http://microformats.org/wiki/naming-principles#Introduction If we decided here and now that class="m" means Month, and then later decided hey class="m" also means something different Minute then this would go directly against the above naming principle, I also think that class "m" suffers a "brevity of meaning", not against any microformats naming principles but should be. http://microformats.org/wiki/naming-principles#Issues so some "meaningful" abbreviation .... 1: 3: 42 I think that the above example meets half way between your example... http://microformats.org/discuss/mail/microformats-new/2008-August/001655.html and mine. Thanks Martin McEvoy From guillaume at lebleu.org Wed Aug 6 15:27:34 2008 From: guillaume at lebleu.org (Guillaume P. Lebleu) Date: Wed Aug 6 15:27:38 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: <489A2045.8000409@weborganics.co.uk> References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> <893300A9-9685-4022-A305-C39957A04304@lebleu.org> <489853E6.70901@weborganics.co.uk> <052438DD-44F0-4420-A4D2-F56B0D305B2F@makedatamakesense.com> <48997256.5060405@weborganics.co.uk> <489A2045.8000409@weborganics.co.uk> Message-ID: On Aug 6, 2008, at 3:05 PM, Martin McEvoy wrote: > so some "meaningful" abbreviation .... > > > 1: > 3: > 42 > Thanks Martin, I actually went in this direction when documenting this thread on the wiki [1]. I'm using abbreviations I found from official source [2] ("s" instead of "sec" for instance) Something that came to my mind is how to reconcile this proposition with the measure microformat [3] (a duration is a measure of time). For instance, according to the draft measure proposal "15min 30s", would be marked up with 30s. [1] http://microformats.org/wiki/datetime-design-pattern#Individual_markup_of_each_date.2Ftime_component [2] http://en.wikipedia.org/wiki/Second [3] http://microformats.org/wiki/measure From martin at weborganics.co.uk Wed Aug 6 17:10:23 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 6 17:10:31 2008 Subject: [uf-new] hAudio Issue Duration In-Reply-To: References: <0E170B19-CA2B-4661-BA4B-CBA12ED9908D@tobyinkster.co.uk> <48976410.4080805@weborganics.co.uk> <21e770780808041428rce7e2eey48321563f8dbf774@mail.gmail.com> <893300A9-9685-4022-A305-C39957A04304@lebleu.org> <489853E6.70901@weborganics.co.uk> <052438DD-44F0-4420-A4D2-F56B0D305B2F@makedatamakesense.com> <48997256.5060405@weborganics.co.uk> <489A2045.8000409@weborganics.co.uk> Message-ID: <489A3D6F.2030409@weborganics.co.uk> Guillaume P. Lebleu wrote: > On Aug 6, 2008, at 3:05 PM, Martin McEvoy wrote: > >> so some "meaningful" abbreviation .... >> >> >> 1: >> 3: >> 42 >> > > Thanks Martin, I actually went in this direction when documenting this > thread on the wiki [1]. I'm using abbreviations I found from official > source [2] ("s" instead of "sec" for instance) Great Guillaume some progress.... > > Something that came to my mind is how to reconcile this proposition > with the measure microformat [3] (a duration is a measure of time). > For instance, according to the draft measure proposal "15min 30s", > would be marked up with 30 class="unit">s. > > [1] > http://microformats.org/wiki/datetime-design-pattern#Individual_markup_of_each_date.2Ftime_component > > [2] http://en.wikipedia.org/wiki/Second > [3] http://microformats.org/wiki/measure > so using a little of both duration could be marked up thus... 1: [1] 3: [2] 42 [3] Duration is marked up in a ISO 31-1 format which is how durations and intervals should be marked up [4] as apposed to ISO 8601[5] for days and dates [1] http://en.wikipedia.org/wiki/Hour [2] http://en.wikipedia.org/wiki/Minute [3] http://en.wikipedia.org/wiki/Second [4] http://en.wikipedia.org/wiki/ISO_31-1 [5] http://en.wikipedia.org/wiki/ISO_8601 +1 from me on this proposal. Thinking back Toby mentioned something in an earlier post... > For people concerned with the accessibility of ISO durations, I'd > suggest allowing duration to take *either* and ISO duration *or* a > length in seconds, optionally followed by whitespace then "s", the SI > abbreviation for seconds http://microformats.org/discuss/mail/microformats-new/2008-August/001652.html which is what got me thinking along those lines. Thanks Martin McEvoy > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Wed Aug 6 17:47:28 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 6 17:47:36 2008 Subject: [uf-new] ISO-31-1 Message-ID: <489A4620.7000603@weborganics.co.uk> Hello There is a study page on the microformats wiki for the exploration of ISO 31-1 [1] as a way of marking up durations and intervals. please feel free to add your comments and suggestions and markup examples. [1] http://microformats.org/wiki/ISO-31-1 Thanks Martin McEvoy From glenn.jones at madgex.com Thu Aug 7 02:25:23 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Thu Aug 7 02:25:29 2008 Subject: [uf-new] ISO-31-1 In-Reply-To: <489A4620.7000603@weborganics.co.uk> References: <489A4620.7000603@weborganics.co.uk> Message-ID: <36A319113CF910438942741C4727ADFF02330039@MOBY.Clarence.local> Martin McEvoy wrote: > There is a study page on the microformats wiki for the exploration of > ISO 31-1 [1] as a way of marking up durations and intervals. please feel > free to add your comments and suggestions and markup examples. > [1] http://microformats.org/wiki/ISO-31-1 You have to be carefully in exploring new options that you don't cause issues elsewhere. I think changing duration is a case in point, as it is not only used in hAudio, but also in hCalendar and in turn hResume. Although we could use days as a measure of a duration for large time periods it does not always work when trying to mark-up certain text i.e. "3 Years and 4 month" is more meaningful to a human than "1068 days". Having different datatypes for a property of the same name is very problematic. Personally I would not like us to use ISO-8601 for hCalendar duration and ISO-31-1 for duration in hAudio. Some parsers do try to convert formats into datatypes this could become hellish if we use the same property names for different data formats. Last but not least you have also just walked into the internalisation issue from the "Human and machine readable data format" debate. Not all languages use the Arabic numerals ie 0,1,2, 3 etc [1] http://en.wikipedia.org/wiki/Japanese_numerals Although most people will understand Arabic numerals and you find them mixed in with languages like Chinese, it's still an issue that need thought. Glenn Jones From glenn.jones at madgex.com Thu Aug 7 05:23:32 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Thu Aug 7 05:23:42 2008 Subject: [uf-new] hResume missing qualifications and grades In-Reply-To: <48987CEB.8050101@hr-xml.org> References: <36A319113CF910438942741C4727ADFF022C95A5@MOBY.Clarence.local> <48987CEB.8050101@hr-xml.org> Message-ID: <36A319113CF910438942741C4727ADFF02330169@MOBY.Clarence.local> Thanks Chuck: a couple of interesting points came from reading your reply Your point about the UK having a "relatively well-known, widely referenced national system of course accreditation for pre-university study" is well taken. University study is much more uniform, with a considerable number of countries offering Bachelor, Masters and Doctorate degrees. That said I think we need to stand back from these issues and ask what is requried from a microformat perspective. The fundamental concept of microformats has been to capture semantic structures in text and make them available for machine processing. That could be searching, sorting, republishing or reformatting, in fact anything someone else may want to use it for. We do not always need precision; a value can be anything from free text to a quantifiable number in a fixed scale and still be useful. I tried to pick a structure that could isolate and preserve as much of the semantic structure as possible, so that if it was reformatted we would still be able to reproduce a good understanding of the educational history. i.e. I could reconstruct a summary like this from a parsed hResume: Between "dtstart" and "dtend", "fn" study at "institution" obtaining a "grade" in "name" - "subject". Reformatting the structure of information would seem to be the lowest level of reuse I can think of. You are right, qualification name, subject and grade are too difficult to directly compare. You would have to have a massive ontology like those built into CV/resume parsers for machine based searching and sorting to work well. But we could provide a much richer structure with just a few changes, which would hopefully add a great deal more utility to the format. Thanks again for the pointers to the resources and your thoughts. [1] http://en.wikipedia.org/wiki/Bologna_process [2] http://en.wikipedia.org/wiki/Academic_degree Glenn Chuck Allen wrote > A couple reactions: > 1. Based on some recent discussion/research in our community, I think the UK market presents some fairly unique requirements > since it is one of the > few countries with a relatively well-known, widely referenced national system of course accreditation for pre-university study. > The wrinkle our > "resume parsing" service providers find in UK resumes/CVs (and what you reference in your example) is the need to capture > course accreditation level > as well as grade. Here's a snippet example: >> 1992-1994 SchoolName, UK >> A Level: Mathematics (B), Physics (C), Economics (C) >> AS Level: Electronics (A) >> GCSE: Nine at grade C or above, including English, Mathematics & French. > The HR-XML work group recently discussed a new component to handle representations like this within resumes. However, for right > now, our rough > consensus is to leave this as a localization for the UK market. Below is the draft model that we sketched out, but have not yet > moved forward: > AccreditedCourseWork > -- CourseLevelCode (e.g., "AS," "A-Level," etc.) > -- CourseCount > -- TimePeriod > -- EducationScoreDetails (reduced to Score/Mark) > -- EducationOrganization > -- Subject > -- A Country Code or AcceditationSchemeID? > 2. As with everything the microformat community considers (or HR-XML for that matter) there's a slippery slope here in terms of complexity. It seems > what makes a good microformat is something simple and relatively flat versus hierarchical. HR-XML focuses a bit more on the back-office > system-to-system communication of data, so we have a bit more leeway. However, on the particular topic of representing education, we certainly realize > that we do not wish to be anything like a full "transcript" standard. However, I think there is a lot of value to some simple standardization of very > basic concepts. "Grade" is an interesting one. There are easily a dozen consortia and standards organizations producing relevant > standards/specifications and I don't think you'll find much consistency in terminology nor corresponding data type (grade, mark, score, score format, > etc.) > Being designed for humans first and computers second, the Microformats community isn't as concerned with data types and data validation as HR-XML. > However, HR-XML is currently trying to advance a few ideas to better ensure interoperability with learning and education communities. We're using the > term "Score" to refer to the numeric variety of "grades". Here's a draft proposal we've submitted to the UN/CEFACT core data type workgroup: > http://docs.hr-xml.org/resources/CandidatePaper_NewCDT_Score_0p2-1-DRAFT .pdf > I not yet sure about the name for the textual or symbolic variety of "grade". Perhaps, we'll just call this "Grade" or "Mark" or "ScoreFormat". Still > having that "what's in a name" debate on this. > I hope this information proves useful. I'd welcome feedback online or offline regarding any of the above. > Chuck Allen > ------------------------- > HR-XML notes: >> Discussed patterns in the UK relating to information about >> accredited course work often found in CV's. This is usually >> a course of secondary (ISCED 3) or pre-university study > > >> Questions: >> -- Is this a UK localization? At the very least >> it is safe to say that few other countries have >> a system of secondary study accreditation and >> credit transfer that is as consistent and widely >> implemented as the NQF in the UK. See: >> http://tinyurl.com/5sswg7 >> http://en.wikipedia.org/wiki/National_Qualifications_Framework >> http://en.wikipedia.org/wiki/GCSE > > >> -- Might some of this be mapped to competency >> records and evidence? Yes. Yet at least in UK resumes >> this type of accredited secondary course work is >> commonly broken out in resumes and CVs. If you look >> at the IMAP model for capturing NQF data, it does seem >> like it was intended as a broader mechanism for >> describing competencies than something designed around >> this course-work communication issue. From scott at makedatamakesense.com Thu Aug 7 06:43:07 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Thu Aug 7 06:43:17 2008 Subject: [uf-new] ISO-31-1 In-Reply-To: <36A319113CF910438942741C4727ADFF02330039@MOBY.Clarence.local> References: <489A4620.7000603@weborganics.co.uk> <36A319113CF910438942741C4727ADFF02330039@MOBY.Clarence.local> Message-ID: On [Aug 7], at [ Aug 7] 3:25 , Glenn Jones wrote: > Last but not least you have also just walked into the internalisation > issue from the "Human and machine readable data format" debate. Not > all > languages use the Arabic numerals ie 0,1,2, 3 etc > > [1] http://en.wikipedia.org/wiki/Japanese_numerals > > Although most people will understand Arabic numerals and you find them > mixed in with languages like Chinese, it's still an issue that need > thought. I strongly disagree here. I think you'd have a hard time finding a single person in either Japan or China who both understands what a computer is (i.e. not counting extreme rural isolation) and is not very familiar with Arabic numerals. You can't buy a computer in either country without using either cash or credit cards covered in Arabic numerals. It's very likely you're also scanning a bar code with Arabic numerals and/or getting a receipt with Arabic numerals. Your clock, television, vehicle, phone, and ID card all use Arabic numerals. And when you turn your computer on, you'll see many more Arabic numerals (e.g. in the version number of your operating system). So I'd say a person looking at using microformats but unfamiliar with Arabic numerals goes well beyond an edge case. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Thu Aug 7 07:45:04 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Aug 7 07:45:11 2008 Subject: [uf-new] ISO-31-1 In-Reply-To: <36A319113CF910438942741C4727ADFF02330039@MOBY.Clarence.local> References: <489A4620.7000603@weborganics.co.uk> <36A319113CF910438942741C4727ADFF02330039@MOBY.Clarence.local> Message-ID: <489B0A70.3020108@weborganics.co.uk> Hello Glenn Glenn Jones wrote: [....] > You have to be carefully in exploring new options that you don't cause > issues elsewhere. I think changing duration is a case in point, as it is > not only used in hAudio, but also in hCalendar and in turn hResume. [....] Agreed duration is based on http://tools.ietf.org/html/rfc2445#section-4.8.2.5, I have always had an issue with this kind of mark-up in microformats this... PT1H0M0S ...if you stuff it in a title its data injected into a human area! surely this should be documented as an anti-pattern?, I am not saying this is wrong, it happens, its just that the data above is the expected output to a *machine*, which is surely a problem of the parser not the author to parse this correctly. 1: 3: 42 Its quite easy to extract PT1H3M42S from the data above because all the base properties are present @duration=>PT, h=>H, min=>M, s=>S however I can not change the way duration is currently parsed, so it may be an idea to change @class="duration" in haudio to class="interval" although I am unsure if this is sound thinking yet. documented here http://microformats.org/wiki/ISO-31-1#issues [...] > Having different datatypes for a property of the same name is very > problematic. Personally I would not like us to use ISO-8601 for > hCalendar duration and ISO-31-1 for duration in hAudio. Some parsers do > try to convert formats into datatypes this could become hellish if we > use the same property names for different data formats. > > Last but not least you have also just walked into the internalisation > issue from the "Human and machine readable data format" debate. Not all > languages use the Arabic numerals ie 0,1,2, 3 etc > > [1] http://en.wikipedia.org/wiki/Japanese_numerals > > Although most people will understand Arabic numerals and you find them > mixed in with languages like Chinese, it's still an issue that need > thought. > [....] Agreed to a certain extent but I believe that commonly Japanese Numerals are Written in arabic ? and I also believe that Arabic numerals are by far the most common form of Numbering in the world? http://en.wikipedia.org/wiki/Arabic_numerals I believe we should keep it simple an focus around the Arabic numbering system for now. Thanks for your input Glenn :-) Martin McEvoy From mephtu at yahoo.com Thu Aug 7 16:03:55 2008 From: mephtu at yahoo.com (Samuel Richter) Date: Thu Aug 7 16:10:38 2008 Subject: [uf-new] New uF: Version Message-ID: <942281.77138.qm@web36702.mail.mud.yahoo.com> Hi, I am submitting this again, because I have had some problems receiving mail from the mailing list. What about a version microformat. Something like this: Version 1.0, for tagging versioned files. Keeping software up to date can be a major hassle. By placing version information on download websites, this process can be automated. Please respond. -Sam http://www.xmlhellco.com From ameer1234567890 at gmail.com Fri Aug 8 01:53:57 2008 From: ameer1234567890 at gmail.com (ameer1234567890@gmail.com) Date: Fri Aug 8 01:54:02 2008 Subject: [uf-new] New uF: Version In-Reply-To: <942281.77138.qm@web36702.mail.mud.yahoo.com> References: <942281.77138.qm@web36702.mail.mud.yahoo.com> Message-ID: <19abcbf20808080153w6923e324t8ce61a6e012a1d98@mail.gmail.com> Hi Sam, (x)html doesn't support psuedo attribute names as of yet. So, major="1" and minor="0" cannot be used! Instead, I propose the following, with some additions to your proposal.
Name: jQuery Version: 1.0 Type: JavaScript
On 8/7/08, Samuel Richter wrote: > Hi, > > I am submitting this again, because I have had some problems receiving mail > from the mailing list. > > What about a version microformat. Something like this: > > Version 1.0, > > for > tagging versioned files. Keeping software up to date can be a major > hassle. By placing version information on download websites, this > process can be automated. Please respond. > > -Sam > http://www.xmlhellco.com > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From mail at tobyinkster.co.uk Fri Aug 8 03:27:54 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Aug 8 03:28:21 2008 Subject: [uf-new] New uF: Version Message-ID: <0C63F089-BC8E-4013-870B-F4885B0C1B44@tobyinkster.co.uk> Danny Ayers once put together "hDOAP", a "microformat" based on DOAP. The profile link is here but the link is broken. A description of DOAP is here . Using that as a guide, I guess that the hDOAP for your example would be:
Name: jQuery Version: 1.0 (2008-08-08) Type: JavaScript
-- Toby A Inkster From tantek at cs.stanford.edu Fri Aug 8 04:23:32 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Fri Aug 8 04:30:15 2008 Subject: Please read /wiki/process first (was Re: [uf-new] New uF ... ) In-Reply-To: <60cb038a0808080421l5f5cbcffr3b4b6a8ba3dab6c3@mail.gmail.com> References: <60cb038a0808080421l5f5cbcffr3b4b6a8ba3dab6c3@mail.gmail.com> Message-ID: <60cb038a0808080423m54dad25aj6f69a919fe450d00@mail.gmail.com> Please read: http://microformats.org/wiki/process before proposing any new microformats. In addition, please read the specific posting guidelines for microformats-new: http://microformats.org/wiki/mailing-lists#microformats-new On Fri, Aug 8, 2008 at 3:27 AM, Toby A Inkster wrote: > Danny Ayers once put together "hDOAP", a "microformat" based on DOAP. Simply proposing a set of class names is not a microformat (again, see /wiki/process/) - at best it is a poshformat. http://microformats.org/wiki/poshformat Thanks, Tantek -- -- http://tantek.com/ From tantek at cs.stanford.edu Fri Aug 8 04:34:05 2008 From: tantek at cs.stanford.edu (=?ISO-8859-1?Q?Tantek_=C7elik?=) Date: Fri Aug 8 04:34:07 2008 Subject: Please read /wiki/process first (was Re: [uf-new] New uF ... ) In-Reply-To: <60cb038a0808080423m54dad25aj6f69a919fe450d00@mail.gmail.com> References: <60cb038a0808080421l5f5cbcffr3b4b6a8ba3dab6c3@mail.gmail.com> <60cb038a0808080423m54dad25aj6f69a919fe450d00@mail.gmail.com> Message-ID: <60cb038a0808080434v2ba3d2b2of636d7a7aa228d40@mail.gmail.com> Please read: http://microformats.org/wiki/process before proposing any new microformats. In addition, please read the specific posting guidelines for microformats-new: http://microformats.org/wiki/mailing-lists#microformats-new On Fri, Aug 8, 2008 at 3:27 AM, Toby A Inkster wrote: > Danny Ayers once put together "hDOAP", a "microformat" based on DOAP. Simply proposing a set of class names is not a microformat (again, see /wiki/process/) - at best it is a poshformat. http://microformats.org/wiki/poshformat Thanks, Tantek -- http://tantek.com/ From scott at makedatamakesense.com Fri Aug 8 06:19:50 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri Aug 8 06:20:00 2008 Subject: [uf-new] New uF: Version In-Reply-To: <942281.77138.qm@web36702.mail.mud.yahoo.com> References: <942281.77138.qm@web36702.mail.mud.yahoo.com> Message-ID: On [Aug 7], at [ Aug 7] 5:03 , Samuel Richter wrote: > What about a version microformat. Something like this: > for tagging versioned files. Keeping software up to date can be a > major > hassle. By placing version information on download websites, this > process can be automated. Please respond. Let's talk about the general concept first. If it seems worth pursuing, we'll get into markup later. I guess I'm not yet convinced by your use case here. An application would periodically reload the web page for each application to see if it's been updated? How would the appropriate web pages be identified? Maybe you could walk us through the entire process of how you see this working? And how would this system compare to existing software update systems? Most of the software I use already checks for automatic updates. Also, do you have any additional use cases in mind for this? -- Scott Reynen MakeDataMakeSense.com From mail at tobyinkster.co.uk Fri Aug 8 07:06:38 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Aug 8 07:07:16 2008 Subject: Please read /wiki/process first (was Re: [uf-new] New uF ... ) Message-ID: <82A6B809-0379-4496-8CE3-1C92F7031C83@tobyinkster.co.uk> Tantek ?elik wrote: > On Fri, Aug 8, 2008 at 3:27 AM, Toby A Inkster tobyinkster.co.uk> wrote: > > Danny Ayers once put together "hDOAP", a "microformat" based on > DOAP. > > Simply proposing a set of class names is not a microformat (again, see > /wiki/process/) - at best it is a poshformat. > http://microformats.org/wiki/poshformat Indeed - which is why I used quote marks around the word "microformat". If it wasn't for the fact that its creator called it a "microformat", I wouldn't have used the word at all. http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005May/ 0044.html -- Toby A Inkster From mail at ciaranmcnulty.com Fri Aug 8 07:28:55 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Aug 8 07:28:59 2008 Subject: [uf-new] New uF: Version In-Reply-To: References: <942281.77138.qm@web36702.mail.mud.yahoo.com> Message-ID: On Fri, Aug 8, 2008 at 2:19 PM, Scott Reynen wrote: > I guess I'm not yet convinced by your use case here. An application would > periodically reload the web page for each application to see if it's been > updated? Plenty of applications 'dial home' to see if there are pending updates, and the same applications also have download links, so why not combine the two? It would be nice to see some sort of checksum mechanism possible too. Certainly an idea worth talking about, I agree the markup is a bit premature. -Ciaran McNulty From scott at makedatamakesense.com Fri Aug 8 09:40:12 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri Aug 8 09:40:16 2008 Subject: [uf-new] New uF: Version In-Reply-To: References: <942281.77138.qm@web36702.mail.mud.yahoo.com> Message-ID: On [Aug 8], at [ Aug 8] 8:28 , Ciaran McNulty wrote: > On Fri, Aug 8, 2008 at 2:19 PM, Scott Reynen > wrote: >> I guess I'm not yet convinced by your use case here. An >> application would >> periodically reload the web page for each application to see if >> it's been >> updated? > > Plenty of applications 'dial home' to see if there are pending > updates, and the same applications also have download links, so why > not combine the two? I'm afraid you've misinterpreted my questions as rhetorical. I'm actually asking for the answers to those questions to better understand the use case, not making an argument about the merits of such a use case (I may do that after I understand it). When I said "I'm not yet convinced," that's because I don't yet have enough information to convince me. To make this more concrete, here's a page that has a version number: http://www.panic.com/transmit/ The proposal seems to be to add descriptive markup around the "3.6" on that page. And how does this use case go after that? The Transmit application downloads that document periodically to check for updates? And if a higher version number is found, what happens next? And how does the process differ from how Transmit already checks for updates? And are there any other use cases for such markup? -- Scott Reynen MakeDataMakeSense.com From tantek at cs.stanford.edu Fri Aug 8 11:42:18 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Fri Aug 8 11:42:21 2008 Subject: [uf-new] New uF: Version In-Reply-To: References: <942281.77138.qm@web36702.mail.mud.yahoo.com> Message-ID: <60cb038a0808081142qedcc193u15143f0e56ca8b42@mail.gmail.com> On Fri, Aug 8, 2008 at 9:40 AM, Scott Reynen wrote: > On [Aug 8], at [ Aug 8] 8:28 , Ciaran McNulty wrote: > >> On Fri, Aug 8, 2008 at 2:19 PM, Scott Reynen >> wrote: >>> >>> I guess I'm not yet convinced by your use case here. An application >>> would >>> periodically reload the web page for each application to see if it's been >>> updated? >> >> Plenty of applications 'dial home' to see if there are pending >> updates, and the same applications also have download links, so why >> not combine the two? > > > I'm afraid you've misinterpreted my questions as rhetorical. I'm actually > asking for the answers to those questions to better understand the use case, > not making an argument about the merits of such a use case (I may do that > after I understand it). When I said "I'm not yet convinced," that's because > I don't yet have enough information to convince me. These are the right questions to be asking and a part of the process http://microformats.org/wiki/process/ Ciaran, in addition (or perhaps first), you should assume that you're not the first person to think of an idea for a microformat, and thus first check the "exploratory discussions" page to see if there is something similar: http://microformats.org/wiki/exploratory-discussions In this case, a similar effort was previously pursued: http://microformats.org/wiki/downloads It may save you some time to take a look at effort and either see if you want to help that previous effort (add to work already done), or at least understand and contrast why your pursuit is different from that previous effort. Tantek From mail at ciaranmcnulty.com Fri Aug 8 14:25:27 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri Aug 8 14:25:37 2008 Subject: [uf-new] New uF: Version In-Reply-To: <60cb038a0808081142qedcc193u15143f0e56ca8b42@mail.gmail.com> References: <942281.77138.qm@web36702.mail.mud.yahoo.com> <60cb038a0808081142qedcc193u15143f0e56ca8b42@mail.gmail.com> Message-ID: <1190F2DE-0F4A-45FB-BA82-7E5BC808E7D0@ciaranmcnulty.com> On 8 Aug 2008, at 19:42, Tantek ?elik wrote: > Ciaran, in addition (or perhaps first), you should assume that you're > not the first person to think of an idea for a microformat, Well I know that for a fact in this case, as I didn't start the thread and just chipped in with a comment! :-) -Ciaran McNulty From mephtu at yahoo.com Fri Aug 8 14:36:00 2008 From: mephtu at yahoo.com (Samuel Richter) Date: Fri Aug 8 14:36:02 2008 Subject: [uf-new] New uF: Version Message-ID: <238463.70952.qm@web36703.mail.mud.yahoo.com> Original Message: From: Scott Reynen To: For discussion of new microformats. Sent: Friday, August 8, 2008 8:19:50 AM Subject: Re: [uf-new] New uF: Version On [Aug 7], at [ Aug 7] 5:03 , Samuel Richter wrote: > What about a version microformat. Something like this: > for tagging versioned files. Keeping software up to date can be a > major > hassle. By placing version information on download websites, this > process can be automated. Please respond. Let's talk about the general concept first. If it seems worth pursuing, we'll get into markup later. I guess I'm not yet convinced by your use case here. An application would periodically reload the web page for each application to see if it's been updated? How would the appropriate web pages be identified? Maybe you could walk us through the entire process of how you see this working? And how would this system compare to existing software update systems? Most of the software I use already checks for automatic updates. Also, do you have any additional use cases in mind for this? -- Scott Reynen MakeDataMakeSense.com _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new Reply: Well, what I see is a consolidation of the update process. First, it seems to me that having each software package with its own update mechanism is a duplication of effort and a not very efficient use of space. Second, there are plenty of open source packages, Apache, PHP, etc. which don't have an automated update mechanism. Third, by formalizing the version information for software packages on their web pages, an update service running in the OS could periodically check the web page for updates. As far as real world examples go, there was an article in Dr. Dobb's Journal a few months ago featuring a piece of software somebody wrote to scrape version information off of these web pages using regular expressions (cf. http://www.ddj.com/architect/206503286). This approach, however, is subject to breakage as conventions change. In short, the immediate(?) outcome of having this type of microformat could be a centralized update mechanism which would be automated by a standardization of the version information. Using firefox plugins like Operator, clicking on a download link with the version microformat could interface with the update server, register the software package with it, periodically checking the page for updates and making installations as controlled by the user. -Sam From mephtu at yahoo.com Fri Aug 8 14:38:07 2008 From: mephtu at yahoo.com (Samuel Richter) Date: Fri Aug 8 14:38:10 2008 Subject: [uf-new] New uF: Version Message-ID: <326038.398.qm@web36706.mail.mud.yahoo.com> ----- Original Message ---- From: Ciaran McNulty To: For discussion of new microformats. Sent: Friday, August 8, 2008 9:28:55 AM Subject: Re: [uf-new] New uF: Version On Fri, Aug 8, 2008 at 2:19 PM, Scott Reynen wrote: > I guess I'm not yet convinced by your use case here. An application would > periodically reload the web page for each application to see if it's been > updated? Plenty of applications 'dial home' to see if there are pending updates, and the same applications also have download links, so why not combine the two? It would be nice to see some sort of checksum mechanism possible too. Certainly an idea worth talking about, I agree the markup is a bit premature. -Ciaran McNulty _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new Reply: Yes, checksums as well as a "What's New" snippet to guide the user in making an informed decision. -Sam http://www.xmlhellco.com From mephtu at yahoo.com Fri Aug 8 14:55:28 2008 From: mephtu at yahoo.com (Samuel Richter) Date: Fri Aug 8 14:55:30 2008 Subject: [uf-new] New uF: Version Message-ID: <553425.61288.qm@web36702.mail.mud.yahoo.com> ----- Original Message ---- From: Scott Reynen To: For discussion of new microformats. Sent: Friday, August 8, 2008 11:40:12 AM Subject: Re: [uf-new] New uF: Version On [Aug 8], at [ Aug 8] 8:28 , Ciaran McNulty wrote: > On Fri, Aug 8, 2008 at 2:19 PM, Scott Reynen > wrote: >> I guess I'm not yet convinced by your use case here. An >> application would >> periodically reload the web page for each application to see if >> it's been >> updated? > > Plenty of applications 'dial home' to see if there are pending > updates, and the same applications also have download links, so why > not combine the two? I'm afraid you've misinterpreted my questions as rhetorical. I'm actually asking for the answers to those questions to better understand the use case, not making an argument about the merits of such a use case (I may do that after I understand it). When I said "I'm not yet convinced," that's because I don't yet have enough information to convince me. To make this more concrete, here's a page that has a version number: http://www.panic.com/transmit/ The proposal seems to be to add descriptive markup around the "3.6" on that page. And how does this use case go after that? The Transmit application downloads that document periodically to check for updates? And if a higher version number is found, what happens next? And how does the process differ from how Transmit already checks for updates? And are there any other use cases for such markup? -- Scott Reynen MakeDataMakeSense.com _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new Reply: There could be a "What's New" section which would pop up in the application when a new version is found. I anticipate that this use case would follow existing processes with software update procedures, where the updater/installer periodically checks for the web page for updates, *or* subscribes to an RSS feed which contains the relevant information. Scenario: A higher version is found With the presentation of this information, a decision will be made: to install, or not. But, this would be configurable. For instance, the user may choose not to install alpha or beta software. Or, the user may want to review a list of changes for the new version, consider package size, dependencies, available space, etc. Other use cases: In software development, library information could be published in a form the IDE could process. A similar dialog would be initiated with each new release. Again, some type of subscription or checking mechanism would be in place to keep libraries up-to-date. I'm not aware of how the Transmit application works. Does it do updates automatically? If so, does it automatically download alpha or beta software. Does it inform the user? Does it make the install? What about old versions, does it clean those up? Does it keep an update history? -Sam From tantek at cs.stanford.edu Fri Aug 8 16:59:17 2008 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Fri Aug 8 16:59:20 2008 Subject: [uf-new] New uF: Version In-Reply-To: <1190F2DE-0F4A-45FB-BA82-7E5BC808E7D0@ciaranmcnulty.com> References: <942281.77138.qm@web36702.mail.mud.yahoo.com> <60cb038a0808081142qedcc193u15143f0e56ca8b42@mail.gmail.com> <1190F2DE-0F4A-45FB-BA82-7E5BC808E7D0@ciaranmcnulty.com> Message-ID: <60cb038a0808081659j3898ea8es45c7de650e4be50d@mail.gmail.com> On Fri, Aug 8, 2008 at 2:25 PM, Ciaran McNulty wrote: > > On 8 Aug 2008, at 19:42, Tantek ?elik wrote: >> >> Ciaran, in addition (or perhaps first), you should assume that you're >> not the first person to think of an idea for a microformat, > > Well I know that for a fact in this case, as I didn't start the thread and > just chipped in with a comment! > > :-) Apologies, I misread the attribution chain and thought you had started the thread. Samuel - you started the thread right? Please take a look at the process and the existing work on "downloads". Thanks! Tantek -- http://tantek.com/ From danny.ayers at gmail.com Sat Aug 9 01:14:22 2008 From: danny.ayers at gmail.com (Danny Ayers) Date: Sat Aug 9 01:14:26 2008 Subject: [uf-new] New uF: Version In-Reply-To: <0C63F089-BC8E-4013-870B-F4885B0C1B44@tobyinkster.co.uk> References: <0C63F089-BC8E-4013-870B-F4885B0C1B44@tobyinkster.co.uk> Message-ID: <1f2ed5cd0808090114v34ebac1dhae70debcaa3835d6@mail.gmail.com> 2008/8/8 Toby A Inkster : > Danny Ayers once put together "hDOAP", a "microformat" based on DOAP. The > profile link is here but the link is > broken. The link should now work. My bad: I changed host but forgot to update this PURL. As now noted in the doc, this isn't an official uF because it wasn't developed using the microformats.org process (I'm not even sure the process was in place when I put it together). The GRDDL/round-trip demos using the W3C XSLT service don't currently work (I suspect because of the redirects from PURL). But you can see a sample of the hDOAP markup at: http://hyperdata.org/xmlns/hdoap/samples/redland-doap.html (If I remember correctly, you can ignore the bits like "literal-label" - they're just there for CSS styling). I do think something along these lines could potentially make a viable official microformat, not least because a lot of the preparatory work has been done by Edd Dumbill with DOAP: https://trac.usefulinc.com/doap Also there is now quite a lot of DOAP (RDF) in the wild, e.g. the Apache Software Foundation: http://projects.apache.org/doap.html Cheers, Danny. -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/ From mail at tobyinkster.co.uk Sun Aug 10 04:48:48 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Aug 10 04:49:28 2008 Subject: [uf-new] citation Message-ID: <65330316-5D59-4622-8AB1-248EE51F4860@tobyinkster.co.uk> I've put together a strawman for citations, based on the current examples and brainstorming pages. http://microformats.org/wiki/citation-strawman-01 I'd appreciate feedback either on this list or the issues/ brainstorming pages linked to at the top of that page. -- Toby A Inkster From mephtu at yahoo.com Mon Aug 11 13:08:03 2008 From: mephtu at yahoo.com (Samuel Richter) Date: Mon Aug 11 13:08:06 2008 Subject: [uf-new] New uF: Version Message-ID: <904720.50721.qm@web36707.mail.mud.yahoo.com> ----- Original Message ---- From: Tantek ?elik To: For discussion of new microformats. Sent: Friday, August 8, 2008 6:59:17 PM Subject: Re: [uf-new] New uF: Version On Fri, Aug 8, 2008 at 2:25 PM, Ciaran McNulty wrote: > > On 8 Aug 2008, at 19:42, Tantek ?elik wrote: >> >> Ciaran, in addition (or perhaps first), you should assume that you're >> not the first person to think of an idea for a microformat, > > Well I know that for a fact in this case, as I didn't start the thread and > just chipped in with a comment! > > :-) Apologies, I misread the attribution chain and thought you had started the thread. Samuel - you started the thread right? Please take a look at the process and the existing work on "downloads". Thanks! Tantek -- http://tantek.com/ _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new Thanks, I have. The work seems rudimentary with a bias to Apple. I think, I may be getting ahead of myself. My original idea was for a version uF. All those download implementation use case questions seems to have somehow popped up. -Sam From scott at makedatamakesense.com Mon Aug 11 13:38:40 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Aug 11 13:38:46 2008 Subject: [uf-new] New uF: Version In-Reply-To: <553425.61288.qm@web36702.mail.mud.yahoo.com> References: <553425.61288.qm@web36702.mail.mud.yahoo.com> Message-ID: <06E568AB-E682-489E-A02F-A09F487B7BA6@makedatamakesense.com> On [Aug 8], at [ Aug 8] 3:55 , Samuel Richter wrote: > There could be a "What's New" section which would pop up in the > application when a new version is found. I anticipate that this use > case would follow existing processes with software update > procedures, where the updater/installer periodically checks for the > web page for updates, *or* subscribes to an RSS feed which contains > the relevant information. > > Scenario: A higher version is found > > With the presentation of this information, a decision will be made: > to install, or not. But, this would be configurable. For instance, > the user may choose not to install alpha or beta software. Or, the > user may want to review a list of changes for the new version, > consider package size, dependencies, available space, etc. Thanks for this more detailed use case. Your mention of RSS made me realize hAtom has already solved much of this problem: http://microformats.org/wiki/hatom entry-title is version number, rel-bookmark is the download link, and entry-content is the change details. So I'd suggest starting with that and identifying gaps as they become evident. -- Scott Reynen MakeDataMakeSense.com From mephtu at yahoo.com Tue Aug 12 14:00:55 2008 From: mephtu at yahoo.com (Samuel Richter) Date: Tue Aug 12 14:00:59 2008 Subject: [uf-new] New uF: Version Message-ID: <590916.47821.qm@web36708.mail.mud.yahoo.com> ----- Original Message ---- From: Scott Reynen To: For discussion of new microformats. Sent: Monday, August 11, 2008 3:38:40 PM Subject: Re: [uf-new] New uF: Version On [Aug 8], at [ Aug 8] 3:55 , Samuel Richter wrote: > There could be a "What's New" section which would pop up in the > application when a new version is found. I anticipate that this use > case would follow existing processes with software update > procedures, where the updater/installer periodically checks for the > web page for updates, *or* subscribes to an RSS feed which contains > the relevant information. > > Scenario: A higher version is found > > With the presentation of this information, a decision will be made: > to install, or not. But, this would be configurable. For instance, > the user may choose not to install alpha or beta software. Or, the > user may want to review a list of changes for the new version, > consider package size, dependencies, available space, etc. Thanks for this more detailed use case. Your mention of RSS made me realize hAtom has already solved much of this problem: http://microformats.org/wiki/hatom entry-title is version number, rel-bookmark is the download link, and entry-content is the change details. So I'd suggest starting with that and identifying gaps as they become evident. -- Scott Reynen MakeDataMakeSense.com _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new Reply: Brilliant. That could form the basis for an update mechanism for software subscriptions. What's the next step? -Sam From martin at weborganics.co.uk Wed Aug 13 07:30:16 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 13 07:30:40 2008 Subject: [uf-new] Proposal: change haudio title to htitle. Message-ID: <48A2EFF8.4030807@weborganics.co.uk> Hello. Not so long ago some of you may remember an interesting discussion[1] about the proposal to replace "fn" with "title" in hAudio[2] the result being "fn" was changed to "title". I was one of the people supporting this proposal, my reason being that a title property has been "discovered" and its not the same as "title" (job title) in hcard and is also needed for many proposed or existing microformats such as... Recipes [3] Books [4] Products [5] Videos [6] Art [7] Job Listings [8] Citations [9] There three Main reasons why hAudio and all the above proposed microformats can't realistically use "title" 1, Its already been defined as "Job Title" in hcard 2, It breaks some microformats naming principles such as "Ignoring all earlier work" and "Using others' names to mean different things" 3, It Breaks meta data profiles(xmdp)[10], because if you do include meta-data profiles in the head of your document and you have both a haudio and hcard profiles and you have markup that looks like this....(real markup from a future project)
A broadcast to the Nation, speech by Sir, Winston Churchill. An encouraging military, economic and political assessment of the first ten weeks of war. Recorded on November 12, 1939
Only the FIRST discovered Title definition will be used , in this case its a haudio title, which is wrong when it comes to the title in the hcard because it will be defined as a haudio title So a resolution use *htitle* definition: "What is to be used as a title for the object. Contents are a short textual description used to identify the object among interested parties." hTitle can then be reused in any microformat that needs a "title" property. hTitle has been given a root class name as it is intended to be used in conjunction with any other root class microformat and mirrors the association semantics expressed by hfeed => hentry in hAtom[11] The most desirable thing about a htile microformat is that we dont have to invent new names that mean the same thing such as recipe-title, book-title, product-title etc... they can all use just one. [1] http://microformats.org/discuss/mail/microformats-new/2008-February/001468.html [2] http://microformats.org/wiki/haudio [3] http://microformats.org/wiki/recipe-examples [4] http://microformats.org/wiki/book-info-formats [5] http://microformats.org/wiki/product-examples [6] http://microformats.org/wiki/video-info-examples#Properties [7] http://microformats.org/wiki/workofart-brainstorming#Proposals [8] http://microformats.org/wiki/job-listing-examples [9] http://microformats.org/wiki/citation-examples [10] http://gmpg.org/xmdp/ [11] http://microformats.org/wiki/hatom Thanks all Martin McEvoy From msporny at digitalbazaar.com Wed Aug 13 09:00:10 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 13 09:00:17 2008 Subject: [uf-new] Proposal: change haudio title to htitle. In-Reply-To: <48A2EFF8.4030807@weborganics.co.uk> References: <48A2EFF8.4030807@weborganics.co.uk> Message-ID: <48A3050A.7080202@digitalbazaar.com> Martin McEvoy wrote: > The most desirable thing about a htitle microformat is that we dont have > to invent new names that mean the same thing such as recipe-title, > book-title, product-title etc... they can all use just one. +1 for what it's worth. and if the above doesn't pan out, +1 for audio-title if this doesn't pan out (mostly because this is the only thing that is holding up hAudio and we've been discussing it for over a year now). -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.0 Website Launches http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches From martin at weborganics.co.uk Wed Aug 13 09:08:27 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 13 09:08:58 2008 Subject: [uf-new] Proposal: change haudio title to htitle. In-Reply-To: <48A3050A.7080202@digitalbazaar.com> References: <48A2EFF8.4030807@weborganics.co.uk> <48A3050A.7080202@digitalbazaar.com> Message-ID: <48A306FB.6030302@weborganics.co.uk> Hello Manu, hope you had a nice break :-) Manu Sporny wrote: > Martin McEvoy wrote: > >> The most desirable thing about a htitle microformat is that we dont have >> to invent new names that mean the same thing such as recipe-title, >> book-title, product-title etc... they can all use just one. >> > > +1 for what it's worth. > Thank you for your support... > and if the above doesn't pan out, > > +1 for audio-title if this doesn't pan out (mostly because this is the > only thing that is holding up hAudio and we've been discussing it for > over a year now). > Agreed, I dont think it is just this issue, it was the banning of Andy Mabbet too that stalled the development of haudio. > -- manu > > Best Wishes Martin McEvoy From chucka at hr-xml.org Wed Aug 13 09:47:26 2008 From: chucka at hr-xml.org (Chuck Allen) Date: Wed Aug 13 09:47:33 2008 Subject: [uf-new] Proposal: change haudio title to htitle. In-Reply-To: <48A306FB.6030302@weborganics.co.uk> References: <48A2EFF8.4030807@weborganics.co.uk> <48A3050A.7080202@digitalbazaar.com> <48A306FB.6030302@weborganics.co.uk> Message-ID: <48A3101E.3060301@hr-xml.org> Hi all, I remember this thread. So, I'll offer my once every 6-months chime-in. By all means, just use htitle or title (assuming parsers can disambiguate), but adopting a wee bit of formality might help you nail this once and for all and help the community handle this the next time it crops up. We call something like "title" (or "htitle") a generic data element, which is defined as a "property" term (e.g., title), plus representation type (e.g., text) that can be used in combination with a variety of classes (e.g., recipe, book, position, etc.). htitle. text In your markup, just use htitle in context, but in your data dictionary you have entries like: * recipe. title * book. title * product. title * position. title * job. title Why? Because they **don't mean the same thing** So really this is one of those violent agreement things. +1 I'm just suggesting the wee bit of formality around the use of these "generic data elements" so the community can learn to recognize them and have conventions for dealing with them instead of rehashing every six months. Cheers, Chuck Allen HR-XML Martin McEvoy wrote: > Hello Manu, hope you had a nice break :-) > > Manu Sporny wrote: >> Martin McEvoy wrote: >> >>> The most desirable thing about a htitle microformat is that we dont have >>> to invent new names that mean the same thing such as recipe-title, >>> book-title, product-title etc... they can all use just one. >>> >> >> +1 for what it's worth. >> > > Thank you for your support... >> and if the above doesn't pan out, >> >> +1 for audio-title if this doesn't pan out (mostly because this is the >> only thing that is holding up hAudio and we've been discussing it for >> over a year now). >> > > Agreed, I dont think it is just this issue, it was the banning of Andy > Mabbet too that stalled the development of haudio. >> -- manu >> >> > > Best Wishes > > Martin McEvoy > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new -- -- Chuck Allen --------------- +1 919 247 6881 --------------- Attend HR-XML's Partnering and Integration Summit http://www.partneringsummit.org --------------- From csarven at gmail.com Wed Aug 13 10:01:33 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Wed Aug 13 10:01:37 2008 Subject: [uf-new] Proposal: change haudio title to htitle. In-Reply-To: <48A2EFF8.4030807@weborganics.co.uk> References: <48A2EFF8.4030807@weborganics.co.uk> Message-ID: On Wed, Aug 13, 2008 at 10:30 AM, Martin McEvoy wrote: > Only the FIRST discovered Title definition will be used , in this case its a > haudio title, which is wrong when it comes to the title in the hcard because > it will be defined as a haudio title There may actually be room for the use of MFO (Microformat Object or Microformat Opacity or Microformat Opaque) [1] to differentiate one title from another. > hTitle can then be reused in any microformat that needs a "title" property. > hTitle has been given a root class name as it is intended to be used in > conjunction with any other root class microformat and mirrors the > association semantics expressed by hfeed => hentry in hAtom[11] > > The most desirable thing about a htile microformat is that we dont have to > invent new names that mean the same thing such as recipe-title, book-title, > product-title etc... they can all use just one. Good idea. +1 for htitle. [1] http://microformats.org/wiki/mfo -Sarven From mail at tobyinkster.co.uk Wed Aug 13 13:19:33 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 13 13:20:00 2008 Subject: [uf-new] Proposal: change haudio title to htitle. Message-ID: In my experience, from a practical point of view, it's not really needed - even if no microformats had any property names in common, parsers still need to take care over microformat opacity due to situations like:
...
And it doesn't seem to have proved a problem for 'url', which is defined fairly differently in RFC 2426 (vCard) and RFC 2445 (iCalendar). 'contact' also has different meanings in hCalendar and XFN (though of course, one is a class and one a rel). This seems to be a solution to a problem which doesn't exist. A better issue to debate would be how to resolve problem that XMDP knows nothing about nesting, making it a blunt tool to define the meanings of properties within compound microformats. -- Toby A Inkster From scott at makedatamakesense.com Wed Aug 13 20:40:49 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Aug 13 20:40:58 2008 Subject: [uf-new] Proposal: change haudio title to htitle. In-Reply-To: References: Message-ID: <1BD65D69-6315-47AE-B910-BB50C0874EE0@makedatamakesense.com> On [Aug 13], at [ Aug 13] 2:19 , Toby A Inkster wrote: > In my experience, from a practical point of view, it's not really > needed - even if no microformats had any property names in common, > parsers still need to take care over microformat opacity due to > situations like: > >
>
I don't think that's a similar situation at all. hCard parsers must know how to handle embedded agent hCards, because it's part of the hCard spec. On the other hand, hCard parsers not only don't need to know how to handle embedded hAudio, but in many cases they couldn't possibly know because they were written before hAudio even existed. > And it doesn't seem to have proved a problem for 'url', which is > defined fairly differently in RFC 2426 (vCard) and RFC 2445 > (iCalendar). Untrue. Here are two documented real world examples (or rather two sites with thousands of examples) of exactly this problem: http://microformats.org/wiki/mfo#hCard_in_hCalendar > This seems to be a solution to a problem which doesn't exist. Again, untrue. There are more examples on the MFO page. If it's a rare problem, that's because it only comes up when microformats are used in high density. Rather than being edge cases, these cases are the core of what we're trying to do with microformats. We're trying to encourage descriptive markup, and it's the sites with the most descriptive markup where existing parsing rules leave ambiguity. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Thu Aug 14 04:22:07 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Aug 14 04:22:14 2008 Subject: [uf-new] Proposal: change haudio title to htitle. In-Reply-To: <1BD65D69-6315-47AE-B910-BB50C0874EE0@makedatamakesense.com> References: <1BD65D69-6315-47AE-B910-BB50C0874EE0@makedatamakesense.com> Message-ID: <48A4155F.7030901@weborganics.co.uk> Hello Scott, Toby... Scott Reynen wrote: > On [Aug 13], at [ Aug 13] 2:19 , Toby A Inkster wrote: > >> In my experience, from a practical point of view, it's not really >> needed - even if no microformats had any property names in common, >> parsers still need to take care over microformat opacity due to >> situations like: >> >>
>>
> > > I don't think that's a similar situation at all. hCard parsers must > know how to handle embedded agent hCards, because it's part of the > hCard spec. On the other hand, hCard parsers not only don't need to > know how to handle embedded hAudio, but in many cases they couldn't > possibly know because they were written before hAudio even existed. > >> And it doesn't seem to have proved a problem for 'url', which is >> defined fairly differently in RFC 2426 (vCard) and RFC 2445 (iCalendar). > > > Untrue. Here are two documented real world examples (or rather two > sites with thousands of examples) of exactly this problem: > > http://microformats.org/wiki/mfo#hCard_in_hCalendar > >> This seems to be a solution to a problem which doesn't exist. > > Again, untrue. There are more examples on the MFO page. If it's a > rare problem, that's because it only comes up when microformats are > used in high density. Rather than being edge cases, these cases are > the core of what we're trying to do with microformats. We're trying > to encourage descriptive markup, and it's the sites with the most > descriptive markup where existing parsing rules leave ambiguity. Is the "item" property in haudio MFO? Item *The element /MUST/ be processed opaquely. No sub-elements should be read from any hAudio contained in a track element. http://microformats.org/wiki/haudio#Item ... or am I misunderstanding the "microformat object(opaque)" problem. Thanks Martin McEvoy > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From scott at makedatamakesense.com Thu Aug 14 06:25:34 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Thu Aug 14 06:25:42 2008 Subject: [uf-new] Opacity (Was: change haudio title to htitle.) In-Reply-To: <48A4155F.7030901@weborganics.co.uk> References: <1BD65D69-6315-47AE-B910-BB50C0874EE0@makedatamakesense.com> <48A4155F.7030901@weborganics.co.uk> Message-ID: <60517388-79F2-4C41-82F4-20F442C02DA1@makedatamakesense.com> On [Aug 14], at [ Aug 14] 5:22 , Martin McEvoy wrote: > Is the "item" property in haudio MFO? > > Item > > *The element /MUST/ be processed opaquely. No sub-elements should be > read from any hAudio contained in a track element. > > http://microformats.org/wiki/haudio#Item > > ... or am I misunderstanding the "microformat object(opaque)" problem. Item solves a small part of the problem MFO proposes to solve. Item has an opacity rule for embedding hAudio within hAudio. MFO would provide a similar rule for embedding anything within anything else. By detaching the opacity indicator from a specific microformat, MFO would have the advantages of being usable for embedding future microformats. For example, hAtom has no rule for opacity of embedded hAudio, and it couldn't possibly have such a rule because hAudio did not exist when hAtom was created. Because both use "published," this leaves room for ambiguity MFO would remove. MFO also has the advantage of decoupling opacity from other semantics. Item makes it impossible to embed another hAudio with a shared name, but MFO would make that possible by giving the publisher more control over describing the meaning of their content. This could reduce unnecessary duplication, for example, in describing single- track album releases. The documented real-world examples with widely-published microformats are, of course, far more relevant than the above hypothetical examples with nascent hAudio: http://microformats.org/wiki/mfo#Examples -- Scott Reynen MakeDataMakeSense.com From mail at tobyinkster.co.uk Thu Aug 14 08:10:45 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Aug 14 08:11:21 2008 Subject: [uf-new] Opacity (Was: change haudio title to htitle.) Message-ID: There are really two problems being discussed here. Microformat opacity and class name clashes between microformats. A solution to the former problem relegates the latter to a mere matter of aesthetics; a solution to the latter problem does nothing for the former problem. To illustrate, say we solve the "title" problem by defining "htitle" as a common title/heading property. That alone will not solve:

My Thoughts for the Day

Foo Song Sucks

Foo Song

Without microformat opacity, the hentry's title could be parsed as any of "My Thoughts for the Day", "Foo Song Sucks" or "Foo Song". "htitle" would do nothing to solve this. Better implementation of MFO in parsers would. I have documented Cognition's MFO on the Wiki. Back in March I outlined the gist of the algorithm here: http://microformats.org/wiki/mfo- brainstorming#mfo_class_is_a_workable_solution More recently, I've documented Cognition's entire Microformat parsing algorithm (apart from recent support I've added for parsing durations) here: http://microformats.org/wiki/parsing-brainstorming I believe this offers a bullet-proof approach to microformat opacity, but would certainly appreciate counter-examples to further refine the algorithm. I'd suggest that this discussion shift to uf-dev. -- Toby A Inkster From martin at weborganics.co.uk Thu Aug 14 09:04:09 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Aug 14 09:04:21 2008 Subject: [uf-new] Opacity (Was: change haudio title to htitle.) In-Reply-To: References: Message-ID: <48A45779.1070205@weborganics.co.uk> Hello Toby... Toby A Inkster wrote: > There are really two problems being discussed here. Microformat > opacity and class name clashes between microformats. A solution to the > former problem relegates the latter to a mere matter of aesthetics; a > solution to the latter problem does nothing for the former problem. > > To illustrate, say we solve the "title" problem by defining "htitle" > as a common title/heading property. That alone will not solve: > >
>

My Thoughts for the Day

>
>

Foo Song Sucks

>
>

Foo Song

>
>
>
I think you misunderstand my proposal, I am not proposing that anything should change in hAtom, hReview or any other existing Draft Microformat, just hAudio, other in progress, or future microformat, this is how the proposal will work....

My Thoughts for the Day

Foo Song Sucks

Foo Song

the only way it *could* be useful to hAtom is as an *extra* property maybe as a feed title.

My Blog Title

My Thoughts for the Day

Foo Song Sucks

Foo Song

Best Wishes Martin McEvoy > > Without microformat opacity, the hentry's title could be parsed as any > of "My Thoughts for the Day", "Foo Song Sucks" or "Foo Song". "htitle" > would do nothing to solve this. Better implementation of MFO in > parsers would. > > I have documented Cognition's MFO on the Wiki. Back in March I > outlined the gist of the algorithm here: > > http://microformats.org/wiki/mfo-brainstorming#mfo_class_is_a_workable_solution > > > More recently, I've documented Cognition's entire Microformat parsing > algorithm (apart from recent support I've added for parsing durations) > here: > > http://microformats.org/wiki/parsing-brainstorming > > I believe this offers a bullet-proof approach to microformat opacity, > but would certainly appreciate counter-examples to further refine the > algorithm. > > I'd suggest that this discussion shift to uf-dev. > From mail at tobyinkster.co.uk Thu Aug 14 13:13:21 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu Aug 14 13:13:51 2008 Subject: [uf-new] Opacity (Was: change haudio title to htitle.) Message-ID: <557613CC-CB9E-4D3F-98F6-F3E08B9F2D1A@tobyinkster.co.uk> > I think you misunderstand my proposal, I am not proposing that > anything > should change in hAtom, hReview or any other existing Draft > Microformat, > just hAudio, other in progress, or future microformat, this is how > the > proposal will work.... No, I don't misunderstand. Perhaps hAtom and hReview were perhaps a bad example on my part, as they distract from the core issue. Consider some hypothetical new microformats: hFee, hFie, hFoe and hFum, each of which has an htitle. The same problem arises.
Title 2
Title 4
Title 3
Title 1
An hFee parser with no knowledge of hFie, hFoe or hFum cannot know which title belongs to the outer hFee. Basically, a good microformat parser has no choice but to know about all existing (and draft) compound microformats. (It doesn't need to have intimate knowledge - just know the root class name.) So we basically have three choices: 1. Parsers need to be updated continually. Whenever a new draft compound microformat is added to the wiki, all the parsers need to be updated with the root class name. 2. Alternatively, there are no more microformats. We call it a day. That way, the parsers only need to be updated for actual improvements - not updated every time a new microformat comes out. 3. We provide a method for parsers to recognise unknown microformats as *being* microformats (and thus, as being opaque). Some possible ways of doing this: all new microformat root class names match a particular regular expression (e.g. class="haudio-container", class="hproduct-container', etc) or are required to include a common class name as well as their root class name (e.g. class="haudio mfo", class="hproduct mfo", etc). That way, all parsers just need to be updated to recognise this method, and new microformats can be freely created using it, without worrying about updating them every time a new format comes out. -- Toby A Inkster From davidjanes at blogmatrix.com Thu Aug 14 13:27:24 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Thu Aug 14 13:27:27 2008 Subject: [uf-new] Opacity (Was: change haudio title to htitle.) In-Reply-To: <557613CC-CB9E-4D3F-98F6-F3E08B9F2D1A@tobyinkster.co.uk> References: <557613CC-CB9E-4D3F-98F6-F3E08B9F2D1A@tobyinkster.co.uk> Message-ID: <21e523c20808141327r6bc2ded6y73e118827d328d3e@mail.gmail.com> On Thu, Aug 14, 2008 at 4:13 PM, Toby A Inkster wrote: > 3. We provide a method for parsers to recognise unknown microformats as > *being* microformats (and thus, as being opaque). Some possible ways of > doing this: all new microformat root class names match a particular regular > expression (e.g. class="haudio-container", class="hproduct-container', etc) > or are required to include a common class name as well as their root class > name (e.g. class="haudio mfo", class="hproduct mfo", etc). That way, all > parsers just need to be updated to recognise this method, and new > microformats can be freely created using it, without worrying about updating > them every time a new format comes out. This was one of the ideas I was trying to explore with the "item" concept [1], which builds upon some existing microformat terms. Regards, etc... [1] http://microformats.org/wiki/item -- David Janes From martin at weborganics.co.uk Thu Aug 14 17:11:10 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Aug 14 17:11:18 2008 Subject: [uf-new] Opacity (Was: change haudio title to htitle.) In-Reply-To: <21e523c20808141327r6bc2ded6y73e118827d328d3e@mail.gmail.com> References: <557613CC-CB9E-4D3F-98F6-F3E08B9F2D1A@tobyinkster.co.uk> <21e523c20808141327r6bc2ded6y73e118827d328d3e@mail.gmail.com> Message-ID: <48A4C99E.1050704@weborganics.co.uk> Hello David, Toby...all David Janes wrote: > On Thu, Aug 14, 2008 at 4:13 PM, Toby A Inkster wrote: > >> 3. We provide a method for parsers to recognise unknown microformats as >> *being* microformats (and thus, as being opaque). Some possible ways of >> doing this: all new microformat root class names match a particular regular >> expression (e.g. class="haudio-container", class="hproduct-container', etc) >> or are required to include a common class name as well as their root class >> name (e.g. class="haudio mfo", class="hproduct mfo", etc). That way, all >> parsers just need to be updated to recognise this method, and new >> microformats can be freely created using it, without worrying about updating >> them every time a new format comes out. >> > > This was one of the ideas I was trying to explore with the "item" > concept [1], which builds upon some existing microformat terms. > > Regards, etc... > > [1] http://microformats.org/wiki/item > And the reason why Item was chosen to mean this is some "thing" that should be treated as its own object... > It is important to understand that ITEM is an opaque element. When > processing the ITEM element, none of the properties of the child > hAudio should be pulled into the parent hAudio. http://microformats.org/wiki/haudio#Parser_Processing_Notes Its a bit vague it basically means haudio has a way of calling the same class names in different contexts and not get the two confused..
Great Playlist Great track
Dont get me wrong I am not saying lets use "item" or "mfo" or any such word, what I am saying is items parsing rule *can* be applied to all root class microformats, hcard already has a similar rule ... > When parsing an hCard, if a parser finds a nested hCard, it should > treat that hCard as its own object, and treat properties of the nested > hCard as only belonging to the nested hCard, not the containing hCard. > > This is essential for example for handling use of the "agent" property > to nest an hCard that is the agent of another hCard http://microformats.org/wiki/hcard-parsing#nested_hCards For what it's worth I feel a little like a dog chasing my own tail , because I am not sure this is an authoring issue just a parser issue. Best Wishes Martin McEvoy From scott at makedatamakesense.com Fri Aug 15 06:22:06 2008 From: scott at makedatamakesense.com (Scott Reynen) Date: Fri Aug 15 06:22:15 2008 Subject: [uf-new] Opacity (Was: change haudio title to htitle.) In-Reply-To: <557613CC-CB9E-4D3F-98F6-F3E08B9F2D1A@tobyinkster.co.uk> References: <557613CC-CB9E-4D3F-98F6-F3E08B9F2D1A@tobyinkster.co.uk> Message-ID: <09DDB9ED-9559-442D-9B74-31F06A3ACED7@makedatamakesense.com> On [Aug 14], at [ Aug 14] 9:10 , Toby A Inkster wrote: > I'd suggest that this discussion shift to uf-dev. We shouldn't be establishing new markup semantics on the -dev list. Once we've done that on the -new list, the -dev list can talk about how to parse the markup, but right now there's nothing to parse. To try to point the discussion in a more publisher-centric direction, I'd like to rephrase the problem: how can publishers indicate a limited context of relevance for the assertions they've published? I think "opacity" is a very developer-focused terminology for describing this problem, making it seem like a developer-centric issue, but it's not really. -- Scott Reynen MakeDataMakeSense.com From martin at weborganics.co.uk Sat Aug 16 19:08:41 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Aug 16 19:08:51 2008 Subject: [uf-new] [uf-discuss] hAudio issue: position References: XSTPtcctuqhHFwNE@pigsonthewing.org.uk Message-ID: <48A78829.20607@weborganics.co.uk> Hello All. I would Like to close Issue D3: 2008-01-10 raised by Andy Mabbett in http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html as it was resolved in this email http://microformats.org/discuss/mail/microformats-discuss/2008-January/011353.html I would also like to add that the proposal should change to : Position The position is used to describe the position of the hAudio item in a list. Examples of hAudio lists can include album track listings, music top 10 lists, playlists, and podcast chapters. * The element is identified by the class name |position|. * hAudio /MAY/ include one |position| element. * The contents of the element /MUST/ be a number or other sequential identifier. * The Contents Can be specified out-of-sequence. http://microformats.org/wiki/haudio#Position the last section was added because the order in a playlist may not be the same as the track number. Thanks Martin McEvoy From msporny at digitalbazaar.com Sat Aug 16 22:24:13 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Aug 16 22:24:18 2008 Subject: [uf-new] hAudio issue D3: position In-Reply-To: <48A78829.20607@weborganics.co.uk> References: XSTPtcctuqhHFwNE@pigsonthewing.org.uk <48A78829.20607@weborganics.co.uk> Message-ID: <48A7B5FD.1050704@digitalbazaar.com> Martin McEvoy wrote: > I would Like to close Issue D3: 2008-01-10 raised by Andy Mabbett in > http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html > > as it was resolved in this email > http://microformats.org/discuss/mail/microformats-discuss/2008-January/011353.html +1 We should close issue haudio-D3 with Martin's edit. We would use the current text in the description of position: http://microformats.org/wiki/haudio#Position and add the following rule to the end: * The sequential identifier MAY be specified out-of-sequence. -- manu From msporny at digitalbazaar.com Sat Aug 16 22:36:32 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sat Aug 16 22:36:36 2008 Subject: [uf-new] Moving hAudio to Draft stage Message-ID: <48A7B8E0.8090303@digitalbazaar.com> We currently have 5 open issues for hAudio that should be fairly easy to resolve now that we have a proposal on the table, "htitle" by Martin McEvoy, to resolve the contentious "title" debate on hAudio. I'd like to set a goal to close all remaining hAudio issues in the next 2-4 weeks. I'm sending this e-mail out as a heads-up to those that are interested in helping to improve hAudio and to get it to the next step in the Microformats process: Draft Specification. Both Martin and I will be posting the remaining hAudio issues and will be asking for feedback from the community in order to resolve the issues. Please respond to each issue with a +1 or a -1 if you have input on each issue and we'll hopefully close each of these issues if we reach a reasonable amount of consensus. -- manu From martin at weborganics.co.uk Sun Aug 17 01:53:02 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Aug 17 01:53:12 2008 Subject: [uf-new] hAudio issue D3: position In-Reply-To: <48A7B5FD.1050704@digitalbazaar.com> References: XSTPtcctuqhHFwNE@pigsonthewing.org.uk <48A78829.20607@weborganics.co.uk> <48A7B5FD.1050704@digitalbazaar.com> Message-ID: <48A7E6EE.2010302@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >> I would Like to close Issue D3: 2008-01-10 raised by Andy Mabbett in >> http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html >> >> as it was resolved in this email >> http://microformats.org/discuss/mail/microformats-discuss/2008-January/011353.html >> > > +1 > > We should close issue haudio-D3 with Martin's edit. We would use the > current text in the description of position: > > http://microformats.org/wiki/haudio#Position > > and add the following rule to the end: > > * The sequential identifier MAY be specified out-of-sequence. > > -- manu > +1 > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From martin at weborganics.co.uk Sun Aug 17 02:11:38 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Aug 17 02:11:49 2008 Subject: [uf-new] Re: hAudio contributor Issue In-Reply-To: <4896FE05.40105@weborganics.co.uk> References: <4896FE05.40105@weborganics.co.uk> Message-ID: <48A7EB4A.20709@weborganics.co.uk> I raised this issue earlier this month with the proposal that this issue be closed. http://microformats.org/discuss/mail/microformats-new/2008-August/001648.html After two weeks and no feedback. I closed this Issue. http://microformats.org/wiki?title=haudio-issues&diff=28245&oldid=28242 Andy emailed me personally to say that this issue should not be closed, because he is unable to respond to the list. Manu also emailed me and Informed me that he is inclined to accept this as an issue he says that the haudio contributor text should be changed to something like: * The contributor's name SHOULD also be marked up as a valid hCard Microformat. * The contributor's name MAY be specified in plain-text without being enclosed in a hCard Microformat. http://microformats.org/wiki/haudio#Contributor I have now re opened this issue as it is clearly not resolved. If this Issue can be resolved so easily. +1 from me. Thanks Martin McEvoy From martin at weborganics.co.uk Mon Aug 18 07:56:55 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 07:57:06 2008 Subject: [uf-new] hAudio Issue D1: 2008-01-10 Contributor. Resolution In-Reply-To: <48A7EB4A.20709@weborganics.co.uk> References: <4896FE05.40105@weborganics.co.uk> <48A7EB4A.20709@weborganics.co.uk> Message-ID: <48A98DB7.9030505@weborganics.co.uk> I would like to confirm the resolution to haudio issue D1: 2008-01-10 Contributor [1] The hAudio Specification should be changed to facilitate a more streamlined mark-up Upon recommendations from Manu the Specification should be changed (slightly) to. Contributor [2] A Contributor is any entity that takes part in the creation and distribution of an audio recording. Examples include: artist, composer, publisher, guitarist, vocalist, violinist, lead singer, backup singer, bassist, drummer, manager, and roadie. * The element is identified by the class name |contributor|. * hAudio /MAY/ include one or more contributors. * The contributor's name SHOULD also be marked up as a valid hCard Microformat. o The |role| attribute /SHOULD/ be used to specify the contributor's responsibility related to the audio recording if hCard is utilized. * The contributor's name MAY be specified in plain-text without being enclosed in a hCard Microformat. * If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator. This applies to plain-text contributor markup as well. [1] http://microformats.org/wiki/haudio-issues#D1:_2008-01-10__Contributor [2] http://microformats.org/wiki/haudio#Contributor Thanks Martin McEvoy From martin at weborganics.co.uk Mon Aug 18 08:53:51 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 08:54:04 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files Message-ID: <48A99B0F.3070100@weborganics.co.uk> Hello All Issue D4: 2008-01-10 [1] Raised by Andy Mabbett in (/http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html/) The required use of rel-enclosure does not allow for links to streaming files, which are not cacheable, and are thus outside the scope of rel-enclosure. An example on (/http://www.bbc.co.uk/radio4/science/livingworld_20041121.shtml/) has the relevant link is below the heading "LISTEN AGAIN". [1] http://microformats.org/wiki/haudio-issues#D4:_2008-01-10__rel-enclosure_does_not_allow_for_links_to_streaming_files I have looked at the cited example to this issue and I can't see a problem with marking the link up with rel-enclosure this link: Listen to 21 November can be marked up in haudio like this: Listen to 21 November I would like to note ".ram" files can be cached and downloaded. I do however agree that rel-enclosure IS unsuitable for some types of files such as audio streamed directly from a server. I would like to Recommend that this issue should be closed, pending further examples. Thanks Martin McEvoy From msporny at digitalbazaar.com Mon Aug 18 09:54:09 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Aug 18 09:54:14 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files In-Reply-To: <48A99B0F.3070100@weborganics.co.uk> References: <48A99B0F.3070100@weborganics.co.uk> Message-ID: <48A9A931.6030406@digitalbazaar.com> Martin McEvoy wrote: > Issue D4: 2008-01-10 [1] > > Raised by Andy Mabbett > in > (/http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html/) > > I do however agree that rel-enclosure IS unsuitable for some types of > files such as audio streamed directly from a server. I disagree, Martin. rel-enclosure is suitable for any type of file, "static" or "streaming", but my interpretation of rel-enclosure could be wrong. I believe that Andy was taking issue at the definition of rel-enclosure: "By adding rel="enclosure" to a hyperlink, a page indicates that the destination of that hyperlink is intended to be downloaded and cached." Take note of the "intended to be downloaded and cached" part of the specification. The term "cached" is problematic because some would understand that in the sense that it is "stored forever", others would understand it as "stored for an undetermined period of time, as a whole or as a part of a whole." I lean towards the second definition, which results in rel-enclosure being suitable for any digital file format (static file or dynamic stream). Afterall, you must /download/ the link in order to do anything with the data and that data must be /cached/ somewhere on your computer. So, we either need to agree that this is a non-issue and rel-enclosure is suitable for static and streaming files, or we need to create a new concept, like rel="download". My preference is to resolve that rel-enclosure is applicable to both static and streaming files and note the decision on the rel-enclosure wiki page. > I would like to Recommend that this issue should be closed, pending > further examples. I don't believe the problem with this issue to be one of more examples, but one of interpretation of the rel-enclosure specification. I propose we: Resolve to accept that rel-enclosure can be applied to both static and streaming files and note the decision on the rel-enclosure wiki page. -- manu From tantek at cs.stanford.edu Mon Aug 18 10:05:27 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Mon Aug 18 10:05:56 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allowfor links to streaming files Message-ID: <1652598821-1219079148-cardhu_decombobulator_blackberry.rim.net-1568821272-@bxe017.bisx.prod.on.blackberry> Apologies for top-posting. BlackBerry email UI does not allow quoting prev email & adding below. In short: I agree w Manu, the intent of rel-enclosure is to apply to the streaming case as well. If we change: " that hyperlink is intended to be downloaded and cached" to: " that hyperlink is intended to be downloaded (and/or streamed) and cached (and/or buffered)" that should be sufficient to resolve this issue. Thanks, Tantek -----Original Message----- From: Manu Sporny Date: Mon, 18 Aug 2008 12:54:09 To: For discussion of new microformats. Subject: Re: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files Martin McEvoy wrote: > Issue D4: 2008-01-10 [1] > > Raised by Andy Mabbett > in > (/http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html/) > > I do however agree that rel-enclosure IS unsuitable for some types of > files such as audio streamed directly from a server. I disagree, Martin. rel-enclosure is suitable for any type of file, "static" or "streaming", but my interpretation of rel-enclosure could be wrong. I believe that Andy was taking issue at the definition of rel-enclosure: "By adding rel="enclosure" to a hyperlink, a page indicates that the destination of that hyperlink is intended to be downloaded and cached." Take note of the "intended to be downloaded and cached" part of the specification. The term "cached" is problematic because some would understand that in the sense that it is "stored forever", others would understand it as "stored for an undetermined period of time, as a whole or as a part of a whole." I lean towards the second definition, which results in rel-enclosure being suitable for any digital file format (static file or dynamic stream). Afterall, you must /download/ the link in order to do anything with the data and that data must be /cached/ somewhere on your computer. So, we either need to agree that this is a non-issue and rel-enclosure is suitable for static and streaming files, or we need to create a new concept, like rel="download". My preference is to resolve that rel-enclosure is applicable to both static and streaming files and note the decision on the rel-enclosure wiki page. > I would like to Recommend that this issue should be closed, pending > further examples. I don't believe the problem with this issue to be one of more examples, but one of interpretation of the rel-enclosure specification. I propose we: Resolve to accept that rel-enclosure can be applied to both static and streaming files and note the decision on the rel-enclosure wiki page. -- manu _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Mon Aug 18 10:15:24 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Aug 18 10:15:30 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files In-Reply-To: <1652598821-1219079148-cardhu_decombobulator_blackberry.rim.net-1568821272-@bxe017.bisx.prod.on.blackberry> References: <1652598821-1219079148-cardhu_decombobulator_blackberry.rim.net-1568821272-@bxe017.bisx.prod.on.blackberry> Message-ID: <48A9AE2C.1010604@digitalbazaar.com> Tantek Celik wrote: > In short: I agree w Manu, the intent of rel-enclosure is to apply to the streaming case as well. > > If we change: > > " that hyperlink is intended to be downloaded and cached" > > to: > > " that hyperlink is intended to be downloaded (and/or streamed) and cached (and/or buffered)" > > that should be sufficient to resolve this issue. +1 to Tantek's proposed wording. Any opposition? -- manu From martin at weborganics.co.uk Mon Aug 18 10:35:32 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 10:35:45 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files In-Reply-To: <48A9A931.6030406@digitalbazaar.com> References: <48A99B0F.3070100@weborganics.co.uk> <48A9A931.6030406@digitalbazaar.com> Message-ID: <48A9B2E4.9010900@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >> Issue D4: 2008-01-10 [1] >> >> Raised by Andy Mabbett >> in >> (/http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html/) >> >> I do however agree that rel-enclosure IS unsuitable for some types of >> files such as audio streamed directly from a server. >> > > I disagree, Martin. rel-enclosure is suitable for any type of file, > "static" or "streaming", but my interpretation of rel-enclosure could be > wrong. > I Agree also.... > I believe that Andy was taking issue at the definition of rel-enclosure: > > "By adding rel="enclosure" to a hyperlink, a page indicates that the > destination of that hyperlink is intended to be downloaded and cached." > > Take note of the "intended to be downloaded and cached" part of the > specification. The term "cached" is problematic because some would > understand that in the sense that it is "stored forever", others would > understand it as "stored for an undetermined period of time, as a whole > or as a part of a whole." > > I lean towards the second definition, which results in rel-enclosure > being suitable for any digital file format (static file or dynamic > stream). Afterall, you must /download/ the link in order to do anything > with the data and that data must be /cached/ somewhere on your computer. > Something I tried to assert in a previous email http://microformats.org/discuss/mail/microformats-new/2008-January/001342.html > So, we either need to agree that this is a non-issue and rel-enclosure > is suitable for static and streaming files, or we need to create a new > concept, like rel="download". > My preference is to resolve that rel-enclosure is applicable to both > static and streaming files and note the decision on the rel-enclosure > wiki page. > > Agreed >> I would like to Recommend that this issue should be closed, pending >> further examples. >> > > I don't believe the problem with this issue to be one of more examples, > but one of interpretation of the rel-enclosure specification. > Noted. > I propose we: > > Resolve to accept that rel-enclosure can be applied to both static and > streaming files and note the decision on the rel-enclosure wiki page. > > +1 Martin McEvoy > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From martin at weborganics.co.uk Mon Aug 18 10:39:01 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 10:39:25 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files In-Reply-To: <48A9AE2C.1010604@digitalbazaar.com> References: <1652598821-1219079148-cardhu_decombobulator_blackberry.rim.net-1568821272-@bxe017.bisx.prod.on.blackberry> <48A9AE2C.1010604@digitalbazaar.com> Message-ID: <48A9B3B5.7020706@weborganics.co.uk> Manu Sporny wrote: > Tantek Celik wrote: > >> In short: I agree w Manu, the intent of rel-enclosure is to apply to the streaming case as well. >> >> If we change: >> >> " that hyperlink is intended to be downloaded and cached" >> >> to: >> >> " that hyperlink is intended to be downloaded (and/or streamed) and cached (and/or buffered)" >> >> that should be sufficient to resolve this issue. >> > > to Tantek's proposed wording. > > Any opposition? > > -- manu > > +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- > microformats-new mailing list > microformats-new+AEA-microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From martin at weborganics.co.uk Mon Aug 18 10:56:21 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 10:56:34 2008 Subject: [uf-new] hAudio Issue D5: 2008-01-10 there is no way of linking to an interim page Message-ID: <48A9B7C5.2070002@weborganics.co.uk> Hello RE: Issue D5: 2008-01-10 there is no way of linking to an interim page[1]. Raised by Andy Mabbett in http://microformats.org/discuss/mail/microformats-discuss/2008-January/011345.html There appears to be no mechanism to mark up an hAudio, expressed in plain text on page A, which links to an interim page, B, which in turn links to a file download. For example, the radio shows listed on (/http://www.westmidlandbirdclub.com/bibliography/radio/). [1] http://microformats.org/wiki/haudio-issues#D5:_2008-01-10__there_is_no_way_of_linking_to_an_interim_page A solution was suggested in this email: http://microformats.org/discuss/mail/microformats-new/2008-January/001342.html "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" Thank You Martin McEvoy From martin at weborganics.co.uk Mon Aug 18 11:14:28 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 11:14:41 2008 Subject: [uf-new] hAudio Issue D6: 2008-01-10 hAudio notes inconsistency Message-ID: <48A9BC04.4030807@weborganics.co.uk> Hello RE: 2008-01-10 hAudio notes inconsistency [1] Raised by Andy Mabbett in http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html The "Notes" section of the hAudio spec says "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content MAY be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using rel-license as specified above.". However, that is the first and only reference to rel-license on the page. I initially closed this issue marking it as a typing error rel-licence is not part of the specification, but the question still remains "should the hAudio Specification include rel-licence" I have re-opened this issue in order that this issue be addressed correctly. Proposed resolution: The hAudio Specification SHOULD include the rel-license microformat. 1, because rel-licence already implicitly exists in haudio it just hasn't been discussed yet. 2, I DO think it is valuable to know which audio files I can freely download no conditions, and ones that may have certain conditions that must be met before I can download this file. Thanks Martin McEvoy From martin at weborganics.co.uk Mon Aug 18 11:15:33 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 11:15:46 2008 Subject: [uf-new] Re: hAudio Issue D6: 2008-01-10 hAudio notes inconsistency In-Reply-To: <48A9BC04.4030807@weborganics.co.uk> References: <48A9BC04.4030807@weborganics.co.uk> Message-ID: <48A9BC45.70801@weborganics.co.uk> Martin McEvoy wrote: > Hello > > > RE: 2008-01-10 hAudio notes inconsistency [1] > > Raised by Andy Mabbett in > http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html > > > The "Notes" section of the hAudio spec says "By marking up audio > content with the hAudio microformat, the expectation is communicated > that information about the content MAY be indexed. This has no impact > on the copyright of the content itself which the publisher may > explicitly specify using rel-license as specified above.". However, > that is the first and only reference to rel-license on the page. sorry: [http://microformats.org/wiki/haudio-issues#D6:_2008-01-10_hAudio_notes_inconsistency] > I initially closed this issue marking it as a typing error rel-licence > is not part of the specification, but the question still remains > "should the hAudio Specification include rel-licence" I have > re-opened this issue in order that this issue be addressed correctly. > > Proposed resolution: > > The hAudio Specification SHOULD include the rel-license microformat. > > 1, because rel-licence already implicitly exists in haudio it > just hasn't been discussed yet. > > 2, I DO think it is valuable to know which audio files I can freely > download no conditions, and ones that may have certain conditions that > must be met before I can download this file. > > > Thanks > > Martin McEvoy > > > > From msporny at digitalbazaar.com Mon Aug 18 11:53:05 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Aug 18 11:53:10 2008 Subject: [uf-new] hAudio Issue D1: 2008-01-10 Contributor. Resolution In-Reply-To: <48A98DB7.9030505@weborganics.co.uk> References: <4896FE05.40105@weborganics.co.uk> <48A7EB4A.20709@weborganics.co.uk> <48A98DB7.9030505@weborganics.co.uk> Message-ID: <48A9C511.8080606@digitalbazaar.com> I am forwarding a message that Andy Mabbett sent to a couple of us involved with hAudio development because it is a valid opposition to the proposed resolution to hAudio issue D1. ------------------------------------------------------------------------ In message <48A98DB7.9030505@weborganics.co.uk>, Martin McEvoy writes > * The contributor's name SHOULD also be marked up as a valid hCard > Microformat. For the record; I do not regard the above as resolving (nor even addressing) the issue highlighted in the e-mail cited in the issue-log. > * If multiple contributors are specified, without |role| > specifications, it /MAY/ be assumed that the first role mentioned > is the primary artist or creator. This does not work for collaborations: Paul Simon & Art Garfunkel Robert Plant & Alison Krause and does not work in prose or tables like: Simon Rattle / Beethoven's Fifth >This applies to plain-text > contributor markup as well. Really? How will parsers handle: Paul Simon & Art Garfunkel Paul Simon and Art Garfunkel Paul Simon Art Garfunkel Paul Simon/ Art Garfunkel Paul Simon, Art Garfunkel Paul Simon und Art Garfunkel Paul Simon et Art Garfunkel and every other language (and character-set) variant; and how will they differentiate between: Paul Simon-Art Garfunkel and: John-Paul Jones [Other interested parties CCd] -- Andy Mabbett From martin at weborganics.co.uk Mon Aug 18 12:22:55 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 12:23:07 2008 Subject: [uf-new] hAudio Issue D1: 2008-01-10 Contributor. Resolution In-Reply-To: <48A9C511.8080606@digitalbazaar.com> References: <4896FE05.40105@weborganics.co.uk> <48A7EB4A.20709@weborganics.co.uk> <48A98DB7.9030505@weborganics.co.uk> <48A9C511.8080606@digitalbazaar.com> Message-ID: <48A9CC0F.5050707@weborganics.co.uk> I have Replied to Andys concerns prior to the posting of this email, I will fill in the gaps Manu Sporny wrote: > I am forwarding a message that Andy Mabbett sent to a couple of us > involved with hAudio development because it is a valid opposition to the > proposed resolution to hAudio issue D1. > > ------------------------------------------------------------------------ > > In message <48A98DB7.9030505@weborganics.co.uk>, Martin McEvoy > writes > >> * The contributor's name SHOULD also be marked up as a valid hCard >> Microformat. >> > > For the record; I do not regard the above as resolving (nor even > addressing) the issue highlighted in the e-mail cited in the issue-log. > > Andy Please STOP being Vague please say what you mean What exactly then IS your Issue >> * If multiple contributors are specified, without |role| >> specifications, it /MAY/ be assumed that the first role mentioned >> is the primary artist or creator. >> > > This does not work for collaborations: > > Paul Simon & Art Garfunkel > > Robert Plant & Alison Krause > > and does not work in prose or tables like: > > Simon Rattle / Beethoven's Fifth > I know it doesn't but would you mark up Multiple Contributors like this [....] Paul Simon & Art Garfunkel [....] .... I dont think most savy microformat publishers would either. > >> This applies to plain-text >> contributor markup as well. >> > > Really? How will parsers handle: > > Paul Simon & Art Garfunkel > > Paul Simon and Art Garfunkel > > Paul Simon > Art Garfunkel > > Paul Simon/ Art Garfunkel > > Paul Simon, Art Garfunkel > > Paul Simon und Art Garfunkel > > Paul Simon et Art Garfunkel > > and every other language (and character-set) variant; and how will they > differentiate between: > > Paul Simon-Art Garfunkel > > and: > > John-Paul Jones > It says Earlier in the proposed change The contributor's name SHOULD also be marked up as a valid hCard I think this is enough to suggest the propper format or hAudio Contributor > > [Other interested parties CCd] > > Why Didn't you CC Tantek and the rest of the microformats Community, What are you trying to achieve Andy? Thanks Martin McEvoy From msporny at digitalbazaar.com Mon Aug 18 12:49:05 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Aug 18 12:49:11 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files In-Reply-To: <48A9AE2C.1010604@digitalbazaar.com> References: <1652598821-1219079148-cardhu_decombobulator_blackberry.rim.net-1568821272-@bxe017.bisx.prod.on.blackberry> <48A9AE2C.1010604@digitalbazaar.com> Message-ID: <48A9D231.4000103@digitalbazaar.com> Andy Mabbett wrote: >>"By adding rel="enclosure" to a hyperlink, a page indicates that the >>destination of that hyperlink is intended to be downloaded and cached." > > I don't take issue with that definition; I simply don't believe that a > streaming audio feed, (say, one running 24/7, like BBC Radio 4's) can > ever be an "enclosure". > > Consider the usage "I have downloaded it and enclose it with this > e-mail". Your issue has to do with the semantics of the word "enclosure", which unfortunately means something a bit different in the English language as it does in the computing realm. It's a valid point - and I'm a bit torn as you could interpret it in different ways. Like you said, one could use it in the following sense: "I have downloaded it and enclose it with this e-mail", which would be a valid use of enclosure. It all depends on what you're "enclosing"... are you enclosing the actual file or a reference to the file. My interpretation is that rel-enclosure states that you're "enclosing a reference to a representation of what you are discussing". A better analogy would be: "I have enclosed a device that will let you listen to this radio station.", as well. Or... "I have enclosed a portal to let you listen to this audio stream". I do admit, however, that this concept will be lost on those that don't know much about knowledge representation... so perhaps there is a better word than rel-enclosure? >>My preference is to resolve that rel-enclosure is applicable to both >>static and streaming files and note the decision on the rel-enclosure >>wiki page. > > In which case "enclosure" is a misnomer. "Embedded" might be better. It's better, but you can't really embed or enclose something that has no end or temporal boundary, can you? (unless we get into the realm of 5+ multi-dimensional physics). rel="manifestation", rel="download" or rel="representation" are more accurate. rel="download" is basically what we decided to use for the Media RDFa vocabulary (which the Audio RDFa vocabulary is layered upon): http://purl.org/media So, that's an option if we'd like to keep both vocabularies in sync, or offer rel-download as an alternative to rel-enclosure. The down-side is that rel-enclosure already exists and we should re-use when possible. Thoughts from the community? -- manu From msporny at digitalbazaar.com Mon Aug 18 13:51:06 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Aug 18 13:51:14 2008 Subject: [uf-new] hAudio Issue D1: 2008-01-10 Contributor. Resolution In-Reply-To: <48A9CC0F.5050707@weborganics.co.uk> References: <4896FE05.40105@weborganics.co.uk> <48A7EB4A.20709@weborganics.co.uk> <48A98DB7.9030505@weborganics.co.uk> <48A9C511.8080606@digitalbazaar.com> <48A9CC0F.5050707@weborganics.co.uk> Message-ID: <48A9E0BA.8080107@digitalbazaar.com> Martin McEvoy wrote: >>> * If multiple contributors are specified, without |role| >>> specifications, it /MAY/ be assumed that the first role >>> mentioned >>> is the primary artist or creator. >> >> This does not work for collaborations: >> >> Paul Simon & Art Garfunkel >> >> Robert Plant & Alison Krause >> >> and does not work in prose or tables like: >> >> Simon Rattle / Beethoven's Fifth >> > I know it doesn't but would you mark up Multiple Contributors like > this > > > [....] > Paul Simon & class="contributor">Art Garfunkel > [....] > > > .... I dont think most savy microformat publishers would either. It seems that the issue that Andy has, Martin, is that if someone were to do that, the hAudio specification says that it's okay to assume that the first contributor is the primary artist. In this particular case, it would be wrong to do so because both Simon AND Garfunkel are each the primary artist. It might be best if we delete that entire bullet point. Would that resolve your issue, Andy? ***(Andy has replied off-list that this would address his issue)*** Proposal for resolving hAudio Issue D1: REMOVE: * If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator. That would leave it up to the application authors to make assumptions if they want to... we really shouldn't be making any assumptions in the specification that are not 100% positive. -- manu From martin at weborganics.co.uk Mon Aug 18 14:03:53 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Mon Aug 18 14:04:06 2008 Subject: [uf-new] hAudio Issue D1: 2008-01-10 Contributor. Resolution In-Reply-To: <48A9E0BA.8080107@digitalbazaar.com> References: <4896FE05.40105@weborganics.co.uk> <48A7EB4A.20709@weborganics.co.uk> <48A98DB7.9030505@weborganics.co.uk> <48A9C511.8080606@digitalbazaar.com> <48A9CC0F.5050707@weborganics.co.uk> <48A9E0BA.8080107@digitalbazaar.com> Message-ID: <48A9E3B9.8@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >>>> * If multiple contributors are specified, without |role| >>>> specifications, it /MAY/ be assumed that the first role >>>> mentioned >>>> is the primary artist or creator. >>>> >>> This does not work for collaborations: >>> >>> Paul Simon & Art Garfunkel >>> >>> Robert Plant & Alison Krause >>> >>> and does not work in prose or tables like: >>> >>> Simon Rattle / Beethoven's Fifth >>> >>> >> I know it doesn't but would you mark up Multiple Contributors like >> this >> >> >> [....] >> Paul Simon & > class="contributor">Art Garfunkel >> [....] >> >> >> .... I dont think most savy microformat publishers would either. >> > > It seems that the issue that Andy has, Martin, is that if someone were > to do that, the hAudio specification says that it's okay to assume that > the first contributor is the primary artist. In this particular case, it > would be wrong to do so because both Simon AND Garfunkel are each the > primary artist. > > It might be best if we delete that entire bullet point. Would that > resolve your issue, Andy? > > ***(Andy has replied off-list that this would address his issue)*** > > Proposal for resolving hAudio Issue D1: > > REMOVE: > > * If multiple contributors are specified, without |role| > specifications, it /MAY/ be assumed that the first role mentioned > is the primary artist or creator. > > That would leave it up to the application authors to make assumptions if > they want to... we really shouldn't be making any assumptions in the > specification that are not 100% positive. > > -- manu > +1 Martin McEvoy > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From martin at weborganics.co.uk Wed Aug 20 04:28:25 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 04:28:38 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files In-Reply-To: <48A9D231.4000103@digitalbazaar.com> References: <1652598821-1219079148-cardhu_decombobulator_blackberry.rim.net-1568821272-@bxe017.bisx.prod.on.blackberry> <48A9AE2C.1010604@digitalbazaar.com> <48A9D231.4000103@digitalbazaar.com> Message-ID: <48ABFFD9.7020804@weborganics.co.uk> Hello Manu Manu Sporny wrote: > Andy Mabbett wrote: > >>> "By adding rel="enclosure" to a hyperlink, a page indicates that the >>> destination of that hyperlink is intended to be downloaded and cached." >>> >> I don't take issue with that definition; I simply don't believe that a >> streaming audio feed, (say, one running 24/7, like BBC Radio 4's) can >> ever be an "enclosure". >> >> Consider the usage "I have downloaded it and enclose it with this >> e-mail". >> > > Your issue has to do with the semantics of the word "enclosure", which > unfortunately means something a bit different in the English language as > it does in the computing realm. > > It's a valid point - and I'm a bit torn as you could interpret it in > different ways. Like you said, one could use it in the following sense: > > "I have downloaded it and enclose it with this e-mail", which would be a > valid use of enclosure. > > It all depends on what you're "enclosing"... are you enclosing the > actual file or a reference to the file. My interpretation is that > rel-enclosure states that you're "enclosing a reference to a > representation of what you are discussing". > > A better analogy would be: > > "I have enclosed a device that will let you listen to this radio > station.", as well. > > Or... "I have enclosed a portal to let you listen to this audio stream". > > I do admit, however, that this concept will be lost on those that don't > know much about knowledge representation... so perhaps there is a better > word than rel-enclosure? > > >>> My preference is to resolve that rel-enclosure is applicable to both >>> static and streaming files and note the decision on the rel-enclosure >>> wiki page. >>> >> In which case "enclosure" is a misnomer. "Embedded" might be better. >> > > It's better, but you can't really embed or enclose something that has no > end or temporal boundary, can you? (unless we get into the realm of 5 > multi-dimensional physics). > > rel="manifestation", rel="download" or rel="representation" are more > accurate. > > rel="download" is basically what we decided to use for the Media RDFa > vocabulary (which the Audio RDFa vocabulary is layered upon): > > http://purl.org/media > > So, that's an option if we'd like to keep both vocabularies in sync, or > offer rel-download as an alternative to rel-enclosure. > > The down-side is that rel-enclosure already exists and we should re-use > when possible. > > Thoughts from the community? > > I think Andy's issue is the definition of rel-enclosure "By adding +AHw-rel="enclosure"+AHw- to a hyperlink, a page indicates that the destination of that hyperlink is intended to be downloaded and cached. " http://microformats.org/wiki/rel-enclosure+ACM-Abstract Certain kinds of audio can not be physically downloaded to your hard drive or cached anywhere, consider shout-cast streams and web radio stations, also audio that can only be accessed through flash players need to be considered, so rel="manifestation", rel="download" or rel="representation" still suggests that they are something that can be cached and saved elsewhere, rel ="stream" may be more accurate for marking up audio that can't be downloaded or cached but still playable. This theory still isn't conclusive, so I hit the audio-info examples page (again) for further analysis, what I was looking for is evidence of audio that is streamed to the user, without being downloaded and typically played in the browser by some form of player commonly a Flash Player the evidence was remarkable. Out of the 38 examples available on: http://microformats.org/wiki/audio-info-examples+ACM-Service+AF8-Publishing+AF8-of+AF8-Music 16 examples Do Have a stream 15 examples Do Not have a stream 7 examples are Unavailable I have made the study available on Line for viewing http://weborganics.co.uk/docs/Stream-Analysis.txt I would like to propose rel="stream" for these kinds of files. Best Wishes. Martin McEvoy > -- manu > > +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- > microformats-new mailing list > microformats-new+AEA-microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From mail at tobyinkster.co.uk Wed Aug 20 05:53:00 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 20 05:53:34 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files Message-ID: Martin McEvoy wrote: > I would like to propose rel="stream" for these kinds of files. +1 from me. This would also be useful for differentiating between download and streaming URLs in the case where both are available. -- Toby A Inkster From martin at weborganics.co.uk Wed Aug 20 06:41:06 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 06:41:24 2008 Subject: [uf-new] hAudio issue D5: 2008-01-10 there is no way of linking to an interim page Message-ID: <48AC1EF2.1010409@weborganics.co.uk> Hello All I initialy posted a resolution to this Issue in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001719.html because it seemed like the "easy answer" I now believe I was In error because I have found evidence that this is An Issue. I found this example on the audio info pages from http://audiofind.ru/music/album/-/Lost%20Angel/Destination/?id=591 Album cover
2001
Psychosomatic
Tracks: 12
This was the only the first example I looked at Im sure there are lots more, I will make a thorough study on this when I have more time. In the meantime the bit I am looking at is this [...]
Psychosomatic
References: <48AC1EF2.1010409@weborganics.co.uk> Message-ID: <48AC2A5F.5020008@digitalbazaar.com> Martin McEvoy wrote: > [...] >
href="/music/album/-/Lost%20Angel/Psychosomatic/?id=7961">Psychosomatic
> [...] > > The above is a link to another page where audio may be listened to or > downloaded. -1 to class="url" rel="bookmark" would be a more POSH way of marking up that relationship: http://www.w3.org/TR/REC-html40/types.html#type-links rel="help" is also an option - we should re-use pre-existing HTML LinkTypes where appropriate. However, I believe that there is also a problem with examples. Most of the hAudio examples deal with the final location of the hAudio data and rarely point elsewhere. We'd need more examples before adding this to hAudio (per the Microformats process). I'm not arguing that it's not useful, just arguing that we don't have enough examples to support adding that feature to hAudio right now. -- manu From tantek at cs.stanford.edu Wed Aug 20 08:07:32 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Aug 20 08:08:02 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow forlinks to streaming files In-Reply-To: References: Message-ID: <1575304313-1219244875-cardhu_decombobulator_blackberry.rim.net-327874547-@bxe017.bisx.prod.on.blackberry> Apologies for top posting (BB limitation). -1 to introducing a new value for rel-streaming. The manner in which this has been pursued is too much "semantic distinction theory" rather than practical and based on existing practice. >From my understanding of existing practice, when streaming media is posted to a blog post, it is also included in RSS in an enclosure element and/or in Atom feeds with a tag, and thus we should interoperate with existing practice rather than inventing a new value. Put another way, the burden of proof is on the need for a new value. No such evidence (arguments of the form "nice to have" or "would also be useful" or English dictionary references are not evidence - real world publishing practice is evidence) has been provided to justify a *new* value rather than use of the existing "enclosure" value. If you do find such evidence, document it on a wiki page like "streaming-examples". Toby wrote: >differentiating between download and streaming URLs in the case where both are available. That distinction is already made via different MIME types on the enclosure, reflected in the type attribute (on a or link tags). No need to invent something new. Tantek -----Original Message----- From: Toby A Inkster Date: Wed, 20 Aug 2008 13:53:00 To: Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for links to streaming files Martin McEvoy wrote: > I would like to propose rel="stream" for these kinds of files. +1 from me. This would also be useful for differentiating between download and streaming URLs in the case where both are available. -- Toby A Inkster _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From mail at tobyinkster.co.uk Wed Aug 20 08:18:41 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 20 08:27:04 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow forlinks to streaming files Message-ID: Tantek wrote: > Toby wrote: > differentiating between download and streaming URLs > > in the case where both are available. > > That distinction is already made via different MIME types on the > enclosure, reflected in the type attribute (on a or link tags). No > need to invent something new. I've written an hAudio -> M3U converter (M3U is a common playlist format supported by several media players including Winamp, XMMS and iTunes) and do indeed use the 'type' attribute to differentiate between playable downloads (e.g. MP3s, OGGs, etc) and downloads which are not directly playable (e.g. BitTorrent files, ZIP files, etc). This distinction needs to be made in order to avoid placing non- playable files into the playlist. However, the percentage of links that actually *include* a 'type' attribute is woefully small. Performing HTTP HEAD requests for each file would be too slow. One solution of course might be for hAudio to strongly encourage the 'type' attribute to be set on any rel=enclosure links. It would help if all the examples of the Wiki included the attribute, and a list of commonly used MIME types could be provided to help newcomers. (Some are not immediately obvious - e.g. application/ogg instead of audio/ ogg.) -- Toby A Inkster From tantek at cs.stanford.edu Wed Aug 20 08:39:38 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Aug 20 08:40:09 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allowforlinks to streaming files In-Reply-To: References: Message-ID: <1731997924-1219246801-cardhu_decombobulator_blackberry.rim.net-868035535-@bxe017.bisx.prod.on.blackberry> This is an excellent follow-up Toby - perhaps you can capture your implementation experience on the wiki on a page like "streaming-implementations". Toby wrote: >However, the percentage of links that actually *include* a 'type' attribute is woefully small. Performing HTTP HEAD requests for each file would be too slow. While I'm not claiming that you are using this as an argument for a new format/value, I will point out that similar forms of argument have been made in the past (and in other forums) for creating new things. The brief point to keep in mind: If existing content publishers are not making use of an *existing* format feature as they should, why would anyone think that such publishers would make any more use of a *new* format feature? And in a proactive way: rather than inventing a new feature for which there is already an existing feature (which may or may not be widely adopted), provide better documentation and how-tos (perhaps with benefits) for how to use that existing feature - as you have recommended in your email. Your solution is good. In addition, we may wish to consider making use of the "type" attribute on a rel="enclosure" links in hAudio a SHOULD to communicate the importance of doing so. Tantek -----Original Message----- From: Toby A Inkster Date: Wed, 20 Aug 2008 16:18:41 To: Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow forlinks to streaming files Tantek wrote: > Toby wrote: > differentiating between download and streaming URLs > > in the case where both are available. > > That distinction is already made via different MIME types on the > enclosure, reflected in the type attribute (on a or link tags). No > need to invent something new. I've written an hAudio -> M3U converter (M3U is a common playlist format supported by several media players including Winamp, XMMS and iTunes) and do indeed use the 'type' attribute to differentiate between playable downloads (e.g. MP3s, OGGs, etc) and downloads which are not directly playable (e.g. BitTorrent files, ZIP files, etc). This distinction needs to be made in order to avoid placing non- playable files into the playlist. However, the percentage of links that actually *include* a 'type' attribute is woefully small. Performing HTTP HEAD requests for each file would be too slow. One solution of course might be for hAudio to strongly encourage the 'type' attribute to be set on any rel=enclosure links. It would help if all the examples of the Wiki included the attribute, and a list of commonly used MIME types could be provided to help newcomers. (Some are not immediately obvious - e.g. application/ogg instead of audio/ ogg.) -- Toby A Inkster _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From martin at weborganics.co.uk Wed Aug 20 08:47:36 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 08:47:50 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow forlinks to streaming files In-Reply-To: <1575304313-1219244875-cardhu_decombobulator_blackberry.rim.net-327874547-@bxe017.bisx.prod.on.blackberry> References: <1575304313-1219244875-cardhu_decombobulator_blackberry.rim.net-327874547-@bxe017.bisx.prod.on.blackberry> Message-ID: <48AC3C98.6000505@weborganics.co.uk> Hello Tantek Tantek Celik wrote: > Apologies for top posting (BB limitation). > > -1 to introducing a new value for rel-streaming. > > The manner in which this has been pursued is too much "semantic distinction theory" rather than practical and based on existing practice. > > >From my understanding of existing practice, when streaming media is posted to a blog post, it is also included in RSS in an enclosure element and/or in Atom feeds with a tag, and thus we should interoperate with existing practice rather than inventing a new value. > > Put another way, the burden of proof is on the need for a new value. No such evidence (arguments of the form "nice to have" or "would also be useful" or English dictionary references are not evidence - real world publishing practice is evidence) has been provided to justify a *new* value rather than use of the existing "enclosure" value. If you do find such evidence, document it on a wiki page like "streaming-examples". > Agreed. It would seem unsafe of me to suggest a rel="stream" without providing evidence that this may be necessary so I made a study on the existence of "Streams" or audio that can be played typically in the users browser and not available to be downloaded and cached to the users hard drive. I found that over 50% our existing examples show evidence of streamed audio see: http://weborganics.co.uk/docs/Stream-Analysis.txt The trouble is this may be just a "semantic distinction theory" because in order that streams can be played some part of the audio must be first downloaded (even if its only a few kilobytes), either to the Browsers Cache, or to memory by the application that is playing it. I think that maybe what is best for the hAudio proposal is that that we add the Existence/or not of streams to work in progress http://microformats.org/wiki/haudio#Work_in_progress for any future versions of hAudio pending further examples. Best Wishes Martin McEvoy > Toby wrote: > >> differentiating between >> > download and streaming URLs in the case where both are available. > > That distinction is already made via different MIME types on the enclosure, reflected in the type attribute (on a or link tags). No need to invent something new. > > Tantek > > -----Original Message----- > From: Toby A Inkster > > Date: Wed, 20 Aug 2008 13:53:00 > To: > Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow for > links to streaming files > > > Martin McEvoy wrote: > > >> I would like to propose rel="stream" for these kinds of files. >> > > +1 from me. This would also be useful for differentiating between > download and streaming URLs in the case where both are available. > > From martin at weborganics.co.uk Wed Aug 20 09:03:11 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 09:03:24 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow forlinks to streaming files In-Reply-To: References: Message-ID: <48AC403F.5040408@weborganics.co.uk> Hello Toby Toby A Inkster wrote: > Tantek wrote: >> Toby wrote: > >> differentiating between download and streaming URLs >> > in the case where both are available. >> >> That distinction is already made via different MIME types on the >> enclosure, reflected in the type attribute (on a or link tags). No >> need to invent something new. > > I've written an hAudio -> M3U converter (M3U is a common playlist > format supported by several media players including Winamp, XMMS and > iTunes) and do indeed use the 'type' attribute to differentiate > between playable downloads (e.g. MP3s, OGGs, etc) and downloads which > are not directly playable (e.g. BitTorrent files, ZIP files, etc). > This distinction needs to be made in order to avoid placing > non-playable files into the playlist. > > However, the percentage of links that actually *include* a 'type' > attribute is woefully small. Performing HTTP HEAD requests for each > file would be too slow. > > One solution of course might be for hAudio to strongly encourage the > 'type' attribute to be set on any rel=enclosure links. It would help > if all the examples of the Wiki included the attribute, and a list of > commonly used MIME types could be provided to help newcomers. (Some > are not immediately obvious - e.g. application/ogg instead of audio/ogg.) > The haudio proposal does say "The type of the file /MAY/ be specified by using the |type| specifier for a URI." http://microformats.org/wiki/haudio#Full_Download_.28Enclosure.29 Maybe this can be changed to: "The type of the file SHOULD be specified by using the type specifier for a URI." Maybe may encorage more haudio publishers to use the type="" specifier, Its also good to note that once haudio eventually becomes more stable we can then start adding extra pages such as hAudio Parsing and hAudio Authoring. Thanks Martin Mcevoy From martin at weborganics.co.uk Wed Aug 20 09:05:20 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 09:05:33 2008 Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allowforlinks to streaming files In-Reply-To: <1731997924-1219246801-cardhu_decombobulator_blackberry.rim.net-868035535-@bxe017.bisx.prod.on.blackberry> References: <1731997924-1219246801-cardhu_decombobulator_blackberry.rim.net-868035535-@bxe017.bisx.prod.on.blackberry> Message-ID: <48AC40C0.4060700@weborganics.co.uk> Hello Tantek Celik wrote: > This is an excellent follow-up Toby - perhaps you can capture your implementation experience on the wiki on a page like "streaming-implementations". > > Toby wrote: > >> However, the percentage of links that actually *include* a 'type' >> > attribute is woefully small. Performing HTTP HEAD requests for each > file would be too slow. > > While I'm not claiming that you are using this as an argument for a new format/value, I will point out that similar forms of argument have been made in the past (and in other forums) for creating new things. > > The brief point to keep in mind: > If existing content publishers are not making use of an *existing* format feature as they should, why would anyone think that such publishers would make any more use of a *new* format feature? > > And in a proactive way: rather than inventing a new feature for which there is already an existing feature (which may or may not be widely adopted), provide better documentation and how-tos (perhaps with benefits) for how to use that existing feature - as you have recommended in your email. > > Your solution is good. In addition, we may wish to consider making use of the "type" attribute on a rel="enclosure" links in hAudio a SHOULD to communicate the importance of doing so. > Ahh I wish I had read this email before I sent My last one... +1 to "Your solution is good. In addition, we may wish to consider making use of the "type" attribute on a rel="enclosure" links in hAudio a SHOULD to communicate the importance of doing so." Thanks Martin McEvoy > Tantek > > > -----Original Message----- > From: Toby A Inkster > > Date: Wed, 20 Aug 2008 16:18:41 > To: > Subject: [uf-new] hAudio Issue D4: 2008-01-10 rel-enclosure does not allow > forlinks to streaming files > > > Tantek wrote: > >> Toby wrote: >> > > >> differentiating between download and streaming URLs >> >>> in the case where both are available. >>> >> That distinction is already made via different MIME types on the >> enclosure, reflected in the type attribute (on a or link tags). No >> need to invent something new. >> > > I've written an hAudio -> M3U converter (M3U is a common playlist > format supported by several media players including Winamp, XMMS and > iTunes) and do indeed use the 'type' attribute to differentiate > between playable downloads (e.g. MP3s, OGGs, etc) and downloads which > are not directly playable (e.g. BitTorrent files, ZIP files, etc). > This distinction needs to be made in order to avoid placing non- > playable files into the playlist. > > However, the percentage of links that actually *include* a 'type' > attribute is woefully small. Performing HTTP HEAD requests for each > file would be too slow. > > One solution of course might be for hAudio to strongly encourage the > 'type' attribute to be set on any rel=enclosure links. It would help > if all the examples of the Wiki included the attribute, and a list of > commonly used MIME types could be provided to help newcomers. (Some > are not immediately obvious - e.g. application/ogg instead of audio/ > ogg.) > > From mail at tobyinkster.co.uk Wed Aug 20 09:27:04 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 20 09:37:05 2008 Subject: [uf-new] rel=license scoping and hAudio Message-ID: For the purposes of illustration, say I'm writing an article entitled "Music in the Digital Age" discussing how the Internet has changed modern music. I may wish to write that: ... Nine Inch Nails released their recent album Ghosts I-IV under a Creative Commons license Now, an hAudio parser (of which there are few) will interpret this as meaning that the Nine Inch Nails' album is released under that licence. But a general rel=license parser (of which there are many, including Yahoo! (cc) Search, Google Usage Rights Search, and absolutely any RDFa parser) will interpret this as meaning that the whole page is available under that licence, which may not be the case. With rel-tag, the scoping issue is of less importance. If I want to tag, say, a particular hCard with a tag of "Tennis" because that person is a tennis player, it is not too unreasonable if the whole page is interpreted as being tagged "Tennis" - after all, the page does mention a tennis player, so does have an (albeit perhaps minor) topic of "Tennis". With rel-license scoping has potentially major legal ramifications. Essentially it means that any rel=license link found needs to be manually checked to determine exactly what the licence applies to. And if one needs to manually inspect a page to determine its licence, then rel=license is adding no value. -- Toby A Inkster From martin at weborganics.co.uk Wed Aug 20 11:19:23 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 11:19:36 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <48AC5A5B.4030107@weborganics.co.uk> References: <48AC5A5B.4030107@weborganics.co.uk> Message-ID: <48AC602B.5070008@weborganics.co.uk> Martin McEvoy wrote: > Hello Toby... > > Toby A Inkster wrote: >> For the purposes of illustration, say I'm writing an article entitled >> "Music in the Digital Age" discussing how the Internet has changed >> modern music. I may wish to write that: >> >> ... >> >> Nine Inch Nails >> released their recent album >> Ghosts I-IV under a >> > rel="license">Creative Commons license >> >> >> Now, an hAudio parser (of which there are few) will interpret this as >> meaning that the Nine Inch Nails' album is released under that licence. >> >> But a general rel=license parser (of which there are many, including >> Yahoo! (cc) Search, Google Usage Rights Search, and absolutely any >> RDFa parser) will interpret this as meaning that the whole page is >> available under that licence, which may not be the case. >> >> With rel-tag, the scoping issue is of less importance. If I want to >> tag, say, a particular hCard with a tag of "Tennis" because that >> person is a tennis player, it is not too unreasonable if the whole >> page is interpreted as being tagged "Tennis" - after all, the page >> does mention a tennis player, so does have an (albeit perhaps minor) >> topic of "Tennis". >> >> With rel-license scoping has potentially major legal ramifications. >> Essentially it means that any rel=license link found needs to be >> manually checked to determine exactly what the licence applies to. >> And if one needs to manually inspect a page to determine its licence, >> then rel=license is adding no value. >> > This is true, > > I would prefer to use rel="copyright" > > http://www.w3.org/TR/REC-html40/types.html#type-links > > because rel="licence" is primarily used for CC licences. > > But even so the problem still exists that the rel-copyright still only > applies to the entire document. > > So *maybe* there is need for something more specific that can be > related to the object maybe a rel="rights" or something else new..? No Im wrong hAudio *can* use rel="copyright" http://microformats.org/wiki/rel-faq#Are_rel_attributes_and_linktypes_in_general_just_document_to_document "Are "rel" attributes, and linktypes in general, just document to document? The vast majority of the rel values defined in HTML4 are from a document to a document. rel="stylesheet" is a bit of an exception, as it from an HTML document to a style sheet, which is more like a set of styling rules and instructions than a "document" in the classical sense. Two more notable exceptions are rel="copyright" and rel="bookmark" which describe the relationship from the current document to (potentially) only part of a document. " Proposal: change rel="licence" to rel="copyright" I would have proposed rev="copyright" but rev is depreciated in Microformats (which is a shame in this case because it looks like something hAudio needs) Thanks Martin McEvoy > > > Thanks > > Martin McEvoy From martin at weborganics.co.uk Wed Aug 20 10:54:35 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 11:22:39 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: References: Message-ID: <48AC5A5B.4030107@weborganics.co.uk> Hello Toby... Toby A Inkster wrote: > For the purposes of illustration, say I'm writing an article entitled > "Music in the Digital Age" discussing how the Internet has changed > modern music. I may wish to write that: > > ... > > Nine Inch Nails > released their recent album > Ghosts I-IV under a > rel="license">Creative Commons license > > > Now, an hAudio parser (of which there are few) will interpret this as > meaning that the Nine Inch Nails' album is released under that licence. > > But a general rel=license parser (of which there are many, including > Yahoo! (cc) Search, Google Usage Rights Search, and absolutely any > RDFa parser) will interpret this as meaning that the whole page is > available under that licence, which may not be the case. > > With rel-tag, the scoping issue is of less importance. If I want to > tag, say, a particular hCard with a tag of "Tennis" because that > person is a tennis player, it is not too unreasonable if the whole > page is interpreted as being tagged "Tennis" - after all, the page > does mention a tennis player, so does have an (albeit perhaps minor) > topic of "Tennis". > > With rel-license scoping has potentially major legal ramifications. > Essentially it means that any rel=license link found needs to be > manually checked to determine exactly what the licence applies to. And > if one needs to manually inspect a page to determine its licence, then > rel=license is adding no value. > This is true, I would prefer to use rel="copyright" http://www.w3.org/TR/REC-html40/types.html#type-links because rel="licence" is primarily used for CC licences. But even so the problem still exists that the rel-copyright still only applies to the entire document. So *maybe* there is need for something more specific that can be related to the object maybe a rel="rights" or something else new..? Thanks Martin McEvoy From msporny at digitalbazaar.com Wed Aug 20 11:44:11 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 20 11:44:16 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: References: Message-ID: <48AC65FB.2060705@digitalbazaar.com> Toby A Inkster wrote: > With rel-license scoping has potentially major legal ramifications. > Essentially it means that any rel=license link found needs to be > manually checked to determine exactly what the licence applies to. And > if one needs to manually inspect a page to determine its licence, then > rel=license is adding no value. This is a very good point, Toby. It is an argument against using rel="license" in the current version of hAudio since the semantics do not match up with what is intended. Namely: "By adding rel="license" to a hyperlink, a page indicates that the destination of that hyperlink is a license for the current page."[1] However, to give a counter-point, Creative Commons notes that rel="license" should be used to specify what music a particular work is licensed under: http://creativecommons.org/license/music Their approach has the musical work(s) described on a page as the only content on that page, so rel="license" makes a little more sense in their use case. This would also make sense in the hAudio case, but has a very high probability of abuse. The XHTML vocabulary also defines rel="license" as applying to the current document and not to resources in the document. http://www.w3.org/1999/xhtml/vocab#license Keep in mind that this is a non-issue in RDFa since you always have a subject, which is why it is supported in Audio RDFa[2]. If we do want to specify the license for Microformatted objects in the future, we should pick something else, like rel="hlicense" to specify the relationship between a Microformat object and it's license. However, hAudio does not have enough examples of specifying the license to warrant this addition to the Microformat. -- manu [1] http://microformats.org/wiki/rel-license#Abstract [2] http://purl.org/media/audio From tantek at cs.stanford.edu Wed Aug 20 11:51:32 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Aug 20 11:52:02 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <48AC65FB.2060705@digitalbazaar.com> References: <48AC65FB.2060705@digitalbazaar.com> Message-ID: <1846391923-1219258315-cardhu_decombobulator_blackberry.rim.net-1828496802-@bxe017.bisx.prod.on.blackberry> Manu, Martin, in brief, please do not propose/introduce/suggest new formats (hlicense, rel copyright etc) without at a minimum checking the wiki for work in progress regarding the limitations of rel-license. http://microformats.org/wiki/license Thanks, Tantek -----Original Message----- From: Manu Sporny Date: Wed, 20 Aug 2008 14:44:11 To: For discussion of new microformats. Subject: Re: [uf-new] rel=license scoping and hAudio Toby A Inkster wrote: > With rel-license scoping has potentially major legal ramifications. > Essentially it means that any rel=license link found needs to be > manually checked to determine exactly what the licence applies to. And > if one needs to manually inspect a page to determine its licence, then > rel=license is adding no value. This is a very good point, Toby. It is an argument against using rel="license" in the current version of hAudio since the semantics do not match up with what is intended. Namely: "By adding rel="license" to a hyperlink, a page indicates that the destination of that hyperlink is a license for the current page."[1] However, to give a counter-point, Creative Commons notes that rel="license" should be used to specify what music a particular work is licensed under: http://creativecommons.org/license/music Their approach has the musical work(s) described on a page as the only content on that page, so rel="license" makes a little more sense in their use case. This would also make sense in the hAudio case, but has a very high probability of abuse. The XHTML vocabulary also defines rel="license" as applying to the current document and not to resources in the document. http://www.w3.org/1999/xhtml/vocab#license Keep in mind that this is a non-issue in RDFa since you always have a subject, which is why it is supported in Audio RDFa[2]. If we do want to specify the license for Microformatted objects in the future, we should pick something else, like rel="hlicense" to specify the relationship between a Microformat object and it's license. However, hAudio does not have enough examples of specifying the license to warrant this addition to the Microformat. -- manu [1] http://microformats.org/wiki/rel-license#Abstract [2] http://purl.org/media/audio _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From mail at tobyinkster.co.uk Wed Aug 20 12:04:19 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 20 12:04:52 2008 Subject: [uf-new] rel=license scoping and hAudio Message-ID: <8ED76B99-667F-431B-9EE9-7E0C26C63FCE@tobyinkster.co.uk> > http://creativecommons.org/license/music > > Their approach has the musical work(s) described on a page as the only > content on that page, so rel="license" makes a little more sense in > their use case. This would also make sense in the hAudio case, but > has a > very high probability of abuse. This only works when the primary topic of the page is a single work under the given licence, or a collection of works all under the same licence. If there are works under different licences, or if the hAudio is only a small part of a the page (as in my "Music in the Digital Age" essay example), then it fails. > The XHTML vocabulary also defines rel="license" as applying to the > current document and not to resources in the document. > http://www.w3.org/1999/xhtml/vocab#license > Keep in mind that this is a non-issue in RDFa since you always have a > subject, which is why it is supported in Audio RDFa[2]. I'm referring more to pages written as non-RDFa hAudio which are then *parsed* as RDFa. Because then no explicit RDFa subject is likely to be given (using e.g. @typeof or @about), so any conforming RDFa implementation will take rel=license to apply to the entire page. -- Toby A Inkster From martin at weborganics.co.uk Wed Aug 20 12:22:12 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 12:22:29 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <48AC65FB.2060705@digitalbazaar.com> References: <48AC65FB.2060705@digitalbazaar.com> Message-ID: <48AC6EE4.2040604@weborganics.co.uk> Hello Manu Manu Sporny wrote: > Toby A Inkster wrote: > >> With rel-license scoping has potentially major legal ramifications. >> Essentially it means that any rel=license link found needs to be >> manually checked to determine exactly what the licence applies to. And >> if one needs to manually inspect a page to determine its licence, then >> rel=license is adding no value. >> > > This is a very good point, Toby. It is an argument against using > rel="license" in the current version of hAudio since the semantics do > not match up with what is intended. Namely: > > "By adding rel="license" to a hyperlink, a page indicates that the > destination of that hyperlink is a license for the current page."[1] > > However, to give a counter-point, Creative Commons notes that > rel="license" should be used to specify what music a particular work is > licensed under: > > http://creativecommons.org/license/music > > Their approach has the musical work(s) described on a page as the only > content on that page, so rel="license" makes a little more sense in > their use case. This would also make sense in the hAudio case, but has a > very high probability of abuse. > > The XHTML vocabulary also defines rel="license" as applying to the > current document and not to resources in the document. > > http://www.w3.org/1999/xhtml/vocab#license > > Keep in mind that this is a non-issue in RDFa since you always have a > subject, which is why it is supported in Audio RDFa[2]. > > If we do want to specify the license for Microformatted objects in the > future, we should pick something else, like rel="hlicense" to specify > the relationship between a Microformat object and it's license. > > However, hAudio does not have enough examples of specifying the license > to warrant this addition to the Microformat. > You are right Manu In fact only a handful of the audio-info-examples make any reference at all to a licence of any kind so for hAudio rel="licence" is out of scope for haudio at this time, but Its good to talk these things through. Is it safe to say that I can re-close issue "D6: 2008-01-10 hAudio notes inconsistency" [1] ? (if thats ok with everyone else that is?) [1] http://microformats.org/wiki/haudio-issues#D6:_2008-01-10_hAudio_notes_inconsistency Thanks Martin McEvoy > -- manu > > [1] http://microformats.org/wiki/rel-license#Abstract > [2] http://purl.org/media/audio > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From msporny at digitalbazaar.com Wed Aug 20 12:24:10 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 20 12:24:17 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <1846391923-1219258315-cardhu_decombobulator_blackberry.rim.net-1828496802-@bxe017.bisx.prod.on.blackberry> References: <48AC65FB.2060705@digitalbazaar.com> <1846391923-1219258315-cardhu_decombobulator_blackberry.rim.net-1828496802-@bxe017.bisx.prod.on.blackberry> Message-ID: <48AC6F5A.7090808@digitalbazaar.com> Tantek Celik wrote: >> Manu Sporny wrote: >> If we do want to specify the license for Microformatted objects in th >> future, we should pick something else, like rel="hlicense" to specify >> the relationship between a Microformat object and it's license. > > Manu, Martin, in brief, please do not propose/introduce/suggest new > formats (hlicense, rel copyright etc) without at a minimum checking > the wiki for work in progress regarding the limitations of > rel-license. Just to be clear, I wasn't attempting to propose/introduce/suggest a new format. I was attempting to state that we'd need "something else", something other than rel="license" if we are to address this issue for Microformats. I was also attempting to point out that this is a non-issue for hAudio at the present because there are not enough examples to warrant the need for stating the license of an hAudio object. The latter of the two statements should close hAudio Issue D6, we should not support rel="license" in hAudio: http://microformats.org/wiki/haudio-issues#D6:_2008-01-10_hAudio_notes_inconsistency -- manu From martin at weborganics.co.uk Wed Aug 20 12:54:09 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 12:54:23 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <48AC6F5A.7090808@digitalbazaar.com> References: <48AC65FB.2060705@digitalbazaar.com> <1846391923-1219258315-cardhu_decombobulator_blackberry.rim.net-1828496802-@bxe017.bisx.prod.on.blackberry> <48AC6F5A.7090808@digitalbazaar.com> Message-ID: <48AC7661.4020104@weborganics.co.uk> Manu Sporny wrote: > Just to be clear, I wasn't attempting to propose/introduce/suggest a new > format. I was attempting to state that we'd need "something else", > something other than rel="license" if we are to address this issue for > Microformats. Perhaps As Dr Ernie suggested in 2006[1] "Now that RFC 4946 [2] specifies rel-license for Atom, should we adopt that as a normative reference?" Its a Good thought it would almost eliminate the rel="licence" issue for good. [...] "2. The "license" Link Relation [2] The "license" link relation can be used to associate licenses with a feed or entry. Feed and entry elements MAY contain any number of "license" link relations but MUST NOT contain more than one with the same combination of href and type attribute values. The IRI specified by the link's href attribute SHOULD be dereferenceable to return a representation of the license. The license representation MAY be machine readable." [....] Just a thought :-) [1] http://microformats.org/wiki/rel-license-issues+ACM-Issues [2] http://www.faqs.org/rfcs/rfc4946.html Thanks Martin McEvoy From tantek at cs.stanford.edu Wed Aug 20 12:58:16 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Aug 20 12:58:46 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <48AC7661.4020104@weborganics.co.uk> References: <48AC65FB.2060705@digitalbazaar.com> <1846391923-1219258315-cardhu_decombobulator_blackberry.rim.net-1828496802-@bxe017.bisx.prod.on.blackberry><48AC6F5A.7090808@digitalbazaar.com><48AC7661.4020104@weborganics.co.uk> Message-ID: <2008574775-1219262319-cardhu_decombobulator_blackberry.rim.net-1502898398-@bxe017.bisx.prod.on.blackberry> rel-license predates Atom and thus the reference should go the other direction. That being said, iterations on rel-license and any work on new licensing formats should reference Atom license as an existing format and take its semantics into consideration. Tantek -----Original Message----- From: Martin McEvoy Date: Wed, 20 Aug 2008 20:54:09 To: For discussion of new microformats. Subject: Re: [uf-new] rel=license scoping and hAudio Manu Sporny wrote: > Just to be clear, I wasn't attempting to propose/introduce/suggest a new > format. I was attempting to state that we'd need "something else", > something other than rel="license" if we are to address this issue for > Microformats. Perhaps As Dr Ernie suggested in 2006[1] "Now that RFC 4946 [2] specifies rel-license for Atom, should we adopt that as a normative reference?" Its a Good thought it would almost eliminate the rel="licence" issue for good. [...] "2. The "license" Link Relation [2] The "license" link relation can be used to associate licenses with a feed or entry. Feed and entry elements MAY contain any number of "license" link relations but MUST NOT contain more than one with the same combination of href and type attribute values. The IRI specified by the link's href attribute SHOULD be dereferenceable to return a representation of the license. The license representation MAY be machine readable." [....] Just a thought :-) [1] http://microformats.org/wiki/rel-license-issues+ACM-Issues [2] http://www.faqs.org/rfcs/rfc4946.html Thanks Martin McEvoy _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new From msporny at digitalbazaar.com Wed Aug 20 13:06:18 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 20 13:06:23 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <48AC6EE4.2040604@weborganics.co.uk> References: <48AC65FB.2060705@digitalbazaar.com> <48AC6EE4.2040604@weborganics.co.uk> Message-ID: <48AC793A.5090401@digitalbazaar.com> Martin McEvoy wrote: > Is it safe to say that I can re-close issue "D6: 2008-01-10 hAudio > notes inconsistency" [1] ? (if thats ok with everyone else that is?) Yes, please do close Issue D6 - I think we're all in agreement and there's no way that we're going to add anything like rel="license" in this version of hAudio due to a lack of examples. -- manu From mail at tobyinkster.co.uk Wed Aug 20 13:14:42 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Aug 20 13:15:22 2008 Subject: [uf-new] rel=license scoping and hAudio Message-ID: > "Now that RFC 4946 [2] specifies rel-license for Atom, should we adopt > that as a normative reference?" > Its a Good thought it would almost eliminate the rel="licence" > issue for > good. I don't think this would necessarily help. RFC 4946 allows links to multiple licences, but the implication is not that the different licences apply to different parts of the article, but rather that the licences are each alternative licences for the entire article - which is pretty much the same situation that we already have. It also doesn't solve the practical problem of misinterpretation by RDFa parsers. -- Toby A Inkster From martin at weborganics.co.uk Wed Aug 20 14:32:03 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 14:32:17 2008 Subject: [uf-new] rel=license scoping and hAudio In-Reply-To: <48AC793A.5090401@digitalbazaar.com> References: <48AC65FB.2060705@digitalbazaar.com> <48AC6EE4.2040604@weborganics.co.uk> <48AC793A.5090401@digitalbazaar.com> Message-ID: <48AC8D53.6020602@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >> Is it safe to say that I can re-close issue "D6: 2008-01-10 hAudio >> notes inconsistency" [1] ? (if thats ok with everyone else that is?) >> > > Yes, please do close Issue D6 - I think we're all in agreement and > there's no way that we're going to add anything like rel="license" in > this version of hAudio due to a lack of examples. > Done see: http://microformats.org/wiki?title=haudio-issues&diff=0&oldid=28319#D6:_2008-01-10_hAudio_notes_inconsistency Thanks > -- manu > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From martin at weborganics.co.uk Wed Aug 20 14:35:44 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 14:35:59 2008 Subject: [uf-new] Closing hAudio issue: position Message-ID: <48AC8E30.3020402@weborganics.co.uk> Hello All I would like to close issue D3: 2008-01-10 Position. as it was resolved in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001707.html are there any objections to this decision? Thanks Martin McEvoy From msporny at digitalbazaar.com Wed Aug 20 15:04:57 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Aug 20 15:05:04 2008 Subject: [uf-new] Closing hAudio issue: position In-Reply-To: <48AC8E30.3020402@weborganics.co.uk> References: <48AC8E30.3020402@weborganics.co.uk> Message-ID: <48AC9509.2010707@digitalbazaar.com> Martin McEvoy wrote: > I would like to close issue D3: 2008-01-10 Position. > > as it was resolved in this email > http://microformats.org/discuss/mail/microformats-new/2008-August/001707.html > > are there any objections to this decision? Note that the wording on the final bullet point should be: * The sequential identifier MAY be specified out-of-sequence. ...and not what you have in the e-mail that you linked to. The two corrections are: 1. "Can" vs. "MAY" differentiation - the word "Can" doesn't have any specific meaning in specifications, whereas MAY does have a specific meaning.[1] 2. "Content" vs. "sequential identifier" - the /Content/ of the element is the /sequential identifier/. The /sequential identifier/ may be specified out-of-sequence. -- manu [1] http://www.ietf.org/rfc/rfc2119.txt From martin at weborganics.co.uk Wed Aug 20 15:08:39 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 15:08:52 2008 Subject: [uf-new] Closing hAudio issue: position In-Reply-To: <48AC9509.2010707@digitalbazaar.com> References: <48AC8E30.3020402@weborganics.co.uk> <48AC9509.2010707@digitalbazaar.com> Message-ID: <48AC95E7.90200@weborganics.co.uk> Manu Sporny wrote: > Martin McEvoy wrote: > >> I would like to close issue D3: 2008-01-10 Position. >> >> as it was resolved in this email >> http://microformats.org/discuss/mail/microformats-new/2008-August/001707.html >> >> are there any objections to this decision? >> > > Note that the wording on the final bullet point should be: > > * The sequential identifier MAY be specified out-of-sequence. > > ...and not what you have in the e-mail that you linked to. > Ahh my bad next email http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html sorry > The two corrections are: > > 1. "Can" vs. "MAY" differentiation - the word "Can" doesn't have any > specific meaning in specifications, whereas MAY does have a specific > meaning.[1] > 2. "Content" vs. "sequential identifier" - the /Content/ of the element > is the /sequential identifier/. The /sequential identifier/ may be > specified out-of-sequence. > > Agreed Thanks Martin McEvoy > -- manu > > [1] http://www.ietf.org/rfc/rfc2119.txt > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From martin at weborganics.co.uk Wed Aug 20 15:21:11 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Aug 20 15:21:23 2008 Subject: [uf-new] hAudio issue Contributor Message-ID: <48AC98D7.80109@weborganics.co.uk> Hello All I would like to close issue D1: 2008-01-10 Contributor [1] as a proposed resolution was made By Manu in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html are there any objections? [1] http://microformats.org/wiki/haudio-issues#D1:_2008-01-10__Contributor Thanks Martin McEvoy From paullee at google.com Wed Aug 20 22:19:41 2008 From: paullee at google.com (=?EUC-KR?B?UGF1bCBMZWUgKMDMseK89ik=?=) Date: Wed Aug 20 22:19:56 2008 Subject: [uf-new] hProduct progress (reply) Message-ID: Hi Jay, Just had two points to chime in on: 1. Reading over the page, sounds still a bit early to call it hProduct. =) 2. That said, I agree with you that there's a case for a separate format. The hListing proposal page makes it clear that it simply wasn't designed to address retail products, for instance: "We are focusing on providing "just enough" structure to enable matching, not to consummate transactions. This is distinct from the majority of formats described on the wiki under listing-examples, which are specific enough to completely describe products for retail sale according to the idiosyncratic semantics of particular merchants and shopping engines. Instead of encoding retail-oriented fields such as UPCs, SKUs, and manufacturer part numbers, this proposal acknowledges that many listings are for "inventories of one" that may not have such precise abstractions." A product microformat could help fill the gap for information like condition, brand, MPN, and unique product identifiers (UPC/EAN, ISBN). 3. Of course, that leads to the question: What about all the product subcategories? My sense from reading archives is that that might be part of the reason why discussion on product has died out - it's a pretty behemoth task to design for tens of highly diverse categories, with their own subcategories, many of which are still evolving. I think, however, there's a lot of value in focusing on the common ground across all products, and the value that that can add in and of itself, as well as as a foundation for future work on subcategories. Paul Google Product Search [uf-new] hProduct progress Jay Myers jmyers at visi.com Wed Aug 6 14:59:06 PDT 2008 All, There is work being done on new standards and reviving the hProduct microformat. During the course of this effort, people have pointed to hListing as a more viable, mature format for displaying product data. We proponents of hProduct feel that a separate hProduct uF would be more granular, and provide more specifics around the products, which often are more complex and have important attributes that are outside of the scope of hListing and others. Please see the updated brainstorming and draft proposal wiki pages for more information on the updated schema. Nonetheless, there are still correlations between hListing and hProduct that can't be ignored. It has been suggested that hProduct be used in conjuction with hListing to enhance the semantics of that format, where hProduct would live under .item. This I agree with, but I would still propose it also be used separately. I would appreciate any thoughts or ideas you might have around the revival effort of hProduct. Thanks, Jay