[uf-new] Unsubscribe
John Blazier
xblazox at gmail.com
Thu Jul 19 09:43:03 PDT 2007
UNSUBSCRIBE
John Blazier
834 Old Waterbury Road
Southbury, CT 06488
voice: 203-267-3328 fax: 203-267-3329
cell: 203-841-9399
xblazox at gmail.com
-----Original Message-----
From: microformats-new-bounces at microformats.org
[mailto:microformats-new-bounces at microformats.org] On Behalf Of
microformats-new-request at microformats.org
Sent: Thursday, July 19, 2007 10:14 AM
To: microformats-new at microformats.org
Subject: microformats-new Digest, Vol 6, Issue 12
Send microformats-new mailing list submissions to
microformats-new at microformats.org
To subscribe or unsubscribe via the World Wide Web, visit
http://microformats.org/mailman/listinfo/microformats-new
or, via email, send a message with subject or body 'help' to
microformats-new-request at microformats.org
You can reach the person managing the list at
microformats-new-owner at microformats.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of microformats-new digest..."
Today's Topics:
1. Re: microformat granularity: currency and measure (re-send)
(Guillaume Lebleu)
2. hMovie? (Patrick Aljord)
3. Re: hMedia? (Regine Heidorn)
4. Re: acessibility problem with currency microformats (Andy Mabbett)
5. Re: microformat granularity: currency and measure (Andy Mabbett)
6. Re: hMovie? (Manu Sporny)
7. Re: hMedia? (Manu Sporny)
8. Re: hMedia? (Brian Suda)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Jul 2007 16:53:55 -0700
From: Guillaume Lebleu <gl at brixlogic.com>
Subject: Re: [uf-new] microformat granularity: currency and measure
(re-send)
To: "For discussion of new microformats."
<microformats-new at microformats.org>
Message-ID: <469EA813.3030702 at brixlogic.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Andy Mabbett wrote:
> In the case of currency, I think we should polish and publish:
>
>
> <http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal>
I had came up with http://microformats.org/wiki/currency-proposal as a
cleaned up version of the straw man proposal. I believe the only
difference between the straw man proposal and this cleaned up version
was that I removed the date and the symbol class names.
The reason for the date removal was due to the lack of strong consensus
on the value of the "date" class name for two reasons:
* Occurrence of dated money amounts is judged rare: See
http://microformats.org/discuss/mail/microformats-discuss/2006-September/005
802.html
* Date is not a property of the money amount, but of a currency
rate: See
http://microformats.org/discuss/mail/microformats-discuss/2006-September/005
927.html
This lack of consensus was confirmed by the poll I had sent. See
results:
http://www.vizu.com/res/Business/Technology/microformats/currency/poll-resul
ts.html?n=15067&formBean=com.productengine.vizu.model.poll.PollNonvoters%401
aca8cc
"symbol" suffered the same lack of consensus, possibly due to a lack of
understanding of the benefits. Maybe a more detailed explanation of the
benefits of such a class name would be worth writing. If I understood
correctly, the main value would be for a user agent to be able to
replace it with the symbol of the currency that the amount is converted
to. If that's the case, I would argue that a user agent may not want to
replace the content, since it may fool the user into believing that
these amounts are guaranteed by the publisher/merchant, where in fact,
they would be mere estimates, which may differ from the actual rate
charged by the merchant or the financial intermediary.
Let me know if I missed something.
>
> In the case of measurement, we can use your examples:
>
> <http://microformats.org/wiki/measure-brainstorming#Guillaume_Lebleu>
>
> as a straw-man, but the chief unresolved issue is what to do about the
> plethora of non-SI units, and which we should include.
>
I think Bogdan and Emil came with some solutions using composition of SI
units and scaling, in line with some of the practices I had identified
(ex. XBRL). This could work for unusual units, when coded shortcurts for
common compositions (ex. square meters) are not available from standard
bodies such ISO or UNECE. Using standard codes for common compositions
of units and allowing custom compositions for unusual units should
hopefully be in line with a "simple things simple, complex things
possible" principle.
I suggest that I come up with a draft proposal based on the current
suggestions that we can start the discussion from.
Guillaume
------------------------------
Message: 2
Date: Thu, 19 Jul 2007 01:20:10 -0500
From: "Patrick Aljord" <patcito at gmail.com>
Subject: [uf-new] hMovie?
To: microformats-new at microformats.org
Message-ID:
<6b6419750707182320v78ad2a75ped5856d19918ec45 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hey all,
I'm doing a website to publish a list of movies with the same kind of
data imdb has:
Director, Writers, Release date (per country), genre, tagline, plot
outline, workers (those are people that work for the movie like
actors, costumes, executive producer, sound engineer etc), language,
sound-mix , country, duration, aspect-ratio...
I'm wondering if there is way to set all that as a microformat.
Do you think it's doable or is that too much information for a microformat?
see http://imdb.com/title/tt0373889/ as an example of data a movie can have.
Thanx in advance
Pat
------------------------------
Message: 3
Date: Thu, 19 Jul 2007 08:33:25 +0200
From: Regine Heidorn <regine at regine-heidorn.de>
Subject: Re: [uf-new] hMedia?
To: "For discussion of new microformats."
<microformats-new at microformats.org>
Message-ID: <FAA00344-43A5-4B8F-93C8-31CAD106ABF6 at regine-heidorn.de>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Just a short thought, maybe it doesn't make sense.
What about using hReview for all kind of media with a subcategory
hMedia and a specification of the media like audio, movie, website etc.?
I mean: hAudio anyway is related to hReview, which is logical. So why
not stretch this relation to hMedia, which can be specified into
audio, movie and other kinds of media. Information to be made about
author, publisher, director, producer, label, licence etc. are very
much similar, so one would only need to include some Extras for one
media or the other.
Hope I could express the idea properly ... ?
------------------------------
Message: 4
Date: Thu, 19 Jul 2007 08:15:58 +0100
From: Andy Mabbett <andy at pigsonthewing.org.uk>
Subject: Re: [uf-new] acessibility problem with currency microformats
To: "For discussion of new microformats."
<microformats-new at microformats.org>
Message-ID: <a9F8GpJu+wnGFwaf at pigsonthewing.org.uk>
Content-Type: text/plain;charset=us-ascii;format=flowed
In message
<8608a69a0707181538n76c82166ub5e39e835e6c4c2e at mail.gmail.com>, Alexandre
Van de Sande <alexandrevandesande at gmail.com> writes
>it looks like again the currency is using a already documented acessibility
>problem of abusing the abbr tag.
>
>this costs <div class="money">
> <abbr class="currency" title="USD">
> <span class="amount">42.67</span>
> </abbr>
> </div>
Hence my comment that the straw-man, which re-dates discussion of the
accessibility issue, needs to be "polished".
--
Andy Mabbett
------------------------------
Message: 5
Date: Thu, 19 Jul 2007 08:23:01 +0100
From: Andy Mabbett <andy at pigsonthewing.org.uk>
Subject: Re: [uf-new] microformat granularity: currency and measure
To: "For discussion of new microformats."
<microformats-new at microformats.org>
Message-ID: <JM7oqKLVFxnGFwqR at pigsonthewing.org.uk>
Content-Type: text/plain;charset=us-ascii;format=flowed
In message <469E8812.7090003 at brixlogic.com>, Guillaume Lebleu
<gl at brixlogic.com> writes
>Andy Mabbett wrote:
>> In the case of currency, I think we should polish and publish:
>>
>>
>><http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal>
>I had came up with http://microformats.org/wiki/currency-proposal as a
>cleaned up version of the straw man proposal. I believe the only
>difference between the straw man proposal and this cleaned up version
>was that I removed the date and the symbol class names.
>
>The reason for the date removal was due to the lack of strong consensus
>on the value of the "date" class name for two reasons:
>
> * Occurrence of dated money amounts is judged rare: See
>
>http://microformats.org/discuss/mail/microformats-discuss/2006-September
>/005802.html
...for some value of "rare". I have provided evidence of widespread use
f historical monetary values. "Five dollars" today does not have the
same value as "five dollars" did a hundred, or even twenty, years ago.
> * Date is not a property of the money amount, but of a currency
> rate: See
>
>http://microformats.org/discuss/mail/microformats-discuss/2006-September
>/005927.html
I don't follow your reasoning there, at all.
>This lack of consensus was confirmed by the poll I had sent. See
>results:
>http://www.vizu.com/res/Business/Technology/microformats/currency/poll-r
>esults.html?n=15067&formBean=com.productengine.vizu.model.poll.PollNonvo
>ters%401aca8cc
I don't believe that that poll has any value; not least because only
nine people participated.
>"symbol" suffered the same lack of consensus, possibly due to a lack of
>understanding of the benefits. Maybe a more detailed explanation of the
>benefits of such a class name would be worth writing. If I understood
>correctly, the main value would be for a user agent to be able to
>replace it with the symbol of the currency that the amount is converted
>to. If that's the case, I would argue that a user agent may not want to
>replace the content, since it may fool the user into believing that
>these amounts are guaranteed by the publisher/merchant, where in fact,
>they would be mere estimates, which may differ from the actual rate
>charged by the merchant or the financial intermediary.
That's hypothetical argument backed with no evidence.
>> In the case of measurement, we can use your examples:
>>
>> <http://microformats.org/wiki/measure-brainstorming#Guillaume_Lebleu>
>>
>> as a straw-man, but the chief unresolved issue is what to do about
>>the plethora of non-SI units, and which we should include.
>>
>I think Bogdan and Emil came with some solutions using composition of
>SI units and scaling, in line with some of the practices I had
>identified (ex. XBRL). This could work for unusual units, when coded
>shortcurts for common compositions (ex. square meters) are not
>available from standard bodies such ISO or UNECE. Using standard codes
>for common compositions of units and allowing custom compositions for
>unusual units should hopefully be in line with a "simple things simple,
>complex things possible" principle.
I don't see what you're saying here - please clarify.
>I suggest that I come up with a draft proposal based on the current
>suggestions that we can start the discussion from.
Sure.
Please excuse my brevity - I'm late leaving home.
--
Andy Mabbett
------------------------------
Message: 6
Date: Thu, 19 Jul 2007 09:13:31 -0400
From: Manu Sporny <msporny at digitalbazaar.com>
Subject: Re: [uf-new] hMovie?
To: "For discussion of new microformats."
<microformats-new at microformats.org>
Message-ID: <469F637B.6070702 at digitalbazaar.com>
Content-Type: text/plain; charset=ISO-8859-1
Patrick Aljord wrote:
> I'm doing a website to publish a list of movies with the same kind of
> data imdb has:
> Director, Writers, Release date (per country), genre, tagline, plot
> outline, workers (those are people that work for the movie like
> actors, costumes, executive producer, sound engineer etc), language,
> sound-mix , country, duration, aspect-ratio...
> I'm wondering if there is way to set all that as a microformat.
>
> Do you think it's doable or is that too much information for a
microformat?
It is do-able and is on the slate of things to get done. We just
finished up the hAudio draft about a month ago. We are going to be
moving forward with hAlbum and hVideo afterwards.
It will take around 3 months to collect enough examples, analyze those
examples and publish a draft for hVideo. hVideo is part of a bigger
initiative called media-info, whose goal is to be able to mark up media
information much like what you listed for video.
In short - yes, the community is definitely interested in getting a
video Microformat completed. It will take around 3 months to complete.
At the moment, nobody is working on it due to the focus on completing
hAudio.
Would you be willing to collect sample URLs for video? If so, that would
move that project forward.
-- manu
------------------------------
Message: 7
Date: Thu, 19 Jul 2007 09:26:06 -0400
From: Manu Sporny <msporny at digitalbazaar.com>
Subject: Re: [uf-new] hMedia?
To: "For discussion of new microformats."
<microformats-new at microformats.org>
Message-ID: <469F666E.8040404 at digitalbazaar.com>
Content-Type: text/plain; charset=ISO-8859-1
Regine Heidorn wrote:
> Just a short thought, maybe it doesn't make sense.
> What about using hReview for all kind of media with a subcategory hMedia
> and a specification of the media like audio, movie, website etc.?
>
> I mean: hAudio anyway is related to hReview, which is logical. So why
> not stretch this relation to hMedia, which can be specified into audio,
> movie and other kinds of media. Information to be made about author,
> publisher, director, producer, label, licence etc. are very much
> similar, so one would only need to include some Extras for one media or
> the other.
The goal with hAudio, hImage and hVideo (hMedia in general) has been to
embed them in other Microformats such as hAtom, hReview, and hProduct.
As far as hReview is concerned, the current approach is to embed the
information in the hReview DESCRIPTION field.
Thus, if you are doing a review about an album, you would include the
hAudio markup of the album in the DESCRIPTION field of the hReview.
Does that address your concern?
-- manu
------------------------------
Message: 8
Date: Thu, 19 Jul 2007 14:13:26 +0000
From: "Brian Suda" <brian.suda at gmail.com>
Subject: Re: [uf-new] hMedia?
To: "For discussion of new microformats."
<microformats-new at microformats.org>
Message-ID:
<21e770780707190713j6a9da0ffw69297f252d62f1ca at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 7/19/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> Regine Heidorn wrote:
> > Just a short thought, maybe it doesn't make sense.
> > What about using hReview for all kind of media with a subcategory hMedia
> > and a specification of the media like audio, movie, website etc.?
--- this is correct, you can do this already. Please have a look at
the Product Review example on the wiki:
http://microformats.org/wiki/hreview#Product_review
it is reviewing a CD. hReview probably covers alot of ground very
simply. A media format is an attempt at adding additional meta
information about the object above and beyond the basic data that is
already encoded by hReview.
hReview has "item type"
item type:: This optional field "type" provides the type of the item
being reviewed, one of the following: product, business, event,
person, place, website, url. If omitted, then in some cases the item
type may be inferred. If the item is also an hCard, then the item type
is a "business" or a "person" based upon which of those the hCard
represents. If the item is also an hCalendar event, then the item type
is an "event".
at the moment it is an emunerated list of values, sometime the
simplest solution might be to extend that list to help suit your needs
rather than duplicate all the work in a new format.
> As far as hReview is concerned, the current approach is to embed the
> information in the hReview DESCRIPTION field.
--- alternatively you do NOT have to re-encode the data in the
description field, the hReview itself can be about the object, as is
demonstated in the examples on the wiki.
> Thus, if you are doing a review about an album, you would include the
> hAudio markup of the album in the DESCRIPTION field of the hReview.
--- this is not the only place to encode the data. For instance, the
existing example on the wiki makes use of the whole hReview.
Therefore, you would not have to repeat certain data, such as the URL,
PHOTO, FN again in the description, the same values could and SHOULD
be reused.
I would start as simple as possible in attempting to mark-up your
data. See how far hReview gets you, then document the short-coming and
then we can see if some of those short-comings are commonly published
and look at working them into a more robust Media format.
I hope that helps,
-brian
--
brian suda
http://suda.co.uk
------------------------------
_______________________________________________
microformats-new mailing list
microformats-new at microformats.org
http://microformats.org/mailman/listinfo/microformats-new
End of microformats-new Digest, Vol 6, Issue 12
***********************************************
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 7/18/2007
3:30 PM
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 7/18/2007
3:30 PM
More information about the microformats-new
mailing list