From kmarks at technorati.com  Thu Dec  1 03:11:57 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Thu Dec  1 03:12:04 2005
Subject: Never underestimate the usefulness of human-readable data. (was
	Re: [uf-discuss] Non-HTTP/HTML microformats)
In-Reply-To: <BFB3E2AC.64547%tantek@cs.stanford.edu>
References: <BFB3E2AC.64547%tantek@cs.stanford.edu>
Message-ID: <552856f29575eb3b7bc6020f0ac77d50@technorati.com>


On Nov 30, 2005, at 11:14 PM, Tantek ?elik wrote:

> On 11/30/05 4:55 PM, "Ryan King" <ryan@technorati.com> wrote:
>> Never underestimate the usefulness of human-readable data.
>
> Ryan, this is an excellent point, and I feel like something that needs 
> to be
> added to that other blog-post-in-progress based on the last discussion 
> of
> "The tools will save us" (NOT!) that we had on the list.
>
> There is SO MUCH evidence (like the examples you just gave) for the
> usefulness of making data formats be human-readable that it really 
> makes you
> wonder why so many otherwise intelligent people keep wanting to do
> otherwise.

Well, there is a second distinction here. XML folks would argue that 
their data is human readable too, and describing the Box Model Hack as 
human-readable only works for a sufficiently narrow definition of 
human.

However the key point with using HTML for the microformats, is that 
everyone has a viewer for the data, so they don't need to parse it by 
eye, as it were.

From danny.ayers at gmail.com  Thu Dec  1 04:06:45 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Thu Dec  1 04:06:48 2005
Subject: [uf-discuss] Subscription lists in XOXO
Message-ID: <1f2ed5cd0512010406g11e2dc92l260cb0dda5542e88@mail.gmail.com>

Big apologies if I missed it, but I was wondering if there was already
a preferred way of expressing aggregator subscription lists in XHTML.
I found an example for simple link lists, but am not sure about the
best way of expressing what in OPML would look like:

<outline text="A Blog"
            type="rss"
            htmlUrl="http://example.org/page.html"
            xmlUrl="http://example.org/feed.xml"/>

I had a fiddle at [1], my crack at the bit in question looking like this:

<ul>A Blog
   <li>
       <a href="http://example.org/page.html">homepage</a>
   </li>
   <li>
       <a href="http://example.org/feed.rss" type="application/xml">feed</a>
   </li>
</ul>

Les Orchard's had a fiddle at [2], his version:

<li class="rss">
    <a class="xmlUrl" type="application/xml"
href="http://example.org/feed.rss">XML</a>
    <a class="htmlUrl" href="http://example.org/page.html" title="A
Blog">A Blog</a>
</li>

I think Les has it much closer to what's needed, the use of class
seems wise. But is this a list of URIs? Definitions? I dunno. Another
question would be how to extend this, if for example there was a
description of the feed available too (check Les' OPML source -
there's description and a few more attributes in there).

When it comes to parsing the stuff, it would be nice to have a common
convention ;-)

Cheers,
Danny.

[1] http://dannyayers.com/archives/2005/11/30/going-to-the-hub/#subs
[2] http://decafbad.com/blog/2005/12/01/feedrolls-in-xoxo-from-opml-via-xslt-and-url-line-magic

--

http://dannyayers.com
From luke.arno at gmail.com  Thu Dec  1 06:24:19 2005
From: luke.arno at gmail.com (Luke Arno)
Date: Thu Dec  1 06:24:22 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>
References: <43843033.4080802@blogmatrix.com>
	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>
Message-ID: <d79e89ce0512010624l2fc59d94ob3247726e3a7bfa2@mail.gmail.com>

On 12/1/05, Ryan King <ryan@technorati.com> wrote:
> On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote:

[ snip ]

> 4. Why do we prefer <h#> over class="title" for entry titles?
>

A preference one way or the other does make
the XSLT make sense.

[ snip ]

> 8. Open item for the list:
>
> > if there is no Entry Updated and Entry Published elements,
> > transformation to Atom is problematic
> > This is because a published element is required. Suggestions would
> > be appreciated here.
>

Actually it is updated that is required. Published is not.

   o  atom:feed elements MUST contain exactly one atom:updated element.
   o  atom:entry elements MUST contain exactly one atom:updated element.
   o  atom:entry elements MUST NOT contain more than one atom:published
      element.

- Luke
From manuel.gonzalez.noriega at gmail.com  Thu Dec  1 07:51:27 2005
From: manuel.gonzalez.noriega at gmail.com (=?ISO-8859-1?Q?Manuel_Gonz=E1lez_Noriega?=)
Date: Thu Dec  1 07:51:30 2005
Subject: [uf-discuss] The need for a Trackback microformat?
Message-ID: <d572750a0512010751k7d22c889k@mail.gmail.com>

Hi all, excuse me if this particular base is already covered.

do you see the need for a microformat that would easily expose the
trackbacks received by a given resource?

For example, I could parse a blog post, discover who's trackbacking
and do it all over again recursively, discovering 'chains' of related
posts.



--
Manuel
a veces :) a veces :(
pero siempre trabajando duro para Simplel?gica: apariencia,
experiencia y comunicaci?n en la web.
http://simplelogica.net # (+34) 985 22 12 65

?Ah! y escribiendo en Logicola: http://logicola.simplelogica.net
From luke at madstop.com  Thu Dec  1 08:15:37 2005
From: luke at madstop.com (Luke Kanies)
Date: Thu Dec  1 08:15:41 2005
Subject: Never underestimate the usefulness of human-readable data. (was
	Re: [uf-discuss] Non-HTTP/HTML microformats)
In-Reply-To: <BFB3E2AC.64547%tantek@cs.stanford.edu>
References: <BFB3E2AC.64547%tantek@cs.stanford.edu>
Message-ID: <Pine.LNX.4.58.0512011013490.15628@culain.madstop.com>

On Wed, 30 Nov 2005, Tantek ?elik wrote:

> Perhaps it is time we started separate pages for each of the microformats
> principles on the wiki, and provided deeper explanations and examples for
> each.

I think this is a great idea, and I would take it a step further by pointing
out how each principle have affected the overall design or the design of
individual formats.  The "principle" section of the page is relatively vague
right now, in that it's not necessarily obvious how to apply each of them or
how they were already applied.

-- 
I think that all good, right thinking people in this country are sick
and tired of being told that all good, right thinking people in this
country are fed up with being told that all good, right thinking people
in this country are fed up with being sick and tired.  I'm certainly
not, and I'm sick and tired of being told that I am.
                -- Monty Python
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

From luke at madstop.com  Thu Dec  1 08:24:05 2005
From: luke at madstop.com (Luke Kanies)
Date: Thu Dec  1 08:24:05 2005
Subject: [uf-discuss] Non-HTTP/HTML microformats
In-Reply-To: <e70a84d1c2cbe37294c5a5eed91fc2b3@technorati.com>
References: <Pine.LNX.4.58.0511301605500.15628@culain.madstop.com>
	<86706795-9105-4F2D-91A8-D0235550F8D5@technorati.com>
	<Pine.LNX.4.58.0511301654250.15628@culain.madstop.com>
	<e70a84d1c2cbe37294c5a5eed91fc2b3@technorati.com>
Message-ID: <Pine.LNX.4.58.0512011019420.15628@culain.madstop.com>

On Wed, 30 Nov 2005, Kevin Marks wrote:

> Do have a look at the discussions on serialiasation and XOXO over REST
> we've had here.

Okay.

> I use XOXO for internal interprocess communication, because it gives me
> an unambiguous serialisation of native list and dictionary structures
> which I can move between languages, and view in a browser for debugging
> or intermediate visualisation
>
> http://microformats.org/wiki/xoxo

That's certainly an interesting idea -- cross-language serialization.  I'm
currently just using Ruby's Marshalling for all IPC, but I'm hoping to
convert to something akin to microformats for most or all of it.  So it
seems that XOXO could be used for those cases that I can't reduce to
microformats.

> Also the discussion Erniw started about flagging types for
> serialization:
>
> http://www.opendarwin.org/~drernie/C395201355/E20051003175427/index.html

So this would be useful to explain to other people how to convert from what
they have to something that communicates over XOXO with what I'm doing,
then.

-- 
    SCSI is *not* magic. There are fundamental technical reasons
    why it is necessary to sacrifice a young goat to your SCSI chain
    now and then.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

From luke at madstop.com  Thu Dec  1 08:39:13 2005
From: luke at madstop.com (Luke Kanies)
Date: Thu Dec  1 08:39:16 2005
Subject: [uf-discuss] Non-HTTP/HTML microformats
In-Reply-To: <3DC15FFB-F146-424C-843D-E7779D4A0555@opendarwin.org>
References: <Pine.LNX.4.58.0511301605500.15628@culain.madstop.com>
	<86706795-9105-4F2D-91A8-D0235550F8D5@technorati.com>
	<Pine.LNX.4.58.0511301654250.15628@culain.madstop.com>
	<e70a84d1c2cbe37294c5a5eed91fc2b3@technorati.com>
	<3DC15FFB-F146-424C-843D-E7779D4A0555@opendarwin.org>
Message-ID: <Pine.LNX.4.58.0512011024170.15628@culain.madstop.com>

On Wed, 30 Nov 2005, Dr. Ernie Prabhakar wrote:

> As Kevin said, this does sound very similar to what we're discussing
> over on microformats REST:
>
> http://microformats.org/wiki/rest/

Ah, thanks for the link.

> I apologize for jumping into this thread late, but I'm curious
> whether you *can't* use HTML, or just weren't planning to because you
> didn't have a web browser in the loop. If the latter, I would
> definitely encourage you to consider the XOXO option.   I actually
> think it would be straightforward to implement "REX" (REST-Enabled
> XHTML) on other transports, in which case it would be germaine on the
> microformats-rest list.

I think at this point I'm too ignorant to be making any kind of decisions.

Yeah, the reason that I wasn't planning on using HTML is because there
aren't any web browsers in the loop anywhere.  I can use whatever I want
because, well, I'm making it all up as I go.  At this point I'm still
collecting information, but the only thing pushing me towards anything like
HTML is the uf use of it.  I've got a colleague who distinctly dislikes the
HTMLy nature of uf and is so far pretty fond of RDF, but that's about all I
have so far.

I'm currently doing all communication over XMLRPC, but I'm sure it could
just as easily be REST, XMLRPC is just the first thing I got working
acceptably well.  One of my other limitations is that I'm writing a tool
that's responsible for managing systems from the most minimal installs, so
I'm doing everything I can to stick to libraries that ship with Ruby to
limit the list of prereqs that my users need in order to start managing
their systems.

-- 
I am a kind of paranoiac in reverse. I suspect people of plotting
to make me happy.                     --J. D. Salinger
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

From luke at madstop.com  Thu Dec  1 08:42:56 2005
From: luke at madstop.com (Luke Kanies)
Date: Thu Dec  1 08:42:58 2005
Subject: [uf-discuss] Non-HTTP/HTML microformats
In-Reply-To: <5934AE80-408F-4E87-9540-4A3F41962E82@technorati.com>
References: <Pine.LNX.4.58.0511301605500.15628@culain.madstop.com>
	<86706795-9105-4F2D-91A8-D0235550F8D5@technorati.com>
	<939B1F7B-8B86-4385-802A-0F105D6D8EEB@randomchaos.com>
	<5934AE80-408F-4E87-9540-4A3F41962E82@technorati.com>
Message-ID: <Pine.LNX.4.58.0512011039310.15628@culain.madstop.com>

On Wed, 30 Nov 2005, Ryan King wrote:

> On Nov 30, 2005, at 3:22 PM, Scott Reynen wrote:
>
> > In addition to removing repetition, using a more human-readable
> > format for machine-only communication greatly simplifies
> > debugging.  That's why JavaScript is far more popular than assembly
> > language.
>
> And developing in general. For example, I write lots of shell scripts
> that end up looking something like:
>
> cat *.log | cut -f2 | grep foo | perl -e "while(<>){print doSomething
> ($_);}" | sort | uniq -c

Just so you know, you can use 'perl -pi -e "print doSomething"' here
instead:

    perl -p -e "s/:/;/g" /etc/passwd

The '-p' gets rid of the need for the "while" loop.

> Of course, to create that, I do it one step at a time and inspect the
> output (often using head or tail instead of cat).
>
> Never underestimate the usefulness of human-readable data.

While that's a great principle, it merely reduces the number of potential
formats from something resembling infinity to a smaller infinite number, so
I'm not sure how much that helps here.

I definitely am not planning on relying on any non-human-readable formats,
but I do think the computer-computer nature of the work I'm doing does
affect other aspects of the formats I'll be using.

-- 
He played the king as if afraid someone else would play the ace.
--John Mason Brown
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

From chris.messina at gmail.com  Thu Dec  1 09:38:34 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Thu Dec  1 09:38:38 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <d572750a0512010751k7d22c889k@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
Message-ID: <1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>

Hmm. Sounds like a case for <blockquote cite="%url%"> or <cite>....

However, it would be interesting to do something like <a href="%url%"
rel="trackback">xyz</a>...

I didn't realize that the <cite> tag is basically worthless when it
comes to inline citations to an external source... does this mean that
one should always use blockquote and just style it to be inline?

FYI, when you drop content into the Flock editor from another webpage,
we properly add the <blockquote> tag with a citation to the original
URL. If you parsed a page with such markup, you could theoretically
infer trackback, n'est-ce pas?

Chris

On 12/1/05, Manuel Gonz?lez Noriega <manuel.gonzalez.noriega@gmail.com> wrote:
> Hi all, excuse me if this particular base is already covered.
>
> do you see the need for a microformat that would easily expose the
> trackbacks received by a given resource?
>
> For example, I could parse a blog post, discover who's trackbacking
> and do it all over again recursively, discovering 'chains' of related
> posts.
>
>
>
> --
> Manuel
> a veces :) a veces :(
> pero siempre trabajando duro para Simplel?gica: apariencia,
> experiencia y comunicaci?n en la web.
> http://simplelogica.net # (+34) 985 22 12 65
>
> ?Ah! y escribiendo en Logicola: http://logicola.simplelogica.net
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
From solitude at solitude.dk  Thu Dec  1 09:45:26 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Thu Dec  1 09:45:36 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
Message-ID: <op.s038x0hjares2h@mail.solitude.dk>

On Thu, 01 Dec 2005 18:38:34 +0100, Chris Messina  
<chris.messina@gmail.com> wrote:

> Hmm. Sounds like a case for <blockquote cite="%url%"> or <cite>....

I'm using rel="cite" for references (with a profile) rather the <cite><a>  
compound. This is so I can use rev="cite" for a list of trackbacks  
recieved.

> However, it would be interesting to do something like <a href="%url%"
> rel="trackback">xyz</a>...

rel="trackback" is being used in the wild to designate a trackback url for  
a document, not for a list of trackbacks recieved.

> I didn't realize that the <cite> tag is basically worthless when it
> comes to inline citations to an external source... does this mean that
> one should always use blockquote and just style it to be inline?

Use <q> for inline quotes?

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From tantek at cs.stanford.edu  Thu Dec  1 11:38:07 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  1 11:38:24 2005
Subject: [uf-discuss] Subscription lists in XOXO
In-Reply-To: <1f2ed5cd0512010406g11e2dc92l260cb0dda5542e88@mail.gmail.com>
Message-ID: <BFB490CA.645D2%tantek@cs.stanford.edu>

On 12/1/05 4:06 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> Big apologies if I missed it, but I was wondering if there was already
> a preferred way of expressing aggregator subscription lists in XHTML.

The only current prior art/attempt at this is Attention.xml, which was
design without the benefit of the microformats process, and although does
reuse XOXO, VoteLinks, and XFN, could use a bit analysis / improvements to
make it a proper microformat (and I'm saying that as one of the
authors/editors).

 http://developers.technorati.com/wiki/attentionxml


> I found an example for simple link lists, but am not sure about the
> best way of expressing what in OPML would look like:
> 
> <outline text="A Blog"
>           type="rss"
>           htmlUrl="http://example.org/page.html"
>           xmlUrl="http://example.org/feed.xml"/>
> 
> I had a fiddle at [1], my crack at the bit in question looking like this:
> 
> <ul>A Blog
>  <li>
>      <a href="http://example.org/page.html">homepage</a>
>  </li>
>  <li>
>      <a href="http://example.org/feed.rss" type="application/xml">feed</a>
>  </li>
> </ul>

Well, the XOXO spec does discuss what to do with "text", "type" and
"htmlUrl" properties.

Take a closer look.

 http://microformats.org/wiki/xoxo


> Les Orchard's had a fiddle at [2], his version:
> 
> <li class="rss">
>   <a class="xmlUrl" type="application/xml"
> href="http://example.org/feed.rss">XML</a>
>   <a class="htmlUrl" href="http://example.org/page.html" title="A
> Blog">A Blog</a>
> </li>
>
> I think Les has it much closer to what's needed,

This is closer, except that two <a> siblings are an implied list.

> the use of class
> seems wise.

There is definitely a difference in approach between XOXO, which uses
definition lists for property/value pairs, and the class name approach. I
think we're still figuring out how to best use these two approaches
together.

One approach has been to define a microformat for the specific *item*
(whether it is a subscription, a wish, a song, etc.), and then just use XOXO
to express lists of that item (subscription lists, wish lists, play lists,
etc.).  We want to avoid the incredibly bad habit of many other format
designers to make up a new list element for each different kind of thing
they want to keep a list of.

A few more concrete examples.

We have hCard for contact info.  Do we need a new microformat for a contact
list?  No.  You simply use XOXO+hCard (e.g. <li class="vcard">...</li> )

Done.

S5 (the XOXO version) is another good example.
The slides are <li class="slide">...</li>


> But is this a list of URIs? Definitions? I dunno.

Right.


> Another
> question would be how to extend this, if for example there was a
> description of the feed available too (check Les' OPML source -
> there's description and a few more attributes in there).

In the general case, the use of definition lists in XOXO lets you extend
this however you want. However...


> When it comes to parsing the stuff, it would be nice to have a common
> convention ;-)

Precisely.  And extensions are typically contrary to common convention
(otherwise they wouldn't call them extensions ;).

I think what we need is perhaps a page on the wiki to discuss specific uses
of XOXO (e.g. subscription lists), along with experiments/thoughts with how
to do so (i.e. the markup sample you gave above).

Perhaps the XOXO brainstorming page would be appropriate for this
discussion.

 http://microformats.org/wiki/xoxo-brainstorming

I noticed that DavidJanes has already started the analysis of subscription
lists.

Please feel free to jump-in and offer alternative examples / markup in the
brainstorming document.

Thanks,

Tantek

From ryan at technorati.com  Thu Dec  1 12:41:08 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  1 12:41:11 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <d79e89ce0512010624l2fc59d94ob3247726e3a7bfa2@mail.gmail.com>
References: <43843033.4080802@blogmatrix.com>
	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>
	<d79e89ce0512010624l2fc59d94ob3247726e3a7bfa2@mail.gmail.com>
Message-ID: <6BD83066-A93A-47FF-9DF0-1A7F3987BCEE@technorati.com>

On Dec 1, 2005, at 6:24 AM, Luke Arno wrote:
> On 12/1/05, Ryan King <ryan@technorati.com> wrote:
>> On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote:
>
> [ snip ]
>
>> 4. Why do we prefer <h#> over class="title" for entry titles?
>>
>
> A preference one way or the other does make
> the XSLT make sense.

Let me rephrase:

4. Why not just use class="title"?

> [ snip ]
>
>> 8. Open item for the list:
>>
>>> if there is no Entry Updated and Entry Published elements,
>>> transformation to Atom is problematic
>>> This is because a published element is required. Suggestions would
>>> be appreciated here.
>
> Actually it is updated that is required. Published is not.
>
>    o  atom:feed elements MUST contain exactly one atom:updated  
> element.
>    o  atom:entry elements MUST contain exactly one atom:updated  
> element.
>    o  atom:entry elements MUST NOT contain more than one  
> atom:published
>       element.

Ok, Luke can you put this on the wiki?

-ryan
--
Ryan King
ryan@technorati.com



From tantek at cs.stanford.edu  Thu Dec  1 12:48:37 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  1 12:48:53 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <6BD83066-A93A-47FF-9DF0-1A7F3987BCEE@technorati.com>
Message-ID: <BFB4A177.645E9%tantek@cs.stanford.edu>

On 12/1/05 12:41 PM, "Ryan King" <ryan@technorati.com> wrote:

> On Dec 1, 2005, at 6:24 AM, Luke Arno wrote:
>> On 12/1/05, Ryan King <ryan@technorati.com> wrote:
>>> On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote:
>> 
>> [ snip ]
>> 
>>> 4. Why do we prefer <h#> over class="title" for entry titles?
>>> 
>> 
>> A preference one way or the other does make
>> the XSLT make sense.
> 
> Let me rephrase:
> 
> 4. Why not just use class="title"?

Or re-use classnames that mean the same thing from the other established
microformats (hCard, hCalendar) like we did in hReview.

We should reuse the building blocks from existing microformats as much as
possible.


>> [ snip ]
>> 
>>> 8. Open item for the list:
>>> 
>>>> if there is no Entry Updated and Entry Published elements,
>>>> transformation to Atom is problematic
>>>> This is because a published element is required. Suggestions would
>>>> be appreciated here.
>> 
>> Actually it is updated that is required. Published is not.
>> 
>>    o  atom:feed elements MUST contain exactly one atom:updated
>> element.
>>    o  atom:entry elements MUST contain exactly one atom:updated
>> element.
>>    o  atom:entry elements MUST NOT contain more than one
>> atom:published
>>       element.
> 
> Ok, Luke can you put this on the wiki?

Actually, those requirements come from Atom 1.0 if I'm not mistaken.

Rather than repeating those requirements, please reference (hyperlink to)
the appropriate section of the Atom 1.0 specification.

Thanks,

Tantek

From scott at randomchaos.com  Thu Dec  1 12:57:04 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec  1 12:57:13 2005
Subject: [uf-discuss] Cross-browser JavaScript vevent parser?
Message-ID: <6AF1F920-313C-4F81-BF7C-76CC14CF9B40@randomchaos.com>

I'm hoping to use vevent as an AJAX tranfser format.  I'm looking for  
a Safari-compatible JavaScript vevent parser for an intranet  
application (Safari is our default browser).  Closest I've found is  
David's microformat.user.js [1], which says at the top "This script  
is not meant to be as monolithic as it looks -- it should be broken  
into separate scripts, one for each microformat."  (It's also lacking  
a clear license.)

So has anyone broken up this script already and/or applied vevent  
parsing code in contexts other than Greasemonkey scripts?  My  
JavaScript skills are sufficient to do parsing of the XML by tag  
names, but probably not by class names, so if I can't find an  
existing function to do that for me, I'll end up writing a single-use  
XML format to transfer what is essentially vevent data.

Peace,
Scott

[1] http://www.blogmatrix.com/include/microformat-find.user.js
From drernie at opendarwin.org  Thu Dec  1 13:00:33 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Thu Dec  1 13:00:36 2005
Subject: [uf-discuss] Cross-browser JavaScript vevent parser?
In-Reply-To: <6AF1F920-313C-4F81-BF7C-76CC14CF9B40@randomchaos.com>
References: <6AF1F920-313C-4F81-BF7C-76CC14CF9B40@randomchaos.com>
Message-ID: <1E93A464-1877-46C8-9B68-751AF03F94D0@opendarwin.org>

Hi Scott,

On Dec 1, 2005, at 12:57 PM, Scott Reynen wrote:
> I'm hoping to use vevent as an AJAX tranfser format.  I'm looking  
> for a Safari-compatible JavaScript vevent parser for an intranet  
> application (Safari is our default browser).  Closest I've found is  
> David's microformat.user.js [1], which says at the top "This script  
> is not meant to be as monolithic as it looks -- it should be broken  
> into separate scripts, one for each microformat."  (It's also  
> lacking a clear license.)

You may want to look at Safari Guide, which is the closest I've found  
to a JavaScript "add-on" for Safari.


> So has anyone broken up this script already and/or applied vevent  
> parsing code in contexts other than Greasemonkey scripts?  My  
> JavaScript skills are sufficient to do parsing of the XML by tag  
> names, but probably not by class names, so if I can't find an  
> existing function to do that for me, I'll end up writing a single- 
> use XML format to transfer what is essentially vevent data.

That seems the least of your challenges.  There's a zillion  
"getElementsByClass" implementations available...

-- Ernie P.



>
> Peace,
> Scott
>
> [1] http://www.blogmatrix.com/include/microformat-find.user.js
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From manuel.gonzalez.noriega at gmail.com  Thu Dec  1 14:31:28 2005
From: manuel.gonzalez.noriega at gmail.com (=?ISO-8859-1?Q?Manuel_Gonz=E1lez_Noriega?=)
Date: Thu Dec  1 14:31:30 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
Message-ID: <d572750a0512011431l676a786eg@mail.gmail.com>

Hi Chris, Andreas, thanks for answering.


> Hmm. Sounds like a case for <blockquote cite="%url%"> or <cite>....
>
By <cite> I assume you mean <q> ? In any case, the need would remain
to distinguish regular quotes from trackbacks

> However, it would be interesting to do something like <a href="%url%"
> rel="trackback">xyz</a>...
>

Yes, that would be more like it, but

a) As Andreas said, rel trackback is already 'taken' to some extent by
common practice and with a different meaning.

b) I'd rather see a way to identify both container  and source for the trackback

Maybe something like:
<blockquote class="trackback">%content% <a href=""
class="trackback_source" href="%url%"></a>

> I didn't realize that the <cite> tag is basically worthless when it
> comes to inline citations to an external source... does this mean that
> one should always use blockquote and just style it to be inline?

No, <q> is for inline quotations, <cite> defines the source for the
citation, usually the name of the book, movie, etc.

> FYI, when you drop content into the Flock editor from another webpage,
> we properly add the <blockquote> tag with a citation to the original
> URL. If you parsed a page with such markup, you could theoretically
> infer trackback, n'est-ce pas?
>

I still couldn't say if it's a trackback or just you quoting someone,
could I ? :-)

BTW, off-topic, but now you mention dropping and blockquote, I
recently made a tiny experiment along those params:

http://simplelogica.net/cajondesastre/dragvatar/


--
Manuel
a veces :) a veces :(
pero siempre trabajando duro para Simplel?gica: apariencia,
experiencia y comunicaci?n en la web.
http://simplelogica.net # (+34) 985 22 12 65

?Ah! y escribiendo en Logicola: http://logicola.simplelogica.net
From scott at randomchaos.com  Thu Dec  1 14:34:36 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec  1 14:34:44 2005
Subject: [uf-discuss] Cross-browser JavaScript vevent parser?
In-Reply-To: <1E93A464-1877-46C8-9B68-751AF03F94D0@opendarwin.org>
References: <6AF1F920-313C-4F81-BF7C-76CC14CF9B40@randomchaos.com>
	<1E93A464-1877-46C8-9B68-751AF03F94D0@opendarwin.org>
Message-ID: <20E8223E-3959-4E0A-A9DD-C61BD348B5C5@randomchaos.com>

Dr. Ernie Prabhakar wrote:

> That seems the least of your challenges.  There's a zillion  
> "getElementsByClass" implementations available...

Yep, that is actually the least of my challenges.  I thought all of  
the getElementsByClass functions I was trying were just poorly  
written, but it turns out the XML object model is entirely different  
from the DOM, so none of my DOM knowledge is applicable.  Time to  
relearn JavaScript for XML, I guess.

Peace,
Scott

From manuel.gonzalez.noriega at gmail.com  Thu Dec  1 14:38:49 2005
From: manuel.gonzalez.noriega at gmail.com (=?ISO-8859-1?Q?Manuel_Gonz=E1lez_Noriega?=)
Date: Thu Dec  1 14:38:50 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <op.s038x0hjares2h@mail.solitude.dk>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
Message-ID: <d572750a0512011438x8bc4eau@mail.gmail.com>

On 01/12/05, Andreas Haugstrup <solitude@solitude.dk> wrote:

Hi Andreas

> > Hmm. Sounds like a case for <blockquote cite="%url%"> or <cite>....
>
> I'm using rel="cite" for references (with a profile) rather the <cite><a>
> compound. This is so I can use rev="cite" for a list of trackbacks
> recieved.

Is that a homemade profile or is it available somewhere?


Maybe we should reclaim rel="trackback" for good. But I still would
like a public interface to both trackback contents and sources on a
page, via microformats.

--
Manuel
a veces :) a veces :(
pero siempre trabajando duro para Simplel?gica: apariencia,
experiencia y comunicaci?n en la web.
http://simplelogica.net # (+34) 985 22 12 65

?Ah! y escribiendo en Logicola: http://logicola.simplelogica.net
From si at kittle.co.uk  Thu Dec  1 14:49:54 2005
From: si at kittle.co.uk (Simon Kittle)
Date: Thu Dec  1 14:50:18 2005
Subject: [uf-discuss] is there microformat / uri scheme for referncing book
	parts (content)? (Bible ref's)
Message-ID: <000501c5f6c9$8c020850$6401a8c0@SIMONNOTEBOOK>

Hi,

So, I have read a bit on the wiki and can't find an answer to the above
question so I thought I'd post it.  What I'd like is a way to reference
specific sections of a book down to chapter, paragraph, verse, etc.

Actually, what I'm after is a specific instance of this (funnily enough it
doesn't seem that the more general case would be much use) in that I want a
scheme / microformat for specifying Bible versse or passages.  Bible verses
are obviously well referenced in both online and offline world but there
isn't a defacto standard for marking them up. (that I could find, anyone?)

It's definitely a cowpath in the sense that Bible verses are quoted all over
the web (so qualifies for the term microformat in that sense) on Christian
sites but also on many a blog, news sites - anywhere there is a chance of
the Bible being mentioned.  

It's common for people to quote Bible verses in part, giving the reference
along side so a way to know it is a Bible reference and automatically look
up the appropriate verse, previous and next, etc, etc would be a valueable
tool.  Also, often when verses are quoted in full there is often need to
view / access different translations, etc so there would be some extremely
useful applications that could use such a scheme as well as the general
advantages that always come with marking something up semantically.

It wouldn't take a lot I don't think, something along the lines of
class="BibleRef" would probably suffice making the following possible:

<span class="BibleRef">Psalm 46:10</span>
<abbr class="BibleRef" title="Psalm 46:10">Ps 46:10</abbr>


Thoughts?


- Simon





From brian.suda at gmail.com  Thu Dec  1 15:06:24 2005
From: brian.suda at gmail.com (brian suda)
Date: Thu Dec  1 15:06:47 2005
Subject: [uf-discuss] is there microformat / uri scheme for referncing
	book	parts (content)? (Bible ref's)
In-Reply-To: <000501c5f6c9$8c020850$6401a8c0@SIMONNOTEBOOK>
References: <000501c5f6c9$8c020850$6401a8c0@SIMONNOTEBOOK>
Message-ID: <438F81F0.6010306@gmail.com>

I know what you are asking for, but there is a bigger problem with
Biblical text. It is NOT well formed[1]. You can not make an XML
representation of a bible verse. There are references that span two
paragraphs, therefore it is not possible todo something like:
<p> text text text <span class="part1"> text text</p>
<p>text text text</span><span class="part2"> text text text</span></p>

This is not well-formed, but very common.

That said, there is a citation format in the works[2], this will allow
for the ability to cite page, etc. Bible chapter, paragraph, verse were
not in the original idea, but could make there way in depending on other
formats.

Have you looked into how other formats, Dublin Core, etc. handle this?
or can/do they?

-brian

[1] -
http://www.idealliance.org/papers/xmle02/dx_xmle02/papers/03-03-07/03-03-07.html
[2] - http://microformats.org/wiki/cite


Simon Kittle wrote:

>Hi,
>
>So, I have read a bit on the wiki and can't find an answer to the above
>question so I thought I'd post it.  What I'd like is a way to reference
>specific sections of a book down to chapter, paragraph, verse, etc.
>
>Actually, what I'm after is a specific instance of this (funnily enough it
>doesn't seem that the more general case would be much use) in that I want a
>scheme / microformat for specifying Bible versse or passages.  Bible verses
>are obviously well referenced in both online and offline world but there
>isn't a defacto standard for marking them up. (that I could find, anyone?)
>
>It's definitely a cowpath in the sense that Bible verses are quoted all over
>the web (so qualifies for the term microformat in that sense) on Christian
>sites but also on many a blog, news sites - anywhere there is a chance of
>the Bible being mentioned.  
>
>It's common for people to quote Bible verses in part, giving the reference
>along side so a way to know it is a Bible reference and automatically look
>up the appropriate verse, previous and next, etc, etc would be a valueable
>tool.  Also, often when verses are quoted in full there is often need to
>view / access different translations, etc so there would be some extremely
>useful applications that could use such a scheme as well as the general
>advantages that always come with marking something up semantically.
>
>It wouldn't take a lot I don't think, something along the lines of
>class="BibleRef" would probably suffice making the following possible:
>
><span class="BibleRef">Psalm 46:10</span>
><abbr class="BibleRef" title="Psalm 46:10">Ps 46:10</abbr>
>
>
>Thoughts?
>
>
>- Simon
>
>
>
>
>
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>
>  
>

From davidjanes at blogmatrix.com  Thu Dec  1 15:16:46 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec  1 15:14:49 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <BFB4A177.645E9%tantek@cs.stanford.edu>
References: <BFB4A177.645E9%tantek@cs.stanford.edu>
Message-ID: <438F845E.3050009@blogmatrix.com>

Tantek ?elik wrote:
> On 12/1/05 12:41 PM, "Ryan King" <ryan@technorati.com> wrote:
> 
>> On Dec 1, 2005, at 6:24 AM, Luke Arno wrote:
>>> On 12/1/05, Ryan King <ryan@technorati.com> wrote:
>>>> On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote:
>>> [ snip ]
>>>
>>>> 4. Why do we prefer <h#> over class="title" for entry titles?
>>>>
>>> A preference one way or the other does make
>>> the XSLT make sense.
>> Let me rephrase:
>>
>> 4. Why not just use class="title"?
> 
> Or re-use classnames that mean the same thing from the other established
> microformats (hCard, hCalendar) like we did in hReview.
> 
> We should reuse the building blocks from existing microformats as much as
> possible.
> 

Excuse my lack of replies -- I've been/am in rather rotten health 
(hopefully temporary).

The <h#> rule is based on "use appropriate XHTML elements first" 
principle. <h#> are titles (and are used as such in many blogs).

Regards, etc...

From ryan at technorati.com  Thu Dec  1 15:27:21 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  1 15:27:24 2005
Subject: [uf-discuss] Cross-browser JavaScript vevent parser?
In-Reply-To: <6AF1F920-313C-4F81-BF7C-76CC14CF9B40@randomchaos.com>
References: <6AF1F920-313C-4F81-BF7C-76CC14CF9B40@randomchaos.com>
Message-ID: <004C24D0-C750-490A-898B-4406733E405E@technorati.com>

On Dec 1, 2005, at 12:57 PM, Scott Reynen wrote:

> I'm hoping to use vevent as an AJAX tranfser format.  I'm looking  
> for a Safari-compatible JavaScript vevent parser for an intranet  
> application (Safari is our default browser).

Have you looked at http://web.mit.edu/glasser/www/JSCalendar/?

-ryan

--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Thu Dec  1 15:30:05 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  1 15:30:08 2005
Subject: [uf-discuss] is there microformat / uri scheme for referncing
	book parts (content)? (Bible ref's)
In-Reply-To: <000501c5f6c9$8c020850$6401a8c0@SIMONNOTEBOOK>
References: <000501c5f6c9$8c020850$6401a8c0@SIMONNOTEBOOK>
Message-ID: <503EC9C6-70E9-4912-BA07-D9A395EB072E@technorati.com>

On Dec 1, 2005, at 2:49 PM, Simon Kittle wrote:

> Hi,
>
> So, I have read a bit on the wiki and can't find an answer to the  
> above
> question so I thought I'd post it.  What I'd like is a way to  
> reference
> specific sections of a book down to chapter, paragraph, verse, etc.
>
> Actually, what I'm after is a specific instance of this (funnily  
> enough it
> doesn't seem that the more general case would be much use) in that  
> I want a
> scheme / microformat for specifying Bible versse or passages.   
> Bible verses
> are obviously well referenced in both online and offline world but  
> there
> isn't a defacto standard for marking them up. (that I could find,  
> anyone?)
>
> It's definitely a cowpath in the sense that Bible verses are quoted  
> all over
> the web (so qualifies for the term microformat in that sense) on  
> Christian
> sites but also on many a blog, news sites - anywhere there is a  
> chance of
> the Bible being mentioned.
>
> It's common for people to quote Bible verses in part, giving the  
> reference
> along side so a way to know it is a Bible reference and  
> automatically look
> up the appropriate verse, previous and next, etc, etc would be a  
> valueable
> tool.  Also, often when verses are quoted in full there is often  
> need to
> view / access different translations, etc so there would be some  
> extremely
> useful applications that could use such a scheme as well as the  
> general
> advantages that always come with marking something up semantically.
>
> It wouldn't take a lot I don't think, something along the lines of
> class="BibleRef" would probably suffice making the following possible:
>
> <span class="BibleRef">Psalm 46:10</span>
> <abbr class="BibleRef" title="Psalm 46:10">Ps 46:10</abbr>

If you want to start research, start collecting *real world* examples  
on http://microformats.org/wiki/book-reference-examples (or http:// 
microformats.org/wiki/bible-reference-examples, if you just want to  
cover those).

-ryan
--
Ryan King
ryan@technorati.com



From solitude at solitude.dk  Thu Dec  1 15:52:13 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Thu Dec  1 15:52:23 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <d572750a0512011438x8bc4eau@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
Message-ID: <op.s04pxbr4ares2h@mail.solitude.dk>

On Thu, 01 Dec 2005 23:38:49 +0100, Manuel Gonz?lez Noriega  
<manuel.gonzalez.noriega@gmail.com> wrote:

> Is that a homemade profile or is it available somewhere?

Homemade as an example of a profile for blogs <URL:  
http://www.solitude.dk/blogprofile/011/ >

Now that hAtom is as far as it is I need to ditch key parts of my example  
and convert to hAtom which is more thorough (albeit missing parts I use  
internally like rel="enclosure" and rel="cite").

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From si at kittle.co.uk  Thu Dec  1 15:59:31 2005
From: si at kittle.co.uk (Simon Kittle)
Date: Thu Dec  1 15:59:46 2005
Subject: [uf-discuss] is there microformat / uri scheme for
	referncingbook	parts (content)? (Bible ref's)
In-Reply-To: <438F81F0.6010306@gmail.com>
Message-ID: <000601c5f6d3$4573da80$6401a8c0@SIMONNOTEBOOK>


> I know what you are asking for, but there is a bigger problem 
> with Biblical text. It is NOT well formed[1]. You can not 
> make an XML representation of a bible verse. There are 
> references that span two paragraphs, therefore it is not 
> possible todo something like:
> <p> text text text <span class="part1"> text text</p> <p>text 
> text text</span><span class="part2"> text text text</span></p>
> 
> This is not well-formed, but very common.

Yeah, I realise that.  I suppose I should clarify I am looking specifically
for a way to markup the references, as opposed to the full on verses /
passages.

But just as a side note there are actually several projects who are
overcoming the issues you talk about (or who've overcome them) [1] example:
[2]

> That said, there is a citation format in the works[2], this 
> will allow for the ability to cite page, etc. Bible chapter, 
> paragraph, verse were not in the original idea, but could 
> make there way in depending on other formats.

Okay, I will take a look at the cite pages.

> Have you looked into how other formats, Dublin Core, etc. handle this?
> or can/do they?

Had a (very) brief look and couldn't find anything, that site's a maze!
Isn't most DC metadata (when embedded in an HTML document) included in the
META tags?  I have to admit I know very little about it but it could be
worth some further research.


- simon

[1] - http://www.bibletechnologies.net/
[2] - http://www.bibletechnologies.net/201.dsp#body.1_div.4

ps: Is it just me that's had to create refences as above by hand?  Or do
some people have clever email clients which do it for them?



From scott at randomchaos.com  Thu Dec  1 16:01:50 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec  1 16:01:56 2005
Subject: [uf-discuss] Cross-browser JavaScript vevent parser?
In-Reply-To: <004C24D0-C750-490A-898B-4406733E405E@technorati.com>
References: <6AF1F920-313C-4F81-BF7C-76CC14CF9B40@randomchaos.com>
	<004C24D0-C750-490A-898B-4406733E405E@technorati.com>
Message-ID: <579A904C-0819-49D0-873A-1306DF88C169@randomchaos.com>

Ryan King wrote:

> On Dec 1, 2005, at 12:57 PM, Scott Reynen wrote:
>
>> I'm hoping to use vevent as an AJAX tranfser format.  I'm looking  
>> for a Safari-compatible JavaScript vevent parser for an intranet  
>> application (Safari is our default browser).
>
> Have you looked at http://web.mit.edu/glasser/www/JSCalendar/?

Looks like that handles vevents via DOM just like everything else  
I've seen.  Apparently no one is using XMLHTTPRequest to request  
actual XML over HTTP.  I've almost figured it out, though, so no  
worries.

Peace,
Scott
From si at kittle.co.uk  Thu Dec  1 16:20:17 2005
From: si at kittle.co.uk (Simon Kittle)
Date: Thu Dec  1 16:20:33 2005
Subject: [uf-discuss] is there microformat / uri scheme for referncingbook
	parts (content)? (Bible ref's)
In-Reply-To: <503EC9C6-70E9-4912-BA07-D9A395EB072E@technorati.com>
Message-ID: <000001c5f6d6$2cbf83b0$6401a8c0@SIMONNOTEBOOK>

> take a lot I don't think, something along the lines of 
> > class="BibleRef" would probably suffice making the 
> following possible:
> >
> > <span class="BibleRef">Psalm 46:10</span> <abbr class="BibleRef" 
> > title="Psalm 46:10">Ps 46:10</abbr>
> 
> If you want to start research, start collecting *real world* 
> examples on 
> http://microformats.org/wiki/book-reference-examples (or 
> http:// microformats.org/wiki/bible-reference-examples, if 
> you just want to cover those).

Sweet I'll try and do that - umm, can't create an account on the wiki
though, do I need to request one?  Just keeps coming back with "invalid user
name" when I try (with user 'simonkittle').

- Simon


From ryan at technorati.com  Thu Dec  1 17:39:54 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  1 17:40:00 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <op.s04pxbr4ares2h@mail.solitude.dk>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
Message-ID: <2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>

On Dec 1, 2005, at 3:52 PM, Andreas Haugstrup wrote:

> On Thu, 01 Dec 2005 23:38:49 +0100, Manuel Gonz?lez Noriega  
> <manuel.gonzalez.noriega@gmail.com> wrote:
>
>> Is that a homemade profile or is it available somewhere?
>
> Homemade as an example of a profile for blogs <URL: http:// 
> www.solitude.dk/blogprofile/011/ >
>
> Now that hAtom is as far as it is I need to ditch key parts of my  
> example and convert to hAtom which is more thorough (albeit missing  
> parts I use internally like rel="enclosure" and rel="cite").

Though http://microformats.org/wiki/rel-enclosure doesn't have a  
profile URI, there's no need to replicate that into hAtom, you can  
just use rel-enclosure.

-ryan
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Thu Dec  1 17:47:01 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  1 17:47:02 2005
Subject: [uf-discuss] draft blog post on rel vs. rev
Message-ID: <A2C025B7-5B2B-4F09-B308-B2DD010F3D32@technorati.com>

I sometimes mail draft blog posts around to select people for review.  
In an experiment on openness and collaboration, I'm gonna try the  
whole list this time. Apologies for the markup, which may be tough to  
read. Any (constructive) comments welcome. If I hear nothing I'll  
post it later tonight.

----
Title: Rel vs. Rev

<p>Another note in my very-neglected series on Semantic XHTML basics  
<a href="http://www.microformats.org/blog/2005/10/19/more-than- 
styling/">started awhile back</a>.</p>

<p>It seems that everytime I present microformats, I need to explain  
the difference bettween the <a href="http://www.w3.org/TR/REC-html40/ 
struct/links.html#adef-rel">rel</a> and <a href="http://www.w3.org/TR/ 
REC-html40/struct/links.html#adef-rev">rev</a> attributes. Its  
understandable that most people don't grasp the difference, as I'm  
sure most webdevelopers haven't needed to make use of these  
semantics.</p>

<p>First of all, <code>rel</code> is an attribute which can be  
applied to <code>&lt;a&gt;</code> and <code>&lt;link&gt;</code> to  
define the relationship between the linked document and the current  
one. So, a very common example is a link to a feed. This blog has:</p>

<pre><code>&lt;link rel="alternate" type="application/rss+xml"  
title="RSS 2.0" href="http://www.microformats.org/feed/" /&gt;</ 
code></pre>

<p>This can be read as <code>http://microformats.org/feed/</code> is  
an <code>alternate</code> for <code>http://microformats.org/</code>  
(Incidentally, the feed could link to this blog with  
<code>rev="alternate"</code>, which would have <a href="http:// 
www.w3.org/TR/REC-html40/struct/links.html#h-12.3.1">exactly the same  
meaning</a>. More on <code>rev</code> in a minute.).</p>

<p><code>rel</code> is used by <a href="http://www.gmpg.org/ 
xfn/">XFN</a>, <a href="http://microformats.org/wiki/rel-tag">rel- 
tag</a>, <a href="http://microformats.org/wiki/rel-directory">rel- 
directory</a> and <a href="http://microformats.org/wiki/rel- 
payment">rel-payment</a> microformats.</p>

<p>Now, <code>rev</code> is just like <code>rel</code>, but the  
relationship is reversed (I think of rev as "reverse relationship").  
It get used in the <a href="http://microformats.org/wiki/vote- 
links">vote-links</a> microformat like this:</p>

<pre><code>
&lt;a href="http://supr.c.ilio.us/blog/" rev="vote-for" title="supr  
snark"&gt;supr.c.ilio.us rocks!&lt;/a&gt;
</code></pre>

<p>...which would be read as "&lt;this document&gt; is a vote-for  
http://supr.c.ilio.us/blog/".</p>

<p>rel and rev are useful for describing the relationships between  
two resources on the web. Remember, it is only the relationship  
between the documents, not the documents themselves which are  
described.</p>
From scott at randomchaos.com  Thu Dec  1 18:14:38 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec  1 18:14:47 2005
Subject: [uf-discuss] draft blog post on rel vs. rev
In-Reply-To: <A2C025B7-5B2B-4F09-B308-B2DD010F3D32@technorati.com>
References: <A2C025B7-5B2B-4F09-B308-B2DD010F3D32@technorati.com>
Message-ID: <C9FFB09A-D8F6-4D75-BE73-524256030C32@randomchaos.com>

Just a typo:

> It get used

should be "It gets used" in 4th from last paragraph.  Other than  
that, my only comment is on the end:

> Remember, it is only the relationship between the documents, not  
> the documents themselves which are described.

I suspect many people reading that will wonder: how does one describe  
the documents themselves?

Peace,
Scott
From tantek at cs.stanford.edu  Thu Dec  1 18:23:39 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  1 18:23:58 2005
Subject: [uf-discuss] draft blog post on rel vs. rev
In-Reply-To: <A2C025B7-5B2B-4F09-B308-B2DD010F3D32@technorati.com>
Message-ID: <BFB4F001.6462E%tantek@cs.stanford.edu>

On 12/1/05 5:47 PM, "Ryan King" <ryan@technorati.com> wrote:

> I sometimes mail draft blog posts around to select people for review.
> In an experiment on openness and collaboration, I'm gonna try the
> whole list this time. Apologies for the markup, which may be tough to
> read. Any (constructive) comments welcome. If I hear nothing I'll
> post it later tonight.
> 
> ----
> Title: Rel vs. Rev

Did you see http://microformats.org/wiki/rel-faq ?

Thanks,

Tantek

From tantek at cs.stanford.edu  Thu Dec  1 18:25:39 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  1 18:25:57 2005
Subject: [uf-discuss] invalid user name - use a WikiName
In-Reply-To: <000001c5f6d6$2cbf83b0$6401a8c0@SIMONNOTEBOOK>
Message-ID: <BFB4F032.6462F%tantek@cs.stanford.edu>

On 12/1/05 4:20 PM, "Simon Kittle" <si@kittle.co.uk> wrote:

>> take a lot I don't think, something along the lines of
>>> class="BibleRef" would probably suffice making the
>> following possible:
>>> 
>>> <span class="BibleRef">Psalm 46:10</span> <abbr class="BibleRef"
>>> title="Psalm 46:10">Ps 46:10</abbr>
>> 
>> If you want to start research, start collecting *real world*
>> examples on 
>> http://microformats.org/wiki/book-reference-examples (or
>> http:// microformats.org/wiki/bible-reference-examples, if
>> you just want to cover those).
> 
> Sweet I'll try and do that - umm, can't create an account on the wiki
> though, do I need to request one?  Just keeps coming back with "invalid user
> name" when I try (with user 'simonkittle').

First question in the FAQ:

http://microformats.org/wiki/faq

Try SimonKittle (note caps).

Tantek

From ryan at technorati.com  Thu Dec  1 18:40:41 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  1 18:40:44 2005
Subject: [uf-discuss] draft blog post on rel vs. rev
In-Reply-To: <BFB4F001.6462E%tantek@cs.stanford.edu>
References: <BFB4F001.6462E%tantek@cs.stanford.edu>
Message-ID: <A9719341-6A4C-410A-97AC-F7A2B432B513@technorati.com>

On Dec 1, 2005, at 6:23 PM, Tantek ?elik wrote:
> On 12/1/05 5:47 PM, "Ryan King" <ryan@technorati.com> wrote:
>
>> I sometimes mail draft blog posts around to select people for review.
>> In an experiment on openness and collaboration, I'm gonna try the
>> whole list this time. Apologies for the markup, which may be tough to
>> read. Any (constructive) comments welcome. If I hear nothing I'll
>> post it later tonight.
>>
>> ----
>> Title: Rel vs. Rev
>
> Did you see http://microformats.org/wiki/rel-faq ?

Yeah, I forgot to link that. The idea was to provide a short, concise  
intro, then point people at that page.

-ryan
--
Ryan King
ryan@technorati.com



From scott at randomchaos.com  Thu Dec  1 20:23:50 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec  1 20:23:57 2005
Subject: [uf-discuss] Microformat Base
Message-ID: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>

I thought I'd go ahead and play around with a microformat-based  
alternative to Google Base.  So far, I have a basic spider that I set  
loose from microformats.org to slowly wander the web.  When it finds  
any known microformat-associated class names, it records the data  
which can then be searched here:

http://www.randomchaos.com/microformats/base/

Or via URL like so:

http://www.randomchaos.com/microformats/base/?key=fn&value=Tantek

It's currently only looking for hcard and hcalendar class names. The  
spider can be invoked on a site manually like so:

http://www.randomchaos.com/microformats/base/spider/?url=http:// 
domain.com/path/to/microformat/

All open source [1][2][3][4] if anyone wants to play with it.  It's  
pretty basic right now, but I'd be interested in any feedback you all  
have.

Peace,
Scott

[1] http://www.randomchaos.com/source/?source=http%3A%2F% 
2Fwww.randomchaos.com%2Fmicroformats%2Fbase%2Fspider/index.php
[2] http://www.randomchaos.com/source/?source=http%3A%2F% 
2Fwww.randomchaos.com%2Fmicroformats%2Fbase%2Findex.php
[3] http://www.randomchaos.com/source/?source=http%3A%2F% 
2Fwww.randomchaos.com%2Fclass/mf_base_data.class.php
[4] http://www.randomchaos.com/source/?source=http%3A%2F% 
2Fwww.randomchaos.com%2Fclass/mf_base_source.class.php
From tantek at cs.stanford.edu  Thu Dec  1 20:26:06 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  1 20:26:22 2005
Subject: [uf-discuss] draft blog post on rel vs. rev
In-Reply-To: <A9719341-6A4C-410A-97AC-F7A2B432B513@technorati.com>
Message-ID: <BFB50C6B.64646%tantek@cs.stanford.edu>

On 12/1/05 6:40 PM, "Ryan King" <ryan@technorati.com> wrote:

> On Dec 1, 2005, at 6:23 PM, Tantek ?elik wrote:
>> On 12/1/05 5:47 PM, "Ryan King" <ryan@technorati.com> wrote:
>> 
>>> I sometimes mail draft blog posts around to select people for review.
>>> In an experiment on openness and collaboration, I'm gonna try the
>>> whole list this time. Apologies for the markup, which may be tough to
>>> read. Any (constructive) comments welcome. If I hear nothing I'll
>>> post it later tonight.
>>> 
>>> ----
>>> Title: Rel vs. Rev
>> 
>> Did you see http://microformats.org/wiki/rel-faq ?
> 
> Yeah, I forgot to link that. The idea was to provide a short, concise
> intro, then point people at that page.

Cool.  I re-read your post.  Looked very good.  Nice and short and to the
point.

Thanks,

Tantek

From tantek at cs.stanford.edu  Thu Dec  1 20:42:19 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  1 20:42:36 2005
Subject: [uf-discuss] Microformat Base
In-Reply-To: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
Message-ID: <BFB510A2.64649%tantek@cs.stanford.edu>

On 12/1/05 8:23 PM, "Scott Reynen" <scott@randomchaos.com> wrote:

> I thought I'd go ahead and play around with a microformat-based
> alternative to Google Base.  So far, I have a basic spider that I set
> loose from microformats.org to slowly wander the web.  When it finds
> any known microformat-associated class names, it records the data
> which can then be searched here:
> 
> http://www.randomchaos.com/microformats/base/
> 
> Or via URL like so:
> 
> http://www.randomchaos.com/microformats/base/?key=fn&value=Tantek

Uh, WOW.

This is VERY cool.


> It's currently only looking for hcard and hcalendar class names.

Consider adding hReview as well!


> The spider can be invoked on a site manually like so:
> 
> http://www.randomchaos.com/microformats/base/spider/?url=http://
> domain.com/path/to/microformat/
> 
> All open source [1][2][3][4] if anyone wants to play with it.  It's
> pretty basic right now, but I'd be interested in any feedback you all
> have.

Well done Scott.

Definitely add it to the "Implementations" sections on the specs for hCard
and hCalendar and for sure on the implementations page

 http://microformats.org/wiki/implementations

> [1] http://www.randomchaos.com/source/?source=http%3A%2F%
> 2Fwww.randomchaos.com%2Fmicroformats%2Fbase%2Fspider/index.php
> [2] http://www.randomchaos.com/source/?source=http%3A%2F%
> 2Fwww.randomchaos.com%2Fmicroformats%2Fbase%2Findex.php
> [3] http://www.randomchaos.com/source/?source=http%3A%2F%
> 2Fwww.randomchaos.com%2Fclass/mf_base_data.class.php
> [4] http://www.randomchaos.com/source/?source=http%3A%2F%
> 2Fwww.randomchaos.com%2Fclass/mf_base_source.class.php

Definitely include those links too.

Thanks,

Tantek

From ryan at technorati.com  Thu Dec  1 23:19:24 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  1 23:19:26 2005
Subject: [uf-discuss] =?iso-8859-1?q?=B5F_blog=2C_was_=28draft_blog_post_?=
 =?iso-8859-1?q?on_rel_vs=2E_rev=29?=
In-Reply-To: <BFB50C6B.64646%tantek@cs.stanford.edu>
References: <BFB50C6B.64646%tantek@cs.stanford.edu>
Message-ID: <D43273FD-9221-4BAF-B243-55124F4A5DA3@technorati.com>


On Dec 1, 2005, at 8:26 PM, Tantek ?elik wrote:
> Cool.  I re-read your post.  Looked very good.  Nice and short and  
> to the
> point.


posted: http://www.microformats.org/blog/2005/12/01/rel-vs-rev/

A couple meta thoughts on this topic:

1. When writing the blog on microformats.org I feel like I'm  
representing the entire community. Implications:
	a) please feel to call me on an misrepresentation I do
	b) please feel free to suggest topics
	c) maybe we need more contributors to the blog?

2. Random though: It dawned on my that the DRY principle doesn't  
apply to blogging. It more like RYUPHY (repeat yourself until people  
hear you).

-ryan
--
Ryan King
ryan@technorati.com



From supercanadian at gmail.com  Fri Dec  2 01:25:02 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Fri Dec  2 01:25:40 2005
Subject: =?ISO-8859-1?Q?Re:_[uf-discuss]_=B5F_blog,
	_was_(?= =?ISO-8859-1?Q?draft_blog_post_on_rel_vs._rev)?=
In-Reply-To: <D43273FD-9221-4BAF-B243-55124F4A5DA3@technorati.com>
References: <BFB50C6B.64646%tantek@cs.stanford.edu>
	<D43273FD-9221-4BAF-B243-55124F4A5DA3@technorati.com>
Message-ID: <84ce626f0512020125h7e2eb5bcob75a1c12eb4e44ca@mail.gmail.com>

Hello,

On 12/1/05, Ryan King <ryan@technorati.com> wrote:
>
> On Dec 1, 2005, at 8:26 PM, Tantek ?elik wrote:
> > Cool.  I re-read your post.  Looked very good.  Nice and short and
> > to the
> > point.
>
>
> posted: http://www.microformats.org/blog/2005/12/01/rel-vs-rev/
>
> A couple meta thoughts on this topic:
>
> 1. When writing the blog on microformats.org I feel like I'm
> representing the entire community. Implications:
>         a) please feel to call me on an misrepresentation I do
>         b) please feel free to suggest topics

One of the problem with hCards is that you have to know vCards before
you can really use them well.  To the uninitiated, this can be a
daunting task.  (And the wiki isn't that helpful unless the reader is
persistent.)

Perhaps, if there was an introducton article to the make up of a vCard
(and thus an hCard) is would help with its adoption.  Give some
examples, like how to mark up a name,.... how to mark up an
address,... an e-mail addresses,... etc.  (Many people learn best
through examples.)


See ya


>         c) maybe we need more contributors to the blog?
>
> 2. Random though: It dawned on my that the DRY principle doesn't
> apply to blogging. It more like RYUPHY (repeat yourself until people
> hear you).
>
> -ryan
> --
> Ryan King
> ryan@technorati.com
>
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From supercanadian at gmail.com  Fri Dec  2 01:35:03 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Fri Dec  2 01:35:39 2005
Subject: =?ISO-8859-1?Q?Re:_[uf-discuss]_=B5F_blog,
	_was_(?= =?ISO-8859-1?Q?draft_blog_post_on_rel_vs._rev)?=
In-Reply-To: <84ce626f0512020125h7e2eb5bcob75a1c12eb4e44ca@mail.gmail.com>
References: <BFB50C6B.64646%tantek@cs.stanford.edu>
	<D43273FD-9221-4BAF-B243-55124F4A5DA3@technorati.com>
	<84ce626f0512020125h7e2eb5bcob75a1c12eb4e44ca@mail.gmail.com>
Message-ID: <84ce626f0512020135j1b763626oe5b2a90a6a27c090@mail.gmail.com>

Hello,

Can't believe I missed this before: http://microformats.org/wiki/hcard-examples

(Forget what I said in my last post.)


Later

On 12/2/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> On 12/1/05, Ryan King <ryan@technorati.com> wrote:
> >
> > On Dec 1, 2005, at 8:26 PM, Tantek ?elik wrote:
> > > Cool.  I re-read your post.  Looked very good.  Nice and short and
> > > to the
> > > point.
> >
> >
> > posted: http://www.microformats.org/blog/2005/12/01/rel-vs-rev/
> >
> > A couple meta thoughts on this topic:
> >
> > 1. When writing the blog on microformats.org I feel like I'm
> > representing the entire community. Implications:
> >         a) please feel to call me on an misrepresentation I do
> >         b) please feel free to suggest topics
>
> One of the problem with hCards is that you have to know vCards before
> you can really use them well.  To the uninitiated, this can be a
> daunting task.  (And the wiki isn't that helpful unless the reader is
> persistent.)
>
> Perhaps, if there was an introducton article to the make up of a vCard
> (and thus an hCard) is would help with its adoption.  Give some
> examples, like how to mark up a name,.... how to mark up an
> address,... an e-mail addresses,... etc.  (Many people learn best
> through examples.)
>
>
> See ya
>
>
> >         c) maybe we need more contributors to the blog?
> >
> > 2. Random though: It dawned on my that the DRY principle doesn't
> > apply to blogging. It more like RYUPHY (repeat yourself until people
> > hear you).
> >
> > -ryan
> > --
> > Ryan King
> > ryan@technorati.com
> >
> >
> >
> > _______________________________________________
> > microformats-discuss mailing list
> > microformats-discuss@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-discuss
> >
>
>
> --
>     Charles Iliya Krempeaux, B.Sc.
>
>     charles @ reptile.ca
>     supercanadian @ gmail.com
>
>     developer weblog: http://ChangeLog.ca/
> ___________________________________________________________________________
>  Never forget where you came from
>


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From abramobagnara at tin.it  Fri Dec  2 02:30:27 2005
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri Dec  2 02:33:52 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
Message-ID: <43902243.4080901@tin.it>


Taken for granted that a microformat is a way to embed data inside xhtml
presentation, last night I was wondering if really it was unavoidable to
have so many different formats with complex rules and nasty exceptions.

>From this thinking I've tried to develop a little proposal to embed
arbitrary xml data inside xhtml and that may be extracted easily and
without ambiguities while leaving total freedom on data presentation.

My main interest was something similar to hcalendar to overcome current
limitations of this microformat wrt params.

This is the reason why you find that the attached test is for calendar
data, but my proposal should be general enough to permit embedding of
*any* xml data.

The attached stylesheet is for extraction of data in xml form, but it
might be easily modified to extract data in xCalendar or iCalendar
format (that maps 1:1 to xml).

-- 
Abramo Bagnara                       mailto:abramobagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_xx.xml
Type: text/xml
Size: 3630 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-discuss/attachments/20051202/5da9eee0/test_xx.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xhtml_xml.xsl
Type: text/xml
Size: 4024 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-discuss/attachments/20051202/5da9eee0/xhtml_xml.bin
From solitude at solitude.dk  Fri Dec  2 03:21:17 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Fri Dec  2 03:21:41 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
Message-ID: <op.s05ltrzjares2h@mail.solitude.dk>

On Fri, 02 Dec 2005 02:39:54 +0100, Ryan King <ryan@technorati.com> wrote:

>> Now that hAtom is as far as it is I need to ditch key parts of my  
>> example and convert to hAtom which is more thorough (albeit missing  
>> parts I use internally like rel="enclosure" and rel="cite").
>
> Though http://microformats.org/wiki/rel-enclosure doesn't have a profile  
> URI, there's no need to replicate that into hAtom, you can just use  
> rel-enclosure.

I've been using rel="enclosure" longer than the rel-enclosure document has  
been around, and that's why it's in my example. I use it to generate  
(Yahoo Media) enclosures in my RSS feed. And along with rel="cite" I use  
it to generate a list of enclosures and citations on my archive pages  
(e.g. http://www.solitude.dk/archives/2005_11.php ).

With that said rel-enclosure doesn't make a whole lot of sense. It says  
"relEnclosure is one of several microformats. By adding rel="enclosure" to  
a hyperlink, a page indicates that the destination of that hyperlink is  
intended to be downloaded and cached."

*Any* link indicates that the destination may be downloaded and cached -  
that's the whole point of making a link. If it's not meant to be  
downloaded there wouldn't be a link, and if it wasn't meant to be cached  
the HTTP header would tell me so (and my browser would handle it without  
me caring).

Enclosures have a different meaning. They are best compared to attachments  
in e-mail. The enclosure is a part of the current document and  
document+enclosure(s) should be seen as a whole. This has great value when  
talking about blog posts (and hAtom) because attachments are usually  
connected to a part of the page (a single blog entry).

I don't care where I point my profiles to, but rel-enclosure isn't what I  
mean when I use rel="enclosure".

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From pilgrim at gmail.com  Fri Dec  2 05:08:54 2005
From: pilgrim at gmail.com (Mark Pilgrim)
Date: Fri Dec  2 05:08:56 2005
Subject: =?ISO-8859-1?Q?Re:_[uf-discuss]_=B5F_blog,
	_was_(?= =?ISO-8859-1?Q?draft_blog_post_on_rel_vs._rev)?=
In-Reply-To: <84ce626f0512020125h7e2eb5bcob75a1c12eb4e44ca@mail.gmail.com>
References: <BFB50C6B.64646%tantek@cs.stanford.edu>
	<D43273FD-9221-4BAF-B243-55124F4A5DA3@technorati.com>
	<84ce626f0512020125h7e2eb5bcob75a1c12eb4e44ca@mail.gmail.com>
Message-ID: <14be96d30512020508m210c53f5t48f755cb99440d35@mail.gmail.com>

On 12/2/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Perhaps, if there was an introducton article to the make up of a vCard
> (and thus an hCard) is would help with its adoption.  Give some
> examples, like how to mark up a name,.... how to mark up an
> address,... an e-mail addresses,... etc.  (Many people learn best
> through examples.)

That sounds like a job for "Dive Into Microformats"...

--
Cheers,
-Mark
From brian.suda at gmail.com  Fri Dec  2 08:37:04 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Dec  2 08:37:27 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <43902243.4080901@tin.it>
References: <43902243.4080901@tin.it>
Message-ID: <43907830.5080107@gmail.com>

Just be careful not to re-invent the wheel. The W3C has a recommended[1]
way to extract RDF from XHTML. This same idea can be applied for XML
(and just about anything else for that matter).

[1] - http://www.w3.org/TeamSubmission/grddl/


Abramo Bagnara wrote:

>Taken for granted that a microformat is a way to embed data inside xhtml
>presentation, last night I was wondering if really it was unavoidable to
>have so many different formats with complex rules and nasty exceptions.
>
>>From this thinking I've tried to develop a little proposal to embed
>arbitrary xml data inside xhtml and that may be extracted easily and
>without ambiguities while leaving total freedom on data presentation.
>
>My main interest was something similar to hcalendar to overcome current
>limitations of this microformat wrt params.
>
>This is the reason why you find that the attached test is for calendar
>data, but my proposal should be general enough to permit embedding of
>*any* xml data.
>
>The attached stylesheet is for extraction of data in xml form, but it
>might be easily modified to extract data in xCalendar or iCalendar
>format (that maps 1:1 to xml).
>
>  
>
>------------------------------------------------------------------------
>
><?xml version="1.0" encoding="ISO-8859-1"?>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
><html xmlns="http://www.w3.org/1999/xhtml">
>  <head>
>    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
>    <title>Test</title>
>    <link type="text/css" rel="stylesheet" href="../../html/project.css" />
>  </head>
>  <body class="xx:vcalendar=">
>    <div class="xx:vtodo=">
>      <h2 class="xx:summary">Task di test</h2>
>      <div>
>        <span class="header">Location: </span>
>        <span class="xx:location">Location</span>
>      </div>
>      <div>
>        <b>Due date: </b>
>        <abbr class="xx:due=@title" title="20051130">30-11-2005</abbr>
>      </div>
>      <div class="xx:description">
>        <div class="ancestor-summary">Test</div>
>        <ol class="disc">
>          <li>
>            <div class="node-summary">
>              <a href="edit:/u/dothert/data/abramo/test.txt##18">Task di test</a>
>            </div>
>            <div class="node-location">Location</div>
>            <div class="node-description">
>              <p>Descrizione sotto divisa in paragrafi di una certa lunghezza di una
>certa lunghezza di una certa <b>lunghezza</b> di una certa lunghezza di una
>certa lunghezza di una certa lunghezza</p>
>              <p>Descrizione sotto divisa in paragrafi di una certa lunghezza di una
>certa lunghezza di una certa lunghezza di una certa lunghezza di una
>certa lunghezza di una certa lunghezza</p>
>              <p>Descrizione sotto divisa in paragrafi di una certa lunghezza di una
>certa lunghezza di una certa lunghezza di una certa lunghezza di una
>certa lunghezza di una certa lunghezza</p>
>            </div>
>          </li>
>        </ol>
>        <p>Descrizione della deadline</p>
>        <p>Descrizione sotto divisa in paragrafi di una certa lunghezza di una
>certa lunghezza di una certa lunghezza di una certa lunghezza di una
>certa lunghezza di una certa lunghezza</p>
>        <p>Descrizione sotto divisa in paragrafi di una certa lunghezza di una
>certa lunghezza di una certa lunghezza di una certa lunghezza di una
>certa lunghezza di una certa lunghezza</p>
>      </div>
>      <div><span class="header">Categories: </span><span class="xx:categories">a</span>, <span class="xx:categories">a:b</span>, <span class="xx:categories">a:b:c</span>, <span class="xx:categories">ismaele</span>, <span class="xx:categories">ismaele:opt</span>, <span class="xx:categories">licia</span>, <span class="xx:categories">licia:opt</span>, <span class="xx:categories">abramo</span>, <span class="xx:categories">abramo:cha</span>, <span class="xx:categories">test</span>, <span class="xx:categories">abramo</span></div>
>      <div>
>        <span class="header">Priority: </span>
>        <abbr class="xx:priority=@title" title="0">not specified</abbr>
>      </div>
>      <div>
>        <span class="header">Presidente: </span>
>        <span class="xx:attendee=">
>          <abbr class="xx:@role=@title" title="chair"></abbr>
>          <a class="xx:@cn xx:=@href" href="mailto:abramo.bagnara@gmail.com">Abramo Bagnara</a>
>        </span>
>      </div>
>      <div>
>	<span class="header">Partecipanti opzionali: </span>
>	<span class="xx:attendee=">
>	  <abbr class="xx:@role=@title" title="opt-participant"></abbr>
>          <a class="xx:@cn xx:=@href" href="mailto:">Ismaele Bagnara</a>
>        </span>, <span class="xx:attendee="><abbr class="xx:@role=@title"
>	title="opt-participant"></abbr>
>      <a class="xx:@cn xx:=@href" href="litabanelli@racine.ra.it">Licia Tabanelli</a></span></div>
>    </div>
>  </body>
></html>
>  
>
>------------------------------------------------------------------------
>
><?xml version="1.0"?>
><xsl:stylesheet version="1.0"
>  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>
><!--
><xsl:stylesheet version="1.0"
>  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>  xmlns:dyn="http://exslt.org/dynamic"
>  extension-element-prefixes="dyn">
>-->
>
><!--
>  Extract xml embedded in xhtml.
>  First draft.
>
>  Copyright 2005 Abramo Bagnara <abramo.bagnara@gmail.com>
>-->
>
><xsl:output method="xml"
>  indent="yes"/>
>
><xsl:variable name="prefix" select="' xx:'"/>
>
><!--
><xsl:template name="dyn-evaluate">
>  <xsl:param name="xpath"/>
>  <xsl:for-each select="dyn:evaluate($xpath)">
>    <xsl:value-of select="."/>
>  </xsl:for-each>
></xsl:template>
>-->
>
><xsl:template name="dyn-evaluate">
>  <xsl:param name="xpath"/>
>  <xsl:choose>
>    <xsl:when test="$xpath='.//text()'">
>      <xsl:for-each select=".//text()">
>        <xsl:value-of select="."/>
>      </xsl:for-each>
>    </xsl:when>
>    <xsl:when test="$xpath='text()'">
>      <xsl:for-each select="text()">
>        <xsl:value-of select="."/>
>      </xsl:for-each>
>    </xsl:when>
>    <xsl:when test="starts-with($xpath,'@')">
>      <xsl:value-of select="@*[name()=substring($xpath,2)]"/>
>    </xsl:when>
>    <xsl:otherwise>
>      <xsl:for-each select="*[name()=$xpath]">
>        <xsl:value-of select="."/>
>      </xsl:for-each>
>    </xsl:otherwise>
>  </xsl:choose>
></xsl:template>
>
><xsl:template name="evaluate">
>  <xsl:param name="xpath"/>
>  <xsl:if test="$xpath != ''">
>    <xsl:call-template name="dyn-evaluate">
>      <xsl:with-param name="xpath" select="$xpath"/>
>    </xsl:call-template>
>  </xsl:if>
></xsl:template>
>
><!--
>class : destination
>      | destination '=' source
>      ;
>
>prefix : 'xx:' ;
>
>destination : name
>            | '@' name
>            ;
>
>source : ''
>       | xpath
>       ;
>-->
>
><xsl:template name="extract">
>  <xsl:param name="classes"/>
>  <xsl:variable name="c" select="substring-after(concat(' ',$classes),$prefix)"/>
>  <xsl:choose>
>    <xsl:when test="$c = ''">
>      <xsl:apply-templates/>
>    </xsl:when>
>    <xsl:otherwise>
>      <xsl:variable name="class" select="substring-before(concat($c,' '),' ')"/>
>      <xsl:variable name="destination" select="substring-before(concat($class,'='),'=')"/>
>      <xsl:variable name="source">
>        <xsl:choose>
>          <xsl:when test="contains($class,'=')">
>            <xsl:value-of select="substring-after($class,'=')"/>
>          </xsl:when>
>          <xsl:otherwise>.//text()</xsl:otherwise>
>        </xsl:choose>
>      </xsl:variable>
>      <xsl:choose>
>        <xsl:when test="$destination = ''">
>          <xsl:call-template name="evaluate">
>            <xsl:with-param name="xpath" select="$source"/>
>          </xsl:call-template>
>          <xsl:call-template name="extract">
>            <xsl:with-param name="classes" select="substring-after($c,' ')"/>
>          </xsl:call-template>
>        </xsl:when>
>        <xsl:when test="starts-with($destination,'@')">
>          <xsl:attribute name="{substring($destination,2)}">
>            <xsl:call-template name="evaluate">
>              <xsl:with-param name="xpath" select="$source"/>
>            </xsl:call-template>
>          </xsl:attribute>
>          <xsl:call-template name="extract">
>            <xsl:with-param name="classes" select="substring-after($c,' ')"/>
>          </xsl:call-template>
>        </xsl:when>
>        <xsl:otherwise>
>          <xsl:element name="{$destination}">
>            <xsl:call-template name="evaluate">
>              <xsl:with-param name="xpath" select="$source"/>
>            </xsl:call-template>
>            <xsl:call-template name="extract">
>              <xsl:with-param name="classes" select="substring-after($c,' ')"/>
>            </xsl:call-template>
>          </xsl:element>
>        </xsl:otherwise>
>      </xsl:choose>
>    </xsl:otherwise>
>  </xsl:choose>
></xsl:template>
>
><xsl:template match="*[@class]">
>  <xsl:call-template name="extract">
>    <xsl:with-param name="classes" select="@class"/>
>  </xsl:call-template>
></xsl:template>
>
><xsl:template match="text()"/>
>
></xsl:stylesheet>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>  
>

From drernie at opendarwin.org  Fri Dec  2 09:21:50 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Fri Dec  2 09:21:52 2005
Subject: [uf-discuss] Microformat Base
In-Reply-To: <BFB510A2.64649%tantek@cs.stanford.edu>
References: <BFB510A2.64649%tantek@cs.stanford.edu>
Message-ID: <861567F9-CA9F-4554-ACBE-7119DD295DF3@opendarwin.org>

> On 12/1/05 8:23 PM, "Scott Reynen" <scott@randomchaos.com> wrote:
>
>> I thought I'd go ahead and play around with a microformat-based
>> alternative to Google Base.

Kudos, Scott!   The best revenge is a happy life, but second-best (or  
perhaps the first step to that) is working code. :-)

-- Ernie P.

On Dec 1, 2005, at 8:42 PM, Tantek ?elik wrote:

> On 12/1/05 8:23 PM, "Scott Reynen" <scott@randomchaos.com> wrote:
>
>> I thought I'd go ahead and play around with a microformat-based
>> alternative to Google Base.  So far, I have a basic spider that I set
>> loose from microformats.org to slowly wander the web.  When it finds
>> any known microformat-associated class names, it records the data
>> which can then be searched here:
>>
>> http://www.randomchaos.com/microformats/base/
>>
>> Or via URL like so:
>>
>> http://www.randomchaos.com/microformats/base/?key=fn&value=Tantek
>
> Uh, WOW.
>
> This is VERY cool.
>
>
>> It's currently only looking for hcard and hcalendar class names.
>
> Consider adding hReview as well!
>
>
>> The spider can be invoked on a site manually like so:
>>
>> http://www.randomchaos.com/microformats/base/spider/?url=http://
>> domain.com/path/to/microformat/
>>
>> All open source [1][2][3][4] if anyone wants to play with it.  It's
>> pretty basic right now, but I'd be interested in any feedback you all
>> have.
>
> Well done Scott.
>
> Definitely add it to the "Implementations" sections on the specs  
> for hCard
> and hCalendar and for sure on the implementations page
>
>  http://microformats.org/wiki/implementations
>
>> [1] http://www.randomchaos.com/source/?source=http%3A%2F%
>> 2Fwww.randomchaos.com%2Fmicroformats%2Fbase%2Fspider/index.php
>> [2] http://www.randomchaos.com/source/?source=http%3A%2F%
>> 2Fwww.randomchaos.com%2Fmicroformats%2Fbase%2Findex.php
>> [3] http://www.randomchaos.com/source/?source=http%3A%2F%
>> 2Fwww.randomchaos.com%2Fclass/mf_base_data.class.php
>> [4] http://www.randomchaos.com/source/?source=http%3A%2F%
>> 2Fwww.randomchaos.com%2Fclass/mf_base_source.class.php
>
> Definitely include those links too.
>
> Thanks,
>
> Tantek
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From ryan at ryancannon.com  Fri Dec  2 09:36:33 2005
From: ryan at ryancannon.com (Ryan Cannon)
Date: Fri Dec  2 09:36:43 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <20051202172154.0C238F08584@microformats>
References: <20051202172154.0C238F08584@microformats>
Message-ID: <3344191C-2D49-4269-8D24-581617AFBEC6@ryancannon.com>


> With that said rel-enclosure doesn't make a whole lot of sense. It  
> says
> "relEnclosure is one of several microformats. By adding  
> rel="enclosure" to
> a hyperlink, a page indicates that the destination of that  
> hyperlink is
> intended to be downloaded and cached."
>
> *Any* link indicates that the destination may be downloaded and  
> cached -
> that's the whole point of making a link. If it's not meant to be
> downloaded there wouldn't be a link, and if it wasn't meant to be  
> cached
> the HTTP header would tell me so (and my browser would handle it  
> without
> me caring).

This is interesting because the description really depends on  
audience. I agree with you: perhaps better language for rel-enclosure  
should be "By adding rel='enclosure' to a hyperlink, a page indicates  
that the destination of that hyperlink is not meant to be viewed by  
the client browser." However, this implies a more technical  
understanding of HTTP than the average person (or amateur web  
developer) has. For those people, "viewing" and "downloading" a file  
are very different. While the language should change, perhaps some  
language somewhere should reflect this difference in audience.

-- 
Ryan


From abramobagnara at tin.it  Fri Dec  2 09:41:56 2005
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri Dec  2 09:41:59 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <43907830.5080107@gmail.com>
References: <43902243.4080901@tin.it> <43907830.5080107@gmail.com>
Message-ID: <43908764.8060401@tin.it>

brian suda ha scritto:
> Just be careful not to re-invent the wheel. The W3C has a recommended[1]
> way to extract RDF from XHTML. This same idea can be applied for XML
> (and just about anything else for that matter).
> 
> [1] - http://www.w3.org/TeamSubmission/grddl/

GRDDL represents a way to specify an arbitrary transformation for an
xhtml page, my proposal is the description of a simple generic way to
embed arbitrary data inside an xhtml (like other microformats hCard,
hCalendar, etc.)

microformats are definitely orthogonal to grddl (and might also live
together happily)

As you can see in the example the format in my proposal is very similar
to hCalendar while allowing arbitrary representation.

I'm missing something?

-- 
Abramo Bagnara                       mailto:abramobagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
From solitude at solitude.dk  Fri Dec  2 09:45:37 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Fri Dec  2 09:45:45 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <3344191C-2D49-4269-8D24-581617AFBEC6@ryancannon.com>
References: <20051202172154.0C238F08584@microformats>
	<3344191C-2D49-4269-8D24-581617AFBEC6@ryancannon.com>
Message-ID: <op.s053mbasares2h@mail.solitude.dk>

On Fri, 02 Dec 2005 18:36:33 +0100, Ryan Cannon <ryan@ryancannon.com>  
wrote:

> This is interesting because the description really depends on audience.  
> I agree with you: perhaps better language for rel-enclosure should be  
> "By adding rel='enclosure' to a hyperlink, a page indicates that the  
> destination of that hyperlink is not meant to be viewed by the client  
> browser." However, this implies a more technical understanding of HTTP  
> than the average person (or amateur web developer) has. For those  
> people, "viewing" and "downloading" a file are very different. While the  
> language should change, perhaps some language somewhere should reflect  
> this difference in audience.

My issue with the language is secondary. The enclosure is an attachment to  
the document and the wording should reflect that. Staying to the e-mail  
metaphor it could be "By adding rel='enclosure' to a hyperlink, a page  
indicates that the destination of that hyperlink is an attachment to the  
current page".

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From ryan at technorati.com  Fri Dec  2 10:47:55 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Dec  2 10:47:58 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <43902243.4080901@tin.it>
References: <43902243.4080901@tin.it>
Message-ID: <EC9F6BA7-41B5-46F9-96CE-68E653257E00@technorati.com>

On Dec 2, 2005, at 2:30 AM, Abramo Bagnara wrote:

> Taken for granted that a microformat is a way to embed data inside  
> xhtml
> presentation, last night I was wondering if really it was  
> unavoidable to
> have so many different formats with complex rules and nasty  
> exceptions.

Whether or not its unavoidable to have "so many different formats"  
depends on what the goal is. In the case of hCard and hCalendar, we  
put up with the complexity of the existing formats so that we can  
create reasonable transformations between the two.

>> From this thinking I've tried to develop a little proposal to embed
> arbitrary xml data inside xhtml and that may be extracted easily and
> without ambiguities while leaving total freedom on data presentation.

Have you looked around to see who else has done this?

> My main interest was something similar to hcalendar to overcome  
> current
> limitations of this microformat wrt params.

Why not propose a fix to hcalendar, rather than starting from scratch?

> This is the reason why you find that the attached test is for calendar
> data, but my proposal should be general enough to permit embedding of
> *any* xml data.

Ok, you can certainly extract semantics this way, but I think there's  
a few shortcomings here:

1. without a shared vocabulary, what do you do with the data you get?
2. how do you deal with overlaid schemas? Those won't map reliably to  
xml.

> The attached stylesheet is for extraction of data in xml form, but it
> might be easily modified to extract data in xCalendar or iCalendar
> format (that maps 1:1 to xml).

Which xCalendar. I believe there's about 6 formats referred to as  
"xCalendar".

> -- 
> Abramo Bagnara                       mailto:abramobagnara@tin.it
>
> Opera Unica                          Phone: +39.0546.656023
> Via Emilia Interna, 140
> 48014 Castel Bolognese (RA) - Italy
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"  
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml">
>   <head>
>     <meta http-equiv="Content-Type" content="text/html;  
> charset=ISO-8859-1" />
>     <title>Test</title>
>     <link type="text/css" rel="stylesheet" href="../../html/ 
> project.css" />
>   </head>
>   <body class="xx:vcalendar=">
>     <div class="xx:vtodo=">
>       <h2 class="xx:summary">Task di test</h2>
>       <div>
>         <span class="header">Location: </span>
>         <span class="xx:location">Location</span>
>       </div>
>       <div>
>         <b>Due date: </b>
>         <abbr class="xx:due=@title" title="20051130">30-11-2005</abbr>
>       </div>
>       <div class="xx:description">
>         <div class="ancestor-summary">Test</div>
>         <ol class="disc">
>           <li>
>             <div class="node-summary">
>               <a href="edit:/u/dothert/data/abramo/ 
> test.txt##18">Task di test</a>
>             </div>
>             <div class="node-location">Location</div>
>             <div class="node-description">
>               <p>Descrizione sotto divisa in paragrafi di una certa  
> lunghezza di una
> certa lunghezza di una certa <b>lunghezza</b> di una certa  
> lunghezza di una
> certa lunghezza di una certa lunghezza</p>
>               <p>Descrizione sotto divisa in paragrafi di una certa  
> lunghezza di una
> certa lunghezza di una certa lunghezza di una certa lunghezza di una
> certa lunghezza di una certa lunghezza</p>
>               <p>Descrizione sotto divisa in paragrafi di una certa  
> lunghezza di una
> certa lunghezza di una certa lunghezza di una certa lunghezza di una
> certa lunghezza di una certa lunghezza</p>
>             </div>
>           </li>
>         </ol>
>         <p>Descrizione della deadline</p>
>         <p>Descrizione sotto divisa in paragrafi di una certa  
> lunghezza di una
> certa lunghezza di una certa lunghezza di una certa lunghezza di una
> certa lunghezza di una certa lunghezza</p>
>         <p>Descrizione sotto divisa in paragrafi di una certa  
> lunghezza di una
> certa lunghezza di una certa lunghezza di una certa lunghezza di una
> certa lunghezza di una certa lunghezza</p>
>       </div>
>       <div><span class="header">Categories: </span><span  
> class="xx:categories">a</span>, <span class="xx:categories">a:b</ 
> span>, <span class="xx:categories">a:b:c</span>, <span  
> class="xx:categories">ismaele</span>, <span  
> class="xx:categories">ismaele:opt</span>, <span  
> class="xx:categories">licia</span>, <span  
> class="xx:categories">licia:opt</span>, <span  
> class="xx:categories">abramo</span>, <span  
> class="xx:categories">abramo:cha</span>, <span  
> class="xx:categories">test</span>, <span  
> class="xx:categories">abramo</span></div>
>       <div>
>         <span class="header">Priority: </span>
>         <abbr class="xx:priority=@title" title="0">not specified</ 
> abbr>
>       </div>
>       <div>
>         <span class="header">Presidente: </span>
>         <span class="xx:attendee=">
>           <abbr class="xx:@role=@title" title="chair"></abbr>
>           <a class="xx:@cn xx:=@href"  
> href="mailto:abramo.bagnara@gmail.com">Abramo Bagnara</a>
>         </span>
>       </div>
>       <div>
> 	<span class="header">Partecipanti opzionali: </span>
> 	<span class="xx:attendee=">
> 	  <abbr class="xx:@role=@title" title="opt-participant"></abbr>
>           <a class="xx:@cn xx:=@href" href="mailto:">Ismaele  
> Bagnara</a>
>         </span>, <span class="xx:attendee="><abbr  
> class="xx:@role=@title"
> 	title="opt-participant"></abbr>
>       <a class="xx:@cn xx:=@href"  
> href="litabanelli@racine.ra.it">Licia Tabanelli</a></span></div>
>     </div>
>   </body>
> </html>
> <?xml version="1.0"?>
> <xsl:stylesheet version="1.0"
>   xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>
> <!--
> <xsl:stylesheet version="1.0"
>   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>   xmlns:dyn="http://exslt.org/dynamic"
>   extension-element-prefixes="dyn">
> -->
>
> <!--
>   Extract xml embedded in xhtml.
>   First draft.
>
>   Copyright 2005 Abramo Bagnara <abramo.bagnara@gmail.com>
> -->
>
> <xsl:output method="xml"
>   indent="yes"/>
>
> <xsl:variable name="prefix" select="' xx:'"/>
>
> <!--
> <xsl:template name="dyn-evaluate">
>   <xsl:param name="xpath"/>
>   <xsl:for-each select="dyn:evaluate($xpath)">
>     <xsl:value-of select="."/>
>   </xsl:for-each>
> </xsl:template>
> -->
>
> <xsl:template name="dyn-evaluate">
>   <xsl:param name="xpath"/>
>   <xsl:choose>
>     <xsl:when test="$xpath='.//text()'">
>       <xsl:for-each select=".//text()">
>         <xsl:value-of select="."/>
>       </xsl:for-each>
>     </xsl:when>
>     <xsl:when test="$xpath='text()'">
>       <xsl:for-each select="text()">
>         <xsl:value-of select="."/>
>       </xsl:for-each>
>     </xsl:when>
>     <xsl:when test="starts-with($xpath,'@')">
>       <xsl:value-of select="@*[name()=substring($xpath,2)]"/>
>     </xsl:when>
>     <xsl:otherwise>
>       <xsl:for-each select="*[name()=$xpath]">
>         <xsl:value-of select="."/>
>       </xsl:for-each>
>     </xsl:otherwise>
>   </xsl:choose>
> </xsl:template>
>
> <xsl:template name="evaluate">
>   <xsl:param name="xpath"/>
>   <xsl:if test="$xpath != ''">
>     <xsl:call-template name="dyn-evaluate">
>       <xsl:with-param name="xpath" select="$xpath"/>
>     </xsl:call-template>
>   </xsl:if>
> </xsl:template>
>
> <!--
> class : destination
>       | destination '=' source
>       ;
>
> prefix : 'xx:' ;
>
> destination : name
>             | '@' name
>             ;
>
> source : ''
>        | xpath
>        ;
> -->
>
> <xsl:template name="extract">
>   <xsl:param name="classes"/>
>   <xsl:variable name="c" select="substring-after(concat(' ', 
> $classes),$prefix)"/>
>   <xsl:choose>
>     <xsl:when test="$c = ''">
>       <xsl:apply-templates/>
>     </xsl:when>
>     <xsl:otherwise>
>       <xsl:variable name="class" select="substring-before(concat 
> ($c,' '),' ')"/>
>       <xsl:variable name="destination" select="substring-before 
> (concat($class,'='),'=')"/>
>       <xsl:variable name="source">
>         <xsl:choose>
>           <xsl:when test="contains($class,'=')">
>             <xsl:value-of select="substring-after($class,'=')"/>
>           </xsl:when>
>           <xsl:otherwise>.//text()</xsl:otherwise>
>         </xsl:choose>
>       </xsl:variable>
>       <xsl:choose>
>         <xsl:when test="$destination = ''">
>           <xsl:call-template name="evaluate">
>             <xsl:with-param name="xpath" select="$source"/>
>           </xsl:call-template>
>           <xsl:call-template name="extract">
>             <xsl:with-param name="classes" select="substring-after 
> ($c,' ')"/>
>           </xsl:call-template>
>         </xsl:when>
>         <xsl:when test="starts-with($destination,'@')">
>           <xsl:attribute name="{substring($destination,2)}">
>             <xsl:call-template name="evaluate">
>               <xsl:with-param name="xpath" select="$source"/>
>             </xsl:call-template>
>           </xsl:attribute>
>           <xsl:call-template name="extract">
>             <xsl:with-param name="classes" select="substring-after 
> ($c,' ')"/>
>           </xsl:call-template>
>         </xsl:when>
>         <xsl:otherwise>
>           <xsl:element name="{$destination}">
>             <xsl:call-template name="evaluate">
>               <xsl:with-param name="xpath" select="$source"/>
>             </xsl:call-template>
>             <xsl:call-template name="extract">
>               <xsl:with-param name="classes" select="substring-after 
> ($c,' ')"/>
>             </xsl:call-template>
>           </xsl:element>
>         </xsl:otherwise>
>       </xsl:choose>
>     </xsl:otherwise>
>   </xsl:choose>
> </xsl:template>
>
> <xsl:template match="*[@class]">
>   <xsl:call-template name="extract">
>     <xsl:with-param name="classes" select="@class"/>
>   </xsl:call-template>
> </xsl:template>
>
> <xsl:template match="text()"/>
>
> </xsl:stylesheet>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Fri Dec  2 10:53:11 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Dec  2 10:53:13 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <43908764.8060401@tin.it>
References: <43902243.4080901@tin.it> <43907830.5080107@gmail.com>
	<43908764.8060401@tin.it>
Message-ID: <B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>

On Dec 2, 2005, at 9:41 AM, Abramo Bagnara wrote:

> brian suda ha scritto:
>> Just be careful not to re-invent the wheel. The W3C has a  
>> recommended[1]
>> way to extract RDF from XHTML. This same idea can be applied for XML
>> (and just about anything else for that matter).
>>
>> [1] - http://www.w3.org/TeamSubmission/grddl/
>
> GRDDL represents a way to specify an arbitrary transformation for an
> xhtml page, my proposal is the description of a simple generic way to
> embed arbitrary data inside an xhtml (like other microformats hCard,
> hCalendar, etc.)
>
> microformats are definitely orthogonal to grddl (and might also live
> together happily)

They already do. Please read the archives and wiki.

> As you can see in the example the format in my proposal is very  
> similar
> to hCalendar while allowing arbitrary representation.
>
> I'm missing something?

I think you're missing the part where many of us believe that  
"arbitrary representation" is desirable. You've recreated the Tower  
of Babel problem in xhtml [http://tantek.com/log/ 
2005/07.html#towerofbabelproblem].

-ryan

--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Fri Dec  2 10:56:40 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Dec  2 10:56:42 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <op.s05ltrzjares2h@mail.solitude.dk>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
Message-ID: <CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>

On Dec 2, 2005, at 3:21 AM, Andreas Haugstrup wrote:
> On Fri, 02 Dec 2005 02:39:54 +0100, Ryan King <ryan@technorati.com>  
> wrote:
>
>>> Now that hAtom is as far as it is I need to ditch key parts of my  
>>> example and convert to hAtom which is more thorough (albeit  
>>> missing parts I use internally like rel="enclosure" and rel="cite").
>>
>> Though http://microformats.org/wiki/rel-enclosure doesn't have a  
>> profile URI, there's no need to replicate that into hAtom, you can  
>> just use rel-enclosure.
>
> I've been using rel="enclosure" longer than the rel-enclosure  
> document has been around, and that's why it's in my example. I use  
> it to generate (Yahoo Media) enclosures in my RSS feed. And along  
> with rel="cite" I use it to generate a list of enclosures and  
> citations on my archive pages (e.g. http://www.solitude.dk/archives/ 
> 2005_11.php ).
>
> With that said rel-enclosure doesn't make a whole lot of sense. It  
> says "relEnclosure is one of several microformats. By adding  
> rel="enclosure" to a hyperlink, a page indicates that the  
> destination of that hyperlink is intended to be downloaded and  
> cached."

Perhaps the language isn't entirely clear here. I think Kevin's  
intention was along the lines of "the destination is meant to be  
downloaded can cached by the useragent." Kevin?

> *Any* link indicates that the destination may be downloaded and  
> cached - that's the whole point of making a link. If it's not meant  
> to be downloaded there wouldn't be a link, and if it wasn't meant  
> to be cached the HTTP header would tell me so (and my browser would  
> handle it without me caring).
>
> Enclosures have a different meaning. They are best compared to  
> attachments in e-mail. The enclosure is a part of the current  
> document and document+enclosure(s) should be seen as a whole. This  
> has great value when talking about blog posts (and hAtom) because  
> attachments are usually connected to a part of the page (a single  
> blog entry).
>
> I don't care where I point my profiles to, but rel-enclosure isn't  
> what I mean when I use rel="enclosure".

I don't think your relEnclosure and http://microformats.org/wiki/rel- 
enclosure are that different, they're just explained differently.  
Also, I think they're close enough to be resolved. You want to work  
on that?

-ryan
--
Ryan King
ryan@technorati.com



From abramobagnara at tin.it  Fri Dec  2 11:39:45 2005
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri Dec  2 11:39:49 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>
References: <43902243.4080901@tin.it>
	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>
	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>
Message-ID: <4390A301.90508@tin.it>

Ryan King ha scritto:
> On Dec 2, 2005, at 9:41 AM, Abramo Bagnara wrote:
> 
> 
>> As you can see in the example the format in my proposal is very  similar
>> to hCalendar while allowing arbitrary representation.
>>
>> I'm missing something?
> 
> 
> I think you're missing the part where many of us believe that 
> "arbitrary representation" is desirable. You've recreated the Tower  of
> Babel problem in xhtml [http://tantek.com/log/
> 2005/07.html#towerofbabelproblem].

I've read that, I don't see how it's pertinent: no tags and/or
attributes are created.

Indeed my proposal is simply a simplification/generalization of
hCalendar and hCard using a very similar approach, but allowing to
specify in a simple way source and destination of data.

The benefits I see wrt current hCalendar are:
- generality
- simplicity and readability (without have to know the complex rules of
hCalendar describing where the data might be located)
- no overlapping with class name in use by consolidated css

> Why not propose a fix to hcalendar, rather than starting from scratch?

My proposal is exactly oriented toward this, to improve current
hCalendar (as you can see the similarity between the two are much many
than the differences...)

I've never thought to start from scratch, I've started copying
hcalendar, analyzing its current shortcomings and I've humbly proposed a
solution (standing on the giant's shoulder...)

I feel a subtle hostility wrt this improvement attempt, I'm wrong?

-- 
Abramo Bagnara                       mailto:abramobagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
From ryan at technorati.com  Fri Dec  2 12:04:28 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Dec  2 12:04:31 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390A301.90508@tin.it>
References: <43902243.4080901@tin.it>
	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>
	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>
	<4390A301.90508@tin.it>
Message-ID: <E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>

On Dec 2, 2005, at 11:39 AM, Abramo Bagnara wrote:

> Ryan King ha scritto:
>> I think you're missing the part where many of us believe that
>> "arbitrary representation" is desirable. You've recreated the  
>> Tower  of
>> Babel problem in xhtml [http://tantek.com/log/
>> 2005/07.html#towerofbabelproblem].
>
> I've read that, I don't see how it's pertinent: no tags and/or
> attributes are created.

I was just trying to make the point that allowing arbitrary xml  
embedding doesn't solve any semantics problems, just creates new ones.

> Indeed my proposal is simply a simplification/generalization of
> hCalendar and hCard using a very similar approach, but allowing to
> specify in a simple way source and destination of data.
>
> The benefits I see wrt current hCalendar are:
> - generality

This may be in opposition to the way we develop ?F's. As the first ?F  
principle states: "solved a specific problem."

> - simplicity and readability (without have to know the complex  
> rules of
> hCalendar describing where the data might be located)

IMHO, your rendition is no easier to read than hcalendar. Of course,  
I'm very familiar with hcalendar, so I may be biased.

> - no overlapping with class name in use by consolidated css

True. However, you do realize that using colons in class names will  
not work well with css (with current useragents, at least, I'm not  
sure exactly where the spec is on this)?

>> Why not propose a fix to hcalendar, rather than starting from  
>> scratch?
>
> My proposal is exactly oriented toward this, to improve current
> hCalendar (as you can see the similarity between the two are much many
> than the differences...)

It just seemed that you'd thrown out more than neccesary. Your stated  
objective was to fixed the cases of encoding iCalendar parameters in  
hcalendar (I think. I'm honestly not sure what part of the format  
you're trying to fix.). Why not just focus on that part of the format?

> I've never thought to start from scratch, I've started copying
> hcalendar, analyzing its current shortcomings and I've humbly  
> proposed a
> solution (standing on the giant's shoulder...)
>
> I feel a subtle hostility wrt this improvement attempt, I'm wrong?

Just disagreement.

-ryan
--
Ryan King
ryan@technorati.com



From scott at randomchaos.com  Fri Dec  2 12:14:15 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Fri Dec  2 12:14:33 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390A301.90508@tin.it>
References: <43902243.4080901@tin.it>
	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>
	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>
	<4390A301.90508@tin.it>
Message-ID: <6F18CEBD-93BA-43FD-9B07-DEBC110BDE1E@randomchaos.com>

Abramo Bagnara wrote:

> I feel a subtle hostility wrt this improvement attempt, I'm wrong?

I suspect many here are tired of fending off attempt after attempt at  
generalization, as such attempts tend to come at a cost of simplicity  
(and therefor adoption).

Less than a month ago [1], Tantek wrote:

>   microformats are not:
>     * infinitely extensible and open-ended
>     * a panacea for all taxonomies, ontologies, and other such  
> abstractions
>     * defining the whole world, or even just boiling the ocean
>
> So yes, such "general purpose" or "universality" is an explicit NON- 
> goal.

You can read through the archives for a few dozen explanations of  
this perspective.

Peace,
Scott

[1] http://microformats.org/discuss/mail/microformats-discuss/2005- 
November/001904.html
From kennyheaton at gmail.com  Fri Dec  2 13:06:12 2005
From: kennyheaton at gmail.com (kenny heaton)
Date: Fri Dec  2 13:06:13 2005
Subject: [uf-discuss] XOXO, the 'compact' attribute is deprecated
Message-ID: <65b4e01f0512021306p763c9enb60eecacb8817e5e@mail.gmail.com>

Hi,

I am new to microformats, but excited about them and eager to learn
and start using them. But as I was reading over the XOXO format, it
uses the attribute compact witch was a part of the HTML specification
but is deprecated. Is this something that has been discussed elsewhere
and is there a reason for including a deprecated attribute in the XOXO
format? I personally would think it better not to use any deprecated
elements.

Kenny
From abramobagnara at tin.it  Fri Dec  2 13:54:07 2005
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri Dec  2 13:54:09 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>
	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>
Message-ID: <4390C27F.1000402@tin.it>

Ryan King ha scritto:
> On Dec 2, 2005, at 11:39 AM, Abramo Bagnara wrote:
> 
>> The benefits I see wrt current hCalendar are:
>> - generality
> 
> 
> This may be in opposition to the way we develop ?F's. As the first ?F 
> principle states: "solved a specific problem."

I'd add: "better if *this* specific problem is solved in a general way,
without complex policies and hairy details".

>> - simplicity and readability (without have to know the complex  rules of
>> hCalendar describing where the data might be located)
> 
> 
> IMHO, your rendition is no easier to read than hcalendar. Of course, 
> I'm very familiar with hcalendar, so I may be biased.

I find very hard to remember which attributes and in which prioritary
order are attempted to find the field content. In my proposal this is
explicit and also permits to avoid the @headers mess extending its
benefits to non tables (like in CSS oriented tables).

> 
>> - no overlapping with class name in use by consolidated css
> 
> 
> True. However, you do realize that using colons in class names will  not
> work well with css (with current useragents, at least, I'm not  sure
> exactly where the spec is on this)?

Good point: .xx:hover is indistinct from .xx:dtstart

What about to choose a $prefix different from "xx:"?

Can we reach an agreement that to use a "namespace" for microformats
specific classes is a good thing?

>>> Why not propose a fix to hcalendar, rather than starting from  scratch?
>>
>>
>> My proposal is exactly oriented toward this, to improve current
>> hCalendar (as you can see the similarity between the two are much many
>> than the differences...)
> 
> 
> It just seemed that you'd thrown out more than neccesary. Your stated 
> objective was to fixed the cases of encoding iCalendar parameters in 
> hcalendar (I think. I'm honestly not sure what part of the format 
> you're trying to fix.). Why not just focus on that part of the format?

See the rationale above.

I'd like you realize how many layout limitations impose current
hCalendar way.

I'll do a specific example, one of that I've found trying to add
hCalendar tagging to my application output.

Suppose that I want to group attendees by role.
With hCalendar I'm forced to this abbr abuse:

<div>
<span class="header">Optional partecipants: </span>
<span class="attendee">
  <abbr class="role" title="opt-participant"></abbr>
  <a class="cn" href="mailto:abramobagnara@tin.it">Abramo Bagnara</a>
</span>,
<span class="attendee">
  <abbr class="role" title="opt-participant"></abbr>
  <a class="cn" href="litabanelli@racine.ra.it">Licia Tabanelli</a>
</span>
</div

while with my proposal I can do the following:

<div>
<span class="header">
<abbr title="opt-participant">Optional partecipants</abbr>
</span>:
<span class="xx:attendee= xx:@role=../abbr/@title">
  <a class="xx:@cn xx:=@href" href="mailto:abramobagnara@tin.it">Abramo
Bagnara</a>
</span>,
<span class="xx:attendee= xx:@role=../abbr/@title">
  <a class="xx:@cn xx:=@href" href="litabanelli@racine.ra.it">Licia
Tabanelli</a>
</span>
</div>

So leaving the needed layout freedom to web page designer.

-- 
Abramo Bagnara                       mailto:abramobagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
From drernie at opendarwin.org  Fri Dec  2 14:19:12 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Fri Dec  2 14:19:15 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390C27F.1000402@tin.it>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>
	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>
	<4390C27F.1000402@tin.it>
Message-ID: <C267EAEB-4228-4EED-B7E2-743B722ABFD1@opendarwin.org>

Hi Abramo,

On Dec 2, 2005, at 1:54 PM, Abramo Bagnara wrote:
> Can we reach an agreement that to use a "namespace" for microformats
> specific classes is a good thing?

That is an interesting question.  I know that Rohit has been asking  
that same question.  The conventional answer is that microformat  
classes *are* in fact the same classes you'd be using for normal CSS  
styling, so there's no need to call them out -- and besides,  
namespaces tend to confuse mere mortals.

Is that the right answer?  I don't know.  I haven't yet heard a fully  
convincing counter-argument, but there may be one.

To your example:

> With hCalendar I'm forced to this abbr abuse:

> <div>
> <span class="header">Optional partecipants: </span>
> <span class="attendee">
>   <abbr class="role" title="opt-participant"></abbr>
>   <a class="cn" href="mailto:abramobagnara@tin.it">Abramo Bagnara</a>
> </span>,
> <span class="attendee">
>   <abbr class="role" title="opt-participant"></abbr>
>   <a class="cn" href="litabanelli@racine.ra.it">Licia Tabanelli</a>
> </span>
> </div
>
> while with my proposal I can do the following:
>
> <div>
> <span class="header">
> <abbr title="opt-participant">Optional partecipants</abbr>
> </span>:
> <span class="xx:attendee= xx:@role=../abbr/@title">
>   <a class="xx:@cn xx:=@href"  
> href="mailto:abramobagnara@tin.it">Abramo
> Bagnara</a>
> </span>,
> <span class="xx:attendee= xx:@role=../abbr/@title">
>   <a class="xx:@cn xx:=@href" href="litabanelli@racine.ra.it">Licia
> Tabanelli</a>
> </span>
> </div>

Forgive me if I'm a little slow, but I'm unclear about i) where the  
problem is, and ii) how your version is any clearer. That use of  
'title' and 'abbr' seems exceedingly odd.  Why can't hCalendar  
already just do:

<div>
<h2><abbr class="role" title="opt-participant">Optional participants</ 
abbr></h2>:
<a class="attendee cn url" href="mailto:abramobagnara@tin.it">Abramo  
Bagnara</a>
<a class="attendee cn url" href="litabanelli@racine.ra.it"> Licia  
Tabanelli </a>
</div>

Am I completely misunderstanding how role and opt-participant are  
supposed to be used?  Is the problem that hCalendar wants 'opt- 
participant' to be a visible key with class 'role' rather than  
invisible one?

-- Ernie P.


From abramobagnara at tin.it  Fri Dec  2 13:18:10 2005
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri Dec  2 14:28:06 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <6F18CEBD-93BA-43FD-9B07-DEBC110BDE1E@randomchaos.com>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>
	<6F18CEBD-93BA-43FD-9B07-DEBC110BDE1E@randomchaos.com>
Message-ID: <4390BA12.70707@tin.it>

Scott Reynen ha scritto:
> Abramo Bagnara wrote:
> 
>> I feel a subtle hostility wrt this improvement attempt, I'm wrong?
> 
> 
> I suspect many here are tired of fending off attempt after attempt at 
> generalization, as such attempts tend to come at a cost of simplicity 
> (and therefor adoption).

About simplicity I guess that a rather reliable way to measure it is to
compare stylesheet needed for data extraction.

> Less than a month ago [1], Tantek wrote:
> 
>>   microformats are not:
>>     * infinitely extensible and open-ended
>>     * a panacea for all taxonomies, ontologies, and other such 
>> abstractions
>>     * defining the whole world, or even just boiling the ocean
>>
>> So yes, such "general purpose" or "universality" is an explicit NON-
>> goal.
> 
> 
> You can read through the archives for a few dozen explanations of  this
> perspective.

I think that "general purpose" and "universality" sacrificing simplicity
is a bad thing, but can we agree that universality *with* simplicity is
a benefit?

-- 
Abramo Bagnara                       mailto:abramobagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
From ryan at technorati.com  Fri Dec  2 14:35:45 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Dec  2 14:35:49 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390C27F.1000402@tin.it>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>
	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>
	<4390C27F.1000402@tin.it>
Message-ID: <0076F04E-EE46-43AF-A509-BF96A279B517@technorati.com>

On Dec 2, 2005, at 1:54 PM, Abramo Bagnara wrote:

> Ryan King ha scritto:
>> On Dec 2, 2005, at 11:39 AM, Abramo Bagnara wrote:
>>
>>> The benefits I see wrt current hCalendar are:
>>> - generality
>>
>> This may be in opposition to the way we develop ?F's. As the first ?F
>> principle states: "solved a specific problem."
>
> I'd add: "better if *this* specific problem is solved in a general  
> way,
> without complex policies and hairy details".
>
>>> - simplicity and readability (without have to know the complex   
>>> rules of
>>> hCalendar describing where the data might be located)
>>
>>
>> IMHO, your rendition is no easier to read than hcalendar. Of course,
>> I'm very familiar with hcalendar, so I may be biased.
>
> I find very hard to remember which attributes and in which prioritary
> order are attempted to find the field content. In my proposal this is
> explicit and also permits to avoid the @headers mess extending its
> benefits to non tables (like in CSS oriented tables).
>>> - no overlapping with class name in use by consolidated css
>>
>> True. However, you do realize that using colons in class names  
>> will  not
>> work well with css (with current useragents, at least, I'm not  sure
>> exactly where the spec is on this)?
>
> Good point: .xx:hover is indistinct from .xx:dtstart

yup.

> What about to choose a $prefix different from "xx:"?
>
> Can we reach an agreement that to use a "namespace" for microformats
> specific classes is a good thing?

Be careful, you might want to read the archives here.

>>>> Why not propose a fix to hcalendar, rather than starting from   
>>>> scratch?
>>>
>>> My proposal is exactly oriented toward this, to improve current
>>> hCalendar (as you can see the similarity between the two are much  
>>> many
>>> than the differences...)
>>
>> It just seemed that you'd thrown out more than neccesary. Your stated
>> objective was to fixed the cases of encoding iCalendar parameters in
>> hcalendar (I think. I'm honestly not sure what part of the format
>> you're trying to fix.). Why not just focus on that part of the  
>> format?
>
> See the rationale above.
>
> I'd like you realize how many layout limitations impose current
> hCalendar way.

By layout, do you mean styling? Or markup? Because its not clear from  
your examples.

> I'll do a specific example, one of that I've found trying to add
> hCalendar tagging to my application output.
>
> Suppose that I want to group attendees by role.
> With hCalendar I'm forced to this abbr abuse:
>
> <div>
> <span class="header">Optional partecipants: </span>

Not to nitpick, but it'd be helpful if you didn't reinvent <h*>.

> <span class="attendee">
>   <abbr class="role" title="opt-participant"></abbr>

Ok, so you've found a place where its hard to follow the DRY principle.

>   <a class="cn" href="mailto:abramobagnara@tin.it">Abramo Bagnara</a>
> </span>,
> <span class="attendee">
>   <abbr class="role" title="opt-participant"></abbr>
>   <a class="cn" href="litabanelli@racine.ra.it">Licia Tabanelli</a>
> </span>
> </div
>
> while with my proposal I can do the following:
>
> <div>
> <span class="header">
> <abbr title="opt-participant">Optional partecipants</abbr>
> </span>:
> <span class="xx:attendee= xx:@role=../abbr/@title">
>   <a class="xx:@cn xx:=@href"  
> href="mailto:abramobagnara@tin.it">Abramo
> Bagnara</a>

Do you realize the tradeoff you make here? You can't write a CSS  
selector to style on "xx:attendee= xx:@role=../abbr/@title". This is  
a deal breaker for microformats. If you really want to reference  
another HTML element, why not use something more HTMLish, like and  
<object>?

> </span>,
> <span class="xx:attendee= xx:@role=../abbr/@title">
>   <a class="xx:@cn xx:=@href" href="litabanelli@racine.ra.it">Licia
> Tabanelli</a>
> </span>
> </div>
>
> So leaving the needed layout freedom to web page designer.

Per my point above, you leave more markup freedom, but eliminate  
[CSS] styling freedom. A big negative in my book.

-ryan

--
Ryan King
ryan@technorati.com



From drernie at opendarwin.org  Fri Dec  2 14:38:21 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Fri Dec  2 14:38:21 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390BA12.70707@tin.it>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>
	<6F18CEBD-93BA-43FD-9B07-DEBC110BDE1E@randomchaos.com>
	<4390BA12.70707@tin.it>
Message-ID: <8E8875D9-3127-4B4E-8D4C-2817002AFC9C@opendarwin.org>

Hi Abramo,

On Dec 2, 2005, at 1:18 PM, Abramo Bagnara wrote:
> I think that "general purpose" and "universality" sacrificing  
> simplicity
> is a bad thing, but can we agree that universality *with*  
> simplicity is
> a benefit?

I think the challenge has always been "simplicity for whom."  I think  
many of us would agree that generality has *some* value, but (in our  
experience) i) universality is too ambitious a goal, and ii) even  
generality comes at *some* price.  For example, making things simpler  
for parsers often makes it a little harder for humans, which (around  
here) is considered evil. :-)

If you can come up with something that is more general, but just as  
simple for *everyone* involved, I'm sure at least a few of us on the  
list would be willing to hear it (though we'd obviously be skeptical  
at first :-).

Best,
Ernie P.

From scott at randomchaos.com  Fri Dec  2 14:49:09 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Fri Dec  2 14:49:16 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <C267EAEB-4228-4EED-B7E2-743B722ABFD1@opendarwin.org>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>
	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>
	<4390C27F.1000402@tin.it>
	<C267EAEB-4228-4EED-B7E2-743B722ABFD1@opendarwin.org>
Message-ID: <FF5FA171-685A-4DAF-82CC-3D2F01D2082C@randomchaos.com>

Dr. Ernie Prabhakar wrote:

> Forgive me if I'm a little slow, but I'm unclear about i) where the  
> problem is, and ii) how your version is any clearer. That use of  
> 'title' and 'abbr' seems exceedingly odd.  Why can't hCalendar  
> already just do:
>
> <div>
> <h2><abbr class="role" title="opt-participant">Optional  
> participants</abbr></h2>:
> <a class="attendee cn url"  
> href="mailto:abramobagnara@tin.it">Abramo Bagnara</a>
> <a class="attendee cn url" href="litabanelli@racine.ra.it"> Licia  
> Tabanelli </a>
> </div>

Maybe I'm wrong, but it looks to me like role must be within the  
attendee it is describing, and Abramo is attempting to remove this  
requirement by cramming XPath-style selectors into class attributes.   
Defining relationships via XPath removes the need for hierarchy in  
HTML.  That may or may not be a worthwhile goal, but it breaks about  
a dozen microformat principles from the about page [1].  Interesting  
idea, but probably not suitable for microformats.

Peace,
Scott

[1] http://microformats.org/about/
From abramobagnara at tin.it  Fri Dec  2 14:50:49 2005
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri Dec  2 14:50:49 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <C267EAEB-4228-4EED-B7E2-743B722ABFD1@opendarwin.org>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>	<4390C27F.1000402@tin.it>
	<C267EAEB-4228-4EED-B7E2-743B722ABFD1@opendarwin.org>
Message-ID: <4390CFC9.2040801@tin.it>

Dr. Ernie Prabhakar ha scritto:

>> Can we reach an agreement that to use a "namespace" for microformats
>> specific classes is a good thing?
> 
> 
> That is an interesting question.  I know that Rohit has been asking 
> that same question.  The conventional answer is that microformat 
> classes *are* in fact the same classes you'd be using for normal CSS 
> styling, so there's no need to call them out -- and besides,  namespaces
> tend to confuse mere mortals.

I've deliberately quoted "namespace": a simple prefix is enough.

As an example consider that a web page might already use class
"description" for its own purpose. Suppose now that he'd like to add
hCalendar encapsulation: how he can easily represent differently the
hCalendar content and the others?

He has some alternative:

1) don't use the "description" class outside hCalendar data (??? to use
hCalendar means to be forced to not use any rfc2445 names as class name?)

2) use selectors like:
.vevent .description { }

but what about if .vevent area is rather large and inside that he
already use some classes clashing with rfc2445? And what about if vevent
internal data is stored outside .vevent area?

Consider also that to have a "namespace" does not inhibits the web
designer to use the same microformat classes for normal CSS as you write.

>> while with my proposal I can do the following:
>>
>> <div>
>> <span class="header">
>> <abbr title="opt-participant">Optional partecipants</abbr>
>> </span>:
>> <span class="xx:attendee= xx:@role=../abbr/@title">
>>   <a class="xx:@cn xx:=@href"  href="mailto:abramobagnara@tin.it">Abramo
>> Bagnara</a>
>> </span>,
>> <span class="xx:attendee= xx:@role=../abbr/@title">
>>   <a class="xx:@cn xx:=@href" href="litabanelli@racine.ra.it">Licia
>> Tabanelli</a>
>> </span>
>> </div>
> 
> 
> Forgive me if I'm a little slow, but I'm unclear about i) where the 
> problem is, and ii) how your version is any clearer. That use of 
> 'title' and 'abbr' seems exceedingly odd.  Why can't hCalendar  already
> just do:
> 
> <div>
> <h2><abbr class="role" title="opt-participant">Optional participants</
> abbr></h2>:
> <a class="attendee cn url" href="mailto:abramobagnara@tin.it">Abramo 
> Bagnara</a>
> <a class="attendee cn url" href="litabanelli@racine.ra.it"> Licia 
> Tabanelli </a>
> </div>
> 
> Am I completely misunderstanding how role and opt-participant are 
> supposed to be used?  Is the problem that hCalendar wants 'opt-
> participant' to be a visible key with class 'role' rather than 
> invisible one?

You should only solve the problem of how to instruct stylesheet about
*where* it can find the role param value in xhtml page... And then you
should be sure that with this policy you're not excluding *any* sensible
layout.

You've an hard work, my friend... :-)

-- 
Abramo Bagnara                       mailto:abramobagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
From drernie at opendarwin.org  Fri Dec  2 14:59:59 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Fri Dec  2 15:00:03 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390CFC9.2040801@tin.it>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>	<4390C27F.1000402@tin.it>
	<C267EAEB-4228-4EED-B7E2-743B722ABFD1@opendarwin.org>
	<4390CFC9.2040801@tin.it>
Message-ID: <ADF22446-8165-4B18-959F-79CBC56AE06F@opendarwin.org>

Hi Abramo,

On Dec 2, 2005, at 2:50 PM, Abramo Bagnara wrote:

> Dr. Ernie Prabhakar ha scritto:
>> That is an interesting question.  I know that Rohit has been asking
>> that same question.  The conventional answer is that microformat
>> classes *are* in fact the same classes you'd be using for normal CSS
>> styling, so there's no need to call them out -- and besides,   
>> namespaces
>> tend to confuse mere mortals.
>
> I've deliberately quoted "namespace": a simple prefix is enough.

Believe me, I understand.  Still, even telling people to do "@name"  
or "-description" is a little odd.

> As an example consider that a web page might already use class
> "description" for its own purpose. Suppose now that he'd like to add
> hCalendar encapsulation: how he can easily represent differently the
> hCalendar content and the others?
>
> He has some alternative:
>
> 1) don't use the "description" class outside hCalendar data (??? to  
> use
> hCalendar means to be forced to not use any rfc2445 names as class  
> name?)
>
> 2) use selectors like:
> .vevent .description { }

The microformat recommendation would clearly be the latter.

> but what about if .vevent area is rather large and inside that he
> already use some classes clashing with rfc2445? And what about if  
> vevent
> internal data is stored outside .vevent area?

This is one of those hypotheticals that we'd love to see a concrete  
use case to justify.  The general microformat rule is to NOT pollute  
the 80% case merely to make the corner cases possible, which I think  
is a rational approach.

> You should only solve the problem of how to instruct stylesheet about
> *where* it can find the role param value in xhtml page... And then you
> should be sure that with this policy you're not excluding *any*  
> sensible
> layout.
>
> You've an hard work, my friend... :-)

Au contraire -- as already noted, *we* are _not_ trying to solve the  
most general case of "any sensible layout", for that very  
reason. :-)  If people have unique needs that aren't solved by a  
general-purpose microformat, then we wish them well but don't feel  
compelled to convert them to our camp.

Now, it *is* certainly possible that an existing definition doesn't  
pass the 80% test, and in fact 40%+ of common uses require something  
different than what we are doing.  But that's why we stress prior  
research before forming a microformat, to ensure we cover the bulk of  
the target audience.   Yes, that means we leave other potential usage  
patterns on the table; if you think you're smart enough to figure out  
a general-purpose solution that will be broadly adopted, by all means  
-- go for it!  Most of us here have decided we're not that smart, so  
we'll be content with something more modest. :-)

Best,
Ernie P.




From scott at randomchaos.com  Fri Dec  2 15:00:37 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Fri Dec  2 15:00:44 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390CFC9.2040801@tin.it>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>	<4390C27F.1000402@tin.it>
	<C267EAEB-4228-4EED-B7E2-743B722ABFD1@opendarwin.org>
	<4390CFC9.2040801@tin.it>
Message-ID: <6A2FE4D5-CAB2-4CDA-ABF2-CED2B1908585@randomchaos.com>

Abramo Bagnara wrote:

> As an example consider that a web page might already use class
> "description" for its own purpose. Suppose now that he'd like to add
> hCalendar encapsulation: how he can easily represent differently the
> hCalendar content and the others?

There are two easy ways to do that.  One is by hierarchy:

.description { color: #f00; }
.hcalendar .description { color: #00f; }

The other is multiple class names:

.description { color: #f00; }
.description.microformat-only { color: #00f; }

Peace,
Scott
From tantek at cs.stanford.edu  Fri Dec  2 15:00:50 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Dec  2 15:01:10 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <8E8875D9-3127-4B4E-8D4C-2817002AFC9C@opendarwin.org>
Message-ID: <BFB61214.646EB%tantek@cs.stanford.edu>

On 12/2/05 2:38 PM, "Dr. Ernie Prabhakar" <drernie@opendarwin.org> wrote:

> Hi Abramo,
> 
> On Dec 2, 2005, at 1:18 PM, Abramo Bagnara wrote:
>> I think that "general purpose" and "universality" sacrificing
>> simplicity
>> is a bad thing, but can we agree that universality *with*
>> simplicity is
>> a benefit?
> 
> I think the challenge has always been "simplicity for whom."  I think
> many of us would agree that generality has *some* value, but (in our
> experience) i) universality is too ambitious a goal, and ii) even
> generality comes at *some* price.  For example, making things simpler
> for parsers often makes it a little harder for humans, which (around
> here) is considered evil. :-)

Correct.

I'll go beyond that.

We've already stated that such "generality" and "universality" is a non-goal
of microformats.

In fact, even wasting everyone's time here discussing whether or not it is
good is outside the scope of this list.

There are other forums in which to have theoretical discussions about the
benefits of universality.  This isn't one of them.

I hate to be blunt about it, but this is essentially one of the techniques
we must employ to keep the signal to noise ratio high on this list (where
signal="practical/pragmatic/useful today" and noise="theoretical ratholes").


> If you can come up with something that is more general, but just as
> simple for *everyone* involved, I'm sure at least a few of us on the
> list would be willing to hear it (though we'd obviously be skeptical
> at first :-).

Even on the off chance that someone did come up with something like that,
even that, would be off-topic for this list.

A better place for such explorations would probably be a weblog where you
could write about it, and solicit feedback via comments etc.

Those that were interested in such discussions, above and beyond practical
microformats discussions could do so there.


In another message, same thread:

On 12/2/05 2:35 PM, "Ryan King" <ryan@technorati.com> wrote:

>> Can we reach an agreement that to use a "namespace" for microformats
>> specific classes is a good thing?
> 
> Be careful, you might want to read the archives here.

Indeed.

Not only are such namespaces (especially prefixes) a *BAD* thing, but that
even wasting time arguing about them is a bad thing.  Another rat-hole that
this community (or at least this mailing list) has no time for.  There is
TONS of wasted bandwidth on many many standards/formats email lists about
namespaces that we neither have the inclination nor the time to needlessly
duplicate.

I've added both of these "Topics to Avoid" to the mailing-lists page.

 http://microformats.org/wiki/mailing-lists


Thanks,

Tantek


From abramobagnara at tin.it  Fri Dec  2 15:06:48 2005
From: abramobagnara at tin.it (Abramo Bagnara)
Date: Fri Dec  2 15:06:49 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <0076F04E-EE46-43AF-A509-BF96A279B517@technorati.com>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>	<E5AACEFA-319E-47B7-9D59-EA136EF4D4F0@technorati.com>	<4390C27F.1000402@tin.it>
	<0076F04E-EE46-43AF-A509-BF96A279B517@technorati.com>
Message-ID: <4390D388.8070006@tin.it>

Ryan King ha scritto:
>> <div>
>> <span class="header">Optional partecipants: </span>
> 
> 
> Not to nitpick, but it'd be helpful if you didn't reinvent <h*>.

I'm not very keen to change display style from block to inline. In past
I've had many troubles with some browsers. I'll retry now, thanks for
the suggestion.


>> <span class="attendee">
>>   <abbr class="role" title="opt-participant"></abbr>
> 
> 
> Ok, so you've found a place where its hard to follow the DRY principle.
> 
>>   <a class="cn" href="mailto:abramobagnara@tin.it">Abramo Bagnara</a>
>> </span>,
>> <span class="attendee">
>>   <abbr class="role" title="opt-participant"></abbr>
>>   <a class="cn" href="litabanelli@racine.ra.it">Licia Tabanelli</a>
>> </span>
>> </div
>>
>> while with my proposal I can do the following:
>>
>> <div>
>> <span class="header">
>> <abbr title="opt-participant">Optional partecipants</abbr>
>> </span>:
>> <span class="xx:attendee= xx:@role=../abbr/@title">
>>   <a class="xx:@cn xx:=@href"  href="mailto:abramobagnara@tin.it">Abramo
>> Bagnara</a>
> 
> 
> Do you realize the tradeoff you make here? You can't write a CSS 
> selector to style on "xx:attendee= xx:@role=../abbr/@title". This is  a
> deal breaker for microformats. If you really want to reference  another
> HTML element, why not use something more HTMLish, like and  <object>?

Obviously I've no interest to style on complex microformat classes (as
the data is not in text() and then the CSS style is irrelevant).

But for trivial microformat classes like <span class="xx:description">
where the contents is inside the element you can have easy CSS selector
(as now in hCalendar).

>> </span>,
>> <span class="xx:attendee= xx:@role=../abbr/@title">
>>   <a class="xx:@cn xx:=@href" href="litabanelli@racine.ra.it">Licia
>> Tabanelli</a>
>> </span>
>> </div>
>>
>> So leaving the needed layout freedom to web page designer.
> 
> 
> Per my point above, you leave more markup freedom, but eliminate  [CSS]
> styling freedom. A big negative in my book.

CSS styling on complex microformat classes (i.e. with xpath) is never
useful (by definition).

-- 
Abramo Bagnara                       mailto:abramobagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
From tantek at cs.stanford.edu  Fri Dec  2 15:08:50 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Dec  2 15:09:11 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <6A2FE4D5-CAB2-4CDA-ABF2-CED2B1908585@randomchaos.com>
Message-ID: <BFB61396.646F1%tantek@cs.stanford.edu>

On 12/2/05 3:00 PM, "Scott Reynen" <scott@randomchaos.com> wrote:

> Abramo Bagnara wrote:
> 
>> As an example consider that a web page might already use class
>> "description" for its own purpose. Suppose now that he'd like to add
>> hCalendar encapsulation: how he can easily represent differently the
>> hCalendar content and the others?
> 
> There are two easy ways to do that.  One is by hierarchy:
> 
> .description { color: #f00; }
> .hcalendar .description { color: #00f; }
> 
> The other is multiple class names:
> 
> .description { color: #f00; }
> .description.microformat-only { color: #00f; }

Thanks Scott!

Scott is precisely correct.

In addition, this has been covered in the FAQ for a while:

 http://microformats.org/wiki/faq#Class_interactions

Thanks,

Tantek

From tantek at cs.stanford.edu  Fri Dec  2 15:37:39 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Dec  2 15:38:03 2005
Subject: [uf-discuss] XOXO, the 'compact' attribute is deprecated
In-Reply-To: <65b4e01f0512021306p763c9enb60eecacb8817e5e@mail.gmail.com>
Message-ID: <BFB61A4E.646F6%tantek@cs.stanford.edu>

On 12/2/05 1:06 PM, "kenny heaton" <kennyheaton@gmail.com> wrote:

> Hi,
> 
> I am new to microformats,

Hi Kenny, welcome to the list!


> but excited about them and eager to learn
> and start using them.

Great!  There are plenty of experts and experienced folks here who have
successfully done so, so you've found the right place.


> But as I was reading over the XOXO format, it
> uses the attribute compact which was a part of the HTML specification
> but is deprecated. Is this something that has been discussed elsewhere
> and is there a reason for including a deprecated attribute in the XOXO
> format? I personally would think it better not to use any deprecated
> elements.

I think it has been discussed somewhere, but nowhere that I can find on the
wiki or the mailing list.

In short:

The 'compact' attribute as specified in HTML4 is purely presentational and
as such was deprecated.  Since this attribute has been little used, we have
repurposed it as a semantic attribute in XOXO that actually preserves the
state of whether or not the ''user'' has twiddled an an outline item and all
its children in the open state vs. the closed state.  We recycled the
'compact' attribute instead of making a new attribute to minimize
reinvention, and to make an otherwise useless attribute useful again.

Your question is a good one and I have added it to the XOXO FAQ:

 http://microformats.org/wiki/xoxo-faq

Thanks,

Tantek

From rbach at rbach.priv.at  Fri Dec  2 17:29:57 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Dec  2 17:29:15 2005
Subject: [uf-discuss] RFC: Proposal for general purpose microformat
In-Reply-To: <4390BA12.70707@tin.it>
References: <43902243.4080901@tin.it>	<43907830.5080107@gmail.com>	<43908764.8060401@tin.it>	<B62A28BF-7A4D-4298-9EFC-5500E71665B7@technorati.com>	<4390A301.90508@tin.it>	<6F18CEBD-93BA-43FD-9B07-DEBC110BDE1E@randomchaos.com>
	<4390BA12.70707@tin.it>
Message-ID: <4390F515.4060909@rbach.priv.at>

Abramo Bagnara wrote:
>>I suspect many here are tired of fending off attempt after attempt at 
>>generalization, as such attempts tend to come at a cost of simplicity 
>>(and therefor adoption).
> 
> About simplicity I guess that a rather reliable way to measure it is to
> compare stylesheet needed for data extraction.

The complexity of your (XSLT, I assume) stylesheet isn't a good measure.

IMO it's better to have a few developers spending 200 hours on
developing a XSLT stylesheet and the average content author needs 5-10
minutes for marking up his HTML with hReview/hCalendar/hCard/etc... than
a few developers spending 20 hours on developing a XSLT stylesheet and
the average content author needs 20-40 minutes for marking up his HTML.

Just my 2 cents,
 Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From benjamincarlyle at optusnet.com.au  Fri Dec  2 20:59:24 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Fri Dec  2 20:58:28 2005
Subject: [uf-discuss] URI schemes vs. visible data (was Re:
	communications log, "tel" microformat?)
In-Reply-To: <BFB248BD.6440A%tantek@cs.stanford.edu>
References: <BFB248BD.6440A%tantek@cs.stanford.edu>
Message-ID: <1133585965.5439.71.camel@tori>

On Tue, 2005-11-29 at 18:15 -0800, Tantek ?elik wrote:
> On 11/26/05 1:07 AM, "Benjamin Carlyle" <benjamincarlyle@optusnet.com.au>
> > On Thu, 2005-11-24 at 10:25 -0800, Tantek ?elik wrote:
> > perhaps
> > it is even worth reexamining the geo and addr microformats in favour of
> > developing URI-based alternatives.
> It's an interesting question to consider.
> Here is the key. 
> Authors aren't publishing links to geo and address information.
> They're publishing *visible text* of geo and address information.
> So the easiest thing to do, for the author, is to leave it as visible text.

Thanks for the input. I have to admit that I did come to some of the
same places in my own thinking while writing the email. I'll just pop in
one last thought:
The thing that really triggered me to post was reading the geo
specification on the microformats wiki:
<div class="geo">
 <abbr class="latitude" title="37.408183">N 37? 24.491</abbr> 
 <abbr class="longitude" title="-122.13855">W 122? 08.313</abbr>
</div>

It seemed to me that this would be simpler described as something like:
<a href="geo:37.408183,-122.13855">N 37? 24.491 W 122? 08.313</a>

What struck me really was that the visible data is ignored in this
specification, so it seemed that URIs might be a way forward. On the
other hand it would probably be even simpler to say:
<abbr class="geo" title="37.408183,-122.13855">N 37? 24.491 W 122? 08.313</a>
or <span class="geo">37.408183,-122.13855</span>

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From benjamincarlyle at optusnet.com.au  Fri Dec  2 21:32:37 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Fri Dec  2 21:31:42 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <43843033.4080802@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>
Message-ID: <1133587958.5439.86.camel@tori>

Hello,

On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
> Have at it:
> http://microformats.org/wiki/hatom

I've had a play at applying this to my weblog[1]. One question I would
like to ask is about the author field. I currently have my name tagged
with dc-author and foaf-name on the main page. I think the dc-author is
non-standard in the body and used in this way. The foaf-name is
experimental based on a generalised microformat for rdf, which of course
is not microformat because it is too general.

I see that hAtom currently recommds the use of a hcard. I could add this
in as well, but what does a hcard mean when floating around on a web
page? I'm also uneasy about including a <span class="vcard"></span>
section in the document. Not all of the relevant information is in one
place.

Urrgh. I'm not quite getting this out right, but what is the most
straightforward way to say "This page and everything in it was authored
by Benjmain Carlyle"? :)

I don't want to add a URL. Why should I? You're already at my home page.
I don't want to add an email address, or not a precisely valid one. I
don't want to attract spam. Technorati has the only photo I display, and
that is provided by javascript I don't control. I can't directly
reference it. I just want to quickly make a few assertions and have them
picked up by a hAtom parser.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
[1] http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/

From benjamincarlyle at optusnet.com.au  Fri Dec  2 21:38:16 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Fri Dec  2 21:37:18 2005
Subject: [uf-discuss] rel-tag for hierarchical categories
Message-ID: <1133588297.5439.93.camel@tori>

G'day,

I'm wanting to use tags as part of my blog entry posts, but I don't like
explicit tagging. I just want a single link at the bottom of each blog
entry to point to its category, and for that to be interpreted as one or
more tags.

Now, rel-tag appears to do the right thing for:
<a
href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/software">software</a>

Now I want it to make sense of a hierarchical category system:
<a
href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/software/httpsubscription">software/httpsubscription</a>

I think the current proposal would tag this as
"software/httpsubscription", when in fact it really means two tags:
"software"+"httpsubscription".

What will current parsing do (especially technorati) with my input? Is
my data point something that could be applied more generally? Should the
specification cover this case?

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From benjamincarlyle at optusnet.com.au  Fri Dec  2 21:42:26 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Fri Dec  2 21:41:30 2005
Subject: [uf-discuss] hCa* CATEGORIES as TAGS
In-Reply-To: <1bc4603e0511260739k780ba8a8o326dc6d51505882f@mail.gmail.com>
References: <21e770780511221717k606274f1jcae66cdc0c9bfb31@mail.gmail.com>
	<1bc4603e0511242127w57caf408y5754cb37971ea345@mail.gmail.com>
	<1132994640.6002.23.camel@tori>
	<1bc4603e0511260739k780ba8a8o326dc6d51505882f@mail.gmail.com>
Message-ID: <1133588548.5439.96.camel@tori>

On Sat, 2005-11-26 at 10:39 -0500, Chris Messina wrote:
> My example really wasn't meant to illustrate anything about that one
> particular type of phrase... instead it was a weak attempt to show
> that categories are not consistently semantically useful equivalents
> of tags. For perhaps a better real-world example, I have a category on
> my site called "Asides". Now if my posts to that category were only
> tagged with "Asides" (as they actually currently are), how on earth
> would anyone find that content? And because they're short, concise
> little posts, I don't really want them littering my other category
> listings (ignoring the obvious hack to exclude that category from
> other listings).

Perhaps this is indicating that "Asides" is a separate feed (ala hAtom)
with its own categorisation requirements?

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From kmarks at technorati.com  Fri Dec  2 22:00:44 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Fri Dec  2 22:00:55 2005
Subject: [uf-discuss] rel-tag for hierarchical categories
In-Reply-To: <1133588297.5439.93.camel@tori>
References: <1133588297.5439.93.camel@tori>
Message-ID: <3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>


On Dec 2, 2005, at 9:38 PM, Benjamin Carlyle wrote:
> I'm wanting to use tags as part of my blog entry posts, but I don't  
> like
> explicit tagging. I just want a single link at the bottom of each blog
> entry to point to its category, and for that to be interpreted as one  
> or
> more tags.
>
> Now, rel-tag appears to do the right thing for:
> <a
> href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ 
> software">software</a>

yes, that is the spec

> Now I want it to make sense of a hierarchical category system:
> <a
> href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ 
> software/httpsubscription">software/httpsubscription</a>
>
> I think the current proposal would tag this as
> "software/httpsubscription", when in fact it really means two tags:
> "software"+"httpsubscription".

No, it would tag it as 'httpsubscription'
Tagspaces are defined to be flat.

>
> What will current parsing do (especially technorati) with my input? Is
> my data point something that could be applied more generally? Should  
> the
> specification cover this case?

No, tagspaces are meant to be flat. If you want hierarchy you need  
something else.

From supercanadian at gmail.com  Fri Dec  2 22:04:55 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Fri Dec  2 22:04:57 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <1133587958.5439.86.camel@tori>
References: <43843033.4080802@blogmatrix.com> <1133587958.5439.86.camel@tori>
Message-ID: <84ce626f0512022204s25cf2237o715c5636f763f576@mail.gmail.com>

Hello,

On 12/2/05, Benjamin Carlyle <benjamincarlyle@optusnet.com.au> wrote:
> Hello,
>
> On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
> > Have at it:
> > http://microformats.org/wiki/hatom
>
> I've had a play at applying this to my weblog[1]. One question I would
> like to ask is about the author field. I currently have my name tagged
> with dc-author and foaf-name on the main page. I think the dc-author is
> non-standard in the body and used in this way. The foaf-name is
> experimental based on a generalised microformat for rdf, which of course
> is not microformat because it is too general.
>
> I see that hAtom currently recommds the use of a hcard. I could add this
> in as well, but what does a hcard mean when floating around on a web
> page? I'm also uneasy about including a <span class="vcard"></span>
> section in the document. Not all of the relevant information is in one
> place.
>
> Urrgh. I'm not quite getting this out right, but what is the most
> straightforward way to say "This page and everything in it was authored
> by Benjmain Carlyle"? :)

In HTML the <address> element can be used to specify the author of a
document.  So, you could combine an <address> element with a hCard and
do something like:

    <address class="vcard">
        <span class="fn">Benjmain Carlyle</span>
    </address>

Or, if you want to get more sophisticated (and more detailed and
complex), you could do something like the following:

    <address class="vcard">
        <span class="fn"><span class="given-name">Benjmain</span>
<span class="family-name">Carlyle</span></span>
    </address>

Note, that's pretty plain... you can add extra stuff -- text, tags,
etc -- in there to make it look better.  (If you don't know what I
mean, I can explain.  I'm just too tired to type one out right now :-)
)

> I don't want to add a URL. Why should I?

You don't have to.

> You're already at my home page.
> I don't want to add an email address, or not a precisely valid one. I
> don't want to attract spam. Technorati has the only photo I display, and
> that is provided by javascript I don't control. I can't directly
> reference it. I just want to quickly make a few assertions and have them
> picked up by a hAtom parser.
>
> --
> Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
> [1] http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From benjamincarlyle at optusnet.com.au  Fri Dec  2 22:48:07 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Fri Dec  2 22:47:10 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <84ce626f0512022204s25cf2237o715c5636f763f576@mail.gmail.com>
References: <43843033.4080802@blogmatrix.com> <1133587958.5439.86.camel@tori>
	<84ce626f0512022204s25cf2237o715c5636f763f576@mail.gmail.com>
Message-ID: <1133592488.5439.99.camel@tori>

On Fri, 2005-12-02 at 22:04 -0800, Charles Iliya Krempeaux wrote:
> In HTML the <address> element can be used to specify the author of a
> document.  So, you could combine an <address> element with a hCard and
> do something like:
>     <address class="vcard">
>         <span class="fn">Benjmain Carlyle</span>
>     </address>

Couldn't address mean something else, though? Perhaps identifying the
person this page is about rather than its author? Wouldn't using dublin
core be more specific?

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From supercanadian at gmail.com  Fri Dec  2 22:53:30 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Fri Dec  2 22:53:33 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <1133592488.5439.99.camel@tori>
References: <43843033.4080802@blogmatrix.com> <1133587958.5439.86.camel@tori>
	<84ce626f0512022204s25cf2237o715c5636f763f576@mail.gmail.com>
	<1133592488.5439.99.camel@tori>
Message-ID: <84ce626f0512022253j3e4244f3ka15f94f8d554b51f@mail.gmail.com>

Hello,

On 12/2/05, Benjamin Carlyle <benjamincarlyle@optusnet.com.au> wrote:
> On Fri, 2005-12-02 at 22:04 -0800, Charles Iliya Krempeaux wrote:
> > In HTML the <address> element can be used to specify the author of a
> > document.  So, you could combine an <address> element with a hCard and
> > do something like:
> >     <address class="vcard">
> >         <span class="fn">Benjmain Carlyle</span>
> >     </address>
>
> Couldn't address mean something else, though? Perhaps identifying the
> person this page is about rather than its author? Wouldn't using dublin
> core be more specific?

Here's something I found here: http://www.w3.org/MarkUp/html3/address.html

    The ADDRESS element specifies such information as address,
signature and authorship for the current document...

The problem is that the <address> element by itself is only human
readable (and not machine readable).  (Which is why things like dublin
core are sometimes useful... they made it so things were machine
readable too.)  However, the <address> element combined with and hCard
brings in the "machine readable" part,... so that an <address> element
combined with an hCard is both human readable and machine readable.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From scott at randomchaos.com  Fri Dec  2 23:03:06 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Fri Dec  2 23:03:14 2005
Subject: [uf-discuss] rel-tag for hierarchical categories
In-Reply-To: <3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
Message-ID: <45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>

Kevin Marks wrote:

>> Now I want it to make sense of a hierarchical category system:
>> <a
>> href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ 
>> software/httpsubscription">software/httpsubscription</a>
>>
>> I think the current proposal would tag this as
>> "software/httpsubscription", when in fact it really means two tags:
>> "software"+"httpsubscription".
>
> No, it would tag it as 'httpsubscription'
> Tagspaces are defined to be flat.

Note that dot ('.') makes a decent hierarchy marker with no required  
change for flat tag systems.  Foxilicious [1] uses dot as a default  
delimiter for converting from the (mostly) flat tag space at  
del.icio.us to the hierarchy of Firefox's bookmarks.  So you could do:

<a
href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ 
software.httpsubscription">software/httpsubscription</a>

Some parsers will still treat that as a single tag, but others will  
treat it as a hierarchy, and even in those systems treating it as a  
single tag, I think "software.httpsubscription" suggests a hierarchy  
to many humans.

Peace,
Scott

[1] http://dietrich.ganx4.com/foxylicious/
From supercanadian at gmail.com  Sat Dec  3 01:07:28 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Sat Dec  3 01:07:33 2005
Subject: [uf-discuss] Vote-Links use cases ?
Message-ID: <84ce626f0512030107r6db5b7cekb7be2778bf28c634@mail.gmail.com>

Hello,

Just wondering if there's a list of use cases for vote-links somewhere?

For example, are vote-links just a better version of rel-nofollow. 
(With rel="nofollow" being equivalent to rev="vote-against".)  Or are
there other use cases.

(Note, I'm pretty certain there are other use cases that can be
used... but I just wanted to confirm it.  It doesn't seem obvious
based on is here: http://microformats.org/wiki/vote-links  Although
other pages, on the wiki, imply it.)


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From davidjanes at blogmatrix.com  Sat Dec  3 01:19:43 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sat Dec  3 01:17:44 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <1133587958.5439.86.camel@tori>
References: <43843033.4080802@blogmatrix.com> <1133587958.5439.86.camel@tori>
Message-ID: <4391632F.80507@blogmatrix.com>

[I think Charles has covered most of this, but I'll give a quick gloss]

Benjamin Carlyle wrote:
> Hello,
> 
> On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
>> Have at it:
>> http://microformats.org/wiki/hatom
> 
> I've had a play at applying this to my weblog[1]. One question I would
> like to ask is about the author field. I currently have my name tagged
> with dc-author and foaf-name on the main page. I think the dc-author is
> non-standard in the body and used in this way. The foaf-name is
> experimental based on a generalised microformat for rdf, which of course
> is not microformat because it is too general.
> 
> I see that hAtom currently recommds the use of a hcard. I could add this
> in as well, but what does a hcard mean when floating around on a web
> page? I'm also uneasy about including a <span class="vcard"></span>
> section in the document. Not all of the relevant information is in one
> place.

I have issues about this too, but it's not required. You are free to do ...
<address>Ben</address>
... and leave it at that.

To address the deeper issue you're getting at, once I'm clear of hAtom, 
I was thinking of pushing the concept of "rel-bookmark" defining the 
"best location for this microformat object". This could be used like this:

<address class="vcard">
  <span class="fn">Benjamin Carlyle</span>,
  <a rel="bookmark" href="http://.../#mycard">My hCard</a>
</address>


> 
> Urrgh. I'm not quite getting this out right, but what is the most
> straightforward way to say "This page and everything in it was authored
> by Benjmain Carlyle"? :)

I think there's been some discussion of this. Maybe something like (?):

<head>
  <link rel="vcard" href="http://.../#mycard" />
</head>

> 
> I don't want to add a URL. Why should I? You're already at my home page.
> I don't want to add an email address, or not a precisely valid one. I
> don't want to attract spam. Technorati has the only photo I display, and
> that is provided by javascript I don't control. I can't directly
> reference it. I just want to quickly make a few assertions and have them
> picked up by a hAtom parser.
> 

or

<address class="vcard">
  <span class="fn">Benjamin Carlyle</span>
</address>

Regards, etc...
David

PS. Extra for hCard experts -- valid or not?

<address class="vcard fn">Benjamin Carlyle</address>

From supercanadian at gmail.com  Sat Dec  3 01:24:09 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Sat Dec  3 01:24:11 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <4391632F.80507@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com> <1133587958.5439.86.camel@tori>
	<4391632F.80507@blogmatrix.com>
Message-ID: <84ce626f0512030124t36071c6eg2a99058c8c8461f5@mail.gmail.com>

Hello,

On 12/3/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:

[...]

> To address the deeper issue you're getting at, once I'm clear of hAtom,
> I was thinking of pushing the concept of "rel-bookmark" defining the
> "best location for this microformat object". This could be used like this:
>
> <address class="vcard">
>   <span class="fn">Benjamin Carlyle</span>,
>   <a rel="bookmark" href="http://.../#mycard">My hCard</a>
> </address>

Just for the benefit of those who aren't Microformat experts yet.... 
That rel-bookmark in there is a completely different Microformat from
the vCard Microformat, even though we've mixed them together like
that.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From davidjanes at blogmatrix.com  Sat Dec  3 01:38:44 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sat Dec  3 01:36:44 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <84ce626f0512030124t36071c6eg2a99058c8c8461f5@mail.gmail.com>
References: <43843033.4080802@blogmatrix.com>
	<1133587958.5439.86.camel@tori>	<4391632F.80507@blogmatrix.com>
	<84ce626f0512030124t36071c6eg2a99058c8c8461f5@mail.gmail.com>
Message-ID: <439167A4.6090207@blogmatrix.com>

Charles Iliya Krempeaux wrote:
> Hello,
> 
> On 12/3/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
> 
> [...]
> 
>> To address the deeper issue you're getting at, once I'm clear of hAtom,
>> I was thinking of pushing the concept of "rel-bookmark" defining the
>> "best location for this microformat object". This could be used like this:
>>
>> <address class="vcard">
>>   <span class="fn">Benjamin Carlyle</span>,
>>   <a rel="bookmark" href="http://.../#mycard">My hCard</a>
>> </address>
> 
> Just for the benefit of those who aren't Microformat experts yet.... 
> That rel-bookmark in there is a completely different Microformat from
> the vCard Microformat, even though we've mixed them together like
> that.

Yes, exactly. In particularly, rel-bookmark as a concept is meant to be 
mixed with all other (non-rel) bookmarks!

Regards, etc...
From davidjanes at blogmatrix.com  Sat Dec  3 01:39:21 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sat Dec  3 01:37:23 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <439167A4.6090207@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>	<1133587958.5439.86.camel@tori>	<4391632F.80507@blogmatrix.com>	<84ce626f0512030124t36071c6eg2a99058c8c8461f5@mail.gmail.com>
	<439167A4.6090207@blogmatrix.com>
Message-ID: <439167C9.40406@blogmatrix.com>

David Janes -- BlogMatrix wrote:

> 
> Yes, exactly. In particularly, rel-bookmark as a concept is meant to be 
> mixed with all other (non-rel) bookmarks!
> 

D'oh. Bookmarks > Microformats.

From solitude at solitude.dk  Sat Dec  3 01:38:38 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Sat Dec  3 01:38:42 2005
Subject: [uf-discuss] rel-tag for hierarchical categories
In-Reply-To: <45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>
Message-ID: <op.s07bqorbares2h@mail.solitude.dk>

On Sat, 03 Dec 2005 08:03:06 +0100, Scott Reynen <scott@randomchaos.com>  
wrote:

> Note that dot ('.') makes a decent hierarchy marker with no required  
> change for flat tag systems.  Foxilicious [1] uses dot as a default  
> delimiter for converting from the (mostly) flat tag space at del.icio.us  
> to the hierarchy of Firefox's bookmarks.  So you could do:
>
> <a
> href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ 
> software.httpsubscription">software/httpsubscription</a>
>
> Some parsers will still treat that as a single tag, but others will  
> treat it as a hierarchy, and even in those systems treating it as a  
> single tag, I think "software.httpsubscription" suggests a hierarchy to  
> many humans.

It won't be cool for those people who use system that don't see the  
hierarchy. Why not use two links:

<a  
href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/software">software</a>/<a  
href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/software/httpsubscription">httpsubscription</a>

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From supercanadian at gmail.com  Sat Dec  3 01:47:50 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Sat Dec  3 01:47:52 2005
Subject: [uf-discuss] New Password From Wiki ?
Message-ID: <84ce626f0512030147g3298faf1lc86666ab243730d2@mail.gmail.com>

Hello,

Forgot my password for the wiki and tried to get my password e-mailed
to me.  It didn't seem to work.  (Never received an e-mail with the
password.)  Can anyone help?

Wiki Username: CharlesIliyaKrempeaux

TIA

See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From danny.ayers at gmail.com  Sat Dec  3 05:23:28 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Sat Dec  3 05:23:30 2005
Subject: [uf-discuss] rel-tag for hierarchical categories
In-Reply-To: <3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
Message-ID: <1f2ed5cd0512030523j5aaf4bf6he56bdaa43c5d92ff@mail.gmail.com>

On 12/3/05, Kevin Marks <kmarks@technorati.com> wrote:

> No, tagspaces are meant to be flat. If you want hierarchy you need
> something else.

I'm not sure "flat" is quite the right word.

If you tag say a blog entry with "software" and "httpsubscription",
the individual relationships are:

<entry> taggedWith "software"
<entry> taggedWith "httpsubscription"

you could potentially view the combined tagging through either hierarchy:

./software/httpsubscription
./httpsubscription/software

which would correspond to relationships in the tagging scheme of:

"httpsubscription" subCategoryOf  "software"
or
"software" subCategoryOf "httpsubscription"

If you use URIs for the categories, this can all fit nicely into the RDF graph.

An individual tagging scheme, capturing the preferred hierarchy (using
Turtle syntax):

@prefix skos: <http://www.w3.org/2004/02/skos/core#"> .

<http://example.org/software/httpsubscription> skos:broader
<http://example.org/software> .

A use of it:

@prefix tags: <http://www.holygoat.co.uk/owl/redwood/0.1/tags/> .

<http://example.com/blog/post/1> tags:tag
<http://example.org/software/httpsubscription>

Going down this route it's not difficult to extend into further
information, like who did the tagging.

[Rich - any chance of adding a minimal example or two to the ontology,
right now it looks like you need to commit to the whole caboodle to be
able to use it]

Cheers,
Danny.

--

http://dannyayers.com
From scott at randomchaos.com  Sat Dec  3 09:13:37 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Sat Dec  3 09:13:44 2005
Subject: [uf-discuss] rel-tag for hierarchical categories
In-Reply-To: <op.s07bqorbares2h@mail.solitude.dk>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>
	<op.s07bqorbares2h@mail.solitude.dk>
Message-ID: <3FEEB0D5-69F6-4664-BFAB-6ADE474F4543@randomchaos.com>

Andreas Haugstrup wrote:

>> Some parsers will still treat that as a single tag, but others  
>> will treat it as a hierarchy, and even in those systems treating  
>> it as a single tag, I think "software.httpsubscription" suggests a  
>> hierarchy to many humans.
>
> It won't be cool for those people who use system that don't see the  
> hierarchy.

I'm not sure what you mean by "won't be cool."  It doesn't break any  
functionality as far as I can tell, and successfully adds  
functionality for systems that support it (e.g. Foxylicious).  People  
are already using parent.child syntax for tags [1] [2], and it seems  
to be working just fine.

> Why not use two links:
>
> <a href="http://members.optusnet.com.au/benjamincarlyle/benjamin/ 
> blog/software">software</a>/<a href="http://members.optusnet.com.au/ 
> benjamincarlyle/benjamin/blog/software/ 
> httpsubscription">httpsubscription</a>

You could, but that doesn't give leave any indication that  
httpsubscription is meant as a subset of software.  Not particularly  
important in this case, but "politics.green" is quite different from  
"construction.green" or "color.green".

Peace,
Scott

[1] http://technorati.com/tag/food.cooking
[2] http://del.icio.us/tag/music.pop
From chris.messina at gmail.com  Sat Dec  3 10:23:25 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Sat Dec  3 10:23:27 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
Message-ID: <1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>

On 12/2/05, Ryan King <ryan@technorati.com> wrote:

> > Enclosures have a different meaning. They are best compared to
> > attachments in e-mail. The enclosure is a part of the current
> > document and document+enclosure(s) should be seen as a whole. This
> > has great value when talking about blog posts (and hAtom) because
> > attachments are usually connected to a part of the page (a single
> > blog entry).
> >
> > I don't care where I point my profiles to, but rel-enclosure isn't
> > what I mean when I use rel="enclosure".
>
> I don't think your relEnclosure and http://microformats.org/wiki/rel-
> enclosure are that different, they're just explained differently.
> Also, I think they're close enough to be resolved. You want to work
> on that?

Perhaps rel-enclosure doesn't actually make sense long term. Given
that relEnclosure, AFAIK, was grafted onto RSS to allow for media
being "attached" to feeds, rel-enclosure doesn't make sense in your
regular browser-consumed webpages because we've got <embed> and
<object>. If RSS had been able to support inline rich media, wouldn't
those tags have sufficed?

It also seems that relEnclosure was about behavior on the client side
and less about semantics.

Let's presume for a minute that we've got infinite bandwidth and
infinite storage. In such a world, all embedded media (and hrefs)
would be able to be pulled in and cached automagically. In which case
the need for delayed media downloading would be much less, so even if
you're syncing your 8,000  feeds,  which all contain rich media like
podcasts and vcasts, you would theoretically be able to pull all that
data down anyway for later consumption.

So the question is, what is the most effective way to link to that
media? Indeed, will the media itself supplant the textual content of
the feed? Will feeds simply become the distribution method for rich
media or eventually get into a TV-for-the-web model where you pick
people to subscribe to and can "tune in" to an aggregate stream of
them whenever you like? I dunno, and I suppose I'm getting a little
off topic here.

So here's what I'm thinking when it comes down to it (now that you
know what I'm looking at in the future)... Shouldn't relEnclosures
just be converted to <object> or <embed> tags when they're pulled into
xhtml? Isn't that what the original intention (and indeed, behavior)
actually implies? Wasn't the original problem one of embedding rich
media in RSS and so therefore, relEnclosure is actually made obsolete
when ported to the world of XHTML microformats?

Anyway, sorry to go on and on, must be the Parisien air. ;)

Chris
From craig.ogg at gmail.com  Sat Dec  3 11:18:43 2005
From: craig.ogg at gmail.com (Craig Ogg)
Date: Sat Dec  3 11:18:45 2005
Subject: [uf-discuss] Microformat Base
In-Reply-To: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
References: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
Message-ID: <8b18dc20512031118l209c2d87rce17f215a52f6a05@mail.gmail.com>

On 12/1/05, Scott Reynen <scott@randomchaos.com> wrote:
> I thought I'd go ahead and play around with a microformat-based
> alternative to Google Base.  So far, I have a basic spider that I set
> loose from microformats.org to slowly wander the web.  When it finds
> any known microformat-associated class names, it records the data
> which can then be searched here:
>

This is very cool, but I don't think it is really an alternative to
Google Base.  As has been pointed out in some of the proposals for a
discovery format here, to have to spider a web site to discover its
data is not very efficient or accurate.  From some of the public
statements that Adam Bosworth of Google has made [1], I think Google
is trying to define a single universal schema for all data.  If you
take Google's upload formats (RSS, Atom, etc.) and combine it with
A9's Open Search you end up with a way to query any web site using
REST for structured data about what it contains. I talk about this on
my blog in more detail [2][3])

While some elements are predefined in the schema, it looks like Google
Base is depending on user-defined attributes converging over time for
specific domains (similar to the tags vs categories benefit).  It
appears to offer to refine your search results on attributes it
discovers are shared by a significant number of items in the initial
search.  This allows new attributes to bubble up as they become
popular.

I think microformats offer much more potential to aid adhoc discovery
and use of information while you are browsing:  drag this event to my
calendar, add this person as a contact in my address book, give me
driving directions to this location, give this blog post proper via
credit, etc.  Having this built-in to Firefox or Flock I think would
be very cool.

Craig

P.S. I realize that rel-tag is being used to aid search already -- but
I think it is being almost exclusively consumed from RSS feeds. 
Probably for the efficiency reasons stated above.

[1] http://www.itconversations.com/shows/detail571.html
[2] http://www.softwarevoices.com/archives/20-Democratizing-Information-Speculation-on-the-Future-of-Google-Base.html
(or http://googlebase2.notlong.com)
http://www.softwarevoices.com/archives/17-Did-Adam-Bosworth-reveal-the-real-Google-Base-at-the-MySQL-Users-Conference.html
(or http://googlebase1.notlong.com)
From chris.messina at gmail.com  Sat Dec  3 12:27:07 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Sat Dec  3 12:27:09 2005
Subject: [uf-discuss] Microformat for dictionary/thesaurus ... + research
In-Reply-To: <813D5E25-45B7-440F-A16A-E5F4A0AA7C89@technorati.com>
References: <1bc4603e0511301220o43e4ee6dm1e3b68e1a9185d05@mail.gmail.com>
	<79B3A59E-EDC4-4628-A1A8-5E827961D8A7@technorati.com>
	<747b6ca27fe60b6411f54b41524fea7c@technorati.com>
	<1bc4603e0511301256m7411c03etca36db745a6a1d91@mail.gmail.com>
	<813D5E25-45B7-440F-A16A-E5F4A0AA7C89@technorati.com>
Message-ID: <1bc4603e0512031227g2fb0482aid5aa487649c48542@mail.gmail.com>

Speaking of all this... maybe we have our first web customer?

http://www3.merriam-webster.com/opendictionary/

On 11/30/05, Ryan King <ryan@technorati.com> wrote:
> On Nov 30, 2005, at 12:56 PM, Chris Messina wrote:
>
> > I guess what's also interesting to me at this point, now that we have
> > some more mature microformats getting spread, to have cool ways of
> > visually styling them. Since the Dictionary.app output looks pretty
> > good, the thought was using that visual style and applying it to data
> > marked up as microformatted data... that way we start bringing our
> > work around to designers who will advocate and implement and start to
> > get these practices into the real world.
> >
> > Anyway, is there a wiki page for definitions/thesauri listings
> > already?
>
> No, I suggest http://microformats.org/wiki/definition-examples (or
> something along those lines).
>
> -ryan
> --
> Ryan King
> ryan@technorati.com
>
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
From brian.suda at gmail.com  Sat Dec  3 12:25:49 2005
From: brian.suda at gmail.com (brian suda)
Date: Sat Dec  3 12:49:41 2005
Subject: [uf-discuss] URI schemes vs. visible data (was Re:	communications
	log, "tel" microformat?)
In-Reply-To: <1133585965.5439.71.camel@tori>
References: <BFB248BD.6440A%tantek@cs.stanford.edu>
	<1133585965.5439.71.camel@tori>
Message-ID: <4391FF4D.2020805@gmail.com>

Benjamin Carlyle wrote:

>The thing that really triggered me to post was reading the geo
>specification on the microformats wiki:
><div class="geo">
> <abbr class="latitude" title="37.408183">N 37? 24.491</abbr> 
> <abbr class="longitude" title="-122.13855">W 122? 08.313</abbr>
></div>
>
>It seemed to me that this would be simpler described as something like:
><a href="geo:37.408183,-122.13855">N 37? 24.491 W 122? 08.313</a>
>  
>
If you look through the archives you will find a post about the problems
with strange protocols, like geo: and tel: and isbn:, etc. While they
may be correct, no browser supports them, and your visitors will be
clicking on links that error. Not to mention then any transforming
applications would have to be aware of every type of protocol possible
to point to a lat/lon pair - not even browsers do that.

>What struck me really was that the visible data is ignored in this
>specification, so it seemed that URIs might be a way forward. 
>  
>
I'm not sure what you mean by "visible data is ignored"? Just like the
date-time issues, you can put the machine data in the TITLE attribute of
an ABBR element and the human readable data as the node value, or put
the machine data AS the node value of any element.

<abbr class="latitude" title="37.408183">N 37? 24.491</abbr>
is the same as
<span class="latitude">37.408183</span>

><abbr class="geo" title="37.408183,-122.13855">N 37? 24.491 W 122? 08.313</a>
>or <span class="geo">37.408183,-122.13855</span>
>  
>
The advantage to explictly wrapping each value in its own container
would avoid ambiguity to what the delimiter is. The ICBM protocol (i
think) uses ';' semicolon as a seperator, not a comma. Others may use
different delimiters. So
<span class="geo"><span class="longitude">-122.13855</span>,<span
class="latitude">37.408183</span></span>
could even be put out of order and still correctly transformed by
applications.

From solitude at solitude.dk  Sat Dec  3 13:17:41 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Sat Dec  3 13:17:42 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
	<1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
Message-ID: <op.s0773rn5ares2h@mail.solitude.dk>

On Sat, 03 Dec 2005 19:23:25 +0100, Chris Messina  
<chris.messina@gmail.com> wrote:

> Perhaps rel-enclosure doesn't actually make sense long term. Given
> that relEnclosure, AFAIK, was grafted onto RSS to allow for media
> being "attached" to feeds, rel-enclosure doesn't make sense in your
> regular browser-consumed webpages because we've got <embed> and
> <object>. If RSS had been able to support inline rich media, wouldn't
> those tags have sufficed?

Video/audio is problematic along with <object>. It's memory intensive -  
especially on a blog with lots of blog entries. The practice right now is  
an image link to the video. Something that's used more and more is a  
rel="enclosure" link that is transformed to an <object> by javascript when  
clicked (my preferred way of embedding video).

And rel-enclosure is not just for audio and video. Using <object> is not  
always desirable - embedding zip files, photoshop files and PDF's with  
additional information directly in the page is rarely a good idea (a quick  
way to break the browser, I bet). they are still enclosures.

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From supercanadian at gmail.com  Sat Dec  3 13:51:50 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Sat Dec  3 13:51:52 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
	<1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
Message-ID: <84ce626f0512031351y28f91868t10f4f5c3f16da6cd@mail.gmail.com>

Hello,

On 12/3/05, Chris Messina <chris.messina@gmail.com> wrote:
> On 12/2/05, Ryan King <ryan@technorati.com> wrote:
>
> > > Enclosures have a different meaning. They are best compared to
> > > attachments in e-mail. The enclosure is a part of the current
> > > document and document+enclosure(s) should be seen as a whole. This
> > > has great value when talking about blog posts (and hAtom) because
> > > attachments are usually connected to a part of the page (a single
> > > blog entry).
> > >
> > > I don't care where I point my profiles to, but rel-enclosure isn't
> > > what I mean when I use rel="enclosure".
> >
> > I don't think your relEnclosure and http://microformats.org/wiki/rel-
> > enclosure are that different, they're just explained differently.
> > Also, I think they're close enough to be resolved. You want to work
> > on that?
>
> Perhaps rel-enclosure doesn't actually make sense long term. Given
> that relEnclosure, AFAIK, was grafted onto RSS to allow for media
> being "attached" to feeds, rel-enclosure doesn't make sense in your
> regular browser-consumed webpages because we've got <embed> and
> <object>. If RSS had been able to support inline rich media, wouldn't
> those tags have sufficed?

No.  In RSS, enclosures instruct the client to pre-download the media,
(but says nothing about "playing" it).  Both <embed> and <object> say
"play" the media (and say nothing about pre-downloading it AFAIK).

To me, there are 2 orthogonal concepts here.  One is pre-downloading
it.  And the other is "playing" it.

It was my (perhaps naive) understanding that rel-enclosure was an
attempt to add pre-downloading to HTML.


> It also seems that relEnclosure was about behavior on the client side
> and less about semantics.
>
> Let's presume for a minute that we've got infinite bandwidth

If that was the case, then, you would NOT need RSS enclosures.

> and
> infinite storage. In such a world, all embedded media (and hrefs)
> would be able to be pulled in and cached automagically. In which case
> the need for delayed media downloading would be much less, so even if
> you're syncing your 8,000  feeds,  which all contain rich media like
> podcasts and vcasts, you would theoretically be able to pull all that
> data down anyway for later consumption.
>
> So the question is, what is the most effective way to link to that
> media? Indeed, will the media itself supplant the textual content of
> the feed?

With RSS, this whole topic has been very problematic.  (And you'll
probably get people arguing alot about it.)

For RSS, enclosures actually say pre-download this.  However, the spec
never said "what" to display when you had various combinations of the
RSS <title>, <description>, and <enclosure> elements.

For the systems I've developed I've taken a different approach.  What
I've done is started using Atomic RSS:
http://www.tbray.org/ongoing/When/200x/2005/07/27/Atomic-RSS . 
(Atomic RSS is a mix or RSS and Atom.)  The point of this was so that
the RSS <description> element can be replaced by the Atom <summary>
and <content> elements.

(The RSS <description> element is very very broken.  Basically, you
don't know the "type" of the data it contains or how it is encoded!)

Using the Atom <content> element, I include SMIL data that tells the
user-agent how to "play" things.  Now, it is true that SMIL does
contain it's own technologies to "pre-download" things.  However, I've
only used certain modules of SMIL, thus trying to keep things as
simple as possible for clients.  And kepts to RSS facilities for
pre-downloading things.  This also has the nice effect of keeping
backward-compatability with client's that don't understand Atomic RSS
or that don't understand SMIL.



> Will feeds simply become the distribution method for rich
> media or eventually get into a TV-for-the-web model where you pick
> people to subscribe to and can "tune in" to an aggregate stream of
> them whenever you like? I dunno, and I suppose I'm getting a little
> off topic here.

That's one of the models of content distribution for this.  (There's others.)

> So here's what I'm thinking when it comes down to it (now that you
> know what I'm looking at in the future)... Shouldn't relEnclosures
> just be converted to <object> or <embed> tags when they're pulled into
> xhtml?

I'd say no.

> Isn't that what the original intention (and indeed, behavior)
> actually implies?

Again, no.  RSS enclosures say "pre-download this", not "play this".

> Wasn't the original problem one of embedding rich
> media in RSS and so therefore, relEnclosure is actually made obsolete
> when ported to the world of XHTML microformats?
>
> Anyway, sorry to go on and on, must be the Parisien air. ;)

I do alot of stuff on this topic, so I'm always happy to discuss it.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From ssriram at gmail.com  Sat Dec  3 16:16:36 2005
From: ssriram at gmail.com (S. Sriram)
Date: Sat Dec  3 16:15:16 2005
Subject: [uf-discuss] Microformat Base
References: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
	<8b18dc20512031118l209c2d87rce17f215a52f6a05@mail.gmail.com>
Message-ID: <003001c5f868$00e12710$0367c33f@SCORPIO>

>From: "Craig Ogg" <craig.ogg@gmail.com>
>>On 12/1/05, Scott Reynen <scott@randomchaos.com> wrote:
>> I thought I'd go ahead and play around with a microformat-based
>> alternative to Google Base.  So far, I have a basic spider that I set
>> loose from microformats.org to slowly wander the web.  When it finds
>> any known microformat-associated class names, it records the data
>> which can then be searched here:
>>

>This is very cool, but I don't think it is really an alternative to
>Google Base.  As has been pointed out in some of the proposals for a
>discovery format here, to have to spider a web site to discover its
>data is not very efficient or accurate.  

>I think microformats offer much more potential to aid adhoc discovery
>and use of information while you are browsing:  drag this event to my
>calendar, add this person as a contact in my address book, give me
>driving directions to this location, give this blog post proper via
>credit, etc.  Having this built-in to Firefox or Flock I think would
>be very cool.

>Craig

>P.S. I realize that rel-tag is being used to aid search already -- but
>I think it is being almost exclusively consumed from RSS feeds. 
>Probably for the efficiency reasons stated above.

Well put! this is the realization that has been dawning
upon me i.e. the future format of web-data would not be
centered around  microformatted HTML but rather

the RSS item overlaid with namespace attributes 
- to use your insight -
in a sloppy user-friendly format.

And just as users 'tag' items with labels of their choice,
they would markup feed items with namespaces of their choice
and search accordingly. Consensus attributes would evolve
between peer groups and voila the future of the data-web.
(The other development that will help nail this is the
advent of SSE in OPML.)

The micro micro-format for an item that I've been talking about 
effectively remains the <item> enclosure in an rss feed.

Microformats(.org), will remain - as you point out-  the manner in
which highly specific data sets (meant for rapid user
consumption, typically in browser environments) are 
painless-ly transferred. (bookmarklets, greasemonkey, ajax, flock etc.)

To this -as you add- microformats will also assist ordinary
users to augment their input such as what rel-tag does right 
now. Loosely speaking 'linkspeak'

So microformats will be used for, 
- adding an event to my calendar
- adding a contact to my address book
- ..
- adding a 'specific dataset' to my 'client'
(stuff html-savvy programmers would undertake)
and
- linkspeak (rel-tag etc.)
(stuff marginally tech-savvy folk could undertake)

Searching the wild web, will not be by spiders crawling web pages and
ferreting out microformats
but rather whole-text as in current vogue and from within RSS
feeds with namespace attributes (your Open Search + google base scenario)
and 'linkspeak'

So, I'd ammend my earlier suggestion of 
-'Open Base' as a microformats response to 'google base' 
to 
- microformats has really "no response" to google base
because
the vision of a semantic web, where folks post their wants
to a web page that gets spidered and searched by the world 
seems likely to fade behind the vision of a semantic
web where folks who want to share their content will do so
by exposing it in RSS feeds for searching by the world 
marked up in a babel of xml namespaces that their clients
output.

If anything, a map between microformats and googles namespace
declarations at http://base.google.com/base/base.xsd could be
considered.

Thanks
S. Sriram
From whoisstan at yahoo.com  Sat Dec  3 16:36:41 2005
From: whoisstan at yahoo.com (Mr Michael Wiechers)
Date: Sat Dec  3 16:36:44 2005
Subject: [uf-discuss] ninentdo mario kart DS microformat
Message-ID: <20051204003641.73157.qmail@web60723.mail.yahoo.com>

Hey!
  
  I like microformats. I had a microformat idea and wanted to run that by  you to see if that this makes sense. I play Mario Kart on my Nintendo  DS a lot, it allows you to play online with your friends. A friend is  added to the system by entering a code, every person has a code. 
  
  Right now I just have the code on my personal website:
  http://www.merkwelt.com/people/stan/   (first thing under whoisstan)
  
  So I was thinking of replacing:
  <li> <img.../>390901938389</li>
  
  with
  
  <li><img .../><span class="marioKartDS">390901938389</span></li>
  
  Does that make sense, so I stumble over a personal website with that  code I could have a bunch of games with that person. What I'm not clear  on is how an application/robot could make sense of that? Say I would be  using the geocode microformat as well and the "cuisine" microformat I  would be able to find people that like vietnamese cuisine, live in new  york and have a mario kart DS. Which kind of application do the  aggregation and would allow me to run a query like that?
  
  Thanks,
  Stan Wiechers
  
  
  

		
---------------------------------
 Yahoo! Personals
 Single? There's someone we'd like you to meet.
 Lots of someones, actually. Yahoo! Personals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051203/959e72c6/attachment.htm
From supercanadian at gmail.com  Sat Dec  3 17:02:18 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Sat Dec  3 17:02:26 2005
Subject: [uf-discuss] ninentdo mario kart DS microformat
In-Reply-To: <20051204003641.73157.qmail@web60723.mail.yahoo.com>
References: <20051204003641.73157.qmail@web60723.mail.yahoo.com>
Message-ID: <84ce626f0512031702y4761d4d3l40b1ddc4a38771d5@mail.gmail.com>

Hello,

On 12/3/05, Mr Michael Wiechers <whoisstan@yahoo.com> wrote:
> Hey!
>
>  I like microformats. I had a microformat idea and wanted to run that by you
> to see if that this makes sense. I play Mario Kart on my Nintendo DS a lot,
> it allows you to play online with your friends. A friend is added to the
> system by entering a code, every person has a code.
>
>  Right now I just have the code on my personal website:
>  http://www.merkwelt.com/people/stan/   (first thing under
> whoisstan)
>
>  So I was thinking of replacing:
>  <li> <img.../>390901938389</li>
>
>  with
>
>  <li><img .../><span
> class="marioKartDS">390901938389</span></li>
>
>  Does that make sense, so I stumble over a personal website with that code I
> could have a bunch of games with that person. What I'm not clear on is how
> an application/robot could make sense of that?

Well, an application or robot could scan the page for tags/elements
that have the class "marioKartDS".  When it does, it then checks to
see if that element has a "title" attribute... if it does, it uses
that... if not, it uses the innerHTML.  Make sense?!  Here's some
JavaScript pseudo code:

    var elements = document.getElementsByClassName("marioKartDS");

    if ( elements && elements.length  ) {
        // We found some marioKartDS Microformats!

        for (var i=elements.length-1; i>-1; i--) {
            var code = elements[i].getAttribute("title");
            if ( ! code ) {
                code = elements[i].innerHTML;
            }

            // #### TODO #### Do something with the code you found. 
(Let's play :-)  )
        }
    }

Does that help?


> Say I would be using the
> geocode microformat as well and the "cuisine" microformat I would be able to
> find people that like vietnamese cuisine, live in new york and have a mario
> kart DS. Which kind of application do the aggregation and would allow me to
> run a query like that?

There may not be one that exists yet.  You could write your own (if
you are a software engineer).  You could make a webcrawler.  Or you
could make a user script (using greasemonkey).  Etc.

Also, various people on this lists are probably working on stuff like
this.  (So it may be just a matter of waiting a little while.)


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From chris.messina at gmail.com  Sat Dec  3 21:22:45 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Sat Dec  3 21:22:47 2005
Subject: [uf-discuss] ninentdo mario kart DS microformat
In-Reply-To: <20051204003641.73157.qmail@web60723.mail.yahoo.com>
References: <20051204003641.73157.qmail@web60723.mail.yahoo.com>
Message-ID: <1bc4603e0512032122i213d4f37u3c63ebf8826937ba@mail.gmail.com>

On 12/4/05, Mr Michael Wiechers <whoisstan@yahoo.com> wrote:
> Say I would be using the
> geocode microformat as well and the "cuisine" microformat I would be able to
> find people that like vietnamese cuisine, live in new york and have a mario
> kart DS. Which kind of application do the aggregation and would allow me to
> run a query like that?

Damn, if only we had a Microformats Base... we'd have something for Michael.

Chris
From danny.ayers at gmail.com  Sun Dec  4 00:02:45 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Sun Dec  4 00:02:46 2005
Subject: Fwd: [uf-discuss] rel-tag for hierarchical categories
In-Reply-To: <07789F5A-7C53-469D-9511-BB63F88A14A0@gmail.com>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
	<1f2ed5cd0512030523j5aaf4bf6he56bdaa43c5d92ff@mail.gmail.com>
	<07789F5A-7C53-469D-9511-BB63F88A14A0@gmail.com>
Message-ID: <1f2ed5cd0512040002o4651ed21vf5b91ed1a1a99e6f@mail.gmail.com>

---------- Forwarded message ----------
From: Richard Newman <holygoat@gmail.com>
Date: Dec 3, 2005 10:36 PM
Subject: Re: [uf-discuss] rel-tag for hierarchical categories
To: Danny Ayers <danny.ayers@gmail.com>
Cc: Microformats Discuss <microformats-discuss@microformats.org>


Danny, microformatters,
   I trust that <http://www.holygoat.co.uk/projects/tags/#example>
will suffice. I have included several levels, each of which is
'correct', though I would advise you to shy away from explicitly
using tags:taggedWithTag (I envisage this property as a logical
consequence of the reified versions). The reasoning behind this is
explained in the doc, but essentially can be summarised as "I don't
agree with your taggings, so one cannot simply state that "x is
tagged with y"". There is an act of tagging to be modelled.

   I would note that relating tags is precisely as subjective as
tagging resources, which means we need either to maintain provenance
and attribution (which RDF does not natively do), or to reify this
relation exactly as I reify tags:

   tag:httpsubscription tags:tagRelation
     [ a tags:TagRelation ;
       tags:relatedBy rich:RichardNewman ;
       tags:subCategoryOfTag tag:software ] .

   Please keep me CCed as appropriate, and ask questions as you wish.

-R

On 3 Dec 2005, at 05:23, Danny Ayers wrote:

> On 12/3/05, Kevin Marks <kmarks@technorati.com> wrote:
>
>> No, tagspaces are meant to be flat. If you want hierarchy you need
>> something else.
>
> I'm not sure "flat" is quite the right word.
>
> If you tag say a blog entry with "software" and "httpsubscription",
> the individual relationships are:
>
> <entry> taggedWith "software"
> <entry> taggedWith "httpsubscription"
>
> you could potentially view the combined tagging through either
> hierarchy:
>
> ./software/httpsubscription
> ./httpsubscription/software
>
> which would correspond to relationships in the tagging scheme of:
>
> "httpsubscription" subCategoryOf  "software"
> or
> "software" subCategoryOf "httpsubscription"
>
> If you use URIs for the categories, this can all fit nicely into
> the RDF graph.
>
> An individual tagging scheme, capturing the preferred hierarchy (using
> Turtle syntax):
>
> @prefix skos: <http://www.w3.org/2004/02/skos/core#"> .
>
> <http://example.org/software/httpsubscription> skos:broader
> <http://example.org/software> .
>
> A use of it:
>
> @prefix tags: <http://www.holygoat.co.uk/owl/redwood/0.1/tags/> .
>
> <http://example.com/blog/post/1> tags:tag
> <http://example.org/software/httpsubscription>
>
> Going down this route it's not difficult to extend into further
> information, like who did the tagging.
>
> [Rich - any chance of adding a minimal example or two to the ontology,
> right now it looks like you need to commit to the whole caboodle to be
> able to use it]
>
> Cheers,
> Danny.
>
> --
>
> http://dannyayers.com



--

http://dannyayers.com
From davidjanes at blogmatrix.com  Sun Dec  4 07:22:17 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sun Dec  4 07:20:21 2005
Subject: [uf-discuss] FYI: Fedora Directory Server 1.0
Message-ID: <439309A9.9020408@blogmatrix.com>

http://hardware.newsforge.com/newsvac/05/12/02/0241222.shtml

If someone was looking for microformats glory and knew Linux, sliding 
hCard in here for release 1.1 would be very sweet.

Regards, etc...
David
From davidjanes at blogmatrix.com  Sun Dec  4 09:15:41 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sun Dec  4 09:13:42 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>
References: <43843033.4080802@blogmatrix.com>
	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>
Message-ID: <4393243D.2000300@blogmatrix.com>

Ryan King wrote:
> On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote:
> 
>> Have at it:
>> http://microformats.org/wiki/hatom
> 
> Some comments (sorry, its taken me awhile to get to this):
> 
> 1. I notice that "feed title" and "feed permalink" have been deferred to 
> future versions (see http://microformats.org/wiki/hatom#Nomenclature). 
> Any reasons why? I must be missing something, 'cause these seem easy to me.

Honestly, I didn't find any consistent pattern and I didn't want to 
spend time figuring it out, so I deferred. If anyone wants to plug 
through the examples and try themselves...

> 
> 2. Not to pick nits, but datetime's probably don't *have to* use the 
> datetime-design-pattern. People who want to are free to publish the ISO

Fair enough; I've updated hAtom with a note. Note that to be consistent 
with the Atom Datetime Construct, the time must be specified to the second.

> 
> 3. I see that we're allowing multiple feeds per page. I wonder what the 
> pros and cons of this are?

It's a common pattern and offhand I don't foresee too many difficulties 
because most operations will be at the Entry level and disambiguatable 
(if that's a word) via. the Entry Permalink.

> 4. Why do we prefer <h#> over class="title" for entry titles?

See my earlier note. I'd really appreciate if you or Tantek got back to 
me here: my understanding is that we'd always prefer appropriate XHTML 
constructs.

> 
> 5. "Entry Permalinks MUST be absolute URIs". Why? We have well 
> established rules for relative urls.

I could lower this to SHOULD; feedback would be appreciated.

However, what I'm trying to accomplish is to let "rel-bookmark" provide 
byte comparable strings for providing "the best location for this resource".

The problem with relative URIs is that readers at 
"http://instapundit.com" and at "http://www.instapundit.com" will come 
up with two different sets of Entry Permalinks that are actually 
representing the same resources.

This even gets uglier with LiveJournal. I do recognize this may be an 
attempt at some mild social engineering on my part.

> 
> 6. quote:
>> there can be at most 1 Entry in an XHTML document without an Entry 
>> Permalink; the Entry Permalink of this Entry is the URI of the page
>> This rule is needed for media pages (i.e. a news article on cnn.com). 
>> There is some ugliness of with this because the URI could be 
>> non-canonical."
> 
> I'm not sure I follow this and don't see anything on the brainstorming 
> page about it.

It's in the blog-post-examples [1]. I'd like to make in practical for 
organizations such as CNN to markup pages such as [2] in hAtom without 
requiring them rewriting the way they do pages.

> 
> 7. "the machine readable datetime should be encoded with an <abbr> ". 
> Again, maybe this *should* should be a *may* ?

See 2.

> 
> 8. Open item for the list:
> 
>> if there is no Entry Updated and Entry Published elements, 
>> transformation to Atom is problematic
>> This is because a published element is required. Suggestions would be 
>> appreciated here.
> 
> Alright, so I'm going to stop before digging into the xmdp and parsing 
> details. Forgive me, david if any of this is ignorance.
> 

It's all great -- bring it on. I'm back in fighting shape :-)

Regards, etc...
David

[1] http://microformats.org/wiki/blog-post-examples#No_Entry_Permalink
[2] http://www.cnn.com/2005/US/12/03/katrina.townhall/index.html

From whoisstan at yahoo.com  Sun Dec  4 09:18:45 2005
From: whoisstan at yahoo.com (Mr Michael Wiechers)
Date: Sun Dec  4 09:18:47 2005
Subject: [uf-discuss] ninentdo mario kart DS microformat
In-Reply-To: <84ce626f0512031702y4761d4d3l40b1ddc4a38771d5@mail.gmail.com>
Message-ID: <20051204171845.52120.qmail@web60720.mail.yahoo.com>

Hey,
  
  I created a little description:
  http://www.merkwelt.com/people/stan/marioKartDSMicroformat.html
  
  So I guess I can write a little greasemonkey script that pop's up a  message when it finds a marioKartDS-ID element, probably showing the  hCard properties as well. Maybe linking to the player-stats if they are  available from nintendo.
  
  Does that make sense?
  
  Thanks,
  Stan

Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:  Hello,

On 12/3/05, Mr Michael Wiechers  wrote:
> Hey!
>
>  I like microformats. I had a microformat idea and wanted to run that by you
> to see if that this makes sense. I play Mario Kart on my Nintendo DS a lot,
> it allows you to play online with your friends. A friend is added to the
> system by entering a code, every person has a code.
>
>  Right now I just have the code on my personal website:
>  http://www.merkwelt.com/people/stan/   (first thing under
> whoisstan)
>
>  So I was thinking of replacing:
>  
 390901938389
>
>  with
>
>  

> class="marioKartDS">390901938389
>
>  Does that make sense, so I stumble over a personal website with that code I
> could have a bunch of games with that person. What I'm not clear on is how
> an application/robot could make sense of that?

Well, an application or robot could scan the page for tags/elements
that have the class "marioKartDS".  When it does, it then checks to
see if that element has a "title" attribute... if it does, it uses
that... if not, it uses the innerHTML.  Make sense?!  Here's some
JavaScript pseudo code:

    var elements = document.getElementsByClassName("marioKartDS");

    if ( elements && elements.length  ) {
        // We found some marioKartDS Microformats!

        for (var i=elements.length-1; i>-1; i--) {
            var code = elements[i].getAttribute("title");
            if ( ! code ) {
                code = elements[i].innerHTML;
            }

            // #### TODO #### Do something with the code you found. 
(Let's play :-)  )
        }
    }

Does that help?


> Say I would be using the
> geocode microformat as well and the "cuisine" microformat I would be able to
> find people that like vietnamese cuisine, live in new york and have a mario
> kart DS. Which kind of application do the aggregation and would allow me to
> run a query like that?

There may not be one that exists yet.  You could write your own (if
you are a software engineer).  You could make a webcrawler.  Or you
could make a user script (using greasemonkey).  Etc.

Also, various people on this lists are probably working on stuff like
this.  (So it may be just a matter of waiting a little while.)


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss



		
---------------------------------
 Yahoo! Personals
 Single? There's someone we'd like you to meet.
 Lots of someones, actually. Try Yahoo! Personals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051204/139f5b22/attachment.htm
From scott at randomchaos.com  Sun Dec  4 10:41:32 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Sun Dec  4 10:41:44 2005
Subject: [uf-discuss] Use title attribute in non-abbr tags?
Message-ID: <02A3EB2A-4F2E-4D60-A9C1-FDA40329539D@randomchaos.com>

I looked around on the wiki, and read Tantek's original explanation  
of using title in abbr tags [1], but I didn't find a clear answer to  
this.  Should title attribute values be preferred to internal text  
values in non-abbr tags when parsing microformats?  E.g. if a parser  
comes across something like <span title="Bob Smith" class="fn">Robert  
Smith</span>, should it take "Bob Smith", or "Robert Smith" as the  
value of the fn, or should that only be done if the tag is abbr?

Peace,
Scott

[1] http://tantek.com/log/2005/01.html#d26t0100
From tantek at cs.stanford.edu  Sun Dec  4 11:10:00 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sun Dec  4 11:10:21 2005
Subject: [uf-discuss] Use title attribute in non-abbr tags?
In-Reply-To: <02A3EB2A-4F2E-4D60-A9C1-FDA40329539D@randomchaos.com>
Message-ID: <BFB87EC4.647CC%tantek@cs.stanford.edu>

Side note: parsing discussions are typically more appropriate for the dev
list rather than the discuss list, redirecting discussion accordingly.


On 12/4/05 10:41 AM, "Scott Reynen" <scott@randomchaos.com> wrote:

> I looked around on the wiki, and read Tantek's original explanation
> of using title in abbr tags [1],
> [1] http://tantek.com/log/2005/01.html#d26t0100
> but I didn't find a clear answer to
> this.  Should title attribute values be preferred to internal text
> values in non-abbr tags when parsing microformats?

In general no.  We want to prefer the *visible* content over the
less-visible (title attribute) content. abbr is an exception, and even
should only be used when a more human-readable value is required in contrast
to a machine readable value.

For specifics, see the hCard parsing page, which has captured a lot of the
"general" approaches to parsing HTML for microformats.

 http://microformats.org/wiki/hcard-parsing

Once I finish writing the equivalent hcalendar-parsing, I'll take the
portions in common and move them to a more general "parsing" page.  Until
then, I'm solving the specific cases first, as that is a better way to
arrive at optimal (least wasteful) general rules, rather than figuring out
the general case first.


> E.g. if a parser 
> comes across something like <span title="Bob Smith" class="fn">Robert
> Smith</span>, should it take "Bob Smith", or "Robert Smith" as the
> value of the fn,

Robert Smith


> or should that only be done if the tag is abbr?

In general yes, but again, see the hcard-parsing page for details.

Thanks,

Tantek

From supercanadian at gmail.com  Sun Dec  4 11:21:20 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Sun Dec  4 11:21:23 2005
Subject: [uf-discuss] ninentdo mario kart DS microformat
In-Reply-To: <20051204171845.52120.qmail@web60720.mail.yahoo.com>
References: <84ce626f0512031702y4761d4d3l40b1ddc4a38771d5@mail.gmail.com>
	<20051204171845.52120.qmail@web60720.mail.yahoo.com>
Message-ID: <84ce626f0512041121g6b4a0c53m306675b572899e1b@mail.gmail.com>

Hello,

On 12/4/05, Mr Michael Wiechers <whoisstan@yahoo.com> wrote:
>
> Hey,
>
> I created a little description:
> http://www.merkwelt.com/people/stan/marioKartDSMicroformat.html
>
> So I guess I can write a little greasemonkey script that pop's up a
> message when it finds a marioKartDS-ID element, probably showing the hCard
> properties as well. Maybe linking to the player-stats if they are available
> from nintendo.
>
> Does that make sense?
>


Yeah, sounds good.

However, let me make one suggestions.  Although I don't think it is a rule,
people tend to choose lowercase names for class names.  For example, people
use "vcard" and not "vCard".  So perhaps you may want to use
"mariokartds-id" or "mario-kart-ds-id" or something like that (instead of
"marioKartDS-ID"),


See ya



Thanks,
> Stan
>
> *Charles Iliya Krempeaux <supercanadian@gmail.com>* wrote:
>
> Hello,
>
> On 12/3/05, Mr Michael Wiechers wrote:
> > Hey!
> >
> > I like microformats. I had a microformat idea and wanted to run that by
> you
> > to see if that this makes sense. I play Mario Kart on my Nintendo DS a
> lot,
> > it allows you to play online with your friends. A friend is added to the
> > system by entering a code, every person has a code.
> >
> > Right now I just have the code on my personal website:
> > http://www.merkwelt.com/people/stan/ (first thing under
> > whoisstan)
> >
> > So I was thinking of replacing:
> >
> 390901938389
> >
> > with
> >
> >
>
> > class="marioKartDS">390901938389
> >
> > Does that make sense, so I stumble over a personal website with that
> code I
> > could have a bunch of games with that person. What I'm not clear on is
> how
> > an application/robot could make sense of that?
>
> Well, an application or robot could scan the page for tags/elements
> that have the class "marioKartDS". When it does, it then checks to
> see if that element has a "title" attribute... if it does, it uses
> that... if not, it uses the innerHTML. Make sense?! Here's some
> JavaScript pseudo code:
>
> var elements = document.getElementsByClassName("marioKartDS");
>
> if ( elements && elements.length ) {
> // We found some marioKartDS Microformats!
>
> for (var i=elements.length-1; i>-1; i--) {
> var code = elements[i].getAttribute("title");
> if ( ! code ) {
> code = elements[i].innerHTML;
> }
>
> // #### TODO #### Do something with the code you found.
> (Let's play :-) )
> }
> }
>
> Does that help?
>
>
> > Say I would be using the
> > geocode microformat as well and the "cuisine" microformat I would be
> able to
> > find people that like vietnamese cuisine, live in new york and have a
> mario
> > kart DS. Which kind of application do the aggregation and would allow me
> to
> > run a query like that?
>
> There may not be one that exists yet. You could write your own (if
> you are a software engineer). You could make a webcrawler. Or you
> could make a user script (using greasemonkey). Etc.
>
> Also, various people on this lists are probably working on stuff like
> this. (So it may be just a matter of waiting a little while.)
>
>
> See ya
>
> --
> Charles Iliya Krempeaux, B.Sc.
>
> charles @ reptile.ca
> supercanadian @ gmail.com
>
> developer weblog: http://ChangeLog.ca/
>
> ___________________________________________________________________________
> Never forget where you came from
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
> ------------------------------
> *Yahoo! Personals*
> Single? There's someone we'd like you to meet.
> Lots of someones, actually. Try Yahoo! Personals<http://us.rd.yahoo.com/evt=36108/*http://personals.yahoo.com+%0D%0A>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
Never forget where you came from
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051204/76590a45/attachment.htm
From scott at randomchaos.com  Sun Dec  4 11:29:33 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Sun Dec  4 11:29:39 2005
Subject: [uf-discuss] Microformat Base
In-Reply-To: <8b18dc20512031118l209c2d87rce17f215a52f6a05@mail.gmail.com>
References: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
	<8b18dc20512031118l209c2d87rce17f215a52f6a05@mail.gmail.com>
Message-ID: <4F05D139-6409-4AFB-88A1-C8D277E9DB88@randomchaos.com>

Tantek ?elik wrote:

> Consider adding hReview as well!

I did that.  I also cleared out all the data and changed it so it  
doesn't follow links from sites with no microformats, in an attempt  
to limit the scope a bit. Turns out I don't have the storage space to  
catalog every URL on the web.  Anything not connected to  
microformats.org via pages containing microformats can still be added  
manually, and I made a simple submission form for that [1].

Craig Ogg wrote:

> On 12/1/05, Scott Reynen <scott@randomchaos.com> wrote:
>> I thought I'd go ahead and play around with a microformat-based
>> alternative to Google Base.  So far, I have a basic spider that I set
>> loose from microformats.org to slowly wander the web.  When it finds
>> any known microformat-associated class names, it records the data
>> which can then be searched here:
>
> This is very cool, but I don't think it is really an alternative to
> Google Base.

I don't think it's a viable alternative myself.  I wrote in my  
weblog: "One suggestion, popular - of course - among the microformats  
community, was that Google could use microformats to remove the need  
for submission to their base and leverage the distributed nature of  
the web. Personally, I suspect there's just not enough microformatted  
content out there yet to make it worth Google's cycles parsing  
it." [2].  But I thought it better to try and prove myself wrong with  
some code than to just speculate about it.

Peace,
Scott

[1] http://www.randomchaos.com/microformats/base/
[2] http://weblog.randomchaos.com/archive/2005/11/30/Microformat_Base/
From ryan at technorati.com  Sun Dec  4 14:12:15 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Dec  4 14:12:18 2005
Subject: [uf-discuss] Vote-Links use cases ?
In-Reply-To: <84ce626f0512030107r6db5b7cekb7be2778bf28c634@mail.gmail.com>
References: <84ce626f0512030107r6db5b7cekb7be2778bf28c634@mail.gmail.com>
Message-ID: <7D8F27A2-E2FE-4588-B9F7-1DA2BE8C2849@technorati.com>

On Dec 3, 2005, at 1:07 AM, Charles Iliya Krempeaux wrote:

> Hello,
>
> Just wondering if there's a list of use cases for vote-links  
> somewhere?
>
> For example, are vote-links just a better version of rel-nofollow.
> (With rel="nofollow" being equivalent to rev="vote-against".)  Or are
> there other use cases.

The first use I ever heard of was Technorati doing a distributed poll  
during the last US election.  Tantek mentioned it here [http:// 
tantek.com/log/2004/11.html#d01t2339]. It is, of course, dead now.

And on the topic of vote-links vs. relnofollow, notice that vote- 
links are actually older than relNoFollow. :D

-ryan
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Sun Dec  4 14:47:07 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Dec  4 14:47:10 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <4393243D.2000300@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>
	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>
	<4393243D.2000300@blogmatrix.com>
Message-ID: <1D13ADC2-8902-4EC8-A415-5E1FAEE6110C@technorati.com>

On Dec 4, 2005, at 9:15 AM, David Janes -- BlogMatrix wrote:
> Ryan King wrote:
>> 4. Why do we prefer <h#> over class="title" for entry titles?
>
> See my earlier note. I'd really appreciate if you or Tantek got  
> back to me here: my understanding is that we'd always prefer  
> appropriate XHTML constructs.

Yes, I'd say we should prefer the appropriate html construct.

In this particular case, though, I'm afraid using <h#> is a bit  
brittle- this is coming from helping triage support requests coming  
into Technorati about us not indexing their blog properly. For this  
particular element I would prefer:

1. an explicit classname (most people are using a classname already,  
no?)
2. fallback to <h#>

I think the explicit declaration should be preferred, but this is  
just a suggestion. I know that other xhtml-syndication efforts have  
used <h#> for entry titles, but I'm not sure of their success. Anyone  
with experience here, please speak up.

>> 5. "Entry Permalinks MUST be absolute URIs". Why? We have well  
>> established rules for relative urls.
>
> I could lower this to SHOULD; feedback would be appreciated.

I think requiring absolute URIs is a bit too high a hurdle, not not  
quite neccessary.

> However, what I'm trying to accomplish is to let "rel-bookmark"  
> provide byte comparable strings for providing "the best location  
> for this resource".

Like I said, the rules for transforming relative URIs to absolute  
ones are pretty well established, so any consumer should be able to  
take care of this for themselves. I think this is just a case where  
we need to optimize for the publisher over the consumer.

> The problem with relative URIs is that readers at "http:// 
> instapundit.com" and at "http://www.instapundit.com" will come up  
> with two different sets of Entry Permalinks that are actually  
> representing the same resources.
>
> This even gets uglier with LiveJournal. I do recognize this may be  
> an attempt at some mild social engineering on my part.

FWIW, there has been some (offline and on-) discussion about a rel- 
canonical microformat. Maybe hAtom should defer this problem (*it is*  
bigger than just atom/blogs).

>> 6. quote:
>>> there can be at most 1 Entry in an XHTML document without an  
>>> Entry Permalink; the Entry Permalink of this Entry is the URI of  
>>> the page
>>> This rule is needed for media pages (i.e. a news article on  
>>> cnn.com). There is some ugliness of with this because the URI  
>>> could be non-canonical."
>> I'm not sure I follow this and don't see anything on the  
>> brainstorming page about it.
>
> It's in the blog-post-examples [1]. I'd like to make in practical  
> for organizations such as CNN to markup pages such as [2] in hAtom  
> without requiring them rewriting the way they do pages.

So the use-case is a "document with one entry"? Is this really worth  
making a general rule about?

> ...
> It's all great -- bring it on. I'm back in fighting shape :-)

Great.

-ryan
--
Ryan King
ryan@technorati.com
From ryan at technorati.com  Sun Dec  4 14:57:53 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Dec  4 14:57:55 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
	<1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
Message-ID: <DA5193B8-650C-41C4-9E9F-962D5DF22CB5@technorati.com>

On Dec 3, 2005, at 10:23 AM, Chris Messina wrote:
> Perhaps rel-enclosure doesn't actually make sense long term. Given
> that relEnclosure, AFAIK, was grafted onto RSS to allow for media
> being "attached" to feeds, rel-enclosure doesn't make sense in your
> regular browser-consumed webpages because we've got <embed> and
> <object>. If RSS had been able to support inline rich media, wouldn't
> those tags have sufficed?
>
> It also seems that relEnclosure was about behavior on the client side
> and less about semantics.

That depends on what you mean by "semantics." :D

> Let's presume for a minute that we've got infinite bandwidth and
> infinite storage. In such a world, all embedded media (and hrefs)
> would be able to be pulled in and cached automagically. In which case
> the need for delayed media downloading would be much less, so even if
> you're syncing your 8,000  feeds,  which all contain rich media like
> podcasts and vcasts, you would theoretically be able to pull all that
> data down anyway for later consumption.
>
> So the question is, what is the most effective way to link to that
> media? Indeed, will the media itself supplant the textual content of
> the feed?

In the case of podcasts/vlogs, I'd say yes. The media file is primary.

> Will feeds simply become the distribution method for rich
> media or eventually get into a TV-for-the-web model where you pick
> people to subscribe to and can "tune in" to an aggregate stream of
> them whenever you like?

Uh, this is already possible with podcasting/vlogging.

> I dunno, and I suppose I'm getting a little
> off topic here.

Yeah. Media revolution is off topic. :D

> So here's what I'm thinking when it comes down to it (now that you
> know what I'm looking at in the future)... Shouldn't relEnclosures
> just be converted to <object> or <embed> tags when they're pulled into
> xhtml?

Eh, don't think so. The use case for enclosures (at least for me) has  
been for the UA to download and queue the media file up for later  
consumption.

> Isn't that what the original intention (and indeed, behavior)
> actually implies? Wasn't the original problem one of embedding rich
> media in RSS and so therefore, relEnclosure is actually made obsolete
> when ported to the world of XHTML microformats?

I don't think so. I think there's still a place for enclosures in  
html. Just like, thought we can send HTML, RTF or PDF (*shudder*),  
attachments are still useful.

> Anyway, sorry to go on and on, must be the Parisien air. ;)

Or the wine.

-ryan
--
Ryan King
ryan@technorati.com



From supercanadian at gmail.com  Sun Dec  4 15:01:59 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Sun Dec  4 15:02:00 2005
Subject: [uf-discuss] Vote-Links use cases ?
In-Reply-To: <7D8F27A2-E2FE-4588-B9F7-1DA2BE8C2849@technorati.com>
References: <84ce626f0512030107r6db5b7cekb7be2778bf28c634@mail.gmail.com>
	<7D8F27A2-E2FE-4588-B9F7-1DA2BE8C2849@technorati.com>
Message-ID: <84ce626f0512041501g4f46fa0bx9677d2c627410a77@mail.gmail.com>

Hello,

On 12/4/05, Ryan King <ryan@technorati.com> wrote:
> On Dec 3, 2005, at 1:07 AM, Charles Iliya Krempeaux wrote:
>
> > Hello,
> >
> > Just wondering if there's a list of use cases for vote-links
> > somewhere?
> >
> > For example, are vote-links just a better version of rel-nofollow.
> > (With rel="nofollow" being equivalent to rev="vote-against".)  Or are
> > there other use cases.
>
> The first use I ever heard of was Technorati doing a distributed poll
> during the last US election.  Tantek mentioned it here [http://
> tantek.com/log/2004/11.html#d01t2339]. It is, of course, dead now.

I should probably read Tantek's blog more :-)

I was actually thinking of using for something along these lines.  So,
for example, (in Canadian politics) a person could express the "view"
on a bill like:

    I am against <a rev="vote-against"
href="http://laws.justice.gc.ca/en/1995/39/">Bill C-68</a>.


> And on the topic of vote-links vs. relnofollow, notice that vote-
> links are actually older than relNoFollow. :D

Didn't know that.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From kmarks at technorati.com  Sun Dec  4 17:45:46 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Sun Dec  4 17:45:50 2005
Subject: [uf-discuss] Vote-Links use cases ?
In-Reply-To: <84ce626f0512041501g4f46fa0bx9677d2c627410a77@mail.gmail.com>
References: <84ce626f0512030107r6db5b7cekb7be2778bf28c634@mail.gmail.com>
	<7D8F27A2-E2FE-4588-B9F7-1DA2BE8C2849@technorati.com>
	<84ce626f0512041501g4f46fa0bx9677d2c627410a77@mail.gmail.com>
Message-ID: <f11c53ab98b4eb62f80d0080f98a750f@technorati.com>


On Dec 4, 2005, at 3:01 PM, Charles Iliya Krempeaux wrote:
> On 12/4/05, Ryan King <ryan@technorati.com> wrote:
>> On Dec 3, 2005, at 1:07 AM, Charles Iliya Krempeaux wrote:
>>> For example, are vote-links just a better version of rel-nofollow.
>>> (With rel="nofollow" being equivalent to rev="vote-against".)  Or are
>>> there other use cases.

Actually rel="nofollow' is equivalent to rev="vote-abstain". It means 
that the status is not asserted by the page.

> I was actually thinking of using for something along these lines.  So,
> for example, (in Canadian politics) a person could express the "view"
> on a bill like:
>
>     I am against <a rev="vote-against"
> href="http://laws.justice.gc.ca/en/1995/39/">Bill C-68</a>.

That would be a splendid use for them.

>> And on the topic of vote-links vs. relnofollow, notice that vote-
>> links are actually older than relNoFollow. :D

The original discussion is here:

http://epeus.blogspot.com/2003_03_01_epeus_archive.html#90699163

This is before vote links got a proper HTML syntax

From chris.messina at gmail.com  Sun Dec  4 22:10:37 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Sun Dec  4 22:10:38 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <DA5193B8-650C-41C4-9E9F-962D5DF22CB5@technorati.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
	<1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
	<DA5193B8-650C-41C4-9E9F-962D5DF22CB5@technorati.com>
Message-ID: <1bc4603e0512042210n57401206jc80443ea6b063785@mail.gmail.com>

On 12/4/05, Ryan King <ryan@technorati.com> wrote:

> > So here's what I'm thinking when it comes down to it (now that you
> > know what I'm looking at in the future)... Shouldn't relEnclosures
> > just be converted to <object> or <embed> tags when they're pulled into
> > xhtml?
>
> Eh, don't think so. The use case for enclosures (at least for me) has
> been for the UA to download and queue the media file up for later
> consumption.

Thanks. This discussion has been illucidating -- and perhaps helpful
in other ways...

Hmm. But did we make any progress on the original topic?

Chris
From chris.messina at gmail.com  Mon Dec  5 01:10:18 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Mon Dec  5 01:10:20 2005
Subject: [uf-discuss] Microformat Base
In-Reply-To: <4F05D139-6409-4AFB-88A1-C8D277E9DB88@randomchaos.com>
References: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
	<8b18dc20512031118l209c2d87rce17f215a52f6a05@mail.gmail.com>
	<4F05D139-6409-4AFB-88A1-C8D277E9DB88@randomchaos.com>
Message-ID: <1bc4603e0512050110w2a36beb8j716199672378800e@mail.gmail.com>

On 12/4/05, Scott Reynen <scott@randomchaos.com> wrote:

> Personally, I suspect there's just not enough microformatted
> content out there yet to make it worth Google's cycles parsing
> it." [2].  But I thought it better to try and prove myself wrong with
> some code than to just speculate about it.

Um, why are we waiting for Google? I mean, besides technorati, aren't
microformats kind of the next frontier for "smart" search engines?

The "web as distributed database" sounds pretty damn appealing to me.

Chris
From supercanadian at gmail.com  Mon Dec  5 01:30:38 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Mon Dec  5 01:30:40 2005
Subject: [uf-discuss] Microformat Base
In-Reply-To: <1bc4603e0512050110w2a36beb8j716199672378800e@mail.gmail.com>
References: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
	<8b18dc20512031118l209c2d87rce17f215a52f6a05@mail.gmail.com>
	<4F05D139-6409-4AFB-88A1-C8D277E9DB88@randomchaos.com>
	<1bc4603e0512050110w2a36beb8j716199672378800e@mail.gmail.com>
Message-ID: <84ce626f0512050130g3a8d4d55p18f048d90b169cee@mail.gmail.com>

Hello,

On 12/5/05, Chris Messina <chris.messina@gmail.com> wrote:
> On 12/4/05, Scott Reynen <scott@randomchaos.com> wrote:
>
> > Personally, I suspect there's just not enough microformatted
> > content out there yet to make it worth Google's cycles parsing
> > it." [2].  But I thought it better to try and prove myself wrong with
> > some code than to just speculate about it.
>
> Um, why are we waiting for Google? I mean, besides technorati, aren't
> microformats kind of the next frontier for "smart" search engines?
>
> The "web as distributed database" sounds pretty damn appealing to me.

If you want to search all of it, and want to do it in a reasonable
amount of time, indexing helps.  (Doesn't matter if the database is
distributed or not.)  (You could always use distributing indexing if
you wanted though.  I don't know how much existing usage it has on the
web though... but it is certainly doable.)

Also, you don't need to wait for anyone... but it will take some
effort when you deal with data sets of those sizes.  Dealing with
scalability issues with live systems can be an effort too.  (And can
sometimes be a pain.  I just finished a huge project to improve
scalability on a live system that didn't go completely smoothly,... so
I feel for anyone who's had to deal with this.)


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From davidjanes at blogmatrix.com  Mon Dec  5 03:54:14 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Mon Dec  5 03:52:15 2005
Subject: [uf-discuss] Fwd: Uploading the Semantic Web into Google Base?
Message-ID: <43942A66.8050308@blogmatrix.com>

I'm forwarding this e-mail from the semantic web mailing list as there 
seems to be some interesting ideas that can be drawn upon.

Here's [1] an example FOAF profile on Google Base. Looks very doable for 
hCards, no?

Regards, etc...
David
http://www.blogmatrix.com

[1] http://base.google.com/base/items?oid=18377492770755894565

-------- Original Message --------
Subject: 	Uploading the Semantic Web into Google Base?
Resent-Date: 	Mon, 05 Dec 2005 09:44:43 +0000
Resent-From: 	semantic-web@w3.org
Date: 	Mon, 5 Dec 2005 10:38:48 +0100
From: 	Chris Bizer <bizer@zedat.fu-berlin.de>
To: 	<semantic-web@w3.org>



Hi all,

we have developed a crawler that collects FOAF profiles from the Web and
uploads them into Google Base.

The profiles that our crawler has uploaded so far are found at:
http://base.google.com/base/search?authorid=1107889

It's nice to see how geo coordinates in the profiles get rendered as Google
maps: http://base.google.com/base/items?oid=396209429990798149
And it's strange to "own" Tim Berners-Lees profile on Google Base ;-)
http://base.google.com/base/items?oid=12665418913991123756

If you want us to upload your profile also, please add it to the FOAF
Bulletin Board http://rdfweb.org/topic/FOAFBulletinBoard and it will be
included in our next crawler run. If you want to be removed from Google
Base, please send us a mail and we will remove you.

It's strange that there hasn't been too much discussion in the Semantic Web
community about Google base yet. Should we be happy, that Google provides us
with a fast repository and a nice search interface? Or should we be critical
because a single company is trying to gain a dominant market position by
building a single central Web data repository? Should we be happy that
Google is promoting the idea of publishing structured information on the
Web? Or should we be critical to their (over-)simplification of the RDF data
model?

All comments are welcome.

Cheers,

Chris Bizer and Richard Cyganiak

-- 
Chris Bizer
Freie Universit?t Berlin
Phone: +49 30 838 54057
Mail: chris@bizer.de
Web: www.bizer.de



From solitude at solitude.dk  Mon Dec  5 04:03:58 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Mon Dec  5 04:04:09 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
Message-ID: <op.s1a7swpgares2h@mail.solitude.dk>

On Fri, 02 Dec 2005 19:56:40 +0100, Ryan King <ryan@technorati.com> wrote:

> I don't think your relEnclosure and http://microformats.org/wiki/rel- 
> enclosure are that different, they're just explained differently. Also,  
> I think they're close enough to be resolved. You want to work on that?

No, not very different, but enough for me to write emails about. :o)
If by work on it you mean "change wiki text to my fitting" or "email Kevin  
Marks and talk" then I can totally put that on my todo list. If by work  
you mean "analyze how people are talking about enclosures and how they are  
using them" then I don't have the time to work on it...

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From scott at randomchaos.com  Mon Dec  5 05:47:39 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Mon Dec  5 05:47:46 2005
Subject: [uf-discuss] Bases
In-Reply-To: <43942A66.8050308@blogmatrix.com>
References: <43942A66.8050308@blogmatrix.com>
Message-ID: <024E688F-3539-4006-BF8A-543DA257E91B@randomchaos.com>

Charles Iliya Krempeaux wrote:

> On 12/5/05, Chris Messina <chris.messina@gmail.com> wrote:
>> On 12/4/05, Scott Reynen <scott@randomchaos.com> wrote:
>>
>>> Personally, I suspect there's just not enough microformatted
>>> content out there yet to make it worth Google's cycles parsing
>>> it." [2].  But I thought it better to try and prove myself wrong  
>>> with
>>> some code than to just speculate about it.
>>
>> Um, why are we waiting for Google? I mean, besides technorati, aren't
>> microformats kind of the next frontier for "smart" search engines?
>>
>> The "web as distributed database" sounds pretty damn appealing to me.
>
> If you want to search all of it, and want to do it in a reasonable
> amount of time, indexing helps.

Right, that's the first problem I ran into.  If you want to crawl the  
whole web, you have to index the whole web.  And there's not enough  
microformatted data out there to be worth indexing the whole web to  
get at it.  Even restricting the crawler to one node away from a  
found microformat, only 293 out of 5163 (5%) URLs currently contain  
microformats.  Crawling the entire web, that percentage quickly  
approaches zero.  Google Base, on the other hand, gets valuable  
structured data out of 100% of submissions.  Advantage Google.

David Janes -- BlogMatrix wrote:

> we have developed a crawler that collects FOAF profiles from the  
> Web and
> uploads them into Google Base.

I've been thinking about doing the same with the Microformat Base  
data, but I don't really care to deal with the potential copyright  
issues:

> If you want to be removed from Google Base, please send us a mail  
> and we will remove you.

If anyone else wants to be responsible for that, I'd be glad to make  
an Atom feed of hCards, which you could convert to a Google Base  
upload format.

Peace,
Scott
From ryan at technorati.com  Mon Dec  5 09:03:20 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Dec  5 09:03:31 2005
Subject: [uf-discuss] Microformat Base
In-Reply-To: <1bc4603e0512050110w2a36beb8j716199672378800e@mail.gmail.com>
References: <E9B6E3DE-38FA-4796-81DF-F869226FFA72@randomchaos.com>
	<8b18dc20512031118l209c2d87rce17f215a52f6a05@mail.gmail.com>
	<4F05D139-6409-4AFB-88A1-C8D277E9DB88@randomchaos.com>
	<1bc4603e0512050110w2a36beb8j716199672378800e@mail.gmail.com>
Message-ID: <34A4B622-D5D1-41EC-8735-C2F495E95B01@technorati.com>

On Dec 5, 2005, at 1:10 AM, Chris Messina wrote:
> On 12/4/05, Scott Reynen <scott@randomchaos.com> wrote:
>
>> Personally, I suspect there's just not enough microformatted
>> content out there yet to make it worth Google's cycles parsing
>> it." [2].  But I thought it better to try and prove myself wrong with
>> some code than to just speculate about it.
>
> Um, why are we waiting for Google? I mean, besides technorati, aren't
> microformats kind of the next frontier for "smart" search engines?

Um, I don't think Scott's waiting, he's already built a spider to  
index a bunch of ?f's.

> The "web as distributed database" sounds pretty damn appealing to me.

Still gotta index stuff.

-ryan
--
Ryan King
ryan@technorati.com



From kennyheaton at gmail.com  Mon Dec  5 09:47:49 2005
From: kennyheaton at gmail.com (kenny heaton)
Date: Mon Dec  5 09:48:01 2005
Subject: [uf-discuss] Goods and Products microformat
Message-ID: <65b4e01f0512050947l3a7d6946ode506b1f11f0d09b@mail.gmail.com>

I work for a hardware manufacturer and as I think about microformats
and how to use them, one of the first things that comes to mind is a
way do describe our products. I've searched around a bit and haven't
found any examples of a standard way to describe
goods/products/merchandise and feel this would be very valuable. I did
find this on using RSS to syndicate a catalog of items which I see as
a good next step after there is a way to describe individual items.

http://ifindkarma.typepad.com/relax/2004/07/catablog.html

The way I see it there are two approaches; a format for generally
describing anything and everything form houses to pin-cushions, or a
format for each type of product (example, a house description format,
a car discretion format, etc..)

Since there is now way to keep up with the amount things that there
are to describe, I think having a general format is a good idea. I
know general considered bad, and specific is better so I would
appreciate feed back on this thought, but I can't think of any other
way to allow someone to describe the what-cha-ma-call-it they just
invented. I also think that specific formats for describing common
things is needed, so someone can easily compare two DVD players for
example. So things like houses, cars, electronics etc.. might have a
more specific microformat derived form the genial product format, that
describes them more specifically.

My first thoughts are that most all product have a set of basic
information in common: a name, a summary including a description of
use, a list of specific features, manufacturer or re-seller name, and
copyright or legal information.

These are just my first thoughts, and I feel there is a real need for
this, but I would love to hear what others think, or if anyone know of
something along these lines.

Kenny
From ryan at technorati.com  Mon Dec  5 11:08:57 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Dec  5 11:08:59 2005
Subject: [uf-discuss] Goods and Products microformat
In-Reply-To: <65b4e01f0512050947l3a7d6946ode506b1f11f0d09b@mail.gmail.com>
References: <65b4e01f0512050947l3a7d6946ode506b1f11f0d09b@mail.gmail.com>
Message-ID: <C1501D72-F12F-4DAF-8DC5-CB5E06E5B1DF@technorati.com>

On Dec 5, 2005, at 9:47 AM, kenny heaton wrote:

> I work for a hardware manufacturer and as I think about microformats
> and how to use them, one of the first things that comes to mind is a
> way do describe our products. I've searched around a bit and haven't
> found any examples of a standard way to describe
> goods/products/merchandise and feel this would be very valuable. I did
> find this on using RSS to syndicate a catalog of items which I see as
> a good next step after there is a way to describe individual items.
>
> http://ifindkarma.typepad.com/relax/2004/07/catablog.html
>
> The way I see it there are two approaches; a format for generally
> describing anything and everything form houses to pin-cushions, or a
> format for each type of product (example, a house description format,
> a car discretion format, etc..)

The words "anything and everything" make me think "open-ended  
problem," which makes me think that a microformat may not be feasible.

Specific formats for specific products seems to be more the  
Microformat Way (TM).

> Since there is now way to keep up with the amount things that there
> are to describe, I think having a general format is a good idea. I
> know general considered bad, and specific is better so I would
> appreciate feed back on this thought, but I can't think of any other
> way to allow someone to describe the what-cha-ma-call-it they just
> invented. I also think that specific formats for describing common
> things is needed, so someone can easily compare two DVD players for
> example. So things like houses, cars, electronics etc.. might have a
> more specific microformat derived form the genial product format, that
> describes them more specifically.
>
> My first thoughts are that most all product have a set of basic
> information in common: a name, a summary including a description of
> use, a list of specific features, manufacturer or re-seller name, and
> copyright or legal information.

Ironically, the basic schema sounds alot like hreview [http:// 
microformats.org/wiki/hreview].

Could product listings be like reviews by the manufacturer/seller?

> These are just my first thoughts, and I feel there is a real need for
> this, but I would love to hear what others think, or if anyone know of
> something along these lines.

I'm sure there's tons of prior art, but very little in terms of  
widely adopted formats. There's already been some reasearch done on  
"listings" (where the use-case is more craigslist-like):

http://microformats.org/wiki/listing-examples
http://microformats.org/wiki/listing-formats
http://microformats.org/wiki/listing-brainstorming

Have a look and see what you can contribute.

-ryan
--
Ryan King
ryan@technorati.com



From kennyheaton at gmail.com  Mon Dec  5 11:33:40 2005
From: kennyheaton at gmail.com (kenny heaton)
Date: Mon Dec  5 11:33:44 2005
Subject: [uf-discuss] Goods and Products microformat
In-Reply-To: <C1501D72-F12F-4DAF-8DC5-CB5E06E5B1DF@technorati.com>
References: <65b4e01f0512050947l3a7d6946ode506b1f11f0d09b@mail.gmail.com>
	<C1501D72-F12F-4DAF-8DC5-CB5E06E5B1DF@technorati.com>
Message-ID: <65b4e01f0512051133p3d25688do5b5cb80c9adbf0c2@mail.gmail.com>

Thanks for your reply Ryan. I had looked at hreview and listing and I
felt hreview was not appropriate for what I was thinking because it
lack some specifics about product features I felt important and has
things like reviewer and rating which wouldn't quite fit for a company
talking about it's own products. I thought listing was not quite right
either because it was geared more toward something like craigslist,
but after a second look I think it might work, although it seems to
have the potential for being very open ended itself.

Thanks for the feedback.

Kenny
From tantek at cs.stanford.edu  Mon Dec  5 12:03:50 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Dec  5 12:04:15 2005
Subject: [uf-discuss] Goods and Products microformat
In-Reply-To: <65b4e01f0512051133p3d25688do5b5cb80c9adbf0c2@mail.gmail.com>
Message-ID: <BFB9D89C.6485D%tantek@cs.stanford.edu>

On 12/5/05 11:33 AM, "kenny heaton" <kennyheaton@gmail.com> wrote:

> Thanks for your reply Ryan. I had looked at hreview and listing and I
> felt hreview was not appropriate for what I was thinking because it
> lack some specifics about product features I felt important and has
> things like reviewer and rating which wouldn't quite fit for a company
> talking about it's own products. I thought listing was not quite right
> either because it was geared more toward something like craigslist,
> but after a second look I think it might work, although it seems to
> have the potential for being very open ended itself.

I think the "listing" efforts are closest to what you are looking for.

By the way, anytime you find yourself wanting to make something "general" or
being able to describe "arbitrary" "features", considering simply using
tags.

E.g. you may want consider simply trying to use xFolk on the URLs of the
products, along with tags for the "features" of those products.

That's one way to avoid the whole defining a comprehensive product / product
feature taxonomy problem.

Thanks,

Tantek

From ryan at technorati.com  Mon Dec  5 12:25:03 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Dec  5 12:25:06 2005
Subject: [uf-discuss] Goods and Products microformat
In-Reply-To: <65b4e01f0512051133p3d25688do5b5cb80c9adbf0c2@mail.gmail.com>
References: <65b4e01f0512050947l3a7d6946ode506b1f11f0d09b@mail.gmail.com>
	<C1501D72-F12F-4DAF-8DC5-CB5E06E5B1DF@technorati.com>
	<65b4e01f0512051133p3d25688do5b5cb80c9adbf0c2@mail.gmail.com>
Message-ID: <85F3508B-BA10-4217-88A3-9407C586AF41@technorati.com>

On Dec 5, 2005, at 11:33 AM, kenny heaton wrote:

> Thanks for your reply Ryan. I had looked at hreview and listing and I
> felt hreview was not appropriate for what I was thinking because it
> lack some specifics about product features I felt important and has
> things like reviewer and rating which wouldn't quite fit for a company
> talking about it's own products.

My point was just that it could be a useful starting point, which  
could be extended. Rating is, of course optional and "reviewer" could  
just be the company. Don't dismiss it too easily.

> I thought listing was not quite right
> either because it was geared more toward something like craigslist,
> but after a second look I think it might work, although it seems to
> have the potential for being very open ended itself.

The listings stuff is still just research, so it can certainly be  
influenced.

-ryan

--
Ryan King
ryan@technorati.com



From kmarks at technorati.com  Mon Dec  5 13:23:28 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Mon Dec  5 13:23:31 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <84ce626f0512031351y28f91868t10f4f5c3f16da6cd@mail.gmail.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<1bc4603e0512010938x306154dapa31fa757cf21105a@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
	<1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
	<84ce626f0512031351y28f91868t10f4f5c3f16da6cd@mail.gmail.com>
Message-ID: <280d35437a8ed2797f9c99644b5b3149@technorati.com>

OK, this brings us to the heart of Podcasting. For much discussion, see 
the last two videos with rel="enclosure" on my blog...

On Dec 3, 2005, at 1:51 PM, Charles Iliya Krempeaux wrote:
> On 12/3/05, Chris Messina <chris.messina@gmail.com> wrote:
>> On 12/2/05, Ryan King <ryan@technorati.com> wrote:
>>> I don't think your relEnclosure and http://microformats.org/wiki/rel-
>>> enclosure are that different, they're just explained differently.
>>> Also, I think they're close enough to be resolved. You want to work
>>> on that?

Yes, the meaning is the same. If we can revise the wording to make this 
clearer, good.

>> Perhaps rel-enclosure doesn't actually make sense long term. Given
>> that relEnclosure, AFAIK, was grafted onto RSS to allow for media
>> being "attached" to feeds, rel-enclosure doesn't make sense in your
>> regular browser-consumed webpages because we've got <embed> and
>> <object>. If RSS had been able to support inline rich media, wouldn't
>> those tags have sufficed?
>
> No.  In RSS, enclosures instruct the client to pre-download the media,
> (but says nothing about "playing" it).  Both <embed> and <object> say
> "play" the media (and say nothing about pre-downloading it AFAIK).
>
> To me, there are 2 orthogonal concepts here.  One is pre-downloading
> it.  And the other is "playing" it.
>
> It was my (perhaps naive) understanding that rel-enclosure was an
> attempt to add pre-downloading to HTML.

It is for pre-downloading, and also to imply synchronisation to a 
non-browser client. The goal is to enable transparent playback of media 
you subscribe to, with no waiting. In other words, the 'playing new 
stuff to me on my bike ride to work' scenario.

>> It also seems that relEnclosure was about behavior on the client side
>> and less about semantics.
>>
>> Let's presume for a minute that we've got infinite bandwidth
>
> If that was the case, then, you would NOT need RSS enclosures.
>
>> and
>> infinite storage. In such a world, all embedded media (and hrefs)
>> would be able to be pulled in and cached automagically. In which case
>> the need for delayed media downloading would be much less, so even if
>> you're syncing your 8,000  feeds,  which all contain rich media like
>> podcasts and vcasts, you would theoretically be able to pull all that
>> data down anyway for later consumption.
>>
>> So the question is, what is the most effective way to link to that
>> media? Indeed, will the media itself supplant the textual content of
>> the feed?

The textual content becomes annotation fro the media, in a podcast, 
which has beneficial effects: it is indexable by search engines and 
other tools that can read HTML (instead of having to spelunk thorugh 
giant binary media files looking for metadata)

>> Will feeds simply become the distribution method for rich
>> media or eventually get into a TV-for-the-web model where you pick
>> people to subscribe to and can "tune in" to an aggregate stream of
>> them whenever you like? I dunno, and I suppose I'm getting a little
>> off topic here.

They already are - see DTV

>> So here's what I'm thinking when it comes down to it (now that you
>> know what I'm looking at in the future)... Shouldn't relEnclosures
>> just be converted to <object> or <embed> tags when they're pulled into
>> xhtml?
>
> I'd say no.

No, that's missing the point.

From supercanadian at gmail.com  Mon Dec  5 15:50:31 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Mon Dec  5 15:50:35 2005
Subject: [uf-discuss] The need for a Trackback microformat?
In-Reply-To: <280d35437a8ed2797f9c99644b5b3149@technorati.com>
References: <d572750a0512010751k7d22c889k@mail.gmail.com>
	<op.s038x0hjares2h@mail.solitude.dk>
	<d572750a0512011438x8bc4eau@mail.gmail.com>
	<op.s04pxbr4ares2h@mail.solitude.dk>
	<2A83EDD6-1854-4359-815D-3240AA531C77@technorati.com>
	<op.s05ltrzjares2h@mail.solitude.dk>
	<CE3F1C22-9137-4BAF-95E4-0F38FC9BD585@technorati.com>
	<1bc4603e0512031023i46bba380j40257a4a2bbfaa5d@mail.gmail.com>
	<84ce626f0512031351y28f91868t10f4f5c3f16da6cd@mail.gmail.com>
	<280d35437a8ed2797f9c99644b5b3149@technorati.com>
Message-ID: <84ce626f0512051550r14d9d89fk1e7c513b3c9803a4@mail.gmail.com>

Hello,

On 12/5/05, Kevin Marks <kmarks@technorati.com> wrote:
> OK, this brings us to the heart of Podcasting. For much discussion, see
> the last two videos with rel="enclosure" on my blog...
>
> On Dec 3, 2005, at 1:51 PM, Charles Iliya Krempeaux wrote:
> > On 12/3/05, Chris Messina <chris.messina@gmail.com> wrote:
> >> On 12/2/05, Ryan King <ryan@technorati.com> wrote:
> >>> I don't think your relEnclosure and http://microformats.org/wiki/rel-
> >>> enclosure are that different, they're just explained differently.
> >>> Also, I think they're close enough to be resolved. You want to work
> >>> on that?
>
> Yes, the meaning is the same. If we can revise the wording to make this
> clearer, good.
>
> >> Perhaps rel-enclosure doesn't actually make sense long term. Given
> >> that relEnclosure, AFAIK, was grafted onto RSS to allow for media
> >> being "attached" to feeds, rel-enclosure doesn't make sense in your
> >> regular browser-consumed webpages because we've got <embed> and
> >> <object>. If RSS had been able to support inline rich media, wouldn't
> >> those tags have sufficed?
> >
> > No.  In RSS, enclosures instruct the client to pre-download the media,
> > (but says nothing about "playing" it).  Both <embed> and <object> say
> > "play" the media (and say nothing about pre-downloading it AFAIK).
> >
> > To me, there are 2 orthogonal concepts here.  One is pre-downloading
> > it.  And the other is "playing" it.
> >
> > It was my (perhaps naive) understanding that rel-enclosure was an
> > attempt to add pre-downloading to HTML.
>
> It is for pre-downloading, and also to imply synchronisation to a
> non-browser client. The goal is to enable transparent playback of media
> you subscribe to, with no waiting. In other words, the 'playing new
> stuff to me on my bike ride to work' scenario.
>
> >> It also seems that relEnclosure was about behavior on the client side
> >> and less about semantics.
> >>
> >> Let's presume for a minute that we've got infinite bandwidth
> >
> > If that was the case, then, you would NOT need RSS enclosures.
> >
> >> and
> >> infinite storage. In such a world, all embedded media (and hrefs)
> >> would be able to be pulled in and cached automagically. In which case
> >> the need for delayed media downloading would be much less, so even if
> >> you're syncing your 8,000  feeds,  which all contain rich media like
> >> podcasts and vcasts, you would theoretically be able to pull all that
> >> data down anyway for later consumption.
> >>
> >> So the question is, what is the most effective way to link to that
> >> media? Indeed, will the media itself supplant the textual content of
> >> the feed?
>
> The textual content becomes annotation fro the media, in a podcast,
> which has beneficial effects: it is indexable by search engines and
> other tools that can read HTML (instead of having to spelunk thorugh
> giant binary media files looking for metadata)
>
> >> Will feeds simply become the distribution method for rich
> >> media or eventually get into a TV-for-the-web model where you pick
> >> people to subscribe to and can "tune in" to an aggregate stream of
> >> them whenever you like? I dunno, and I suppose I'm getting a little
> >> off topic here.
>
> They already are - see DTV
>
> >> So here's what I'm thinking when it comes down to it (now that you
> >> know what I'm looking at in the future)... Shouldn't relEnclosures
> >> just be converted to <object> or <embed> tags when they're pulled into
> >> xhtml?
> >
> > I'd say no.
>
> No, that's missing the point.

Could you elaborate on this please.  (How am I missing the point)

I'm all for the possibilty of using client side JavaScript, User
Scripts, or whatever technique to convert the rel-enclosure's to
<object>'s, <embed>'s, or whatever to play it.  But, in the actual
HTML code of the page, I think it would better to just the
rel-enclosure'd <a> tag.

To me, this is more of a usability issue.

Now, granted, it would be nice if we could attach more meta data to
the rel-enclosure, to allow for better "playing".  (And maybe that
calls for a new Microformat.)  But I still think keeping it as a
rel-enclosure'd <a> tag would be better.  (It doesn't always make
sense to treat a media file all by itself.  Sometimes it is related to
others in a particular way.)

I've been pondering the idea of something like hSMIL for a while.  So,
it may be a path than can be taken.  Although there are other paths
too (that I've been thinking of).


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From supercanadian at gmail.com  Tue Dec  6 01:27:37 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 01:27:59 2005
Subject: [uf-discuss] Show Microformat Brainstorming
Message-ID: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>

Hello,

Thought I'd do some thinking out load about possibilities for a show
microformat.

What is a show?  Think TV show.  Although it doesn't have to be a TV show.

First, listing some existing uses cases.  These are what I've seen
people do already.  Note, I've made the example HTML very simple (so
as not to clutter things).  Usually people use all sorts of extra
markup to make things look nice.  But I don't include that here.)

#1: Single clip with a preview image.  The clip is the full show.

        <a href="clip.mpeg"><img src="preview.png" /></a>

#2: Single clip with a preview image.  The clip is the teaser of the
full show.  And there is a link that you can go to pay to see the full
show.

        <a href="teaser.mpeg"><img src="preview.png" /></a>

        <a href="http://example.com/go">Pay to View</a>

(The "Pay to View" link may or may not directly go to the "pay" page. 
And you may or may not have to pay for more than just this show to
view it.)

#3: A show divided up in multiple clips, each with a preview image. 
Together the clips make up the show.

        <a href="clip-1.mpg"><img src="preview-1.png" /></a>

        <a href="clip-2.mpg"><img src="preview-2.png" /></a>

        <a href="clip-3.mpg"><img src="preview-3.png" /></a>

(Note, there's a specific order here that matters.)

#4: A set of teasers for a show.  Together they don't make up the full
show.  And the may or may not overlap in time.  There's a "Pay to
View" link there too.

        <a href="clip-blue.mpg"><img src="preview-blue.png" /></a>

        <a href="clip-red.mpg"><img src="preview-red.png" /></a>

        <a href="clip-green.mpg"><img src="preview-green.png" /></a>


        <a href="http://example.com/go">Pay to View</a>

#5: A single clip that comes in different formats.  (Could be a
teaser, a clip, or a full show.)

        <img src="preview.png" />
        <a href="clip.mpg">MPEG</a>
        <a href="clip.ogm">Ogg</a>
        <a href="clip.avi">AVI</a>

And of course, you can do combos of these.

So, the orthogonal concepts here seem like:
  * there's the concept of a "preview" image.  (maybe thumbnail would
be a better name.)
  * there's the concept of a "show"
  * there's the concept of a "teaser"
  * If it is a teaser there is a "Pay to View" link
  * show can divided up into multiple contiguous files
  * teaser can be made up of multiple files
  * alternatives of the same media
  * you can combine all these

Did I miss anything?

(If anyone else knows SMIL here, you'll probably notice that alot of
this stuff has already been dealt with there.  Although SMIL does much
much more.)


There's already some related stuff on the wiki:
  http://microformats.org/wiki/media-metadata-examples
  http://microformats.org/wiki/video-metadata-model

And I wrote this before:
  http://changelog.ca/log/2005/10/16/thoughts_on_video_and_audio_microformats

And SMIL and Media RSS are good references too.


Comments?


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From danny.ayers at gmail.com  Tue Dec  6 02:02:08 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Dec  6 02:02:11 2005
Subject: [uf-discuss] rel="homepage"?
Message-ID: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>

I was wondering whether there was a link rel value or similar already
defined for pointing from e.g. a blog archive post to the blog main
page.

The use case I have is just that - I can grab an archived page,
express the data in the RDF model, but without some reference being
available from the archive to the homepage a lot of potentially useful
info is unavailable.

e.g. foaf:weblog is inverse-functional, so having the blog homepage
means you can identify the person behind the archived post.

Cheers,
Danny.

--

http://dannyayers.com
From solitude at solitude.dk  Tue Dec  6 02:07:19 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Tue Dec  6 02:07:23 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
Message-ID: <op.s1cw2hj9ares2h@mail.solitude.dk>

On Tue, 06 Dec 2005 11:02:08 +0100, Danny Ayers <danny.ayers@gmail.com>  
wrote:

> I was wondering whether there was a link rel value or similar already
> defined for pointing from e.g. a blog archive post to the blog main
> page.

rel="home" is defined in HTML  
( http://www.w3.org/TR/html4/types.html#type-links ). Opera translates  
that into a "Home" button on the link bar, and I'm sure Firefox has  
similar behaviour.

Close enough for me. :o)

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From supercanadian at gmail.com  Tue Dec  6 02:08:17 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 02:08:18 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
Message-ID: <84ce626f0512060208j61a8569fx2e3405da72135007@mail.gmail.com>

Hello,

On 12/6/05, Danny Ayers <danny.ayers@gmail.com> wrote:
> I was wondering whether there was a link rel value or similar already
> defined for pointing from e.g. a blog archive post to the blog main
> page.

I'd say probably rel-author.  (It's what I used on my blog.)  Works
with the idea of URL's being proxies for people.


> The use case I have is just that - I can grab an archived page,
> express the data in the RDF model, but without some reference being
> available from the archive to the homepage a lot of potentially useful
> info is unavailable.

Yeah, I came to similar issues when dealing with trust metrics.  I
also use rev-author to say that "I wrote that" (... if that helps). 
That way you get these pages (semantically) pointing to each other.


See ya

> e.g. foaf:weblog is inverse-functional, so having the blog homepage
> means you can identify the person behind the archived post.
>
> Cheers,
> Danny.
>
> --
>
> http://dannyayers.com
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From danny.ayers at gmail.com  Tue Dec  6 03:53:33 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Dec  6 03:53:35 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <op.s1cw2hj9ares2h@mail.solitude.dk>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
Message-ID: <1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>

On 12/6/05, Andreas Haugstrup <solitude@solitude.dk> wrote:
> On Tue, 06 Dec 2005 11:02:08 +0100, Danny Ayers <danny.ayers@gmail.com>
> wrote:
>
> > I was wondering whether there was a link rel value or similar already
> > defined for pointing from e.g. a blog archive post to the blog main
> > page.
>
> rel="home" is defined in HTML
> ( http://www.w3.org/TR/html4/types.html#type-links ).

Sorry, I can't find "home" anywhere on that page - do you have a more
direct link..?

Cheers,
Danny.



--

http://dannyayers.com
From solitude at solitude.dk  Tue Dec  6 03:55:17 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Tue Dec  6 03:55:21 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
Message-ID: <op.s1c12feaares2h@mail.solitude.dk>

On Tue, 06 Dec 2005 12:53:33 +0100, Danny Ayers <danny.ayers@gmail.com>  
wrote:

> On 12/6/05, Andreas Haugstrup <solitude@solitude.dk> wrote:
>> On Tue, 06 Dec 2005 11:02:08 +0100, Danny Ayers <danny.ayers@gmail.com>
>> wrote:
>>
>> > I was wondering whether there was a link rel value or similar already
>> > defined for pointing from e.g. a blog archive post to the blog main
>> > page.
>>
>> rel="home" is defined in HTML
>> ( http://www.w3.org/TR/html4/types.html#type-links ).
>
> Sorry, I can't find "home" anywhere on that page - do you have a more
> direct link..?

Sorry, that was a typo. rel="start" gets shown as a "home" button in the  
browser.

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From davidjanes at blogmatrix.com  Tue Dec  6 03:59:43 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Tue Dec  6 03:59:46 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <1D13ADC2-8902-4EC8-A415-5E1FAEE6110C@technorati.com>
References: <43843033.4080802@blogmatrix.com>	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>	<4393243D.2000300@blogmatrix.com>
	<1D13ADC2-8902-4EC8-A415-5E1FAEE6110C@technorati.com>
Message-ID: <43957D2F.1060707@blogmatrix.com>

Ryan King wrote:
> On Dec 4, 2005, at 9:15 AM, David Janes -- BlogMatrix wrote:
>> Ryan King wrote:
>>> 4. Why do we prefer <h#> over class="title" for entry titles?
>>
>> See my earlier note. I'd really appreciate if you or Tantek got back 
>> to me here: my understanding is that we'd always prefer appropriate 
>> XHTML constructs.
> 
> Yes, I'd say we should prefer the appropriate html construct.
> 
> In this particular case, though, I'm afraid using <h#> is a bit brittle- 
> this is coming from helping triage support requests coming into 
> Technorati about us not indexing their blog properly. For this 
> particular element I would prefer:
> 
> 1. an explicit classname (most people are using a classname already, no?)
> 2. fallback to <h#>
> 
> I think the explicit declaration should be preferred, but this is just a 
> suggestion. I know that other xhtml-syndication efforts have used <h#> 
> for entry titles, but I'm not sure of their success. Anyone with 
> experience here, please speak up.

I'm going to go with your suggestion. I've actually been doing lots of 
playing with parsing Microformats using Python, DOMs, and so forth and 
I'm getting a better sense of what practically works.

> 
>>> 5. "Entry Permalinks MUST be absolute URIs". Why? We have well 
>>> established rules for relative urls.
>>
>> I could lower this to SHOULD; feedback would be appreciated.
> 
> I think requiring absolute URIs is a bit too high a hurdle, not not 
> quite neccessary.

I'm going to change this to SHOULD. There, done.

> 
>> However, what I'm trying to accomplish is to let "rel-bookmark" 
>> provide byte comparable strings for providing "the best location for 
>> this resource".
> 
> Like I said, the rules for transforming relative URIs to absolute ones 
> are pretty well established, so any consumer should be able to take care 
> of this for themselves. I think this is just a case where we need to 
> optimize for the publisher over the consumer.

I was reading a blog post yesterday about how much misery atom:base and 
relative URIs are causing. Can't find it, ah well.

> 
>> The problem with relative URIs is that readers at 
>> "http://instapundit.com" and at "http://www.instapundit.com" will come 
>> up with two different sets of Entry Permalinks that are actually 
>> representing the same resources.
>>
>> This even gets uglier with LiveJournal. I do recognize this may be an 
>> attempt at some mild social engineering on my part.
> 
> FWIW, there has been some (offline and on-) discussion about a 
> rel-canonical microformat. Maybe hAtom should defer this problem (*it 
> is* bigger than just atom/blogs).

Fair enough. Maybe it'll be a role model.

> 
>>> 6. quote:
>>>> there can be at most 1 Entry in an XHTML document without an Entry 
>>>> Permalink; the Entry Permalink of this Entry is the URI of the page
>>>> This rule is needed for media pages (i.e. a news article on 
>>>> cnn.com). There is some ugliness of with this because the URI could 
>>>> be non-canonical."
>>> I'm not sure I follow this and don't see anything on the 
>>> brainstorming page about it.
>>
>> It's in the blog-post-examples [1]. I'd like to make in practical for 
>> organizations such as CNN to markup pages such as [2] in hAtom without 
>> requiring them rewriting the way they do pages.
> 
> So the use-case is a "document with one entry"? Is this really worth 
> making a general rule about?
> 
>> ...
>> It's all great -- bring it on. I'm back in fighting shape :-)
> 
> Great.

A few more changes have gone in. I've documented a list [1] for people 
tracking the proposal. I've also started collecting practical advice on 
templates, CSS and so forth [2]. Contributions from WP people and so 
forth would be appreciated.

> 
> -ryan
> 

Regards, etc...
David
http://www.blogmatrix.com

[1] http://microformats.org/wiki/hatom#Recent_Changes
[2] http://microformats.org/wiki/hatom#Hints_and_Tips

From danny.ayers at gmail.com  Tue Dec  6 04:05:52 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Dec  6 04:05:53 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <84ce626f0512060208j61a8569fx2e3405da72135007@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<84ce626f0512060208j61a8569fx2e3405da72135007@mail.gmail.com>
Message-ID: <1f2ed5cd0512060405m4e9b2922v268f797c9b426c33@mail.gmail.com>

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> On 12/6/05, Danny Ayers <danny.ayers@gmail.com> wrote:
> > I was wondering whether there was a link rel value or similar already
> > defined for pointing from e.g. a blog archive post to the blog main
> > page.
>
> I'd say probably rel-author.  (It's what I used on my blog.)  Works
> with the idea of URL's being proxies for people.

The problem there for me is that I will also be using the homepage URI
to refer to the homepage.

    <http://dannyayers.com>  dc:title "Raw" .

- but I don't have the title "Raw". Unambiguous reference to me
through the page URI is still possible:

    _:me foaf:weblog <http://dannyayers.com> .

because foaf:weblog is defined as being inverse-functional,

   _:someone foaf:weblog <http://dannyayers.com> .

implies

   _:someone owl:sameAs _:me .

Cheers,
Danny.

--

http://dannyayers.com
From danny.ayers at gmail.com  Tue Dec  6 04:35:28 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Dec  6 04:35:31 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <op.s1c12feaares2h@mail.solitude.dk>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
	<op.s1c12feaares2h@mail.solitude.dk>
Message-ID: <1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>

On 12/6/05, Andreas Haugstrup <solitude@solitude.dk> wrote:

> Sorry, that was a typo. rel="start" gets shown as a "home" button in the
> browser.

Thanks - got it.
[[
Start
    Refers to the first document in a collection of documents. This
link type tells search engines which document is considered by the
author to be the starting point of the collection.
]]

Hmm, I'm not sure, might there not be a conflict in the blog archive
scenario - archived post #1 being rel="start"..?

Cheers,
Danny.

--

http://dannyayers.com
From microformats at gr0w.com  Tue Dec  6 04:51:52 2005
From: microformats at gr0w.com (Jon Tan)
Date: Tue Dec  6 04:52:07 2005
Subject: [uf-discuss] =?iso-8859-1?q?=B5F_Press_/_Starter_Pack?=
Message-ID: <021c01c5fa63$d4fc2d90$0302a8c0@js3hz40y5b5j1w>

Hi all. There's been a little discussion around a Press / Starter Pack for 
?F's.

As Ryan King puts it, 'by covering the journalist use-case, we will also 
hopefully make ?f's more accessible to all [non | less]-technical people'.

The aim is to provide an easier way for non/less technical people discover 
?f's more easily along the lines of the Technorati Press Kit [1]. It would 
be adjusted to meet a generic less-technical person use-case and 
supplemental to About ?f's [2], wiki Introduction [3], wiki FAQ [4],  wiki 
press coverage [5] and presentations page [6].

The press / starter pack might include the following:

- ?F's 'About' simplified introduction as to *what* ?f's are, *why* they are 
being created / are useful and *how* they can be used (currently). Could 
also include a list of links to:

* Presentations
* 'history of ?F's
* Graphics for use by authors / press + buttons [7]
* Historical Press on ?F's'
* Links external blog posts around ?F's for alternative explanations of ?f's 
and sound-bites.
* ?F's Discuss list access

- Basic FAQ along similar lines to the Technorati basic FAQ [8]. Could also 
contain a list of:

* Implementations / Examples in The Wild wiki sections
* Code examples and creators [9]
* External helper articles (like the wiki Introduction)
* Graphics / buttons

- Press contact [ as a hCard - X2V - vCard of course :) ]

I see a Starter Pack functioning as a simplified introduction and 
foundation. It might be an addition to either to the Introduction page or 
the Press page, or a wiki page on it's own. A call to action from the About 
page to enable journalists or anyone else to be eased in to ?F's prior to 
diving in to the technical information might be useful.

As someone who is new to ?F's and having just implemented my first ?F as an 
interface designer rather than a developer, this would of been of great 
benefit to me when first trying to answer my own questions regarding ?F's. 
Others who I've introduced to ?F's have asked almost identical questions 
that this proposal tries to answer in a more accessible form.

All suggestions and comments will be much appreciated. Thanks,

Jon Tan
microformats@gr0w.com

[1] http://technorati.com/press/#kit
[2] http://microformats.org/about/
[3] http://microformats.org/wiki/introduction
[4] http://microformats.org/wiki/faq
[5] http://microformats.org/wiki/press
[6] http://microformats.org/wiki/presentations
[7] http://microformats.org/wiki/buttons
[8] http://technorati.com/help/faq.html
[9] http://microformats.org/code/ 

From davidjanes at blogmatrix.com  Tue Dec  6 05:11:27 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Tue Dec  6 05:11:30 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>	<op.s1cw2hj9ares2h@mail.solitude.dk>	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>	<op.s1c12feaares2h@mail.solitude.dk>
	<1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
Message-ID: <43958DFF.1070100@blogmatrix.com>

Danny Ayers wrote:
> On 12/6/05, Andreas Haugstrup <solitude@solitude.dk> wrote:
> 
>> Sorry, that was a typo. rel="start" gets shown as a "home" button in the
>> browser.
> 
> Thanks - got it.
> [[
> Start
>     Refers to the first document in a collection of documents. This
> link type tells search engines which document is considered by the
> author to be the starting point of the collection.
> ]]
> 
> Hmm, I'm not sure, might there not be a conflict in the blog archive
> scenario - archived post #1 being rel="start"..?
> 

Yes, exactly. After reading through the last couple of posts, I would 
think that rel="home" has to be something different.

Regards, etc...

From solitude at solitude.dk  Tue Dec  6 05:21:41 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Tue Dec  6 05:21:45 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <43958DFF.1070100@blogmatrix.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
	<op.s1c12feaares2h@mail.solitude.dk>
	<1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
	<43958DFF.1070100@blogmatrix.com>
Message-ID: <op.s1c52ff2ares2h@mail.solitude.dk>

On Tue, 06 Dec 2005 14:11:27 +0100, David Janes -- BlogMatrix  
<davidjanes@blogmatrix.com> wrote:

> Danny Ayers wrote:
>> On 12/6/05, Andreas Haugstrup <solitude@solitude.dk> wrote:
>>
>>> Sorry, that was a typo. rel="start" gets shown as a "home" button in  
>>> the
>>> browser.
>>  Thanks - got it.
>> [[
>> Start
>>     Refers to the first document in a collection of documents. This
>> link type tells search engines which document is considered by the
>> author to be the starting point of the collection.
>> ]]
>>  Hmm, I'm not sure, might there not be a conflict in the blog archive
>> scenario - archived post #1 being rel="start"..?
>>
>
> Yes, exactly. After reading through the last couple of posts, I would  
> think that rel="home" has to be something different.

A quick test reveals that Opera creates the "home" button for rel="home"  
as well. I can't for the life of me figure out how to turn on this feature  
in Firefox (has it been removed?). Maybe rel="home" is to be preferred  
because it doesn't interfere with rel="start" and because the browser  
(Opera at least) actually does useful stuff with it.

- Andreas
-- 
<URL: http://www.solitude.dk/ >
Commentary on media, communication, culture and technology.
From qidydl at gmail.com  Tue Dec  6 06:17:21 2005
From: qidydl at gmail.com (David Osolkowski)
Date: Tue Dec  6 06:17:23 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <op.s1c52ff2ares2h@mail.solitude.dk>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
	<op.s1c12feaares2h@mail.solitude.dk>
	<1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
	<43958DFF.1070100@blogmatrix.com> <op.s1c52ff2ares2h@mail.solitude.dk>
Message-ID: <ee0909a60512060617g738902c2l5d48fbec2716e4b4@mail.gmail.com>

On 12/6/05, Andreas Haugstrup <solitude@solitude.dk> wrote:
>
> On Tue, 06 Dec 2005 14:11:27 +0100, David Janes -- BlogMatrix
> <davidjanes@blogmatrix.com> wrote:
>
> > Danny Ayers wrote:
> >> On 12/6/05, Andreas Haugstrup <solitude@solitude.dk> wrote:
> >>
> >>> Sorry, that was a typo. rel="start" gets shown as a "home" button in
> >>> the
> >>> browser.
> >>  Thanks - got it.
> >> [[
> >> Start
> >>     Refers to the first document in a collection of documents. This
> >> link type tells search engines which document is considered by the
> >> author to be the starting point of the collection.
> >> ]]
> >>  Hmm, I'm not sure, might there not be a conflict in the blog archive
> >> scenario - archived post #1 being rel="start"..?
> >>
> >
> > Yes, exactly. After reading through the last couple of posts, I would
> > think that rel="home" has to be something different.
>
> A quick test reveals that Opera creates the "home" button for rel="home"
> as well. I can't for the life of me figure out how to turn on this feature
> in Firefox (has it been removed?). Maybe rel="home" is to be preferred
> because it doesn't interfere with rel="start" and because the browser
> (Opera at least) actually does useful stuff with it.


Mark Pilgrim suggests rel="home":
http://diveintoaccessibility.org/day_9_providing_additional_navigation_aids.html

The site navigation toolbar was in the full Mozilla suite.  I don't think it
made it into Firefox, although I wouldn't be surprised if there's an
extension for it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051206/2eb26302/attachment.htm
From dimitri.glazkov at gmail.com  Tue Dec  6 06:17:35 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Tue Dec  6 06:17:41 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <43957D2F.1060707@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>
	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>
	<4393243D.2000300@blogmatrix.com>
	<1D13ADC2-8902-4EC8-A415-5E1FAEE6110C@technorati.com>
	<43957D2F.1060707@blogmatrix.com>
Message-ID: <fb15ac210512060617x3ae0e89aj742fce6aa08b3897@mail.gmail.com>

David,

Just in case people didn't say this enough: this hAtom thing is
tremendous. I am working on implementing it at a client's site and I
am enjoying the quality of the spec and the level of thought that went
into it.

Now, try to fit that head into a doorway :)

:DG<
From hakejam at gmail.com  Tue Dec  6 07:04:45 2005
From: hakejam at gmail.com (Jacob Ham)
Date: Tue Dec  6 07:04:49 2005
Subject: =?ISO-8859-1?Q?Re:_[uf-discuss]_=B5F_Press_/_Starter_Pack?=
In-Reply-To: <021c01c5fa63$d4fc2d90$0302a8c0@js3hz40y5b5j1w>
References: <021c01c5fa63$d4fc2d90$0302a8c0@js3hz40y5b5j1w>
Message-ID: <b3a45b540512060704o30cf11f2p969f02410776238b@mail.gmail.com>

On the topic of getting started with Microformats, Drew McLellan, the
creator of '24 ways', released a great introduction on hCard format.

http://24ways.org/advent/practical-microformats-with-hcard

Cheers,

Jake
From davidjanes at blogmatrix.com  Tue Dec  6 07:36:10 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Tue Dec  6 07:36:14 2005
Subject: [uf-discuss] hReview Question/Statement
Message-ID: <4395AFEA.8050507@blogmatrix.com>

What's the rule for associating "rating" with "best"? I'm looking at 
this example [1] from the Wiki:

  <ul class="categories">
   <li><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
    Food: <span class="rating">18</span>/<span 
class="best">30</span></a>;</li>
   <li><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
    Ambience: <span class="rating">19</span>/<span 
class="best">30</span></a>;</li>
   <li><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
    Service: <span class="rating">15</span>/<span 
class="best">30</span></a>;</li>
   <li><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
    Price: <abbr class="rating" title="2">$$</abbr>...</a></li>
  </ul>

and the implied rule (if it follows) seems rather loosey goosey: if it's 
under the same parent element, associate them?. For example, there's 
clear way to write:

<p>
On Fred's <span class="best">4</a> ICBM scale, I give this a <span 
class="rating">2</a>.
</p>

Would it not be better to explicitly place them within a named parent 
container (say "rated")? Then one no longer needs to make sure 
everything is grouped in some explicit way:

<p class="rated">
I rate all my Chilis on a <span class="best">4</span> ICBM scale. The 
best I ever had was Texas Joe's Twister, which render large parts of the 
midwest uninhabitable later that night and earned a <span 
class="rating">4</span> from me.
</p>

Regards, etc...



From davidjanes at blogmatrix.com  Tue Dec  6 07:41:52 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Tue Dec  6 07:41:55 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <fb15ac210512060617x3ae0e89aj742fce6aa08b3897@mail.gmail.com>
References: <43843033.4080802@blogmatrix.com>	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>	<4393243D.2000300@blogmatrix.com>	<1D13ADC2-8902-4EC8-A415-5E1FAEE6110C@technorati.com>	<43957D2F.1060707@blogmatrix.com>
	<fb15ac210512060617x3ae0e89aj742fce6aa08b3897@mail.gmail.com>
Message-ID: <4395B140.20108@blogmatrix.com>

Thanks Dimitri,

I aim to please. I hope to have an interesting webservice to show off 
before the end of the week relating to uFs also.

Regards, etc...
David

Dimitri Glazkov wrote:
> David,
> 
> Just in case people didn't say this enough: this hAtom thing is
> tremendous. I am working on implementing it at a client's site and I
> am enjoying the quality of the spec and the level of thought that went
> into it.
> 
> Now, try to fit that head into a doorway :)
> 
> :DG<
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 
> 


From supercanadian at gmail.com  Tue Dec  6 09:44:01 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 09:44:04 2005
Subject: [uf-discuss] hReview Question/Statement
In-Reply-To: <4395AFEA.8050507@blogmatrix.com>
References: <4395AFEA.8050507@blogmatrix.com>
Message-ID: <84ce626f0512060944h30b2f88du6e88d07d57b84dae@mail.gmail.com>

Hello,

On 12/6/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
> What's the rule for associating "rating" with "best"? I'm looking at
> this example [1] from the Wiki:
>
>   <ul class="categories">
>    <li><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
>     Food: <span class="rating">18</span>/<span
> class="best">30</span></a>;</li>
>    <li><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
>     Ambience: <span class="rating">19</span>/<span
> class="best">30</span></a>;</li>
>    <li><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
>     Service: <span class="rating">15</span>/<span
> class="best">30</span></a>;</li>
>    <li><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
>     Price: <abbr class="rating" title="2">$$</abbr>...</a></li>
>   </ul>
>
> and the implied rule (if it follows) seems rather loosey goosey: if it's
> under the same parent element, associate them?. For example, there's
> clear way to write:
>
> <p>
> On Fred's <span class="best">4</a> ICBM scale, I give this a <span
> class="rating">2</a>.
> </p>
>
> Would it not be better to explicitly place them within a named parent
> container (say "rated")? Then one no longer needs to make sure
> everything is grouped in some explicit way:
>
> <p class="rated">
> I rate all my Chilis on a <span class="best">4</span> ICBM scale. The
> best I ever had was Texas Joe's Twister, which render large parts of the
> midwest uninhabitable later that night and earned a <span
> class="rating">4</span> from me.
> </p>

I'd say yes.  (Unless you want to make them share some unique class
name that binds them together.)


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From danny.ayers at gmail.com  Tue Dec  6 10:21:00 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Dec  6 10:21:02 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <ee0909a60512060617g738902c2l5d48fbec2716e4b4@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
	<op.s1c12feaares2h@mail.solitude.dk>
	<1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
	<43958DFF.1070100@blogmatrix.com> <op.s1c52ff2ares2h@mail.solitude.dk>
	<ee0909a60512060617g738902c2l5d48fbec2716e4b4@mail.gmail.com>
Message-ID: <1f2ed5cd0512061021q51db5fc3tc3782dd243689efb@mail.gmail.com>

Thanks guys, sounds like rel="home" is the way to go.


--

http://dannyayers.com
From supercanadian at gmail.com  Tue Dec  6 10:22:05 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 10:22:07 2005
Subject: [uf-discuss] Re: Show Microformat Brainstorming
In-Reply-To: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
Message-ID: <84ce626f0512061022y2572009ar95fa22ac20a91b33@mail.gmail.com>

Hello,

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,

[...]

> So, the orthogonal concepts here seem like:
>   * there's the concept of a "preview" image.  (maybe thumbnail would
> be a better name.)
>   * there's the concept of a "show"
>   * there's the concept of a "teaser"
>   * If it is a teaser there is a "Pay to View" link
>   * show can divided up into multiple contiguous files
>   * teaser can be made up of multiple files
>   * alternatives of the same media

There's some stuff related to this on the wiki:
  http://microformats.org/wiki/alternates-examples
  http://microformats.org/wiki/alternates-brainstorming

To me,, I get the impression that the favorite for speciying a set of
alternate links to the "same" thing is something like:

    <ul class="alternates">
        <li><a href="clip.mpeg">MPEG</a></li>
        <li><a href="clip.ogm">OGG</a></li>
        <li><a href="clip.avi">AVI</a></li>
    </ul>

Now, from the point of view of reusing existing HTML elements that
already have the proper semantics, I agree that at first that this
does seem like a good idea.  However, it seems to have some problems:

#1: You can't have loosely coupled alternatives.
#2: Without some pretty fancy CSS styling, this is really going to
mess up people's webpages.  (This will probably be a "show stopper"
for some people.)

For those 2 reasons, I'm more inclined to go with something like:

    <span class="alternates">
        <a class="alternate" href="clip.mpeg">MPEG</a>
        <a class="alternate" href="clip.ogm">OGG</a>
        <a class="alternate" href="clip.avi">AVI</a>
    </span>

That way you could do stuff like:

    <p>
        To help software handle RSS properly you should use RSS
Disposition Hinting (<span class="alternates"><a
href="http://advogato.org/article/852.html" title="RSS Disposition
Hinting Proposal">Advogato version</a>, <a
href="http://changelog.ca/log/2005/08/21/rss-disposition-hinting-proposal"
title="RSS Disposition Hinting Proposal">ChangeLog.ca 
version</a></span>).
    </p>

If you wanted to be lazy, you could even do the following:

    <p class="alternates">
        To help software handle RSS properly you should use RSS
Disposition Hinting (<a href="http://advogato.org/article/852.html"
title="RSS Disposition Hinting Proposal">Advogato version</a>, <a
href="http://changelog.ca/log/2005/08/21/rss-disposition-hinting-proposal"
title="RSS Disposition Hinting Proposal">ChangeLog.ca  version</a>).
    </p>

(Don't know what people think of the class names I'm using.  They may
or may not be too generic.)

>   * you can combine all these
>
> Did I miss anything?

[...]


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From supercanadian at gmail.com  Tue Dec  6 10:51:40 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 10:51:42 2005
Subject: [uf-discuss] Re: Show Microformat Brainstorming
In-Reply-To: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
Message-ID: <84ce626f0512061051wa2ccb0dhac666743efbea3c1@mail.gmail.com>

Hello,

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:

[...]

> So, the orthogonal concepts here seem like:
>   * there's the concept of a "preview" image.  (maybe thumbnail would
> be a better name.)
>   * there's the concept of a "show"
>   * there's the concept of a "teaser"
>   * If it is a teaser there is a "Pay to View" link
>   * show can divided up into multiple contiguous files
>   * teaser can be made up of multiple files
>   * alternatives of the same media
>   * you can combine all these

(Some more things to add.)

  * there's the concept of a "clip"
  * there's the concept of the "media file".  (What the <a> tag's
"href" points to)


>
> Did I miss anything?

[...]


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From danny.ayers at gmail.com  Tue Dec  6 11:17:20 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Dec  6 11:17:22 2005
Subject: [uf-discuss] XSLT for converting from OPML to XBEL and XOXO
Message-ID: <1f2ed5cd0512061117q6f4b67bfladfc9cce1af1b179@mail.gmail.com>

fyi, blog post from Uche Ogbuji -

http://copia.ogbuji.net/blog/2005-12-05/XSLT_for_c

note re. XOXO:
"I really couldn't figure out any common conventions for Web feeds",
seems he went down the path earlier:

http://copia.ogbuji.net/blog/2005-11-15/I_must_be_

Cheers,
Danny.

--

http://dannyayers.com
From ryan at technorati.com  Tue Dec  6 12:22:26 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Dec  6 12:22:29 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <43957D2F.1060707@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>	<B16834B7-F8DE-4AA1-8613-13702353C1A6@technorati.com>	<4393243D.2000300@blogmatrix.com>
	<1D13ADC2-8902-4EC8-A415-5E1FAEE6110C@technorati.com>
	<43957D2F.1060707@blogmatrix.com>
Message-ID: <677C13A8-E27D-447E-8F74-723FA53ABF44@technorati.com>

On Dec 6, 2005, at 3:59 AM, David Janes -- BlogMatrix wrote:
>>> However, what I'm trying to accomplish is to let "rel-bookmark"  
>>> provide byte comparable strings for providing "the best location  
>>> for this resource".
>> Like I said, the rules for transforming relative URIs to absolute  
>> ones are pretty well established, so any consumer should be able  
>> to take care of this for themselves. I think this is just a case  
>> where we need to optimize for the publisher over the consumer.
>
> I was reading a blog post yesterday about how much misery atom:base  
> and relative URIs are causing. Can't find it, ah well.

Tantek can tell you about about atom:base problems. :D

Anyway, for better or worse, we have relative URIs in [X]HTML. The  
problem of resolving them is bigger than hatom.

-ryan
--
Ryan King
ryan@technorati.com



From supercanadian at gmail.com  Tue Dec  6 12:23:18 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 12:23:21 2005
Subject: [uf-discuss] Re: Show Microformat Brainstorming
In-Reply-To: <84ce626f0512061051wa2ccb0dhac666743efbea3c1@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
	<84ce626f0512061051wa2ccb0dhac666743efbea3c1@mail.gmail.com>
Message-ID: <84ce626f0512061223o8cdfa4fr49bedea1f063e9c3@mail.gmail.com>

Hello,

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
>
> [...]
>
> > So, the orthogonal concepts here seem like:
> >   * there's the concept of a "preview" image.  (maybe thumbnail would
> > be a better name.)
> >   * there's the concept of a "show"
> >   * there's the concept of a "teaser"
> >   * If it is a teaser there is a "Pay to View" link
> >   * show can divided up into multiple contiguous files
> >   * teaser can be made up of multiple files
> >   * alternatives of the same media
> >   * you can combine all these
>
> (Some more things to add.)
>
>   * there's the concept of a "clip"
>   * there's the concept of the "media file".  (What the <a> tag's
> "href" points to)

This is probably the foundation of it all -- the "media file".  So, to
mark something as being media, you could do something like:

    <a class="media" href="clip.mpeg">watch this</a>

However, if you want to attach metadata to the media file (beyond what
the <a> tag lets you do) then you might do something like the
following:

    <span class="media">
        <img class="preview" src="preview.png" />
        <a class="reference" href="clip.mpeg">MPEG</a>
        <div class="description">description goes here</div>
        <a href="text">text version goes here... useful to the deaf
and for searching and indexing</a>
    </span>

Note, I'm NOT trying to enumerate all the metadata that can be
associated with a "media".  There's already been some work on this
here:
  http://microformats.org/wiki/video-metadata-model
  http://microformats.org/wiki/media-metadata-examples

Also, I'm not trying to name these class names either.  Just thinking out loud.

So, going back to the simple example again, it would be better to have it as:

    <a class="media reference" href="clip.mpeg">watch this</a>

It's just a compact version of and the simplest version of the other form.

And going through all those examples I listed before....  (Note, in
the end, more microformats are needed for this, but for right now, I'm
just apply the "media" stuff to it.)

Here's the first one that's just a bit more complex (and very very common):

    <a class="media reference" href="clip.mpeg"><img class="preview"
src="preview.png" /></a>

The next one is basically the same:

    <a class="media reference" href="teaser.mpeg"><img class="preview"
src="preview.png" /></a>

    <a href="http://example.com/go">Pay to View</a>

Note, the "Pay to View" part of it didn't even get affected by this
microformat.  (Although in the final show microformat it needs to.  It
needs to get "marked".  And we need to bind all this together.)

For the third one:

    <a class="media reference" href="clip-1.mpg"><img class="preview" 
src="preview-1.png" /></a>

    <a class="media reference" href="clip-2.mpg"><img class="preview" 
src="preview-2.png" /></a>

    <a class="media reference" href="clip-3.mpg"><img class="preview" 
src="preview-3.png" /></a>

Note, there's just 3 completely separate media's here.  (Although in
the final show microformat they need to be bound together.  And it
needs to tell you that there is an order to these.  And it needs to
tell you that together they make up a show.)

For the forth one, it's alot like the last one:

    <a class="media reference" href="clip-blue.mpg"><img
class="preview" src="preview-blue.png" /></a>

    <a class="media reference" href="clip-red.mpg"><img
class="preview" src="preview-red.png" /></a>

    <a class="media reference" href="clip-green.mpg"><img
class="preview" src="preview-green.png" /></a>


    <a href="http://example.com/go">Pay to View</a>

Again, the "Pay to View" link didn't even get addressed.  (Although in
the final show microformat it needs to.  And we need to bind this all
together.)

And for the fifth and final use case I listed before, it becomes:


    <img src="preview.png" />
    <a class="media reference" href="clip.mpg">MPEG</a>
    <a class="media reference" href="clip.ogm">Ogg</a>
    <a class="media reference" href="clip.avi">AVI</a>

Note that in this case the "preview" isn't bound to any particular
media and isn't even marked as being such.  (In the final show
microformat it needs to be, but we also need something to contain all
this in to bind it all together.)


The rest of the Show Microformat would be built on top of this.

Comments?


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From ryan at technorati.com  Tue Dec  6 12:24:19 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Dec  6 12:24:21 2005
Subject: [uf-discuss] hReview Question/Statement
In-Reply-To: <4395AFEA.8050507@blogmatrix.com>
References: <4395AFEA.8050507@blogmatrix.com>
Message-ID: <9B0BD87C-7230-4EC2-A64C-ECC6624D6A8E@technorati.com>

On Dec 6, 2005, at 7:36 AM, David Janes -- BlogMatrix wrote:

> What's the rule for associating "rating" with "best"? I'm looking  
> at this example [1] from the Wiki:
>
>  <ul class="categories">
>   <li><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
>    Food: <span class="rating">18</span>/<span class="best">30</ 
> span></a>;</li>
>   <li><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
>    Ambience: <span class="rating">19</span>/<span class="best">30</ 
> span></a>;</li>
>   <li><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
>    Service: <span class="rating">15</span>/<span class="best">30</ 
> span></a>;</li>
>   <li><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
>    Price: <abbr class="rating" title="2">$$</abbr>...</a></li>
>  </ul>
>
> and the implied rule (if it follows) seems rather loosey goosey: if  
> it's under the same parent element, associate them?. For example,  
> there's clear way to write:
>
> <p>
> On Fred's <span class="best">4</a> ICBM scale, I give this a <span  
> class="rating">2</a>.
> </p>

This example is qualitatively different than the above. The above is  
giving ratings for specific categories (aka, tags).

-ryan
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Tue Dec  6 12:29:07 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Dec  6 12:29:08 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <1f2ed5cd0512061021q51db5fc3tc3782dd243689efb@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
	<op.s1c12feaares2h@mail.solitude.dk>
	<1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
	<43958DFF.1070100@blogmatrix.com>
	<op.s1c52ff2ares2h@mail.solitude.dk>
	<ee0909a60512060617g738902c2l5d48fbec2716e4b4@mail.gmail.com>
	<1f2ed5cd0512061021q51db5fc3tc3782dd243689efb@mail.gmail.com>
Message-ID: <3914A99F-ECD6-489D-A19D-51BBE7A5444E@technorati.com>


On Dec 6, 2005, at 10:21 AM, Danny Ayers wrote:

> Thanks guys, sounds like rel="home" is the way to go.

Yeah, it sounds like it has precedent. Does anyone want to work on  
documenting this?

-ryan
--
Ryan King
ryan@technorati.com



From supercanadian at gmail.com  Tue Dec  6 15:34:50 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 15:34:52 2005
Subject: [uf-discuss] Re: Show Microformat Brainstorming
In-Reply-To: <84ce626f0512061223o8cdfa4fr49bedea1f063e9c3@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
	<84ce626f0512061051wa2ccb0dhac666743efbea3c1@mail.gmail.com>
	<84ce626f0512061223o8cdfa4fr49bedea1f063e9c3@mail.gmail.com>
Message-ID: <84ce626f0512061534r471a8fb6wdc71cec07d16c78c@mail.gmail.com>

Hello,

Sorry, just a correction.

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> > Hello,
> >
> > On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> >
> > [...]
> >
> > > So, the orthogonal concepts here seem like:
> > >   * there's the concept of a "preview" image.  (maybe thumbnail would
> > > be a better name.)
> > >   * there's the concept of a "show"
> > >   * there's the concept of a "teaser"
> > >   * If it is a teaser there is a "Pay to View" link
> > >   * show can divided up into multiple contiguous files
> > >   * teaser can be made up of multiple files
> > >   * alternatives of the same media
> > >   * you can combine all these
> >
> > (Some more things to add.)
> >
> >   * there's the concept of a "clip"
> >   * there's the concept of the "media file".  (What the <a> tag's
> > "href" points to)
>
> This is probably the foundation of it all -- the "media file".  So, to
> mark something as being media, you could do something like:
>
>     <a class="media" href="clip.mpeg">watch this</a>
>
> However, if you want to attach metadata to the media file (beyond what
> the <a> tag lets you do) then you might do something like the
> following:
>
>     <span class="media">
>         <img class="preview" src="preview.png" />
>         <a class="reference" href="clip.mpeg">MPEG</a>
>         <div class="description">description goes here</div>
>         <a href="text">text version goes here... useful to the deaf
> and for searching and indexing</a>
>     </span>

That part that says:

    <a href="text">text version goes here... useful to the deaf and
for searching and indexing</a>

...is wrong.  It should be:

    <a class="text" href="">the "text version" is pointed to by the
href... useful to the deaf and for searching and indexing.  It could
be plain text.  Or another format.  Like a format that would sync up
text with frame sequences in the media file.</a>


[...]


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From whump at mac.com  Tue Dec  6 18:33:42 2005
From: whump at mac.com (Bill Humphries)
Date: Tue Dec  6 18:33:47 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
Message-ID: <81A2CD0E-41D7-4DEB-A4E4-71F7DC16E061@mac.com>


On Dec 6, 2005, at 1:27 AM, Charles Iliya Krempeaux wrote:

> Thought I'd do some thinking out load about possibilities for a show
> microformat.
>
> What is a show?  Think TV show.  Although it doesn't have to be a  
> TV show.

When you mentioned that, I had an orthogonal conception of the problem.

Consider the case of the person writing about their favorite show,  
Buffy the Vampire Slayer, in their blog. Bloggers and Whedon: two  
things that go together, eh?

 > Last night's Buffy episode was silly.

I'd like to find all the shows my friends are watching/writing about,  
so I can build things from it, or tell tools "go and buy these  
episodes of these shows from the Apricot You Tunes Music Store."

Now there's not an existing XML format to my knowledge for us to work  
from. So I have to make some assumptions.

1. This is a recurring TV series our blogger's writing about.
2. It's in its N season.
3. This is episode X of the current season.

Observing fan and academic writers online, I often see them refer to  
episodes of a TV show using:

BtVS 1.12 "Prophesy Girl"

That is: Episode twelve of season one of Buffy the Vampire Slayer,  
entitled "Prophesy Girl".

Okay:

<cite>BtVS1.12 "Prophesy Girl"</cite>

Feh, it tells me it a cite, but there's only unicode inside.

Better:

<cite class="htv">BtVS 1.12 "Prophesy Girl"</cite>

Okay, it's a show using the htv ? format.

Ah:

<cite class="htv"><span class="series"><abbr title="Buffy the Vampire  
Slayer">BtVS</abbr></span> <span class="season">1</span>.<span  
class="episode">12</span> <span class="title">Prophesy Girl</span></ 
cite>

in the CSS we'll throw in a rule to put quotes around the episode title.

So what do we have so far:

htv
	series, required	name of series
		name of series
		or 	abbr with title attribute set to name of series
	season, optional	number indicating season
		episode, optional	number indicating order of airing
		[ headaches when we talk about Firefly that has a different  
canonical order than the airing order ]
	title, optional		title of episode

I'll run this past some media fan and academic friends to get their  
impression.

If there's interest, I'll write it up for the bestiary.

-- Bill 'whump' Humphries | http://www.whump.com/
From supercanadian at gmail.com  Tue Dec  6 20:27:09 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 20:27:13 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <81A2CD0E-41D7-4DEB-A4E4-71F7DC16E061@mac.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
	<81A2CD0E-41D7-4DEB-A4E4-71F7DC16E061@mac.com>
Message-ID: <84ce626f0512062027q5280e5e8reaf7e9b789d62683@mail.gmail.com>

Hello,

On 12/6/05, Bill Humphries <whump@mac.com> wrote:
>
> On Dec 6, 2005, at 1:27 AM, Charles Iliya Krempeaux wrote:
>
> > Thought I'd do some thinking out load about possibilities for a show
> > microformat.
> >
> > What is a show?  Think TV show.  Although it doesn't have to be a
> > TV show.
>
> When you mentioned that, I had an orthogonal conception of the problem.
>
> Consider the case of the person writing about their favorite show,
> Buffy the Vampire Slayer, in their blog. Bloggers and Whedon: two
> things that go together, eh?

Yeah, I like Whedon's shows too :-)

>  > Last night's Buffy episode was silly.
>
> I'd like to find all the shows my friends are watching/writing about,
> so I can build things from it, or tell tools "go and buy these
> episodes of these shows from the Apricot You Tunes Music Store."

This is an area I've been working on too.  (Although it wasn't
something I tried to address in this thread.  Trying to do this in
steps :-)  But I'm happy to broaden the discussion.)

Specifically I thought about finding out what my friends, family,
neighbor, people who's opinion matter to me, etc are watching, and
using that find stuff I might like to watch too.  I wrote about it a
bit here:

http://changelog.ca/log/2005/09/12/proposed-microformats-for-reputation-and-trust-metrics

(Although the article addresses the larger topic of "trust metrics"
and isn't specifically about "Internet TV".)  This becomes especially
powerful (for all parties involved) when people do "auto subscribing"
via this to series, channels, etc.

(I won't try to enumerating all the problems "Internet Television"
present.  This message would get just to huge, but) one of the
solutions for "Internet Television" is advertising what you watch.

If you look at my weblog -- http://changelog.ca/ -- you can see a
couple XOXO lists where I list (some of) the shows I watch, and (some
of) the channels I watch.  ("shows" and "channels" are concepts I've
found are important when dealing with "Internet TV".)  Each is an XOXO
list, with some other (semantic) class names used.  (These extra class
names may or may not change in the future.)

Things like this will become important as more and more "shows" and
"channels" get syndicated on the web.  I.e., Internet TV, IPTV,
NewTube, broadcatching, vcasting, vidcasting, vodcasting, or whatever
you want to call it.  (This syndication can take place via RSS/Atom. 
Or via hAtom and the Microformat I've been trying to discuss in this
thread.)

Of course, what you discuss next is a little different than this, but
is very important too.

> Now there's not an existing XML format to my knowledge for us to work
> from. So I have to make some assumptions.
>
> 1. This is a recurring TV series our blogger's writing about.
> 2. It's in its N season.
> 3. This is episode X of the current season.
>
> Observing fan and academic writers online, I often see them refer to
> episodes of a TV show using:
>
> BtVS 1.12 "Prophesy Girl"
>
> That is: Episode twelve of season one of Buffy the Vampire Slayer,
> entitled "Prophesy Girl".
>
> Okay:
>
> <cite>BtVS1.12 "Prophesy Girl"</cite>
>
> Feh, it tells me it a cite, but there's only unicode inside.
>
> Better:
>
> <cite class="htv">BtVS 1.12 "Prophesy Girl"</cite>
>
> Okay, it's a show using the htv ? format.
>
> Ah:
>
> <cite class="htv"><span class="series"><abbr title="Buffy the Vampire
> Slayer">BtVS</abbr></span> <span class="season">1</span>.<span
> class="episode">12</span> <span class="title">Prophesy Girl</span></
> cite>
>
> in the CSS we'll throw in a rule to put quotes around the episode title.

I think that all shows, episodes, series, and channels will (in the
near future) have URLs associated with them.  So, I think it is
important to work that concept in there too.  (Actually, I can
guarantee you that at least some of them will.)

I.e, there's a URL for the series/show.  And there's a URL for each
episode.  (Channels are will have URLs too.)

Also, the person giving the review might want to make a buck if
someone follows the "link" they provide to the show, series, channel,
etc, and pays some money to watch it.  So you may want to work that
concept in there too.  (And this "link" should be able to be expressed
as an HTTP POST and not just an HTTP GET,... so both <a> and <form>
should be supported for it.)

Also, you may want to see what people are currently doing out there. 
And make sure what you propose can be nicely applied to that too.

>
> So what do we have so far:
>
> htv
>         series, required        name of series
>                 name of series
>                 or      abbr with title attribute set to name of series
>         season, optional        number indicating season
>                 episode, optional       number indicating order of airing
>                 [ headaches when we talk about Firefly that has a different
> canonical order than the airing order ]
>         title, optional         title of episode
>
> I'll run this past some media fan and academic friends to get their
> impression.
>
> If there's interest, I'll write it up for the bestiary.

I'm definitely interested.  And it's a part of "Internet TV" that I
haven't put much thought into yet.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From kmarks at technorati.com  Tue Dec  6 21:38:29 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Tue Dec  6 21:39:42 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <1f2ed5cd0512061021q51db5fc3tc3782dd243689efb@mail.gmail.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
	<op.s1c12feaares2h@mail.solitude.dk>
	<1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
	<43958DFF.1070100@blogmatrix.com>
	<op.s1c52ff2ares2h@mail.solitude.dk>
	<ee0909a60512060617g738902c2l5d48fbec2716e4b4@mail.gmail.com>
	<1f2ed5cd0512061021q51db5fc3tc3782dd243689efb@mail.gmail.com>
Message-ID: <a2971a0f13b2858b56c17b7e0ad0cb08@technorati.com>


On Dec 6, 2005, at 10:21 AM, Danny Ayers wrote:

> Thanks guys, sounds like rel="home" is the way to go.

If it's not otherwise documented, clone one of the other rel formats 
and fill it in as a draft

From supercanadian at gmail.com  Tue Dec  6 23:04:13 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec  6 23:04:16 2005
Subject: [uf-discuss] Re: Show Microformat Brainstorming
In-Reply-To: <84ce626f0512061534r471a8fb6wdc71cec07d16c78c@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
	<84ce626f0512061051wa2ccb0dhac666743efbea3c1@mail.gmail.com>
	<84ce626f0512061223o8cdfa4fr49bedea1f063e9c3@mail.gmail.com>
	<84ce626f0512061534r471a8fb6wdc71cec07d16c78c@mail.gmail.com>
Message-ID: <84ce626f0512062304n522f00a5k9f9b91ee1e1b47d3@mail.gmail.com>

Hello,

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> Sorry, just a correction.
>
> On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> > Hello,
> >
> > On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> > > Hello,
> > >
> > > On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> > >
> > > [...]
> > >
> > > > So, the orthogonal concepts here seem like:
> > > >   * there's the concept of a "preview" image.  (maybe thumbnail would
> > > > be a better name.)
> > > >   * there's the concept of a "show"
> > > >   * there's the concept of a "teaser"
> > > >   * If it is a teaser there is a "Pay to View" link
> > > >   * show can divided up into multiple contiguous files
> > > >   * teaser can be made up of multiple files
> > > >   * alternatives of the same media
> > > >   * you can combine all these
> > >
> > > (Some more things to add.)
> > >
> > >   * there's the concept of a "clip"
> > >   * there's the concept of the "media file".  (What the <a> tag's
> > > "href" points to)
> >
> > This is probably the foundation of it all -- the "media file".  So, to
> > mark something as being media, you could do something like:
> >
> >     <a class="media" href="clip.mpeg">watch this</a>
> >
> > However, if you want to attach metadata to the media file (beyond what
> > the <a> tag lets you do) then you might do something like the
> > following:
> >
> >     <span class="media">
> >         <img class="preview" src="preview.png" />
> >         <a class="reference" href="clip.mpeg">MPEG</a>
> >         <div class="description">description goes here</div>
> >         <a href="text">text version goes here... useful to the deaf
> > and for searching and indexing</a>
> >     </span>
>
> That part that says:
>
>     <a href="text">text version goes here... useful to the deaf and
> for searching and indexing</a>
>
> ...is wrong.  It should be:
>
>     <a class="text" href="">the "text version" is pointed to by the
> href... useful to the deaf and for searching and indexing.  It could
> be plain text.  Or another format.  Like a format that would sync up
> text with frame sequences in the media file.</a>
>
>
> [...]

After "media", and all the metadata that may or may not be included
with it, the next level up would be "clip".

Expanding our previous example, we'd replace:

    <a class="media reference" href="clip.mpeg">watch this</a>

with:

    <span class="clip">
        <a class="media reference" href="clip.mpeg">watch this</a>
    </span>

or more compactly:

    <a class="clip media reference" href="clip.mpeg">watch this</a>

So, going through those common use cases again, we get...

#1:

    <a class="clip media reference" href="clip.mpeg"><img class="preview"
src="preview.png" /></a>

(Here it's almost exactly the same as before, except we added the "clip" class.)

#2:

        <a class="clip media reference" href="teaser.mpeg"><img class="preview"
src="preview.png" /></a>

        <a href="http://example.com/go">Pay to View</a>


(Here we still have NOT bound the "Pay to View" link to the rest of
the stuff... but we need to eventually.  And it's almost exactly the
same as before, except we added the "clip" class.)

#3:


    <a class="clip media reference" href="clip-1.mpg"><img class="preview"
src="preview-1.png" /></a>

    <a class="clip media reference" href="clip-2.mpg"><img class="preview"
src="preview-2.png" /></a>

    <a class="clip media reference" href="clip-3.mpg"><img class="preview"
src="preview-3.png" /></a>


(We still nee to bind all these clips together and show the ordering
between them.  And show that together they make a show.  And it's
almost exactly the same as before, except we added the "clip" class.)

#4:

    <a class="clip media reference" href="clip-blue.mpg"><img
class="preview" src="preview-blue.png" /></a>

    <a class="clip media reference" href="clip-red.mpg"><img
class="preview" src="preview-red.png" /></a>

    <a class="clip media reference" href="clip-green.mpg"><img
class="preview" src="preview-green.png" /></a>


    <a href="http://example.com/go">Pay to View</a>

(Here we still have NOT bound the "Pay to View" link to the rest of
the stuff... but we need to eventually.  Also we have bound the clips
together.  And it's almost exactly the same as before, except we added
the "clip" class.)

#5:

    <span class="clip">
        <img class="preview" src="preview.png" />
        <a class="media reference" href="clip.mpg">MPEG</a>
        <a class="media reference" href="clip.ogm">Ogg</a>
        <a class="media reference" href="clip.avi">AVI</a>
    </span>

Here's the place where having a "clip" really starts to become useful.
 Note that I've added the class="preview" to the <img>.  It now makes
sense to add it since that <img> is a preview for the clip, and not
one specific media reference.  (You could add more metadata in there
too.)

(One may also be able to see clips containing other clips, in some
way.  But more microformats are needed before that can be done.)


Comments?

See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From whump at mac.com  Tue Dec  6 23:22:08 2005
From: whump at mac.com (Bill Humphries)
Date: Tue Dec  6 23:22:14 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512062027q5280e5e8reaf7e9b789d62683@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
	<81A2CD0E-41D7-4DEB-A4E4-71F7DC16E061@mac.com>
	<84ce626f0512062027q5280e5e8reaf7e9b789d62683@mail.gmail.com>
Message-ID: <075E02AB-6065-47E6-B027-36A1C771E317@mac.com>


On Dec 6, 2005, at 8:27 PM, Charles Iliya Krempeaux wrote:

> I think that all shows, episodes, series, and channels will (in the
> near future) have URLs associated with them.  So, I think it is
> important to work that concept in there too.  (Actually, I can
> guarantee you that at least some of them will.)

Since that's currently not the case (unless you count the handful of  
shows available via iTMS,) I'm going to fall back on the principles  
and the "you ain't gonna need it" rule and leave that out for now.

Hopefully I'm not premature in writing up a straw-man model.

I've punted the idea to people who are practitioners in the domain  
for further comment, and will get back to the list.

-- whump
From danny.ayers at gmail.com  Wed Dec  7 01:39:07 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Dec  7 01:39:09 2005
Subject: [uf-discuss] rel="homepage"?
In-Reply-To: <a2971a0f13b2858b56c17b7e0ad0cb08@technorati.com>
References: <1f2ed5cd0512060202s547f756bl4908b20cfc642018@mail.gmail.com>
	<op.s1cw2hj9ares2h@mail.solitude.dk>
	<1f2ed5cd0512060353n762fffacxf8adf4c48127c2c2@mail.gmail.com>
	<op.s1c12feaares2h@mail.solitude.dk>
	<1f2ed5cd0512060435x3bb0dc08q6920cea84be02a59@mail.gmail.com>
	<43958DFF.1070100@blogmatrix.com> <op.s1c52ff2ares2h@mail.solitude.dk>
	<ee0909a60512060617g738902c2l5d48fbec2716e4b4@mail.gmail.com>
	<1f2ed5cd0512061021q51db5fc3tc3782dd243689efb@mail.gmail.com>
	<a2971a0f13b2858b56c17b7e0ad0cb08@technorati.com>
Message-ID: <1f2ed5cd0512070139x799604f7pea107513398b4443@mail.gmail.com>

> If it's not otherwise documented, clone one of the other rel formats
> and fill it in as a draft

Ok, done that :

http://microformats.org/wiki/rel-home


--

http://dannyayers.com
From davidjanes at blogmatrix.com  Wed Dec  7 05:30:19 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec  7 05:30:22 2005
Subject: [uf-discuss] Microformats and When 2.0
Message-ID: <4396E3EB.5080200@blogmatrix.com>

Was anyone holding up the uF flag for hCalendar at When 2.0 [1]?

Regards, etc...
David

[1] http://blogs.zdnet.com/BTL/?p=2236&part=rss&tag=feed&subj=zdblog
From scott at randomchaos.com  Wed Dec  7 05:41:37 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Wed Dec  7 05:41:51 2005
Subject: [uf-discuss] Microformats and When 2.0
In-Reply-To: <4396E3EB.5080200@blogmatrix.com>
References: <4396E3EB.5080200@blogmatrix.com>
Message-ID: <2D9E931A-507F-42FF-9FD7-5812AD6AA398@randomchaos.com>

David Janes -- BlogMatrix wrote:

> Was anyone holding up the uF flag for hCalendar at When 2.0 [1]?

http://tantek.com/log/2005/12.html#d06t1551

Peace,
Scott
From davidjanes at blogmatrix.com  Wed Dec  7 06:51:45 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec  7 06:51:53 2005
Subject: [uf-discuss] Somewhat Universal Microformat Parser
Message-ID: <4396F701.20309@blogmatrix.com>

Here's what I've been working on for the last couple of days. It's a 
service -- actually, a front end onto a Python library/framework -- that 
can rip apart microformats into a (hopefully) simpler format that will 
be easier for programs to manipulate.

pages:
- the interface [1]
- an example of hAtom parsing [2]

you can paste XHTML fragments in -- try something from the hReview page [3].

microformats supported:
- hatom - pretty good
- hreview - a lot of work is needed
- hcard - pretty good
- rel-tag - actually, a slightly expanded "rel-reviewed-tag" from hreview

I hope to have vCalendar and xEntry in their this afternoon/tomorrow.

Here's what a parser looks like [4]

Regards, etc...
David
http://www.blogmatrix.com

[1] http://www.davidjanes.com/microformats/extract/
[2] 
http://www.davidjanes.com/microformats/extract/?uri=http%3A%2F%2Fblog.davidjanes.com%2F&microformat=hatom&submit=Submit
[3] http://microformats.org/wiki/hreview
[4]

class MicroformatHReview(microformat.Microformat):
   def __init__(self):
     microformat.Microformat.__init__(self, "hreview")

     self.CollectClassText('version')
     self.CollectClassText('summary', text_type = microformat.TT_XML_INNER)
     self.CollectClassText('description', text_type = 
microformat.TT_XML_INNER)
     self.CollectClassText('type')
     self.CollectClassText('dtreviewed', text_type = microformat.TT_ABBR_DT)
     self.CollectClassText('info', text_type = microformat.TT_XML_OUTER)
     self.CollectClassText('reviewer', text_type = microformat.TT_XML_OUTER)
     self.CollectRelAttribute('permalink', 'href')

     self.CollectClassText('rating', text_type = microformat.TT_ABBR)
     self.CollectClassText('best', text_type = microformat.TT_ABBR)
     self.CollectClassText('worst', text_type = microformat.TT_ABBR)

     self.CollectClassModifier('item')

     self.CollectRelReparse('tag', reltag.MicroformatRelTag())
     self.CollectClassReparse('reviewer', hcard.MicroformatHCard())

     self.DeclareRepeatingName('reviewer')
     self.DeclareRepeatingName('tag')
From tantek at cs.stanford.edu  Wed Dec  7 07:30:56 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec  7 07:31:17 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <075E02AB-6065-47E6-B027-36A1C771E317@mac.com>
Message-ID: <BFBC3FCC.64A48%tantek@cs.stanford.edu>

On 12/6/05 11:22 PM, "Bill Humphries" <whump@mac.com> wrote:

> 
> On Dec 6, 2005, at 8:27 PM, Charles Iliya Krempeaux wrote:
> 
>> I think that all shows, episodes, series, and channels will (in the
>> near future) have URLs associated with them.  So, I think it is
>> important to work that concept in there too.  (Actually, I can
>> guarantee you that at least some of them will.)
> 
> Since that's currently not the case (unless you count the handful of
> shows available via iTMS,) I'm going to fall back on the principles
> and the "you ain't gonna need it" rule and leave that out for now.
> 
> Hopefully I'm not premature in writing up a straw-man model.

Hi Bill,

Writing up a straw-man model *is* premature in that it is part of doing the
*-brainstorming step in the process which should be done AFTER first doing
the research and documentation for *-examples and *-formats.

 http://microformats.org/wiki/process

That is, assuming you do want to make it into a microformat.  If all you
want to do is start publishing the content yourself and figuring out
semantic classes to mark it up, then by all means, go ahead and experiment
with actual blog posts.

In this specific case, I'll point you to the existing media-metadata work
and ask you to please help fill that out, as it *desperately* needs *actual*
examples of *content* about media published on the web, in addition to the
documentation/contrasting of various existing formats.

 http://microformats.org/wiki/media-metadata-examples

Thanks,

Tantek

From ehs at pobox.com  Wed Dec  7 07:42:26 2005
From: ehs at pobox.com (Edward Summers)
Date: Wed Dec  7 07:42:16 2005
Subject: [uf-discuss] Somewhat Universal Microformat Parser
In-Reply-To: <4396F701.20309@blogmatrix.com>
References: <4396F701.20309@blogmatrix.com>
Message-ID: <FDC63551-C4B7-4579-9EA1-F862E98C4EAB@pobox.com>

On Dec 7, 2005, at 8:51 AM, David Janes -- BlogMatrix wrote:
> Here's what a parser looks like [4]

Nice! Are you planning on releasing the python library as a  
distribution of some kind?

//Ed
From tantek at cs.stanford.edu  Wed Dec  7 08:34:36 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec  7 08:34:59 2005
Subject: [uf-discuss] hReview Question/Statement
In-Reply-To: <4395AFEA.8050507@blogmatrix.com>
Message-ID: <BFBC4EA6.64A5C%tantek@cs.stanford.edu>

On 12/6/05 7:36 AM, "David Janes -- BlogMatrix" <davidjanes@blogmatrix.com>
wrote:

> What's the rule for associating "rating" with "best"? I'm looking at
> this example [1] from the Wiki:
> 
> <ul class="categories">
>  <li><a href="http://en.wikipedia.org/wiki/Food" rel="tag">
>   Food: <span class="rating">18</span>/<span
> class="best">30</span></a>;</li>
>  <li><a href="http://flickr.com/photos/tags/Ambience" rel="tag">
>   Ambience: <span class="rating">19</span>/<span
> class="best">30</span></a>;</li>
>  <li><a href="http://en.wikipedia.org/wiki/Service" rel="tag">
>   Service: <span class="rating">15</span>/<span
> class="best">30</span></a>;</li>
>  <li><a href="http://en.wikipedia.org/wiki/Price" rel="tag">
>   Price: <abbr class="rating" title="2">$$</abbr>...</a></li>
> </ul>
> 
> and the implied rule (if it follows) seems rather loosey goosey: if it's
> under the same parent element, associate them?.

Not quite.  The example above is demonstrating rated *tags*, i.e. a rating
along a specific axis, which is identified by with a tag.

Thus the rel-tag link forms the container in which there is a "rating" and a
"best" (and optionally a "worst") value.  Thus "rating", "best", and "worst"
are associated by containment within a single tag.

That being said...

> For example, there's
> clear way to write:
> 
> <p>
> On Fred's <span class="best">4</a> ICBM scale, I give this a <span
> class="rating">2</a>.
> </p>

I need to put in an example of exactly this.

I think to convey the scale of an overall rating, we may need to borrow the
"value" construct from hCard (as it is used in "tel" properties for
example).

 http://microformats.org/wiki/hcard#Value_excerpting

Thus the above could (should?) be marked up as:

<p class="rating">
On Fred's <span class="best">4</a> ICBM scale, I give this a <span
class="value">2</a>.
</p>

I will add this to hreview-feedback as something to make explicit in hReview
0.3.

> Would it not be better to explicitly place them within a named parent
> container (say "rated")? Then one no longer needs to make sure
> everything is grouped in some explicit way:
> 
> <p class="rated">
> I rate all my Chilis on a <span class="best">4</span> ICBM scale. The
> best I ever had was Texas Joe's Twister, which render large parts of the
> midwest uninhabitable later that night and earned a <span
> class="rating">4</span> from me.
> </p>

>From a schema standpoint, yes, agreed completely.  As to the names of the
specific fields, as noted above, we can reuse the property/"value" construct
from hCard, and avoid having to have both "rated" and "rating".

Thanks very much for the feedback David.  This will be a definite
improvement in hReview 0.3.

Tantek

From davidjanes at blogmatrix.com  Wed Dec  7 09:18:44 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec  7 09:18:46 2005
Subject: [uf-discuss] Somewhat Universal Microformat Parser
In-Reply-To: <FDC63551-C4B7-4579-9EA1-F862E98C4EAB@pobox.com>
References: <4396F701.20309@blogmatrix.com>
	<FDC63551-C4B7-4579-9EA1-F862E98C4EAB@pobox.com>
Message-ID: <43971974.4020101@blogmatrix.com>

Edward Summers wrote:
> On Dec 7, 2005, at 8:51 AM, David Janes -- BlogMatrix wrote:
>> Here's what a parser looks like [4]
> 
> Nice! Are you planning on releasing the python library as a distribution 
> of some kind?

Yes. Probably next week once I have a go-around on the code.

Regards, etc...
David

From davidjanes at blogmatrix.com  Wed Dec  7 09:57:39 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec  7 09:57:41 2005
Subject: [uf-discuss] hReview Question/Statement
In-Reply-To: <BFBC4EA6.64A5C%tantek@cs.stanford.edu>
References: <BFBC4EA6.64A5C%tantek@cs.stanford.edu>
Message-ID: <43972293.2050103@blogmatrix.com>

Tantek ?elik wrote:

>>From a schema standpoint, yes, agreed completely.  As to the names of the
> specific fields, as noted above, we can reuse the property/"value" construct
> from hCard, and avoid having to have both "rated" and "rating".
> 
> Thanks very much for the feedback David.  This will be a definite
> improvement in hReview 0.3.

I'm getting into the spirit of what the spec meanings now, so it's all 
becoming a little clearer. I've modified my parser a bit to reflect 
your's and Ryan's comments, plus a better understanding how 
reviewer/item works.

Here's some parsed hReviews, randomly chosen:

http://tinyurl.com/ctg6m
http://tinyurl.com/c7kyd
http://tinyurl.com/dmxnr
http://tinyurl.com/99nwc

Regards, etc...
David
From davidjanes at blogmatrix.com  Wed Dec  7 12:59:27 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec  7 13:00:11 2005
Subject: [uf-discuss] Problems with hCalendar formatting
Message-ID: <43974D2F.5000400@blogmatrix.com>

I'm looking at this [1]. It looks like the "dtstart" and "dtend" are 
outside of the associated "vevents" and thus shouldn't be parsed. Agree 
or disagree?

Regards, etc...
David

[1] http://we05.com/program.cfm
From davidjanes at blogmatrix.com  Wed Dec  7 13:15:01 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec  7 13:15:03 2005
Subject: [uf-discuss] Almost UMP: hCalendar Supported
Message-ID: <439750D5.1080901@blogmatrix.com>

Buffalo Bills in EvDB
http://tinyurl.com/ck7jr

Some Chilean event
http://tinyurl.com/csedz

Ice Hockey stuff -- alas missing the times. Perhaps there's something 
wrong with my parser?
http://iceoasis.shrub.ca/
http://tinyurl.com/ahrs3

Brian Suda's lesser known holidays:
http://tinyurl.com/9cz2c

As per usual, start here if you want to try it yourself:
http://www.davidjanes.com/microformats/extract/

Regards, etc...
David

From tantek at cs.stanford.edu  Wed Dec  7 13:32:56 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec  7 13:33:26 2005
Subject: [uf-discuss] Problems with hCalendar formatting
In-Reply-To: <43974D2F.5000400@blogmatrix.com>
Message-ID: <BFBC94E3.64AA5%tantek@cs.stanford.edu>

On 12/7/05 12:59 PM, "David Janes -- BlogMatrix" <davidjanes@blogmatrix.com>
wrote:

> I'm looking at this [1]. It looks like the "dtstart" and "dtend" are
> outside of the associated "vevents" and thus shouldn't be parsed. Agree
> or disagree?
> 
> Regards, etc...
> David
> 
> [1] http://we05.com/program.cfm

Note the judicious use of "headers" attributes to link the vevent table data
cells to their dtstart and dtend table header cells.

Technique described here:

 http://microformats.org/wiki/hcalendar-brainstorming#Tabular_Data

Thanks,

Tantek

From davidjanes at blogmatrix.com  Wed Dec  7 14:47:48 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec  7 14:47:51 2005
Subject: [uf-discuss] Problems with hCalendar formatting
In-Reply-To: <BFBC94E3.64AA5%tantek@cs.stanford.edu>
References: <BFBC94E3.64AA5%tantek@cs.stanford.edu>
Message-ID: <43976694.4000906@blogmatrix.com>

Tantek ?elik wrote:
> On 12/7/05 12:59 PM, "David Janes -- BlogMatrix" <davidjanes@blogmatrix.com>
> wrote:
> 
>> I'm looking at this [1]. It looks like the "dtstart" and "dtend" are
>> outside of the associated "vevents" and thus shouldn't be parsed. Agree
>> or disagree?
>>
>> Regards, etc...
>> David
>>
>> [1] http://we05.com/program.cfm
> 
> Note the judicious use of "headers" attributes to link the vevent table data
> cells to their dtstart and dtend table header cells.
> 
> Technique described here:
> 
>  http://microformats.org/wiki/hcalendar-brainstorming#Tabular_Data

Ah, brilliant. Here's the Web05 data parsed:
http://tinyurl.com/cdy5m

I still need to work on the categories stuff.

Regards, etc...
From ryan at technorati.com  Wed Dec  7 15:31:28 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Dec  7 15:31:29 2005
Subject: [uf-discuss] Problems with hCalendar formatting
In-Reply-To: <BFBC94E3.64AA5%tantek@cs.stanford.edu>
References: <BFBC94E3.64AA5%tantek@cs.stanford.edu>
Message-ID: <444E5001-3FF2-45FE-AFB7-482229C07856@technorati.com>

On Dec 7, 2005, at 1:32 PM, Tantek ?elik wrote:
> On 12/7/05 12:59 PM, "David Janes -- BlogMatrix"  
> <davidjanes@blogmatrix.com>
> wrote:
>
>> I'm looking at this [1]. It looks like the "dtstart" and "dtend" are
>> outside of the associated "vevents" and thus shouldn't be parsed.  
>> Agree
>> or disagree?
>>
>> Regards, etc...
>> David
>>
>> [1] http://we05.com/program.cfm
>
> Note the judicious use of "headers" attributes to link the vevent  
> table data
> cells to their dtstart and dtend table header cells.
>
> Technique described here:
>
>  http://microformats.org/wiki/hcalendar-brainstorming#Tabular_Data

This reminds me, I have a draft blog post explaining this more  
succinctly. I'll hopefully get it posted next week (after finals are  
over). Feel free to bug me about it. :-D

-ryan
--
Ryan King
ryan@technorati.com


From jpanzer at aol.net  Wed Dec  7 16:52:59 2005
From: jpanzer at aol.net (John Panzer)
Date: Wed Dec  7 16:53:11 2005
Subject: [uf-discuss] Interest in stock ticker microformat?
Message-ID: <439783EB.9020507@aol.net>

An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051207/caa1a91a/attachment.htm
From whump at mac.com  Thu Dec  8 00:08:35 2005
From: whump at mac.com (Bill Humphries)
Date: Thu Dec  8 00:08:40 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <BFBC3FCC.64A48%tantek@cs.stanford.edu>
References: <BFBC3FCC.64A48%tantek@cs.stanford.edu>
Message-ID: <F0C97242-DFA1-4B48-B4D8-5C84F0209014@mac.com>


On Dec 7, 2005, at 7:30 AM, Tantek ?elik wrote:

> In this specific case, I'll point you to the existing media- 
> metadata work
> and ask you to please help fill that out, as it *desperately* needs  
> *actual*
> examples of *content* about media published on the web, in addition  
> to the
> documentation/contrasting of various existing formats.
>
>  http://microformats.org/wiki/media-metadata-examples

Sorry about the delay in responding, long day.

I'll take that on. There's some interest in the fan/media scholar  
communities to proceed.

I'll start collecting URLs of examples in the wild.

Thanks.

-- whump
From davidjanes at blogmatrix.com  Thu Dec  8 03:04:09 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec  8 03:04:11 2005
Subject: [uf-discuss] Almost UMP:xFolk Supported
In-Reply-To: <439750D5.1080901@blogmatrix.com>
References: <439750D5.1080901@blogmatrix.com>
Message-ID: <43981329.7020600@blogmatrix.com>

I've added xFolk [1] to the list of microformats the Almost Universal 
Microformat Parser handles.

Examples:
http://tinyurl.com/cdcfp (http://de.lirio.us/rubric)
http://tinyurl.com/cddta (http://unalog.com/)

Regards, etc...
David

[1] http://microformats.org/wiki/xfolk
From davidjanes at blogmatrix.com  Thu Dec  8 03:05:41 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec  8 03:05:43 2005
Subject: [uf-discuss] Nomenclature Question
Message-ID: <43981385.9030903@blogmatrix.com>

- RelHome?
- rel-home?
- Rel-Home?

Variants of these across the rel-* are all available. My understanding 
is that this should be:

- RelHome -- this official name
- rel-home -- the wiki page name

Yes, no?

Regards, etc...
From davidjanes at blogmatrix.com  Thu Dec  8 03:14:01 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec  8 03:14:03 2005
Subject: [uf-discuss] Nomenclature Question (II)
Message-ID: <43981579.5060301@blogmatrix.com>

"adr" and "geo" standing there all nekkid as microformat names makes me 
kind of nervous. How about

adr-mixin, geo-mixin
mAdr, mGeo (for mixin)
cAdr, cGeo (for component)

to recognize their potential as mixin/components for other uFs?

Regards, etc...
David
From chudley at gmail.com  Thu Dec  8 07:14:18 2005
From: chudley at gmail.com (C. Hudley)
Date: Thu Dec  8 07:14:21 2005
Subject: [uf-discuss] Almost UMP:xFolk Supported
In-Reply-To: <43981329.7020600@blogmatrix.com>
References: <439750D5.1080901@blogmatrix.com> <43981329.7020600@blogmatrix.com>
Message-ID: <e28976dd0512080714m6b62a507k3af8590f4390657d@mail.gmail.com>

On 12/8/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
> I've added xFolk [1] to the list of microformats the Almost Universal
> Microformat Parser handles.
>
> Examples:
> http://tinyurl.com/cddta (http://unalog.com/)

This is very cool, thanks!

What is the intended meaning of the repeating "@uri =
http://unalog.com" here?  Is it intended to be the identifier for the
entry?  I'm asking because there is a URI of sorts embedded in the
COinS for each entry (see span[@class.contains(Z3988)]).

Over on gcs-pcs-list we've been talking about a simplification of the
COinS spec when simply indicating what-the-identifier-is, which is
(obviously) rather lost inside the OpenURL ContextObject inside the
span.  Lately we've considered instead just using "class='uri'" and a
URI in a title or as the textnode content.  I'm experimenting with
something like this in the canary database as well.

All of which brings me back to the question of clarifying where the
identifiers are...


--
C. Hudley
We Know The Truth, Inc.
From tantek at cs.stanford.edu  Thu Dec  8 07:26:15 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  8 07:26:37 2005
Subject: [uf-discuss] Nomenclature Question
In-Reply-To: <43981385.9030903@blogmatrix.com>
Message-ID: <BFBD9064.64B7D%tantek@cs.stanford.edu>

On 12/8/05 3:05 AM, "David Janes -- BlogMatrix" <davidjanes@blogmatrix.com>
wrote:

> - RelHome?
> - rel-home?
> - Rel-Home?
> 
> Variants of these across the rel-* are all available. My understanding
> is that this should be:
> 
> - RelHome -- this official name
> - rel-home -- the wiki page name

I think the latter is preferred overall for rel values.  There are some
places on the wiki where the old style of "RelTag" is used, but those should
be edited IMHO to be "rel-tag".

Here is some off the top of my head reasoning:

The name of the "rel" attribute is case-sensitive in XHTML, thus it is
better to use the precise case (all lowercase in particular) of the
attribute in XHTML.

Once you've done that, it's just easier to use all lowercase for the value
as well, and it conveniently matches the wiki page name.

Other thoughts?

Thanks,

Tantek

From tantek at cs.stanford.edu  Thu Dec  8 07:28:18 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  8 07:28:40 2005
Subject: [uf-discuss] Nomenclature Question (II)
In-Reply-To: <43981579.5060301@blogmatrix.com>
Message-ID: <BFBD9109.64B80%tantek@cs.stanford.edu>

On 12/8/05 3:14 AM, "David Janes -- BlogMatrix" <davidjanes@blogmatrix.com>
wrote:

> "adr" and "geo" standing there all nekkid as microformat names makes me
> kind of nervous. How about
> 
> adr-mixin, geo-mixin
> mAdr, mGeo (for mixin)
> cAdr, cGeo (for component)
> 
> to recognize their potential as mixin/components for other uFs?

The introduction of mixing/component aspects into the name feels too
programmer-centric (while microformats as a whole seek to be
content-author-centric).

Also, "adr" and "geo" reflect the precise value of the root class names to
be used, and thus their names are useful mnemonics for the (beginning of
the) format.

Thanks,

Tantek

From davidjanes at blogmatrix.com  Thu Dec  8 07:40:46 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec  8 07:40:49 2005
Subject: [uf-discuss] Almost UMP:xFolk Supported
In-Reply-To: <e28976dd0512080714m6b62a507k3af8590f4390657d@mail.gmail.com>
References: <439750D5.1080901@blogmatrix.com> <43981329.7020600@blogmatrix.com>
	<e28976dd0512080714m6b62a507k3af8590f4390657d@mail.gmail.com>
Message-ID: <439853FE.20706@blogmatrix.com>


C. Hudley wrote:
> On 12/8/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
>> I've added xFolk [1] to the list of microformats the Almost Universal
>> Microformat Parser handles.
>>
>> Examples:
>> http://tinyurl.com/cddta (http://unalog.com/)
> 
> This is very cool, thanks!
> 
> What is the intended meaning of the repeating "@uri =
> http://unalog.com" here?  Is it intended to be the identifier for the
> entry?  I'm asking because there is a URI of sorts embedded in the
> COinS for each entry (see span[@class.contains(Z3988)]).

"@uri" and in fact "@anything" are little pieces of information the 
parser has picked up among the way, not necessarily part of the uF. In 
this particular case, it's the uri of the page being parsed.

There's another I added this morning, called '@index' which allows the 
uF element to be corresponded to the parsed version. For example, 
'@id=vevent-3'means that the 3rd element with "vevent" in the class 
attribute is the one that was parsed.

> Over on gcs-pcs-list we've been talking about a simplification of the
> COinS spec when simply indicating what-the-identifier-is, which is
> (obviously) rather lost inside the OpenURL ContextObject inside the
> span.  Lately we've considered instead just using "class='uri'" and a
> URI in a title or as the textnode content.  I'm experimenting with
> something like this in the canary database as well.

How about rel="bookmark" (i.e. rel-bookmark) Not only is it used in 
hAtom, it's also part of the HTML spec [1]

> All of which brings me back to the question of clarifying where the
> identifiers are...

Regards, etc...
David

[1]
http://www.w3.org/TR/REC-html40/types.html#type-links
From bkdelong at pobox.com  Thu Dec  8 07:47:19 2005
From: bkdelong at pobox.com (B.K. DeLong)
Date: Thu Dec  8 07:48:11 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <F0C97242-DFA1-4B48-B4D8-5C84F0209014@mac.com>
References: <BFBC3FCC.64A48%tantek@cs.stanford.edu>
	<F0C97242-DFA1-4B48-B4D8-5C84F0209014@mac.com>
Message-ID: <6.2.3.4.2.20051208104614.08f69eb0@mail.brain-stream.net>

At 03:08 AM 12/8/2005, Bill Humphries wrote:

>On Dec 7, 2005, at 7:30 AM, Tantek ?elik wrote:
>
>>In this specific case, I'll point you to the existing media- metadata work
>>and ask you to please help fill that out, as it *desperately* needs
>>*actual*
>>examples of *content* about media published on the web, in addition
>>to the
>>documentation/contrasting of various existing formats.
>>
>>  http://microformats.org/wiki/media-metadata-examples
>
>Sorry about the delay in responding, long day.
>
>I'll take that on. There's some interest in the fan/media scholar
>communities to proceed.
>
>I'll start collecting URLs of examples in the wild.

The one I'm doing for my client is still in 
progress but I'll have a URL for you once we implement.


--
B.K. DeLong
bkdelong@pobox.com
+1.617.797.8471

http://www.wkdelong.org         Son.
http://www.haloworldwide.com            Work.
http://www.bostonredcross.org           Volunteer.
http://www.brain-stream.com             Play.
http://www.the-leaky-cauldron.org       Potter.



PGP Fingerprint:
38D4 D4D4 5819 8667 DFD5  A62D AF61 15FF 297D 67FE

FOAF:
http://foaf.brain-stream.org 

From chudley at gmail.com  Thu Dec  8 08:02:05 2005
From: chudley at gmail.com (C. Hudley)
Date: Thu Dec  8 08:02:10 2005
Subject: [uf-discuss] Almost UMP:xFolk Supported
In-Reply-To: <439853FE.20706@blogmatrix.com>
References: <439750D5.1080901@blogmatrix.com> <43981329.7020600@blogmatrix.com>
	<e28976dd0512080714m6b62a507k3af8590f4390657d@mail.gmail.com>
	<439853FE.20706@blogmatrix.com>
Message-ID: <e28976dd0512080802l291ba899r690858d3d8d99a4f@mail.gmail.com>

On 12/8/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
>
> "@uri" and in fact "@anything" are little pieces of information the
> parser has picked up among the way, not necessarily part of the uF. In
> this particular case, it's the uri of the page being parsed.

It would be nice to be able to pick up per-microobject URIs, should
they be specified.


> There's another I added this morning, called '@index' which allows the
> uF element to be corresponded to the parsed version. For example,
> '@id=vevent-3'means that the 3rd element with "vevent" in the class
> attribute is the one that was parsed.

That's very helpful!


> > Over on gcs-pcs-list we've been talking about a simplification of the
> > COinS spec when simply indicating what-the-identifier-is, which is
> > (obviously) rather lost inside the OpenURL ContextObject inside the
> > span.  Lately we've considered instead just using "class='uri'" and a
> > URI in a title or as the textnode content.  I'm experimenting with
> > something like this in the canary database as well.
>
> How about rel="bookmark" (i.e. rel-bookmark) Not only is it used in
> hAtom, it's also part of the HTML spec [1]

As I understand it, rel="bookmark" implies that identified items
are/have directly resolvable http URLs.  In our use cases the URIs
often include not-directly-resolvable URNs, such as those constructed
using the recently registered "info" URN namespace id (e.g. ISBNs or
DOIs... and "just point to amazon or the DOI foundation" is not a
sufficient solution :).

I'd presume - perhaps incorrectly - that most applications parsing
rel="bookmark" items would in turn assume that they are http-locatable
URLs.  This is certainly the case in hAtom, where it's specified as
such (unless I misunderstand the concept of "permalinks").  If that's
the case, then this wouldn't work.
From davidjanes at blogmatrix.com  Thu Dec  8 08:06:51 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec  8 08:06:55 2005
Subject: [uf-discuss] Almost UMP:xFolk Supported
In-Reply-To: <e28976dd0512080802l291ba899r690858d3d8d99a4f@mail.gmail.com>
References: <439750D5.1080901@blogmatrix.com>
	<43981329.7020600@blogmatrix.com>	<e28976dd0512080714m6b62a507k3af8590f4390657d@mail.gmail.com>	<439853FE.20706@blogmatrix.com>
	<e28976dd0512080802l291ba899r690858d3d8d99a4f@mail.gmail.com>
Message-ID: <43985A1B.4060504@blogmatrix.com>

C. Hudley wrote:
> On 12/8/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
>> "@uri" and in fact "@anything" are little pieces of information the
>> parser has picked up among the way, not necessarily part of the uF. In
>> this particular case, it's the uri of the page being parsed.
> 
> It would be nice to be able to pick up per-microobject URIs, should
> they be specified.
> 
> 
>> There's another I added this morning, called '@index' which allows the
>> uF element to be corresponded to the parsed version. For example,
>> '@id=vevent-3'means that the 3rd element with "vevent" in the class
>> attribute is the one that was parsed.
> 
> That's very helpful!

Especially for some apps I'm working on :-)

> 
> 
>>> Over on gcs-pcs-list we've been talking about a simplification of the
>>> COinS spec when simply indicating what-the-identifier-is, which is
>>> (obviously) rather lost inside the OpenURL ContextObject inside the
>>> span.  Lately we've considered instead just using "class='uri'" and a
>>> URI in a title or as the textnode content.  I'm experimenting with
>>> something like this in the canary database as well.
>> How about rel="bookmark" (i.e. rel-bookmark) Not only is it used in
>> hAtom, it's also part of the HTML spec [1]
> 
> As I understand it, rel="bookmark" implies that identified items
> are/have directly resolvable http URLs.  In our use cases the URIs
> often include not-directly-resolvable URNs, such as those constructed
> using the recently registered "info" URN namespace id (e.g. ISBNs or
> DOIs... and "just point to amazon or the DOI foundation" is not a
> sufficient solution :).
> 
> I'd presume - perhaps incorrectly - that most applications parsing
> rel="bookmark" items would in turn assume that they are http-locatable
> URLs.  This is certainly the case in hAtom, where it's specified as
> such (unless I misunderstand the concept of "permalinks").  If that's
> the case, then this wouldn't work.

Yeah, rel-bookmark assumes that the given URI will resolve to a copy of 
the microformat/microcontent enclosed.

Maybe this concept [1] from hCard would be useful?

Regards, etc...
David

[1] http://microformats.org/wiki/hcard-examples#3.6.7_UID_Type_Definition
From kennyheaton at gmail.com  Thu Dec  8 08:15:05 2005
From: kennyheaton at gmail.com (kenny heaton)
Date: Thu Dec  8 08:15:08 2005
Subject: [uf-discuss] hCard tel extension
Message-ID: <65b4e01f0512080815v11a41338la75a36d77fb7bc7d@mail.gmail.com>

There dosn't seem to be a way to declare a telephone extension in the
hCard microformat. I quickly looked over the vCard RFC2426 spec and
didn't find it there either, so I'm wondering is this an intentional
omission or an oversite (or is it there and I just missed it), and is
there a need for it?

Kenny
From chudley at gmail.com  Thu Dec  8 08:15:10 2005
From: chudley at gmail.com (C. Hudley)
Date: Thu Dec  8 08:15:12 2005
Subject: [uf-discuss] Almost UMP:xFolk Supported
In-Reply-To: <43985A1B.4060504@blogmatrix.com>
References: <439750D5.1080901@blogmatrix.com> <43981329.7020600@blogmatrix.com>
	<e28976dd0512080714m6b62a507k3af8590f4390657d@mail.gmail.com>
	<439853FE.20706@blogmatrix.com>
	<e28976dd0512080802l291ba899r690858d3d8d99a4f@mail.gmail.com>
	<43985A1B.4060504@blogmatrix.com>
Message-ID: <e28976dd0512080815l4c8984fclaf97e7234b752c5a@mail.gmail.com>

On 12/8/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:

> Maybe this concept [1] from hCard would be useful?
> [1] http://microformats.org/wiki/hcard-examples#3.6.7_UID_Type_Definition

Yes, exactly like that, but in our case, they're URIs, so we'd rather
call them URIs. :)
From rbach at rbach.priv.at  Thu Dec  8 11:36:46 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Thu Dec  8 11:35:58 2005
Subject: [uf-discuss] Values for rel/rev are case-insensitive in HTML (was:
 Nomenclature Question)
In-Reply-To: <BFBD9064.64B7D%tantek@cs.stanford.edu>
References: <BFBD9064.64B7D%tantek@cs.stanford.edu>
Message-ID: <43988B4E.4040400@rbach.priv.at>

Tantek ?elik wrote:
> The name of the "rel" attribute is case-sensitive in XHTML, thus it is
> better to use the precise case (all lowercase in particular) of the
> attribute in XHTML.

In HTML it is case-insensitive.

?These link types are case-insensitive, i.e., "Alternate" has the same
meaning as "alternate".?
-- http://www.w3.org/TR/html401/types.html#type-links

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From jpanzer at aol.net  Thu Dec  8 12:15:25 2005
From: jpanzer at aol.net (John Panzer)
Date: Thu Dec  8 12:15:38 2005
Subject: [uf-discuss] Interest in stock ticker microformat?
In-Reply-To: <439783EB.9020507@aol.net>
References: <439783EB.9020507@aol.net>
Message-ID: <4398945D.40705@aol.net>

An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051208/6123f5a7/attachment.htm
From ryan at technorati.com  Thu Dec  8 12:19:04 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  8 12:19:07 2005
Subject: [uf-discuss] hCard tel extension
In-Reply-To: <65b4e01f0512080815v11a41338la75a36d77fb7bc7d@mail.gmail.com>
References: <65b4e01f0512080815v11a41338la75a36d77fb7bc7d@mail.gmail.com>
Message-ID: <18380FFF-A02F-4F22-9D05-DE78DB94264E@technorati.com>

On Dec 8, 2005, at 8:15 AM, kenny heaton wrote:

> There dosn't seem to be a way to declare a telephone extension in the
> hCard microformat. I quickly looked over the vCard RFC2426 spec and
> didn't find it there either, so I'm wondering is this an intentional
> omission or an oversite (or is it there and I just missed it), and is
> there a need for it?

Well, after a bit of poking around http://microformats.org/wiki/hcard  
and http://ietf.org/rfc/rfc2426.txt, I can't seem to find anything  
specified. It appears to be undefined in vcard and x.500. So, I'd say  
just but it in the tel element like:

<span class="tel">
	<span class="type">cell</span>: <span class="value">800 555-1212 x  
1234</span
</span>

-ryan
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Thu Dec  8 12:22:59 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec  8 12:23:01 2005
Subject: [uf-discuss] Values for rel/rev are case-insensitive in HTML
	(was: Nomenclature Question)
In-Reply-To: <43988B4E.4040400@rbach.priv.at>
References: <BFBD9064.64B7D%tantek@cs.stanford.edu>
	<43988B4E.4040400@rbach.priv.at>
Message-ID: <6C675C6D-B11F-4240-910B-B9926598D240@technorati.com>

On Dec 8, 2005, at 11:36 AM, Robert Bachmann wrote:

> Tantek ?elik wrote:
>> The name of the "rel" attribute is case-sensitive in XHTML, thus  
>> it is
>> better to use the precise case (all lowercase in particular) of the
>> attribute in XHTML.
>
> In HTML it is case-insensitive.
>
> ?These link types are case-insensitive, i.e., "Alternate" has the same
> meaning as "alternate".?
> -- http://www.w3.org/TR/html401/types.html#type-links

Yes, but <a rel=".."/> is different than <a Rel="..." />

-ryan
--
Ryan King
ryan@technorati.com



From supercanadian at gmail.com  Thu Dec  8 12:24:05 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu Dec  8 12:24:07 2005
Subject: [uf-discuss] Values for rel/rev are case-insensitive in HTML
	(was: Nomenclature Question)
In-Reply-To: <43988B4E.4040400@rbach.priv.at>
References: <BFBD9064.64B7D%tantek@cs.stanford.edu>
	<43988B4E.4040400@rbach.priv.at>
Message-ID: <84ce626f0512081224x41d3ca01g46d7f4ff4593cdf8@mail.gmail.com>

Hello,

On 12/8/05, Robert Bachmann <rbach@rbach.priv.at> wrote:
> Tantek ?elik wrote:
> > The name of the "rel" attribute is case-sensitive in XHTML, thus it is
> > better to use the precise case (all lowercase in particular) of the
> > attribute in XHTML.
>
> In HTML it is case-insensitive.
>
> ?These link types are case-insensitive, i.e., "Alternate" has the same
> meaning as "alternate".?
> -- http://www.w3.org/TR/html401/types.html#type-links
>

Should probably do the same for class names too -- use all lowercase
for class names too.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From tantek at cs.stanford.edu  Thu Dec  8 12:53:10 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec  8 12:53:37 2005
Subject: [uf-discuss] hCard tel extension
In-Reply-To: <65b4e01f0512080815v11a41338la75a36d77fb7bc7d@mail.gmail.com>
Message-ID: <BFBDA024.64B94%tantek@cs.stanford.edu>

On 12/8/05 8:15 AM, "kenny heaton" <kennyheaton@gmail.com> wrote:

> There dosn't seem to be a way to declare a telephone extension in the
> hCard microformat. I quickly looked over the vCard RFC2426 spec and
> didn't find it there either, so I'm wondering is this an intentional
> omission or an oversite (or is it there and I just missed it), and is
> there a need for it?

Good question.  I don't have an answer off the top of my head.

Please add it to http://microformats.org/wiki/hcard-issues

So we don't forget, and can document the q&a in the FAQ once figured out.

Thanks,

Tantek

From scott at randomchaos.com  Thu Dec  8 13:47:37 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec  8 13:47:43 2005
Subject: [uf-discuss] Values for rel/rev are case-insensitive in HTML
	(was: Nomenclature Question)
In-Reply-To: <6C675C6D-B11F-4240-910B-B9926598D240@technorati.com>
References: <BFBD9064.64B7D%tantek@cs.stanford.edu>
	<43988B4E.4040400@rbach.priv.at>
	<6C675C6D-B11F-4240-910B-B9926598D240@technorati.com>
Message-ID: <3701F5E7-5F56-4F5E-B9AC-22B25AA7C93F@randomchaos.com>

Ryan King wrote:

>> ?These link types are case-insensitive, i.e., "Alternate" has the  
>> same
>> meaning as "alternate".?
>> -- http://www.w3.org/TR/html401/types.html#type-links
>
> Yes, but <a rel=".."/> is different than <a Rel="..." />

What markup language are we talking about here?

In XHTML, <a Rel="..." /> is different in that it's invalid:

http://www.w3.org/TR/xhtml1/#h-4.2

"XHTML documents must use lower case for all HTML element and  
attribute names."

In HTML 4, the two are identical:

http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.2

"Attribute names are always case-insensitive."

Peace,
Scott
From supercanadian at gmail.com  Thu Dec  8 15:04:37 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu Dec  8 15:04:40 2005
Subject: [uf-discuss] Values for rel/rev are case-insensitive in HTML
	(was: Nomenclature Question)
In-Reply-To: <3701F5E7-5F56-4F5E-B9AC-22B25AA7C93F@randomchaos.com>
References: <BFBD9064.64B7D%tantek@cs.stanford.edu>
	<43988B4E.4040400@rbach.priv.at>
	<6C675C6D-B11F-4240-910B-B9926598D240@technorati.com>
	<3701F5E7-5F56-4F5E-B9AC-22B25AA7C93F@randomchaos.com>
Message-ID: <84ce626f0512081504w19b1fdabx352506f7b163037f@mail.gmail.com>

Hello,

On 12/8/05, Scott Reynen <scott@randomchaos.com> wrote:
> Ryan King wrote:
>
> >> ?These link types are case-insensitive, i.e., "Alternate" has the
> >> same
> >> meaning as "alternate".?
> >> -- http://www.w3.org/TR/html401/types.html#type-links
> >
> > Yes, but <a rel=".."/> is different than <a Rel="..." />
>
> What markup language are we talking about here?
>
> In XHTML, <a Rel="..." /> is different in that it's invalid:
>
> http://www.w3.org/TR/xhtml1/#h-4.2
>
> "XHTML documents must use lower case for all HTML element and
> attribute names."
>
> In HTML 4, the two are identical:
>
> http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.2
>
> "Attribute names are always case-insensitive."
>

I was talking about "attribute values" (not "attribute names").


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From supercanadian at gmail.com  Fri Dec  9 00:08:05 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Fri Dec  9 00:08:06 2005
Subject: [uf-discuss] Re: New Password From Wiki ?
In-Reply-To: <84ce626f0512030147g3298faf1lc86666ab243730d2@mail.gmail.com>
References: <84ce626f0512030147g3298faf1lc86666ab243730d2@mail.gmail.com>
Message-ID: <84ce626f0512090008i76cb1894w394eb0ac7a9c3e8c@mail.gmail.com>

*bump*

Anyone wiki admins here that can help with this?


See ya


On 12/3/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> Forgot my password for the wiki and tried to get my password e-mailed
> to me.  It didn't seem to work.  (Never received an e-mail with the
> password.)  Can anyone help?
>
> Wiki Username: CharlesIliyaKrempeaux
>
> TIA
>
> See ya
>
> --
>     Charles Iliya Krempeaux, B.Sc.
>
>     charles @ reptile.ca
>     supercanadian @ gmail.com
>
>     developer weblog: http://ChangeLog.ca/
> ___________________________________________________________________________
>  Never forget where you came from
>


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From webbg at wsu.edu  Fri Dec  9 09:56:10 2005
From: webbg at wsu.edu (Webb, Geoffrey Lawrence)
Date: Fri Dec  9 09:56:13 2005
Subject: [uf-discuss] Ics import in Outlook
Message-ID: <EF6631296121CF4390E090D9B4EFD069015683FB@cru80.cahe.ad.wsu.edu>

I have been using the service at suda.co.uk to harvest hCalendar events
from my web pages.  However, Outlook 2003 won't import the resulting
file.  If I change the version to 1.0, everything works fine.  Outlook
itself produces 2.0 ics files, so in a logical world Outlook should be
able to import 2.0 files.  Has anyone dealt with this problem before?
Just changing the version the stylesheet produces feels very kludgy.
From brian.suda at gmail.com  Fri Dec  9 10:04:56 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Dec  9 10:05:18 2005
Subject: [uf-discuss] Ics import in Outlook
In-Reply-To: <EF6631296121CF4390E090D9B4EFD069015683FB@cru80.cahe.ad.wsu.edu>
References: <EF6631296121CF4390E090D9B4EFD069015683FB@cru80.cahe.ad.wsu.edu>
Message-ID: <4399C748.7070509@gmail.com>

Webb, Geoffrey Lawrence wrote:

> I have been using the service at suda.co.uk to harvest hCalendar events
> from my web pages. However, Outlook 2003 won't import the resulting
> file. If I change the version to 1.0, everything works fine. Outlook
> itself produces 2.0 ics files, so in a logical world Outlook should be
> able to import 2.0 files. Has anyone dealt with this problem before?
> Just changing the version the stylesheet produces feels very kludgy

hCard has kept a list of different applications, versions and their
import/export problems[1]. Feel free to start an iCal page[2] and
document your finds with your OS version, application version etc.  This
will help other replicate and fix the problems.

[1] - http://microformats.org/wiki/vcard-implementations
[2] - http://microformats.org/wiki/ical-implementations

-brian
From webbg at wsu.edu  Fri Dec  9 11:38:30 2005
From: webbg at wsu.edu (Webb, Geoffrey Lawrence)
Date: Fri Dec  9 11:38:53 2005
Subject: [uf-discuss] Ics import in Outlook
Message-ID: <EF6631296121CF4390E090D9B4EFD0690156851C@cru80.cahe.ad.wsu.edu>

Thanks for the response Brian.  I'm very thankful for the service you
are providing.

I found the problem.  Outlook is expecting the vevent component to have
UID and DTSTAMP parameters.  I took a look at RFC2445 and I think I
found a conflict. Where the UID and DTSTAMP parameters are described the
rfc says 
"Conformance: This property MUST be included in the "VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar components".

However, the format definition starting on page 51, seems to indicate
that the UID and DTSTAMP parameters are optional.

So, does the XSLT file need to be changed or do I need to author these
parameters into my hCalendar markup?



-----Original Message-----
From: microformats-discuss-bounces@microformats.org
[mailto:microformats-discuss-bounces@microformats.org] On Behalf Of
brian suda
Sent: Friday, December 09, 2005 10:05 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] Ics import in Outlook

Webb, Geoffrey Lawrence wrote:

> I have been using the service at suda.co.uk to harvest hCalendar 
> events from my web pages. However, Outlook 2003 won't import the 
> resulting file. If I change the version to 1.0, everything works fine.

> Outlook itself produces 2.0 ics files, so in a logical world Outlook 
> should be able to import 2.0 files. Has anyone dealt with this problem
before?
> Just changing the version the stylesheet produces feels very kludgy

hCard has kept a list of different applications, versions and their
import/export problems[1]. Feel free to start an iCal page[2] and
document your finds with your OS version, application version etc.  This
will help other replicate and fix the problems.

[1] - http://microformats.org/wiki/vcard-implementations
[2] - http://microformats.org/wiki/ical-implementations

-brian
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
From brian.suda at gmail.com  Fri Dec  9 11:57:39 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Dec  9 11:58:02 2005
Subject: [uf-discuss] Ics import in Outlook
In-Reply-To: <EF6631296121CF4390E090D9B4EFD0690156851C@cru80.cahe.ad.wsu.edu>
References: <EF6631296121CF4390E090D9B4EFD0690156851C@cru80.cahe.ad.wsu.edu>
Message-ID: <4399E1B3.6080203@gmail.com>

DTSTAMP is easy, that is just the date-time stamp when the was created.
You could certainly encode that into your HTML.

UID is more difficult. That is Universal ID, and within a given page you
can be use those UIDs are unique, but over the WWW there is now way to
gauntee its uniqueness.

There seems to be a similar problem with hCard as well.

To make the UID unique, it might be possible to prepend an MD5 hash of
the URL by the transforming application, then the UID would have more
uniqueness and avoid collisions of two events with the same UID on two
seperate pages... but then if they are the same event they SHOULD have
the same UID.

UID was originally part of hCard, it was encoded on the 'id' attribute
of the element with class="vcard", but was later removed.[1]

With enough discussion we might be able to find away to get around this.
-brian

[1] - http://microformats.org/wiki/hcard-examples#3.6.7_UID_Type_Definition

Webb, Geoffrey Lawrence wrote:

>Thanks for the response Brian.  I'm very thankful for the service you
>are providing.
>
>I found the problem.  Outlook is expecting the vevent component to have
>UID and DTSTAMP parameters.  I took a look at RFC2445 and I think I
>found a conflict. Where the UID and DTSTAMP parameters are described the
>rfc says 
>"Conformance: This property MUST be included in the "VEVENT", "VTODO",
>   "VJOURNAL" or "VFREEBUSY" calendar components".
>
>However, the format definition starting on page 51, seems to indicate
>that the UID and DTSTAMP parameters are optional.
>
>So, does the XSLT file need to be changed or do I need to author these
>parameters into my hCalendar markup?
>
>
>
>-----Original Message-----
>From: microformats-discuss-bounces@microformats.org
>[mailto:microformats-discuss-bounces@microformats.org] On Behalf Of
>brian suda
>Sent: Friday, December 09, 2005 10:05 AM
>To: Microformats Discuss
>Subject: Re: [uf-discuss] Ics import in Outlook
>
>Webb, Geoffrey Lawrence wrote:
>
>  
>
>>I have been using the service at suda.co.uk to harvest hCalendar 
>>events from my web pages. However, Outlook 2003 won't import the 
>>resulting file. If I change the version to 1.0, everything works fine.
>>    
>>
>
>  
>
>>Outlook itself produces 2.0 ics files, so in a logical world Outlook 
>>should be able to import 2.0 files. Has anyone dealt with this problem
>>    
>>
>before?
>  
>
>>Just changing the version the stylesheet produces feels very kludgy
>>    
>>
>
>hCard has kept a list of different applications, versions and their
>import/export problems[1]. Feel free to start an iCal page[2] and
>document your finds with your OS version, application version etc.  This
>will help other replicate and fix the problems.
>
>[1] - http://microformats.org/wiki/vcard-implementations
>[2] - http://microformats.org/wiki/ical-implementations
>
>-brian
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>
>  
>

From tantek at cs.stanford.edu  Fri Dec  9 12:17:56 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Dec  9 12:18:18 2005
Subject: [uf-discuss] Ics import in Outlook
In-Reply-To: <4399E1B3.6080203@gmail.com>
Message-ID: <BFBF2645.64C8E%tantek@cs.stanford.edu>

On 12/9/05 11:57 AM, "brian suda" <brian.suda@gmail.com> wrote:

> DTSTAMP is easy, that is just the date-time stamp when the event was created.
> You could certainly encode that into your HTML.

Agreed.  Similarly hCard has the REV property.

> UID is more difficult. That is Universal ID, and within a given page you
> can be use those UIDs are unique, but over the WWW there is now way to
> gauntee its uniqueness.
> 
> There seems to be a similar problem with hCard as well.
> 
> To make the UID unique, it might be possible to prepend an MD5 hash of
> the URL by the transforming application, then the UID would have more
> uniqueness and avoid collisions of two events with the same UID on two
> seperate pages... but then if they are the same event they SHOULD have
> the same UID.

I am against having a transforming application automatically generate the
UID.  I think that if necessary, it should come from the content creator.


> UID was originally part of hCard, it was encoded on the 'id' attribute
> of the element with class="vcard", but was later removed.[1]
> [1] - http://microformats.org/wiki/hcard-examples#3.6.7_UID_Type_Definition

I don't think that's quite accurate.  UID has not been removed.

What we've said is that:

 a) We've never seen anyone providing unique IDs (UID equivalent) for
contact information on the web.

 b) It is a bad idea to use the HTML 'id' attribute for UID since 'id' is
only unique within the document, not globally.  That's all the above-quoted
hCard-examples section says.


Note the list of hCard properties:

 http://microformats.org/wiki/hcard#Property_List

and the hCard profile:

 http://microformats.org/wiki/hcard-profile

both contain "uid".  Thus you can do so in your hCard:

<span class="uid">insert your unique id here</span>

Thanks,

Tantek

From qidydl at gmail.com  Fri Dec  9 14:03:45 2005
From: qidydl at gmail.com (David Osolkowski)
Date: Fri Dec  9 14:03:46 2005
Subject: [uf-discuss] Ics import in Outlook
In-Reply-To: <4399E1B3.6080203@gmail.com>
References: <EF6631296121CF4390E090D9B4EFD0690156851C@cru80.cahe.ad.wsu.edu>
	<4399E1B3.6080203@gmail.com>
Message-ID: <ee0909a60512091403r567ba4fex5693bae34dba353c@mail.gmail.com>

On 12/9/05, brian suda <brian.suda@gmail.com> wrote:
>
> DTSTAMP is easy, that is just the date-time stamp when the was created.
> You could certainly encode that into your HTML.
>
> UID is more difficult. That is Universal ID, and within a given page you
> can be use those UIDs are unique, but over the WWW there is now way to
> gauntee its uniqueness.
>


The tag: URI scheme[1] provides a fairly effective way to generate unique
ID's.  I believe it is the recommended way to generate GUIDs for Atom[2].
Thus, it seems likely it could be re-used here.

[1] http://www.taguri.org/
[2] http://diveintomark.org/archives/2004/05/28/howto-atom-id

- David Osolkowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051209/bcd1d6a5/attachment.htm
From kennyheaton at gmail.com  Fri Dec  9 14:37:08 2005
From: kennyheaton at gmail.com (kenny heaton)
Date: Fri Dec  9 14:37:10 2005
Subject: [uf-discuss] rel Link browser extention
Message-ID: <65b4e01f0512091437j7dd8a9efg1f7a996f67cad4f4@mail.gmail.com>

There was discussion of a navigation tool bar like the one in Opera
for quick access to links in the rel="home" discussion. I since I
couldn't find any existing extensions, I was thinking about making
one, so I did.

http://www.heatonarts.com/extensions/rellink/rellink.xpi

It's a tool bar modeled after the one in Opera, but it also has a link
for rel-license and a "Tags" button that opens a sidebar which
displays all the rel-tag links on the page. I plan on adding more
microformats related to the rel attribute including a sidebar for XFN.

If something like this is already out there let me know so I don't
duplicate someone else work. Check it out if your interested and let
me know any suggestions or bugs, but be nice, it's my first extension.
(works in Flock too). I'll get a page up later with more info and what
else I plan for it later.

Kenny
From benjamincarlyle at optusnet.com.au  Sat Dec 10 05:27:24 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Sat Dec 10 05:27:15 2005
Subject: [uf-discuss] rel-tag for hierarchical and general categories
In-Reply-To: <op.s07bqorbares2h@mail.solitude.dk>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>
	<op.s07bqorbares2h@mail.solitude.dk>
Message-ID: <1134221246.5660.24.camel@tori>

On Sat, 2005-12-03 at 10:38 +0100, Andreas Haugstrup wrote:
> On Sat, 03 Dec 2005 08:03:06 +0100, Scott Reynen <scott@randomchaos.com>  
> wrote:
> > Note that dot ('.') makes a decent hierarchy marker with no required  
> > change for flat tag systems.  Foxilicious [1] uses dot as a default  
> > delimiter for converting from the (mostly) flat tag space at del.icio.us  
> > to the hierarchy of Firefox's bookmarks.  So you could do:
> > <a
> > href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ 
> > software.httpsubscription">software/httpsubscription</a>
> > Some parsers will still treat that as a single tag, but others will  
> > treat it as a hierarchy, and even in those systems treating it as a  
> > single tag, I think "software.httpsubscription" suggests a hierarchy to  
> > many humans.
> It won't be cool for those people who use system that don't see the  
> hierarchy. Why not use two links:
> <a  
> href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/software">software</a>/<a  
> href="http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/software/httpsubscription">httpsubscription</a>

The reason I don't use two tags is primarily techinical. I'm using
bloxsom for my blogging needs and I get a simple $path varible to work
with. I can't get any further without hacking perl, and that's probably
too high a hurdle for me to jump this weekend.

The hierarchical approach is interesting. Bloxsom starts with a
directory structure populated with *.txt files in order to render its
pages. I could rename my software/httpsubscription directory to
software.httpsubscription, but this would disrupt the hierarchical
categories list in my nav panel. More perl hacking to fix. I guess the
right answer for this approach would be to keep the directory structure
as-is, and give myself another variable to work with. That actually
wouldn't be too much perl hacking.

This leads me to my final(?) issue with this microformat. I currently
categorise all of my posts at the same level, so alongside
software/httpsubscription I have software/general. Obviously this latter
entry should be tagged as software, and removing the general directory
level would solve the tagging problem. This however also produces a
technical issue for me. If I remove that directory level my categories
navigation list would hide these general entries (and the count of them)
at the "software" level. The general entries would not get equal showing
as there would be nowhere to have a look at them separately. I think
this would require extensive perl hacking to fix. Could this problem be
resolved in the microformat?

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
(who feels some perl hacking may be inevitable...)

From tantek at cs.stanford.edu  Sat Dec 10 08:51:34 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Dec 10 08:52:00 2005
Subject: extensive perl hacking vs. changing a microformat (was Re:
	[uf-discuss] rel-tag for hierarchical and general categories)
In-Reply-To: <1134221246.5660.24.camel@tori>
Message-ID: <BFC04757.64D55%tantek@cs.stanford.edu>

On 12/10/05 5:27 AM, "Benjamin Carlyle" <benjamincarlyle@optusnet.com.au>
wrote:

> I think
> this would require extensive perl hacking to fix. Could this problem be
> resolved in the microformat?

Hi Ben,

There is a general rule to follow in software design and data formats which
is very important.

If it is a question of hacking a particular implementation to work, or
changing a data format to work around a particular implementation's
limitations, the answer is, you always hack the implementation, not the data
format.

Data outlives code 10-100 fold.  People's data is what they care about.
Applications come and go and people move their data around.

It is much more important to have a properly design data format for data
integrity, portability, longevity etc. than to morph it just to work with an
ephemeral implementation or two.

Thanks,

Tantek

From davidjanes at blogmatrix.com  Sat Dec 10 12:51:17 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sat Dec 10 12:51:20 2005
Subject: [uf-discuss] Call for Victims: Template Rewriter
Message-ID: <439B3FC5.4020505@blogmatrix.com>

I'm looking for Blogger, MovableType or TypePad bloggers to test my 
hAtom Template Rewriter tool. This is a web page that you input your 
existing script and out pops a rewritten script with all the appropriate 
hAtom css class/rel information added.

Also, if you're using a different blogging platform and you'd like me to 
try to write a Rewriter for that, please send me a note (and a copy of 
your templates as attachment, if possible)

Regards, etc...
David
http://www.blogmatrix.com

From kmarks at technorati.com  Sat Dec 10 14:08:51 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Sat Dec 10 14:08:54 2005
Subject: [uf-discuss] Call for Victims: Template Rewriter
In-Reply-To: <439B3FC5.4020505@blogmatrix.com>
References: <439B3FC5.4020505@blogmatrix.com>
Message-ID: <31c47a3d9c0f65be2e601a1229032bc7@technorati.com>

Sure, let me know how.
On Dec 10, 2005, at 12:51 PM, David Janes -- BlogMatrix wrote:

> I'm looking for Blogger, MovableType or TypePad bloggers to test my 
> hAtom Template Rewriter tool. This is a web page that you input your 
> existing script and out pops a rewritten script with all the 
> appropriate hAtom css class/rel information added.
>
> Also, if you're using a different blogging platform and you'd like me 
> to try to write a Rewriter for that, please send me a note (and a copy 
> of your templates as attachment, if possible)
>
> Regards, etc...
> David
> http://www.blogmatrix.com
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From jeff at parnasse.com  Mon Dec 12 05:59:36 2005
From: jeff at parnasse.com (Jeff Harrington)
Date: Mon Dec 12 05:59:44 2005
Subject: [uf-discuss] How to Announce the Availability of New Media Content
	with uf? 
In-Reply-To: <1134221246.5660.24.camel@tori>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>
	<1134221246.5660.24.camel@tori>
Message-ID: <439D8248.7040206@parnasse.com>

I've been thinking and researching for a solution to a problem 
independent artists have on the web.  Because of the loss of the MP3.COM 
community, and the diaspora of OMD's online musicians have been 
dispersed and now find themselve unable to easily 'announce' their new 
works to other music creators and consumers. 

I've proposed at my blog, htttp://beepsnort.org a use of del.iciou.us 
tags to help in this process - (A Proposal for Announcing New Music 
Recordings on the Nethttp://beepsnort.org/archives/000402.html) but now 
I'm beginning to think that microformats might be needed in order to 
additionally create a discovery phase of this announcement process.  
Also, my use of the example, mp3_classical_contemporary tag, would 
probably eventually lead to an over-abundance of announcements and 
pseudo-announcements as the community began using it.  (Admittedly its a 
hack approach but does auto-generate podcasts hehe). 

Is there an implicit announcement mechanism built in already that I'm 
missing?  Any research projects about how to 'announce'?  I'm looking 
for practical solutions for the thousands of online musicians. 

I'm thinking at the moment of tying in my del.icio.us tag announcement 
with a discovery mechanism through uf's.  If I trigger the discovery by 
an email list I think only spam will result. 

Any ideas or suggestions?

Jeff
http://jeffharrington.org


From drernie at opendarwin.org  Mon Dec 12 07:17:10 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Mon Dec 12 07:17:14 2005
Subject: [uf-discuss] How to Announce the Availability of New Media
	Content with uf? 
In-Reply-To: <439D8248.7040206@parnasse.com>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>
	<1134221246.5660.24.camel@tori> <439D8248.7040206@parnasse.com>
Message-ID: <310DB254-EEB5-4EDF-9D2A-4FF14208CFFB@opendarwin.org>

Hi Jeff,

I'm not sure exactly what problem you're trying to solve, but it  
sounds like what you really want is a "ping server" (or a few) that  
people can, well, "ping" to announce availability of new content.    
There's scalability issues, but as far as I can tell that's the only  
way to generate any sort of meaningful "announce" postings.

-- Ernie P.

On Dec 12, 2005, at 5:59 AM, Jeff Harrington wrote:

> I've been thinking and researching for a solution to a problem  
> independent artists have on the web.  Because of the loss of the  
> MP3.COM community, and the diaspora of OMD's online musicians have  
> been dispersed and now find themselve unable to easily 'announce'  
> their new works to other music creators and consumers.
> I've proposed at my blog, htttp://beepsnort.org a use of  
> del.iciou.us tags to help in this process - (A Proposal for  
> Announcing New Music Recordings on the Nethttp://beepsnort.org/ 
> archives/000402.html) but now I'm beginning to think that  
> microformats might be needed in order to additionally create a  
> discovery phase of this announcement process.  Also, my use of the  
> example, mp3_classical_contemporary tag, would probably eventually  
> lead to an over-abundance of announcements and pseudo-announcements  
> as the community began using it.  (Admittedly its a hack approach  
> but does auto-generate podcasts hehe).
> Is there an implicit announcement mechanism built in already that  
> I'm missing?  Any research projects about how to 'announce'?  I'm  
> looking for practical solutions for the thousands of online musicians.
> I'm thinking at the moment of tying in my del.icio.us tag  
> announcement with a discovery mechanism through uf's.  If I trigger  
> the discovery by an email list I think only spam will result.
> Any ideas or suggestions?
>
> Jeff
> http://jeffharrington.org
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From davidjanes at blogmatrix.com  Mon Dec 12 07:22:00 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Mon Dec 12 07:22:03 2005
Subject: [uf-discuss] Call for Victims (II)
In-Reply-To: <439B3FC5.4020505@blogmatrix.com>
References: <439B3FC5.4020505@blogmatrix.com>
Message-ID: <439D9598.1050602@blogmatrix.com>

The hAtom Template Rewriter now supports WordPress (as well as 
MovableType and Blogger). If you have a WordPress blog and would like to 
support the hAtom microformat, please send me a note and I'll set you up

Regards, etc...
David
http://www.blogmatrix.com

From jeff at parnasse.com  Mon Dec 12 07:37:03 2005
From: jeff at parnasse.com (Jeff Harrington)
Date: Mon Dec 12 07:36:32 2005
Subject: [uf-discuss] How to Announce the Availability of New Media	Content
	with uf?
In-Reply-To: <310DB254-EEB5-4EDF-9D2A-4FF14208CFFB@opendarwin.org>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>	<1134221246.5660.24.camel@tori>
	<439D8248.7040206@parnasse.com>
	<310DB254-EEB5-4EDF-9D2A-4FF14208CFFB@opendarwin.org>
Message-ID: <439D991F.9030504@parnasse.com>

A ping server... yeah that's what the del.icio.us works as in my proposal. 

The problem I'm trying to solve is that currently online musicians have 
to post, at umpteen online forums, announcements that a new song or 
album is available.  And even then it gets missed by the majority of 
other musicians.  It probably doesn't make sense, unless you 
participated in the forums at MP3.COM where every new song was met with 
eager anticipation, comments, suggestions, etc... and listeners.  By 
creating a global music genre-specific RSS feed and some type of 
discovery mechanism with uf's (or not) I was hoping to aggregate these 
helpfully without creating new community. 

Could you give me examples of functioning ping servers and the 
community/purposes they serve?

Jeff
http://jeffharrington.org

Dr. Ernie Prabhakar wrote:

> Hi Jeff,
>
> I'm not sure exactly what problem you're trying to solve, but it  
> sounds like what you really want is a "ping server" (or a few) that  
> people can, well, "ping" to announce availability of new content.    
> There's scalability issues, but as far as I can tell that's the only  
> way to generate any sort of meaningful "announce" postings.
>
> -- Ernie P.
>
> On Dec 12, 2005, at 5:59 AM, Jeff Harrington wrote:
>
>> I've been thinking and researching for a solution to a problem  
>> independent artists have on the web.  Because of the loss of the  
>> MP3.COM community, and the diaspora of OMD's online musicians have  
>> been dispersed and now find themselve unable to easily 'announce'  
>> their new works to other music creators and consumers.
>> I've proposed at my blog, htttp://beepsnort.org a use of  
>> del.iciou.us tags to help in this process - (A Proposal for  
>> Announcing New Music Recordings on the Nethttp://beepsnort.org/ 
>> archives/000402.html) but now I'm beginning to think that  
>> microformats might be needed in order to additionally create a  
>> discovery phase of this announcement process.  Also, my use of the  
>> example, mp3_classical_contemporary tag, would probably eventually  
>> lead to an over-abundance of announcements and pseudo-announcements  
>> as the community began using it.  (Admittedly its a hack approach  
>> but does auto-generate podcasts hehe).
>> Is there an implicit announcement mechanism built in already that  
>> I'm missing?  Any research projects about how to 'announce'?  I'm  
>> looking for practical solutions for the thousands of online musicians.
>> I'm thinking at the moment of tying in my del.icio.us tag  
>> announcement with a discovery mechanism through uf's.  If I trigger  
>> the discovery by an email list I think only spam will result.
>> Any ideas or suggestions?
>>
>> Jeff
>> http://jeffharrington.org
>>
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From teohuiming.work at gmail.com  Mon Dec 12 07:43:47 2005
From: teohuiming.work at gmail.com (toydi)
Date: Mon Dec 12 07:43:48 2005
Subject: [uf-discuss] How to Announce the Availability of New Media
	Content with uf?
In-Reply-To: <439D8248.7040206@parnasse.com>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>
	<op.s07bqorbares2h@mail.solitude.dk> <1134221246.5660.24.camel@tori>
	<439D8248.7040206@parnasse.com>
Message-ID: <73ec599d0512120743q1440bd7yd6cf50b0ab5611e4@mail.gmail.com>

Hi Jeff,

On 12/12/05, Jeff Harrington <jeff@parnasse.com> wrote:
> I've proposed at my blog, htttp://beepsnort.org a use of del.iciou.us
> tags to help in this process - (A Proposal for Announcing New Music
> Recordings on the Net http://beepsnort.org/archives/000402.html)

Inspiring way to make use of delicious. ;-) About the "notes", AFAIK,
del.iciou.us let users to add "notes" to the bookmark. In your case,
the first bookmark creator (should be the mp3 owner) can supply
his/her notes, and the following users' notes can be consider as
comments.

>
> Is there an implicit announcement mechanism built in already that I'm
> missing?  Any research projects about how to 'announce'?  I'm looking
> for practical solutions for the thousands of online musicians.

iTunes RSS Spec. [1] Any reason you need a microformat to announce the
new songs? RSS/ATOM syndication & aggregation has created an almost
complete ecosystem for announcement purpose.

Besides "announce to discover", is it possible to use Microformat Base
or Google Base to make submission and provide "search to discover"?

[1] http://phobos.apple.com/static/iTunesRSS.html


> I'm thinking at the moment of tying in my del.icio.us tag announcement
> with a discovery mechanism through uf's.

An example about the "discovery mechanism through uf's" ?


Cheers,
--
Teo HuiMing (toydi)
http://toydi.wordpress.com
From jeff at parnasse.com  Mon Dec 12 08:05:41 2005
From: jeff at parnasse.com (Jeff Harrington)
Date: Mon Dec 12 08:05:11 2005
Subject: [uf-discuss] How to Announce the Availability of New Media	Content
	with uf?
In-Reply-To: <73ec599d0512120743q1440bd7yd6cf50b0ab5611e4@mail.gmail.com>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>
	<1134221246.5660.24.camel@tori>	<439D8248.7040206@parnasse.com>
	<73ec599d0512120743q1440bd7yd6cf50b0ab5611e4@mail.gmail.com>
Message-ID: <439D9FD5.1040101@parnasse.com>

toydi wrote:

>Hi Jeff,
>
>On 12/12/05, Jeff Harrington <jeff@parnasse.com> wrote:
>  
>
>>I've proposed at my blog, htttp://beepsnort.org a use of del.iciou.us
>>tags to help in this process - (A Proposal for Announcing New Music
>>Recordings on the Net http://beepsnort.org/archives/000402.html)
>>    
>>
>
>Inspiring way to make use of delicious. ;-) About the "notes", AFAIK,
>del.iciou.us let users to add "notes" to the bookmark. In your case,
>the first bookmark creator (should be the mp3 owner) can supply
>his/her notes, and the following users' notes can be consider as
>comments.
>
>  
>
Thanks toydi.  Does del.icio.us maintain order as other bookmarks are 
created.  I guess they do...

>>Is there an implicit announcement mechanism built in already that I'm
>>missing?  Any research projects about how to 'announce'?  I'm looking
>>for practical solutions for the thousands of online musicians.
>>    
>>
>
>iTunes RSS Spec. [1] Any reason you need a microformat to announce the
>new songs? RSS/ATOM syndication & aggregation has created an almost
>complete ecosystem for announcement purpose.
>
>Besides "announce to discover", is it possible to use Microformat Base
>or Google Base to make submission and provide "search to discover"?
>
>[1] http://phobos.apple.com/static/iTunesRSS.html
>  
>

I would probably use the XSPF format instead of the proprietary iTunes. 

>
>  
>
>>I'm thinking at the moment of tying in my del.icio.us tag announcement
>>with a discovery mechanism through uf's.
>>    
>>
>
>An example about the "discovery mechanism through uf's" ?
>
>  
>
My initial idea was that the announce would provoke a secondary fetch 
where graphics and album
art, album notes, etc could be appended by any site that knew how.  So 
anybody subscribing to the
feed would have an implied discovery methodology for enhancements using 
uf pointers. 

Jeff
http://jeffharrington.org

From jeff at parnasse.com  Mon Dec 12 08:19:58 2005
From: jeff at parnasse.com (Jeff Harrington)
Date: Mon Dec 12 08:19:27 2005
Subject: [uf-discuss] How to Announce the Availability of New Media	Content
	with uf?
In-Reply-To: <439D991F.9030504@parnasse.com>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>	<1134221246.5660.24.camel@tori>	<439D8248.7040206@parnasse.com>	<310DB254-EEB5-4EDF-9D2A-4FF14208CFFB@opendarwin.org>
	<439D991F.9030504@parnasse.com>
Message-ID: <439DA32E.9060106@parnasse.com>

Duh... like a blog ping server.  Right!

Jeff

Jeff Harrington wrote:

> Could you give me examples of functioning ping servers and the 
> community/purposes they serve?
>
> Jeff
> http://jeffharrington.org
>
> Dr. Ernie Prabhakar wrote:
>
>> Hi Jeff,
>>
>> I'm not sure exactly what problem you're trying to solve, but it  
>> sounds like what you really want is a "ping server" (or a few) that  
>> people can, well, "ping" to announce availability of new content.    
>> There's scalability issues, but as far as I can tell that's the only  
>> way to generate any sort of meaningful "announce" postings.
>>
>> -- Ernie P.
>>
>> On Dec 12, 2005, at 5:59 AM, Jeff Harrington wrote:
>>
>>> I've been thinking and researching for a solution to a problem  
>>> independent artists have on the web.  Because of the loss of the  
>>> MP3.COM community, and the diaspora of OMD's online musicians have  
>>> been dispersed and now find themselve unable to easily 'announce'  
>>> their new works to other music creators and consumers.
>>> I've proposed at my blog, htttp://beepsnort.org a use of  
>>> del.iciou.us tags to help in this process - (A Proposal for  
>>> Announcing New Music Recordings on the Nethttp://beepsnort.org/ 
>>> archives/000402.html) but now I'm beginning to think that  
>>> microformats might be needed in order to additionally create a  
>>> discovery phase of this announcement process.  Also, my use of the  
>>> example, mp3_classical_contemporary tag, would probably eventually  
>>> lead to an over-abundance of announcements and pseudo-announcements  
>>> as the community began using it.  (Admittedly its a hack approach  
>>> but does auto-generate podcasts hehe).
>>> Is there an implicit announcement mechanism built in already that  
>>> I'm missing?  Any research projects about how to 'announce'?  I'm  
>>> looking for practical solutions for the thousands of online musicians.
>>> I'm thinking at the moment of tying in my del.icio.us tag  
>>> announcement with a discovery mechanism through uf's.  If I trigger  
>>> the discovery by an email list I think only spam will result.
>>> Any ideas or suggestions?
>>>
>>> Jeff
>>> http://jeffharrington.org
>>>
>>>
>>> _______________________________________________
>>> microformats-discuss mailing list
>>> microformats-discuss@microformats.org
>>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>>
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From chudley at gmail.com  Mon Dec 12 08:23:47 2005
From: chudley at gmail.com (C. Hudley)
Date: Mon Dec 12 08:23:50 2005
Subject: [uf-discuss] Ics import in Outlook
In-Reply-To: <ee0909a60512091403r567ba4fex5693bae34dba353c@mail.gmail.com>
References: <EF6631296121CF4390E090D9B4EFD0690156851C@cru80.cahe.ad.wsu.edu>
	<4399E1B3.6080203@gmail.com>
	<ee0909a60512091403r567ba4fex5693bae34dba353c@mail.gmail.com>
Message-ID: <e28976dd0512120823m3bec4ca1m1512c79f81307f63@mail.gmail.com>

On 12/9/05, David Osolkowski <qidydl@gmail.com> wrote:
>
> The tag: URI scheme[1] provides a fairly effective way to generate unique
> ID's.  I believe it is the recommended way to generate GUIDs for Atom[2].
> Thus, it seems likely it could be re-used here.
>
> [1] http://www.taguri.org/

Has the tag URI scheme been registered successfully?  I don't see an
update on its status on that page.

If not, the info URI scheme (as was mentioned here recently), with the
"sid" namespace, could be used the same way, and it has been
registered.

http://info-uri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg&identifier=info:sid/

Fyi.  -ch.
From qidydl at gmail.com  Mon Dec 12 08:45:49 2005
From: qidydl at gmail.com (David Osolkowski)
Date: Mon Dec 12 08:45:51 2005
Subject: [uf-discuss] Ics import in Outlook
In-Reply-To: <e28976dd0512120823m3bec4ca1m1512c79f81307f63@mail.gmail.com>
References: <EF6631296121CF4390E090D9B4EFD0690156851C@cru80.cahe.ad.wsu.edu>
	<4399E1B3.6080203@gmail.com>
	<ee0909a60512091403r567ba4fex5693bae34dba353c@mail.gmail.com>
	<e28976dd0512120823m3bec4ca1m1512c79f81307f63@mail.gmail.com>
Message-ID: <ee0909a60512120845x5e816ce6n918243f68b68f3dc@mail.gmail.com>

On 12/12/05, C. Hudley <chudley@gmail.com> wrote:
>
> On 12/9/05, David Osolkowski <qidydl@gmail.com> wrote:
> >
> > The tag: URI scheme[1] provides a fairly effective way to generate
> unique
> > ID's.  I believe it is the recommended way to generate GUIDs for
> Atom[2].
> > Thus, it seems likely it could be re-used here.
> >
> > [1] http://www.taguri.org/
>
> Has the tag URI scheme been registered successfully?  I don't see an
> update on its status on that page.
>
> If not, the info URI scheme (as was mentioned here recently), with the
> "sid" namespace, could be used the same way, and it has been
> registered.
>
>
> http://info-uri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg&identifier=info:sid/


The tag scheme is RFC 4151: http://ietf.org/rfc/rfc4151

The sid namespace appears to be for identifying collections of information
("The sid namespace facilitates the identification of collections of
information assets. A collection of information assets could be an
organization, a website, a publisher, or a database.").  The point here is
to identify a specific event.  The tag scheme is similarly used to identify
specific entries, as opposed to collections.  I suggest that tag is a better
match than sid ("more semantic", just to tie this back to microformats).

- David Osolkowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051212/90d86ecc/attachment.htm
From chudley at gmail.com  Mon Dec 12 09:37:11 2005
From: chudley at gmail.com (C. Hudley)
Date: Mon Dec 12 09:37:14 2005
Subject: [uf-discuss] Ics import in Outlook
In-Reply-To: <ee0909a60512120845x5e816ce6n918243f68b68f3dc@mail.gmail.com>
References: <EF6631296121CF4390E090D9B4EFD0690156851C@cru80.cahe.ad.wsu.edu>
	<4399E1B3.6080203@gmail.com>
	<ee0909a60512091403r567ba4fex5693bae34dba353c@mail.gmail.com>
	<e28976dd0512120823m3bec4ca1m1512c79f81307f63@mail.gmail.com>
	<ee0909a60512120845x5e816ce6n918243f68b68f3dc@mail.gmail.com>
Message-ID: <e28976dd0512120937l33088ee1o788efd872a22cee4@mail.gmail.com>

On 12/12/05, David Osolkowski <qidydl@gmail.com> wrote:
> >
> > Has the tag URI scheme been registered successfully?  I don't see an
> > update on its status on that page.
> >
> > If not, the info URI scheme (as was mentioned here recently), with the
> > "sid" namespace, could be used the same way, and it has been
> > registered.
>
> The tag scheme is RFC 4151: http://ietf.org/rfc/rfc4151

Yes, that is its scheme.  But I didn't see if that indicates whether
it has been registered formally.  Ah, this is what I was looking for:

  http://www.iana.org/assignments/uri-schemes

So, yes, it is registered.  Apparently, just before info was. :)


>  The sid namespace appears to be for identifying collections of information
> ("The sid namespace facilitates the identification of collections of
> information assets. A collection of information assets could be an
> organization, a website, a publisher, or a database.").  The point here is
> to identify a specific event.  The tag scheme is similarly used to identify
> specific entries, as opposed to collections.  I suggest that tag is a better
> match than sid ("more semantic", just to tie this back to microformats).

Aye, perhaps I misunderstood it then; I'd thought a valid use might
include its specified pattern *plus* an additional item content
identification suffix.  I'll check with the appropriate folks. 
Thanks!
From chris.messina at gmail.com  Mon Dec 12 10:55:01 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Mon Dec 12 10:55:03 2005
Subject: [uf-discuss] How to Announce the Availability of New Media
	Content with uf?
In-Reply-To: <439DA32E.9060106@parnasse.com>
References: <1133588297.5439.93.camel@tori>
	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>
	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>
	<op.s07bqorbares2h@mail.solitude.dk> <1134221246.5660.24.camel@tori>
	<439D8248.7040206@parnasse.com>
	<310DB254-EEB5-4EDF-9D2A-4FF14208CFFB@opendarwin.org>
	<439D991F.9030504@parnasse.com> <439DA32E.9060106@parnasse.com>
Message-ID: <1bc4603e0512121055p57e12df8gf3068a52efd26c80@mail.gmail.com>

Yeah, but here's what would be better than a ping server... a ping spider....

So here's what I want. I want net radio, in the real sense.

I want to tell my browser "give me 'rock, alt-rock, artist:disturbed,
artist:elliot smith, like:eminem' and add it to a smart collection
which will then go out across the web and anytime it finds a XOXO
playlist matching this criteria adds it to an ad hoc playlist... And
when I choose to "play" this collection, it just streams the files
from the respective servers.

Pipe dream? Nah. We'll get there.

But in terms of discovering new music that matches these smart
collection prefs, microformats + indie publishing + a ping spider that
works p2p betweeen the independet sites is what we need.

Imagine the web is your jukebox. Websites are compilation albums.
Microformats provide the track listing and resource location. MP3/OGG
store the music. Your browser is your audio player.  Distributed
broadcasting that can't be shut down. The FCC just shit a brick.

And this works for podcasting/vidcasting too.The web as TV
replacement? Hells yes, on my terms.

Chris

On 12/12/05, Jeff Harrington <jeff@parnasse.com> wrote:
> Duh... like a blog ping server.  Right!
>
> Jeff
>
> Jeff Harrington wrote:
>
> > Could you give me examples of functioning ping servers and the
> > community/purposes they serve?
> >
> > Jeff
> > http://jeffharrington.org
> >
> > Dr. Ernie Prabhakar wrote:
> >
> >> Hi Jeff,
> >>
> >> I'm not sure exactly what problem you're trying to solve, but it
> >> sounds like what you really want is a "ping server" (or a few) that
> >> people can, well, "ping" to announce availability of new content.
> >> There's scalability issues, but as far as I can tell that's the only
> >> way to generate any sort of meaningful "announce" postings.
> >>
> >> -- Ernie P.
> >>
> >> On Dec 12, 2005, at 5:59 AM, Jeff Harrington wrote:
> >>
> >>> I've been thinking and researching for a solution to a problem
> >>> independent artists have on the web.  Because of the loss of the
> >>> MP3.COM community, and the diaspora of OMD's online musicians have
> >>> been dispersed and now find themselve unable to easily 'announce'
> >>> their new works to other music creators and consumers.
> >>> I've proposed at my blog, htttp://beepsnort.org a use of
> >>> del.iciou.us tags to help in this process - (A Proposal for
> >>> Announcing New Music Recordings on the Nethttp://beepsnort.org/
> >>> archives/000402.html) but now I'm beginning to think that
> >>> microformats might be needed in order to additionally create a
> >>> discovery phase of this announcement process.  Also, my use of the
> >>> example, mp3_classical_contemporary tag, would probably eventually
> >>> lead to an over-abundance of announcements and pseudo-announcements
> >>> as the community began using it.  (Admittedly its a hack approach
> >>> but does auto-generate podcasts hehe).
> >>> Is there an implicit announcement mechanism built in already that
> >>> I'm missing?  Any research projects about how to 'announce'?  I'm
> >>> looking for practical solutions for the thousands of online musicians.
> >>> I'm thinking at the moment of tying in my del.icio.us tag
> >>> announcement with a discovery mechanism through uf's.  If I trigger
> >>> the discovery by an email list I think only spam will result.
> >>> Any ideas or suggestions?
> >>>
> >>> Jeff
> >>> http://jeffharrington.org
> >>>
> >>>
> >>> _______________________________________________
> >>> microformats-discuss mailing list
> >>> microformats-discuss@microformats.org
> >>> http://microformats.org/mailman/listinfo/microformats-discuss
> >>
> >>
> >>
> >> _______________________________________________
> >> microformats-discuss mailing list
> >> microformats-discuss@microformats.org
> >> http://microformats.org/mailman/listinfo/microformats-discuss
> >>
> >>
> >
> > _______________________________________________
> > microformats-discuss mailing list
> > microformats-discuss@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-discuss
> >
> >
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
From chris.messina at gmail.com  Mon Dec 12 11:15:59 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Mon Dec 12 11:16:02 2005
Subject: [uf-discuss] Call for Victims (II)
In-Reply-To: <439D9598.1050602@blogmatrix.com>
References: <439B3FC5.4020505@blogmatrix.com> <439D9598.1050602@blogmatrix.com>
Message-ID: <1bc4603e0512121115w49dea691o2c41381ad7ba8f6f@mail.gmail.com>

Would be great to get this into K2: http://binarybonsai.com/k2/

On 12/12/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
> The hAtom Template Rewriter now supports WordPress (as well as
> MovableType and Blogger). If you have a WordPress blog and would like to
> support the hAtom microformat, please send me a note and I'll set you up
>
> Regards, etc...
> David
> http://www.blogmatrix.com
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
From stevej at pobox.com  Mon Dec 12 17:54:06 2005
From: stevej at pobox.com (Steve Jenson)
Date: Mon Dec 12 17:54:08 2005
Subject: [uf-discuss] Call for Victims: Template Rewriter
In-Reply-To: <439B3FC5.4020505@blogmatrix.com>
References: <439B3FC5.4020505@blogmatrix.com>
Message-ID: <81d74c280512121754l286a9f6fnfe13b8cc3a5d79ff@mail.gmail.com>

I'd be willing to help. I have a Blogger blog.

Steve

On 12/10/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
> I'm looking for Blogger, MovableType or TypePad bloggers to test my
> hAtom Template Rewriter tool. This is a web page that you input your
> existing script and out pops a rewritten script with all the appropriate
> hAtom css class/rel information added.
>
> Also, if you're using a different blogging platform and you'd like me to
> try to write a Rewriter for that, please send me a note (and a copy of
> your templates as attachment, if possible)
>
> Regards, etc...
> David
> http://www.blogmatrix.com
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
From davidjanes at blogmatrix.com  Mon Dec 12 18:18:32 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Mon Dec 12 18:18:56 2005
Subject: [uf-discuss] Call for Victims: Template Rewriter
In-Reply-To: <81d74c280512121754l286a9f6fnfe13b8cc3a5d79ff@mail.gmail.com>
References: <439B3FC5.4020505@blogmatrix.com>
	<81d74c280512121754l286a9f6fnfe13b8cc3a5d79ff@mail.gmail.com>
Message-ID: <439E2F78.4080407@blogmatrix.com>

Hi Steve,

(1)
If you're running Mozilla, Greasemonkey and all that, install:
http://www.blogmatrix.com/tools/greasemonkey/microformat-action.user.js
to identify MF content

(2)
The template rewriter:
http://www.blogmatrix.com/tools/rewrite/

(3)
I can't stress enough making a backup of your existing template(s)

(4)
The URIs above redirect to "trinityanne.com" -- this is a temporary thing.

Please let me know how it works!

Regards, etc.

Steve Jenson wrote:
> I'd be willing to help. I have a Blogger blog.
>
> Steve
>
> On 12/10/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
>   
>> I'm looking for Blogger, MovableType or TypePad bloggers to test my
>> hAtom Template Rewriter tool. This is a web page that you input your
>> existing script and out pops a rewritten script with all the appropriate
>> hAtom css class/rel information added.
>>
>> Also, if you're using a different blogging platform and you'd like me to
>> try to write a Rewriter for that, please send me a note (and a copy of
>> your templates as attachment, if possible)
>>
>> Regards, etc...
>> David
>> http://www.blogmatrix.com
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>>
>>     
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>   

From ryan at technorati.com  Mon Dec 12 22:45:47 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Dec 12 22:45:48 2005
Subject: [uf-discuss] How to Announce the Availability of New Media
	Content with uf? 
In-Reply-To: <439D8248.7040206@parnasse.com>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>
	<1134221246.5660.24.camel@tori> <439D8248.7040206@parnasse.com>
Message-ID: <B472FD05-C9B0-45E4-8DA3-FD31EE011BDE@technorati.com>

On Dec 12, 2005, at 5:59 AM, Jeff Harrington wrote:

> I've been thinking and researching for a solution to a problem  
> independent artists have on the web.  Because of the loss of the  
> MP3.COM community, and the diaspora of OMD's online musicians have  
> been dispersed and now find themselve unable to easily 'announce'  
> their new works to other music creators and consumers.
> I've proposed at my blog, htttp://beepsnort.org a use of  
> del.iciou.us tags to help in this process - (A Proposal for  
> Announcing New Music Recordings on the Nethttp://beepsnort.org/ 
> archives/000402.html) but now I'm beginning to think that  
> microformats might be needed in order to additionally create a  
> discovery phase of this announcement process.  Also, my use of the  
> example, mp3_classical_contemporary tag, would probably eventually  
> lead to an over-abundance of announcements and pseudo-announcements  
> as the community began using it.  (Admittedly its a hack approach  
> but does auto-generate podcasts hehe).
> Is there an implicit announcement mechanism built in already that  
> I'm missing?

Weblog.com style ping servers would be an example of technology that  
does notification. But I have a feeling you are concerned with  
technical notification, but with a more human type of notification.  
As is, I don't think there's a web-wide way to do this, you still  
gotta pound the pavement.

Also, as I'm sure you know, ?f's are modeled after existing user  
behavior. So it might be worthwhile to see what artists are already  
doing to promote themselves and start there.

> Any research projects about how to 'announce'?  I'm looking for  
> practical solutions for the thousands of online musicians.
> I'm thinking at the moment of tying in my del.icio.us tag  
> announcement with a discovery mechanism through uf's.  If I trigger  
> the discovery by an email list I think only spam will result.
> Any ideas or suggestions?

-ryan

--
Ryan King
ryan@technorati.com



From jeff at parnasse.com  Tue Dec 13 05:52:37 2005
From: jeff at parnasse.com (Jeff Harrington)
Date: Tue Dec 13 05:52:06 2005
Subject: [uf-discuss] How to Announce the Availability of New Media	Content
	with uf?
In-Reply-To: <B472FD05-C9B0-45E4-8DA3-FD31EE011BDE@technorati.com>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>	<1134221246.5660.24.camel@tori>
	<439D8248.7040206@parnasse.com>
	<B472FD05-C9B0-45E4-8DA3-FD31EE011BDE@technorati.com>
Message-ID: <439ED225.7080009@parnasse.com>

Ryan King wrote:

> On Dec 12, 2005, at 5:59 AM, Jeff Harrington wrote:
>
>> I've been thinking and researching for a solution to a problem  
>> independent artists have on the web.  Because of the loss of the  
>> MP3.COM community, and the diaspora of OMD's online musicians have  
>> been dispersed and now find themselve unable to easily 'announce'  
>> their new works to other music creators and consumers.
>> I've proposed at my blog, htttp://beepsnort.org a use of  
>> del.iciou.us tags to help in this process - (A Proposal for  
>> Announcing New Music Recordings on the Nethttp://beepsnort.org/ 
>> archives/000402.html) but now I'm beginning to think that  
>> microformats might be needed in order to additionally create a  
>> discovery phase of this announcement process.  Also, my use of the  
>> example, mp3_classical_contemporary tag, would probably eventually  
>> lead to an over-abundance of announcements and pseudo-announcements  
>> as the community began using it.  (Admittedly its a hack approach  
>> but does auto-generate podcasts hehe).
>> Is there an implicit announcement mechanism built in already that  
>> I'm missing?
>
>
> Weblog.com style ping servers would be an example of technology that  
> does notification. But I have a feeling you are concerned with  
> technical notification, but with a more human type of notification.  
> As is, I don't think there's a web-wide way to do this, you still  
> gotta pound the pavement.
>
Yeah, I'm learning about them now... should have one up shortly.  Great 
idea guys...

> Also, as I'm sure you know, ?f's are modeled after existing user  
> behavior. So it might be worthwhile to see what artists are already  
> doing to promote themselves and start there.
>
Well, since I invented this whole 'internet musician thing' ;)  I'll ask 
myself what I would do.  Heheh...

Jeff
http://jeffharrington.org

From pp at myelin.co.nz  Tue Dec 13 05:56:04 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Tue Dec 13 05:56:16 2005
Subject: [uf-discuss] Structured Blogging now supports microformats...
Message-ID: <439ED2F4.10007@myelin.co.nz>

Hey guys,

A quick heads-up... this evening in San Francisco, the new Structured 
Blogging plugins (for Wordpress and Movable Type) are going to be 
officially announced.

SB is changing quite a bit.  The key thing is that it now supports 
microformats!

v1.0pre8, which will be available on structuredblogging.org sometime 
this/Tuesday morning (Eastern time), currently outputs:

- hReview (for reviews)
- hCalendar (for events)
- hCard (for people / group showcases)
- XOXO (for lists)
- relLicense (for media)

We're also planning on putting these in over the next few days...

- XFN (for lists / blogrolls)
- relTag (all over the place)
- relHome (in the blog

Cheers,
Phil
From drernie at opendarwin.org  Tue Dec 13 08:31:33 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Tue Dec 13 08:31:37 2005
Subject: [uf-discuss] How to Announce the Availability of New
	Media	Content with uf?
In-Reply-To: <439ED225.7080009@parnasse.com>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>	<1134221246.5660.24.camel@tori>
	<439D8248.7040206@parnasse.com>
	<B472FD05-C9B0-45E4-8DA3-FD31EE011BDE@technorati.com>
	<439ED225.7080009@parnasse.com>
Message-ID: <CD500A37-C9AB-4047-BF58-16506B72643A@opendarwin.org>

Hi Jeff,

On Dec 13, 2005, at 5:52 AM, Jeff Harrington wrote:
>> Also, as I'm sure you know, ?f's are modeled after existing user   
>> behavior. So it might be worthwhile to see what artists are  
>> already  doing to promote themselves and start there.
>>
> Well, since I invented this whole 'internet musician thing' ;)   
> I'll ask myself what I would do.  Heheh...

Actually, you might want to check out MySpace, which I'm told is  
*the* place to find new music (and be found) for the younger set.   
The model they've evolved uses friendster-style mailing lists and  
easy forwarding to push information out into a community.  I strongly  
suspect something like this will become the dominant model in the  
future...

-- ERnie P.
  
From jeff at parnasse.com  Tue Dec 13 08:44:09 2005
From: jeff at parnasse.com (Jeff Harrington)
Date: Tue Dec 13 08:43:33 2005
Subject: [uf-discuss] How to Announce the Availability of New	Media	Content
	with uf?
In-Reply-To: <CD500A37-C9AB-4047-BF58-16506B72643A@opendarwin.org>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>	<1134221246.5660.24.camel@tori>	<439D8248.7040206@parnasse.com>	<B472FD05-C9B0-45E4-8DA3-FD31EE011BDE@technorati.com>	<439ED225.7080009@parnasse.com>
	<CD500A37-C9AB-4047-BF58-16506B72643A@opendarwin.org>
Message-ID: <439EFA59.6010305@parnasse.com>

Dr. Ernie Prabhakar wrote:

> Hi Jeff,
>
> On Dec 13, 2005, at 5:52 AM, Jeff Harrington wrote:
>
>>> Also, as I'm sure you know, ?f's are modeled after existing user   
>>> behavior. So it might be worthwhile to see what artists are  
>>> already  doing to promote themselves and start there.
>>>
>> Well, since I invented this whole 'internet musician thing' ;)   I'll 
>> ask myself what I would do.  Heheh...
>
>
> Actually, you might want to check out MySpace, which I'm told is  
> *the* place to find new music (and be found) for the younger set.   
> The model they've evolved uses friendster-style mailing lists and  
> easy forwarding to push information out into a community.  I strongly  
> suspect something like this will become the dominant model in the  
> future...

Not to be too off topic for too long, but coincidentally just got an 
email commenting on my music from a classical conductor to my MySpace 
account.  It's amazing how this contact would have been problematic, 
party or serendiptious dependant, if not for MySpace.  The big problem 
with the MySpace network re discovery of music is the limitation to 4 
'songs'.  For this reason it serves as nice bait, but is no replacement 
for a good musician site either independant or through an OMD. 

FWIW, looks like the XSPF format will be fine as the data source for an 
XML-RPC ping server for the announce.  Now just have to write set it up, 
and write a little front end to easily allow for submits (like the 
audio.weblogs.com podcast submit page).   XSPF has an implied discovery 
URL too, in the info tag.  I'm a little troubled by how the format has 
an implied multiplicity, but that's a good thing too for net albums. 

Thanks for all your comments; I hope to have something operational this 
weekend... 

Jeff
http://jeffharrington.org
From supercanadian at gmail.com  Tue Dec 13 11:03:46 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec 13 11:04:52 2005
Subject: [uf-discuss] Re: Show Microformat Brainstorming
In-Reply-To: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
Message-ID: <84ce626f0512131103x6c7baa0fw87acecf27ea2381a@mail.gmail.com>

Hello,

I've started a page for the "show brainstorming" on the wiki.  You can
get to it via:

    http://microformats.org/wiki/show-brainstorming



See ya

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> Thought I'd do some thinking out load about possibilities for a show
> microformat.
>
> What is a show?  Think TV show.  Although it doesn't have to be a TV show.
>
> First, listing some existing uses cases.  These are what I've seen
> people do already.  Note, I've made the example HTML very simple (so
> as not to clutter things).  Usually people use all sorts of extra
> markup to make things look nice.  But I don't include that here.)
>
> #1: Single clip with a preview image.  The clip is the full show.
>
>         <a href="clip.mpeg"><img src="preview.png" /></a>
>
> #2: Single clip with a preview image.  The clip is the teaser of the
> full show.  And there is a link that you can go to pay to see the full
> show.
>
>         <a href="teaser.mpeg"><img src="preview.png" /></a>
>
>         <a href="http://example.com/go">Pay to View</a>
>
> (The "Pay to View" link may or may not directly go to the "pay" page.
> And you may or may not have to pay for more than just this show to
> view it.)
>
> #3: A show divided up in multiple clips, each with a preview image.
> Together the clips make up the show.
>
>         <a href="clip-1.mpg"><img src="preview-1.png" /></a>
>
>         <a href="clip-2.mpg"><img src="preview-2.png" /></a>
>
>         <a href="clip-3.mpg"><img src="preview-3.png" /></a>
>
> (Note, there's a specific order here that matters.)
>
> #4: A set of teasers for a show.  Together they don't make up the full
> show.  And the may or may not overlap in time.  There's a "Pay to
> View" link there too.
>
>         <a href="clip-blue.mpg"><img src="preview-blue.png" /></a>
>
>         <a href="clip-red.mpg"><img src="preview-red.png" /></a>
>
>         <a href="clip-green.mpg"><img src="preview-green.png" /></a>
>
>
>         <a href="http://example.com/go">Pay to View</a>
>
> #5: A single clip that comes in different formats.  (Could be a
> teaser, a clip, or a full show.)
>
>         <img src="preview.png" />
>         <a href="clip.mpg">MPEG</a>
>         <a href="clip.ogm">Ogg</a>
>         <a href="clip.avi">AVI</a>
>
> And of course, you can do combos of these.
>
> So, the orthogonal concepts here seem like:
>   * there's the concept of a "preview" image.  (maybe thumbnail would
> be a better name.)
>   * there's the concept of a "show"
>   * there's the concept of a "teaser"
>   * If it is a teaser there is a "Pay to View" link
>   * show can divided up into multiple contiguous files
>   * teaser can be made up of multiple files
>   * alternatives of the same media
>   * you can combine all these
>
> Did I miss anything?
>
> (If anyone else knows SMIL here, you'll probably notice that alot of
> this stuff has already been dealt with there.  Although SMIL does much
> much more.)
>
>
> There's already some related stuff on the wiki:
>   http://microformats.org/wiki/media-metadata-examples
>   http://microformats.org/wiki/video-metadata-model
>
> And I wrote this before:
>   http://changelog.ca/log/2005/10/16/thoughts_on_video_and_audio_microformats
>
> And SMIL and Media RSS are good references too.
>
>
> Comments?
>
>
> See ya
>
> --
>     Charles Iliya Krempeaux, B.Sc.
>
>     charles @ reptile.ca
>     supercanadian @ gmail.com
>
>     developer weblog: http://ChangeLog.ca/
> ___________________________________________________________________________
>  Never forget where you came from
>


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From ryan at technorati.com  Tue Dec 13 11:24:28 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Dec 13 11:24:26 2005
Subject: [uf-discuss] How to Announce the Availability of New
	Media	Content with uf?
In-Reply-To: <439ED225.7080009@parnasse.com>
References: <1133588297.5439.93.camel@tori>	<3e21e31d6a25de22cfbca5bec8f9f361@technorati.com>	<45B0F7FE-C068-42E4-B659-9B66C42A2A10@randomchaos.com>	<op.s07bqorbares2h@mail.solitude.dk>	<1134221246.5660.24.camel@tori>
	<439D8248.7040206@parnasse.com>
	<B472FD05-C9B0-45E4-8DA3-FD31EE011BDE@technorati.com>
	<439ED225.7080009@parnasse.com>
Message-ID: <A371ABDF-0BEB-4368-B6BF-C3D6980E6771@technorati.com>

On Dec 13, 2005, at 5:52 AM, Jeff Harrington wrote:
>> Also, as I'm sure you know, ?f's are modeled after existing user   
>> behavior. So it might be worthwhile to see what artists are  
>> already  doing to promote themselves and start there.
>>
> Well, since I invented this whole 'internet musician thing' ;)   
> I'll ask myself what I would do.  Heheh...

Let us know what you find out. :D

-ryan
--
Ryan King
ryan@technorati.com



From supercanadian at gmail.com  Tue Dec 13 16:19:05 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec 13 16:19:08 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512062027q5280e5e8reaf7e9b789d62683@mail.gmail.com>
References: <84ce626f0512060127p1efd05f8ma069c13dafdb2d04@mail.gmail.com>
	<81A2CD0E-41D7-4DEB-A4E4-71F7DC16E061@mac.com>
	<84ce626f0512062027q5280e5e8reaf7e9b789d62683@mail.gmail.com>
Message-ID: <84ce626f0512131619j10dcacf5i533cd890f39a508f@mail.gmail.com>

Hello,

On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:

[...]

> If you look at my weblog -- http://changelog.ca/ -- you can see a
> couple XOXO lists where I list (some of) the shows I watch, and (some
> of) the channels I watch.

I've created a wiki page for showrolls at:

    http://microformats.org/wiki/showroll-brainstorming

Also, I've created a tool that can help you test any showrolls one
marks up.  (It extracts it, and lists what it finds.  You could use
this to compare it to what you expect to be extracted.)  It's at:

    http://newtube.org/tester/microshowroll

You can see it in action, extracting the showroll from my blog --
http://changelog.ca/ -- with this:

    http://newtube.org/tester/microshowroll?url=http://changelog.ca/


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From teohuiming.work at gmail.com  Tue Dec 13 16:28:35 2005
From: teohuiming.work at gmail.com (toydi)
Date: Tue Dec 13 16:28:38 2005
Subject: [uf-discuss] Microformats: for hand-authoring or aggregating
	purpose?
Message-ID: <73ec599d0512131628v4b8508bbw333250dd2e947a75@mail.gmail.com>

Hi all,

A question ran into my mind when i was using hCalendar-o-matic to
build my first hEvent microformats several weeks ago. From an
author/user perspective, would you prefer to create a micro-content by
hand-author, or use a helper form (e.g h*-o-matic) to help you build
it? I'm really curious to know how actually authors out there write
microformats, do share some of your experience with all. :-)

The same question strike me again as I'm thinking about submitting
data in microformats to remote web server. As a user, let say to
modify your birthday event data, do you prefer to update a <textarea>
containing microformatted XHTML, or prefer to update several <input>
textboxes and combo boxes? Which one you choose?

OTOH, more people start to write scripts to collect microformatted
contents from web sites. It seems like in nature, microformats has
been used for aggregating purpose. We publish microformatted contents,
so that others will be able to aggregate those contents easier.

These lead me to the question: microformats makes us easy to
hand-author data or aggregate data? What's your opinion? ;-)


Cheers,
--
Teo HuiMing (toydi)
http://toydi.wordpress.com
From supercanadian at gmail.com  Tue Dec 13 16:35:29 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Tue Dec 13 16:35:30 2005
Subject: [uf-discuss] Microformats: for hand-authoring or aggregating
	purpose?
In-Reply-To: <73ec599d0512131628v4b8508bbw333250dd2e947a75@mail.gmail.com>
References: <73ec599d0512131628v4b8508bbw333250dd2e947a75@mail.gmail.com>
Message-ID: <84ce626f0512131635u4853da8fsb6a3b9c56038d5bc@mail.gmail.com>

Hello,


On 12/13/05, toydi <teohuiming.work@gmail.com> wrote:
> Hi all,
>
> A question ran into my mind when i was using hCalendar-o-matic to
> build my first hEvent microformats several weeks ago. From an
> author/user perspective, would you prefer to create a micro-content by
> hand-author, or use a helper form (e.g h*-o-matic) to help you build
> it? I'm really curious to know how actually authors out there write
> microformats, do share some of your experience with all. :-)
>
> The same question strike me again as I'm thinking about submitting
> data in microformats to remote web server. As a user, let say to
> modify your birthday event data, do you prefer to update a <textarea>
> containing microformatted XHTML, or prefer to update several <input>
> textboxes and combo boxes? Which one you choose?
>
> OTOH, more people start to write scripts to collect microformatted
> contents from web sites. It seems like in nature, microformats has
> been used for aggregating purpose. We publish microformatted contents,
> so that others will be able to aggregate those contents easier.
>
> These lead me to the question: microformats makes us easy to
> hand-author data or aggregate data? What's your opinion? ;-)


The first thing to remember is that there are alot of different kinds
of developers.  Some will hand code things.  And some will need tools
(to code them automagically).  (And then there are actual users... who
will likely always need to do this stuff through tools.)

For me though. the h*-o-matics helped me learn the Microformats.  But,
when I code these, I code them by hand.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From kennyheaton at gmail.com  Tue Dec 13 16:39:52 2005
From: kennyheaton at gmail.com (kenny heaton)
Date: Tue Dec 13 16:39:56 2005
Subject: [uf-discuss] Microformats: for hand-authoring or aggregating
	purpose?
In-Reply-To: <84ce626f0512131635u4853da8fsb6a3b9c56038d5bc@mail.gmail.com>
References: <73ec599d0512131628v4b8508bbw333250dd2e947a75@mail.gmail.com>
	<84ce626f0512131635u4853da8fsb6a3b9c56038d5bc@mail.gmail.com>
Message-ID: <65b4e01f0512131639v54b5e4e3m95314754b2946684@mail.gmail.com>

I find that no XHTML writer/tool write things the way I want. Like
Charles I used the h*-o-matic's to help me learn, and to give me
starter templates, but I find I need to do most of the work by hand.

But as a user, I'd rather have a easy to use tool. I don't want to
have to worry about formatting content when I'm a user, only when I'm
an author.

kenny
From pp at myelin.co.nz  Tue Dec 13 17:28:09 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Tue Dec 13 17:28:24 2005
Subject: [uf-discuss] Microformats: for hand-authoring or aggregating
	purpose?
In-Reply-To: <73ec599d0512131628v4b8508bbw333250dd2e947a75@mail.gmail.com>
References: <73ec599d0512131628v4b8508bbw333250dd2e947a75@mail.gmail.com>
Message-ID: <439F7529.5020803@myelin.co.nz>

toydi wrote:

>A question ran into my mind when i was using hCalendar-o-matic to
>build my first hEvent microformats several weeks ago. From an
>author/user perspective, would you prefer to create a micro-content by
>hand-author, or use a helper form (e.g h*-o-matic) to help you build
>it? I'm really curious to know how actually authors out there write
>microformats, do share some of your experience with all. :-)
>  
>
Microformats have the nice feature of not being significantly harder to 
hand-author than HTML links etc., so they do actually "afford" 
hand-coding.  That said, I find it more pleasant to use a WYSIWYG editor 
to enter HTML links, as long as it doesn't screw everything up :-)

>The same question strike me again as I'm thinking about submitting
>data in microformats to remote web server. As a user, let say to
>modify your birthday event data, do you prefer to update a <textarea>
>containing microformatted XHTML, or prefer to update several <input>
>textboxes and combo boxes? Which one you choose?
>  
>
All other things being equal, I'd pick the inputs and combo boxes, as 
long as they supported the kind of data I wanted to publish.  That way I 
only need to spell everything right once to get consistently good output.

It all depends on how consistent my output would be.  For example, when 
reviewing cafes on coffee.gen.nz, I always want the same fields, and I 
want each review to look pretty much the same as the rest.  So in that 
case, I use the input form, which also gives me the convenience of 
having the fields stored in separate columns in the database.  However, 
if I was writing a freeform web page with reviews embedded in arbitrary 
places, I'd have to resort to hand-coding.

>OTOH, more people start to write scripts to collect microformatted
>contents from web sites. It seems like in nature, microformats has
>been used for aggregating purpose. We publish microformatted contents,
>so that others will be able to aggregate those contents easier.
>
>These lead me to the question: microformats makes us easy to
>hand-author data or aggregate data? What's your opinion? ;-)
>  
>
I'd say that microformats make it much easier to hand-author than 
aggregate.  They are marginally easier to parse than RDF, but still way 
harder than plain-XML formats like RSS or the Structured Blogging 
plugin's internal format.  However, the incremental work involved to 
move from publishing just HTML to publishing HTML+microformats is fairly 
small.

Of course, even though they are relatively more difficult to parse, 
their ease of publication is a Good Thing for aggregators, as it should 
result in more content in the wild...

BTW, does anybody have any figures about the quantity of microformatted 
content being published on blogs?  It will be interesting to see how the 
new SB plugins will contribute to that.

Cheers,
Phil

From supercanadian at gmail.com  Wed Dec 14 12:47:27 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Wed Dec 14 12:47:30 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
Message-ID: <84ce626f0512141247g1cb7b7c7uf4922b2e4e89c17c@mail.gmail.com>

Hello,

While I've been reseaching the stuff for the show microformat --
http://microformats.org/wiki/show-brainstorming -- I've noticed that
many sites put their show's title in an image.  So then, the
machine-readable part would be the "alt" attribute of the image.

I think this -- using images instead of plain text -- is probably
common enough that other microformats should also allow use of this.

For example, for a "microshow" (which a spec isn't written for yet,
and I'm still brainstorming) you can do something like the following
to specify a show's title:

    <div class="show">

        <span class="title">My Show</span>

    </div>

But you could also do:

    <div class="show">

        <img class="title" src="..." alt="My Show" />

    </div>

For this case the show's title (in machine-readable form) would be
what's in the alt attribute.  (The "alt" attribute is even more
important since an <img> element can NOT contain text, even if you
wanted it to.)

So, maybe hCard's, hReview's, etc should allow this too?  For example:

    <address class="vcard">
        <img class="fn" src="my-name-in-styled-lettering.png"
alt="Charles Iliya Krempeaux" />
    </address>

(And, yeah, I know this would give the problem that would can't add
the sub-structure to the "fn" that hCard's allow.  But you could
always break it up into multiple images if you wanted.  And at least
then you'd support this very common practice.)


Comments?

See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From ryan at technorati.com  Wed Dec 14 14:15:51 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Dec 14 14:15:53 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <84ce626f0512141247g1cb7b7c7uf4922b2e4e89c17c@mail.gmail.com>
References: <84ce626f0512141247g1cb7b7c7uf4922b2e4e89c17c@mail.gmail.com>
Message-ID: <D9E73991-319F-4C93-8CBB-2BDE130259A0@technorati.com>

On Dec 14, 2005, at 12:47 PM, Charles Iliya Krempeaux wrote:
> So, maybe hCard's, hReview's, etc should allow this too?  For example:
>
>     <address class="vcard">
>         <img class="fn" src="my-name-in-styled-lettering.png"
> alt="Charles Iliya Krempeaux" />
>     </address>
>
> (And, yeah, I know this would give the problem that would can't add
> the sub-structure to the "fn" that hCard's allow.  But you could
> always break it up into multiple images if you wanted.  And at least
> then you'd support this very common practice.)

For properties that don't expect images it might be reasonable to use  
the alt attribute value for the value of the property. However, it  
might be a bit too open ended (and how often do people do this,  
anyway?).

-ryan
--
Ryan King
ryan@technorati.com



From scott at randomchaos.com  Wed Dec 14 15:04:13 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Wed Dec 14 15:04:23 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <D9E73991-319F-4C93-8CBB-2BDE130259A0@technorati.com>
References: <84ce626f0512141247g1cb7b7c7uf4922b2e4e89c17c@mail.gmail.com>
	<D9E73991-319F-4C93-8CBB-2BDE130259A0@technorati.com>
Message-ID: <37A3530B-0EFB-4723-87DD-7FDDE8317C2A@randomchaos.com>


On Dec 14, 2005, at 4:15 PM, Ryan King wrote:

> On Dec 14, 2005, at 12:47 PM, Charles Iliya Krempeaux wrote:
>> So, maybe hCard's, hReview's, etc should allow this too?  For  
>> example:
>>
>>     <address class="vcard">
>>         <img class="fn" src="my-name-in-styled-lettering.png"
>> alt="Charles Iliya Krempeaux" />
>>     </address>
>>
>> (And, yeah, I know this would give the problem that would can't add
>> the sub-structure to the "fn" that hCard's allow.  But you could
>> always break it up into multiple images if you wanted.  And at least
>> then you'd support this very common practice.)
>
> For properties that don't expect images it might be reasonable to  
> use the alt attribute value for the value of the property. However,  
> it might be a bit too open ended (and how often do people do this,  
> anyway?).

Using images of stylized text with alt attributes containing the text  
is quite common:

http://www.google.com/
http://www.apple.com/
http://www.yahoo.com/
http://www.microsoft.com/
and, um...
http://www.technorati.com/
http://microformats.org/

If you're asking about TV show titles specifically, I'm sure Charles  
could answer that better, but here's one:

http://tv.yahoo.com/

My question: which should take precedence between alt and title values?

Peace,
Scott
From ryan at technorati.com  Wed Dec 14 15:24:06 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Dec 14 15:24:10 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <37A3530B-0EFB-4723-87DD-7FDDE8317C2A@randomchaos.com>
References: <84ce626f0512141247g1cb7b7c7uf4922b2e4e89c17c@mail.gmail.com>
	<D9E73991-319F-4C93-8CBB-2BDE130259A0@technorati.com>
	<37A3530B-0EFB-4723-87DD-7FDDE8317C2A@randomchaos.com>
Message-ID: <B0EB424D-1C5D-4660-A599-6E2D07E7B262@technorati.com>

On Dec 14, 2005, at 3:04 PM, Scott Reynen wrote:
> On Dec 14, 2005, at 4:15 PM, Ryan King wrote:
>> On Dec 14, 2005, at 12:47 PM, Charles Iliya Krempeaux wrote:
>>> So, maybe hCard's, hReview's, etc should allow this too?  For  
>>> example:
>>>
>>>     <address class="vcard">
>>>         <img class="fn" src="my-name-in-styled-lettering.png"
>>> alt="Charles Iliya Krempeaux" />
>>>     </address>
>>>
>>> (And, yeah, I know this would give the problem that would can't add
>>> the sub-structure to the "fn" that hCard's allow.  But you could
>>> always break it up into multiple images if you wanted.  And at least
>>> then you'd support this very common practice.)
>>
>> For properties that don't expect images it might be reasonable to  
>> use the alt attribute value for the value of the property.  
>> However, it might be a bit too open ended (and how often do people  
>> do this, anyway?).
>
> Using images of stylized text with alt attributes containing the  
> text is quite common:
>
> http://www.google.com/
> http://www.apple.com/
> http://www.yahoo.com/
> http://www.microsoft.com/
> and, um...
> http://www.technorati.com/
> http://microformats.org/

Eh, good point. I guess I wasn't thinking about logos and such. But  
in the case of technorati.com, we could reasonably make our logo into  
an hcard with:

<span class="vcard">
	<a class="url" href="http://technorati.com/">
		<img class="org fn logo" src="http://static.technorati.com/pix/tn- 
logo.gif" alt="Technorati" />
	</a>
</span>

With the interpretation being:

fn=Technorati
org=Technorati
url=http://technorati.com/
logo=http://static.technorati.com/pix/tn-logo.gif

> If you're asking about TV show titles specifically, I'm sure  
> Charles could answer that better, but here's one:
>
> http://tv.yahoo.com/
>
> My question: which should take precedence between alt and title  
> values?

Good question.

 From the spec [http://www.w3.org/TR/REC-html40/struct/ 
objects.html#adef-alt]:

> alt = text [CS]
> For user agents that cannot display images, forms, or applets, this  
> attribute specifies alternate text. The language of the alternate  
> text is specified by the lang attribute.
> Several non-textual elements (IMG, AREA, APPLET, and INPUT) let  
> authors specify alternate text to serve as content when the element  
> cannot be rendered normally. Specifying alternate text assists  
> users without graphic display terminals, users whose browsers don't  
> support forms, visually impaired users, those who use speech  
> synthesizers, those who have configured their graphical user agents  
> not to display images, etc.
and [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.3]

> title = text [CS]
> This attribute offers advisory information about the element for  
> which it is set.

It seems to me that title would not make sense for content (except  
for in the case of the abbr-datetime pattern). Alt seems more  
meaningful here.

-ryan

--
Ryan King
ryan@technorati.com



From supercanadian at gmail.com  Wed Dec 14 15:26:04 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Wed Dec 14 15:26:08 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <37A3530B-0EFB-4723-87DD-7FDDE8317C2A@randomchaos.com>
References: <84ce626f0512141247g1cb7b7c7uf4922b2e4e89c17c@mail.gmail.com>
	<D9E73991-319F-4C93-8CBB-2BDE130259A0@technorati.com>
	<37A3530B-0EFB-4723-87DD-7FDDE8317C2A@randomchaos.com>
Message-ID: <84ce626f0512141526r52af5bb3j462314410edf04c9@mail.gmail.com>

Hello,

On 12/14/05, Scott Reynen <scott@randomchaos.com> wrote:
>
> On Dec 14, 2005, at 4:15 PM, Ryan King wrote:
>
> > On Dec 14, 2005, at 12:47 PM, Charles Iliya Krempeaux wrote:
> >> So, maybe hCard's, hReview's, etc should allow this too?  For
> >> example:
> >>
> >>     <address class="vcard">
> >>         <img class="fn" src="my-name-in-styled-lettering.png"
> >> alt="Charles Iliya Krempeaux" />
> >>     </address>
> >>
> >> (And, yeah, I know this would give the problem that would can't add
> >> the sub-structure to the "fn" that hCard's allow.  But you could
> >> always break it up into multiple images if you wanted.  And at least
> >> then you'd support this very common practice.)
> >
> > For properties that don't expect images it might be reasonable to
> > use the alt attribute value for the value of the property. However,
> > it might be a bit too open ended (and how often do people do this,
> > anyway?).
>
> Using images of stylized text with alt attributes containing the text
> is quite common:
>
> http://www.google.com/
> http://www.apple.com/
> http://www.yahoo.com/
> http://www.microsoft.com/
> and, um...
> http://www.technorati.com/
> http://microformats.org/
>
> If you're asking about TV show titles specifically, I'm sure Charles
> could answer that better,

Well, for one I'm having this situation on "Internet TV" sites that
I'm making.  People want to use "graphic logos" (that they had artists
design) and not plain text.  So, the machine-readable title is the
value of the "alt" attribute.


> but here's one:
>
> http://tv.yahoo.com/
>
> My question: which should take precedence between alt and title values?

IMO, "title" should take precedece over anything else.  (Don't have a
reference in the HTML spec to back it up but,...) it seems to kind of
be the purpose of the "title" attribute.  For example:

    <p>
        Read <a href="http://changelog.ca/" title="Weblog for Charles
Iliya Krempeaux">my blog</a>.
    </p>

The phrase "my blog" would a back title for "http://changelog.ca/" so
we override this with the use of the "title".  Same would apply to an
image.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From ryan at technorati.com  Wed Dec 14 16:20:19 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Dec 14 16:20:22 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <84ce626f0512141526r52af5bb3j462314410edf04c9@mail.gmail.com>
References: <84ce626f0512141247g1cb7b7c7uf4922b2e4e89c17c@mail.gmail.com>
	<D9E73991-319F-4C93-8CBB-2BDE130259A0@technorati.com>
	<37A3530B-0EFB-4723-87DD-7FDDE8317C2A@randomchaos.com>
	<84ce626f0512141526r52af5bb3j462314410edf04c9@mail.gmail.com>
Message-ID: <A8FB7EA1-6263-4D61-BACF-5B5F434F0ED4@technorati.com>

On Dec 14, 2005, at 3:26 PM, Charles Iliya Krempeaux wrote:
> IMO, "title" should take precedece over anything else.  (Don't have a
> reference in the HTML spec to back it up but,...)

I disagree. See my previous mail [http://microformats.org/discuss/ 
mail/microformats-discuss/2005-December/002401.html], where I  
actually have references from the spec.

-ryan

> it seems to kind of
> be the purpose of the "title" attribute.  For example:
>
>     <p>
>         Read <a href="http://changelog.ca/" title="Weblog for Charles
> Iliya Krempeaux">my blog</a>.
>     </p>
>
> The phrase "my blog" would a back title for "http://changelog.ca/" so
> we override this with the use of the "title".  Same would apply to an
> image.

--
Ryan King
ryan@technorati.com



From maetl at mcs.vuw.ac.nz  Wed Dec 14 17:21:57 2005
From: maetl at mcs.vuw.ac.nz (Mark Rickerby)
Date: Wed Dec 14 17:22:00 2005
Subject: [uf-discuss] requirements testing
Message-ID: <ffa20f220512141721p5d957726u25cff576cbd1e5@mail.gmail.com>

Hi all,

For the last few months, I've been considering possibilities for using
HTML to define test cases, with references to various testing formats
from around the web:

http://microformats.org/wiki/requirements-testing
http://microformats.org/wiki/requirements-testing-examples

Through my work, I've had to write a lot of tests, and in some cases I
would rather that they weren't bound to a specific framework or
language. It would also be good if they were readable by people who
aren't necessarily familiar with specific programming language syntax.
Hence HTML makes a lot of sense to use here.

One of the key things I've noted is that the existing tools already
based on an HTML format (like Selenium and FitNesse) use <table>
elements to define assertions. These tables are effective, but clunky,
and not particularly natural to write, when compared to the native
syntax of various unit testing frameworks (eg: JUnit, SimpleTest,
Test::Unit)...

Heres an example from the Selenium documentation:

<table border="1" class="table">
<colgroup>
<col width="23%" />
<col width="55%" />
<col width="21%" />
</colgroup>
<tbody valign="top">
<tr><td>type</td>
<td>nameField</td>
<td>John Smith</td>
</tr>
<tr><td>typeAndWait</td>
<td>textBoxThatSubmitsOnChange</td>
<td>newValue</td>(
</tr>
</tbody>
</table>

Great idea, but it seems a kinda strange mash of HTML - especially if
this is intended to be hand coded. It strikes me that the natural
expression of a web test case is a bullet point list or an ordered
list. Here's an example using the Selenium semantics, which seems a
litttle bit more clear:

<ul class="test">
 <li>
  <span class="command">type</span>
  <span class="target">nameField</span>
  <span class="value">John Smith</span>
 </li>
 <li>
  <span class="command">typeAndWait</span>
  <span class="target">textBoxThatSubmitsOnChange</span>
  <span class="value">newValue</span>
 </li>
</ul>

If we removed the selenium commands, and reduced the test case to
natural language semantics we would have something like:

<ul class="test">
  <li>type "John Smith" in nameField</li>
  <li>type "newValue" in textBoxThatSubmitsOnChange and wait</li>
</ul>

This example gets to the root of the problem of documenting acceptance
tests in HTML: there are different levels of abstraction that will all
produce the same imperative command.

I was just wondering if anyone had any thoughts, criticism or
suggestions relating to this. The concept has been kicked around for a
while, so I thought I would push it out on the list, to see if anyone
else could see any significant overlaps with the existing microformats
work. Pointers to other testing tools / languages that I haven't yet
covered would be much appreciated, as would better HTML examples.

Also - is there such a thing as rel-test? Has anyone used this - or
has intentions to use this, and if so - where and what for?

Thanks,
Mark

--
----------------------------------------------------------------------
mark rickerby
http://maetl.coretxt.net.nz
http://www.mcs.vuw.ac.nz/~maetl/
----------------------------------------------------------------------
From ryan at technorati.com  Wed Dec 14 18:09:46 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Dec 14 18:09:51 2005
Subject: [uf-discuss] Call for Victims (II)
In-Reply-To: <439D9598.1050602@blogmatrix.com>
References: <439B3FC5.4020505@blogmatrix.com> <439D9598.1050602@blogmatrix.com>
Message-ID: <3433DC9D-0C01-4FD1-8D3F-33BCB49AFA2B@technorati.com>

On Dec 12, 2005, at 7:22 AM, David Janes -- BlogMatrix wrote:

> The hAtom Template Rewriter now supports WordPress (as well as  
> MovableType and Blogger). If you have a WordPress blog and would  
> like to support the hAtom microformat, please send me a note and  
> I'll set you up

FWIW, I did mine by hand. Took about 5 minutes:

http://theryanking.com/blog/

-ryan
--
Ryan King
ryan@technorati.com



From davidjanes at blogmatrix.com  Wed Dec 14 18:15:37 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 14 18:15:40 2005
Subject: [uf-discuss] Call for Victims (II)
In-Reply-To: <3433DC9D-0C01-4FD1-8D3F-33BCB49AFA2B@technorati.com>
References: <439B3FC5.4020505@blogmatrix.com> <439D9598.1050602@blogmatrix.com>
	<3433DC9D-0C01-4FD1-8D3F-33BCB49AFA2B@technorati.com>
Message-ID: <43A0D1C9.1030609@blogmatrix.com>

Cool:
http://tinyurl.com/btb8z

I'm still trying to figure out if the structured blogging stuff is 
generating proper hreview or if there's a problem with my parser. A 
minor concern: I'm off to semi-vacation for a 10 day.

Here's some samples if folks want to look at it:
http://outputthis.blogspot.com/
http://pokemon.broadbandmechanics.com/~phil/mt/

Regards, etc...
David

Ryan King wrote:
> On Dec 12, 2005, at 7:22 AM, David Janes -- BlogMatrix wrote:
> 
>> The hAtom Template Rewriter now supports WordPress (as well as 
>> MovableType and Blogger). If you have a WordPress blog and would like 
>> to support the hAtom microformat, please send me a note and I'll set 
>> you up
> 
> FWIW, I did mine by hand. Took about 5 minutes:
> 
> http://theryanking.com/blog/
> 
> -ryan
> -- 
> Ryan King
> ryan@technorati.com
> 
> 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 
> 

From pp at myelin.co.nz  Wed Dec 14 21:53:19 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Wed Dec 14 21:53:20 2005
Subject: [uf-discuss] Call for Victims (II)
In-Reply-To: <43A0D1C9.1030609@blogmatrix.com>
References: <439B3FC5.4020505@blogmatrix.com>
	<439D9598.1050602@blogmatrix.com>	<3433DC9D-0C01-4FD1-8D3F-33BCB49AFA2B@technorati.com>
	<43A0D1C9.1030609@blogmatrix.com>
Message-ID: <43A104CF.4070609@myelin.co.nz>

Oh, excellent, a parser I can test stuff with.

See also:

http://pokemon.broadbandmechanics.com/~phil/sb_latest/

-> the parser can find two hReviews (http://tinyurl.com/83kwe) and three 
hCalendar objects (

http://structuredblogging.org/blog/

David Janes -- BlogMatrix wrote:

> Cool:
> http://tinyurl.com/btb8z
>
> I'm still trying to figure out if the structured blogging stuff is 
> generating proper hreview or if there's a problem with my parser. A 
> minor concern: I'm off to semi-vacation for a 10 day.
>
> Here's some samples if folks want to look at it:
> http://outputthis.blogspot.com/
> http://pokemon.broadbandmechanics.com/~phil/mt/
>
> Regards, etc...
> David
>
> Ryan King wrote:
>
>> On Dec 12, 2005, at 7:22 AM, David Janes -- BlogMatrix wrote:
>>
>>> The hAtom Template Rewriter now supports WordPress (as well as 
>>> MovableType and Blogger). If you have a WordPress blog and would 
>>> like to support the hAtom microformat, please send me a note and 
>>> I'll set you up
>>
>>
>> FWIW, I did mine by hand. Took about 5 minutes:
>>
>> http://theryanking.com/blog/
>>
>> -ryan
>> -- 
>> Ryan King
>> ryan@technorati.com
>>
>>
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss


From pp at myelin.co.nz  Wed Dec 14 22:23:28 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Wed Dec 14 22:23:29 2005
Subject: [uf-discuss] Call for Victims (II)
In-Reply-To: <43A0D1C9.1030609@blogmatrix.com>
References: <439B3FC5.4020505@blogmatrix.com>
	<439D9598.1050602@blogmatrix.com>	<3433DC9D-0C01-4FD1-8D3F-33BCB49AFA2B@technorati.com>
	<43A0D1C9.1030609@blogmatrix.com>
Message-ID: <43A10BE0.7080504@myelin.co.nz>

Argh, hit 'send' too early...

----

Oh, excellent, a parser I can test stuff with.

It's quite possible that SB doesn't generate proper hreview... if 
anybody notices anything wrong, please let me know, and I'll make sure 
it's fixed straight away.

Testing out the URLs you mention...

* http://pokemon.broadbandmechanics.com/~phil/mt/: four hReview objects 
(http://tinyurl.com/7999b).  That's actually a very old version of the 
MT plugin though - you're better off looking at /~phil/sb_mt_demo/ 
(http://tinyurl.com/beobh).

-> a few of those are broken because class="hreview" is on the wrong 
div.  This is already fixed in the latest code, I think, except for 
software reviews, which I've just fixed and will be in the code on the 
structuredblogging.org website in the morning.

* http://outputthis.blogspot.com/ (http://tinyurl.com/byw2v) has the 
same problem - which will be fixed in the morning.

* http://pokemon.broadbandmechanics.com/~phil/sb_latest/

-> the parser can find two hReview (http://tinyurl.com/83kwe) and three 
hCalendar objects (http://tinyurl.com/8yqqg).  The empty locations are 
an SB issue on the to-do list.

http://structuredblogging.org/blog/

-> three hCalendar objects (http://tinyurl.com/9cj4y), all look good.

Cheers,
Phil :)


David Janes -- BlogMatrix wrote:

> Cool:
> http://tinyurl.com/btb8z
>
> I'm still trying to figure out if the structured blogging stuff is 
> generating proper hreview or if there's a problem with my parser. A 
> minor concern: I'm off to semi-vacation for a 10 day.
>
> Here's some samples if folks want to look at it:
> http://outputthis.blogspot.com/
> http://pokemon.broadbandmechanics.com/~phil/mt/
>
> Regards, etc...
> David
>
> Ryan King wrote:
>
>> On Dec 12, 2005, at 7:22 AM, David Janes -- BlogMatrix wrote:
>>
>>> The hAtom Template Rewriter now supports WordPress (as well as 
>>> MovableType and Blogger). If you have a WordPress blog and would 
>>> like to support the hAtom microformat, please send me a note and 
>>> I'll set you up
>>
>>
>>
>> FWIW, I did mine by hand. Took about 5 minutes:
>>
>> http://theryanking.com/blog/
>>
>> -ryan
>> -- 
>> Ryan King
>> ryan@technorati.com
>>
>>
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss




From viny at MIT.EDU  Thu Dec 15 07:13:28 2005
From: viny at MIT.EDU (Vinay Pulim)
Date: Thu Dec 15 07:13:40 2005
Subject: [uf-discuss] Relevant tags in hReview
Message-ID: <20051215101328.mkix5p8a45yckssw@webmail.mit.edu>

Hi, I'm working on an hreview aggregator (http://kritx.com) and had a question
about how to properly handle tags.  Specifically, the Cafe Borrone example in
the hReview wiki contains numerous reltags.  However, some of them (food,
ambience, service, and price) don't really describe the business, but rather
different types of ratings associated with the business.  If an hReview
aggregator were to simply tag a review with every reltag it contained, it would
contain a mix of tags describing the actual item being reviewed (coffee, jazz,
sandwich, etc...) as well as tags describing the various ratings associated
with it (price, ambience, etc...).  Is this how reltags within hReviews were
intended to be parsed?  That is, should rating tags show up alongside item tags
when an hReview is displayed?

I think the answer is "yes", but I just wanted to make sure I'm understanding
this correctly.

-Vinay
From tantek at cs.stanford.edu  Thu Dec 15 07:40:36 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec 15 07:41:07 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <B0EB424D-1C5D-4660-A599-6E2D07E7B262@technorati.com>
Message-ID: <BFC6CE2B.65186%tantek@cs.stanford.edu>

On 12/14/05 3:24 PM, "Ryan King" <ryan@technorati.com> wrote:

> On Dec 14, 2005, at 3:04 PM, Scott Reynen wrote:
>> On Dec 14, 2005, at 4:15 PM, Ryan King wrote:
>>> On Dec 14, 2005, at 12:47 PM, Charles Iliya Krempeaux wrote:
>>>> So, maybe hCard's, hReview's, etc should allow this too?  For
>>>> example:
>>>> 
>>>>     <address class="vcard">
>>>>         <img class="fn" src="my-name-in-styled-lettering.png"
>>>> alt="Charles Iliya Krempeaux" />
>>>>     </address>
>>>> 
>>>> (And, yeah, I know this would give the problem that would can't add
>>>> the sub-structure to the "fn" that hCard's allow.  But you could
>>>> always break it up into multiple images if you wanted.  And at least
>>>> then you'd support this very common practice.)
>>> 
>>> For properties that don't expect images it might be reasonable to
>>> use the alt attribute value for the value of the property.
>>> However, it might be a bit too open ended (and how often do people
>>> do this, anyway?).
>> 
>> Using images of stylized text with alt attributes containing the
>> text is quite common:
>> 
>> http://www.google.com/
>> http://www.apple.com/
>> http://www.yahoo.com/
>> http://www.microsoft.com/
>> and, um...
>> http://www.technorati.com/
>> http://microformats.org/
> 
> Eh, good point. I guess I wasn't thinking about logos and such. But
> in the case of technorati.com, we could reasonably make our logo into
> an hcard with:
> 
> <span class="vcard">
> <a class="url" href="http://technorati.com/">
> <img class="org fn logo" src="http://static.technorati.com/pix/tn-
> logo.gif" alt="Technorati" />
> </a>
> </span>
> 
> With the interpretation being:
> 
> fn=Technorati
> org=Technorati
> url=http://technorati.com/
> logo=http://static.technorati.com/pix/tn-logo.gif

Ryan is correct, and this has been specified for quite some time in the
hCard parsing spec:

<http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_val
ues>


>> If you're asking about TV show titles specifically, I'm sure
>> Charles could answer that better, but here's one:
>> 
>> http://tv.yahoo.com/
>> 
>> My question: which should take precedence between alt and title
>> values?
> 
> Good question.
> 
> From the spec [http://www.w3.org/TR/REC-html40/struct/
> objects.html#adef-alt]:
> 
>> alt = text [CS]
>> For user agents that cannot display images, forms, or applets, this
>> attribute specifies alternate text. The language of the alternate
>> text is specified by the lang attribute.
>> Several non-textual elements (IMG, AREA, APPLET, and INPUT) let
>> authors specify alternate text to serve as content when the element
>> cannot be rendered normally. Specifying alternate text assists
>> users without graphic display terminals, users whose browsers don't
>> support forms, visually impaired users, those who use speech
>> synthesizers, those who have configured their graphical user agents
>> not to display images, etc.
> and [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.3]
> 
>> title = text [CS]
>> This attribute offers advisory information about the element for
>> which it is set.
> 
> It seems to me that title would not make sense for content (except
> for in the case of the abbr-datetime pattern). Alt seems more
> meaningful here.

Agreed.

In general we should not be using "title" for this kind of purpose unless
*absolutely* necessary, like in the abbr-datetime pattern, as Ryan pointed
it.

The rule still is to keep the data as visible as possible.  We made an
exception in the abbr-datetime case only because of another rule which is
humans first, machines second.

Thanks,

Tantek

From scott at randomchaos.com  Thu Dec 15 08:16:18 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec 15 08:16:26 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <BFC6CE2B.65186%tantek@cs.stanford.edu>
References: <BFC6CE2B.65186%tantek@cs.stanford.edu>
Message-ID: <76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>

Tantek ?elik wrote:

>> It seems to me that title would not make sense for content (except
>> for in the case of the abbr-datetime pattern). Alt seems more
>> meaningful here.
>
> Agreed.
>
> In general we should not be using "title" for this kind of purpose  
> unless
> *absolutely* necessary, like in the abbr-datetime pattern, as Ryan  
> pointed
> it.
>
> The rule still is to keep the data as visible as possible.  We made an
> exception in the abbr-datetime case only because of another rule  
> which is
> humans first, machines second.

Maybe I'm misunderstanding you, but it doesn't seem to me that using  
alt for machine data follows the humans first principle because  
imageless humans are reading alt tags.  As a human, I'd hate to be  
reading something like this in a screen reader:

<img class="bday" src="today.png" alt="20051215T080000Z" />

And my first inclination would be to give imageless humans something  
more readable by putting the machine data in the title attribute  
instead, e.g.:

<img class="bday" src="today.png" alt="December 15, 2005"  
title="20051215T080000Z" />

This is sending three different types of data to three different  
types of readers.  src is for imaged humans, alt is for imageless  
humans, and title is for machines.  I understand the drawback of  
further complication, but the alternative seems to require authors to  
choose between usability and microformats.

Peace,
Scott
From tantek at cs.stanford.edu  Thu Dec 15 09:07:24 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec 15 09:07:53 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>
Message-ID: <BFC6E2A2.65196%tantek@cs.stanford.edu>

On 12/15/05 8:16 AM, "Scott Reynen" <scott@randomchaos.com> wrote:

> Maybe I'm misunderstanding you, but it doesn't seem to me that using
> alt for machine data follows the humans first principle

The idea is to use the alt for the human readable text version of what is in
the image, sorry I wasn't clear about that.

> because  
> imageless humans are reading alt tags.

Right.

> As a human, I'd hate to be
> reading something like this in a screen reader:
> 
> <img class="bday" src="today.png" alt="20051215T080000Z" />

Indeed.

> And my first inclination would be to give imageless humans something
> more readable by putting the machine data in the title attribute
> instead, e.g.:
> 
> <img class="bday" src="today.png" alt="December 15, 2005"
> title="20051215T080000Z" />
>
> This is sending three different types of data to three different
> types of readers.

AFAIK this is the first we have discussed using the <img> tag to convey
three pieces of information like that.

> src is for imaged humans, alt is for imageless
> humans, and title is for machines.  I understand the drawback of
> further complication, but the alternative seems to require authors to
> choose between usability and microformats.

Here is my question:

Have you seen any examples on the Web where people are publishing date-time
information as an image?

Thanks,

Tantek

From supercanadian at gmail.com  Thu Dec 15 09:18:38 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Thu Dec 15 09:18:40 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <BFC6E2A2.65196%tantek@cs.stanford.edu>
References: <76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>
	<BFC6E2A2.65196%tantek@cs.stanford.edu>
Message-ID: <84ce626f0512150918m7df4b81bh4ef82c114bbcd880@mail.gmail.com>

Hello,

On 12/15/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> On 12/15/05 8:16 AM, "Scott Reynen" <scott@randomchaos.com> wrote:
>
> > Maybe I'm misunderstanding you, but it doesn't seem to me that using
> > alt for machine data follows the humans first principle
>
> The idea is to use the alt for the human readable text version of what is in
> the image, sorry I wasn't clear about that.
>
> > because
> > imageless humans are reading alt tags.
>
> Right.
>
> > As a human, I'd hate to be
> > reading something like this in a screen reader:
> >
> > <img class="bday" src="today.png" alt="20051215T080000Z" />
>
> Indeed.
>
> > And my first inclination would be to give imageless humans something
> > more readable by putting the machine data in the title attribute
> > instead, e.g.:
> >
> > <img class="bday" src="today.png" alt="December 15, 2005"
> > title="20051215T080000Z" />
> >
> > This is sending three different types of data to three different
> > types of readers.
>
> AFAIK this is the first we have discussed using the <img> tag to convey
> three pieces of information like that.
>
> > src is for imaged humans, alt is for imageless
> > humans, and title is for machines.  I understand the drawback of
> > further complication, but the alternative seems to require authors to
> > choose between usability and microformats.
>
> Here is my question:
>
> Have you seen any examples on the Web where people are publishing date-time
> information as an image?

>From usability point of view, if is sometimes betters to use images to
convey information (when you can),  So,.... this isn't a published
date-time, but how about a progress bar:

    <img src="progress-bar" alt="38% done (you stil have a ways to
go)" title="0.38" />

Using the "alt" and "title" would both be very useful.  You see these
in the wild all the time.


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From scott at randomchaos.com  Thu Dec 15 11:23:24 2005
From: scott at randomchaos.com (Scott Reynen)
Date: Thu Dec 15 11:23:35 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <BFC6E2A2.65196%tantek@cs.stanford.edu>
References: <BFC6E2A2.65196%tantek@cs.stanford.edu>
Message-ID: <941B49C3-6A9B-4465-B737-1EC4A345902F@randomchaos.com>

Tantek ?elik wrote:

> Have you seen any examples on the Web where people are publishing  
> date-time
> information as an image?

Here's a couple I've seen recently:

http://www.gizmodo.com/

<div class="datehed"><img src="/a/v4/i/d/thu.gif" alt="Thursday" / 
 ><img src="/a/v4/i/d/15.gif" alt="15" /><img src="/a/v4/i/d/dec.gif"  
alt="December" /><img src="/a/v4/i/d/2005.gif" alt="2005" /></div>

http://flickr.com/explore/interesting/2005/12/

<img src="http://static.flickr.com/18/69212214_6e1b640642_s.jpg"  
width="75" height="75" class="Thumb" alt="Zoom into December 1st  
2005" />

Peace,
Scott

From ryan at technorati.com  Thu Dec 15 12:45:09 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 15 12:45:11 2005
Subject: [uf-discuss] Relevant tags in hReview
In-Reply-To: <20051215101328.mkix5p8a45yckssw@webmail.mit.edu>
References: <20051215101328.mkix5p8a45yckssw@webmail.mit.edu>
Message-ID: <49CB14E5-15BB-4679-B933-BF72D3031888@technorati.com>

On Dec 15, 2005, at 7:13 AM, Vinay Pulim wrote:

> Hi, I'm working on an hreview aggregator (http://kritx.com) and had  
> a question
> about how to properly handle tags.  Specifically, the Cafe Borrone  
> example in
> the hReview wiki contains numerous reltags.  However, some of them  
> (food,
> ambience, service, and price) don't really describe the business,  
> but rather
> different types of ratings associated with the business.  If an  
> hReview
> aggregator were to simply tag a review with every reltag it  
> contained, it would
> contain a mix of tags describing the actual item being reviewed  
> (coffee, jazz,
> sandwich, etc...) as well as tags describing the various ratings  
> associated
> with it (price, ambience, etc...).  Is this how reltags within  
> hReviews were
> intended to be parsed?  That is, should rating tags show up  
> alongside item tags
> when an hReview is displayed?

Honestly, this is up to you. If you think it makes sense to show them  
together, go for it.

> I think the answer is "yes", but I just wanted to make sure I'm  
> understanding
> this correctly.

The two kinds of tags are subtly different, but not so different that  
you can't collapse them, if you wanted to.

-ryan

--
Ryan King
ryan@technorati.com



From viny at MIT.EDU  Thu Dec 15 14:46:12 2005
From: viny at MIT.EDU (Vinay Pulim)
Date: Thu Dec 15 14:46:24 2005
Subject: [uf-discuss] Relevant tags in hReview
In-Reply-To: <49CB14E5-15BB-4679-B933-BF72D3031888@technorati.com>
References: <20051215101328.mkix5p8a45yckssw@webmail.mit.edu>
	<49CB14E5-15BB-4679-B933-BF72D3031888@technorati.com>
Message-ID: <20051215174612.m4j0i7y1fpeas8wc@webmail.mit.edu>

Quoting Ryan King <ryan@technorati.com>:

>> That is, should rating tags show up  alongside item tags
>> when an hReview is displayed?
>
> Honestly, this is up to you. If you think it makes sense to show them 
>  together, go for it.
>
> The two kinds of tags are subtly different, but not so different that 
>  you can't collapse them, if you wanted to.

I understand.  Without any standard markup to differentiate between the 
two uses
of the reltag, the parser would have to make some assumptions when 
inferring the
reltag's target.

Perhaps we could tie rating specific tags into the new rating format suggested
in an earlier thread for hReview 0.3:

<p class="rating">
On Fred's <span class="best">4</span><a 
href="http://en.wikipedia.org/wiki/ICBM"
rel="tag">ICBM</a> scale, I give this a <span
class="value">2</span>.
</p>

 From this structure, it is clear that the tag "ICBM" is referring to 
the rating
and not the item.

Anyway, thanks for your response Ryan.  I'll just assume all tags refer to the
item for now.

-Vinay
From ryan at technorati.com  Thu Dec 15 16:23:27 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 15 16:23:30 2005
Subject: [uf-discuss] Relevant tags in hReview
In-Reply-To: <20051215174612.m4j0i7y1fpeas8wc@webmail.mit.edu>
References: <20051215101328.mkix5p8a45yckssw@webmail.mit.edu>
	<49CB14E5-15BB-4679-B933-BF72D3031888@technorati.com>
	<20051215174612.m4j0i7y1fpeas8wc@webmail.mit.edu>
Message-ID: <26FCE08B-171C-406F-915D-38153D257C38@technorati.com>

On Dec 15, 2005, at 2:46 PM, Vinay Pulim wrote:

> Quoting Ryan King <ryan@technorati.com>:
>
>>> That is, should rating tags show up  alongside item tags
>>> when an hReview is displayed?
>>
>> Honestly, this is up to you. If you think it makes sense to show  
>> them  together, go for it.
>>
>> The two kinds of tags are subtly different, but not so different  
>> that  you can't collapse them, if you wanted to.
>
> I understand.  Without any standard markup to differentiate between  
> the two uses
> of the reltag,

Huh? You mean this isn't differentiable:

<a href="http://en.wikipedia.org/wiki/Food" rel="tag"> Food: <span  
class="rating">18</span>/<span class="best">30</span></a>;

from this:

<a rel="tag" href="http://your-favorite-tagspace.com/Awesome">Awesome! 
</a>

? Or maybe I'm not understanding you.


> the parser would have to make some assumptions when inferring the
> reltag's target.

If by target, you mean "what the tag is tagging," then yes, you may  
need to make some assumptions. However, this is the case with rel-tag  
pretty much everywhere.

> Perhaps we could tie rating specific tags into the new rating  
> format suggested
> in an earlier thread for hReview 0.3:
>
> <p class="rating">
> On Fred's <span class="best">4</span><a href="http:// 
> en.wikipedia.org/wiki/ICBM"
> rel="tag">ICBM</a> scale, I give this a <span
> class="value">2</span>.
> </p>
>
> From this structure, it is clear that the tag "ICBM" is referring  
> to the rating
> and not the item.

I don't think we gain anything by adding another layer of nesting here.

> Anyway, thanks for your response Ryan.  I'll just assume all tags  
> refer to the
> item for now.

No problem.

-ryan
--
Ryan King
ryan@technorati.com



From viny at MIT.EDU  Thu Dec 15 16:53:14 2005
From: viny at MIT.EDU (Vinay Pulim)
Date: Thu Dec 15 16:54:04 2005
Subject: [uf-discuss] Relevant tags in hReview
In-Reply-To: <26FCE08B-171C-406F-915D-38153D257C38@technorati.com>
References: <20051215101328.mkix5p8a45yckssw@webmail.mit.edu>
	<49CB14E5-15BB-4679-B933-BF72D3031888@technorati.com>
	<20051215174612.m4j0i7y1fpeas8wc@webmail.mit.edu>
	<26FCE08B-171C-406F-915D-38153D257C38@technorati.com>
Message-ID: <20051215195314.nsadtws86bz4gok8@webmail.mit.edu>

> <a href="http://en.wikipedia.org/wiki/Food" rel="tag"> Food: <span  
> class="rating">18</span>/<span class="best">30</span></a>;

I must have gone over that example a hundred times and not once did I notice
that the <span class="best"> tag was a child of the <a> tag. Then 
entire time I
was thinking the <a> and <span class="best"> were siblings.  That's 
what led to
the confusion about what that the tag was referring to.

I apologize for spamming the list about this...please ignore my earlier 
comments
in this thread.

-Vinay
From tantek at cs.stanford.edu  Fri Dec 16 02:16:53 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Dec 16 02:17:31 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512131619j10dcacf5i533cd890f39a508f@mail.gmail.com>
Message-ID: <BFC7D3CE.65234%tantek@cs.stanford.edu>

Charles,

I am emailing you directly on this because it appears you have not received
earlier email sent on this subject.

Regarding:

On 12/13/05 4:19 PM, "Charles Iliya Krempeaux" <supercanadian@gmail.com>
wrote:

> Hello,
> 
> On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> 
> [...]
> 
>> If you look at my weblog -- http://changelog.ca/ -- you can see a
>> couple XOXO lists where I list (some of) the shows I watch, and (some
>> of) the channels I watch.
> 
> I've created a wiki page for showrolls at:
> 
>   http://microformats.org/wiki/showroll-brainstorming

and

> Hello,
> 
> I've started a page for the "show brainstorming" on the wiki.  You can
> get to it via:
> 
>   http://microformats.org/wiki/show-brainstorming
> 
> 

First, please take a closer look at the microformats process.

 http://microformats.org/wiki/process


A few comments in particular.

1. Jumping straight to a *-brainstorming document is premature.  There
should first be a *-examples document where *real* *existing* examples of
the content being published on the Web are documented.  Second there should
be a *-formats document where previous/current *formats* that attempt to
solve the problem are documented.  Neither of these have been created, and
the process page is quite clear about this.

2. As far as I can tell, this is nothing but a link to a piece of media, in
particular video.  This is ignoring (since it doesn't even mention it),
several existing standards and microformats:

 a. To indicate that the type of data being linked to is video, use the
appropriate mime type, e.g. <a type="video/mpeg" href="show.mpg">...</a>

 b. rel-enclosure handles the "download this" semantic already.

There is nowhere near enough justification for a new microformat for this.

3. AFAIK, there has been no attempt to work with this within the current
media-metadata or video-metadata work/research.   Rather than inventing a
new media related microformat, please first understand existing work towards
media microformats, and work within that research.

  http://microformats.org/wiki/media-metadata-examples

This has been requested several times in this thread.

Rather than creating new pages for a specific type of media microformat,
please instead work on the media-metadata-* pages.  There has been a lot of
thinking by a lot of smart folks put into trying to figure out
media-metadata (even just links), and ignoring that is blatant violation of
the process -- don't ignore nor reinvent earlier work.


I also noticed this: http://microformats.org/wiki/microshow

1. See above problems.

2. Please do not create a microformat page for something for which there
isn't even a strawman specification in the *-brainstorming page.  Shell
pages like this one will be deleted.

Thanks,

Tantek

From tantek at cs.stanford.edu  Fri Dec 16 02:33:24 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Dec 16 02:33:58 2005
Subject: [uf-discuss] Relevant tags in hReview
In-Reply-To: <20051215195314.nsadtws86bz4gok8@webmail.mit.edu>
Message-ID: <BFC7D793.6523A%tantek@cs.stanford.edu>

On 12/15/05 4:53 PM, "Vinay Pulim" <viny@MIT.EDU> wrote:

>> <a href="http://en.wikipedia.org/wiki/Food" rel="tag"> Food: <span
>> class="rating">18</span>/<span class="best">30</span></a>;
> 
> I must have gone over that example a hundred times and not once did I notice
> that the <span class="best"> tag was a child of the <a> tag. Then
> entire time I
> was thinking the <a> and <span class="best"> were siblings.  That's
> what led to
> the confusion about what that the tag was referring to.

This is good feedback Vinay.  Clearly we need to make this more clear in the
spec.

> I apologize for spamming the list about this...please ignore my earlier
> comments in this thread.

No problem at all.

I strongly recommend you also read through the hReview related pages on the
wiki as well, and if/when you encounter areas that can be improved (like
explaining the rated tags), please note it in the hreview-feedback page:

 http://microformats.org/wiki/hreview-feedback
 http://microformats.org/wiki/hreview-faq

Thanks,

Tantek

From supercanadian at gmail.com  Fri Dec 16 09:31:22 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Fri Dec 16 09:31:29 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512160925v2d6df1cahbaefcbdf0ef863be@mail.gmail.com>
References: <84ce626f0512131619j10dcacf5i533cd890f39a508f@mail.gmail.com>
	<BFC7D3CE.65234%tantek@cs.stanford.edu>
	<84ce626f0512160925v2d6df1cahbaefcbdf0ef863be@mail.gmail.com>
Message-ID: <84ce626f0512160931p15fb2506v536b555e6f696c2f@mail.gmail.com>

Hello,

Forgot to send this to the list.

On 12/16/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello Tantek,
>
> On 12/16/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> > Charles,
> >
> > I am emailing you directly on this because it appears you have not received
> > earlier email sent on this subject.
> >
> > Regarding:
> >
> > On 12/13/05 4:19 PM, "Charles Iliya Krempeaux" <supercanadian@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> > >
> > > [...]
> > >
> > >> If you look at my weblog -- http://changelog.ca/ -- you can see a
> > >> couple XOXO lists where I list (some of) the shows I watch, and (some
> > >> of) the channels I watch.
> > >
> > > I've created a wiki page for showrolls at:
> > >
> > >   http://microformats.org/wiki/showroll-brainstorming
> >
> > and
> >
> > > Hello,
> > >
> > > I've started a page for the "show brainstorming" on the wiki.  You can
> > > get to it via:
> > >
> > >   http://microformats.org/wiki/show-brainstorming
> > >
> > >
> >
> > First, please take a closer look at the microformats process.
> >
> >  http://microformats.org/wiki/process
> >
> >
> > A few comments in particular.
> >
> > 1. Jumping straight to a *-brainstorming document is premature.  There
> > should first be a *-examples document where *real* *existing* examples of
> > the content being published on the Web are documented.
>
> The "show-brainstorming" page contained strawmen of examples I found.
> I was hesitant to give links to the examples I found because most of
> them were from Adult sites.  (Although my motivation is for non-adult
> material, adult examples are easier to find.)
>
> If people are OK with me posting links to that kind of material (for
> examples) I'll do so.  But I (perhaps wrongly) suspected they
> wouldn't.
>
> Let me know though.
>
>
>
> > Second there should
> > be a *-formats document where previous/current *formats* that attempt to
> > solve the problem are documented.  Neither of these have been created, and
> > the process page is quite clear about this.
>
> I'll admit that I should have read the process page more closely.  But
> I have been documenting what I've been seeing in the wild on the
> show-brainstorming page.  (In the section titled " Current Practice".)
>  Would it be sufficient to just move these to a page called
> "show-formats"?
>
>
> > 2. As far as I can tell, this is nothing but a link to a piece of media, in
> > particular video.  This is ignoring (since it doesn't even mention it),
> > several existing standards and microformats:
> >
> >  a. To indicate that the type of data being linked to is video, use the
> > appropriate mime type, e.g. <a type="video/mpeg" href="show.mpg">...</a>
> >
> >  b. rel-enclosure handles the "download this" semantic already.
> >
> > There is nowhere near enough justification for a new microformat for this.
>
> The motivation behind a "show microformat" is to.... (1) tell you how
> to play the media file(s).  (This is especially important when there
> is more than one file, or alternatives.)  (2) attach (more) metadata
> to the show (and not just the individual media files).  (But most
> importantly, it's about telling you how to "play" a set of media
> files.)
>
> It's not just about pre-downloading stuff.  It's more about "how to
> play it".  (If you look at some of the previous stuff I've written in
> reference to this type of thing, I mention <a>'s type attribute and
> rel-enclosure.  In fact, I did expect them to be important parts of a
> "show microformat".)
>
> > 3. AFAIK, there has been no attempt to work with this within the current
> > media-metadata or video-metadata work/research.
>
> I'm a little unclear about what you mean by this -- what you mean by
> "work within".  (Do you just mean put all this stuff on one of those 2
> pages?)  I referenced those works.  And mentioned that it should be
> used for its "metadata" work.  None of those pages seemed to say
> anything about "playing" (which is what I was trying to work on with
> the "show-brainstorming" page.)  (But perhaps "playing" information
> could be considered "metadata".  I didn't think it would be.)
>
> If you could explain this more, I'd be happy to work on this from that angle.
>
>
> > Rather than inventing a
> > new media related microformat, please first understand existing work towards
> > media microformats, and work within that research.
> >
> >   http://microformats.org/wiki/media-metadata-examples
> >
> > This has been requested several times in this thread.
>
> I never received any of those messages.  (I don't even seem them in
> the Microformats mailing list archive.)
>
> > Rather than creating new pages for a specific type of media microformat,
> > please instead work on the media-metadata-* pages.  There has been a lot of
> > thinking by a lot of smart folks put into trying to figure out
> > media-metadata (even just links), and ignoring that is blatant violation of
> > the process -- don't ignore nor reinvent earlier work.
>
> Given that what I'm trying to address is "playing" of media, do you
> still feel that I should be going at this from those pages?
>
> > I also noticed this: http://microformats.org/wiki/microshow
> >
> > 1. See above problems.
> >
> > 2. Please do not create a microformat page for something for which there
> > isn't even a strawman specification in the *-brainstorming page.  Shell
> > pages like this one will be deleted.
>
> OK.


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From supercanadian at gmail.com  Fri Dec 16 09:38:57 2005
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Fri Dec 16 09:38:59 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512160931p15fb2506v536b555e6f696c2f@mail.gmail.com>
References: <84ce626f0512131619j10dcacf5i533cd890f39a508f@mail.gmail.com>
	<BFC7D3CE.65234%tantek@cs.stanford.edu>
	<84ce626f0512160925v2d6df1cahbaefcbdf0ef863be@mail.gmail.com>
	<84ce626f0512160931p15fb2506v536b555e6f696c2f@mail.gmail.com>
Message-ID: <84ce626f0512160938t77aa01f5x98af14cd783de3a4@mail.gmail.com>

Hello Tantek,

I moved "show-brainstorming" to "show-formats" (perhaps temporarily). 
Should the info on this be perhaps merged into
"media-metadata-examples"?  (Because I'm not completely sure it would
be appropriate.  Again, I'm not sure "playing" stuff belongs on that
page or not.)

Let me know please.


See ya

On 12/16/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> Hello,
>
> Forgot to send this to the list.
>
> On 12/16/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> > Hello Tantek,
> >
> > On 12/16/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> > > Charles,
> > >
> > > I am emailing you directly on this because it appears you have not received
> > > earlier email sent on this subject.
> > >
> > > Regarding:
> > >
> > > On 12/13/05 4:19 PM, "Charles Iliya Krempeaux" <supercanadian@gmail.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
> > > >
> > > > [...]
> > > >
> > > >> If you look at my weblog -- http://changelog.ca/ -- you can see a
> > > >> couple XOXO lists where I list (some of) the shows I watch, and (some
> > > >> of) the channels I watch.
> > > >
> > > > I've created a wiki page for showrolls at:
> > > >
> > > >   http://microformats.org/wiki/showroll-brainstorming
> > >
> > > and
> > >
> > > > Hello,
> > > >
> > > > I've started a page for the "show brainstorming" on the wiki.  You can
> > > > get to it via:
> > > >
> > > >   http://microformats.org/wiki/show-brainstorming
> > > >
> > > >
> > >
> > > First, please take a closer look at the microformats process.
> > >
> > >  http://microformats.org/wiki/process
> > >
> > >
> > > A few comments in particular.
> > >
> > > 1. Jumping straight to a *-brainstorming document is premature.  There
> > > should first be a *-examples document where *real* *existing* examples of
> > > the content being published on the Web are documented.
> >
> > The "show-brainstorming" page contained strawmen of examples I found.
> > I was hesitant to give links to the examples I found because most of
> > them were from Adult sites.  (Although my motivation is for non-adult
> > material, adult examples are easier to find.)
> >
> > If people are OK with me posting links to that kind of material (for
> > examples) I'll do so.  But I (perhaps wrongly) suspected they
> > wouldn't.
> >
> > Let me know though.
> >
> >
> >
> > > Second there should
> > > be a *-formats document where previous/current *formats* that attempt to
> > > solve the problem are documented.  Neither of these have been created, and
> > > the process page is quite clear about this.
> >
> > I'll admit that I should have read the process page more closely.  But
> > I have been documenting what I've been seeing in the wild on the
> > show-brainstorming page.  (In the section titled " Current Practice".)
> >  Would it be sufficient to just move these to a page called
> > "show-formats"?
> >
> >
> > > 2. As far as I can tell, this is nothing but a link to a piece of media, in
> > > particular video.  This is ignoring (since it doesn't even mention it),
> > > several existing standards and microformats:
> > >
> > >  a. To indicate that the type of data being linked to is video, use the
> > > appropriate mime type, e.g. <a type="video/mpeg" href="show.mpg">...</a>
> > >
> > >  b. rel-enclosure handles the "download this" semantic already.
> > >
> > > There is nowhere near enough justification for a new microformat for this.
> >
> > The motivation behind a "show microformat" is to.... (1) tell you how
> > to play the media file(s).  (This is especially important when there
> > is more than one file, or alternatives.)  (2) attach (more) metadata
> > to the show (and not just the individual media files).  (But most
> > importantly, it's about telling you how to "play" a set of media
> > files.)
> >
> > It's not just about pre-downloading stuff.  It's more about "how to
> > play it".  (If you look at some of the previous stuff I've written in
> > reference to this type of thing, I mention <a>'s type attribute and
> > rel-enclosure.  In fact, I did expect them to be important parts of a
> > "show microformat".)
> >
> > > 3. AFAIK, there has been no attempt to work with this within the current
> > > media-metadata or video-metadata work/research.
> >
> > I'm a little unclear about what you mean by this -- what you mean by
> > "work within".  (Do you just mean put all this stuff on one of those 2
> > pages?)  I referenced those works.  And mentioned that it should be
> > used for its "metadata" work.  None of those pages seemed to say
> > anything about "playing" (which is what I was trying to work on with
> > the "show-brainstorming" page.)  (But perhaps "playing" information
> > could be considered "metadata".  I didn't think it would be.)
> >
> > If you could explain this more, I'd be happy to work on this from that angle.
> >
> >
> > > Rather than inventing a
> > > new media related microformat, please first understand existing work towards
> > > media microformats, and work within that research.
> > >
> > >   http://microformats.org/wiki/media-metadata-examples
> > >
> > > This has been requested several times in this thread.
> >
> > I never received any of those messages.  (I don't even seem them in
> > the Microformats mailing list archive.)
> >
> > > Rather than creating new pages for a specific type of media microformat,
> > > please instead work on the media-metadata-* pages.  There has been a lot of
> > > thinking by a lot of smart folks put into trying to figure out
> > > media-metadata (even just links), and ignoring that is blatant violation of
> > > the process -- don't ignore nor reinvent earlier work.
> >
> > Given that what I'm trying to address is "playing" of media, do you
> > still feel that I should be going at this from those pages?
> >
> > > I also noticed this: http://microformats.org/wiki/microshow
> > >
> > > 1. See above problems.
> > >
> > > 2. Please do not create a microformat page for something for which there
> > > isn't even a strawman specification in the *-brainstorming page.  Shell
> > > pages like this one will be deleted.
> >
> > OK.
>
>
> --
>     Charles Iliya Krempeaux, B.Sc.
>
>     charles @ reptile.ca
>     supercanadian @ gmail.com
>
>     developer weblog: http://ChangeLog.ca/
> ___________________________________________________________________________
>  Never forget where you came from
>


--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from
From rbach at rbach.priv.at  Fri Dec 16 11:35:30 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Dec 16 11:34:29 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>
References: <BFC6CE2B.65186%tantek@cs.stanford.edu>
	<76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>
Message-ID: <43A31702.2040001@rbach.priv.at>

Scott Reynen wrote:
> [...]
> And my first inclination would be to give imageless humans something 
> more readable by putting the machine data in the title attribute 
> instead, e.g.:
> 
> <img class="bday" src="today.png" alt="December 15, 2005" 
> title="20051215T080000Z" />
> 
> This is sending three different types of data to three different  types
> of readers.  src is for imaged humans, alt is for imageless  humans, and
> title is for machines.  I understand the drawback of  further
> complication, but the alternative seems to require authors to  choose
> between usability and microformats.

IMO it would be better to write:

<abbr class="bday" title="20051215T080000Z">
<img src="file..." alt="December 15, 2005" />
</abbr>

This way you could have
- img's src for the imaged users
- img's alt for the imageless users
- and abbr's title for users who think in 1's and 0's.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From brian.suda at gmail.com  Fri Dec 16 11:36:18 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Dec 16 11:36:43 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <43A31702.2040001@rbach.priv.at>
References: <BFC6CE2B.65186%tantek@cs.stanford.edu>	<76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>
	<43A31702.2040001@rbach.priv.at>
Message-ID: <43A31732.40807@gmail.com>

Robert Bachmann wrote:

>Scott Reynen wrote:
>  
>
>>[...]
>>And my first inclination would be to give imageless humans something 
>>more readable by putting the machine data in the title attribute 
>>instead, e.g.:
>>
>><img class="bday" src="today.png" alt="December 15, 2005" 
>>title="20051215T080000Z" />
>>
>>This is sending three different types of data to three different  types
>>of readers.  src is for imaged humans, alt is for imageless  humans, and
>>title is for machines.  I understand the drawback of  further
>>complication, but the alternative seems to require authors to  choose
>>between usability and microformats.
>>    
>>
>
>IMO it would be better to write:
>
><abbr class="bday" title="20051215T080000Z">
><img src="file..." alt="December 15, 2005" />
></abbr>
>
>This way you could have
>- img's src for the imaged users
>- img's alt for the imageless users
>- and abbr's title for users who think in 1's and 0's.
>
>Robert
>  
>
wouldn't that imply that ABBR is the abberviation of the IMG and not the
IMG alt? maybe that is one and the same thing?

-brian
From davidjanes at blogmatrix.com  Fri Dec 16 11:39:26 2005
From: davidjanes at blogmatrix.com (David Janes)
Date: Fri Dec 16 11:39:30 2005
Subject: [uf-discuss] FYI: Firefox Scholar (aka SmartFox)
Message-ID: <011201c60278$6cc097d0$6501a8c0@JOANNELAPTOP>

Firefox Scholar [1] sounds like something that is microformat based. Does 
anyone have any further information? For an open source project university 
directed project, they look like they're operating pretty dark.

Regards, etc...
David

[1] 
http://echo.gmu.edu/toolcenter-wiki/index.php?title=Firefox_Scholar_(aka_SmartFox) 

From qidydl at gmail.com  Fri Dec 16 11:58:21 2005
From: qidydl at gmail.com (David Osolkowski)
Date: Fri Dec 16 11:58:23 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <43A31732.40807@gmail.com>
References: <BFC6CE2B.65186%tantek@cs.stanford.edu>
	<76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>
	<43A31702.2040001@rbach.priv.at> <43A31732.40807@gmail.com>
Message-ID: <ee0909a60512161158s230b96f7oe784729ac65474c@mail.gmail.com>

On 12/16/05, brian suda <brian.suda@gmail.com> wrote:
>
> wouldn't that imply that ABBR is the abberviation of the IMG and not the
> IMG alt? maybe that is one and the same thing?


I believe the alt attribute is intended to serve as an equivalent
replacement for the image for users that are unable to view the image.
Thus, an abbreviation of the image should be equivalent to an abbreviation
of the alt text.  It may be a bit strange but I think it is both correct and
workable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051216/3621fb75/attachment.htm
From chudley at gmail.com  Fri Dec 16 12:22:24 2005
From: chudley at gmail.com (C. Hudley)
Date: Fri Dec 16 12:22:26 2005
Subject: [uf-discuss] FYI: Firefox Scholar (aka SmartFox)
In-Reply-To: <011201c60278$6cc097d0$6501a8c0@JOANNELAPTOP>
References: <011201c60278$6cc097d0$6501a8c0@JOANNELAPTOP>
Message-ID: <e28976dd0512161222y6e0813d1v8c8e7d60e532efb2@mail.gmail.com>

On 12/16/05, David Janes <davidjanes@blogmatrix.com> wrote:
> Firefox Scholar [1] sounds like something that is microformat based. Does
> anyone have any further information? For an open source project university
> directed project, they look like they're operating pretty dark.

One of the folks on that project recently visited here.  They delayed
the start of their grant several months due to some unexpected new
work needing immediate attention.  They will be getting started in
earnest after the start of the new year, and expect to have something
release-worthy by summer, if I'm remembering correctly.


--
C. Hudley
We Know The Truth, Inc.
From fantasai.lists at inkedblade.net  Sat Dec 17 10:12:25 2005
From: fantasai.lists at inkedblade.net (fantasai)
Date: Sat Dec 17 10:12:34 2005
Subject: [uf-discuss] RFC: Using <img>'s alt attribute for Microformats
In-Reply-To: <43A31732.40807@gmail.com>
References: <BFC6CE2B.65186%tantek@cs.stanford.edu>	<76ECC3BB-781B-497D-A699-AAEE39435C53@randomchaos.com>	<43A31702.2040001@rbach.priv.at>
	<43A31732.40807@gmail.com>
Message-ID: <43A45509.30009@inkedblade.net>

brian suda wrote:
> Robert Bachmann wrote:
> 
>>IMO it would be better to write:
>>
>><abbr class="bday" title="20051215T080000Z">
>><img src="file..." alt="December 15, 2005" />
>></abbr>
>>
>>This way you could have
>>- img's src for the imaged users
>>- img's alt for the imageless users
>>- and abbr's title for users who think in 1's and 0's.

I agree that that's the right way to do it.

> wouldn't that imply that ABBR is the abberviation of the IMG and not the
> IMG alt? maybe that is one and the same thing?

No, that implies that the image is an abbreviation of the <abbr>
tag's title attribute, i.e. is an abbreviation for 20051215T080000Z.

~fantasai
From tantek at cs.stanford.edu  Sat Dec 17 14:12:50 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Dec 17 14:13:25 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512160938t77aa01f5x98af14cd783de3a4@mail.gmail.com>
Message-ID: <BFC9CD5F.65323%tantek@cs.stanford.edu>

On 12/16/05 9:38 AM, "Charles Iliya Krempeaux" <supercanadian@gmail.com>
wrote:

> Hello Tantek,
> 
> I moved "show-brainstorming" to "show-formats" (perhaps temporarily).
> Should the info on this be perhaps merged into
> "media-metadata-examples"?  (Because I'm not completely sure it would
> be appropriate.  Again, I'm not sure "playing" stuff belongs on that
> page or not.)

Hi Charles,

I see that you have started moving things into the media-metadata-examples
page, and helping cleaning things up.

As to the question of whether shows and media are the same or not, I think
there are some broad areas of media metadata that can be separated into
(hopefully) smaller problems to be solved.

1. Media themselves images, audio, video (.png, .mp3, .mov)
2. The info about the media (author, title, length, license etc.)
3. A list of media, song playlist, showlist etc.

(1) is pretty clearly outside the domain of microformats.  Often (1) embeds
portions of (2).

(2) is I think the right thing to focus on.

(3) has some specific efforts/formats (e.g. XSPF, .m3u etc.), but I think is
a different problem than specifying the information about just one item.

2 and 3 are definitely different once you take a look at how people publish
each on the web today, and that's why we require first research and
documenting existing examples on the web, before looking at formats or
proposals (strawman or not).

I noticed you started putting in (3) into the table about (2) on the
media-metadata-examples page.  I strongly recommend creating a new
comparison table for how people represent lists of media items.

Part of the problem right now is that the media-metadata-examples page is a
mess (mostly because I think when it was started, someone confused
"examples" with "formats", or perhaps they thought it was supposed to show
examples of formats, which is not what examples means.), and needs a lot of
clean up, rearranging, and probably breaking into multiple pages for
different purposes.

This feels like something that might be better discussed on IRC.

Anyone up for this?  Perhaps some of the contributors listed on the
media-metadata-examples page?  Jump into IRC and lets figure this out.

irc:irc.freenode.net#microformats

Thanks,

Tantek

From tantek at cs.stanford.edu  Sat Dec 17 14:32:51 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Dec 17 14:33:21 2005
Subject: [uf-discuss] Show Microformat Brainstorming
In-Reply-To: <84ce626f0512160931p15fb2506v536b555e6f696c2f@mail.gmail.com>
Message-ID: <BFC9D1C8.65329%tantek@cs.stanford.edu>

On 12/16/05 9:31 AM, "Charles Iliya Krempeaux" <supercanadian@gmail.com>
wrote:

> On 12/16/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
>> Hello Tantek,
>> 
>> On 12/16/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
>>> Charles,
>>> 
>>> I am emailing you directly on this because it appears you have not received
>>> earlier email sent on this subject.
>>> 
>>> Regarding:
>>> 
>>> On 12/13/05 4:19 PM, "Charles Iliya Krempeaux" <supercanadian@gmail.com>
>>> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> On 12/6/05, Charles Iliya Krempeaux <supercanadian@gmail.com> wrote:
>>>> 
>>>> [...]
>>>> 
>>>>> If you look at my weblog -- http://changelog.ca/ -- you can see a
>>>>> couple XOXO lists where I list (some of) the shows I watch, and (some
>>>>> of) the channels I watch.
>>>> 
>>>> I've created a wiki page for showrolls at:
>>>> 
>>>>   http://microformats.org/wiki/showroll-brainstorming
>>> 
>>> and
>>> 
>>>> Hello,
>>>> 
>>>> I've started a page for the "show brainstorming" on the wiki.  You can
>>>> get to it via:
>>>> 
>>>>   http://microformats.org/wiki/show-brainstorming
>>>> 
>>>> 
>>> 
>>> First, please take a closer look at the microformats process.
>>> 
>>>  http://microformats.org/wiki/process
>>> 
>>> 
>>> A few comments in particular.
>>> 
>>> 1. Jumping straight to a *-brainstorming document is premature.  There
>>> should first be a *-examples document where *real* *existing* examples of
>>> the content being published on the Web are documented.
>> 
>> The "show-brainstorming" page contained strawmen of examples I found.

First of all, examples are not strawmen.  We need to be VERY clear about
this.

Examples are *actual* examples you have found on the Web.  With URL to the
example so that others can verify that it is a *real* example not a
*theoretical* example.


>> I was hesitant to give links to the examples I found because most of
>> them were from Adult sites.  (Although my motivation is for non-adult
>> material, adult examples are easier to find.)

I'm confident that you can find sufficient non-Adult examples so let's focus
on those so we can have links.


>> If people are OK with me posting links to that kind of material (for
>> examples) I'll do so.  But I (perhaps wrongly) suspected they
>> wouldn't.
>>
>> Let me know though.
>> 

I think your guess makes sense.  There is a broad variety of folks working
on microformats, and there's just less to worry about if we keep it kid-safe
/ work-safe.



>>> Second there should
>>> be a *-formats document where previous/current *formats* that attempt to
>>> solve the problem are documented.  Neither of these have been created, and
>>> the process page is quite clear about this.
>> 
>> I'll admit that I should have read the process page more closely.  But
>> I have been documenting what I've been seeing in the wild on the
>> show-brainstorming page.  (In the section titled " Current Practice".)
>>  Would it be sufficient to just move these to a page called
>> "show-formats"?

Yes, except that there is the larger problem that "shows" are just one type
of media, and there is a lot of overlap.  It's not clear that there should
be something special just for "shows".


>>> 2. As far as I can tell, this is nothing but a link to a piece of media, in
>>> particular video.  This is ignoring (since it doesn't even mention it),
>>> several existing standards and microformats:
>>> 
>>>  a. To indicate that the type of data being linked to is video, use the
>>> appropriate mime type, e.g. <a type="video/mpeg" href="show.mpg">...</a>
>>> 
>>>  b. rel-enclosure handles the "download this" semantic already.
>>> 
>>> There is nowhere near enough justification for a new microformat for this.
>> 
>> The motivation behind a "show microformat" is to.... (1) tell you how
>> to play the media file(s).  (This is especially important when there
>> is more than one file, or alternatives.)  (2) attach (more) metadata
>> to the show (and not just the individual media files).  (But most
>> importantly, it's about telling you how to "play" a set of media
>> files.)

That "play a set" is very different from just information about one media
item.


>> It's not just about pre-downloading stuff.  It's more about "how to
>> play it".  (If you look at some of the previous stuff I've written in
>> reference to this type of thing, I mention <a>'s type attribute and
>> rel-enclosure.  In fact, I did expect them to be important parts of a
>> "show microformat".)

Ok.


>>> 3. AFAIK, there has been no attempt to work with this within the current
>>> media-metadata or video-metadata work/research.
>> 
>> I'm a little unclear about what you mean by this -- what you mean by
>> "work within".  (Do you just mean put all this stuff on one of those 2
>> pages?)

I mean that there is a lot of overlap, and rather than creating pages that
solve a slightly different problem, it makes more sense to figure out how
your work fits into the existing work.  This is not always easy, but the
alternative is that everybody creates their own slightly different page to
work on their own slightly different microformat which is much worse.


>> I referenced those works.  And mentioned that it should be
>> used for its "metadata" work.  None of those pages seemed to say
>> anything about "playing" (which is what I was trying to work on with
>> the "show-brainstorming" page.)  (But perhaps "playing" information
>> could be considered "metadata".  I didn't think it would be.)

"playing" information could even be considered different from the list of
things to play.

For example, you might have a list, and you might have shuffle vs. once in
order, vs. repeat etc.


>>> Rather than inventing a
>>> new media related microformat, please first understand existing work towards
>>> media microformats, and work within that research.
>>> 
>>>   http://microformats.org/wiki/media-metadata-examples
>>> 
>>> This has been requested several times in this thread.
>> 
>> I never received any of those messages.  (I don't even seem them in
>> the Microformats mailing list archive.)

Hmm... Look for previous emails in the archive with "Show Microformat
Brainstorming" in the subject. There were quite a few.


>>> Rather than creating new pages for a specific type of media microformat,
>>> please instead work on the media-metadata-* pages.  There has been a lot of
>>> thinking by a lot of smart folks put into trying to figure out
>>> media-metadata (even just links), and ignoring that is blatant violation of
>>> the process -- don't ignore nor reinvent earlier work.
>> 
>> Given that what I'm trying to address is "playing" of media, do you
>> still feel that I should be going at this from those pages?

Yes.  At a minimum, they are sufficiently related that you should be making
sure they both make sense together.

Initially your examples looked more like media metadata than something about
"playing".

As pointed out in the previous message, we (all of us interested in media
related microformats) need to clean up the media-metadata-examples page.  If
you put your name on the contributors list, please jump in and help.  Worst
comes to worst, I can try reformatting/reorganizing it like other
microformats' pages.

Thanks,

Tantek

From benjamincarlyle at optusnet.com.au  Sat Dec 17 22:36:21 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Sat Dec 17 22:35:49 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <43843033.4080802@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>
Message-ID: <1134887782.6650.4.camel@tori>

Hello,

On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
> Have at it:
> http://microformats.org/wiki/hatom

I'm not sure if this has been discussed already, but hAtom and hCalendar
both contain a "summary" element. I have my blog formatted for hAtom,
and some entries contain hCalendar data. I have a "content" node but no
"summary" node in my entries, and when the almost universal microformat
parser[1] reads my site it takes the hCalandar summary as my hAtom
summary.

What is the correct behaviour, here?

For an example, see [2]. Look for the Newsletter 2005 entry.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
[1] http://www.trinityanne.com/tools/extract/
[2] http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%
2Fmembers.optusnet.com.au%2Fbenjamincarlyle%2Fbenjamin%2Fblog%
2F&microformat=hatom&submit=Submit

From davidjanes at blogmatrix.com  Sun Dec 18 03:10:49 2005
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Dec 18 03:10:52 2005
Subject: [uf-discuss] hAtom draft
References: <43843033.4080802@blogmatrix.com> <1134887782.6650.4.camel@tori>
Message-ID: <010801c603c3$b3fa9e10$6501a8c0@JOANNELAPTOP>

It was a bug in the Almost Universal Microformat Parser. hatom:content, 
hatom:summary, hatom:contributor and hatom:author are all "opaque", meaning 
that searching for further hAtom content within that element should stop 
[1], exactly for this sort of situation. I've fixed it and posted the result 
[2].

Thanks for trying it out and finding this.

Regards, etc...
David

[1] http://microformats.org/wiki/hatom#Nesting_Rules
[2] http://tinyurl.com/a7uex

----- Original Message ----- 
From: "Benjamin Carlyle" <benjamincarlyle@optusnet.com.au>
To: "Microformats Discuss" <microformats-discuss@microformats.org>
Sent: Sunday, December 18, 2005 1:36 AM
Subject: Re: [uf-discuss] hAtom draft


> Hello,
>
> On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
>> Have at it:
>> http://microformats.org/wiki/hatom
>
> I'm not sure if this has been discussed already, but hAtom and hCalendar
> both contain a "summary" element. I have my blog formatted for hAtom,
> and some entries contain hCalendar data. I have a "content" node but no
> "summary" node in my entries, and when the almost universal microformat
> parser[1] reads my site it takes the hCalandar summary as my hAtom
> summary.
>
> What is the correct behaviour, here?
>
> For an example, see [2]. Look for the Newsletter 2005 entry.
>
> -- 
> Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
> [1] http://www.trinityanne.com/tools/extract/
> [2] http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%
> 2Fmembers.optusnet.com.au%2Fbenjamincarlyle%2Fbenjamin%2Fblog%
> 2F&microformat=hatom&submit=Submit
>
> 
From benjamincarlyle at optusnet.com.au  Sun Dec 18 06:49:34 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Sun Dec 18 06:49:10 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <010801c603c3$b3fa9e10$6501a8c0@JOANNELAPTOP>
References: <43843033.4080802@blogmatrix.com> <1134887782.6650.4.camel@tori>
	<010801c603c3$b3fa9e10$6501a8c0@JOANNELAPTOP>
Message-ID: <1134917376.5553.30.camel@tori>

On Sun, 2005-12-18 at 06:10 -0500, David Janes wrote:
> It was a bug in the Almost Universal Microformat Parser. hatom:content, 
> hatom:summary, hatom:contributor and hatom:author are all "opaque", meaning 
> that searching for further hAtom content within that element should stop 
> [1], exactly for this sort of situation. I've fixed it and posted the result 
> [2].
> Thanks for trying it out and finding this.

My pleasure :)
I like to pass my metadata through a parser whenever possible to make
sure my understanding of what I'm telling my readers is in fact what I
am telling them.

Does the parser currently support the hatom concept of placing a hcard
on the page as a substitute for the author field of each entry?

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From davidjanes at blogmatrix.com  Sun Dec 18 08:14:29 2005
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Dec 18 08:14:31 2005
Subject: [uf-discuss] hAtom draft
References: <43843033.4080802@blogmatrix.com>
	<1134887782.6650.4.camel@tori><010801c603c3$b3fa9e10$6501a8c0@JOANNELAPTOP>
	<1134917376.5553.30.camel@tori>
Message-ID: <011901c603ee$2028ea90$6501a8c0@JOANNELAPTOP>

Yes. In fact, it converts non-hCards into a simple FN-only one to gain N 
parsing.

Regards, etc...
David

----- Original Message ----- 
From: "Benjamin Carlyle" <benjamincarlyle@optusnet.com.au>
Sent: Sunday, December 18, 2005 9:49 AM
Subject: Re: [uf-discuss] hAtom draft

> Does the parser currently support the hatom concept of placing a hcard
> on the page as a substitute for the author field of each entry?

From drernie at opendarwin.org  Mon Dec 19 10:04:06 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Mon Dec 19 10:04:10 2005
Subject: [uf-discuss] Newspaper XML format?
References: <200512191716.jBJHGWEi023272@alox.afp.com>
Message-ID: <DB182AB3-35C0-4994-B60E-B1965DCE8C06@opendarwin.org>

Hi all,

I ran across this on the atom list, and wanted to pass it along in  
case anybody was working on a "newspaper" markup format.  I suspect  
that this should ultimately be built around hAtom, but I'm not sure  
where (if anywhere) in belongs on the current wiki.  They also seem  
interested in RDF and the Semantic Web; anybody want to talk to them  
about semantic HTML?

-- Ernie P.

http://www.iptc.org/dev
The IPTC NewsML2 Architecture WP is very happy to announce that the  
www.iptc.org/dev site has been updated.

  Here you will find:

-          a document introducing the current experimental phase  
(new!). The first part target IT management, and the second part  
targets implementers.

-          an updated NAR Model draft document (v12)

-          an updated Technical Specification draft document (v18)

-          a Glossary document (new!, v1)

-          a set of W3C XML schemas (new!, XSD format, v0.6)

-          a NewsML2 -> RDF N-triples XSLT transform (new!, v1)



All these resources are provided in order to help users test NewsML2  
in its draft form.

  It is now time for experimentation. Tests and feed-back on the  
current documentation and schemata would be highly appreciated from  
the news community.

Note: in order to access the XSD schema and contributions, you need  
to download this package.

After download, please drop the file in a ?root? directory and unzip  
it: this will create a directory tree, with ?IPTC? at the top.

  The ?IPTC/NAR/1.0? subfolder contains itself 4 folders:

-          ?specification? contains the Model, the TechSpec, the set  
of XML schemas and test samples (used to check the schema; better  
samples will come soon).

-          ?documentation? contains the Glossary plus the  
introduction to the current experimental phase.

-          ?contribution? contains the NewsML2 -> RDF N-triples XSLT  
transform.

-          ?examples?: we will provide samples asap.



We hope that you will find it useful.



Laurent Le Meur

IPTC NewsML Architecture WP chair

AFP Medialab, manager
From pp at myelin.co.nz  Mon Dec 19 19:32:02 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Mon Dec 19 19:32:11 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for books
 in a library catalog
In-Reply-To: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
Message-ID: <43A77B32.7030302@myelin.co.nz>

This would probably make more sense over on the microformats-discuss 
list.  Edward - visit 
http://microformats.org/mailman/listinfo/microformats-discuss/ to join.  
I'm crossposting this over there in case this is a solved problem already...

There are a bunch of links about encoding MARC data in SGML/XML here:

    http://xml.coverpages.org/marc.html

Here's the official schema:

    http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd

There are examples at:

    http://www.loc.gov/standards/marcxml/

It looks like MARCXML is pretty cryptic.  The MODS or Dublin Core 
transformations might work better as a microformat:

    http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml
    http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml

Cheers,
Phil

Edward Vielmetti wrote:

>I'm looking for suggestions for a microformat
>suitable to recommend to my library which
>produces an RSS feed as a result set for
>a search through its library catalog.
>
>hReview isn't quite right, and there's a lot
>of potentially useful book metadata that
>comes from a standard format (US-MARC)
>and should be straightforward to map in.
>  
>

From benjamincarlyle at optusnet.com.au  Mon Dec 19 20:31:32 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Mon Dec 19 20:31:03 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <43A77B32.7030302@myelin.co.nz>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
	<43A77B32.7030302@myelin.co.nz>
Message-ID: <1135053094.6203.15.camel@tori>

On Tue, 2005-12-20 at 16:32 +1300, Phillip Pearson wrote:
> This would probably make more sense over on the microformats-discuss 
> list.  Edward - visit 
> http://microformats.org/mailman/listinfo/microformats-discuss/ to join.  
> Edward Vielmetti wrote:
> >I'm looking for suggestions for a microformat
> >suitable to recommend to my library which
> >produces an RSS feed as a result set for
> >a search through its library catalog.
> >hReview isn't quite right, and there's a lot
> >of potentially useful book metadata that
> >comes from a standard format (US-MARC)
> >and should be straightforward to map in.

MARC is also the name of what we use in Australia, especially in
academic libraries. My spouse works in this field, but isn't sure if the
encoding is the same as US MARC or not. According to wikipedia[1], it is
US MARC.

In the primary school library where she currently works, she makes
extensive use of the scis[2] database. This is a subscriber-only system
that allows users to search for already-catalogued works so that they
can avoid doing the original cataloguing over again. The user enters
ISBNs for those works that have them, and SCIS numbers that need to be
searched for when items do not have an ISBN. The list of ISBN and SCIS
numbers is entered into a dialogue, and a usmarc.dat file is produced
for download. This file is imported into the local library system, and
bob's your uncle.

Interestingly, this isn't an XML MARC. It is still the original system,
which looks something like this:
00741nam  2200265 a
4500001000800000005001700008007000300025008004100028020001500069040000900084082002000093100001600113245004100129260003900170300002300209440002500232440003800257500004100295500001400336650002200350650002200372650002700394650002700421650002700448105068920010622154425.0ta010622s2000    at           |000 0 eng d  a1862830517  aW.A.14a796.5bGRA2a131 aGrant, Jim.10aEveryone likes ....

It seems likely that any microformatted MARC would have to be able to be
translated back to this version for import to local tools in order to be
useful.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
[1] http://en.wikipedia.org/wiki/MARC_21
[2] http://www.curriculum.edu.au/scis/

From edward.vielmetti at gmail.com  Mon Dec 19 20:37:54 2005
From: edward.vielmetti at gmail.com (Edward Vielmetti)
Date: Mon Dec 19 20:37:56 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <1135053094.6203.15.camel@tori>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
	<43A77B32.7030302@myelin.co.nz> <1135053094.6203.15.camel@tori>
Message-ID: <343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>

Thanks Benjamin.  I'm actually not after an XML-coded
raw MARC format, let me explain the use case a little
better.

Our library has RSS feeds for all sorts of patron searches
through the catalog (note "patron", not "cataloger").  I'm
aiming for a microformat to mark up that RSS so that
a minimally smart reader or application can pull out
fields and do something useful with them.

The intended use can be envisaged by looking at this
posting:

http://vielmetti.typepad.com/vacuum/2005/12/duckytool_searc.html

showing a command-line library search tool, and

http://vielmetti.typepad.com/vacuum/2005/12/a_design_for_a_.html

with a design for an IM library bot that would read a microformatted
RSS feed and transform queries into appropriate responses.

thanks

Ed

On 12/19/05, Benjamin Carlyle <benjamincarlyle@optusnet.com.au> wrote:
> On Tue, 2005-12-20 at 16:32 +1300, Phillip Pearson wrote:
> > This would probably make more sense over on the microformats-discuss
> > list.  Edward - visit
> > http://microformats.org/mailman/listinfo/microformats-discuss/ to join.
> > Edward Vielmetti wrote:
> > >I'm looking for suggestions for a microformat
> > >suitable to recommend to my library which
> > >produces an RSS feed as a result set for
> > >a search through its library catalog.
> > >hReview isn't quite right, and there's a lot
> > >of potentially useful book metadata that
> > >comes from a standard format (US-MARC)
> > >and should be straightforward to map in.
>
> MARC is also the name of what we use in Australia, especially in
> academic libraries. My spouse works in this field, but isn't sure if the
> encoding is the same as US MARC or not. According to wikipedia[1], it is
> US MARC.
>
> In the primary school library where she currently works, she makes
> extensive use of the scis[2] database. This is a subscriber-only system
> that allows users to search for already-catalogued works so that they
> can avoid doing the original cataloguing over again. The user enters
> ISBNs for those works that have them, and SCIS numbers that need to be
> searched for when items do not have an ISBN. The list of ISBN and SCIS
> numbers is entered into a dialogue, and a usmarc.dat file is produced
> for download. This file is imported into the local library system, and
> bob's your uncle.
>
> Interestingly, this isn't an XML MARC. It is still the original system,
> which looks something like this:
> 00741nam  2200265 a
> 4500001000800000005001700008007000300025008004100028020001500069040000900084082002000093100001600113245004100129260003900170300002300209440002500232440003800257500004100295500001400336650002200350650002200372650002700394650002700421650002700448
1050689
20010622154425.0
ta
010622s2000    at           |000 0 eng d
  a1862830517
  aW.A.
14a796.5bGRA2a13
1 aGrant, Jim.
10aEveryone likes ....
>
> It seems likely that any microformatted MARC would have to be able to be
> translated back to this version for import to local tools in order to be
> useful.
>
> --
> Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
> [1] http://en.wikipedia.org/wiki/MARC_21
> [2] http://www.curriculum.edu.au/scis/
>
>


--
Edward Vielmetti in Ann Arbor, MI 48104
+1 734 276 5910

edward.vielmetti@gmail.com
http://www.vacuumgroup.com
From pp at myelin.co.nz  Mon Dec 19 21:21:37 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Mon Dec 19 21:21:42 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>	<43A77B32.7030302@myelin.co.nz>
	<1135053094.6203.15.camel@tori>
	<343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
Message-ID: <43A794E1.4020904@myelin.co.nz>

If it's not important to look like MARC data, take a look at the MODS 
and Dublin Core transformations, which are more human-friendly 
representations of this sort of data:

   http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml
   http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml

Perhaps the example could look something like this in XHTML:

<div class="book" lang="en">
  <h3 class="fn">Arithmetic /</h3>
  <p>By <span class="creator"><span class="fn">Sandburg, Carl</span>, 
<span class="date">1878-1967</span></span>, and <span 
class="illustrator">Rand, Ted</span></p>
  <p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace 
Jovanovich</span>, <span class="locality">San Diego</span></span></p>
  <p>Published: <span class="issued">1993</span></p>
  <p class="description">A poem about numbers and their characteristics. 
Features anamorphic, or distorted, drawings which can be restored to 
normal by viewing from a particular angle or by viewing the image's 
reflection in the provided Mylar cone.</p>
  <p class="note">One Mylar sheet included in pocket.</p>
  <p>Subjects:</p>
  <ul>
    <li class="subject">Arithmetic</li>
    <li class="subject">Children's poetry, American.</li>
    <li class="subject">Arithmetic</li>
    <li class="subject">American poetry</li>
    <li class="subject">Visual perception</li>
  </ul>
</div>

Cheers,
Phil

Edward Vielmetti wrote:

>Thanks Benjamin.  I'm actually not after an XML-coded
>raw MARC format, let me explain the use case a little
>better.
>
>Our library has RSS feeds for all sorts of patron searches
>through the catalog (note "patron", not "cataloger").  I'm
>aiming for a microformat to mark up that RSS so that
>a minimally smart reader or application can pull out
>fields and do something useful with them.
>
>The intended use can be envisaged by looking at this
>posting:
>
>http://vielmetti.typepad.com/vacuum/2005/12/duckytool_searc.html
>
>showing a command-line library search tool, and
>
>http://vielmetti.typepad.com/vacuum/2005/12/a_design_for_a_.html
>
>with a design for an IM library bot that would read a microformatted
>RSS feed and transform queries into appropriate responses.
>
>thanks
>
>Ed
>
>On 12/19/05, Benjamin Carlyle <benjamincarlyle@optusnet.com.au> wrote:
>  
>
>>On Tue, 2005-12-20 at 16:32 +1300, Phillip Pearson wrote:
>>    
>>
>>>This would probably make more sense over on the microformats-discuss
>>>list.  Edward - visit
>>>http://microformats.org/mailman/listinfo/microformats-discuss/ to join.
>>>Edward Vielmetti wrote:
>>>      
>>>
>>>>I'm looking for suggestions for a microformat
>>>>suitable to recommend to my library which
>>>>produces an RSS feed as a result set for
>>>>a search through its library catalog.
>>>>hReview isn't quite right, and there's a lot
>>>>of potentially useful book metadata that
>>>>comes from a standard format (US-MARC)
>>>>and should be straightforward to map in.
>>>>        
>>>>
>>MARC is also the name of what we use in Australia, especially in
>>academic libraries. My spouse works in this field, but isn't sure if the
>>encoding is the same as US MARC or not. According to wikipedia[1], it is
>>US MARC.
>>
>>In the primary school library where she currently works, she makes
>>extensive use of the scis[2] database. This is a subscriber-only system
>>that allows users to search for already-catalogued works so that they
>>can avoid doing the original cataloguing over again. The user enters
>>ISBNs for those works that have them, and SCIS numbers that need to be
>>searched for when items do not have an ISBN. The list of ISBN and SCIS
>>numbers is entered into a dialogue, and a usmarc.dat file is produced
>>for download. This file is imported into the local library system, and
>>bob's your uncle.
>>
>>Interestingly, this isn't an XML MARC. It is still the original system,
>>which looks something like this:
>>00741nam  2200265 a
>>4500001000800000005001700008007000300025008004100028020001500069040000900084082002000093100001600113245004100129260003900170300002300209440002500232440003800257500004100295500001400336650002200350650002200372650002700394650002700421650002700448
1050689
20010622154425.0
ta
010622s2000    at           |000 0 eng d
  a1862830517
  aW.A.
14a796.5bGRA2a13
1 aGrant, Jim.
10aEveryone likes ....
>>
>>It seems likely that any microformatted MARC would have to be able to be
>>translated back to this version for import to local tools in order to be
>>useful.
>>
>>--
>>Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
>>[1] http://en.wikipedia.org/wiki/MARC_21
>>[2] http://www.curriculum.edu.au/scis/
>>
>>
>>    
>>
>
>
>--
>Edward Vielmetti in Ann Arbor, MI 48104
>+1 734 276 5910
>
>edward.vielmetti@gmail.com
>http://www.vacuumgroup.com
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>  
>

From ehs at pobox.com  Mon Dec 19 21:23:54 2005
From: ehs at pobox.com (Edward Summers)
Date: Mon Dec 19 21:23:58 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
	<43A77B32.7030302@myelin.co.nz> <1135053094.6203.15.camel@tori>
	<343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
Message-ID: <31EEEF81-3E96-4F13-96D1-81F91964664C@pobox.com>

We've actually been throwing around some of these on the wiki:
	
	http://microformats.org/wiki/cite
	http://microformats.org/wiki/cite-brainstorming
	http://microformats.org/wiki/cite-examples

MARC, or MARC21 as it is known after the harmonization of USMARC and  
CAN/MARC is a nasty old format from the early 1970s, and not at all  
suited to being represented as semantic HTML imho. MODS [1] is a  
reworking of MARC with more meaningful element names and an XML  
syntax--but it is still relatively complicated, largely because it's  
an outgrowth of MARC itself.

There is quite a bit of interest in the library community in getting  
a microformat established for citations. Given its deployment in  
libraries around the world I think that the xml encoding for openurl  
[2] represents a well trodden path for encoding citation data in  
HTML. It also could lend itself to some really interesting remixing  
in blogs where browser extensions extract citations and fire them off  
at licensed library databases, your local public library, amazon, a  
citation manager, etc.

If there is interest I think we could knock out a draft citation  
microformat using the key/encoded-value names from openurl [3] in  
fairly short order.

//Ed (another)

[1] http://www.loc.gov/standards/mods/
[2] http://www.niso.org/committees/committee_ax.html
[3] http://alcme.oclc.org/openurl/servlet/OAIHandler? 
verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats
From ehs at pobox.com  Mon Dec 19 21:27:38 2005
From: ehs at pobox.com (Edward Summers)
Date: Mon Dec 19 21:27:40 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <43A794E1.4020904@myelin.co.nz>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>	<43A77B32.7030302@myelin.co.nz>
	<1135053094.6203.15.camel@tori>
	<343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
	<43A794E1.4020904@myelin.co.nz>
Message-ID: <6E63FFBD-E9EC-4774-B5A7-4F8037EF5027@pobox.com>

On Dec 19, 2005, at 11:21 PM, Phillip Pearson wrote:
> Perhaps the example could look something like this in XHTML:
>
> <div class="book" lang="en">
>  <h3 class="fn">Arithmetic /</h3>
>  <p>By <span class="creator"><span class="fn">Sandburg, Carl</ 
> span>, <span class="date">1878-1967</span></span>, and <span  
> class="illustrator">Rand, Ted</span></p>
>  <p>Publisher: <span class="publisher"><span class="fn">Harcourt  
> Brace Jovanovich</span>, <span class="locality">San Diego</span></ 
> span></p>
>  <p>Published: <span class="issued">1993</span></p>
>  <p class="description">A poem about numbers and their  
> characteristics. Features anamorphic, or distorted, drawings which  
> can be restored to normal by viewing from a particular angle or by  
> viewing the image's reflection in the provided Mylar cone.</p>
>  <p class="note">One Mylar sheet included in pocket.</p>
>  <p>Subjects:</p>
>  <ul>
>    <li class="subject">Arithmetic</li>
>    <li class="subject">Children's poetry, American.</li>
>    <li class="subject">Arithmetic</li>
>    <li class="subject">American poetry</li>
>    <li class="subject">Visual perception</li>
>  </ul>
> </div>

It would be nice to have this on the wiki somewhere, perhaps on the  
http://microformats.org/wiki/cite-brainstorming ?

//Ed
From pp at myelin.co.nz  Mon Dec 19 22:48:55 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Mon Dec 19 22:49:00 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <6E63FFBD-E9EC-4774-B5A7-4F8037EF5027@pobox.com>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>	<43A77B32.7030302@myelin.co.nz>	<1135053094.6203.15.camel@tori>	<343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>	<43A794E1.4020904@myelin.co.nz>
	<6E63FFBD-E9EC-4774-B5A7-4F8037EF5027@pobox.com>
Message-ID: <43A7A957.2090700@myelin.co.nz>

Edward Summers wrote:

>> Perhaps the example could look something like this in XHTML:
>>
>> [...]
>
> It would be nice to have this on the wiki somewhere, perhaps on the  
> http://microformats.org/wiki/cite-brainstorming ?

Sure - I've added it, and the example links, to the bottom of that page.

Cheers,
Phil
From benjamincarlyle at optusnet.com.au  Tue Dec 20 07:22:50 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Tue Dec 20 07:22:15 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <31EEEF81-3E96-4F13-96D1-81F91964664C@pobox.com>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
	<43A77B32.7030302@myelin.co.nz> <1135053094.6203.15.camel@tori>
	<343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
	<31EEEF81-3E96-4F13-96D1-81F91964664C@pobox.com>
Message-ID: <1135092172.6204.24.camel@tori>

On Mon, 2005-12-19 at 23:23 -0600, Edward Summers wrote:
> We've actually been throwing around some of these on the wiki:
> 	http://microformats.org/wiki/cite
> 	http://microformats.org/wiki/cite-brainstorming
> 	http://microformats.org/wiki/cite-examples
> MARC, or MARC21 as it is known after the harmonization of USMARC and  
> CAN/MARC is a nasty old format from the early 1970s, and not at all  
> suited to being represented as semantic HTML imho. MODS [1] is a  
> reworking of MARC with more meaningful element names and an XML  
> syntax--but it is still relatively complicated, largely because it's  
> an outgrowth of MARC itself.

MARC is typically used for cataloging rather than citation. It is the
electronic equivalent to a paper card catalogue in your local library.
Cataloging and citation are targeted at slightly different audiences.
Citation is targetted at an audience who wants to follow a kind of
hyperlink from one place to another. The emphasis is on providing enough
information to know where to look and to recognise it when you find it.
Cataloging is intended for the reference librarian audience, where you
know something about the work but do not have your hyperlink. You know
it was a blue book of certain dimensions about flies. The catalogue
entry is the google base that will help you hone in on what you are
looking for. A citation has a quite different focus.

Whether this cite micrformat proposal covers cataloging as well as
citation may be important to consider. Cataloging typically requires
conformance to very specific rules such as AARC2, and significant
portions of some library courses are built around getting it right.
These rules cover details such as whether you have to record both the
width and the height of a book, depending on how closely related the
dimensions are. I think that aiming to include the capabilities of MARC
or a simliar cataloging system might be aiming too high. If MARC was
able to be encoded it may well be useful, but at a quick glance I would
see this as a microformat in itself. I think you would either have to
pick MARC21 as your semantic model or choose not be compatible with
MARC.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From benjamincarlyle at optusnet.com.au  Tue Dec 20 07:44:38 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Tue Dec 20 07:43:57 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <43843033.4080802@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>
Message-ID: <1135093478.6321.9.camel@tori>

David,

On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
> Have at it:
> http://microformats.org/wiki/hatom

I'm currently doing some work based on Luke Arno's hAtom2Atom.xsl to get
my feed reader of choice (liferea) to parse hAtom sites. I currently
have the xsl scraping the html page for each entry in order to fill out
author details when they are not present in the entry itself. I first
search the entry proximity, then start back at xpath "/" if none are
found. This is in line with the Entry Author heading in the
microformat[1] which states:
"if an Entry has 0 Entry Athor elements, the "logical Entry Author" is
assumed to be the author of the XHTML page"

Looking at the required feed[2] and entry[3] elements from
atomenabled.org it seems that only "id", "title", and "updated" are
required in each. Is this a mismatch with the standard, or is my
understanding of the hAtom spec mismatched? Reading the information from
that atomenabled.org I'm inclined to write the parser as only placing
author and contributor elements in an entry when they appear in the
hAtom html within an entry. If author and contributor fields were only
to be found at the feed level I would only repeat them there in the atom
output. Is my inclination reasonable? That would make any atom feed
reader responsible for making the association between a feed with a
particular author an each entry having a particular author rather than
the transform...

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
[1] http://microformats.org/wiki/hatom#Entry_Author
[2] http://atomenabled.org/developers/syndication/#requiredFeedElements
[3] http://atomenabled.org/developers/syndication/#requiredEntryElements

From ehs at pobox.com  Tue Dec 20 07:53:18 2005
From: ehs at pobox.com (Ed Summers)
Date: Tue Dec 20 07:55:13 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <1135092172.6204.24.camel@tori>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
	<43A77B32.7030302@myelin.co.nz> <1135053094.6203.15.camel@tori>
	<343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
	<31EEEF81-3E96-4F13-96D1-81F91964664C@pobox.com>
	<1135092172.6204.24.camel@tori>
Message-ID: <f032cc060512200753o26b7474ft6a9a5779fc5bd1b0@mail.gmail.com>

On 12/20/05, Benjamin Carlyle <benjamincarlyle@optusnet.com.au> wrote:
> MARC is typically used for cataloging rather than citation. It is the
> electronic equivalent to a paper card catalogue in your local library.
> Cataloging and citation are targeted at slightly different audiences.
> Citation is targetted at an audience who wants to follow a kind of
> hyperlink from one place to another. The emphasis is on providing enough
> information to know where to look and to recognise it when you find it.
> Cataloging is intended for the reference librarian audience, where you
> know something about the work but do not have your hyperlink. You know
> it was a blue book of certain dimensions about flies. The catalogue
> entry is the google base that will help you hone in on what you are
> looking for. A citation has a quite different focus.

Yes, I'm conflating cataloging metadata and citation metadata a bit.
Cataloging cards typically have access points such as the main entry,
subject headings which guided how the card was filed in the physical
catalog. Citations do not have these typically.

With the advent of online catalogs this distinction is blurred quite a
bit given  the availability of freetext searching, and being able to
search against any metadata field, not just the main entry, subject
headings.

I'd argue that as a microformat the distinction gets blurred even
further since the artificat being processed by the machine is the
actual display of the citation metadata.

> Whether this cite micrformat proposal covers cataloging as well as
> citation may be important to consider. Cataloging typically requires
> conformance to very specific rules such as AARC2, and significant
> portions of some library courses are built around getting it right.
> These rules cover details such as whether you have to record both the
> width and the height of a book, depending on how closely related the
> dimensions are. I think that aiming to include the capabilities of MARC
> or a simliar cataloging system might be aiming too high. If MARC was
> able to be encoded it may well be useful, but at a quick glance I would
> see this as a microformat in itself. I think you would either have to
> pick MARC21 as your semantic model or choose not be compatible with
> MARC.

Agreed. Expecting microformatters to learn AACR2 and MARC's byzantine
tagging mechanism is a non starter. By definition MARC (Machine
Readable Cataloging) was designed for machines to read--not humans.
This is evident in the numeric tags that have no semantic content,
apart from what trained catalogers know them to be. MODS on the other
hand takes the semantics of MARC and associates the numeric tags with
pleasant human readable tags. There might actually be some potential
for MODS as a microformat.

That being said I'd love to see some MODS as microformat examples in
the wiki...and am enjoying this thread.

//Ed
From edward.vielmetti at gmail.com  Tue Dec 20 08:38:12 2005
From: edward.vielmetti at gmail.com (Edward Vielmetti)
Date: Tue Dec 20 08:38:14 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <f032cc060512200753o26b7474ft6a9a5779fc5bd1b0@mail.gmail.com>
References: <343d89550512191809s546136c3t124881d1eb8a4235@mail.gmail.com>
	<43A77B32.7030302@myelin.co.nz> <1135053094.6203.15.camel@tori>
	<343d89550512192037r32dd6b56w9e49a518488b3741@mail.gmail.com>
	<31EEEF81-3E96-4F13-96D1-81F91964664C@pobox.com>
	<1135092172.6204.24.camel@tori>
	<f032cc060512200753o26b7474ft6a9a5779fc5bd1b0@mail.gmail.com>
Message-ID: <343d89550512200838m7fee54e6o5589f2cc907a60cb@mail.gmail.com>

On 12/20/05, Ed Summers <ehs@pobox.com> wrote:
> Agreed. Expecting microformatters to learn AACR2 and MARC's byzantine
> tagging mechanism is a non starter. By definition MARC (Machine
> Readable Cataloging) was designed for machines to read--not humans.
> This is evident in the numeric tags that have no semantic content,
> apart from what trained catalogers know them to be. MODS on the other
> hand takes the semantics of MARC and associates the numeric tags with
> pleasant human readable tags. There might actually be some potential
> for MODS as a microformat.

There's a possibility of course that you won't have
to "have microformatters learn" more than once -
if you think of the audience for this in part is the
tech librarian / library online catalog vendor / etc
who has a huge number of MARC records already
and just needs to have rules to format them nicely,
rather than code things up by hand once for
every blog posting.

Thanks for the pointer to MODS.

This would be microformats for big publisher,
many consumers and reconsumers of the data.

Ed

>
> That being said I'd love to see some MODS as microformat examples in
> the wiki...and am enjoying this thread.
>
> //Ed
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>


--
Edward Vielmetti in Ann Arbor, MI 48104
+1 734 276 5910

edward.vielmetti@gmail.com
http://www.vacuumgroup.com
From tjameswhite at yahoo.com  Tue Dec 20 09:14:35 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Tue Dec 20 09:14:37 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <343d89550512200838m7fee54e6o5589f2cc907a60cb@mail.gmail.com>
Message-ID: <20051220171435.81939.qmail@web50014.mail.yahoo.com>

Brian Suda and I have had some on-again, off-again discussions
regarding a citation microformat. As this thread points out, solving
the whole thing in one shot is rather tricky.

So, what we've come up with as a starting point is identifying design
patterns and working on those first. I've tried to identify what is
currently being done (i.e.: people blogging about books) as well as
looking at the future and full citations. I wrote up an entry the other
day:
http://www.tjameswhite.com/blog/archives/2005/12/microformat-design-pattern/

Feel free to comment away (either there on on list).



~ Tim

<a href="http://www.tjameswhite.com">www.tjameswhite.com</a>

<a href="http://www.spreadfirefox.com/?q=affiliates&amp;id=12227&amp;t=1">Get Firefox!</a>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
From ehs at pobox.com  Tue Dec 20 09:37:20 2005
From: ehs at pobox.com (Ed Summers)
Date: Tue Dec 20 09:38:35 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <20051220171435.81939.qmail@web50014.mail.yahoo.com>
References: <343d89550512200838m7fee54e6o5589f2cc907a60cb@mail.gmail.com>
	<20051220171435.81939.qmail@web50014.mail.yahoo.com>
Message-ID: <f032cc060512200937y4072277sf963ae85b0dca768@mail.gmail.com>

On 12/20/05, Tim White <tjameswhite@yahoo.com> wrote:
> Brian Suda and I have had some on-again, off-again discussions
> regarding a citation microformat. As this thread points out, solving
> the whole thing in one shot is rather tricky.

Well, perhaps rather than solving 100% of the citation problems out
there we could focus on the 80% that openurl key/value pairs cover. It
really doesn't need to be that involved does it?

//Ed
From brian.suda at gmail.com  Tue Dec 20 09:57:44 2005
From: brian.suda at gmail.com (brian suda)
Date: Tue Dec 20 09:58:08 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <f032cc060512200937y4072277sf963ae85b0dca768@mail.gmail.com>
References: <343d89550512200838m7fee54e6o5589f2cc907a60cb@mail.gmail.com>	<20051220171435.81939.qmail@web50014.mail.yahoo.com>
	<f032cc060512200937y4072277sf963ae85b0dca768@mail.gmail.com>
Message-ID: <43A84618.1050507@gmail.com>

80% is exactly the point, i have started to put together a list of
"common" citation types, MODS, BibTeX, Dublin Core, etc. Then trying to
map the names between the many different formats, DC.Title->Title,
Bibtex.year->DC.Date, etc.

Then when we find all the common propties, we just give them our own
names (title, description, etc). Then everyone will know that the
Microformat.Title maps to ... in their own format. The cite-format[1]
page is the start of the current mappings, feel free to add/edit/delete
the terms.

>From that we can start to work-out the best way to encode the data.

-brian

[1] - http://microformats.org/wiki/cite-formats

Ed Summers wrote:

>On 12/20/05, Tim White <tjameswhite@yahoo.com> wrote:
>  
>
>>Brian Suda and I have had some on-again, off-again discussions
>>regarding a citation microformat. As this thread points out, solving
>>the whole thing in one shot is rather tricky.
>>    
>>
>
>Well, perhaps rather than solving 100% of the citation problems out
>there we could focus on the 80% that openurl key/value pairs cover. It
>really doesn't need to be that involved does it?
>
>//Ed
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>
>  
>

From tantek at cs.stanford.edu  Tue Dec 20 11:15:53 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Dec 20 11:16:29 2005
Subject: [uf-discuss] microformats.org nominated for "Best Web 2.0 Blog" -
	go vote!
Message-ID: <BFCD9811.65539%tantek@cs.stanford.edu>

Greetings microformatters,

We've been nominated for the (perhaps dubious?) "Best Web 2.0 Blog" award on
kbcafe.com:

http://www.kbcafe.com/iBLOGthere4iM/?guid=20051220093051

Scroll down to #7 on the list:

7. Best Web 2.0 Blog

[x] microformats - http://www.microformats.org/

Congratulations everyone for all your hard work!

Voting is open until New Year's Eve.  Have at it.

Thanks,

Tantek

From ryan at technorati.com  Tue Dec 20 12:05:00 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Dec 20 12:05:03 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <1135093478.6321.9.camel@tori>
References: <43843033.4080802@blogmatrix.com> <1135093478.6321.9.camel@tori>
Message-ID: <0DC0AF36-1935-4784-B035-E8108768022A@technorati.com>

On Dec 20, 2005, at 7:44 AM, Benjamin Carlyle wrote:

> David,
>
> On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
>> Have at it:
>> http://microformats.org/wiki/hatom
>
> I'm currently doing some work based on Luke Arno's hAtom2Atom.xsl  
> to get
> my feed reader of choice (liferea) to parse hAtom sites. I currently
> have the xsl scraping the html page for each entry in order to fill  
> out
> author details when they are not present in the entry itself. I first
> search the entry proximity, then start back at xpath "/" if none are
> found. This is in line with the Entry Author heading in the
> microformat[1] which states:
> "if an Entry has 0 Entry Athor elements, the "logical Entry Author" is
> assumed to be the author of the XHTML page"
>
> Looking at the required feed[2] and entry[3] elements from
> atomenabled.org it seems that only "id", "title", and "updated" are
> required in each. Is this a mismatch with the standard, or is my
> understanding of the hAtom spec mismatched?

I think the point of this is that in html we have a way of  
determining an author, without the help of hAtom (ie, <address> +  
hcard).

> Reading the information from
> that atomenabled.org I'm inclined to write the parser as only placing
> author and contributor elements in an entry when they appear in the
> hAtom html within an entry. If author and contributor fields were only
> to be found at the feed level I would only repeat them there in the  
> atom
> output. Is my inclination reasonable? That would make any atom feed
> reader responsible for making the association between a feed with a
> particular author an each entry having a particular author rather than
> the transform...

I'm not sure I follow what you're saying here.

Are you saying that when you transform to Atom, you're inclined to  
replicate the author information on every entry?

-rk
--
Ryan King
ryan@technorati.com



From davidjanes at blogmatrix.com  Tue Dec 20 12:29:49 2005
From: davidjanes at blogmatrix.com (David Janes)
Date: Tue Dec 20 12:29:55 2005
Subject: [uf-discuss] hAtom draft
References: <43843033.4080802@blogmatrix.com> <1135093478.6321.9.camel@tori>
Message-ID: <031201c605a4$20963c50$6501a8c0@JOANNELAPTOP>


----- Original Message ----- 
From: "Benjamin Carlyle" <benjamincarlyle@optusnet.com.au>
To: "Microformats Discuss" <microformats-discuss@microformats.org>
Sent: Tuesday, December 20, 2005 10:44 AM
Subject: Re: [uf-discuss] hAtom draft


> David,
>
> On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
>> Have at it:
>> http://microformats.org/wiki/hatom
>
> I'm currently doing some work based on Luke Arno's hAtom2Atom.xsl to get
> my feed reader of choice (liferea) to parse hAtom sites. I currently
> have the xsl scraping the html page for each entry in order to fill out
> author details when they are not present in the entry itself. I first
> search the entry proximity, then start back at xpath "/" if none are
> found. This is in line with the Entry Author heading in the
> microformat[1] which states:
> "if an Entry has 0 Entry Athor elements, the "logical Entry Author" is
> assumed to be the author of the XHTML page"
>
> Looking at the required feed[2] and entry[3] elements from
> atomenabled.org it seems that only "id", "title", and "updated" are
> required in each.

Right.

> Is this a mismatch with the standard, or is my
> understanding of the hAtom spec mismatched?

The Atom spec layers further requirements in the text, specifically from the 
Recommended Elements [4]

"Names one author of the entry. An entry may have multiple authors. An entry 
must contain at least one author element unless there is an author element 
in the enclosing feed, or there is an author element in the enclosed source 
element."

> Reading the information from
> that atomenabled.org I'm inclined to write the parser as only placing
> author and contributor elements in an entry when they appear in the
> hAtom html within an entry. If author and contributor fields were only
> to be found at the feed level I would only repeat them there in the atom
> output. Is my inclination reasonable? That would make any atom feed
> reader responsible for making the association between a feed with a
> particular author an each entry having a particular author rather than
> the transform...

I'm going to consider this a little further over Christmas. Right now, the 
hAtom spec does not define author (or contributor) at the feed level. This 
is an ommission, but I was concerned with making the minimal set of rules I 
could make.

Here's what I was/am thinking:
- the page also represents feed data; this is the reality of most blogs and 
there's a nice parsimony in not duplicating the information
- have you seen a blog where the Author is specified outside the entries 
(and not in the entries)? I.e. are we inventing edge cases that don't really 
exist?

That's not to say that what you're suggesting isn't a bad idea: that 
author/contributor are brought in IF they appear within the feed.

Regards, etc...
David

> -- 
> Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
> [1] http://microformats.org/wiki/hatom#Entry_Author
> [2] http://atomenabled.org/developers/syndication/#requiredFeedElements
> [3] http://atomenabled.org/developers/syndication/#requiredEntryElements
>

[4] http://atomenabled.org/developers/syndication/#recommendedEntryElements

From ryan at technorati.com  Tue Dec 20 12:33:41 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Dec 20 12:33:43 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <031201c605a4$20963c50$6501a8c0@JOANNELAPTOP>
References: <43843033.4080802@blogmatrix.com> <1135093478.6321.9.camel@tori>
	<031201c605a4$20963c50$6501a8c0@JOANNELAPTOP>
Message-ID: <E4B4A927-D7A9-4342-A9A2-5F01821016BF@technorati.com>

On Dec 20, 2005, at 12:29 PM, David Janes wrote:
> I'm going to consider this a little further over Christmas. Right  
> now, the hAtom spec does not define author (or contributor) at the  
> feed level. This is an ommission, but I was concerned with making  
> the minimal set of rules I could make.
>
> Here's what I was/am thinking:
> - the page also represents feed data; this is the reality of most  
> blogs and there's a nice parsimony in not duplicating the information
> - have you seen a blog where the Author is specified outside the  
> entries (and not in the entries)? I.e. are we inventing edge cases  
> that don't really exist?

Yes. Many personal blogs will have author data in one place on the  
page (like mine, in the footer: http://theryanking.com/blog/).

> That's not to say that what you're suggesting isn't a bad idea:  
> that author/contributor are brought in IF they appear within the feed.

-rk
From ryan at ryancannon.com  Tue Dec 20 12:59:41 2005
From: ryan at ryancannon.com (Ryan Cannon)
Date: Tue Dec 20 12:59:52 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for books
 in a library catalog
Message-ID: <61953.64.105.178.180.1135112381.squirrel@webmail.ryancannon.com>

Greetings,

I've actually been looking at this problem from another angle, and
considered submitting a microformat about it. What we're really looking
for is not solely citation data (such as ISBN), but bibliographic
information. Perhaps a good method for starting is to break down the
relevant information from accepted academic bibliography formats (MLA,
APA, Chicago) and synthesize proper class names based on that data.
-- 
Ryan Cannon

Interactive Developer
MSI Student, School of Information
University of Michigan
http://RyanCannon.com/

From brian.suda at gmail.com  Tue Dec 20 14:39:20 2005
From: brian.suda at gmail.com (brian suda)
Date: Tue Dec 20 14:39:46 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <61953.64.105.178.180.1135112381.squirrel@webmail.ryancannon.com>
References: <61953.64.105.178.180.1135112381.squirrel@webmail.ryancannon.com>
Message-ID: <43A88818.9000503@gmail.com>

Ryan Cannon wrote:

>Greetings,
>
>I've actually been looking at this problem from another angle, and
>considered submitting a microformat about it. What we're really looking
>for is not solely citation data (such as ISBN), but bibliographic
>information. Perhaps a good method for starting is to break down the
>relevant information from accepted academic bibliography formats (MLA,
>APA, Chicago) and synthesize proper class names based on that data.
>  
>
I see a citation and a reference as almost one and the same thing. I
know the lines are bluring as more data is on the web so your references
points to the document itself.

One thing i am working on, is how to use the same data that describe a
citation for both the current page and the list of references. So you
could say class="title" and people would know that it is the that is the
title of THIS page, and then use class="title" inside a
class="bibliography" to show that it is the title of that biblographic
citation. It is still a work in progress.

MLA, APA, and Chicago are way to display the data, the underlying
properties are the same.

This citation format is also going to be rolled into the Resume
microformat, so any publications, papers, etc, will be marked-up in this
fashion.

if anyone is intersted please read http://www.microformats.org/wiki/cite
and see if what you want is either already in there, or can be added.

I know there has been alot of talk about a television microformat, IMHO
i think that is just a very specialised version of a citation
microformat, with additional specialised fields.

-brian

-brian

From whump at mac.com  Tue Dec 20 14:49:27 2005
From: whump at mac.com (Bill Humphries)
Date: Tue Dec 20 14:49:32 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <43A88818.9000503@gmail.com>
References: <61953.64.105.178.180.1135112381.squirrel@webmail.ryancannon.com>
	<43A88818.9000503@gmail.com>
Message-ID: <98239DE6-16F0-45E8-A463-870A9C2CF0A8@mac.com>


On Dec 20, 2005, at 2:39 PM, brian suda wrote:

> I know there has been alot of talk about a television microformat,  
> IMHO
> i think that is just a very specialised version of a citation
> microformat, with additional specialised fields.

Thanks Brian.

B.K. DeLong and I had committed to researching examples of references  
to TV shows in the wild (it's still on my to do stack) and I'll add  
those to the 'cite-examples' page when I'm done with my research.

-- whump

From ryan at ryancannon.com  Tue Dec 20 12:56:42 2005
From: ryan at ryancannon.com (Ryan Cannon)
Date: Tue Dec 20 20:56:31 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for books
	in a library catalog
In-Reply-To: <20051220200003.8C706F08587@microformats>
References: <20051220200003.8C706F08587@microformats>
Message-ID: <5EF167FB-AF7E-4859-8BFD-DDA1394FCF41@ryancannon.com>

Greetings,

I've actually been looking at this problem from another angle, and  
considered submitting a microformat about it. What we're really  
looking for is not solely citation data (such as ISBN), but  
bibliographic information. Perhaps a good method for starting is to  
break down the relevant information from accepted academic  
bibliography formats (MLA, APA, Chicago) and synthesize proper class  
names based on that data.
-- 
Ryan Cannon

Interactive Developer
MSI Student, School of Information
University of Michigan
http://RyanCannon.com/


From benjamincarlyle at optusnet.com.au  Tue Dec 20 20:57:58 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Tue Dec 20 20:57:22 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <0DC0AF36-1935-4784-B035-E8108768022A@technorati.com>
References: <43843033.4080802@blogmatrix.com> <1135093478.6321.9.camel@tori>
	<0DC0AF36-1935-4784-B035-E8108768022A@technorati.com>
Message-ID: <1135141080.5516.29.camel@tori>

Ryan,

On Tue, 2005-12-20 at 12:05 -0800, Ryan King wrote:
> On Dec 20, 2005, at 7:44 AM, Benjamin Carlyle wrote:
> > Reading the information from
> > that atomenabled.org I'm inclined to write the parser as only placing
> > author and contributor elements in an entry when they appear in the
> > hAtom html within an entry. If author and contributor fields were only
> > to be found at the feed level I would only repeat them there in the  
> > atom
> > output. Is my inclination reasonable? That would make any atom feed
> > reader responsible for making the association between a feed with a
> > particular author an each entry having a particular author rather than
> > the transform...
> I'm not sure I follow what you're saying here.
> Are you saying that when you transform to Atom, you're inclined to  
> replicate the author information on every entry?

My current implementation looks within a class=entry for author and
contributor details. If it finds none it searches the feed (or
approximately so, the implementation is currently a little hacky) for an
author and places it within the <atom:entry> on output. If the feed has
an author it will be duplicated within each entry.

My inclination is to drop this processing, and only place atom:author
and atom:contributor where they appear in the source document. If they
appear at the feed level they are placed there. If they appear at the
entry level they are placed there. If they occur in both they are placed
in both. If they occur in neither they are placed in neither.

On Tue, 2005-12-20 at 15:29 -0500, David Janes wrote:
> The Atom spec layers further requirements in the text, specifically
from the 
> Recommended Elements [4]
> 
> "Names one author of the entry. An entry may have multiple authors. An entry 
> must contain at least one author element unless there is an author element 
> in the enclosing feed, or there is an author element in the enclosed source 
> element."

Ok, I took this on my reading as indicating that an author or
contributor at the atom:feed level would negate the need to provide
these fields on each atom:entry. But this:
> Right now, the 
> hAtom spec does not define author (or contributor) at the feed level
is certainly pause for thought. If it isn't legal to put them at
the atom:feed level or the meaning of the elements at the atom:feed
level is unclear copying the information into atom:entry nodes on
transform to atom would seem reasonable.

> - have you seen a blog where the Author is specified outside the
entries 
> (and not in the entries)? I.e. are we inventing edge cases that don't really 
> exist?

I think this is fairly typical. My blog is a case in point.
Individual entries may be tagged with minimal author information
(I sign off with "Benjamin"), but information such as email address
and the like tend to be situated only once on the page. This detail
would seem the more useful set to include.

Here is a quick survey of some current members of my blogroll
(a quick subset only). I have only selected personal blogs
which will typically have only one author. vcard means either
an actual hcard or information that could be reformatted as a hcard.

No vcard data (3):
http://www.gnome.org/~gman/blog/
http://www.gnome.org/~jdub/blog/
http://hardy.dropbear.id.au/blog/

Feed vcard only, no entry vcard (2):
http://www.advogato.org/person/robertc/
	- Name and uri, etc at top of page. No individual entry signoff.
http://ozlabs.org/~rusty/index.cgi
	- Email addres, job description, etc. No entry signoff.

Entry vcard only, no feed vcard (4):
http://www.sarahanne.co.uk/
	- Posted by, with hyperlink for uri.
	Also, "about" link... but not really vcard-compatible.
http://gnu.wildebeest.org/diary-man-di/index.php
	- "man-di" in post header?
http://research.operationaldynamics.com/blogs/
	- "posted by" signoff
http://www.csamuel.org/
	- "posted by" in post header

Feed vcard + Entry vcard,
but with additional detail in the "feed" vcard (2):
http://gracewood.blogspot.com/
	- About Me section + "posted by"
http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/
	- Tales from the homeworld poput + "Benjamin" sign-off

I would not indicate vcards for the signoff in the last
section, only marking author and contributor at the feed
level where more data is available. This would effectively
put them back into the "feed vard only" set, bumping its
count up to 4. Also, the feeds that do provide entry-level
vard information tend to keep it to just a name or name+url.

I don't know whether these figures are at all representative
of the general blog population. I started at the bottom of
my list of feeds in order to pick up some non-technical blogs.
I'm hoping this makes the figures remotely valid.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From pp at myelin.co.nz  Wed Dec 21 00:17:44 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Wed Dec 21 00:25:32 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <5EF167FB-AF7E-4859-8BFD-DDA1394FCF41@ryancannon.com>
References: <20051220200003.8C706F08587@microformats>
	<5EF167FB-AF7E-4859-8BFD-DDA1394FCF41@ryancannon.com>
Message-ID: <20051221081744.GC10435@myelin.co.nz>

In related news, Daniel Chudnov (who wrote this:
http://curtis.med.yale.edu/dchud/resolvable/) got in touch to point
out COinS, which is a (fairly cryptic-looking) microformat that embeds
OpenURL information inside HTML:

	http://ocoins.info/

It seems to be in current use: http://ocoins.info/#id3205609424

I've added this to the book review template for the Structured
Blogging plugins, and put an example on cite-brainstorming#OpenURL in
the wiki.

Cheers,
Phil

On Tue, Dec 20, 2005 at 03:56:42PM -0500, Ryan Cannon wrote:
> Greetings,
> 
> I've actually been looking at this problem from another angle, and  
> considered submitting a microformat about it. What we're really  
> looking for is not solely citation data (such as ISBN), but  
> bibliographic information. Perhaps a good method for starting is to  
> break down the relevant information from accepted academic  
> bibliography formats (MLA, APA, Chicago) and synthesize proper class  
> names based on that data.
> -- 
> Ryan Cannon
> 
> Interactive Developer
> MSI Student, School of Information
> University of Michigan
> http://RyanCannon.com/
> 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
From tantek at cs.stanford.edu  Wed Dec 21 03:28:48 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec 21 03:29:28 2005
Subject: [uf-discuss] cite/citation examples/formats/brainstorming
In-Reply-To: <5EF167FB-AF7E-4859-8BFD-DDA1394FCF41@ryancannon.com>
Message-ID: <BFCE7C49.655DD%tantek@cs.stanford.edu>

Hi Ryan,

On 12/20/05 12:56 PM, "Ryan Cannon" <ryan@ryancannon.com> wrote:

> Greetings,
> 
> I've actually been looking at this problem from another angle, and
> considered submitting a microformat about it. What we're really
> looking for is not solely citation data (such as ISBN), but
> bibliographic information.

Yes.

> Perhaps a good method for starting is to
> break down the relevant information from accepted academic
> bibliography formats (MLA, APA, Chicago) and synthesize proper class
> names based on that data.

If there was wide interoperability of one particular academic bibliographic
format, then yes, that basing a microformat on that one academic
bibliographic format would be a reasonable route to take. (e.g. as we did
with vCard for hCard).

However, there are a plethora of citation formats, most of which could be
criticized as being drastically overdesigned/overengineered for the 80/20
case of what people actually publish on the Web.

So before jumping to format analysis, the first thing to do, per the
microformats process:

 http://microformats.org/wiki/process
 
...is to research and document more real world *examples* of people posting
actual citation *content* on the Web, visibly, intended for human
consumption.

 http://microformats.org/wiki/cite-examples

So far we have only two sets of examples listed, a few more would be good,
along with the analysis of the implicit schemas illustrated by each content
example.

Once we have a good idea what the 80/20 is of actual citation related fields
used in actual citation examples published on the web, then we can take a
analyze existing formats (and please add to this page if you know of more):

 http://microformats.org/wiki/cite-formats

...to see how drastically we should subset them and brainstorm a straw
microformat accordingly in the cite-brainstorming page:

 http://microformats.org/wiki/cite-brainstorming

Thanks,

Tantek

From ehs at pobox.com  Wed Dec 21 06:20:46 2005
From: ehs at pobox.com (Ed Summers)
Date: Wed Dec 21 06:20:49 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <20051221081744.GC10435@myelin.co.nz>
References: <20051220200003.8C706F08587@microformats>
	<5EF167FB-AF7E-4859-8BFD-DDA1394FCF41@ryancannon.com>
	<20051221081744.GC10435@myelin.co.nz>
Message-ID: <f032cc060512210620l51b5377alb2da7479ae937f50@mail.gmail.com>

On 12/21/05, Phillip Pearson <pp@myelin.co.nz> wrote:
> I've added this to the book review template for the Structured
> Blogging plugins, and put an example on cite-brainstorming#OpenURL in
> the wiki.

Thanks Phil and Dan! When can we expect the openurl/coins support in
structured blogging to be released?

//Ed
From pp at myelin.co.nz  Wed Dec 21 12:56:58 2005
From: pp at myelin.co.nz (Phillip Pearson)
Date: Wed Dec 21 12:56:56 2005
Subject: [uf-discuss] Re: [Structuredblogging-discuss] microformat for
	books in a library catalog
In-Reply-To: <f032cc060512210620l51b5377alb2da7479ae937f50@mail.gmail.com>
References: <20051220200003.8C706F08587@microformats>	<5EF167FB-AF7E-4859-8BFD-DDA1394FCF41@ryancannon.com>	<20051221081744.GC10435@myelin.co.nz>
	<f032cc060512210620l51b5377alb2da7479ae937f50@mail.gmail.com>
Message-ID: <43A9C19A.9090502@myelin.co.nz>

Ed Summers wrote:

>On 12/21/05, Phillip Pearson <pp@myelin.co.nz> wrote:
>  
>
>>I've added this to the book review template for the Structured
>>Blogging plugins, and put an example on cite-brainstorming#OpenURL in
>>the wiki.
>>    
>>
>Thanks Phil and Dan! When can we expect the openurl/coins support in
>structured blogging to be released?
>  
>
It'll go out with the next preview/beta release, which will either be 
right before Christmas or in the second week of January, after I come 
back from vacation.  If you want it right now, edit 
wpsb-files/microcontent/descriptions/review-book.xml (Wordpress) or 
plugins/StructuredBlogging/descriptions/review-book.xml (Movable Type) 
and change line 13 to:

<if content="@isbn"><p><b>ISBN</b>: <span class="Z3988"><attribute 
name="title">ctx_ver=Z39.88-2004&amp;rft_val_fmt=info:ofi/fmt:kev:mtx:book&amp;rft.isbn=<field 
content="@isbn"/></attribute><field content="@isbn"/></span></p></if>

Cheers,
Phil

From ryan at technorati.com  Wed Dec 21 14:19:07 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Dec 21 14:19:07 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <1135141080.5516.29.camel@tori>
References: <43843033.4080802@blogmatrix.com> <1135093478.6321.9.camel@tori>
	<0DC0AF36-1935-4784-B035-E8108768022A@technorati.com>
	<1135141080.5516.29.camel@tori>
Message-ID: <55F3037B-5260-49C7-A9C1-D942A617853B@technorati.com>

On Dec 20, 2005, at 8:57 PM, Benjamin Carlyle wrote:
> Ryan,
>
> On Tue, 2005-12-20 at 12:05 -0800, Ryan King wrote:
> > On Dec 20, 2005, at 7:44 AM, Benjamin Carlyle wrote:
> > > Reading the information from
> > > that atomenabled.org I'm inclined to write the parser as only  
> placing
> > > author and contributor elements in an entry when they appear in  
> the
> > > hAtom html within an entry. If author and contributor fields  
> were only
> > > to be found at the feed level I would only repeat them there in  
> the
> > > atom
> > > output. Is my inclination reasonable? That would make any atom  
> feed
> > > reader responsible for making the association between a feed  
> with a
> > > particular author an each entry having a particular author  
> rather than
> > > the transform...
> > I'm not sure I follow what you're saying here.
> > Are you saying that when you transform to Atom, you're inclined to
> > replicate the author information on every entry?
>
> My current implementation looks within a class=entry for author and
> contributor details. If it finds none it searches the feed (or
> approximately so, the implementation is currently a little hacky)  
> for an
> author and places it within the <atom:entry> on output. If the feed  
> has
> an author it will be duplicated within each entry.
>
> My inclination is to drop this processing, and only place atom:author
> and atom:contributor where they appear in the source document. If they
> appear at the feed level they are placed there. If they appear at the
> entry level they are placed there. If they occur in both they are  
> placed
> in both. If they occur in neither they are placed in neither.

This sounds reasonable.

> On Tue, 2005-12-20 at 15:29 -0500, David Janes wrote:
> > The Atom spec layers further requirements in the text, specifically
> from the
> > Recommended Elements [4]
> >
> > "Names one author of the entry. An entry may have multiple  
> authors. An entry
> > must contain at least one author element unless there is an  
> author element
> > in the enclosing feed, or there is an author element in the  
> enclosed source
> > element."
>
> Ok, I took this on my reading as indicating that an author or
> contributor at the atom:feed level would negate the need to provide
> these fields on each atom:entry. But this:
> > Right now, the
> > hAtom spec does not define author (or contributor) at the feed level
> is certainly pause for thought. If it isn't legal to put them at
> the atom:feed level or the meaning of the elements at the atom:feed
> level is unclear copying the information into atom:entry nodes on
> transform to atom would seem reasonable.

It not that its illegal, it just isn't defined yet. Your algorithm  
above seems reasonable and if it produces good results for you, I'd  
say go ahead with it. Your experiences with it could certainly help  
shape the spec around extracting author information.

-rk
--
Ryan King
ryan@technorati.com



From paul at msn.com  Wed Dec 21 14:28:26 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 21 14:31:17 2005
Subject: [uf-discuss] XOXO Comments
Message-ID: <dockpg$12r$1@sea.gmane.org>

http://microformats.org/wiki/xoxo
The XOXO format doesn't seem to allow, or specify, the use of heading 
elements for multi-level outlines, such as <h2>, <h3>, etc.  Is there a 
reason for this?

This example uses <p>
http://diveintomark.org/public/2004/01/xo-embeddable.xo

This one uses <span> and <a>
http://homepage.mac.com/ctholland/thelab/outlines/


Also, none of these examples seem to use class="xoxo" in them.  Is this a 
required feature, or optional?


Atamido




From drernie at opendarwin.org  Wed Dec 21 14:56:37 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Wed Dec 21 14:56:38 2005
Subject: [uf-discuss] XOXO Comments
In-Reply-To: <dockpg$12r$1@sea.gmane.org>
References: <dockpg$12r$1@sea.gmane.org>
Message-ID: <7DAC6BA5-8458-4D76-A563-315987ACC5C9@opendarwin.org>

Hi Paul,

On Dec 21, 2005, at 2:28 PM, Paul Bryson wrote:
> http://microformats.org/wiki/xoxo
> The XOXO format doesn't seem to allow, or specify, the use of heading
> elements for multi-level outlines, such as <h2>, <h3>, etc.  Is  
> there a
> reason for this?

I don't think XOXO cares about "headers" -- everything is determined  
by the structure.  So, I assume <h2> et al would be part of the text  
(or ignore) not part of the XOXO structure per se.

However, the very existence of headers implies that one can NOT do  
trivial YAML-like serialization.  Kevin, does your parser even try to  
deal with that?

> Also, none of these examples seem to use class="xoxo" in them.  Is  
> this a
> required feature, or optional?

Good question.  I suspect the answer may be context-dependent.  If  
you're writing a parser, you could try to grab any list, but there's  
always the risk that it wouldn't keep the "xoxo" contract implied by  
the class name.

-- Ernie P.

>
> This example uses <p>
> http://diveintomark.org/public/2004/01/xo-embeddable.xo
>
> This one uses <span> and <a>
> http://homepage.mac.com/ctholland/thelab/outlines/
>
>
> Also, none of these examples seem to use class="xoxo" in them.  Is  
> this a
> required feature, or optional?
>
>
> Atamido
>
>
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From paul at msn.com  Wed Dec 21 15:24:24 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 21 15:22:10 2005
Subject: [uf-discuss] hCard Comments
Message-ID: <doco2e$bh5$1@sea.gmane.org>

http://microformats.org/wiki/hcard

Is the hCard format supposed to contain all classes as specified in the 
vCard RFC unless otherwise specified?  Or is it limited in scope to what has 
actually been mentioned?


Key is mentioned specifically in the spec, but there doesn't seem to be any 
definition indicating how exactly it should be implemented.  What kind of 
key to use?  Is there a link to a file or base64 encoded inline?


Is class="hcard" ever used?


The spec does not specifically address the use of handles or usernames, so I 
was wondering about input about this.

There are a number of websites that will allow a user to have both a 
username and to enter their real name.  Many of these sites do not display 
the real name to normal users, or possibly in normal browsing.  It would 
seem to make sense to display the username in the "fn" so that you have:

<span class="fn nickname">Atamido</span>

Now, if an admin is looking at the same profile information, it would be far 
easier on the backend design to have it simply add the real name before the 
user name like this:

<span class="fn">Paul Bryson</span>
<span class="fn nickname">Atamido</span>

Would this be appropriate?


Paul Bryson 



From tantek at cs.stanford.edu  Wed Dec 21 16:55:32 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec 21 16:56:09 2005
Subject: [uf-discuss] XOXO Comments
In-Reply-To: <7DAC6BA5-8458-4D76-A563-315987ACC5C9@opendarwin.org>
Message-ID: <BFCF3933.65651%tantek@cs.stanford.edu>

On 12/21/05 2:56 PM, "Dr. Ernie Prabhakar" <drernie@opendarwin.org> wrote:

> Hi Paul,
> 
> On Dec 21, 2005, at 2:28 PM, Paul Bryson wrote:
>> http://microformats.org/wiki/xoxo
>> The XOXO format doesn't seem to allow, or specify, the use of heading
>> elements for multi-level outlines, such as <h2>, <h3>, etc.  Is
>> there a
>> reason for this?
> 
> I don't think XOXO cares about "headers" -- everything is determined
> by the structure.  So, I assume <h2> et al would be part of the text
> (or ignore) not part of the XOXO structure per se.

It would be ignored by a XOXO-only parser, per the FAQ:

 http://microformats.org/wiki/xoxo-faq#other_markup_in_xoxo


See my blogroll for an example of combining <hn> tag structure with a XOXO
structure:

 http://tantek.com/log/


> However, the very existence of headers implies that one can NOT do
> trivial YAML-like serialization.  Kevin, does your parser even try to
> deal with that?

Except that we can (and do) special case the common case of a single element
surrounding the "content" of a XOXO item.  This is done in the XOXO parsing
code.

Of course this is not required by XOXO at all, but is permitted.


>> Also, none of these examples seem to use class="xoxo" in them.  Is
>> this a
>> required feature, or optional?
> 
> Good question.  I suspect the answer may be context-dependent.  If
> you're writing a parser, you could try to grab any list, but there's
> always the risk that it wouldn't keep the "xoxo" contract implied by
> the class name.

This is also in the FAQ:

http://microformats.org/wiki/xoxo-faq#class.3D.22xoxo.22

Thanks,

Tantek

From ryan at technorati.com  Wed Dec 21 17:11:57 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Dec 21 17:11:56 2005
Subject: [uf-discuss] hCard Comments
In-Reply-To: <doco2e$bh5$1@sea.gmane.org>
References: <doco2e$bh5$1@sea.gmane.org>
Message-ID: <7551728C-6950-458B-BE10-D78AF3740605@technorati.com>

On Dec 21, 2005, at 3:24 PM, Paul Bryson wrote:

> http://microformats.org/wiki/hcard
>
> Is the hCard format supposed to contain all classes as specified in  
> the
> vCard RFC unless otherwise specified?  Or is it limited in scope to  
> what has
> actually been mentioned?

For the most part, yes. Just realize that it is definitely still a  
work in progress, so if there are properties which no one has needed  
yet, then they probably haven't been addressed.

> Key is mentioned specifically in the spec, but there doesn't seem  
> to be any
> definition indicating how exactly it should be implemented.  What  
> kind of
> key to use?  Is there a link to a file or base64 encoded inline?

You might want to explain what key is and why people should care (ie,  
what it would be used for).

> Is class="hcard" ever used?

no.

> The spec does not specifically address the use of handles or  
> usernames, so I
> was wondering about input about this.
>
> There are a number of websites that will allow a user to have both a
> username and to enter their real name.  Many of these sites do not  
> display
> the real name to normal users, or possibly in normal browsing.  It  
> would
> seem to make sense to display the username in the "fn" so that you  
> have:
>
> <span class="fn nickname">Atamido</span>
>
> Now, if an admin is looking at the same profile information, it  
> would be far
> easier on the backend design to have it simply add the real name  
> before the
> user name like this:
>
> <span class="fn">Paul Bryson</span>
> <span class="fn nickname">Atamido</span>
>
> Would this be appropriate?

This is how we typically do it, but we may not have documented it  
anywhere. If you could add an entry to http://microformats.org/wiki/ 
hcard-faq about this, it'd be great.

thanks,
ryan

--
Ryan King
ryan@technorati.com



From tantek at cs.stanford.edu  Wed Dec 21 18:17:57 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec 21 18:18:36 2005
Subject: [uf-discuss] hCard Comments
In-Reply-To: <doco2e$bh5$1@sea.gmane.org>
Message-ID: <BFCF4CCC.65664%tantek@cs.stanford.edu>

First of all, thanks for the comments Paul!  Both these and the feedback on
XOXO are excellent.


On 12/21/05 3:24 PM, "Paul Bryson" <paul@msn.com> wrote:

> http://microformats.org/wiki/hcard
> 
> Is the hCard format supposed to contain all classes as specified in the
> vCard RFC unless otherwise specified?

Yes.  It does contain all classes as properties specified in the vCard RFC.

If you find something missing, please let us know!


> Key is mentioned specifically in the spec, but there doesn't seem to be any
> definition indicating how exactly it should be implemented.  What kind of
> key to use?  Is there a link to a file or base64 encoded inline?

Any such questions about "what kind of key to use" are left to the RFC.
hCard doesn't change the semantic of the key property.


> Is class="hcard" ever used?

No.  Though it has been suggested that should hCard ever expand beyond
vCard, we could use class="hcard" to indicate such an expansion.  Hopefully
we would be smart enough to keep it backward compatible with hCard "1.0" as
it were, and thus use something like class="vcard hcard", permitting hCard
1.0 parsers to consume such future content.  Again, these are just "forward
looking statements" and are not commitments to an expansion.  We may just
consider hCard "done" with the current 1.0 version.


> The spec does not specifically address the use of handles or usernames, so I
> was wondering about input about this.

You may use nickname for that purpose.

If the handle/username has a specific context/domain, then a URL to the
profile of that username within it's service context/domain can be used.


> There are a number of websites that will allow a user to have both a
> username and to enter their real name.  Many of these sites do not display
> the real name to normal users, or possibly in normal browsing.  It would
> seem to make sense to display the username in the "fn" so that you have:
> 
> <span class="fn nickname">Atamido</span>

Yes.


> Now, if an admin is looking at the same profile information, it would be far
> easier on the backend design to have it simply add the real name before the
> user name like this:
> 
> <span class="fn">Paul Bryson</span>
> <span class="fn nickname">Atamido</span>
> 
> Would this be appropriate?

Well, it wouldn't be valid per the hCard spec since you may only have one
"fn" per hCard.

However, due to the hCard parsing rules for unique (one instance only)
properties, a compliant hCard parser encountering the two span fn elements
above would use the first "fn", and ignore the second.

In addition, due to the prevalence of the use of "nicknames" or "handles" on
the Web, in actual content published on the Web (e.g. authors of reviews),
there has been a discussion (maybe in old email?  maybe in private email
between Brian Suda and myself before the microformats lists were created?)
about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as
a fallback.

E.g. right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an
"n" element per the "implied n property" rules in the spec.

PROPOSAL:

We should consider adding one more step and that is:

If no "fn" is present either, then look for a "nickname" element to uses to
imply both the "fn", and the "given-name", leaving the "family-name" as
empty.

This would allow you to write in your example:

 <span class="nickname">Atamido</span>

For the "public" display and have it work and have it imply an "fn" and
"n/given-name".  Then in the admin case you would have:

 <span class="fn">Paul Bryson</span>
 <span class="nickname">Atamido</span>

And it would use the "fn" to imply the "n", and everything would work as
before for that case.  The net result is that the admin sees more info than
the public.

Proposal captured here:

http://microformats.org/wiki/hcard-brainstorming#Implied_.22FN_and_N.22_Opti
mization_.28proposal.29

What do folks think?

Tantek

From paul at msn.com  Wed Dec 21 23:44:31 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 21 23:42:17 2005
Subject: [uf-discuss] XOXO Comments
References: <7DAC6BA5-8458-4D76-A563-315987ACC5C9@opendarwin.org>
	<BFCF3933.65651%tantek@cs.stanford.edu>
Message-ID: <dodlc2$mee$1@sea.gmane.org>

"Tantek Ç elik" wrote...
> On 12/21/05 2:56 PM, "Dr. Ernie Prabhakar"  wrote:
>> I don't think XOXO cares about "headers" -- everything is determined
>> by the structure.  So, I assume <h2> et al would be part of the text
>> (or ignore) not part of the XOXO structure per se.
>
> It would be ignored by a XOXO-only parser, per the FAQ:
>
> http://microformats.org/wiki/xoxo-faq#other_markup_in_xoxo

Okay, this makes sense to me now.  However it may be worth noting in the 
same that the Web Apps 1.0 spec prohibits both inline and block level 
content to be used in the same container.  So if you are going to label it, 
you should use an block level element around the label.

http://www.whatwg.org/specs/web-apps/current-work/#li0

> This is also in the FAQ:
>
> http://microformats.org/wiki/xoxo-faq#class.3D.22xoxo.22

Okay, I didn't notice the FAQ.  It would be nice if the pages had a concise 
list of all of the internal wiki pages related directly to that topic.  When 
I want to refer to some page I spotted earlier, I have to hunt through the 
text for that one link, whatever it was called...


Atamido 



From paul at msn.com  Thu Dec 22 00:17:38 2005
From: paul at msn.com (Paul Bryson)
Date: Thu Dec 22 00:15:26 2005
Subject: [uf-discuss] hCard Comments
References: <doco2e$bh5$1@sea.gmane.org>
	<BFCF4CCC.65664%tantek@cs.stanford.edu>
Message-ID: <dodna6$qpj$1@sea.gmane.org>

"Tantek Ç elik" wrote...
> On 12/21/05 3:24 PM, "Paul Bryson" wrote:
>> Key is mentioned specifically in the spec, but there doesn't seem to be 
>> any
>> definition indicating how exactly it should be implemented.  What kind of
>> key to use?  Is there a link to a file or base64 encoded inline?
>
> Any such questions about "what kind of key to use" are left to the RFC.
> hCard doesn't change the semantic of the key property.

>From the RFC:
   Type purpose: To specify a public key or authentication certificate
   associated with the object that the vCard represents.

   Type encoding: The encoding MUST be reset to "b" using the ENCODING
   parameter in order to specify inline, encoded binary data. If the
   value is a text value, then the default encoding of 8bit is used and
   no explicit ENCODING parameter is needed.

   Type value: A single value. The default is binary. It can also be
   reset to text value. The text value can be used to specify a text
   key.

   Type special notes: The type can also include the type parameter TYPE
   to specify the public key or authentication certificate format. The
   parameter type should specify an IANA registered public key or
   authentication certificate format. The parameter type can also
   specify a non-standard format.

   Type example:

        KEY;ENCODING=b:MIICajCCA....

First, you specify the encoding using "encoding", which hasn't been used 
anywhere else up to this point.  It's other uses involve photos, sounds, and 
other binary files that are realistically never placed inline.  And 
specifying them explicitly isn't needed because we use src="" and href="". 
But we could theoretically place the key inline.

Here is an actual signing that is done in an email.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some Message text
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC5/UHXXdo3FmeeeYRAhDEAJ0eNCBD4ncYAJt0i+qGxDq47ie8dwCgmfFU
3PBLjF1xtXjZBHpOVtEthMc=
=UCHu
-----END PGP SIGNATURE-----


You will notice the entire message is encompassed about by the key.  It also 
includes version information so that you know how to authenticate the key. 
Some other clients will place the email text in one attachment and the key 
(BEGIN to END SIGNATURE) in another.

The vCard RFC, however, does not seem to include any of this information. 
Honestly, I have no idea what kind of key they are suggesting they are 
using, nor what data they are trying to authenticate.  This part of the RFC 
seems incredibly ambiguous.  Am I missing something or reading this wrong?

I'm not complaining because I really don't know how you would validate some 
XHTML data, especially using an element that is the child of the element you 
are trying to authenticate.

>> Is class="hcard" ever used?
>
> No.  Though it has been suggested that should hCard ever expand beyond
> vCard, we could use class="hcard" to indicate such an expansion. 
> Hopefully
> we would be smart enough to keep it backward compatible with hCard "1.0" 
> as
> it were, and thus use something like class="vcard hcard", permitting hCard
> 1.0 parsers to consume such future content.  Again, these are just 
> "forward
> looking statements" and are not commitments to an expansion.  We may just
> consider hCard "done" with the current 1.0 version.

Good thoughts.

> PROPOSAL:
>
> We should consider adding one more step and that is:
>
> If no "fn" is present either, then look for a "nickname" element to uses 
> to
> imply both the "fn", and the "given-name", leaving the "family-name" as
> empty.
>
> This would allow you to write in your example:
>
> <span class="nickname">Atamido</span>
>
> For the "public" display and have it work and have it imply an "fn" and
> "n/given-name".  Then in the admin case you would have:
>
> <span class="fn">Paul Bryson</span>
> <span class="nickname">Atamido</span>
>
> And it would use the "fn" to imply the "n", and everything would work as
> before for that case.  The net result is that the admin sees more info 
> than
> the public.
>
> Proposal captured here:
>
> http://microformats.org/wiki/hcard-brainstorming#Implied_.22FN_and_N.22_Opti
> mization_.28proposal.29
>
> What do folks think?

Your proposal seems very clean.  If n can fall back to fn, then also falling 
back to nickname would not seem like a stretch, and it simplifies things 
within the HTML itself.


Atamido 



From ryan at technorati.com  Thu Dec 22 11:41:24 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 22 11:41:24 2005
Subject: [uf-discuss] wiki gardening (was: XOXO Comments)
In-Reply-To: <dodlc2$mee$1@sea.gmane.org>
References: <7DAC6BA5-8458-4D76-A563-315987ACC5C9@opendarwin.org>
	<BFCF3933.65651%tantek@cs.stanford.edu>
	<dodlc2$mee$1@sea.gmane.org>
Message-ID: <D04DF517-C228-413D-A38A-ED20459AF486@technorati.com>

On Dec 21, 2005, at 11:44 PM, Paul Bryson wrote:
> ... It would be nice if the pages had a concise
> list of all of the internal wiki pages related directly to that  
> topic.  When
> I want to refer to some page I spotted earlier, I have to hunt  
> through the
> text for that one link, whatever it was called...

The wiki could certainly use some gardening. I'm open to any ideas  
and volunteers. :D

-rk
--
Ryan King
ryan@technorati.com



From davidjanes at blogmatrix.com  Thu Dec 22 11:54:05 2005
From: davidjanes at blogmatrix.com (David Janes)
Date: Thu Dec 22 11:54:00 2005
Subject: [uf-discuss] hAtom draft
References: <43843033.4080802@blogmatrix.com>
	<1135093478.6321.9.camel@tori><031201c605a4$20963c50$6501a8c0@JOANNELAPTOP>
	<E4B4A927-D7A9-4342-A9A2-5F01821016BF@technorati.com>
Message-ID: <04e301c60731$770954d0$6501a8c0@JOANNELAPTOP>

More in general, people put their real address elsewhere. It would be cool 
if there was a standardized way to do

<a
  class="author vcard fn"
  rel="vcard"
  href=http://theryanking.com/blog/contact/
>Ryan King</a>.

The key being the rel="vcard" (or something like it) saying that the full 
vcard is somewhere else.

Regards, etc...

----- Original Message ----- 
From: "Ryan King" <ryan@technorati.com>
Sent: Tuesday, December 20, 2005 3:33 PM


> Yes. Many personal blogs will have author data in one place on the  page 
> (like mine, in the footer: http://theryanking.com/blog/).

From paul at msn.com  Thu Dec 22 12:01:44 2005
From: paul at msn.com (Paul Bryson)
Date: Thu Dec 22 11:59:29 2005
Subject: [uf-discuss] wiki gardening (was: XOXO Comments)
References: <7DAC6BA5-8458-4D76-A563-315987ACC5C9@opendarwin.org><BFCF3933.65651%tantek@cs.stanford.edu><dodlc2$mee$1@sea.gmane.org>
	<D04DF517-C228-413D-A38A-ED20459AF486@technorati.com>
Message-ID: <dof0i9$vja$1@sea.gmane.org>

"Ryan King" wrote...
> On Dec 21, 2005, at 11:44 PM, Paul Bryson wrote:
> The wiki could certainly use some gardening. I'm open to any ideas  and 
> volunteers. :D

I'm thinking something like this on each of the main pages.
http://microformats.org/wiki/hcard#hCard_Wiki_Pages


Atamido 



From qidydl at gmail.com  Thu Dec 22 13:58:21 2005
From: qidydl at gmail.com (David Osolkowski)
Date: Thu Dec 22 13:58:23 2005
Subject: [uf-discuss] XFN and hCards
Message-ID: <ee0909a60512221358j389a109am22e428c63692e118@mail.gmail.com>

In XFN Delusions of Grandeur[1], Jennifer Golbeck argues that XFN isn't very
useful because it annotates links between web pages, not people.  Ok, so how
do we make XFN link people?

There are two people involved, a source and a target.  To identify the
source, a page with XFN links should include an <address> element, which
identifies the author of the page.  The <address> element should contain an
hCard, which--to my knowledge--is the best method we have for representing a
person in (X)HTML.

Identifying the target is a little more complicated.  Generally, we should
check the linked page for an <address> element, and assume that linking to a
page means relating to the author of that page.  If that assumption is
incorrect, the source could link directly to an hCard (i.e.
http://www.example.com/page.html#hCard).  This requires the hCard to have an
id, which makes things a bit trickier; what should the source do if the
hCard does not have an id?  When publishing hCards, how do you know whether
they'll need ids?  Is this situation within the 80%?

Basically, I'm proposing some best practices for using XFN with hCards that
seem to improve the semantics, without needing to invent anything new.  If
we agree on these practices, they should be explained on the XFN website.

[1]: http://www.oreillynet.com/pub/wlg/8281


- David Osolkowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051222/35cf08ef/attachment.htm
From ryan at technorati.com  Thu Dec 22 15:05:13 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 22 15:05:18 2005
Subject: [uf-discuss] wiki gardening (was: XOXO Comments)
In-Reply-To: <dof0i9$vja$1@sea.gmane.org>
References: <7DAC6BA5-8458-4D76-A563-315987ACC5C9@opendarwin.org><BFCF3933.65651%tantek@cs.stanford.edu><dodlc2$mee$1@sea.gmane.org>
	<D04DF517-C228-413D-A38A-ED20459AF486@technorati.com>
	<dof0i9$vja$1@sea.gmane.org>
Message-ID: <4C2C63BA-C3B5-4B8B-A75C-78E58D77F6DD@technorati.com>

On Dec 22, 2005, at 12:01 PM, Paul Bryson wrote:

> "Ryan King" wrote...
>> On Dec 21, 2005, at 11:44 PM, Paul Bryson wrote:
>> The wiki could certainly use some gardening. I'm open to any  
>> ideas  and
>> volunteers. :D
>
> I'm thinking something like this on each of the main pages.
> http://microformats.org/wiki/hcard#hCard_Wiki_Pages

Looks good. Does someone want to work on creating little templates  
for these?

-rk
--
Ryan King
ryan@technorati.com



From tantek at cs.stanford.edu  Thu Dec 22 15:06:16 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec 22 15:07:05 2005
Subject: [uf-discuss] wiki gardening (was: XOXO Comments)
In-Reply-To: <dof0i9$vja$1@sea.gmane.org>
Message-ID: <BFD06251.656FF%tantek@cs.stanford.edu>

On 12/22/05 12:01 PM, "Paul Bryson" <paul@msn.com> wrote:

> "Ryan King" wrote...
>> On Dec 21, 2005, at 11:44 PM, Paul Bryson wrote:
>> The wiki could certainly use some gardening. I'm open to any ideas  and
>> volunteers. :D
> 
> I'm thinking something like this on each of the main pages.
> http://microformats.org/wiki/hcard#hCard_Wiki_Pages

Note that 4 out of the 5 links that are in that new section were already at
the bottom of that page.

Related links are good thing, let's just not duplicate the ones that area
already there. :)

Tantek

From ryan at technorati.com  Thu Dec 22 15:14:37 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 22 15:14:37 2005
Subject: [uf-discuss] XFN and hCards
In-Reply-To: <ee0909a60512221358j389a109am22e428c63692e118@mail.gmail.com>
References: <ee0909a60512221358j389a109am22e428c63692e118@mail.gmail.com>
Message-ID: <D1FCA10B-3932-487D-820B-280BCA02F95D@technorati.com>

On Dec 22, 2005, at 1:58 PM, David Osolkowski wrote:

> In XFN Delusions of Grandeur[1], Jennifer Golbeck argues that XFN  
> isn't very useful because it annotates links between web pages, not  
> people.  Ok, so how do we make XFN link people?

First of all, see the discussion here: http://www.microformats.org/ 
blog/2005/11/02/xfn-grandeur/

> There are two people involved, a source and a target.  To identify  
> the source, a page with XFN links should include an <address>  
> element, which identifies the author of the page.  The <address>  
> element should contain an hCard, which--to my knowledge--is the  
> best method we have for representing a person in (X)HTML.

I think you'll find a lot of agreement on that around here.

> Identifying the target is a little more complicated.  Generally, we  
> should check the linked page for an <address> element, and assume  
> that linking to a page means relating to the author of that page.

I'm not sure what you mean by the last part above.

> If that assumption is incorrect, the source could link directly to  
> an hCard ( i.e. http://www.example.com/page.html#hCard).  This  
> requires the hCard to have an id, which makes things a bit  
> trickier; what should the source do if the hCard does not have an  
> id?  When publishing hCards, how do you know whether they'll need  
> ids?  Is this situation within the 80%?

You can certainly use XFN links to link directly to people's hCards.

But, honestly, I think the two concerns: 1) annotating social  
connections and 2) identifying people are separate concerns in terms  
of formats/technology.

XFN and hCard do different things. Together they can be very useful,  
but "identifying authors of pages" is a concern that stands on its  
own, apart from XFN.

> Basically, I'm proposing some best practices for using XFN with  
> hCards that seem to improve the semantics, without needing to  
> invent anything new.  If we agree on these practices, they should  
> be explained on the XFN website.

I don't know if it needs to be explained on gmpg.org. Perhaps someone  
could start a wikipage to document these best practices?

Just remember that just because two technologies get lumped together  
in an application doesn't mean they should be conflated in their  
specifications.

-rk
--
Ryan King
ryan@technorati.com



From tantek at cs.stanford.edu  Thu Dec 22 15:27:08 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec 22 15:27:46 2005
Subject: Bloggers use URLs to represent people (was Re: [uf-discuss] XFN
	and hCards)
In-Reply-To: <ee0909a60512221358j389a109am22e428c63692e118@mail.gmail.com>
Message-ID: <BFD072F2.65711%tantek@cs.stanford.edu>

On 12/22/05 1:58 PM, "David Osolkowski" <qidydl@gmail.com> wrote:

> In XFN Delusions of Grandeur[1], Jennifer Golbeck argues that XFN isn't
> very useful because it annotates links between web pages, not people.

[1] http://www.oreillynet.com/pub/wlg/8281

Unfortunately Jennifer makes the mistake of siding with theoretical
arguments against actual behavior.

Bloggers have conflated people and URLs.  That's the reality.  It's not even
worth time debating theoretical arguments when you can build technologies
based on actual human behaviors, with the exception of arguing them once so
you can simply reference them later.

http://www.microformats.org/blog/2005/11/02/xfn-grandeur/#comment-134

Thanks,

Tantek

From tantek at cs.stanford.edu  Thu Dec 22 15:27:08 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec 22 15:27:47 2005
Subject: [uf-discuss] wiki gardening (was: XOXO Comments)
In-Reply-To: <4C2C63BA-C3B5-4B8B-A75C-78E58D77F6DD@technorati.com>
Message-ID: <BFD0760E.65713%tantek@cs.stanford.edu>

On 12/22/05 3:05 PM, "Ryan King" <ryan@technorati.com> wrote:

> On Dec 22, 2005, at 12:01 PM, Paul Bryson wrote:
> 
>> "Ryan King" wrote...
>>> On Dec 21, 2005, at 11:44 PM, Paul Bryson wrote:
>>> The wiki could certainly use some gardening. I'm open to any
>>> ideas  and
>>> volunteers. :D
>> 
>> I'm thinking something like this on each of the main pages.
>> http://microformats.org/wiki/hcard#hCard_Wiki_Pages
> 
> Looks good.

It's good when it doesn't just duplicate what is already at the bottom of
the pages.

I've tried reorganizing what was already in the footer of the page into a
tighter more compact list, hopefully that will serve more folks better.

Take a look.

http://microformats.org/wiki/hcard#Related_Pages_And_Further_Reading

Thanks,

Tantek

From benjamincarlyle at optusnet.com.au  Thu Dec 22 20:09:13 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Thu Dec 22 20:08:33 2005
Subject: [uf-discuss] hAtom draft
In-Reply-To: <04e301c60731$770954d0$6501a8c0@JOANNELAPTOP>
References: <43843033.4080802@blogmatrix.com> <1135093478.6321.9.camel@tori>
	<031201c605a4$20963c50$6501a8c0@JOANNELAPTOP>
	<E4B4A927-D7A9-4342-A9A2-5F01821016BF@technorati.com>
	<04e301c60731$770954d0$6501a8c0@JOANNELAPTOP>
Message-ID: <1135310955.6244.15.camel@tori>

David,

On Thu, 2005-12-22 at 14:54 -0500, David Janes wrote:
> On Tuesday, December 20, 2005 3:33 PM, Ryan King wrote:
> > Yes. Many personal blogs will have author data in one place on the  page 
> > (like mine, in the footer: http://theryanking.com/blog/).
> More in general, people put their real address elsewhere.

True. I found one example in my earlier survey where the only useful
complete vcard information was off-page.

> It would be cool 
> if there was a standardized way to do
> <a
>   class="author vcard fn"
>   rel="vcard"
>   href=http://theryanking.com/blog/contact/
> >Ryan King</a>.

Interestingly, this might even work for vcards on the same page. Suppose
we have a list of entries wrapped in a feed element, but the "About Me"
is somewhere else on the page. It might be useful to say:

<a class="author" rel="vcard" href="#aboutMe">Author Name</a>

I suspect this would be straightforward to include in any current
"posted by" entry header or footer. I would even be inclined to
associate my signoff with a card (I would just have to move it outside
the content div). The human-visible effect may be reasonble also,
although it would change the visible attributes of the page slightly.
Humans would see new hyperlinks that jump to the "about me" page or
anchor.

I would suggest dropping vcard and fn from the class list as things are
currently written in the hAtom microformat page. If no vcard is present
in the author element the content is treated like an fn already, and
stating the vcard class may be confusing. A parser may assume this is
the full vcard and not interrogate the link.

One downside is that a parser that isn't willing to visit the "about me"
page (due to being offline or for some other reason), or isn't smart
enough to decypher the "about me" anchor (perhaps because it has thrown
that part of the document away already) may produce an abbreviated view
of the author vcard. Keeping the author name within the href mitigates
this problem by ensuring at least that is preserved.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From tantek at cs.stanford.edu  Thu Dec 22 22:34:21 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Dec 22 22:35:00 2005
Subject: using hCard to identify people (was Re: [uf-discuss] XFN and hCards)
In-Reply-To: <ee0909a60512221358j389a109am22e428c63692e118@mail.gmail.com>
Message-ID: <BFD0DA60.65740%tantek@cs.stanford.edu>

David,

You have brought up good use cases for using hCards to identify people, and
this is definitely worth further exploring and defining.


On 12/22/05 1:58 PM, "David Osolkowski" <qidydl@gmail.com> wrote:

> To identify the source,
> a page with XFN links should include an <address> element, which identifies
> the author of the page.

Yes.  And you could just shorten that to:

"a page should include an <address> element, which identifies
 the author of the page"

This is true for all pages, not just pages with XFN.  This is orthogonal to
XFN.

Using <address> accordingly is simply a good semantic XHTML authoring
practice.


> The <address> element should contain an hCard,
> which--to my knowledge--is the best method we have for representing a person
> in (X)HTML.

Strongly agreed.  

This is IMHO a very good "hCard practice" and documented in the hCard FAQ:

 http://microformats.org/wiki/hcard-faq

In addition, you've inspired me to write it up in the hcard-examples page as
well:

 http://microformats.org/wiki/hcard-examples#Authors_of_Pages_and_Posts


> Identifying the target is a little more complicated.

Actually, I'm not sure that it is that complicated at all.

First of all, there are two key cases here to satisfy illustrated by the
scenario you mentioned (when author A uses XFN to indicate a relationship to
another author B).


1. Author A asserts what Author B's name is.  This is the common/80% case as
in blogrolls, as those links nearly always say what the person's name is
that they are linking to.

This is easily done by taking a "typical" XFN link from a blogroll:

<a href="http://jeff.example.org" rel="friend">Jeff Xmpl</a>

And marking it up with hCard:

<span class="vcard">
 <a class="fn url" href="http://jeff.example.org" rel="friend">Jeff Xmpl</a>
</span>

In fact, I'll just go do this on my blogroll right now...

...that was fairly straight forward.  I think this might be another
improvement on the markup pattern for blogrolls.


2. Author B asserts what Author B's name is.  Clearly this is the better of
the two, as you can more often trust a person to spell their own name than
others to spell their name for them (perhaps I'm biased from personal
experience ;).  This is the case you address (so to speak) with your
example:


> Generally, we should
> check the linked page for an <address> element,

Again, this is just a good idea in general, whether using XFN or not.

> and assume that linking to a
> page means relating to the author of that page.

Yes, that's one of the established behaviors that XFN is built on


> Basically, I'm proposing some best practices for using XFN with hCards that
> seem to improve the semantics, without needing to invent anything new.

Yes, and your methodology, "improve the semantics, without needing to invent
anything new" is excellent.


> If we agree on these practices, they should be explained on the XFN website.

Agreed.  There is a page on the XFN website that explains how XFN is used
with other services and technologies:

 http://gmpg.org/xfn/and/

but it hasn't been updated in quite some time (it predates hCard ;).

Let's start with flipping this around, and document on the microformats.org
wiki the best practices of using hCards with XFN.

 http://microformats.org/wiki/hcard-examples#hCard_and_XFN

Thanks,

Tantek



From paul at msn.com  Thu Dec 22 23:31:36 2005
From: paul at msn.com (Paul Bryson)
Date: Thu Dec 22 23:31:51 2005
Subject: [uf-discuss] wiki gardening (was: XOXO Comments)
References: <dof0i9$vja$1@sea.gmane.org>
	<BFD06251.656FF%tantek@cs.stanford.edu>
Message-ID: <dog94o$d50$1@sea.gmane.org>

"Tantek Ç elik" wrote...
> On 12/22/05 12:01 PM, "Paul Bryson" wrote:
>
>> "Ryan King" wrote...
>>> On Dec 21, 2005, at 11:44 PM, Paul Bryson wrote:
>>> The wiki could certainly use some gardening. I'm open to any ideas  and
>>> volunteers. :D
>>
>> I'm thinking something like this on each of the main pages.
>> http://microformats.org/wiki/hcard#hCard_Wiki_Pages
>
> Note that 4 out of the 5 links that are in that new section were already 
> at
> the bottom of that page.
>
> Related links are good thing, let's just not duplicate the ones that area
> already there. :)

I wasn't fixing the page, just adding some information that I needed.  :P

Anyway, your method should work as long as it doesn't become cluttered with 
external links and the inside pages stay grouped together.  Also, looks like 
the hCard-examples page is missing.  Should it be moved from "more examples" 
or duplicated?


Atamido 



From neuro at 7el.net  Fri Dec 23 06:04:00 2005
From: neuro at 7el.net (Frederic de Villamil)
Date: Fri Dec 23 06:05:22 2005
Subject: [uf-discuss] "parental guidance" Microformat?
Message-ID: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>

Hi list,
I was lately thinking about a way to tell the most accurate way that a
link points to a page with content not suitable for people under a
certain age, such as porn, violence... the list should be long.
This reflexion came after a French law was voted that force Internet
providers to provide a parental control tool to every user. I think
having a microformat doing that sort of thing would greatly help those
tools to work, much more than page content analysis which is not always
relevant.

I've been thinking about vote-links, and I'm wondering why we could not
use rev="pg13" or rev="pg16" in links the way we use vote-for and 
vote-against in vote links.

It would give something like this:
<a href="http://www.example.com" rev="pg13" title="not suitable for
people under 13">some page</a>

Was my 2 cents of reflexion about it.
Merry Xmas to all,
Frederic / neuro
From qidydl at gmail.com  Fri Dec 23 07:12:10 2005
From: qidydl at gmail.com (David Osolkowski)
Date: Fri Dec 23 07:12:16 2005
Subject: [uf-discuss] XFN and hCards
In-Reply-To: <ee0909a60512230710u6f9f98bdp895b4dacfa6ac662@mail.gmail.com>
References: <ee0909a60512221358j389a109am22e428c63692e118@mail.gmail.com>
	<D1FCA10B-3932-487D-820B-280BCA02F95D@technorati.com>
	<ee0909a60512230710u6f9f98bdp895b4dacfa6ac662@mail.gmail.com>
Message-ID: <ee0909a60512230712q59e72e6bp7a0f17e28b98da06@mail.gmail.com>

On 12/22/05, Ryan King <ryan@technorati.com> wrote:
>
> First of all, see the discussion here: http://www.microformats.org/
> blog/2005/11/02/xfn-grandeur/


Apologies, I hadn't seen that; it looks like I'm a little late on this
topic, so if I'm not contributing anything new feel free to shut me up.

> Identifying the target is a little more complicated.  Generally, we
> > should check the linked page for an <address> element, and assume
> > that linking to a page means relating to the author of that page.
>
> I'm not sure what you mean by the last part above.


Well, the microformats blog post talks about using URLs as a proxy for
people.  If a page at a URL includes an <address> element, it seems safe to
assume that the content of that <address> element would be a representation
of the person that the URL is a proxy for.

Suppose http://source.website/blogroll.html includes an XFN link to
http://target.website/.  If http://source.website/blogroll.html contains an
<address> element, the content of that element would be the obvious
representation of the person on the source side of the XFN relationship.  If
http://target.website/ contains an <address> element, the content of that
element would be the obvious representation of the person on the target side
of the XFN relationship.  But... (see below)

> If that assumption is incorrect, the source could link directly to
> > an hCard ( i.e. http://www.example.com/page.html#hCard).  This
> > requires the hCard to have an id, which makes things a bit
> > trickier; what should the source do if the hCard does not have an
> > id?  When publishing hCards, how do you know whether they'll need
> > ids?  Is this situation within the 80%?
>
> You can certainly use XFN links to link directly to people's hCards.


Well, the tricky situation I was trying to describe is, what if the target
is an hCard on a page not authored by the person in the hCard? Suppose
http://target.website/
is authored by Joe Schmoe, but http://target.website/#wife is Jane Schmoe's
hCard.  If someone links to http://target.website/#wife with an XFN
relationship, the general case says it's a link to Joe, even though the
intention may be to link to Jane.  I don't know if this is a common
practice, or a theoretical edge case, or something that is currently rare
but could become common practice as hCard/XFN are more widely deployed (need
to find the cowpaths).  This may be more of an issue for tools than for
people authoring websites.  I don't consider myself experienced enough to
make these decisions.

But, honestly, I think the two concerns: 1) annotating social
> connections and 2) identifying people are separate concerns in terms
> of formats/technology.
>
> XFN and hCard do different things. Together they can be very useful,
> but "identifying authors of pages" is a concern that stands on its
> own, apart from XFN.


Indeed, that's why I intended to present this as "best practices when using
the formats," as opposed to "changes to the formats."  It's a combination of
XFN, hCard, and identifying the person that a URL represents.  XFN links the
URLs, hCards represent the people, I'm just trying to fill in the
(perceived?) gap between the URLs and the hCards.

I don't know if it needs to be explained on gmpg.org . Perhaps someone
> could start a wikipage to document these best practices?


Well, at the least gmpg.org should probably link to the wiki page.  "XFN
works best when used as explained on [this wiki page]."  How about the name
"social-networking-practices" for the wiki page?  I can try to draft
something up during the weekend.

Just remember that just because two technologies get lumped together
> in an application doesn't mean they should be conflated in their
> specifications.


Agreed.  I do not wish to change XFN or hCard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20051223/48bfae28/attachment.htm
From paul at msn.com  Fri Dec 23 08:20:00 2005
From: paul at msn.com (Paul Bryson)
Date: Fri Dec 23 08:20:23 2005
Subject: [uf-discuss] "parental guidance" Microformat?
References: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>
Message-ID: <doh83d$5cj$1@sea.gmane.org>

There already exists a rating system that is much more detailed than that.
http://www.icra.org/

Attached is an example ICRA file.


Atamido

"Frederic de Villamil" <neuro@7el.net> wrote...
> Hi list,
> I was lately thinking about a way to tell the most accurate way that a
> link points to a page with content not suitable for people under a
> certain age, such as porn, violence... the list should be long.
> This reflexion came after a French law was voted that force Internet
> providers to provide a parental control tool to every user. I think
> having a microformat doing that sort of thing would greatly help those
> tools to work, much more than page content analysis which is not always
> relevant.
>
> I've been thinking about vote-links, and I'm wondering why we could not
> use rev="pg13" or rev="pg16" in links the way we use vote-for and
> vote-against in vote links.
>
> It would give something like this:
> <a href="http://www.example.com" rev="pg13" title="not suitable for
> people under 13">some page</a>
>
> Was my 2 cents of reflexion about it.
> Merry Xmas to all,
> Frederic / neuro 


begin 666 labels.rdf
M/#]X;6P@=F5R<VEO;CTB,2XP(B!E;F-O9&EN9STB:7-O+3@X-3DM,2(_/@H\
M<F1F.E)$1@H@('AM;&YS.G)D9CTB:'1T<#HO+W=W=RYW,RYO<F<O,3DY.2\P
M,B\R,BUR9&8M<WEN=&%X+6YS(R(*("!X;6QN<SIR9&9S/2)H='1P.B\O=W=W
M+G<S+F]R9R\R,# P+S Q+W)D9BUS8VAE;6$C(@H@('AM;&YS.F1C/2)H='1P
M.B\O<'5R;"YO<F<O9&,O96QE;65N=',O,2XQ+R(*("!X;6QN<SID8W1E<FUS
M/2)H='1P.B\O<'5R;"YO<F<O9&,O=&5R;7,O(@H@('AM;&YS.FQA8F5L/2)H
M='1P.B\O=W=W+G<S+F]R9R\R,# T+S$R+W$O8V]N=&5N=&QA8F5L(R(*("!X
M;6QN<SII8W)A/2)H='1P.B\O=W=W+FEC<F$N;W)G+W)D9G,O=F]C86)U;&%R
M>78P,R,B/@H*(" \<F1F.D1E<V-R:7!T:6]N(')D9CIA8F]U=#TB(CX*(" @
M(#QD8SIC<F5A=&]R(')D9CIR97-O=7)C93TB:'1T<#HO+W=W=RYI8W)A+F]R
M9R(@+SX*(" @(#QD8W1E<FUS.FES<W5E9#XR,# U+3$R+3(S/"]D8W1E<FUS
M.FES<W5E9#X*(" @(#QL86)E;#IA=71H;W)I='E&;W(^:'1T<#HO+W=W=RYI
M8W)A+F]R9R]R9&9S+W9O8V%B=6QA<GEV,#,C/"]L86)E;#IA=71H;W)I='E&
M;W(^"B @/"]R9&8Z1&5S8W)I<'1I;VX^"@H@(#QL86)E;#I2=6QE<V5T/@H@
M(" @/&QA8F5L.FAA<TAO<W1297-T<FEC=&EO;G,^"B @(" @(#QL86)E;#I(
M;W-T<SX*(" @(" @(" \;&%B96PZ:&]S=%)E<W1R:6-T:6]N/G-E>"YC;VT\
M+VQA8F5L.FAO<W1297-T<FEC=&EO;CX*(" @(" @/"]L86)E;#I(;W-T<SX*
M(" @(#PO;&%B96PZ:&%S2&]S=%)E<W1R:6-T:6]N<SX*(" @(#QL86)E;#IH
M87-$969A=6QT3&%B96P@<F1F.G)E<V]U<F-E/2(C;&%B96Q?,2(@+SX*(" \
M+VQA8F5L.E)U;&5S970^"@H@(#QL86)E;#I#;VYT96YT3&%B96P@<F1F.DE$
M/2)L86)E;%\Q(CX*(" @(#QR9&9S.F-O;6UE;G0^3&%B96P@9F]R(&%L;"]M
M;W-T(&]F('=E8G-I=&4\+W)D9G,Z8V]M;65N=#X*(" @(#QI8W)A.FYA/C$\
M+VEC<F$Z;F$^"B @(" \:6-R83IN8CXQ/"]I8W)A.FYB/@H@(" @/&EC<F$Z
M;F,^,3PO:6-R83IN8SX*(" @(#QI8W)A.G-A/C$\+VEC<F$Z<V$^"B @(" \
M:6-R83IS8CXQ/"]I8W)A.G-B/@H@(" @/&EC<F$Z<V,^,3PO:6-R83IS8SX*
M(" @(#QI8W)A.G-D/C$\+VEC<F$Z<V0^"B @(" \:6-R83IS93XQ/"]I8W)A
M.G-E/@H@(" @/&EC<F$Z<V8^,3PO:6-R83IS9CX*(" @(#QI8W)A.G9Z/C$\
M+VEC<F$Z=GH^"B @(" \:6-R83IL8CXQ/"]I8W)A.FQB/@H@(" @/&EC<F$Z
M;&,^,3PO:6-R83IL8SX*(" @(#QI8W)A.F]Z/C$\+VEC<F$Z;WH^"B @(" \
M:6-R83IC>CXP/"]I8W)A.F-Z/@H@(" @/')D9G,Z;&%B96P^17AP;W-E9"!B
M<F5A<W1S.R!"87)E(&)U='1O8VMS.R!6:7-I8FQE(&=E;FET86QS.R!087-S
M:6]N871E(&MI<W-I;F<[($]B<V-U<F5D(&]R(&EM<&QI960@<V5X=6%L(&%C
M=',[(%9I<VEB;&4@<V5X=6%L('1O=6-H:6YG.R!%>'!L:6-I="!S97AU86P@
M;&%N9W5A9V4[($5R96-T:6]N<R]E>'!L:6-I="!S97AU86P@86-T<SL@17)O
M=&EC83L@3F\@=FEO;&5N8V4[(%!R;V9A;FET>2!O<B!S=V5A<FEN9SL@36EL
M9"!E>'!L971I=F5S.R!.;R!P;W1E;G1I86QL>2!H87)M9G5L(&%C=&EV:71I
M97,[(%5S97(@9V5N97)A=&5D(&-O;G1E;G0@;6%Y(&)E+"!B=70@:7,@;F]T
M(&MN;W=N('1O(&)E+"!P<F5S96YT.R \+W)D9G,Z;&%B96P^"B @/"]L86)E
<;#I#;VYT96YT3&%B96P^"@H\+W)D9CI21$8^"@``
`
end


From tantek at cs.stanford.edu  Fri Dec 23 12:58:23 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Dec 23 12:59:02 2005
Subject: Just tag it. (was Re: [uf-discuss] "parental guidance" Microformat?)
In-Reply-To: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>
Message-ID: <BFD1A4B3.657AA%tantek@cs.stanford.edu>

On 12/23/05 6:04 AM, "Frederic de Villamil" <neuro@7el.net> wrote:

> Hi list,
> I was lately thinking about a way to tell the most accurate way that a
> link points to a page with content not suitable for people under a
> certain age, such as porn, violence...

What subjects are suitable or not for people of what age differs greatly
across both different cultures in the same time (e.g. in the present), and
the same culture across different times.


> the list should be long.

And for that reason, there shouldn't be a precise list, or taxonomy,
certainly not developed by the microformats community.

For such lists, it is much preferable to use a folksonomy, or simple tags
that each individual in the community applies in their own determination.


> I've been thinking about vote-links, and I'm wondering why we could not
> use rev="pg13" or rev="pg16" in links the way we use vote-for and
> vote-against in vote links.
>
> It would give something like this:
> <a href="http://www.example.com" rev="pg13" title="not suitable for
> people under 13">some page</a>

An effectively identical proposal, rel="xxx" has been proposed and rejected,
please see the archives.

Also, please see the rel-faq which also discusses rev.  This proposal is an
incorrect use of rev.

 http://microformats.org/wiki/rel-faq

In short, rev="vote-for" means the current page is a "vote-for" the
referenced page.

Whereas, it makes no sense to say that the current page is a "pg13" for the
referenced page.


The short answer is, rather than jumping to using a rel or rev value, first
describe what you are trying to do, and then the answer is fairly
straightforward.


My understanding of what you are trying to do is this:


Enable any author on the web to associate one or more keywords pertaining to
aspects of content with a url associated with that content.


As with the rejection of rel="xxx", there is no need to specify a new
specific microformat with specific keywords or tags for this.


The right answer here is to use either xFolk and/or hReview to tag and/or
review the content in question, using whatever tags you want to use.

 http://microformats.org/wiki/xfolk

 http://microformats.org/wiki/hreview

If you want to use the precise meaning of tags or keywords defined by a
particular authority, then you need a URL tagspace for those precise
meanings, as defined in the rel-tag standard.

 http://microformats.org/wiki/rel-tag


Thanks,

Tantek

From paul at msn.com  Fri Dec 23 19:20:46 2005
From: paul at msn.com (Paul Bryson)
Date: Fri Dec 23 19:21:12 2005
Subject: Just tag it. (was Re: [uf-discuss] "parental guidance"
	Microformat?)
References: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>
	<BFD1A4B3.657AA%tantek@cs.stanford.edu>
Message-ID: <doieq9$8ds$1@sea.gmane.org>

"Tantek Ç elik" wrote...
> On 12/23/05 6:04 AM, "Frederic de Villamil" wrote:
>
>> Hi list,
>> I was lately thinking about a way to tell the most accurate way that a
>> link points to a page with content not suitable for people under a
>> certain age, such as porn, violence...
>
> What subjects are suitable or not for people of what age differs greatly
> across both different cultures in the same time (e.g. in the present), and
> the same culture across different times.

It just occurred to me that a very level and relevant measure are the 
commonly used idioms "work safe" and "not work safe".  I don't know if 
"marking appropriate content" is for a microformat or not, but if it is I 
don't think you'll get simpler than that.


Atamido 



From neuro at 7el.net  Sat Dec 24 00:51:06 2005
From: neuro at 7el.net (Frederic de Villamil)
Date: Sat Dec 24 00:52:27 2005
Subject: Just tag it. (was Re: [uf-discuss] "parental guidance"
	Microformat?)
In-Reply-To: <BFD1A4B3.657AA%tantek@cs.stanford.edu>
References: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>
	<BFD1A4B3.657AA%tantek@cs.stanford.edu>
Message-ID: <20051224085106.GB8169@ns99.cdedie.com.cdedie.com>

On Fri, Dec 23, 2005 at 12:58:23PM -0800, Tantek ?elik wrote:
> On 12/23/05 6:04 AM, "Frederic de Villamil" <neuro@7el.net> wrote:
> 
> > Hi list,
> > I was lately thinking about a way to tell the most accurate way that a
> > link points to a page with content not suitable for people under a
> > certain age, such as porn, violence...
> 
> What subjects are suitable or not for people of what age differs greatly
> across both different cultures in the same time (e.g. in the present), and
> the same culture across different times.
> 
> 
> > the list should be long.
> 
> And for that reason, there shouldn't be a precise list, or taxonomy,
> certainly not developed by the microformats community.
> 
> For such lists, it is much preferable to use a folksonomy, or simple tags
> that each individual in the community applies in their own determination.
> 
> 
> > I've been thinking about vote-links, and I'm wondering why we could not
> > use rev="pg13" or rev="pg16" in links the way we use vote-for and
> > vote-against in vote links.
> >
> > It would give something like this:
> > <a href="http://www.example.com" rev="pg13" title="not suitable for
> > people under 13">some page</a>
> 
> An effectively identical proposal, rel="xxx" has been proposed and rejected,
> please see the archives.
> 
> Also, please see the rel-faq which also discusses rev.  This proposal is an
> incorrect use of rev.
> 
>  http://microformats.org/wiki/rel-faq
> 
> In short, rev="vote-for" means the current page is a "vote-for" the
> referenced page.
> 
> Whereas, it makes no sense to say that the current page is a "pg13" for the
> referenced page.
> 
> 
> The short answer is, rather than jumping to using a rel or rev value, first
> describe what you are trying to do, and then the answer is fairly
> straightforward.
> 
> 
> My understanding of what you are trying to do is this:
> 
> 
> Enable any author on the web to associate one or more keywords pertaining to
> aspects of content with a url associated with that content.
> 
> 
> As with the rejection of rel="xxx", there is no need to specify a new
> specific microformat with specific keywords or tags for this.
> 
> 
> The right answer here is to use either xFolk and/or hReview to tag and/or
> review the content in question, using whatever tags you want to use.
> 
>  http://microformats.org/wiki/xfolk
> 
>  http://microformats.org/wiki/hreview
> 
> If you want to use the precise meaning of tags or keywords defined by a
> particular authority, then you need a URL tagspace for those precise
> meanings, as defined in the rel-tag standard.
> 
>  http://microformats.org/wiki/rel-tag
> 
> 
> Thanks,
> 
> Tantek

Tantek,
I did not follow the rejection of rel="xxx" and I misunderstood the real
purpose of rev="xxx" after reading Ryan's article. Thank you for
enlighting me and pointing my mistakes out.

After reading all this, tags are obviously the best way to do what I
wanted to do.
Frederic 
From tantek at cs.stanford.edu  Sat Dec 24 09:18:46 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Dec 24 09:19:24 2005
Subject: Just tag it. (was Re: [uf-discuss] "parental
	guidance"Microformat?)
In-Reply-To: <doieq9$8ds$1@sea.gmane.org>
Message-ID: <BFD2C290.6582B%tantek@cs.stanford.edu>

On 12/23/05 7:20 PM, "Paul Bryson" <paul@msn.com> wrote:

> "Tantek ? elik" wrote...
>> On 12/23/05 6:04 AM, "Frederic de Villamil" wrote:
>> 
>>> Hi list,
>>> I was lately thinking about a way to tell the most accurate way that a
>>> link points to a page with content not suitable for people under a
>>> certain age, such as porn, violence...
>> 
>> What subjects are suitable or not for people of what age differs greatly
>> across both different cultures in the same time (e.g. in the present), and
>> the same culture across different times.
> 
> It just occurred to me that a very level and relevant measure are the
> commonly used idioms "work safe" and "not work safe".

My statement above still applies and perhaps even more so.

What is regarded as "work safe" or not content greatly varies from say Saudi
Arabia, to the US, to Sweden.

Even in the US, it has both changed over time, and is quite different in
different locations, e.g. a beach lifeguard tower, a car repair shop, or an
accounting firm.

In addition, common practice on the web is to use the abbreviation NSFW in
text.  It's even used as a consistent tag across several tagging services:

http://technorati.com/tag/nsfw  (results themselves are likely NSFW!)

> I don't know if 
> "marking appropriate content" is for a microformat or not, but if it is I
> don't think you'll get simpler than that.

Actually, you can get simpler, in two ways:

1. Use zero additional microformats instead of creating a new one.

Again, xFolk and/or hReview can already serve the need of tagging things
with arbitrary terms.

2. Use just one tag instead of two.

In practice, few people mark things explicitly as "work safe".  Nearly all
such indication is "NSFW", the presumption being that lack of that tag means
it is work safe (though not necessarily so).  Thus feel free to use
xFolk/hReview to tag items as NSFW if that's your opinion of those items.

Thanks,

Tantek

From benjamincarlyle at optusnet.com.au  Sun Dec 25 22:05:04 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Sun Dec 25 22:04:13 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <43843033.4080802@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com>
Message-ID: <1135577105.6008.29.camel@tori>

On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
> Have at it:
> http://microformats.org/wiki/hatom

I have been thinking a little about what feeds are and what they will be
used for. Currently my own mostly-hAtom-formatted blog[1] has no feed
element. Essentially, the page is the feed. Are feed elements useful?
Are they required? I have been having the following arguments with
myself.

Argument 1: They exist in atom, so should exist in hAtom
<feed> is the top-level element in atom, amounting to <html>. Only one
is ever permitted in a single document. Contrast this to the current
proposal to allow multiple class=feed elements within a hAtom document.
I think this argument is invalid.

Argument 2: They exist in the wild, so should exist in hAtom
My blog does not currently have a div around its class=entry elements,
so this is not univeral. I suspect my blog is in a minority, but I think
this argument is still invalid.

Argument 3: Web pages with multiple feeds on them exist in the wild, so
hAtom should support multiple feeds in a page
This is probably the central argument at present, but it is perhaps
useful to consider how hAtom might be used in the future. Let's first
look at the examples:
Google News <http://news.google.ca/nwshp?hl=en&tab=wn&q=> lists entries
grouped by category. It provides a single atom feed for this page at
<http://news.google.ca/nwshp?hl=en&tab=wn&q=&output=atom> which combines
entries into a single page-ordered feed.
The Truth Laid Bear <http://www.truthlaidbear.com/topics.php>. This page
does not provide an atom alternative but follows the basic "by-category"
ordering used by google.
Are these separate feeds, or is it a single feed ordered by category?
Personally I would lean towards the latter interpretation. "The Truth
Laid Bear" also includes a miniblog which contains advertising. I would
guess that if they did provide an atom feed they would prefer to see
these entries included within than left out, or in a separate feed.
In short, I am not sure I have seen a case yet where multiple feeds
exist on the one page. Order of blog entries can be defined by the
publisher as either by-date or by-category, but these may still be
placed in a single feed structure.

I kind of feel that hAtom may be better off without a feed element, not
only because of the reasons above but because it might improve hAtom's
applicability. I think it would be a simpler standard if it didn't
define a feed level (and it subsequent interacton with the entry level).
If it specalised to do entries really well then I imagine that non-blog
uses might appear also to take advantage of the entry concept. Entry now
becomes something like "a piece of content with author and publication
metadata attached".

This also brings to light the question of what a parser should do with a
page that contains multiple feeds. A valid Atom document can't be
produced. Multiple documents would be required. In fact, I think the
absence of explicit feed elements might make more sense. A client could
point at http://example.com/blog/ in order to get an atom feed of
everything on the page, or at http://example.com/blog/#Iraq to locate
the element with id=Iraq and any elements contained within it. In
essence this approach would allow a hierarchical but otherwise freeform
feed construction on a hAtom page that contains particular subsets of
class=entry elements.

I just want to also question the utility of marking up single-entry
feeds such as
<http://www.microformats.org/blog/2005/09/30/web-essentials-audio/>.
Atom is primarily used to monitor web pages for changes, and I would see
that as the primary market for hAtom for the near future. A single entry
feed is (by definition?) one that won't change, thus subscribing to it
or syndicating it doesn't necessarily make sense to me. I can possibly
see how entries such as these could help search engines, but I don't
have a specific use case in mind at all. I guess the question is "How
does a single-entry hAtom feed differ from the web page that would
otherwise be there"? Thoughts?

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
[1] http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/

From ryan at technorati.com  Sun Dec 25 12:22:56 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Dec 26 13:33:08 2005
Subject: [uf-discuss] "parental guidance" Microformat?
In-Reply-To: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>
References: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>
Message-ID: <50EE461C-5B5A-4768-9C79-079CD8BE8961@technorati.com>

On Dec 23, 2005, at 6:04 AM, Frederic de Villamil wrote:

> Hi list,
> I was lately thinking about a way to tell the most accurate way that a
> link points to a page with content not suitable for people under a
> certain age, such as porn, violence... the list should be long.
> This reflexion came after a French law was voted that force Internet
> providers to provide a parental control tool to every user. I think
> having a microformat doing that sort of thing would greatly help those
> tools to work, much more than page content analysis which is not  
> always
> relevant.
>
> I've been thinking about vote-links, and I'm wondering why we could  
> not
> use rev="pg13" or rev="pg16" in links the way we use vote-for and
> vote-against in vote links.

It is an abuse of the 'rev' semantics. "pg13" does not describe the  
*reverse relationship* between the two documents.

These kind of 3rd party assertions don't work very well on the web.

-rk
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Sun Dec 25 12:26:00 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Dec 26 13:33:12 2005
Subject: Just tag it. (was Re: [uf-discuss] "parental guidance"
	Microformat?)
In-Reply-To: <doieq9$8ds$1@sea.gmane.org>
References: <20051223140400.GA21242@ns99.cdedie.com.cdedie.com>
	<BFD1A4B3.657AA%tantek@cs.stanford.edu>
	<doieq9$8ds$1@sea.gmane.org>
Message-ID: <787D19AE-7998-4A0C-A444-0FF2D889CE7F@technorati.com>

On Dec 23, 2005, at 7:20 PM, Paul Bryson wrote:
> "Tantek ? elik" wrote...
>> On 12/23/05 6:04 AM, "Frederic de Villamil" wrote:
>>
>>> Hi list,
>>> I was lately thinking about a way to tell the most accurate way  
>>> that a
>>> link points to a page with content not suitable for people under a
>>> certain age, such as porn, violence...
>>
>> What subjects are suitable or not for people of what age differs  
>> greatly
>> across both different cultures in the same time (e.g. in the  
>> present), and
>> the same culture across different times.
>
> It just occurred to me that a very level and relevant measure are the
> commonly used idioms "work safe" and "not work safe".  I don't know if
> "marking appropriate content" is for a microformat or not, but if  
> it is I
> don't think you'll get simpler than that.

The definition of "work safe" is going to vary greatly from one  
culture and workplace to another. This is still a case for tagging.

-rk
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Mon Dec 26 06:43:30 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Dec 26 13:33:17 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <1135577105.6008.29.camel@tori>
References: <43843033.4080802@blogmatrix.com> <1135577105.6008.29.camel@tori>
Message-ID: <B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>

On Dec 26, 2005, at 12:05 AM, Benjamin Carlyle wrote:
> On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote:
>> Have at it:
>> http://microformats.org/wiki/hatom
>
> I have been thinking a little about what feeds are and what they  
> will be
> used for. Currently my own mostly-hAtom-formatted blog[1] has no feed
> element. Essentially, the page is the feed. Are feed elements useful?
> Are they required? I have been having the following arguments with
> myself.
>
> Argument 1: They exist in atom, so should exist in hAtom
> <feed> is the top-level element in atom, amounting to <html>. Only one
> is ever permitted in a single document. Contrast this to the current
> proposal to allow multiple class=feed elements within a hAtom  
> document.
> I think this argument is invalid.

When creating microformats, we explicitly try to keep things  
compatible with existing formats, so that they can be transformed in  
a reasonably easy way. We've made compromises with hcard, hcalendar  
and hatom for precisely this purpose. I don't think this argument is  
invalid.

> Argument 2: They exist in the wild, so should exist in hAtom
> My blog does not currently have a div around its class=entry elements,
> so this is not univeral. I suspect my blog is in a minority, but I  
> think
> this argument is still invalid.

Once again, I think this argument is invalid- we're explicitly  
designing for the majority, even if it means the minority gets ignored.

> Argument 3: Web pages with multiple feeds on them exist in the  
> wild, so
> hAtom should support multiple feeds in a page
> This is probably the central argument at present, but it is perhaps
> useful to consider how hAtom might be used in the future. Let's first
> look at the examples:
> Google News <http://news.google.ca/nwshp?hl=en&tab=wn&q=> lists  
> entries
> grouped by category. It provides a single atom feed for this page at
> <http://news.google.ca/nwshp?hl=en&tab=wn&q=&output=atom> which  
> combines
> entries into a single page-ordered feed.
> The Truth Laid Bear <http://www.truthlaidbear.com/topics.php>. This  
> page
> does not provide an atom alternative but follows the basic "by- 
> category"
> ordering used by google.
> Are these separate feeds, or is it a single feed ordered by category?

 From the perspective of someone working on the spec, it doesn't  
matter. Google can choose to do it either way.

> Personally I would lean towards the latter interpretation. "The Truth
> Laid Bear" also includes a miniblog which contains advertising. I  
> would
> guess that if they did provide an atom feed they would prefer to see
> these entries included within than left out, or in a separate feed.
> In short, I am not sure I have seen a case yet where multiple feeds
> exist on the one page. Order of blog entries can be defined by the
> publisher as either by-date or by-category, but these may still be
> placed in a single feed structure.

There are a number of blogs which syndicate other feeds into their  
blog. While this isn't the most interesting case for syndication, we  
should still be allowed to mark up those bits of content as feeds  
('cause that's what they are).

> I kind of feel that hAtom may be better off without a feed element,  
> not
> only because of the reasons above but because it might improve hAtom's
> applicability. I think it would be a simpler standard if it didn't
> define a feed level (and it subsequent interacton with the entry  
> level).
> If it specalised to do entries really well then I imagine that non- 
> blog
> uses might appear also to take advantage of the entry concept.  
> Entry now
> becomes something like "a piece of content with author and publication
> metadata attached".

I don't think so. So far, all you need to have a feed is  
class="feed." I don't think this is much of a burden, and you can  
always apply it to the <body> tag, if you want your entire page to be  
the feed.

> This also brings to light the question of what a parser should do  
> with a
> page that contains multiple feeds. A valid Atom document can't be
> produced. Multiple documents would be required.

I'd say just return the first one.

> In fact, I think the
> absence of explicit feed elements might make more sense. A client  
> could
> point at http://example.com/blog/ in order to get an atom feed of
> everything on the page, or at http://example.com/blog/#Iraq to locate
> the element with id=Iraq and any elements contained within it. In
> essence this approach would allow a hierarchical but otherwise  
> freeform
> feed construction on a hAtom page that contains particular subsets of
> class=entry elements.
>
> I just want to also question the utility of marking up single-entry
> feeds such as
> <http://www.microformats.org/blog/2005/09/30/web-essentials-audio/>.
> Atom is primarily used to monitor web pages for changes, and I  
> would see
> that as the primary market for hAtom for the near future. A single  
> entry
> feed is (by definition?) one that won't change, thus subscribing to it
> or syndicating it doesn't necessarily make sense to me.

Blog posts can and *do* change. There's no argument here.

Plus, remember, hAtom, though its use case is syndication, is also  
useful in that it *applies semantics,* which can be parsed and  
understood by user agents. For example, the guys at Flock could use  
hAtom markup for doing proper citations when quoting blog posts. Mo'  
data, mo' betta.

> I can possibly
> see how entries such as these could help search engines, but I don't
> have a specific use case in mind at all. I guess the question is "How
> does a single-entry hAtom feed differ from the web page that would
> otherwise be there"? Thoughts?

More explicit semantics. 'nuff said.

-rk

> -- 
> Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
> [1] http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

--
Ryan King
ryan@technorati.com



From benjamincarlyle at optusnet.com.au  Tue Dec 27 06:21:40 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Tue Dec 27 06:20:47 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>
References: <43843033.4080802@blogmatrix.com> <1135577105.6008.29.camel@tori>
	<B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>
Message-ID: <1135693300.5514.60.camel@tori>

Ryan,

Rather than trying to get into too detailed a discussion over email I'll
try to catch you in irc some time. Email isn't the best forum for the
resolution of technical questions :)

I'll just summarise my main feelings at this time:

* The hAtom specification does not define any child elements of a
class=feed element, except for class=entry elements. The specification
is at a tipping point where the additional feed-level elements could all
be defined or all be left out. I lean towards the latter, except for the
definitions of the required <atom:id> and <atom:updated> fields. These
are the only things missing from the current specification required to
translate hAtom to valid Atom.
* I think that the <atom:entry> concept is more important than the
<atom:feed> and is in a good state in the current hAtom. I think
defining the set of elements for <atom:feed> may be a case of
diminishing returns.

I will do some more thinking about how feeds would work in the examples
currently available. I am in two minds as to whether I feel they should
be available for use or not. It seems reasonable to be able to define
disjoint feeds on a single page, but these would have to be addressable
using id attributes for parsers to subscribe to them. Nested feeds would
not be supported, but categorisation within a single feed could affect
ordering and presentation in a client such as a feed reader.

On Mon, 2005-12-26 at 08:43 -0600, Ryan King wrote:
> On Dec 26, 2005, at 12:05 AM, Benjamin Carlyle wrote:
> > I have been thinking a little about what feeds are and what they  
> > will be
> > used for. Currently my own mostly-hAtom-formatted blog[1] has no feed
> > element. Essentially, the page is the feed. Are feed elements useful?
> > Are they required? I have been having the following arguments with
> > myself.
...

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From paul at msn.com  Tue Dec 27 13:10:10 2005
From: paul at msn.com (Paul Bryson)
Date: Tue Dec 27 13:10:09 2005
Subject: [uf-discuss] hAtom draft - class="title"
References: <43843033.4080802@blogmatrix.com>
Message-ID: <dosaiu$tqd$1@sea.gmane.org>

I'm just looking for extra confirmation of this little problem before 
touching the wiki.  It appears that hAtom uses the class attribute "title" 
for it's title, such as what would go in a heading <hn>  However, the hCard 
also uses "title", but in a completely different context.

The problem arises if an hCard, which contains a "title", is located inside 
of an hAtom, especially prior to the hAtom's "title".  The specification 
says:

    *  the first hAtom valid element with a class="title" is the Entry Title
    hAtom valid meaning somewhere where we expect it (like not inside Entry 
Content, for example).
    * otherwise, the first hAtom valid <h#> element to appear in an hAtom 
document is the Entry Title
    * otherwise, the Entry Title is the empty string
    Atom does not allow for an entry not to have a title.

It almost sounds like it cannot use a "title" from within the hCard, but it 
isn't very clear.  Is this wrong, or could someone provide clearer verbiage?


Atamido

"David Janes -- BlogMatrix"wrote...
> Have at it:
> http://microformats.org/wiki/hatom
>
> Regards, etc...
> David
> http://www.blogmatrix.com 



From davidjanes at blogmatrix.com  Tue Dec 27 13:35:52 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Tue Dec 27 13:35:54 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <dosaiu$tqd$1@sea.gmane.org>
References: <43843033.4080802@blogmatrix.com> <dosaiu$tqd$1@sea.gmane.org>
Message-ID: <43B1B3B8.1020902@blogmatrix.com>

Hi Paul,

hAtom:content, hAtom:author and hAtom:contributor are all opaque [1], 
that is, hAtom parsers must stop searching for hAtom content within 
these elements.

Thus, you can safely nest a hCard side any of these elements without 
worry of conflicts. There has been an issue raised [2] about hCards 
appearing in other places. I'm not sure if it's a critical issue on 
80-20 principles.

Regards, etc...
David
http://www.blogmatrix.com

[1] http://microformats.org/wiki/hatom#Nesting_Rules
[2] 
http://microformats.org/wiki/hatom-issues#Opaqueness_of_other_microformat_elements

Paul Bryson wrote:
> I'm just looking for extra confirmation of this little problem before 
> touching the wiki.  It appears that hAtom uses the class attribute "title" 
> for it's title, such as what would go in a heading <hn>  However, the hCard 
> also uses "title", but in a completely different context.
> 
> The problem arises if an hCard, which contains a "title", is located inside 
> of an hAtom, especially prior to the hAtom's "title".  The specification 
> says:
> 
>     *  the first hAtom valid element with a class="title" is the Entry Title
>     hAtom valid meaning somewhere where we expect it (like not inside Entry 
> Content, for example).
>     * otherwise, the first hAtom valid <h#> element to appear in an hAtom 
> document is the Entry Title
>     * otherwise, the Entry Title is the empty string
>     Atom does not allow for an entry not to have a title.
> 
> It almost sounds like it cannot use a "title" from within the hCard, but it 
> isn't very clear.  Is this wrong, or could someone provide clearer verbiage?
> 
> 
> Atamido
From tantek at cs.stanford.edu  Tue Dec 27 15:43:00 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Dec 27 15:43:41 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <43B1B3B8.1020902@blogmatrix.com>
Message-ID: <BFD71181.659D5%tantek@cs.stanford.edu>

Paul,

You're right about the issue.

In general we should be avoiding vocabulary divergence or confusion wherever
possible.

This means working deliberately to avoid the two cardinal sins that
namespaces typical both enable and encourage:

1. The same term is used to mean two different things
2. Two terms are used to mean the same things

The current "established" microformats have avoided this problem by
essentially reusing from earlier microformats when possible, *before*
reusing from other standards.

E.g. hReview has reused a lot from hCard and hCalendar.

See http://microformats.org/wiki/existing-classes for an overview.

In the case of 'title', Paul is right.  hCard (by way of vCard) has defined
'title' to mean something in particular.

In the case of hReview, we used 'summary' from hCalendar to serve this
purpose.

Would it be possible to do so for hAtom as well?

Thanks,

Tantek



On 12/27/05 1:35 PM, "David Janes -- BlogMatrix" <davidjanes@blogmatrix.com>
wrote:

> Hi Paul,
> 
> hAtom:content, hAtom:author and hAtom:contributor are all opaque [1],
> that is, hAtom parsers must stop searching for hAtom content within
> these elements.
> 
> Thus, you can safely nest a hCard side any of these elements without
> worry of conflicts. There has been an issue raised [2] about hCards
> appearing in other places. I'm not sure if it's a critical issue on
> 80-20 principles.
> 
> Regards, etc...
> David
> http://www.blogmatrix.com
> 
> [1] http://microformats.org/wiki/hatom#Nesting_Rules
> [2] 
> http://microformats.org/wiki/hatom-issues#Opaqueness_of_other_microformat_elem
> ents
> 
> Paul Bryson wrote:
>> I'm just looking for extra confirmation of this little problem before
>> touching the wiki.  It appears that hAtom uses the class attribute "title"
>> for it's title, such as what would go in a heading <hn>  However, the hCard
>> also uses "title", but in a completely different context.
>> 
>> The problem arises if an hCard, which contains a "title", is located inside
>> of an hAtom, especially prior to the hAtom's "title".  The specification
>> says:
>> 
>>     *  the first hAtom valid element with a class="title" is the Entry Title
>>     hAtom valid meaning somewhere where we expect it (like not inside Entry
>> Content, for example).
>>     * otherwise, the first hAtom valid <h#> element to appear in an hAtom
>> document is the Entry Title
>>     * otherwise, the Entry Title is the empty string
>>     Atom does not allow for an entry not to have a title.
>> 
>> It almost sounds like it cannot use a "title" from within the hCard, but it
>> isn't very clear.  Is this wrong, or could someone provide clearer verbiage?
>> 
>> 
>> Atamido

From benjamincarlyle at optusnet.com.au  Tue Dec 27 19:21:12 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Tue Dec 27 19:20:21 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <BFD71181.659D5%tantek@cs.stanford.edu>
References: <BFD71181.659D5%tantek@cs.stanford.edu>
Message-ID: <1135740073.6087.14.camel@tori>

Tantek et al,

On Tue, 2005-12-27 at 15:43 -0800, Tantek ?elik wrote:
> In general we should be avoiding vocabulary divergence or confusion wherever
> possible.
...
> See http://microformats.org/wiki/existing-classes for an overview.

I am mostly unfamiliar with hReview, so I may be off on some points. I
have tried to summarise below the list of hAtom elements which different
in interpretation from existing elements, and those whose names are
different but functions may be the same.

The following hAtom element definitions differ from those described in
existing-classes:
* hAtom uses only bookmark (not self) for its permalink. hReview uses
both.
* hAtom summary is a summary of the entry content which is both shorter
than the content and longer than the title. This may differ from
hCalendar whose summary appears more similar to hAtom's title
* hAtom title means "entry title", not "person title"

The definition of the following hAtom elements may have different names
in other vocabularies:
* hAtom content may be the same as hReview description
* hAtom published may be the same as hReview dtreviewed
* hAtom author may be the same as hReview reviewer
* hAtom title or <h?> may be the same as hCalendar summary

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From paul at msn.com  Tue Dec 27 21:23:08 2005
From: paul at msn.com (Paul Bryson)
Date: Tue Dec 27 21:23:01 2005
Subject: [uf-discuss] hAtom draft - class="title"
References: <43B1B3B8.1020902@blogmatrix.com>
	<BFD71181.659D5%tantek@cs.stanford.edu>
Message-ID: <dot7f6$b39$1@sea.gmane.org>

"Tantek Ç elik" wrote...
> See http://microformats.org/wiki/existing-classes for an overview.

Ugh, someone should really update that page.


Atamido 



From davidjanes at blogmatrix.com  Wed Dec 28 05:41:00 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 05:41:05 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <1135693300.5514.60.camel@tori>
References: <43843033.4080802@blogmatrix.com>
	<1135577105.6008.29.camel@tori>	<B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>
	<1135693300.5514.60.camel@tori>
Message-ID: <43B295EC.4050409@blogmatrix.com>

I've been thinking about the feed issue for a while now (obviously), 
plus I've had a few e-mails with Benjamin and so forth. For a while I 
was leaning toward depreciating or removing the feed element, but I'm 
more or less back to where I've started, with one minor mod.

- feed is a part of Atom which suggests (but does not require) its 
presence in hAtom
- feed is easy and harmless to add to templates
- conceptually, it's a good idea to group like things
- requiring an explicit feed element makes it easier to avoid 
"accidental" name space collision

Disambiguation:
- multiple feeds on one page can be differentiated by the id/uri fragments
- if not expecting multiple feeds, the first feed can be considered the 
feed for the page, even if others exist.

Although not covered explicitly in the examples, my latest thought is to 
allow a Feed element to be embedded in an Entry element. Why? To model a 
comment feed, which obviously is blog like content.

Regards, etc...
David
http://www.blogmatrix.com

Benjamin Carlyle wrote:
> Ryan,
> 
> Rather than trying to get into too detailed a discussion over email I'll
> try to catch you in irc some time. Email isn't the best forum for the
> resolution of technical questions :)
> 
> I'll just summarise my main feelings at this time:
> 
> * The hAtom specification does not define any child elements of a
> class=feed element, except for class=entry elements. The specification
> is at a tipping point where the additional feed-level elements could all
> be defined or all be left out. I lean towards the latter, except for the
> definitions of the required <atom:id> and <atom:updated> fields. These
> are the only things missing from the current specification required to
> translate hAtom to valid Atom.
> * I think that the <atom:entry> concept is more important than the
> <atom:feed> and is in a good state in the current hAtom. I think
> defining the set of elements for <atom:feed> may be a case of
> diminishing returns.
> 
> I will do some more thinking about how feeds would work in the examples
> currently available. I am in two minds as to whether I feel they should
> be available for use or not. It seems reasonable to be able to define
> disjoint feeds on a single page, but these would have to be addressable
> using id attributes for parsers to subscribe to them. Nested feeds would
> not be supported, but categorisation within a single feed could affect
> ordering and presentation in a client such as a feed reader.
> 
> On Mon, 2005-12-26 at 08:43 -0600, Ryan King wrote:
>> On Dec 26, 2005, at 12:05 AM, Benjamin Carlyle wrote:
>>> I have been thinking a little about what feeds are and what they  
>>> will be
>>> used for. Currently my own mostly-hAtom-formatted blog[1] has no feed
>>> element. Essentially, the page is the feed. Are feed elements useful?
>>> Are they required? I have been having the following arguments with
>>> myself.
> ...
> 

From davidjanes at blogmatrix.com  Wed Dec 28 05:59:47 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 05:59:50 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <BFD71181.659D5%tantek@cs.stanford.edu>
References: <BFD71181.659D5%tantek@cs.stanford.edu>
Message-ID: <43B29A53.7050106@blogmatrix.com>

Tantek,

If it's an explicit goal of the microformats.org process to come up with 
a CSS name -> microformat meaning, it'd be nice explicitly recognize 
this, especially with something like a dictionary.

I think it's not a bad idea, but I don't universally think it should be 
done (see point #5 below).

Here's my thoughts:

(1)
The concept of the word "title" meaning the title of a document is part 
of HTML. Obviously, we're doing it differently (CSS names vs. an 
explicit element), but the thought is there. Is not HTML the ur-Microformat?

(2)
hcalendar:summary sort of means a title and could be potentially reused 
in hAtom. However, using the word "summary" for title in the context of 
webloging, atom feeds and so forth in large degree clashes with the 
expected meaning in that domain and would lead to at least a little 
confusion.

(3)
hcard:title reserving the meaning of the word "title" to mean the title 
of a person is ... a little narrow. However, if we do want to keep a 
canonical dictionary for microformats, hAtom and other standards should 
probably roll with the punches.

(4)
New class names could be invented: atomtitle, atomsummary, entrytitle, 
entrysummary, entry-title, entry-summary, subject, synopsis and so forth 
come to mind. If the canonical dictionary is a overriding goal, choosing 
something from this list may be the way to go.

If we went with just entry-title and entry-summary, users may be a 
little confused by author, contributor, and so forth. If we made it 
consistent by adding "entry-" in front of them, we're effectively 
defining a namespace, in which case why not use "atom-" and be done with?

(5)
Having unique-name -> unique-meaning doesn't get us around the problem 
of nesting. For example, if we chose the word "summary" to replace 
hatom:title, we would still have the problem of nested hCalendars in 
hAtom content.

Everyone's thoughts are appreciated and solicited on this matter, as the 
sooner it gets resolved, the better I'll feel going around plugging hAtom.

Regards, etc...
David

Tantek ?elik wrote:
> Paul,
> 
> You're right about the issue.
> 
> In general we should be avoiding vocabulary divergence or confusion wherever
> possible.
> 
> This means working deliberately to avoid the two cardinal sins that
> namespaces typical both enable and encourage:
> 
> 1. The same term is used to mean two different things
> 2. Two terms are used to mean the same things
> 
> The current "established" microformats have avoided this problem by
> essentially reusing from earlier microformats when possible, *before*
> reusing from other standards.
> 
> E.g. hReview has reused a lot from hCard and hCalendar.
> 
> See http://microformats.org/wiki/existing-classes for an overview.
> 
> In the case of 'title', Paul is right.  hCard (by way of vCard) has defined
> 'title' to mean something in particular.
> 
> In the case of hReview, we used 'summary' from hCalendar to serve this
> purpose.
> 
> Would it be possible to do so for hAtom as well?

From paul at msn.com  Wed Dec 28 11:57:35 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 11:57:50 2005
Subject: [uf-discuss] XOXO Comments
References: <dockpg$12r$1@sea.gmane.org>
Message-ID: <douqml$s0i$1@sea.gmane.org>

For the sake of simplicity in JavaScript, it would be nice to be able to 
give all <ul> in an XOXO the class="xoxo".  So I might have:

<ul class="xoxo">
 <li><a>Linkblogs</a>
   <ul class="xoxo">
     <li>dive into mark b-links</li>
     <li>Erics Weblog</li>
   </ul>
 </li>
 <li><a>Another link</a></li>
</ul>

Is the class="xoxo" only allowed on the primary parent?  Would this be 
broken?


Atamido

"Paul Bryson" <paul@msn.com> wrotexoxo
> The XOXO format doesn't seem to allow, or specify, the use of heading 
> elements for multi-level outlines, such as <h2>, <h3>, etc.  Is there a 
> reason for this?
>
> This example uses <p>
> http://diveintomark.org/public/2004/01/xo-embeddable.xo
>
> This one uses <span> and <a>
> http://homepage.mac.com/ctholland/thelab/outlines/
>
>
> Also, none of these examples seem to use class="xoxo" in them.  Is this a 
> required feature, or optional?
>
>
> Atamido 



From drernie at opendarwin.org  Wed Dec 28 12:00:55 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Wed Dec 28 12:01:01 2005
Subject: [uf-discuss] XOXO Comments
In-Reply-To: <douqml$s0i$1@sea.gmane.org>
References: <dockpg$12r$1@sea.gmane.org> <douqml$s0i$1@sea.gmane.org>
Message-ID: <CF22FCA8-37AC-4FD3-8DD6-0C4C1136119A@opendarwin.org>

Hi Paul,

> Is the class="xoxo" only allowed on the primary parent?  Would this be
> broken?

I don't think it is "forbidden", but as a practical matter  I don't  
think it should (or even -can-) be "required."  Speaking at least for  
myself, I don't want to have to tag every sublist.  This is one of  
those cases where (as usual ;-) its better to make the parser-writer  
do a little extra work to make things easier on the content creator.

-- Ernie P.

On Dec 28, 2005, at 11:57 AM, Paul Bryson wrote:

> For the sake of simplicity in JavaScript, it would be nice to be  
> able to
> give all <ul> in an XOXO the class="xoxo".  So I might have:
>
> <ul class="xoxo">
>  <li><a>Linkblogs</a>
>    <ul class="xoxo">
>      <li>dive into mark b-links</li>
>      <li>Erics Weblog</li>
>    </ul>
>  </li>
>  <li><a>Another link</a></li>
> </ul>
>
> Is the class="xoxo" only allowed on the primary parent?  Would this be
> broken?
>
>
> Atamido
>
> "Paul Bryson" <paul@msn.com> wrotexoxo
>> The XOXO format doesn't seem to allow, or specify, the use of heading
>> elements for multi-level outlines, such as <h2>, <h3>, etc.  Is  
>> there a
>> reason for this?
>>
>> This example uses <p>
>> http://diveintomark.org/public/2004/01/xo-embeddable.xo
>>
>> This one uses <span> and <a>
>> http://homepage.mac.com/ctholland/thelab/outlines/
>>
>>
>> Also, none of these examples seem to use class="xoxo" in them.  Is  
>> this a
>> required feature, or optional?
>>
>>
>> Atamido
>
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From davidjanes at blogmatrix.com  Wed Dec 28 12:33:05 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 12:33:07 2005
Subject: [uf-discuss] XOXO Comments
In-Reply-To: <douqml$s0i$1@sea.gmane.org>
References: <dockpg$12r$1@sea.gmane.org> <douqml$s0i$1@sea.gmane.org>
Message-ID: <43B2F681.7070604@blogmatrix.com>

What are you trying to do in Javascript? Certainly, you couldn't expect 
all XOXO's in the wild to look like this.

Regards, etc...
David

Paul Bryson wrote:
> For the sake of simplicity in JavaScript, it would be nice to be able to 
> give all <ul> in an XOXO the class="xoxo".  So I might have:
> 
> <ul class="xoxo">
>  <li><a>Linkblogs</a>
>    <ul class="xoxo">
>      <li>dive into mark b-links</li>
>      <li>Erics Weblog</li>
>    </ul>
>  </li>
>  <li><a>Another link</a></li>
> </ul>
> 
> Is the class="xoxo" only allowed on the primary parent?  Would this be 
> broken?
From paul at msn.com  Wed Dec 28 12:59:14 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 12:59:07 2005
Subject: [uf-discuss] XOXO Comments
References: <dockpg$12r$1@sea.gmane.org> <douqml$s0i$1@sea.gmane.org>
	<43B2F681.7070604@blogmatrix.com>
Message-ID: <douua8$c30$1@sea.gmane.org>

"David Janes -- BlogMatrix" wrote...
> What are you trying to do in Javascript? Certainly, you couldn't expect 
> all XOXO's in the wild to look like this.

Not at all.  I want the JavaScript on MY page to be simple, I think I can 
make it work easiest if every child of an XOXO on MY page has a 
class="xoxo".  So I was wondering if this is allowed or not.

I was not suggesting that any other page on the internet do the same as what 
I am trying to do.


Atamido 



From davidjanes at blogmatrix.com  Wed Dec 28 13:14:58 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 13:15:01 2005
Subject: [uf-discuss] XOXO Comments
In-Reply-To: <douua8$c30$1@sea.gmane.org>
References: <dockpg$12r$1@sea.gmane.org>
	<douqml$s0i$1@sea.gmane.org>	<43B2F681.7070604@blogmatrix.com>
	<douua8$c30$1@sea.gmane.org>
Message-ID: <43B30052.8050202@blogmatrix.com>

Try MochiKit [1].

var xoxo_elements = getElementsByTagAndClassName("*", "xoxo")
for (var xi = 0; xi < xoxo_elements.length; xi++) {
    var children = getElementsByTagAndClassName("*")
    for (var ci = 0; ci < children.length; ci++) {
       element = children[ci]
       if ((element.tagName == "UL") || (element.tagName == "OL")) {
           // ... do stuff ...
       }
    }
}

Regards, etc...
David

[1] http://www.mochikit.com/doc/html/MochiKit/DOM.html

Paul Bryson wrote:
> "David Janes -- BlogMatrix" wrote...
>> What are you trying to do in Javascript? Certainly, you couldn't expect 
>> all XOXO's in the wild to look like this.
> 
> Not at all.  I want the JavaScript on MY page to be simple, I think I can 
> make it work easiest if every child of an XOXO on MY page has a 
> class="xoxo".  So I was wondering if this is allowed or not.
> 
> I was not suggesting that any other page on the internet do the same as what 
> I am trying to do.
> 
> 
> Atamido 
> 
> 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 
> 

From paul at msn.com  Wed Dec 28 13:02:46 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 13:21:20 2005
Subject: [uf-discuss] hAtom draft - class="title"
References: <43843033.4080802@blogmatrix.com> <dosaiu$tqd$1@sea.gmane.org>
Message-ID: <douugr$cvg$1@sea.gmane.org>

"Paul Bryson" wrote...
> I'm just looking for extra confirmation of this little problem before 
> touching the wiki.  It appears that hAtom uses the class attribute "title" 
> for it's title, such as what would go in a heading <hn>  However, the 
> hCard also uses "title", but in a completely different context.

Here is an example of what I am trying to do.
http://files.commo.de/md-lite/mdforum/topic-combined-2.html


Atamido 



From paul at msn.com  Wed Dec 28 13:13:19 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 13:27:41 2005
Subject: [uf-discuss] Avatar Microformat ?
References: <84ce626f0511232305mb7d12b7hcecb2c3851494f39@mail.gmail.com><BFAACC24.640A1%tantek@cs.stanford.edu><1bc4603e0511241219vecd0b9aj92d53d6741dbeeb5@mail.gmail.com><84ce626f0511241343h7b178c77rc33eab6dac8f0c5d@mail.gmail.com><4341199A-FF2C-4907-9AD9-12131F2B7914@technorati.com>
	<84ce626f0511281426h707477actd6d026d99786ce13@mail.gmail.com>
Message-ID: <douv4l$er1$1@sea.gmane.org>

"Charles Iliya Krempeaux" 
<supercanadian@gmail.com> wrote...
> I'd agree with this if hCards allowed for multiple PHOTO's or LOGO's.
> So, from my perspective, the question comes down to: does an hCard
> support mutiple PHOTO's or LOGO's?  (My understanding so far is that
> they don't.  But please correct me if I'm wrong.)

I am currently using "logo" to display an avatar.  But I am curious if more 
than one photo/logo is allowed per hCard.


Paul Bryson 



From davidjanes at blogmatrix.com  Wed Dec 28 13:43:20 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 13:43:22 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <douugr$cvg$1@sea.gmane.org>
References: <43843033.4080802@blogmatrix.com> <dosaiu$tqd$1@sea.gmane.org>
	<douugr$cvg$1@sea.gmane.org>
Message-ID: <43B306F8.80702@blogmatrix.com>

Nice. I just discovered a bug in my parser that screwed up the title 
nesting. Here's [1] the new and improved version.

You'll want to move class="logo" from the <li> down to the <img> where 
it belongs though.

Regards, etc...
David

[1] http://tinyurl.com/bqevh

Paul Bryson wrote:
> "Paul Bryson" wrote...
>> I'm just looking for extra confirmation of this little problem before 
>> touching the wiki.  It appears that hAtom uses the class attribute "title" 
>> for it's title, such as what would go in a heading <hn>  However, the 
>> hCard also uses "title", but in a completely different context.
> 
> Here is an example of what I am trying to do.
> http://files.commo.de/md-lite/mdforum/topic-combined-2.html
> 
> 
> Atamido 
> 
> 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 
> 

From pilgrim at gmail.com  Wed Dec 28 13:57:58 2005
From: pilgrim at gmail.com (Mark Pilgrim)
Date: Wed Dec 28 13:58:00 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <43B295EC.4050409@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com> <1135577105.6008.29.camel@tori>
	<B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>
	<1135693300.5514.60.camel@tori> <43B295EC.4050409@blogmatrix.com>
Message-ID: <14be96d30512281357n66c036dbyd97f37e43f2540b8@mail.gmail.com>

On 12/28/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
> Although not covered explicitly in the examples, my latest thought is to
> allow a Feed element to be embedded in an Entry element. Why? To model a
> comment feed, which obviously is blog like content.

I plan to implement it in feedparser.py when it's done, so I am
intensely interested in a few crucial design decisions.  You've been
doing pretty well with hAtom so far, so I've stayed
uncharacteristically quiet.  But now you're just making shit up, and
that's dangerous.

hAtom is a derivative format, like hCard is derivative of vCard.  The
Atom format has been endlessly argued and finally codified and RFC'd. 
Now you're trying to find an elegant way to backport it to HTML, which
I fully support.  But please resist the temptation to invent new
things.

The Atom community already had this particular argument; nested feeds lost.

--
Cheers,
-Mark
From jpanzer at aol.net  Wed Dec 28 14:09:32 2005
From: jpanzer at aol.net (John Panzer)
Date: Wed Dec 28 14:09:46 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <14be96d30512281357n66c036dbyd97f37e43f2540b8@mail.gmail.com>
References: <43843033.4080802@blogmatrix.com> <1135577105.6008.29.camel@tori>
	<B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>
	<1135693300.5514.60.camel@tori> <43B295EC.4050409@blogmatrix.com>
	<14be96d30512281357n66c036dbyd97f37e43f2540b8@mail.gmail.com>
Message-ID: <43B30D1C.7030603@aol.net>



Mark Pilgrim wrote on 12/28/2005, 1:57 PM:

 > On 12/28/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
 > > Although not covered explicitly in the examples, my latest thought
 > is to
 > > allow a Feed element to be embedded in an Entry element. Why? To
 > model a
 > > comment feed, which obviously is blog like content.
 >
 > I plan to implement it in feedparser.py when it's done, so I am
 > intensely interested in a few crucial design decisions.  You've been
 > doing pretty well with hAtom so far, so I've stayed
 > uncharacteristically quiet.  But now you're just making shit up, and
 > that's dangerous.
 >
 > hAtom is a derivative format, like hCard is derivative of vCard.  The
 > Atom format has been endlessly argued and finally codified and RFC'd.
 > Now you're trying to find an elegant way to backport it to HTML, which
 > I fully support.  But please resist the temptation to invent new
 > things.
 >
 > The Atom community already had this particular argument; nested feeds
 > lost.
 >

Yes.  Although entry content@src="http://example.org/comments/feed/1138" 
is allowed by the Atom 1.0 spec.  How does content@src get translated in 
hAtom?  (The Wiki doesn't give any details on this.)

<a href="http://example.org/comments/feed/1138" 
class="content">Comments</a> wouldn't exactly match the intent of 
content@src, which is intended to imply inline processing.  But maybe 
that's a nitpick.

-- 
John Panzer
http://journals.aol.com/panzerjohn/abstractioneer


From davidjanes at blogmatrix.com  Wed Dec 28 14:10:30 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 14:10:33 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <14be96d30512281357n66c036dbyd97f37e43f2540b8@mail.gmail.com>
References: <43843033.4080802@blogmatrix.com>
	<1135577105.6008.29.camel@tori>	<B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>	<1135693300.5514.60.camel@tori>
	<43B295EC.4050409@blogmatrix.com>
	<14be96d30512281357n66c036dbyd97f37e43f2540b8@mail.gmail.com>
Message-ID: <43B30D56.9080602@blogmatrix.com>

Ah, but I'm thinking in terms of multiple feeds on a single page, each 
feed being identified by a URI. Or do you think this is a bad idea also?

I notice that Tantek has placed a generic opaque container as a 
potential idea onto the blog. If multiple feeds per page is OK with all 
and a generic opaque container is available, then we get it "for free".

However, your wider point is appreciated, in both senses.

Regards, etc...
David

Mark Pilgrim wrote:
> On 12/28/05, David Janes -- BlogMatrix <davidjanes@blogmatrix.com> wrote:
>> Although not covered explicitly in the examples, my latest thought is to
>> allow a Feed element to be embedded in an Entry element. Why? To model a
>> comment feed, which obviously is blog like content.
> 
> I plan to implement it in feedparser.py when it's done, so I am
> intensely interested in a few crucial design decisions.  You've been
> doing pretty well with hAtom so far, so I've stayed
> uncharacteristically quiet.  But now you're just making shit up, and
> that's dangerous.
> 
> hAtom is a derivative format, like hCard is derivative of vCard.  The
> Atom format has been endlessly argued and finally codified and RFC'd. 
> Now you're trying to find an elegant way to backport it to HTML, which
> I fully support.  But please resist the temptation to invent new
> things.
> 
> The Atom community already had this particular argument; nested feeds lost.

From paul at msn.com  Wed Dec 28 14:17:35 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 14:24:02 2005
Subject: [uf-discuss] hAtom draft - class="title"
References: <43843033.4080802@blogmatrix.com>
	<dosaiu$tqd$1@sea.gmane.org><douugr$cvg$1@sea.gmane.org>
	<43B306F8.80702@blogmatrix.com>
Message-ID: <dov2t4$u81$1@sea.gmane.org>

"David Janes -- BlogMatrix" wrote...
> Nice. I just discovered a bug in my parser that screwed up the title 
> nesting. Here's [1] the new and improved version.

Does your parser fill the Author from the hCard's FN/NICKNAME field?  I am 
curious if it would, given that the hCard should be opaque, but it is also 
the Author.

> You'll want to move class="logo" from the <li> down to the <img> where it 
> belongs though.

Done.  Is it required to be in an IMG only, or can the IMG act as another 
element's value (as I had it previously).


Atamido 



From davidjanes at blogmatrix.com  Wed Dec 28 14:28:50 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 14:28:53 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <dov2t4$u81$1@sea.gmane.org>
References: <43843033.4080802@blogmatrix.com>	<dosaiu$tqd$1@sea.gmane.org><douugr$cvg$1@sea.gmane.org>	<43B306F8.80702@blogmatrix.com>
	<dov2t4$u81$1@sea.gmane.org>
Message-ID: <43B311A2.50707@blogmatrix.com>

Paul Bryson wrote:
> "David Janes -- BlogMatrix" wrote...
>> Nice. I just discovered a bug in my parser that screwed up the title 
>> nesting. Here's [1] the new and improved version.
> 
> Does your parser fill the Author from the hCard's FN/NICKNAME field?  I am 
> curious if it would, given that the hCard should be opaque, but it is also 
> the Author.

The "author" is opaque in that hAtom is not looking for further hAtom 
elements within that element. However, hAtom does know that this element 
is a hCard and parses it as a hCard.

Regards, etc...
David



From davidjanes at blogmatrix.com  Wed Dec 28 14:30:55 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 14:30:57 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <dov2t4$u81$1@sea.gmane.org>
References: <43843033.4080802@blogmatrix.com>	<dosaiu$tqd$1@sea.gmane.org><douugr$cvg$1@sea.gmane.org>	<43B306F8.80702@blogmatrix.com>
	<dov2t4$u81$1@sea.gmane.org>
Message-ID: <43B3121F.9080808@blogmatrix.com>

Paul Bryson wrote:
>> You'll want to move class="logo" from the <li> down to the <img> where it 
>> belongs though.
> 
> Done.  Is it required to be in an IMG only, or can the IMG act as another 
> element's value (as I had it previously).

You should be able to now convert the Date Posted into a nice 
"published" element.

Regards, etc...
David
From davidjanes at blogmatrix.com  Wed Dec 28 14:36:27 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 14:36:31 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <43B30D1C.7030603@aol.net>
References: <43843033.4080802@blogmatrix.com>
	<1135577105.6008.29.camel@tori>	<B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>	<1135693300.5514.60.camel@tori>
	<43B295EC.4050409@blogmatrix.com>	<14be96d30512281357n66c036dbyd97f37e43f2540b8@mail.gmail.com>
	<43B30D1C.7030603@aol.net>
Message-ID: <43B3136B.9050202@blogmatrix.com>

John Panzer wrote:
> Yes.  Although entry content@src="http://example.org/comments/feed/1138" 
> is allowed by the Atom 1.0 spec.  How does content@src get translated in 
> hAtom?  (The Wiki doesn't give any details on this.)
> 
> <a href="http://example.org/comments/feed/1138" 
> class="content">Comments</a> wouldn't exactly match the intent of 
> content@src, which is intended to imply inline processing.  But maybe 
> that's a nitpick.
> 

hAtom -- at this point -- is only taking the subset of Atom definitions 
that are commonly used on weblogs. There are several reasons for this, 
one being the starting point of creating a microformat for weblog posts 
(rather than a translation for Atom into HTML), documenting the need for 
what elements are to be used through examples, and not least keeping the 
project manageable.

Thus, hAtom won't give you a good set of rules for turning an arbitrary 
Atom feed into HTML.

Regards, etc...
David
From paul at msn.com  Wed Dec 28 14:43:00 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 14:46:50 2005
Subject: [uf-discuss] hAtom draft - class="title"
References: <43843033.4080802@blogmatrix.com>	<dosaiu$tqd$1@sea.gmane.org><douugr$cvg$1@sea.gmane.org>	<43B306F8.80702@blogmatrix.com><dov2t4$u81$1@sea.gmane.org>
	<43B311A2.50707@blogmatrix.com>
Message-ID: <dov4cp$322$1@sea.gmane.org>

"David Janes -- BlogMatrix" wrote ...
> The "author" is opaque in that hAtom is not looking for further hAtom 
> elements within that element. However, hAtom does know that this element 
> is a hCard and parses it as a hCard.

Ah, that explains a lot.  Thanks.


Atamido 



From tjameswhite at yahoo.com  Wed Dec 28 14:53:58 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Wed Dec 28 14:54:02 2005
Subject: [uf-discuss] Book Citation Examples
Message-ID: <20051228225358.29290.qmail@web50010.mail.yahoo.com>

As an interest in the citation microformat and title design pattern I
mentioned previously[1], I've done a little research to see how
publishers are currently marking up book titles.

The results have been added to the citation examples page as Citation
Mark up in the Wild[2]


These are just a few examples from a handful of publishers' online
catalogs. A quick synopsis of the type of mark up being used:

For Titles:

* id="title" class="producttitle"
* class="title"
* id="lblTitle" class="book_headline block"
* table cell, no mark up
* h1
* h2


Sub-titles:

* id="subtitle" class="productsubtitle"
* class="sub_title"
* id="lblSubTitle" class="book_subline"
* class="subTitle"

I've also created a citations in the wild page[3] where I tried to
capture the pieces of each publisher's page. The wiki page needs a
bunch of clean up, and I may just post the examples on my site with
just a list of links to the publisher's sites. Let me know which you'd
prefer.

Any feedback is appreciated.

Tim White

[1] This may also be informative for the hAtom class="title"
discussion.
http://www.tjameswhite.com/blog/archives/2005/12/microformat-design-pattern/

[2] http://microformats.org/wiki/cite-examples

[3] http://microformats.org/wiki/citations_in_the_wild
(I've gone and posted it to my site:
http://www.tjameswhite.com/citation-examples.htm)


	
		
__________________________________ 
Yahoo! for Good - Make a difference this year. 
http://brand.yahoo.com/cybergivingweek2005/
From paul at msn.com  Wed Dec 28 14:51:08 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 14:55:36 2005
Subject: [uf-discuss] hAtom draft - class="title"
References: <43843033.4080802@blogmatrix.com>	<dosaiu$tqd$1@sea.gmane.org><douugr$cvg$1@sea.gmane.org>	<43B306F8.80702@blogmatrix.com><dov2t4$u81$1@sea.gmane.org>
	<43B3121F.9080808@blogmatrix.com>
Message-ID: <dov4s1$5dk$1@sea.gmane.org>

"David Janes -- BlogMatrix" wrote...
> You should be able to now convert the Date Posted into a nice "published" 
> element.

It isn't already?  Honestly, in production I'm not sure that I will have 
access to the date in an ISO format.  I will include it though for the 
example.  I'm not a fan of how things are laid out around the published 
element, but I guess it probably doesn't matter to much.

It is a shame that we cannot use dtpublished to keep with what has already 
been pulled from hCard and hCalendar.


Atamido 



From tantek at cs.stanford.edu  Wed Dec 28 15:04:41 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec 28 15:05:22 2005
Subject: Multiple LOGOs or PHOTOs in hCard/vCard? (was Re: [uf-discuss]
	Avatar Microformat ?)
In-Reply-To: <douv4l$er1$1@sea.gmane.org>
Message-ID: <BFD85A02.65A96%tantek@cs.stanford.edu>

On 12/28/05 1:13 PM, "Paul Bryson" <paul@msn.com> wrote:

> "Charles Iliya Krempeaux"
> <supercanadian@gmail.com> wrote...
>> I'd agree with this if hCards allowed for multiple PHOTO's or LOGO's.
>> So, from my perspective, the question comes down to: does an hCard
>> support mutiple PHOTO's or LOGO's?  (My understanding so far is that
>> they don't.  But please correct me if I'm wrong.)
> 
> I am currently using "logo" to display an avatar.  But I am curious if more
> than one photo/logo is allowed per hCard.

I don't see any wording in RFC 2426 (vCard) that prohibits multiple LOGOs or
PHOTOs, therefore it is reasonable to allow for more than one in hCards as
well.

Now, what different clients/applications do with those multiple LOGOs/PHOTOs
is a different matter, but the assumption is that those implementations are
constantly improving.

Your markup should reflect the content you are publishing.  The
implementations will adapt to the content out there, especially if you add
your particular content as one of the "Examples in the Wild" in the hCard
specification:

 http://microformats.org/wiki/hcard#Examples_in_the_wild

Thanks,

Tantek

From tantek at cs.stanford.edu  Wed Dec 28 15:12:41 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec 28 15:13:22 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <dov4s1$5dk$1@sea.gmane.org>
Message-ID: <BFD85BD6.65A9B%tantek@cs.stanford.edu>

On 12/28/05 2:51 PM, "Paul Bryson" <paul@msn.com> wrote:

> "David Janes -- BlogMatrix" wrote...
>> You should be able to now convert the Date Posted into a nice "published"
>> element.
> 
> It isn't already?  Honestly, in production I'm not sure that I will have
> access to the date in an ISO format.  I will include it though for the
> example.  I'm not a fan of how things are laid out around the published
> element, but I guess it probably doesn't matter to much.
> 
> It is a shame that we cannot use dtpublished to keep with what has already
> been pulled from hCard and hCalendar.

Paul, this is an interesting proposal and I believe is worthy of
consideration.  Please add it to the hAtom issues page:

 http://microformats.org/wiki/hatom-issues

In addition, it is probably worth referencing other similar properties such
as REV in hCard/vCard, DTSTAMP in hCalendar/iCalendar, and the
examples/formats/brainstorming for last-modified:

http://microformats.org/wiki/last-modified-brainstorming

Among all these, it feels like we can do some simplification.  And where the
properties have different semantics, it would be useful to call out those
differences.

Thanks,

Tantek

From brian.suda at gmail.com  Wed Dec 28 15:19:20 2005
From: brian.suda at gmail.com (brian suda)
Date: Wed Dec 28 15:19:44 2005
Subject: Multiple LOGOs or PHOTOs in hCard/vCard? (was Re: [uf-discuss]
	Avatar Microformat ?)
In-Reply-To: <BFD85A02.65A96%tantek@cs.stanford.edu>
References: <BFD85A02.65A96%tantek@cs.stanford.edu>
Message-ID: <43B31D78.3030208@gmail.com>

The problem i see in the RFC and hCard for having multiple Images is this:

All properties that allow multiple instances, NICKNAME do so as comma
delimited values
NICKNAME: bill, billy, Wil

and not as:

NICKNAME: bill
NICKNAME: billy
NICKNAME: Wil

In the RFC it is normally written at the end of the document as
something like:

NICKNAME: (text-value)*,

saying that it can take multiple 'text-values'

LOGO and IMAGE do not have the * operator, so i would interpret this as
NOT allowing multiple comma delimated values.

That leaves the question of can it have multiple instance of the same
property:

LOGO:....
LOGO:....

No other property does this, as my NICKNAME example above shows, so i
would not think LOGO, PHOTO to be any different.

So i DON'T think it is possible to have two or more PHOTOs or LOGOs, but
i might be missing something.

-brian

Tantek ?elik wrote:

>On 12/28/05 1:13 PM, "Paul Bryson" <paul@msn.com> wrote:
>
>  
>
>>"Charles Iliya Krempeaux"
>><supercanadian@gmail.com> wrote...
>>    
>>
>>>I'd agree with this if hCards allowed for multiple PHOTO's or LOGO's.
>>>So, from my perspective, the question comes down to: does an hCard
>>>support mutiple PHOTO's or LOGO's?  (My understanding so far is that
>>>they don't.  But please correct me if I'm wrong.)
>>>      
>>>
>>I am currently using "logo" to display an avatar.  But I am curious if more
>>than one photo/logo is allowed per hCard.
>>    
>>
>
>I don't see any wording in RFC 2426 (vCard) that prohibits multiple LOGOs or
>PHOTOs, therefore it is reasonable to allow for more than one in hCards as
>well.
>
>Now, what different clients/applications do with those multiple LOGOs/PHOTOs
>is a different matter, but the assumption is that those implementations are
>constantly improving.
>
>Your markup should reflect the content you are publishing.  The
>implementations will adapt to the content out there, especially if you add
>your particular content as one of the "Examples in the Wild" in the hCard
>specification:
>
> http://microformats.org/wiki/hcard#Examples_in_the_wild
>
>Thanks,
>
>Tantek
>
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>
>  
>

From davidjanes at blogmatrix.com  Wed Dec 28 15:24:53 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Wed Dec 28 15:24:56 2005
Subject: Multiple LOGOs or PHOTOs in hCard/vCard? (was Re: [uf-discuss]
	Avatar Microformat ?)
In-Reply-To: <43B31D78.3030208@gmail.com>
References: <BFD85A02.65A96%tantek@cs.stanford.edu>
	<43B31D78.3030208@gmail.com>
Message-ID: <43B31EC5.4020603@blogmatrix.com>

The "Overview" of vcard [1, page 2] says:

   In addition, traditional paper business card information such
   as an image of an organizational logo or identify photograph can be
   included in this person object.

I'm reading "an" and "can" as saying "0 or 1".

Regards, etc...
David

[1] http://www.ietf.org/rfc/rfc2426.txt

brian suda wrote:
> The problem i see in the RFC and hCard for having multiple Images is this:
> 
> All properties that allow multiple instances, NICKNAME do so as comma
> delimited values
> NICKNAME: bill, billy, Wil
> 
> and not as:
> 
> NICKNAME: bill
> NICKNAME: billy
> NICKNAME: Wil
> 
> In the RFC it is normally written at the end of the document as
> something like:
> 
> NICKNAME: (text-value)*,
> 
> saying that it can take multiple 'text-values'
> 
> LOGO and IMAGE do not have the * operator, so i would interpret this as
> NOT allowing multiple comma delimated values.
> 
> That leaves the question of can it have multiple instance of the same
> property:
> 
> LOGO:....
> LOGO:....
> 
> No other property does this, as my NICKNAME example above shows, so i
> would not think LOGO, PHOTO to be any different.
> 
> So i DON'T think it is possible to have two or more PHOTOs or LOGOs, but
> i might be missing something.
> 
> -brian
> 
> Tantek ?elik wrote:
> 
>> On 12/28/05 1:13 PM, "Paul Bryson" <paul@msn.com> wrote:
>>
>>  
>>
>>> "Charles Iliya Krempeaux"
>>> <supercanadian@gmail.com> wrote...
>>>    
>>>
>>>> I'd agree with this if hCards allowed for multiple PHOTO's or LOGO's.
>>>> So, from my perspective, the question comes down to: does an hCard
>>>> support mutiple PHOTO's or LOGO's?  (My understanding so far is that
>>>> they don't.  But please correct me if I'm wrong.)
>>>>      
>>>>
>>> I am currently using "logo" to display an avatar.  But I am curious if more
>>> than one photo/logo is allowed per hCard.
>>>    
>>>
>> I don't see any wording in RFC 2426 (vCard) that prohibits multiple LOGOs or
>> PHOTOs, therefore it is reasonable to allow for more than one in hCards as
>> well.
>>
>> Now, what different clients/applications do with those multiple LOGOs/PHOTOs
>> is a different matter, but the assumption is that those implementations are
>> constantly improving.
>>
>> Your markup should reflect the content you are publishing.  The
>> implementations will adapt to the content out there, especially if you add
>> your particular content as one of the "Examples in the Wild" in the hCard
>> specification:
>>
>> http://microformats.org/wiki/hcard#Examples_in_the_wild
>>
>> Thanks,
>>
>> Tantek
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>>  
>>
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 
> 

From tantek at cs.stanford.edu  Wed Dec 28 15:36:41 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Dec 28 15:37:20 2005
Subject: Multiple LOGOs or PHOTOs in hCard/vCard? (was Re:
	[uf-discuss] Avatar Microformat ?)
In-Reply-To: <43B31EC5.4020603@blogmatrix.com>
Message-ID: <BFD8613A.65AA3%tantek@cs.stanford.edu>

Actually, if you read the various property descriptions carefully, you see
that some properties (e.g. FN, N, BDAY), say "the", and others (e.g. PHOTO,
LOGO) say "a" or "an".

IMHO, the use of "the" may indicate a singular property.

Whereas the use of "a" or "an" seems to indicate that you may have more than
one instance of that property for that element.

Brian's right that some properties explicitly allow multivalues delimited by
commas (e.g. NICKNAME, CATEGORIES, etc.), but that doesn't prohibit
multiple instances of a whole property declaration in order to indicate
multiple values.

OTOH, look at the definition for TEL, it says "to specify THE telephone
number ..." (EMPHASIS mine).

Whereas clearly vCards can (and do) represent multiple phone numbers, both
in numerous Address Book clients and in hCards on the Web.

The same with the EMAIL property.

Both of these are illustrated with the example vCards of the spec authors at
the end of RFC 2426 (section 7. Authors' Addresses).

Thus, I believe it is correct to presume that multiple properties/values are
allowed unless *explicitly* forbidden by the format.

Thanks,

Tantek

On 12/28/05 3:24 PM, "David Janes -- BlogMatrix" <davidjanes@blogmatrix.com>
wrote:

> The "Overview" of vcard [1, page 2] says:
> 
>  In addition, traditional paper business card information such
>  as an image of an organizational logo or identify photograph can be
>  included in this person object.
> 
> I'm reading "an" and "can" as saying "0 or 1".
> 
> Regards, etc...
> David
> 
> [1] http://www.ietf.org/rfc/rfc2426.txt
> 
> brian suda wrote:
>> The problem i see in the RFC and hCard for having multiple Images is this:
>> 
>> All properties that allow multiple instances, NICKNAME do so as comma
>> delimited values
>> NICKNAME: bill, billy, Wil
>> 
>> and not as:
>> 
>> NICKNAME: bill
>> NICKNAME: billy
>> NICKNAME: Wil
>> 
>> In the RFC it is normally written at the end of the document as
>> something like:
>> 
>> NICKNAME: (text-value)*,
>> 
>> saying that it can take multiple 'text-values'
>> 
>> LOGO and IMAGE do not have the * operator, so i would interpret this as
>> NOT allowing multiple comma delimated values.
>> 
>> That leaves the question of can it have multiple instance of the same
>> property:
>> 
>> LOGO:....
>> LOGO:....
>> 
>> No other property does this, as my NICKNAME example above shows, so i
>> would not think LOGO, PHOTO to be any different.
>> 
>> So i DON'T think it is possible to have two or more PHOTOs or LOGOs, but
>> i might be missing something.
>> 
>> -brian
>> 
>> Tantek ?elik wrote:
>> 
>>> On 12/28/05 1:13 PM, "Paul Bryson" <paul@msn.com> wrote:
>>> 
>>>  
>>> 
>>>> "Charles Iliya Krempeaux"
>>>> <supercanadian@gmail.com> wrote...
>>>>    
>>>> 
>>>>> I'd agree with this if hCards allowed for multiple PHOTO's or LOGO's.
>>>>> So, from my perspective, the question comes down to: does an hCard
>>>>> support mutiple PHOTO's or LOGO's?  (My understanding so far is that
>>>>> they don't.  But please correct me if I'm wrong.)
>>>>>      
>>>>> 
>>>> I am currently using "logo" to display an avatar.  But I am curious if more
>>>> than one photo/logo is allowed per hCard.
>>>>    
>>>> 
>>> I don't see any wording in RFC 2426 (vCard) that prohibits multiple LOGOs or
>>> PHOTOs, therefore it is reasonable to allow for more than one in hCards as
>>> well.
>>> 
>>> Now, what different clients/applications do with those multiple LOGOs/PHOTOs
>>> is a different matter, but the assumption is that those implementations are
>>> constantly improving.
>>> 
>>> Your markup should reflect the content you are publishing.  The
>>> implementations will adapt to the content out there, especially if you add
>>> your particular content as one of the "Examples in the Wild" in the hCard
>>> specification:
>>> 
>>> http://microformats.org/wiki/hcard#Examples_in_the_wild
>>> 
>>> Thanks,
>>> 
>>> Tantek
>>> 
>>> _______________________________________________
>>> microformats-discuss mailing list
>>> microformats-discuss@microformats.org
>>> http://microformats.org/mailman/listinfo/microformats-discuss
>>> 
>>>  
>>> 
>> 
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>> 
>> 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From paul at msn.com  Wed Dec 28 17:42:26 2005
From: paul at msn.com (Paul Bryson)
Date: Wed Dec 28 17:42:21 2005
Subject: [uf-discuss] hAtom draft - class="title"
References: <dov4s1$5dk$1@sea.gmane.org>
	<BFD85BD6.65A9B%tantek@cs.stanford.edu>
Message-ID: <dovet6$vhm$1@sea.gmane.org>

"Tantek Ç elik" wrote...
> On 12/28/05 2:51 PM, "Paul Bryson" <paul@msn.com> 
> wrote:
>> It is a shame that we cannot use dtpublished to keep with what has 
>> already
>> been pulled from hCard and hCalendar.
>
> Paul, this is an interesting proposal and I believe is worthy of
> consideration.  Please add it to the hAtom issues page:

Sorry, I wasn't actually trying to make a suggestion.  I had noted that both 
vCalendar and hReview prefixed dates with "dt" (dtend, dtstart, dtreviewed). 
So it would be nice to continue that trend.  However, as hAtom's main pull 
is from Atom, it wouldn't make much sense to replace the already existing 
"published" (from Atom) with "dtpublished".


Atamido 



From davidjanes at blogmatrix.com  Thu Dec 29 05:06:32 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec 29 05:06:36 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <dovet6$vhm$1@sea.gmane.org>
References: <dov4s1$5dk$1@sea.gmane.org>	<BFD85BD6.65A9B%tantek@cs.stanford.edu>
	<dovet6$vhm$1@sea.gmane.org>
Message-ID: <43B3DF58.8010708@blogmatrix.com>

Paul Bryson wrote:
> "Tantek ? elik" wrote...
>> On 12/28/05 2:51 PM, "Paul Bryson" <paul@msn.com> 
>> wrote:
>>> It is a shame that we cannot use dtpublished to keep with what has 
>>> already
>>> been pulled from hCard and hCalendar.
>> Paul, this is an interesting proposal and I believe is worthy of
>> consideration.  Please add it to the hAtom issues page:
> 
> Sorry, I wasn't actually trying to make a suggestion.  I had noted that both 
> vCalendar and hReview prefixed dates with "dt" (dtend, dtstart, dtreviewed). 
> So it would be nice to continue that trend.  However, as hAtom's main pull 
> is from Atom, it wouldn't make much sense to replace the already existing 
> "published" (from Atom) with "dtpublished".

I'm fairly happy with the way things are named in hAtom right now: 
anyone familiar with weblogs and/or Atom will immediately recognize all 
the elements. The one (so far) variance is rel="bookmark", which is 
defined in HTML so that's cool.

I'm waiting for someone to express a stronger opinion or principle on 
how elements should be named, preferably with a reference to a Wiki page 
listing it. At this point, there's serious proposals to rename 75%+ of 
the elements in hAtom, which means hAtom won't look very Atomish at all! 
However, if there's a consensus, that's the way it goes.

Regards, etc...
David

From davidjanes at blogmatrix.com  Thu Dec 29 05:11:38 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Thu Dec 29 05:11:41 2005
Subject: [uf-discuss] Almost Universal Microformat Parser: source code
Message-ID: <43B3E08A.1050105@blogmatrix.com>

The AUMFP provides Python (2.3) classes for extracting microformat 
content from HTML documents, and includes classes for hCard, hCalendar, 
xFolk, and rel-tag. It should be easily extendable to new uF types.

The source code is here [1] as a tarball and includes a CGI interface. A 
running demo is here [2] with samples and a minor amount of 
documentation available here [3] and here [4].

I'd like to know if you're using it in a project (preferably credited) 
and I'd like bug fixes and new parses fed back to me.

Regards, etc...
David
http://www.blogmatrix.com

[1] http://www.blogmatrix.com/tools/src/
[2] http://www.blogmatrix.com/tools/extract/
[3] http://blog.davidjanes.com/mtarchives/2005_12.html#003472
[4] http://blog.davidjanes.com/mtarchives/2005_12.html#003468


From benjamincarlyle at optusnet.com.au  Thu Dec 29 05:45:27 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Thu Dec 29 05:44:31 2005
Subject: [uf-discuss] hAtom draft - utility of feeds
In-Reply-To: <43B30D56.9080602@blogmatrix.com>
References: <43843033.4080802@blogmatrix.com> <1135577105.6008.29.camel@tori>
	<B22424E6-7E8E-4219-9AB0-816CF3E813B6@technorati.com>
	<1135693300.5514.60.camel@tori> <43B295EC.4050409@blogmatrix.com>
	<14be96d30512281357n66c036dbyd97f37e43f2540b8@mail.gmail.com>
	<43B30D56.9080602@blogmatrix.com>
Message-ID: <1135863929.8616.32.camel@tori>

On Wed, 2005-12-28 at 17:10 -0500, David Janes -- BlogMatrix wrote:
> I notice that Tantek has placed a generic opaque container as a 
> potential idea onto the blog. If multiple feeds per page is OK with all 
> and a generic opaque container is available, then we get it "for free".

I'll try to share some of my thinking on the opacity question:

Opacity is required when:
1. There is a uf element that I think I understand, but may have a
definition that differs from mine.
2. There is a uf element that I think I understand, but it may not apply
to my context. It may apply to a context that I do not recognise and
have skipped over.

Opacity (identified nesting generally, in fact) could be about solving
the problem of applying context to complete a triple, or about providing
a walled garden over which common definitions do not apply, or about
both. Microformats already make use of nesting that can only be
understood if you are a parser of that microformat, and annotates each
nested level with at least one type (vcard, vcalendar, etc).

I have a quick mapping of the potential solution space:

== Different Definitions, aka naming the type ==

1.1 Do not permit different definitions of the same term

1.1.1 Hold old microformat definitions valid until they pass out of
common use
	+ Definitions are stable, new versions of old ufs are not created
	- The set of terms may become more esoteric than necessary when the
most widely-understood usage of a term is barred in favour of an older
and less widely-understood one

1.1.2 Review the validity of old definitions from time to time and widen
or replace them with more appropriate definitions
	+/- inverse of keeping definitions valid
Possible mitigating strategies:
	* Start with esoteric names such as vcard-title rather than title, or
reviewer rather than author (of a review). Move to more mainstream names
only when it is proven across several microformats to be
widely-understood. Parsers accept both esoteric and mainstream names
until esoteric ones pass out of common use.

1.2 Permit different definitions. Opacity is required to avoid tripping
over elements that appear to signify something they do not.
	- Opacity is no longer a matter of completing the triple using context.
It is also a boundary of understanding. What can you rely on? title?
author? vcard? It may be important to specify which definitions are
fixed, and which movable.
	- Without a boundary of understanding in place users would be able to
define arbirary contexts to allow author, contributor, and the like to
be applied to individual documents. This might not directly affect
parsing. Consider the atom "entry" concept. It may not have to exist if
it were always clear what an atom author applied to. Likewise, one might
mark up a hreview of hcard in the hAtom style. All that would be needed
would be to add "mfo" to a div and insert further metadata relating to
that div.
	- Harder to use css?

== Different Contexts, aka completing the triple ==

2.1 Define global ruleset for context

2.1.1 Applies to parent context (mfo) but not children of that context
	+/-?

2.1.2 Applies to parent context and child mfos
	+ Good for author, contributor

2.1.3 Applies only to child mfos of the element
	+/-?

2.2 Define a per-element ruleset for context
	+ Allow author to be defined differently to ???

2.3 Allow individual element instances to identify context
	+ Allow the whole triple to be defined in one place, "foo is author of
bar"
	- More complicated... triples don't seem to match human prose well.

Back to the subject of hAtom, I think the terminology issue has to come
to a head if forward momentum is to be maintained. It would be nice to
get a resolution to that as early as possible in the mfo process. Will
there be divergence in definitions? If not, who will budge? What should
the strategy be going forwards? I think this will rely on the people
involved getting as face-to-face as possible for a few hours at some
point :)

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From benjamincarlyle at optusnet.com.au  Thu Dec 29 06:01:27 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Thu Dec 29 06:00:29 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <43B3DF58.8010708@blogmatrix.com>
References: <dov4s1$5dk$1@sea.gmane.org>
	<BFD85BD6.65A9B%tantek@cs.stanford.edu> <dovet6$vhm$1@sea.gmane.org>
	<43B3DF58.8010708@blogmatrix.com>
Message-ID: <1135864887.8616.44.camel@tori>

On Thu, 2005-12-29 at 08:06 -0500, David Janes -- BlogMatrix wrote:
> I'm fairly happy with the way things are named in hAtom right now: 
> anyone familiar with weblogs and/or Atom will immediately recognize all 
> the elements. The one (so far) variance is rel="bookmark", which is 
> defined in HTML so that's cool.
> 
> I'm waiting for someone to express a stronger opinion or principle on 
> how elements should be named, preferably with a reference to a Wiki page 
> listing it. At this point, there's serious proposals to rename 75%+ of 
> the elements in hAtom, which means hAtom won't look very Atomish at all! 
> However, if there's a consensus, that's the way it goes.

I would back this with the observation that the atom standardisation
process suggests that the terms in use are widely accepted and
understood. Stepping away from them may be stepping into esoterica.

I understand that on one hand you want to maintain compatability with
existing implementations by protecting the current namespace. On the
other hand, you'll never have a smaller installed base than you do
today. Opacity might allow for a resolution, but using identified
scoping in that way has its own problems.

Unless an experienced microformatter is able to take a stand based on
solid experience, I don't think this will be solved via email.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From rbach at rbach.priv.at  Thu Dec 29 16:41:19 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Thu Dec 29 16:39:59 2005
Subject: [uf-discuss] RFC: Microformat to denote the date of the last	(page)
	modfication/publication
Message-ID: <43B4822F.90504@rbach.priv.at>

Please give me your thougths:

 2nd Strawman proposal
 http://microformats.org/wiki/last-modified-brainstorming#proposal

Thanks,
 Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Thu Dec 29 21:28:15 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 29 21:47:57 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <dot7f6$b39$1@sea.gmane.org>
References: <43B1B3B8.1020902@blogmatrix.com>
	<BFD71181.659D5%tantek@cs.stanford.edu>
	<dot7f6$b39$1@sea.gmane.org>
Message-ID: <79B751A7-8674-4380-99CF-6E8919EA9059@technorati.com>

On Dec 27, 2005, at 11:23 PM, Paul Bryson wrote:

> "Tantek ? elik" wrote...
>> See http://microformats.org/wiki/existing-classes for an overview.
>
> Ugh, someone should really update that page.

Are you volunteering? :D

-rk
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Thu Dec 29 21:47:56 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 29 21:48:04 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <43B3DF58.8010708@blogmatrix.com>
References: <dov4s1$5dk$1@sea.gmane.org>	<BFD85BD6.65A9B%tantek@cs.stanford.edu>
	<dovet6$vhm$1@sea.gmane.org> <43B3DF58.8010708@blogmatrix.com>
Message-ID: <42162087-2527-4DE5-8D5E-94DA958BECD9@technorati.com>

On Dec 29, 2005, at 7:06 AM, David Janes -- BlogMatrix wrote:
> I'm waiting for someone to express a stronger opinion or principle  
> on how elements should be named, preferably with a reference to a  
> Wiki page listing it. At this point, there's serious proposals to  
> rename 75%+ of the elements in hAtom, which means hAtom won't look  
> very Atomish at all! However, if there's a consensus, that's the  
> way it goes.

I assume you're referring to the suggestion that elements get  
prefixed with atom- and/or entry-

I have a couple of responses to this idea (which I think I've already  
gone over on this list, but anyway...):

First, its just ugly. I just want to say 'entry,' not 'atomentry.'

Second, I believe that context and specific rules on opacity are  
sufficient for making thing unambiguous. Admittedly, with  
microformats we tend to walk a fine line here, but its not without  
reason- we're trying to optimize for publishers- which mainly  
includes geeks who hand-write html in textareas and web developers/ 
designers.

I'm sure I have other responses, but can't think of them right now  
(they're probably in the archive somewhere).

-rk
--
Ryan King
ryan@technorati.com



From ryan at technorati.com  Thu Dec 29 21:50:12 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Dec 29 21:50:10 2005
Subject: [uf-discuss] RFC: Microformat to denote the date of the
	last	(page) modfication/publication
In-Reply-To: <43B4822F.90504@rbach.priv.at>
References: <43B4822F.90504@rbach.priv.at>
Message-ID: <8D0097C9-2BC9-406A-8415-1C2E727D18FE@technorati.com>

On Dec 29, 2005, at 6:41 PM, Robert Bachmann wrote:

> Please give me your thougths:
>
>  2nd Strawman proposal
>  http://microformats.org/wiki/last-modified-brainstorming#proposal

Under "<del> and <ins>":

>  <del class="date-modified1" datetime="2005-12-29T14:39:12 
> +0100">wrong words</del>

what's datetime? And why change the classname?

-rk
--
Ryan King
ryan@technorati.com



From rbach at rbach.priv.at  Fri Dec 30 03:28:59 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Dec 30 03:27:40 2005
Subject: [uf-discuss] RFC: Microformat to denote the date of the	last
	(page) modfication/publication
In-Reply-To: <8D0097C9-2BC9-406A-8415-1C2E727D18FE@technorati.com>
References: <43B4822F.90504@rbach.priv.at>
	<8D0097C9-2BC9-406A-8415-1C2E727D18FE@technorati.com>
Message-ID: <43B519FB.5070305@rbach.priv.at>

Ryan King wrote:
> Under "<del> and <ins>":
> 
>>  <del class="date-modified1" datetime="2005-12-29T14:39:12
>> +0100">wrong words</del>
> 
> 
> what's datetime? 

 The value of this attribute specifies the date and time when the change
 was made.
  -- http://www.w3.org/TR/html401/struct/text.html#edef-ins

> And why change the classname?
Ups.
http://microformats.org/wiki?title=last-modified-brainstorming&diff=next&oldid=3630

Thanks,
 Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Fri Dec 30 11:09:23 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Dec 30 11:09:26 2005
Subject: [uf-discuss] RFC: Microformat to denote the date of the	last
	(page) modfication/publication
In-Reply-To: <43B519FB.5070305@rbach.priv.at>
References: <43B4822F.90504@rbach.priv.at>
	<8D0097C9-2BC9-406A-8415-1C2E727D18FE@technorati.com>
	<43B519FB.5070305@rbach.priv.at>
Message-ID: <8138E961-ABE0-43F9-8D52-C154CDDC9FAC@technorati.com>

On Dec 30, 2005, at 5:28 AM, Robert Bachmann wrote:
> Ryan King wrote:
>> Under "<del> and <ins>":
>>
>>>  <del class="date-modified1" datetime="2005-12-29T14:39:12
>>> +0100">wrong words</del>
>>
>>
>> what's datetime?
>
>  The value of this attribute specifies the date and time when the  
> change
>  was made.
>   -- http://www.w3.org/TR/html401/struct/text.html#edef-ins

Ah, sorry, forgot about that (and shoulda looked it up).

>> And why change the classname?
> Ups.
> http://microformats.org/wiki?title=last-modified- 
> brainstorming&diff=next&oldid=3630

-rk
--
Ryan King
ryan@technorati.com



From kevin at lawver.net  Fri Dec 30 12:44:03 2005
From: kevin at lawver.net (Kevin Lawver)
Date: Fri Dec 30 12:44:07 2005
Subject: [uf-discuss] User Profile Microformat
Message-ID: <43B59C13.5030607@lawver.net>

I was looking at hCard today (and around the web) looking for ideas 
around a user profile microformat.   I went looking for existing schema, 
and honestly didn't find a whole lot.  There's PIDF[1], but it's for 
presence.  There's hCard, but it doesn't hold all the things you see in 
social networking sites' profiles (interests, favorites, marital status, 
looking for, personal descriptions, etc).  Some of those things 
(interests and favorites especially) could be accomplished with 
attentionxml, but there doesn't seem to be anything about profiles (or a 
page on the wiki for that matter).

Is there any interest from the list?

Also, our site showing off our module (widget) microformat should be 
launching next week.  I'll send the url to the list when it does.

[1] http://xml.coverpages.org/pidf.html

Kevin
http://lawver.net
From paul at msn.com  Fri Dec 30 14:24:06 2005
From: paul at msn.com (Paul Bryson)
Date: Fri Dec 30 14:23:39 2005
Subject: [uf-discuss] RFC: Microformat to denote the date of the
	last	(page)modfication/publication
References: <43B4822F.90504@rbach.priv.at>
Message-ID: <dp4c0u$tg6$1@sea.gmane.org>

"Robert Bachmann" wrote...
> Please give me your thougths:
>
> 2nd Strawman proposal
> http://microformats.org/wiki/last-modified-brainstorming#proposal

"published" and "updated" both exist already as date elements in hAtom, 
which got them from Atom.


Atamido 



From benjamincarlyle at optusnet.com.au  Sat Dec 31 01:58:02 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Sat Dec 31 01:57:01 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <42162087-2527-4DE5-8D5E-94DA958BECD9@technorati.com>
References: <dov4s1$5dk$1@sea.gmane.org>
	<BFD85BD6.65A9B%tantek@cs.stanford.edu> <dovet6$vhm$1@sea.gmane.org>
	<43B3DF58.8010708@blogmatrix.com>
	<42162087-2527-4DE5-8D5E-94DA958BECD9@technorati.com>
Message-ID: <1136023084.6183.12.camel@tori>

Ryan,

On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote:
> ...I believe that context and specific rules on opacity are  
> sufficient for making thing unambiguous. Admittedly, with  
> microformats we tend to walk a fine line here, but its not without  
> reason- we're trying to optimize for publishers- which mainly  
> includes geeks who hand-write html in textareas and web developers/ 
> designers.

Is it your position that hAtom's title class can have a different
meaning to hCard's title, and that hAtom's summary class can have a
different meaning to hReview's summary class? Is it your position that
opacity will allow for classes to have different definitions depending
on scope?

Tantek, is this your position also? Does anyone need more time or more
direct discussion to consider the question?

If this is carried through, hAtom should be able to stay as it is and
may be ready for promotion and use as it currently exists. It may be
important to define which class names have a globally-understood meaning
and which have context-sensitive meaning. If this trajectory is carried
through, I would suggest that top-level microformat names such as
"vcard", "feed", rel="tag", and the like should all have immutable
definitions that cannot be used in other microformats. A parser looking
for vcards on a page should be able to find them even though they are
embedded in in hAtom "author" contexts.

Child elements of these top-level microformats could change in
definition according to context, including "summary" and "title".
Parsers could not go searching for them except within the appropriate
contexts. All parsers should recognise whatever the mfo class eventually
gets transformed into and not assume familiar class names within those
scopes are understandable, except for top-level microformats.

Would all of the experienced microformatters be happy with this
resolution?

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From tantek at cs.stanford.edu  Sat Dec 31 09:06:23 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Dec 31 09:07:09 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <1136023084.6183.12.camel@tori>
Message-ID: <BFDBFA4C.65C5A%tantek@cs.stanford.edu>

On 12/31/05 1:58 AM, "Benjamin Carlyle" <benjamincarlyle@optusnet.com.au>
wrote:

> Ryan,
> 
> On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote:
>> ...I believe that context and specific rules on opacity are
>> sufficient for making thing unambiguous. Admittedly, with
>> microformats we tend to walk a fine line here, but its not without
>> reason- we're trying to optimize for publishers- which mainly
>> includes geeks who hand-write html in textareas and web developers/
>> designers.
> 
> Is it your position that hAtom's title class can have a different
> meaning to hCard's title, and that hAtom's summary class can have a
> different meaning to hReview's summary class? Is it your position that
> opacity will allow for classes to have different definitions depending
> on scope?
> 
> Tantek, is this your position also?

No.  Like I said[1], this is one of the two most common mistakes that
namespaces both enable and encourage.

[1]
<http://microformats.org/discuss/mail/microformats-discuss/2005-December/002
498.html>

1. The same term is used to mean two different things
2. Two terms are used to mean the same things

The current "established" microformats have avoided this problem by
essentially reusing from earlier microformats when possible, *before*
reusing from other standards.

One problem with most standards committees that design a new format is that
they are typically focused only on that one format, and often pick a new
vocabular instead of acknowledging previous vocabularies and attempting
compatibility.

That's not the microformat way.  We don't invent new terms when unnecessary.
Similarly, we prefer terms from older more established standards than newer
standards.

And by the way, one of the ways to optimize for publishers is to make the
overall vocabulary of microformats easy to understand and use.  Sticking
with one term = one meaning (and vice versa) makes this much easier.

Thanks,

Tantek


From tantek at cs.stanford.edu  Sat Dec 31 09:20:24 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Dec 31 09:21:14 2005
Subject: [uf-discuss] hAtom and blog-post-* need some more work
Message-ID: <BFDBFDAA.65C5B%tantek@cs.stanford.edu>

Though I definitely understand (and applaud) the eagerness to get an hAtom
format defined, things have definitely been rushed a bit, and there are
holes in the background research necessary to do a good job. Holes which, if
they were filled, would most likely result in quite a few changes to the
hAtom proposal.


For example:

http://microformats.org/wiki/blog-post-formats

1. The formats page has yet to describe "basic structure of an RSS
document".  This is a glaring hole.  Given how much more established RSS 2.0
is over Atom in the space of "syndication", it needs to be taken a lot more
seriously than that.

2. The formats page omits another old "blog post" standard - VJOURNAL.  I
believe Outlook supports VJOURNAL, and if so, greatly outnumbers all RSS
readers combined.  I've at least added a starter section for VJOURNAL:

http://microformats.org/wiki/blog-post-formats#VJOURNAL


One of the larger points here to consider is:

Just because other standards keep inventing new terms for the same thing,
doesn't mean we should.

Who knows why they invented new terms?  The simplest explanation is that
they just didn't know any better.  Did they do as much research into
existing standards? If so, then you should be able to find URLs to that
research which we should eagerly reuse.

We should actively AVOID inventing new terms for the same thing, even if
those "new terms" come from other standards.

The utility of hAtom comes from the 1:1 correspondence of Atom elements to
hAtom class names. 

This does not mean that the names have to be the same.  In fact, we should
be preferring names from previous microformats, and even previous standards
over new names introduced by Atom.

As long as it is made clear which hAtom class name translates into which
Atom element name, the goal of creating a 1:1 representation of hAtom in
XHTML is achieved.

Thanks,

Tantek


From davidjanes at blogmatrix.com  Sat Dec 31 09:58:29 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sat Dec 31 09:58:31 2005
Subject: [uf-discuss] hAtom and blog-post-* need some more work
In-Reply-To: <BFDBFDAA.65C5B%tantek@cs.stanford.edu>
References: <BFDBFDAA.65C5B%tantek@cs.stanford.edu>
Message-ID: <43B6C6C5.6020606@blogmatrix.com>

I don't even have the slightest idea how to respond to this. I've been
working on hAtom since August (hardly a rush), constantly soliciting
feedback, documenting progress and descions, recently providing code, 
and so forth. Now suddenly a new there's some new microformat principles 
-- not appearing on the Wiki in any obvious place or (particularly) the 
process page.

I have no issue renaming elements in hAtom, as long as there's a
microformats process that I'm actually following -- something that I've
seriously attempt to do since the second week I've been on this list. 
I'm assuming the process is driven by documentation and discussion, and 
not by personality.

David

PS. Does someone want to fill in the RSS feed structure? It's basically 
the same as Atom, with different terminology.

Tantek ?elik wrote:
> Though I definitely understand (and applaud) the eagerness to get an hAtom
> format defined, things have definitely been rushed a bit, and there are
> holes in the background research necessary to do a good job. Holes which, if
> they were filled, would most likely result in quite a few changes to the
> hAtom proposal.
> 
> 
> For example:
> 
> http://microformats.org/wiki/blog-post-formats
> 
> 1. The formats page has yet to describe "basic structure of an RSS
> document".  This is a glaring hole.  Given how much more established RSS 2.0
> is over Atom in the space of "syndication", it needs to be taken a lot more
> seriously than that.
> 
> 2. The formats page omits another old "blog post" standard - VJOURNAL.  I
> believe Outlook supports VJOURNAL, and if so, greatly outnumbers all RSS
> readers combined.  I've at least added a starter section for VJOURNAL:
> 
> http://microformats.org/wiki/blog-post-formats#VJOURNAL
> 
> 
> One of the larger points here to consider is:
> 
> Just because other standards keep inventing new terms for the same thing,
> doesn't mean we should.
> 
> Who knows why they invented new terms?  The simplest explanation is that
> they just didn't know any better.  Did they do as much research into
> existing standards? If so, then you should be able to find URLs to that
> research which we should eagerly reuse.
> 
> We should actively AVOID inventing new terms for the same thing, even if
> those "new terms" come from other standards.
> 
> The utility of hAtom comes from the 1:1 correspondence of Atom elements to
> hAtom class names. 
> 
> This does not mean that the names have to be the same.  In fact, we should
> be preferring names from previous microformats, and even previous standards
> over new names introduced by Atom.
> 
> As long as it is made clear which hAtom class name translates into which
> Atom element name, the goal of creating a 1:1 representation of hAtom in
> XHTML is achieved.

From drernie at opendarwin.org  Sat Dec 31 10:47:36 2005
From: drernie at opendarwin.org (Dr.Ernie Prabhakar)
Date: Sat Dec 31 10:47:34 2005
Subject: [uf-discuss] hAtom and blog-post-* need some more work
In-Reply-To: <43B6C6C5.6020606@blogmatrix.com>
References: <BFDBFDAA.65C5B%tantek@cs.stanford.edu>
	<43B6C6C5.6020606@blogmatrix.com>
Message-ID: <2C2F829E-31CF-42AA-ACD3-59CDD566B564@opendarwin.org>

Hi David,

On Dec 31, 2005, at 9:58 AM, David Janes -- BlogMatrix wrote:
> I don't even have the slightest idea how to respond to this. I've been
> working on hAtom since August (hardly a rush), constantly soliciting
> feedback, documenting progress and descions, recently providing  
> code, and so forth. Now suddenly a new there's some new microformat  
> principles -- not appearing on the Wiki in any obvious place or  
> (particularly) the process page.

I certainly affirm your efforts to play by the rules and solicit  
input.  I think what Tantek may be reacting to was the perceived  
pressure to "formalize" hAtom as an official microformat.  I think  
you've done a fantastic job of documenting 'hAtom' per se, but there  
are valid concerns about taking it to the next level.

> I have no issue renaming elements in hAtom, as long as there's a
> microformats process that I'm actually following -- something that  
> I've
> seriously attempt to do since the second week I've been on this  
> list. I'm assuming the process is driven by documentation and  
> discussion, and not by personality.

I think Tantek's principles are useful, and I agree they should be on  
the wiki.  Are they? I'm not sure:

>> Just because other standards keep inventing new terms for the same  
>> thing,
>> doesn't mean we should.
>> We should actively AVOID inventing new terms for the same thing,  
>> even if
>> those "new terms" come from other standards.

Thanks for all your efforts.

-- Ernie P.

>
> David
>
> PS. Does someone want to fill in the RSS feed structure? It's  
> basically the same as Atom, with different terminology.
>
> Tantek ?elik wrote:
>> Though I definitely understand (and applaud) the eagerness to get  
>> an hAtom
>> format defined, things have definitely been rushed a bit, and  
>> there are
>> holes in the background research necessary to do a good job. Holes  
>> which, if
>> they were filled, would most likely result in quite a few changes  
>> to the
>> hAtom proposal.
>> For example:
>> http://microformats.org/wiki/blog-post-formats
>> 1. The formats page has yet to describe "basic structure of an RSS
>> document".  This is a glaring hole.  Given how much more  
>> established RSS 2.0
>> is over Atom in the space of "syndication", it needs to be taken a  
>> lot more
>> seriously than that.
>> 2. The formats page omits another old "blog post" standard -  
>> VJOURNAL.  I
>> believe Outlook supports VJOURNAL, and if so, greatly outnumbers  
>> all RSS
>> readers combined.  I've at least added a starter section for  
>> VJOURNAL:
>> http://microformats.org/wiki/blog-post-formats#VJOURNAL
>> One of the larger points here to consider is:
>> Just because other standards keep inventing new terms for the same  
>> thing,
>> doesn't mean we should.
>> Who knows why they invented new terms?  The simplest explanation  
>> is that
>> they just didn't know any better.  Did they do as much research into
>> existing standards? If so, then you should be able to find URLs to  
>> that
>> research which we should eagerly reuse.
>> We should actively AVOID inventing new terms for the same thing,  
>> even if
>> those "new terms" come from other standards.
>> The utility of hAtom comes from the 1:1 correspondence of Atom  
>> elements to
>> hAtom class names. This does not mean that the names have to be  
>> the same.  In fact, we should
>> be preferring names from previous microformats, and even previous  
>> standards
>> over new names introduced by Atom.
>> As long as it is made clear which hAtom class name translates into  
>> which
>> Atom element name, the goal of creating a 1:1 representation of  
>> hAtom in
>> XHTML is achieved.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From davidjanes at blogmatrix.com  Sat Dec 31 11:53:06 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sat Dec 31 11:53:07 2005
Subject: [uf-discuss] hAtom and blog-post-* need some more work
In-Reply-To: <2C2F829E-31CF-42AA-ACD3-59CDD566B564@opendarwin.org>
References: <BFDBFDAA.65C5B%tantek@cs.stanford.edu>	<43B6C6C5.6020606@blogmatrix.com>
	<2C2F829E-31CF-42AA-ACD3-59CDD566B564@opendarwin.org>
Message-ID: <43B6E1A2.2030001@blogmatrix.com>

Dr.Ernie Prabhakar wrote:
> Hi David,
> 
> On Dec 31, 2005, at 9:58 AM, David Janes -- BlogMatrix wrote:
>> I don't even have the slightest idea how to respond to this. I've been
>> working on hAtom since August (hardly a rush), constantly soliciting
>> feedback, documenting progress and descions, recently providing code, 
>> and so forth. Now suddenly a new there's some new microformat 
>> principles -- not appearing on the Wiki in any obvious place or 
>> (particularly) the process page.
> 
> I certainly affirm your efforts to play by the rules and solicit input.  
> I think what Tantek may be reacting to was the perceived pressure to 
> "formalize" hAtom as an official microformat.  I think you've done a 
> fantastic job of documenting 'hAtom' per se, but there are valid 
> concerns about taking it to the next level.

Sure, and I've been consistently soliciting input on the nomenclature 
for a blog post microformat and changes have been made ... "bookmark", 
for example ... based on this input.

Furthermore, I have no issues with debating and or changing the 
nomenclature involved. For example, two or three days ago I explained 
the options that were available to us for the various elements, the 
precedence of HTML is using the word "title" or "heading" to mean 
"title" and why the word "summary" is particularly ill-suited in the the 
blog world for describing a title. (Direct responses: 0)

If there's a process, it can be followed by anyone, even if everyone 
here went away and was replaced by some other group of people. If hAtom 
breaks the process in any sort of non-trite way, I'll be the first to 
say that we should change it. But if we're just debating terminology, 
well let us debate that as opposed to a broad statement that I've been 
trumped by precedent, process and principles of the community.

> 
>> I have no issue renaming elements in hAtom, as long as there's a
>> microformats process that I'm actually following -- something that I've
>> seriously attempt to do since the second week I've been on this list. 
>> I'm assuming the process is driven by documentation and discussion, 
>> and not by personality.
> 
> I think Tantek's principles are useful, and I agree they should be on 
> the wiki.  Are they? I'm not sure:

Well, have a look. By this is something that should be debated by the 
community -- if the principle is "one name/one meaning" and "first use, 
first dibs", lets discuss the pros and cons of that.

Strangely, I note that on the few discussions on namespaces (for 
example, [1]) the answer isn't "we don't need namespaces since we'll 
never reuse CSS classes to mean something different than a previous use".

> 
>>> Just because other standards keep inventing new terms for the same 
>>> thing,
>>> doesn't mean we should.
>>> We should actively AVOID inventing new terms for the same thing, even if
>>> those "new terms" come from other standards.
> 
> Thanks for all your efforts.

No sweat. Well, actually, quite a bit of sweat -- which is why it's 
nicer to hear "we should be doing this differently" two months in rather 
than 4.

Regards, etc...
David

[1] 
http://microformats.org/wiki/faqs-for-rdf#What_about_namespaces_for_the_attributes.2C_should_I_use_.22xxx:term.22.3F
From benjamincarlyle at optusnet.com.au  Sat Dec 31 14:39:00 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Sat Dec 31 14:38:00 2005
Subject: [uf-discuss] hAtom and blog-post-* need some more work
In-Reply-To: <BFDBFDAA.65C5B%tantek@cs.stanford.edu>
References: <BFDBFDAA.65C5B%tantek@cs.stanford.edu>
Message-ID: <1136068742.6566.52.camel@tori>

Tantek,

On Sat, 2005-12-31 at 09:20 -0800, Tantek ?elik wrote:
> Though I definitely understand (and applaud) the eagerness to get an hAtom
> format defined, things have definitely been rushed a bit, and there are
> holes in the background research necessary to do a good job. Holes which, if
> they were filled, would most likely result in quite a few changes to the
> hAtom proposal.

The way I interpret this statement in the light of various irc
conversations you and I have been involved in is that hAtom turning the
corner onto a home straight. David has put in a great effort to get
hAtom to a stage where it meets two major design goals. It has a 1:1
correspondance to atom where elements are defined, and it is both
implementable and implemented. hAtom2Atom.xsl exists as the seed of a
reference implementation and now carries with it a growing test suite
too. hAtom is being tested both from the publisher and the subscriber
perspective.

Several specific issues are currently open on hAtom and are recorded at
the hatom-issues microformats page. Nomenclature is a broad area that
has lacked some definition in the current set of email exchanges. I
suggest that anyone with specific nomenclature issues bring them forward
for resolution. I think that now is the time to get involved to search
out these issues and all other outstanding issues to ensure hAtom makes
it through the gate with the blessing of all and without reservations
from anyone.

Email has a way of keeping frictions from being resolved, and that is
why I usually recommend the use of a more immediate medium such as IRC
for this kind of technical discussion. I think everyone here is more or
less on the same page. I think that once specific technical issues are
identified and discussed that the closeness of any relative positions
will be underscored.

> 1. The formats page has yet to describe "basic structure of an RSS
> document".  This is a glaring hole.  Given how much more established RSS 2.0
> is over Atom in the space of "syndication", it needs to be taken a lot more
> seriously than that.
> 2. The formats page omits another old "blog post" standard - VJOURNAL.  I
> believe Outlook supports VJOURNAL, and if so, greatly outnumbers all RSS
> readers combined.  I've at least added a starter section for VJOURNAL:
> http://microformats.org/wiki/blog-post-formats#VJOURNAL

I have tried to plug this gap. My brain is a little bit sushi'd out from
parsing standards documentation so there is bound to be a fair bit of
detail that is off the mark. Anyone who wants to build on the skeletons
that are now in place is welcome to, as they are welcome to refine them.
RSS is particularly difficult to get a grasp on due to it not really
defining anything. For the most part it seems to assume you know RSS and
how often elements are allowed to be repeated, so just lists out the
names.

Tantek, your focus on VJOURNAL is interesting. It is via our discussion
on #microformats[1] that I learned your interest is inspired by the
existing hCalendar and hCard microformats. VJOURNAL is an IETF standard
built into the same rfc as hCalendar uses as its source. Your suggestion
that this could be a useful source of nomenclature is an interesting
one. Although this format has likely never been used for blogging, it
does contain elements equivalent to significant subset to those of an
atom entry. I see the following possible equivalences:

Required:
atom:id           = VJOURNAL:UID? Maybe VJOURNAL:URL?
atom:title        = VJOURNAL:SUMMARY
atom:updated      = VJOURNAL:LAST-MODIFIED
Recommended:
atom:author       = VJOURNAL:ATTENDEE? Maybe ORGANIZER?
atom:content      = VJOURNAL:DESCRIPTION
atom:link         = VJOURNAL:URL?
atom:summary      = ?
Optional:
atom:category     = VJOURNAL:CATEGORIES
atom:contributor  = VJOURNAL:ATTENDEE?
atom:published    = VJOURNAL:DTSTART? Maybe VJOURNAL:CREATED?
atom:source       = ?
atom:rights       = ?

This summary may be useful for enlightening the unenlightened, however
it is probably not useful progress on hAtom in and of itself. We should
be focusing on specific issues. This list supports the suggestion that
atom:title be called "summary" in the microformat, however it does not
guve us an answer for atom:summary. RSS is similarly blank on the issue,
providing a description element but no summary except for its title.
Atom appears to be the origin of this separation of title and summary,
and this hallmark is something I would suggest that atom boosters would
prefer to keep in place.

So, should we call atom:title "summary"? If so, what should we call
atom:summary? Do any other sources of established terminology exist? Is
this the only real nomenclature issue, or are there more specific issues
waiting in the wings? I suggest taking this opportunity to pick on every
specific item you are not comfortable with and get it out in the open.
General issues without clear focus need to be refined and sharpened
until they are ready to be put onto hAtom-issues, and that should happen
as soon as possible.

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>
[1] http://rbach.priv.at/Microformats-IRC/2005-12-31

From kmarks at technorati.com  Sat Dec 31 15:48:36 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Sat Dec 31 15:48:47 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <BFD71181.659D5%tantek@cs.stanford.edu>
References: <BFD71181.659D5%tantek@cs.stanford.edu>
Message-ID: <569fc60987d4d897cf57ed88ab4623f9@technorati.com>


On Dec 27, 2005, at 3:43 PM, Tantek ?elik wrote:
> This means working deliberately to avoid the two cardinal sins that
> namespaces typical both enable and encourage:
>
> 1. The same term is used to mean two different things
> 2. Two terms are used to mean the same things

Indeed. In fact this is one of the advantages of Atom over RSS - 
resolving ambiguous usage.

In RSS 'description' is used for both summary and full-content feeds.

Atom defines distinct 'summary' and 'content' elements for this

In RSS 'link' is used for both 'entry permalink' and 'external linked 
element from a brief entry'.

>
> The current "established" microformats have avoided this problem by
> essentially reusing from earlier microformats when possible, *before*
> reusing from other standards.
>
> E.g. hReview has reused a lot from hCard and hCalendar.
>
> See http://microformats.org/wiki/existing-classes for an overview.
>
> In the case of 'title', Paul is right.  hCard (by way of vCard) has 
> defined
> 'title' to mean something in particular.
>
> In the case of hReview, we used 'summary' from hCalendar to serve this
> purpose.
>
> Would it be possible to do so for hAtom as well?

I would say that letting hCard use a bare 'title' to mean 'honorific 
form of address' was possibly a mistake in retrospect, but it is 
established.

That said, 'title' is context-defined in Atom - it can mean 'feed 
title' or 'entry title'.

Replacing this with 'summary' would be a mistake, as that needlessly 
blurs the summary/content distinction which is important for authors, 
readers and parsers alike.

I think keeping 'summary' and 'content' are good. hReview's and 
hCalendar's 'summary' is IMO not really a title in the atom/rss sense, 
but a one-line abbreviated form.

So I would suggest 'entry-title'.

From davidjanes at blogmatrix.com  Sat Dec 31 16:15:15 2005
From: davidjanes at blogmatrix.com (David Janes -- BlogMatrix)
Date: Sat Dec 31 16:15:16 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <569fc60987d4d897cf57ed88ab4623f9@technorati.com>
References: <BFD71181.659D5%tantek@cs.stanford.edu>
	<569fc60987d4d897cf57ed88ab4623f9@technorati.com>
Message-ID: <43B71F13.8060601@blogmatrix.com>

Kevin Marks wrote:
> 
> On Dec 27, 2005, at 3:43 PM, Tantek ?elik wrote:
>> This means working deliberately to avoid the two cardinal sins that
>> namespaces typical both enable and encourage:
>>
>> 1. The same term is used to mean two different things
>> 2. Two terms are used to mean the same things
> 
> Indeed. In fact this is one of the advantages of Atom over RSS - 
> resolving ambiguous usage.
> 
> In RSS 'description' is used for both summary and full-content feeds.
> 
> Atom defines distinct 'summary' and 'content' elements for this
> 
> In RSS 'link' is used for both 'entry permalink' and 'external linked 
> element from a brief entry'.
> 
>>
>> The current "established" microformats have avoided this problem by
>> essentially reusing from earlier microformats when possible, *before*
>> reusing from other standards.
>>
>> E.g. hReview has reused a lot from hCard and hCalendar.
>>
>> See http://microformats.org/wiki/existing-classes for an overview.
>>
>> In the case of 'title', Paul is right.  hCard (by way of vCard) has 
>> defined
>> 'title' to mean something in particular.
>>
>> In the case of hReview, we used 'summary' from hCalendar to serve this
>> purpose.
>>
>> Would it be possible to do so for hAtom as well?
> 
> I would say that letting hCard use a bare 'title' to mean 'honorific 
> form of address' was possibly a mistake in retrospect, but it is 
> established.
> 
> That said, 'title' is context-defined in Atom - it can mean 'feed title' 
> or 'entry title'.
> 
> Replacing this with 'summary' would be a mistake, as that needlessly 
> blurs the summary/content distinction which is important for authors, 
> readers and parsers alike.
> 
> I think keeping 'summary' and 'content' are good. hReview's and 
> hCalendar's 'summary' is IMO not really a title in the atom/rss sense, 
> but a one-line abbreviated form.
> 
> So I would suggest 'entry-title'.

Hi Kevin,

(1)
There'll still be a dual use for the name "summary", so we really have 
to establish whether this is going to be kosher or not. I'm cool if it's 
not ... if it's an enumerated design goal of the microformats community.

 From my POV, this is the only major sticking point to making a change 
(or not) is this point.

(2)
'entry-title' is cool with me, but my feeling was that this is 
explicitly resolved by context; that is, "title" appearing within a 
"entry" is an EntryTitle, whereas "title" appearing within a "feed" but 
not within an "entry" is a FeedTitle. This is fairly easy to resolve in 
an XPath sense and using DOM manipulation as I do in Python, and is the 
same rule Atom uses.

(3)
Note that opacity is the only real way to stop meaning conflicts in a 
meaning sense. For example, what if someone included a hCalendar object 
within a hReview ... "I saw this concert and this is what I thought of 
it, here's the schedule for the other nights the band is playing in 
town"? We'll still have multiple "summary" elements floating about.

(4)
Happy New Years everyone! I'm off to party. And jeez, Benjamin, 
shouldn't you be in bed by now? Unless you're not where your extension 
says you are!

Regards, etc...
David

From benjamincarlyle at optusnet.com.au  Sat Dec 31 18:35:39 2005
From: benjamincarlyle at optusnet.com.au (Benjamin Carlyle)
Date: Sat Dec 31 18:34:38 2005
Subject: [uf-discuss] hAtom draft - class="title"
In-Reply-To: <43B71F13.8060601@blogmatrix.com>
References: <BFD71181.659D5%tantek@cs.stanford.edu>
	<569fc60987d4d897cf57ed88ab4623f9@technorati.com>
	<43B71F13.8060601@blogmatrix.com>
Message-ID: <1136082939.7204.6.camel@tori>

On Sat, 2005-12-31 at 19:15 -0500, David Janes -- BlogMatrix wrote:
> Happy New Years everyone! I'm off to party. And jeez, Benjamin, 
> shouldn't you be in bed by now? Unless you're not where your extension 
> says you are!

I have officially sworn off sleep until hAtom is dusted, I return to
work next Monday, or my wife orders me to bed.

That's the problem with a GMT+10 timezone. All the cool kids are
chatting after 2am. Annual leave is my only time to have this kind of
fun, at least until my firstborn arrives in March. Then I'll be up
anyway.

Have a happy new year, and may 2006 be the year that publishers skip the
implementation of atom feeds and move straight on to hAtom :)

-- 
Benjamin Carlyle <benjamincarlyle@optusnet.com.au>

From tantek at cs.stanford.edu  Sat Dec 31 19:42:26 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Dec 31 19:43:09 2005
Subject: [uf-discuss] hAtom and blog-post-* need some more work
In-Reply-To: <43B6E1A2.2030001@blogmatrix.com>
Message-ID: <BFDC8F7E.65C9E%tantek@cs.stanford.edu>

On 12/31/05 11:53 AM, "David Janes -- BlogMatrix"
<davidjanes@blogmatrix.com> wrote:

> Dr.Ernie Prabhakar wrote:
>> Hi David,
>> 
>> On Dec 31, 2005, at 9:58 AM, David Janes -- BlogMatrix wrote:
>>> I don't even have the slightest idea how to respond to this. I've been
>>> working on hAtom since August (hardly a rush), constantly soliciting
>>> feedback, documenting progress and descions, recently providing code,
>>> and so forth.

First things first.

David, you have been doing an EXCELLENT job on hAtom.  I've largely stayed
out of the hAtom discussions precisely because you have been guiding them so
well. My input at this point is only to help improve a few details here and
there.  I want to make sure you understand that context.

>>> Now suddenly a new there's some new microformat
>>> principles -- not appearing on the Wiki in any obvious place or
>>> (particularly) the process page.

These are very much the principles of re-use.  And there have been some
notes on the process page about them.

However, you're right, the level of detail that I've outlined recently
hasn't been made clear on the wiki.

I will take as an action item the need to write up more detail on principles
and process around names and naming.


>> I certainly affirm your efforts to play by the rules and solicit input.
>> I think what Tantek may be reacting to was the perceived pressure to
>> "formalize" hAtom as an official microformat.  I think you've done a
>> fantastic job of documenting 'hAtom' per se, but there are valid
>> concerns about taking it to the next level.
> 
> Sure, and I've been consistently soliciting input on the nomenclature
> for a blog post microformat and changes have been made ... "bookmark",
> for example ... based on this input.

You absolutely have and have done a superb job of this - don't get me wrong.


> Furthermore, I have no issues with debating and or changing the
> nomenclature involved. For example, two or three days ago I explained
> the options that were available to us for the various elements, the
> precedence of HTML is using the word "title" or "heading" to mean
> "title" and why the word "summary" is particularly ill-suited in the the
> blog world for describing a title.

David, your ability to incorporate feedback and continue iterating is an
excellent example how someone who is spearheading a microformat should
behave.


> (Direct responses: 0)

A couple of minor pieces of feedback on this point.

A lot of collaborative efforts treat silence as consent.

While this is often a way to keep things moving quickly on implementations
and other development work, it's not necessarily the best for design, which
is what microformats essentially are.

To your credit David, you have explicitly *solicited* feedback on drafts,
changes, issues etc., so you have definitely done the right thing here.

What I want to point out is that the lack of response does not necessarily
imply approval.  It might (in general, not in this case), indicate
indifference.

Second, there we are using at least three different mediums of communication
to discuss microformats:

i. this list
ii. the irc channel irc:irc.freenode.net#microformats
iii. blog posts, either via tags "microformats", or perhaps the specific
microformat, e.g. "hAtom", or simply by mentioning those terms.

The fourth medium is of course the wiki, but that is more useful as a way to
capture state information (issues are both state and communication), than to
perform general communication.

Thus every microformat spec editor (and author/contributor) should pay
attention to all these communication channels, rather than expect a "direct
response" from any one.  Sometimes this is not possible, since not everyone
can monitor all channels.  Thus it is ok, to communicate these things on
more than one channel, e.g. by asking about an issue iin IRC, and then
adding it to the wiki, and then perhaps emailing a pointer to the issue on
the wiki.


> If there's a process, it can be followed by anyone, even if everyone
> here went away and was replaced by some other group of people.

Ideally yes.  We're certainly not at that level of detail in the process.

Now if that other group of people were cultural anthropologists, then they
would probably be able to figure out what we were doing, what direction we
were heading, and follow in our presumptive footsteps.



> If hAtom 
> breaks the process in any sort of non-trite way, I'll be the first to
> say that we should change it. But if we're just debating terminology,
> well let us debate that as opposed to a broad statement that I've been
> trumped by precedent, process and principles of the community.

Terminology is part of the *-brainstorming and spec drafting and *iteration*
phase.

One of our key principles is to draft something quickly (once the other
steps have been followed of course :), and then iterate rapidly based on
feedback.  This draft-quickly, iterate and evolve quickly is essential to
our rapid productivity.  The alternative is people getting stuck on their
first (or perhaps second) proposal due to the inertia of an implementation
or site or two.  And frankly, that's no good.


>>> I have no issue renaming elements in hAtom, as long as there's a
>>> microformats process that I'm actually following -- something that I've
>>> seriously attempt to do since the second week I've been on this list.
>>> I'm assuming the process is driven by documentation and discussion,
>>> and not by personality.
>> 
>> I think Tantek's principles are useful, and I agree they should be on
>> the wiki.  Are they? I'm not sure:

Part of it is written here:

http://microformats.org/wiki/process#Pages_to_consider_creating

But I will definitely admit I provide more explicit guidance on how to best
pick names and our overall vocabulary strategy for microformats.


> Well, have a look. By this is something that should be debated by the
> community -- if the principle is "one name/one meaning"

Certainly that.  The negatives of the alternatives are well established.

> and "first use, 
> first dibs", lets discuss the pros and cons of that.

Rather, the principles is reuse.  And the priority for us is to *first*
reuse from other microformats, and second to reuse from other well
established interoperable formats.  As the number of microformats grow,
we'll be reusing from those more and more often, because we'll inevitably
find that other standards have actually reinvented numerous wheels
(especially in the area of terminology).


> Strangely, I note that on the few discussions on namespaces (for
> example, [1]) the answer isn't "we don't need namespaces since we'll
> never reuse CSS classes to mean something different than a previous use".

That's *one* of the answers.

There is a key distinction here between the *root* class name (or names),
for a microformatted chunk of data, e.g. see:

 http://microformats.org/wiki/hcard-parsing#root_class_name

and the class names for the properties of that chunk are chosen based on
pre-existing microformat class names for properties, and "from pre-existing,
established, well-supported standards by reference". From:

 http://microformats.org/wiki/Template:semantic-xhtml-design-principles


>>>> Just because other standards keep inventing new terms for the same
>>>> thing, doesn't mean we should.
>>>> We should actively AVOID inventing new terms for the same thing, even if
>>>> those "new terms" come from other standards.
>> 
>> Thanks for all your efforts.

Yes, everyone in the microformats community is very thankful for your
efforts on hAtom David.  I think one of things we realize is that hAtom has
*incredible* potential, and so we're even more self-conscious about getting
it "right".


> No sweat. Well, actually, quite a bit of sweat -- which is why it's
> nicer to hear "we should be doing this differently" two months in rather
> than 4.

You are absolutely correct David.  With the rapid iteration of feedback,
issues, specification, and implementations, it is definitely the time to
bring up any outstanding issues about hAtom, to try using it on our own
blogs, and to report back how it works (or doesn't work).

We need to be our own best and harshest critics so that when we declare
hAtom ready for the "outside world", we already know exactly where all the
"soft points" are, and can provide good guidance.

I for one am working on a rewrite of my blog markup for January (though I
don't know if I will finish it in the next 5 hours :), based on hAtom.

The key here is to be up front with folks.

Please give hAtom a try and keep in mind that it will almost certainly
change, as can any of the "Exploratory discussions" or "Drafts" may.  If
that scares you, and you prefer stability before testing the waters, then
consider waiting a month (or two at most), and in the mean time, try out the
"Specifications" for now.

Thanks,

Tantek