From carl.beeth at gmail.com  Fri Jul  1 15:03:08 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul  1 14:54:49 2005
Subject: [microformats-discuss] Extending the embedded information
Message-ID: <e8ca2e11050701150345c53a2a@mail.gmail.com>

I'm very excited about the microformats, seems I have been looking for
something like this for ages. I Even found a old mail from 98 in the
w3c html discussion list where we talk along those lines.
<http://lists.w3.org/Archives/Public/www-html/1998Apr/0016.html>

Although I am all for embedding semantics in web pages, I'm missing
one thing in the microformats: a way to semantically link to more
complete version of the information when one does not want to pollute
the page with all the information.

Here is an example from the site:
<div class="vcard">
 <a class="url fn" href="http://tantek.com/">
  Tantek ?elik
 </a>
 <div class="org">Technorati</div>
</div>

Now what if we wanted to have a to make more information available
with out necessarily displaying it in the web page. maybe something
like this:

<div class="vcard">
 <a class="url fn" href="http://tantek.com/">
  Tantek ?elik
 </a>
 <div class="org">Technorati</div>
 <a href="http://tantek.com/vcard.txt" class="vcardfile">vcard</a>
</div>

The reason the class is important in on the link is that it allows the
user agent/crawler to identify what is behind the link. a possible
alternative would be to use type="text/vcard" but sadly I think they
are supposed to be mimetypes but could not find the mime type for
vcard

Does this make sense?

Carl
__________________
Carl Beeth
http://www.beeth.com/
From ryan at technorati.com  Fri Jul  1 17:10:05 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul  1 17:01:50 2005
Subject: [microformats-discuss] Extending the embedded information
In-Reply-To: <e8ca2e11050701150345c53a2a@mail.gmail.com>
References: <e8ca2e11050701150345c53a2a@mail.gmail.com>
Message-ID: <F21E4FE3-9BFE-46D9-A95B-34E11865CC88@technorati.com>

On Jul 1, 2005, at 3:03 PM, Carl Beeth wrote:
> I'm very excited about the microformats, seems I have been looking for
> something like this for ages. I Even found a old mail from 98 in the
> w3c html discussion list where we talk along those lines.
> <http://lists.w3.org/Archives/Public/www-html/1998Apr/0016.html>
>
> Although I am all for embedding semantics in web pages, I'm missing
> one thing in the microformats: a way to semantically link to more
> complete version of the information when one does not want to pollute
> the page with all the information.

We don't have a universal solution for this situation at the current  
time. However, in the given example, there are possible solutions.

> ...
>
> Now what if we wanted to have a to make more information available
> with out necessarily displaying it in the web page. maybe something
> like this:
>
> <div class="vcard">
>  <a class="url fn" href="http://tantek.com/">
>   Tantek ?elik
>  </a>
>  <div class="org">Technorati</div>
>  <a href="http://tantek.com/vcard.txt" class="vcardfile">vcard</a>
> </div>

First, you could always put the info on the page, but use a  
display:none to hide it.

Second, one of the observations that led to the creation of XFN, was  
that we already use urls as a proxy to identify people. Given that,  
why can't the link above (http://tantek.com) be enough? Tantek could  
certainly have an identifying vcard on that page, or could link to it  
with a rel="me".

Perhaps there are other opinions here?

> The reason the class is important in on the link is that it allows the
> user agent/crawler to identify what is behind the link.

Actually, a rel attribute would probably be better than a class value.

> ...

-ryan

--
Ryan King
ryan@technorati.com
AIM: kingryan331


From ryan at technorati.com  Fri Jul  1 20:14:32 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul  1 20:06:13 2005
Subject: [microformats-discuss] personal intro
Message-ID: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>

We've had a lot of people join the list recently and most people  
probably don't know who else is subscribed to the list (there's 51  
total). So, some personal introductions are in order... I'll start:

I'm Ryan King. I'm currently working at Technorati and studying at  
the University of San Francisco. My background is in Computer Science  
and most of my development experience is in web development (html/css/ 
php/(my|postgres)sql).

I have a blog at http://theryanking.com/blog/.

-ryan
--
Ryan King
ryan@technorati.com


From ryan at technorati.com  Fri Jul  1 21:33:12 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul  1 21:24:51 2005
Subject: [microformats-discuss] geo format BoF
Message-ID: <53B60B5E-F3D9-406B-92D1-47F809B1B6A4@technorati.com>

On Thursday evening Tantek, Kevin and I hosted a geo format BoF at  
the Where 2.0 conference. A rough transcript is available at:

http://microformats.org/wiki/geo-bof-2005-06-30

-ryan

--
Ryan King
ryan@technorati.com


From bud at thecommunityengine.com  Fri Jul  1 22:04:40 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul  1 21:56:14 2005
Subject: [microformats-discuss] Extending the embedded information
In-Reply-To: <F21E4FE3-9BFE-46D9-A95B-34E11865CC88@technorati.com>
References: <e8ca2e11050701150345c53a2a@mail.gmail.com>
	<F21E4FE3-9BFE-46D9-A95B-34E11865CC88@technorati.com>
Message-ID: <75A60029-8D79-4107-BE59-520E03B63FF4@thecommunityengine.com>

On Jul 1, 2005, at 20:10, Ryan King wrote:

> First, you could always put the info on the page, but use a  
> display:none to hide it.
>
> Second, one of the observations that led to the creation of XFN,  
> was that we already use urls as a proxy to identify people. Given  
> that, why can't the link above (http://tantek.com) be enough?  
> Tantek could certainly have an identifying vcard on that page, or  
> could link to it with a rel="me".
>
> Perhaps there are other opinions here?

One way to think of this is as follows.  The microformat is a data  
transmission format as well as a display format.  Under this  
interpretation, the question is what is the minimal amount of  
information that fulfills the user's needs when they go to the hCard.

The answer for hCard would seem to be some minimal subset of  
information that would go on the whole card.  For instance, just the  
business contact information, maybe just a name.  You could then put  
links to fuller versions of the hCard.  These links would not need  
any special formatting but would lead to valid hCard entries.

Bud

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050702/27c8e96f/attachment.htm
From bud at thecommunityengine.com  Sat Jul  2 00:43:18 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sat Jul  2 00:34:52 2005
Subject: [microformats-discuss] Location Tagging
Message-ID: <BA7B6FCC-AA1A-40B7-AEAE-FBE4B6EEBC68@thecommunityengine.com>

At the geo microformats BOF, we decided to give some thought to  
location tagging, suffering a bit of insomnia back here on the East  
Coast after a week on the West Coast, I've started that ball rolling  
here:

http://microformats.org/wiki/location-formats#Location_Tagging

Bud
From suw.charman at gmail.com  Sat Jul  2 03:46:52 2005
From: suw.charman at gmail.com (Suw Charman)
Date: Sat Jul  2 03:38:23 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <138647dc0507020346742a4561@mail.gmail.com>

Good idea, Ryan. 

Ok, I'm Suw Charman. I am a blogger, writer and blog consultant based
in the UK. I blog at www.corante.com/strange and
chocnvodka.blogware.com. I'm friends with Kevin and Tantek and it's
their fault I'm here. I'm entirely non-programmery, so more interested
in communicating about microformats to a wider, non-geek community.

Suw



On 7/2/05, Ryan King <ryan@technorati.com> wrote:
> We've had a lot of people join the list recently and most people
> probably don't know who else is subscribed to the list (there's 51
> total). So, some personal introductions are in order... I'll start:
> 
> I'm Ryan King. I'm currently working at Technorati and studying at
> the University of San Francisco. My background is in Computer Science
> and most of my development experience is in web development (html/css/
> php/(my|postgres)sql).
> 
> I have a blog at 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
> 


-- 
-----------------------------------------------

+44 (0)7813 769685
AIM: nefibach
IRC: #suwcharman on freenode
Timezone: GMT
http://chocnvodka.blogware.com/
http://www.corante.com/strange/
From kinrowan at gmail.com  Sat Jul  2 04:48:14 2005
From: kinrowan at gmail.com (kinrowan)
Date: Sat Jul  2 04:39:47 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <42C67EFE.9070909@gmail.com>

I'm Cori Schlegel.  I'm a self-taught IT developer at a mid-size 
manufacturing firm in the US Midwest.  My background prior to that is as 
a project manager.

I blog at http://kinrowan.net.

cori


Ryan King wrote:

> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order... I'll start:
>
> I'm Ryan King. I'm currently working at Technorati and studying at  
> the University of San Francisco. My background is in Computer Science  
> and most of my development experience is in web development (html/css/ 
> php/(my|postgres)sql).
>
> I have a blog at 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 marclaporte at avantech.net  Sat Jul  2 05:41:27 2005
From: marclaporte at avantech.net (Marc Laporte)
Date: Sat Jul  2 05:33:10 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <42C68B77.7000204@avantech.net>

Hi!

My name is Marc Laporte and I am a project admin for Tiki CMS/Groupware.
http://sourceforge.net/projects/tikiwiki/
http://freshmeat.net/projects/tiki/

What I am basically looking for is an equivalent to RSS feeds (for news 
data) but for others types of data within Tiki CMS/Groupware. Ex.: I 
would like to be able to share calendar between Tiki-powered sites and 
other applications ( ex.: http://webcalendar.sourceforge.net/)

Best regards,

M ;-)



Ryan King wrote:

> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order... I'll start:
>
> I'm Ryan King. I'm currently working at Technorati and studying at  
> the University of San Francisco. My background is in Computer Science  
> and most of my development experience is in web development (html/css/ 
> php/(my|postgres)sql).
>
> I have a blog at 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
>

-- 
M ;-)

//////////////////////////////////////////////////////////////////
/                                                                /
/ Marc Laporte       <|>                  http://marclaporte.com /
/ Avantech.net       <|>                     http://avantech.net /
/ Tiki CMS/Groupware <|> http://tikiwiki.org/UserPagemarclaporte /
/                                                                /
//////////////////////////////////////////////////////////////////

From andyhume at thedredge.org  Sat Jul  2 06:31:26 2005
From: andyhume at thedredge.org (Andy Hume)
Date: Sat Jul  2 06:23:00 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <193FE71D-EB8C-457B-87A7-757357171D51@thedredge.org>

Hi.

I'm Andy Hume, and my blog is http://thedredge.org.

I live in London, work for Multimap.com as a front end developer on  
the public site, and as such have a particular interest in location  
formats and geo-tagging -  as well as microformats in general.

Best,

Andy Hume


On 2 Jul 2005, at 04:14, Ryan King wrote:


> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order... I'll start:
>
> I'm Ryan King. I'm currently working at Technorati and studying at  
> the University of San Francisco. My background is in Computer  
> Science and most of my development experience is in web development  
> (html/css/php/(my|postgres)sql).
>
> I have a blog at 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
>
>
>
>

Andy Hume
Web Developer

Mail: andyhume@thedredge.org
http://thedredge.org
Mobile: +44 (0)7957 208843
Skype: andyhume



From markl at glyphic.com  Sat Jul  2 08:03:54 2005
From: markl at glyphic.com (Mark Lentczner)
Date: Sat Jul  2 07:55:29 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <153C9182-196C-47C8-862D-9D61066EDFE9@glyphic.com>

Hi all -

I'm Mark Lentczner.  I have a background in programming language  
design and implementation, computer music, and web technologies  
(including cell-phone based web access).  Currently, I'm a stay-at- 
home-dad working on open-source projects.

My big project is Wheat, a language and environment for putting data  
on the web:  Every object has a URI, and can render into XHTML  
fragments (down to locals on the stack!).  Interaction between  
objects is modeled on REST so that can scale across the internet  
(pointers in the languages are just URLs).  Because of the nature of  
Wheat's objects, they are already rendered in micro-format style.   
I'm looking forward to a tight integration of the micro-format work  
into Wheat.
     http://www.wheatfarm.org/

     - Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
markl@glyphic.com


From solitude at solitude.dk  Sat Jul  2 08:19:11 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Sat Jul  2 08:10:43 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <op.stakt9txares2h@mail.solitude.dk>

On Sat, 02 Jul 2005 05:14:32 +0200, Ryan King <ryan@technorati.com> wrote:

> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order...

I'm Andreas Haugstrup. I'm doing the graduate program in Communication at  
the University of Aalborg in Denmark (nothing particulary web-related, but  
it might turn that way). Currently I'm doing an internship as a part of my  
studies at the community TV station in Ann Arbor, Michigan. The hot summer  
is slowly killing me.

As a result of my schoolwork my view on HTML comes from text analysis. I  
leave engineering to my twin brother.

Since last October I have been wanting to create a HTML profile for  
weblogs. Various things always seem to get me off track, so I hope I can  
work with people here once I get a new draft written up. The last one is  
 from January, and I need to change some things. It includes describing the  
structure of a typical blog relations (permalink, ping/trackback,  
enclosures and groups of enclosures). My starting point is weblogs, but I  
hope that it can be so general that all websites can benifit.

I blog at <URL: http://www.solitude.dk/ >

- Andreas
-- 
<URL:http://www.solitude.dk/>
Commentary on media, communication, culture and technology.
From bud at thecommunityengine.com  Sat Jul  2 09:50:28 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sat Jul  2 09:41:56 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <342A6398-2AB9-4D83-9685-B88AEBBE427F@thecommunityengine.com>

On Jul 1, 2005, at 23:14, Ryan King wrote:

> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order.

I'm Bud Gibson.  I'm founder of The Community Engine.  We help  
companies develop information communities around their products and  
services.   These communities allow companies to streamline their  
operations and gain Internet visibility.  My interest in microformats  
derives from my belief that *the* significant opportunity in online  
communities lies in distributed communities.  These distributed  
communities are essentially aggregations and remixes of individuals'  
and other groups' contributions.  Microformats enable that better  
than any other approach I have seen.

I have a BS in French and Linguistics from Georgetown, an MBA from  
Wharton, and a PhD from Carnegie Mellon.  In May 2006, I'll be  
leaving University of Michigan's Ross School of Business where I will  
have been on faculty for nine years.

I have a blog at:  http://thecommunityengine.com.

Bud

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050702/c92713e8/attachment.htm
From seni at dystopia.com  Sat Jul  2 09:52:48 2005
From: seni at dystopia.com (Seni Sangrujee)
Date: Sat Jul  2 09:43:33 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <42C6C660.7000004@dystopia.com>

Hi, I'm Seni Sangrujee.  I'm currently working at Berkeley Lab 
(http://www.lbl.gov/) as a software consultant.

In my spare time, I work on several mobile phone apps as well as a group 
planning site called GefilterFish (http://gefilter.com).  I'm interested 
in geo-tagging and calendar formats.

-seni

From mike at stamen.com  Sat Jul  2 11:14:35 2005
From: mike at stamen.com (Michal Migurski)
Date: Sat Jul  2 11:06:03 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <E35C97A4-6993-41CA-80E8-BB56A333097F@stamen.com>

> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order...

Hi everyone, I joined this list yesterday after meeting Ryan, Ian and  
Tantek at Where 2.0.

My name is Michal Migurski, I'm a principal at Stamen Design in San  
Francisco (http://stamen.com). Our work primarily focuses on data  
visualization and user interface development. My technological  
knowledge is also primarily in web development (html/css/php/(my| 
postgre)sql/python/perl).

I'm here because I'm one of the developers of ReBlog (http:// 
reblog.org), a hosted RSS reader and republisher that recently got  
some unexpected microformat-related attention from Marc Canter  
(http://reblg.com/). We've been considering adding microformat  
awareness to ReBlog for some time, so I'm here to learn more about  
"official" formats as well as folk formats - Del & Flickr tags, for  
example.

I have a blog at http://mike.teczno.com/.

-mike.

----------------------------------------------------------------
michal migurski- mike@stamen.com
                  415.558.1610


From jeff at vertexdev.com  Sat Jul  2 13:34:33 2005
From: jeff at vertexdev.com (Jeff Barr)
Date: Sat Jul  2 13:26:24 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <153C9182-196C-47C8-862D-9D61066EDFE9@glyphic.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
	<153C9182-196C-47C8-862D-9D61066EDFE9@glyphic.com>
Message-ID: <42C6FA59.5050008@vertexdev.com>

Hi,

I am Jeff Barr, and I was invited in to this group by Tantek.

During the day I'm the Web Services Evangelist for Amazon.com
(http://www.amazon.com/webservices). We've exposed our entire
product catalog and our shopping cart using SOAP and REST-based
APIs. We've also exposed the 300TB archive of Alexa crawl
data.

Before dawn and after dusk I work on Syndic8 (http://www.syndic8.com),
a large directory of RSS and Atom feeds. Syndic8 has over 400,000
feeds in its database, a complete XML-RPC interface, and a very
strong user community.

Jeff;

-- 
* RSS Feeds:       http://www.syndic8.com
* Blog:            http://www.syndic8.com/~jeff/blog/
* Web Services:    http://aws.typepad.com
* Resume:          http://www.syndic8.com/~jeff/resume.html

From subs at angryamoeba.co.uk  Sat Jul  2 14:53:23 2005
From: subs at angryamoeba.co.uk (Dan Glegg (angryamoeba))
Date: Sat Jul  2 14:44:52 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <A5AF47D7-5338-43C5-8BD1-998392CBCA68@angryamoeba.co.uk>

Hi all,

My name's Dan Glegg, and I'm a plain old web developer working with  
web applications in standards-compliant languages, and multimedia  
applications using actionscript. I'd like to chip off actionscript in  
favour of markup all the way, and things are starting to shape up in  
a way that makes that possible.

I've been developing applications for around eight years, and I'm  
interested in using microformats to convey metadata and licensing  
information relating to multimedia files (specifically audio in a  
purely selfish sense as I have an application in the works that could  
really do with it). I see this as extending and complimenting  
relLicense, but that's a decision to be made formally later down the  
line.

I'm also interested in providing server-side helpers to let  
developers provide microformatted data more easily - and help them  
keep their microformat implementations up-to-date within their  
applications as these standards develop.

Oh, and I'm in england. Nice to meet you all.

Cheers,
Dan

p.s. List moderator, apologies for a stray mail from my other,  
default address. My mistake entirely.

On 2 Jul 2005, at 04:14, Ryan King wrote:

> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order... I'll start:
>
> I'm Ryan King. I'm currently working at Technorati and studying at  
> the University of San Francisco. My background is in Computer  
> Science and most of my development experience is in web development  
> (html/css/php/(my|postgres)sql).
>
> I have a blog at 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 progrium at gmail.com  Sun Jul  3 03:49:44 2005
From: progrium at gmail.com (Jeff Lindsay)
Date: Sun Jul  3 03:41:03 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <ec47901a05070303493d7adc2d@mail.gmail.com>

Hi,

I'm Jeff Lindsay. I'm a developer and entrepreneur. I help organize
parties for developers called SuperHappyDevHouse (you're all invited:
http://upcoming.org/event/22655/ ), which is where I met Tantek and
Ryan.

I like microformats, in particular the idea of writing tools for them.

Blog: http://blogrium.com

Btw, Mark Lentczner, nice plug. Hope you can make it to the party, I
want to learn more about Wheat and see it in action.
From chris.messina at gmail.com  Sun Jul  3 10:12:01 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Sun Jul  3 10:03:19 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <ec47901a05070303493d7adc2d@mail.gmail.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
	<ec47901a05070303493d7adc2d@mail.gmail.com>
Message-ID: <1bc4603e05070310124db5df3c@mail.gmail.com>

Hi all,

My name is Chris Messina and I work for a startup formerly known as
Round Two (we changed our name last Thursday...). Prior to this work,
I was at CivicSpace Labs, creating a toolkit for grassroots community
organizing and volunteering as an admin team member of and designer
for SpreadFirefox.com.

I'm now working with Ryan and Tantek to widen the support for
microformats both in publishing tools like Drupal (on which CivicSpace
is based) and WordPress and, with Round Two, getting a similar level
of support and awareness into the browser.

I'm particularly interested in using XHTML as a dataformat/API and
what it might mean for content providers and creators to have the
benefits of microformats without ever having to touch a line of code.
It seems to me that when both the publishing tools and the user agents
become aware of microformats as a standard, an immense amount of
possibility is exposed.

Chris
From andyhume at thedredge.org  Sun Jul  3 10:19:49 2005
From: andyhume at thedredge.org (Andy Hume)
Date: Sun Jul  3 10:11:07 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <1bc4603e05070310124db5df3c@mail.gmail.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
	<ec47901a05070303493d7adc2d@mail.gmail.com>
	<1bc4603e05070310124db5df3c@mail.gmail.com>
Message-ID: <A8AE14C5-85A7-4DD5-B4DE-3DA483ED4740@thedredge.org>

Hi Chris,


> support for microformats both in publishing tools like Drupal (on  
> which CivicSpace
> is based) and WordPress
>

What kind of microformat support are you looking to get in to these  
publishing tools? Obviously wordpress has built in support for XFN.  
What else are you trying to get happening?

Andy



On 3 Jul 2005, at 18:12, Chris Messina wrote:


> Hi all,
>
> My name is Chris Messina and I work for a startup formerly known as
> Round Two (we changed our name last Thursday...). Prior to this work,
> I was at CivicSpace Labs, creating a toolkit for grassroots community
> organizing and volunteering as an admin team member of and designer
> for SpreadFirefox.com.
>
> I'm now working with Ryan and Tantek to widen the support for
> microformats both in publishing tools like Drupal (on which CivicSpace
> is based) and WordPress and, with Round Two, getting a similar level
> of support and awareness into the browser.
>
> I'm particularly interested in using XHTML as a dataformat/API and
> what it might mean for content providers and creators to have the
> benefits of microformats without ever having to touch a line of code.
> It seems to me that when both the publishing tools and the user agents
> become aware of microformats as a standard, an immense amount of
> possibility is exposed.
>
> Chris
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>
>

Andy Hume
Web Developer

Mail: andyhume@thedredge.org
http://thedredge.org
Mobile: +44 (0)7957 208843
Skype: andyhume



From bud at thecommunityengine.com  Sun Jul  3 23:25:29 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul  3 23:16:40 2005
Subject: [microformats-discuss] Going from preliminary microformats
	explorations to specifications
Message-ID: <618FAA2C-B228-4B17-9A3E-2D762CCF0E49@thecommunityengine.com>

Building on Ryan's excellent write-up, I have added a note on how to  
move your microformat along from preliminary explorations to full- 
blown specification.  This largely mirrors my effort to develop xFolk  
from outside the core group of microformat developers (though they  
helped a lot from a distance, a lot of the process remained implicit).

The note is very rudimentary, but I think it starts to give an idea  
about how to proceed and is action oriented.  I'm expecting that  
there will be a lot of edits.  At the very least, someone needs to  
add hyperlinks.  Here's the link:

http://microformats.org/wiki/process#Moving_from_Stage_to_Stage

Bud

From michiel at caribmedia.com  Mon Jul  4 06:03:30 2005
From: michiel at caribmedia.com (Michiel van der Blonk)
Date: Mon Jul  4 05:54:46 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <42C933A2.6050602@caribmedia.com>

Hi

My name is Michiel van der Blonk, I am a web developer. The last half 
year I have done so much CSS I have nightmares about it. Ok, that's a 
bit too personal. I am also a trainer, doing mostly .NET.

I am interested in the future of the web, and very pro-semantic-web. I 
don't know much about microformats, but am willing to learn more here.

BTW: I live on Aruba. I only have a dutch blog, unfortunately, it's 
here: http://michiel.vanderblonk.com

Michiel

Ryan King wrote:

> We've had a lot of people join the list recently and most people  
> probably don't know who else is subscribed to the list (there's 51  
> total). So, some personal introductions are in order... I'll start:
>
> I'm Ryan King. I'm currently working at Technorati and studying at  
> the University of San Francisco. My background is in Computer Science  
> and most of my development experience is in web development (html/css/ 
> php/(my|postgres)sql).
>
> I have a blog at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050704/78c3924f/attachment.htm
From simonlilja at gmail.com  Mon Jul  4 07:31:29 2005
From: simonlilja at gmail.com (Simon)
Date: Mon Jul  4 07:22:37 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <80436ac10507040731840379a@mail.gmail.com>

Hi, I'm Simon Lilja and I'm an amateur web designer from Sweden.

I for one do not have a personal blog/site, my host had a slight mishap 
while moving
the databases to a new server and they were lost in space. (whoever told me 
that
backing up databases was silly should be forced to eat my grandmas pork 
chops
for a month, they taste horrible)

I got to hear about microformats from a fellow staff member (I know you're 
out there somewhere)
at neverside.com <http://neverside.com>. Actually, I heard about it before 
but he got me interested in it
and made me sign up to this mail list. I like the whole idea behind it and 
can't
wait to learn more. (I'll admit it, I was rather puzzled about microformats 
when
I first visited the site, it took me a while to understand it)

Just like some of the others I hope to learn more about microformats. :)



On 7/2/05, Ryan King <ryan@technorati.com> wrote:
> 
> We've had a lot of people join the list recently and most people
> probably don't know who else is subscribed to the list (there's 51
> total). So, some personal introductions are in order... I'll start:
> 
> I'm Ryan King. I'm currently working at Technorati and studying at
> the University of San Francisco. My background is in Computer Science
> and most of my development experience is in web development (html/css/
> php/(my|postgres)sql).
> 
> I have a blog at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050704/23111566/attachment.htm
From mail at webmapper.net  Tue Jul  5 03:20:34 2005
From: mail at webmapper.net (Edward Mac Gillavry)
Date: Tue Jul  5 03:11:36 2005
Subject: [microformats-discuss] personal intro
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <001101c5814b$2f178cd0$2201a8c0@webmapper>

Hi folks,

I'm a Dutch (really!) cartographer and work as an independent developer of 
online mapping applications using Open Source technology whenever I can. You 
can read my thoughts on web cartography, online mapping and geo-blogging at 
(www.webmapper.net). And yes, I used to work for Multimap.com before I 
re-migrated (is there such a word?) to the Netherlands.

Attended Where 2.0 last week and joined the list after I met Tantek, Ryan 
and Ian at the geo microformats BOF session. Having followed similar 
discussions on the geowanking mailing list, I hope that this discussion list 
benefits from having a fairly focussed objective in mind for using a geo 
microformat.

Previous discussions are found here:
- Location encodings, URL schemes 
(http://lists.burri.to/pipermail/geowanking/2005-February/001399.html)
- Formal location metadata in blog description area 
(http://lists.burri.to/pipermail/geowanking/2005-January/001279.html)

Kind regards,

Edward

----- Original Message ----- 
From: "Ryan King" <ryan@technorati.com>
To: "Microformats Discuss" <microformats-discuss@microformats.org>
Sent: Saturday, July 02, 2005 5:14 AM
Subject: [microformats-discuss] personal intro


> We've had a lot of people join the list recently and most people  probably 
> don't know who else is subscribed to the list (there's 51  total). So, 
> some personal introductions are in order... I'll start:
>
> I'm Ryan King. I'm currently working at Technorati and studying at  the 
> University of San Francisco. My background is in Computer Science  and 
> most of my development experience is in web development (html/css/ 
> php/(my|postgres)sql).
>
> I have a blog at 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 ryan at technorati.com  Tue Jul  5 11:01:09 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul  5 10:52:13 2005
Subject: [microformats-discuss] geo format BoF
In-Reply-To: <53B60B5E-F3D9-406B-92D1-47F809B1B6A4@technorati.com>
References: <53B60B5E-F3D9-406B-92D1-47F809B1B6A4@technorati.com>
Message-ID: <B4E0A5FF-A36E-487A-8A9A-10B841722E95@technorati.com>

I've blogged an overview of the event: http://www.microformats.org/ 
blog/2005/07/05/locations-microformat/

-ryan

On Jul 1, 2005, at 9:33 PM, Ryan King wrote:

> On Thursday evening Tantek, Kevin and I hosted a geo format BoF at  
> the Where 2.0 conference. A rough transcript is available at:
>
> http://microformats.org/wiki/geo-bof-2005-06-30
>
> -ryan
>
> --
> Ryan King
> ryan@technorati.com
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://micr

--
Ryan King
ryan@technorati.com


From dougal at gunters.org  Tue Jul  5 14:19:27 2005
From: dougal at gunters.org (Dougal Campbell)
Date: Tue Jul  5 14:10:41 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <42CAF95F.9030302@gunters.org>

I'm Dougal Campbell, and I'm involved in two different community things 
currently. The first is WordPress, which is a blog system that I imagine 
many of you have heard of. The second is Ping-O-Matic, which is an 
XML-RPC ping redistribution service (see pingomatic.com if that doesn't 
make any sense). My interest in microformats is mostly related to my 
blogging activities.

In addition to blogging, I've also been active in other areas over the 
years, to varying degrees. I've contributed code to the Persistance of 
Vision raytracer (I coded the hexagon texture many, many years ago), I 
used to be fairly active in the anti-spam community (e.g. in the 
net.admin.net-abuse.email newsgroup), and I had minor mentions in Alan 
Schwartz and Simson Garfinkle's "Stopping Spam" and in Paul Robichaux's 
"Managing Microsoft Exchange Server".

My current dayjob involves backend perl coding for a network access 
portal used in the hospitality industry (hotels, airports, etc).

-- 
Dougal Campbell <dougal@gunters.org>
http://dougal.gunters.org/

From tjameswhite at yahoo.com  Tue Jul  5 18:02:21 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Tue Jul  5 17:53:13 2005
Subject: [microformats-discuss] Re: personal intro
In-Reply-To: <20050705190003.3AEF9F08631@microformats>
Message-ID: <20050706010221.37108.qmail@web30605.mail.mud.yahoo.com>

Hello,

I'm Tim White, a self-taught web developer working at a large
publishing company in Farmington Hills, MI. Since surfing the web and
stumbling across sites like WASP and then reading Zeldman's book, I've
become more and more intrigued with the idea of standards and semantic
coding.

I'm not quite sure where microformats fit in, but I'm interested to see
where they lead -- and they just may help with a problem I have. I have
a 1 month old daughter, so I haven't had much time to read up on
everything yet.

I see that there are a couple of other Michigan microformaters in the
crowd; perhaps our own small meet-up would be in order some day.

Tim
www.tjameswhite.com/blog


		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 

From mnl at well.com  Tue Jul  5 23:46:17 2005
From: mnl at well.com (Mike Liebhold)
Date: Tue Jul  5 23:37:06 2005
Subject: [microformats-discuss] geowanking microformats thread
In-Reply-To: <20050706010221.37108.qmail@web30605.mail.mud.yahoo.com>
References: <20050706010221.37108.qmail@web30605.mail.mud.yahoo.com>
Message-ID: <42CB7E39.9010200@well.com>

Hello,

Readers here may be interested in the ongoing very active and informed 
discussion of microformats on the Geowanking list

See archives at : http://lists.burri.to/pipermail/geowanking/

Tim White wrote:
> Hello,
> 
> I'm Tim White, a self-taught web developer working at a large
> publishing company in Farmington Hills, MI. Since surfing the web and
> stumbling across sites like WASP and then reading Zeldman's book, I've
> become more and more intrigued with the idea of standards and semantic
> coding.
> 
> I'm not quite sure where microformats fit in, but I'm interested to see
> where they lead -- and they just may help with a problem I have. I have
> a 1 month old daughter, so I haven't had much time to read up on
> everything yet.
> 
> I see that there are a couple of other Michigan microformaters in the
> crowd; perhaps our own small meet-up would be in order some day.
> 
> Tim
> www.tjameswhite.com/blog
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail 
> Stay connected, organized, and protected. Take the tour: 
> http://tour.mail.yahoo.com/mailtour.html 
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 
> 
From yoheiy at gmail.com  Wed Jul  6 05:09:39 2005
From: yoheiy at gmail.com (YAMAMOTO Yohei)
Date: Wed Jul  6 05:00:25 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <b10c6934050706050922361daf@mail.gmail.com>

Hi, all

2005/7/2, Ryan King <ryan@technorati.com>:
> We've had a lot of people join the list recently and most people
> probably don't know who else is subscribed to the list (there's 51
> total). So, some personal introductions are in order...

I'm YAMAMOTO Yohei (Family Given), a Japanese software engineer.
I am interested in Web related technologies.
So here is my current view of Web 2.0 which includes "microformats" :-)
  http://www.flickr.com/photos/60043209@N00/18508797/

I have a blog at http://yohei-y.blogspot.com/ (Sorry it's in Japanese).

--
YAMAMOTO Yohei
From hober0 at gmail.com  Wed Jul  6 15:30:30 2005
From: hober0 at gmail.com (Edward O'Connor)
Date: Wed Jul  6 15:51:44 2005
Subject: [microformats-discuss] Re: personal intro
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <m2irznr2ih.fsf@roisin.local>

I'm Edward O'Connor, currently working at EVDB in San Diego. I'm
something of a multi-purpose coder at work; have done some of the
web-side coding and some of the backend work. In my spare time I hack
mainly elisp. More about me (including links to my blog, del.icio.us,
flickr, etc.) here: <http://edward.oconnor.cx/>


Ted

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

From lucas.gonze at gmail.com  Wed Jul  6 18:16:42 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Wed Jul  6 18:07:21 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <b10c6934050706050922361daf@mail.gmail.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
	<b10c6934050706050922361daf@mail.gmail.com>
Message-ID: <ab069aa005070618166ef20f52@mail.gmail.com>

I'm Lucas Gonze, a web developer based in Honolulu.  I am best known
for webjay.org, a playlist community.  My main interest is open media
on the web, and I was drawn into things related to microformats as a
result of work on the XSPF playlist format.

I am also the architect of the aforementioned reblg.com Marc Canter project.  :)

- Lucas
From kevinmarks at mac.com  Wed Jul  6 17:49:17 2005
From: kevinmarks at mac.com (Kevin Marks)
Date: Wed Jul  6 19:00:29 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat BOF session
	at Where 2.0
In-Reply-To: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>
Message-ID: <db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>


On Jul 6, 2005, at 1:57 AM, Edward Mac Gillavry wrote:

> Hmmm... Let's get us back on track, shall we? This list is about 
> GEOwanking. But maybe being a cartographer I don't get the 
> importance/relevancy of the discussion so far. I agree, there is a 
> chance for yet another representation of location to emerge with the 
> geo microformat. Therefore I'm happy this thread receives some 
> attention as I think there are many ways in which we can contribute to 
> a geo microformat.
>
> However, before going into the implementation, e.g. 
> XML/RDF/SomethingElse, what have we come up with so far in our 
> previous discussions? Should the geo microformat focus on point 
> locations only? Because that's what seems to be the main approach: how 
> to structure an address and translate that into a point location? 
> However, I seem to remember people on this list have realised it's 
> useful to represent area features as well. While we're at it: 
> polylines? Should we give an indication of accuracy, spatial 
> precision?

A key use case for a geo microformat is for people to be able to refer 
to a place from a web page. Currently, people do this predominantly in 
two ways:

  * referring to a human-readable address ('San Francisco', '665 3rd 
Street, SF, 94107', '3rd and Townsend', 'by the ballpark'
  * linking to an existing map service with a proprietary URL (mapquest, 
google, yahoo)

These are useful in human terms, but they don't really map onto a point 
location, as they are referring to a human-scale area.
Bare latitude/longitude is insufficient to present a cartographic 
representation to a user, as there is no way to know what scale to 
display that map at.

What would be useful, in my view, would be to translate the above into 
a latitude, longitude, and radius of interest. These can be translated 
back into different map display systems.

Translating the human-readable names is a tricky problem, but one that 
mapping services already tackle with variable success, so  having a way 
of presenting the human-readable and lat/long/radius data as 
alternatives is valuable.

From carl.beeth at gmail.com  Thu Jul  7 04:43:03 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Thu Jul  7 04:33:37 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat BOF
	session at Where 2.0
In-Reply-To: <db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>
	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>
Message-ID: <e8ca2e1105070704437cced4a2@mail.gmail.com>

On 7/7/05, Kevin Marks <kevinmarks@mac.com> wrote:

> What would be useful, in my view, would be to translate the above into
> a latitude, longitude, and radius of interest. These can be translated
> back into different map display systems.

IMO radius is an not an important piece of information, or rather
radius is assuming a particular use for the data that may or may not
be the way people use it. Even if the user uses it to map an area in
what way do we as authors know what would be an appropriate scale. It
will be very different on a PDA or a big screen.
Most applications will pick their own appropriate scale, for example
if you are to get driving directions the appropriate map scale may be
whatever fits both you start and end points.

Carl
From bud at thecommunityengine.com  Thu Jul  7 05:18:15 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul  7 05:08:48 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat BOF
	session at Where 2.0
In-Reply-To: <e8ca2e1105070704437cced4a2@mail.gmail.com>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>
	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>
	<e8ca2e1105070704437cced4a2@mail.gmail.com>
Message-ID: <E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>

On Jul 7, 2005, at 7:43, Carl Beeth wrote:

> On 7/7/05, Kevin Marks <kevinmarks@mac.com> wrote:
>
>
>> What would be useful, in my view, would be to translate the above  
>> into
>> a latitude, longitude, and radius of interest. These can be  
>> translated
>> back into different map display systems.
>>
>
> IMO radius is an not an important piece of information, or rather
> radius is assuming a particular use for the data that may or may not
> be the way people use it. Even if the user uses it to map an area in
> what way do we as authors know what would be an appropriate scale. It
> will be very different on a PDA or a big screen.
> Most applications will pick their own appropriate scale, for example
> if you are to get driving directions the appropriate map scale may be
> whatever fits both you start and end points.
>
> Carl

One thought I have had in all of this is the remarkable precision we  
are asking for from users.  I could not give you latitude and  
longitude.  Radius would be interesting.  Is that in miles?

It seems there are at least two concerns here, and I am not sure what  
the microformat is trying to address:

1.  Giving people a systematic way to express their location.

2.  Collecting precise coordinate data (address or longitudinal).

If microformats are going to be user friendly, I would wonder if you  
would not want to focus on 1.

The google maps search interface as one of the referents for the  
location microformat.  Should we study in closer detail how that  
interface works?  I expect that this is the level of detail most  
people are going to be able to give on their location.

Bud

From ryan at technorati.com  Thu Jul  7 07:38:57 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul  7 07:29:31 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat BOF
	session at Where 2.0
In-Reply-To: <E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>
	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>
	<e8ca2e1105070704437cced4a2@mail.gmail.com>
	<E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>
Message-ID: <CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>

On Jul 7, 2005, at 5:18 AM, Bud Gibson wrote:
> One thought I have had in all of this is the remarkable precision  
> we are asking for from users.  I could not give you latitude and  
> longitude.  Radius would be interesting.  Is that in miles?
>
> It seems there are at least two concerns here, and I am not sure  
> what the microformat is trying to address:
>
> 1.  Giving people a systematic way to express their location.
>
> 2.  Collecting precise coordinate data (address or longitudinal).
>
> If microformats are going to be user friendly, I would wonder if  
> you would not want to focus on 1.

I think we are. However, its seems that we need to make accomodations  
for #2, as well as #1.


> The google maps search interface as one of the referents for the  
> location microformat.  Should we study in closer detail how that  
> interface works?

I'm not sure what you're talking about. Are you talking about the  
search interface? or the new Google maps api?

> I expect that this is the level of detail most people are going to  
> be able to give on their location.

Yes. That is the majority case, but the  minority case is large  
enough to be supported.

-ryan


From bud at thecommunityengine.com  Thu Jul  7 08:59:23 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul  7 08:49:54 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat BOF
	session at Where 2.0
In-Reply-To: <CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>
	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>
	<e8ca2e1105070704437cced4a2@mail.gmail.com>
	<E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>
	<CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>
Message-ID: <613C8FD6-20F2-45B6-B12D-0FE515C3E564@thecommunityengine.com>

On Jul 7, 2005, at 10:38, Ryan King wrote:

> I think we are. However, its seems that we need to make  
> accomodations for #2, as well as #1.

Let me challenge this.  My main observation is that there is a  
difference with a tension.  #1 is providing a systematic interface  
for humans and #2 is providing precise geo coordinates (street  
addresses or "geometric" per the Tantek sense).  Would we be better  
off with a divide and conquer strategy?  That's the question I mean  
to raise.

>
>> The google maps search interface as one of the referents for the  
>> location microformat.  Should we study in closer detail how that  
>> interface works?
>>
>
> I'm not sure what you're talking about. Are you talking about the  
> search interface? or the new Google maps api?

I'm talking about the search interface.  I think there is a lot to  
learn there because that is what lots and lots of real users use.   
It's how these people express location, or at least one semi- 
systematic way here in the US.

Given this last observation, why couldn't I have a microformat for  
expressing location that is like this:

1.  A tagging method based on the reltag standard, perhaps with an  
extra "geo" class attribute value or some other way of indicating we  
are talking about tagging a location.
2.  Tag values that are equivalent to search terms that produce  
unique results in any one of a set of commercial search services.

Let's call this geotag, or if that name is taken, bdgeotag (brain  
dead geotag).

That way, bumpkisses like me who are generally aware of city and  
sometime street (almost always place name) would have a chance of  
producing data that could go in there.  We could check whether we had  
a legal value by using a search service.  You could even make a  
geotag creator that had people do searches and once they were  
satisfied slide the search term as a valid tag value into the geotag.

Some might object to the idea of using commercial search services.   
Well, why not some interface to the Tiger database

http://www.census.gov/geo/www/tiger/

Like reltag, geotag could apply to the whole blog post or some  
portion thereof as delineated by enclosing elements.
>
>
>> I expect that this is the level of detail most people are going to  
>> be able to give on their location.
>>
>
> Yes. That is the majority case, but the  minority case is large  
> enough to be supported.
>
> -ryan
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050707/fb01a81d/attachment-0001.htm
From ryan at technorati.com  Thu Jul  7 11:26:02 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul  7 11:16:33 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat BOF
	session at Where 2.0
In-Reply-To: <613C8FD6-20F2-45B6-B12D-0FE515C3E564@thecommunityengine.com>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>
	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>
	<e8ca2e1105070704437cced4a2@mail.gmail.com>
	<E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>
	<CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>
	<613C8FD6-20F2-45B6-B12D-0FE515C3E564@thecommunityengine.com>
Message-ID: <FEA23E97-F638-448D-AEA4-AF7D47AAFBF3@technorati.com>

On Jul 7, 2005, at 8:59 AM, Bud Gibson wrote:
> On Jul 7, 2005, at 10:38, Ryan King wrote:
>
>> I think we are. However, its seems that we need to make  
>> accomodations for #2, as well as #1.
>
> Let me challenge this.  My main observation is that there is a  
> difference with a tension.  #1 is providing a systematic interface  
> for humans and #2 is providing precise geo coordinates (street  
> addresses or "geometric" per the Tantek sense).  Would we be better  
> off with a divide and conquer strategy?  That's the question I mean  
> to raise.

I don't think we need to divide this effort at this point, for  
several reasons:
1. Most people who are interested in one, will be interested in both
2. They have implications for each other.
3. Implementors will want to implement both of them.
4. They're trying to solve the same problem.

Of course, I may be wrong..

>>> The google maps search interface as one of the referents for the  
>>> location microformat.  Should we study in closer detail how that  
>>> interface works?
>>
>> I'm not sure what you're talking about. Are you talking about the  
>> search interface? or the new Google maps api?
>
> I'm talking about the search interface.  I think there is a lot to  
> learn there because that is what lots and lots of real users use.   
> It's how these people express location, or at least one semi- 
> systematic way here in the US.
>
> Given this last observation, why couldn't I have a microformat for  
> expressing location that is like this:
>
> 1.  A tagging method based on the reltag standard, perhaps with an  
> extra "geo" class attribute value or some other way of indicating  
> we are talking about tagging a location.
> 2.  Tag values that are equivalent to search terms that produce  
> unique results in any one of a set of commercial search services.

This idea has come up several times before and was actually my  
original idea (in f2f conversations with Tantek and Kevin). It has  
also come up as  a current practice on http://microformats.org/wiki/ 
location-formats and come up during the BOF.

Here are the outstanding issues with it:
1. Is there a common url scheme we can use?
2. Are the urls parseable in a reasonable manner?


> Let's call this geotag, or if that name is taken, bdgeotag (brain  
> dead geotag).

Geotag is being used by the flickr geotaggers and possibly by others.

> That way, bumpkisses like me who are generally aware of city and  
> sometime street (almost always place name) would have a chance of  
> producing data that could go in there.  We could check whether we  
> had a legal value by using a search service.  You could even make a  
> geotag creator that had people do searches and once they were  
> satisfied slide the search term as a valid tag value into the geotag.

Yes, I very much like the idea. I think one of the reasons that rel- 
tag has done better than meta keywords is something I call "one-click  
verifiability." RelTag does well by being visible, but it also does  
well because you can click on the link and see what it is (in a  
loose, general sense) that the person means by that tag. Also, the  
author can verify that they've done things correctly (otherwise 404  
errors and such).


> Some might object to the idea of using commercial search services.   
> Well, why not some interface to the Tiger database
>
> http://www.census.gov/geo/www/tiger/

vendor neutrality++

However, it would be great if someone could still link to google or  
yahoo or webmapper or mapquest. To do this, though, they'd all need  
to support some common url scheme (or someone would have to write a  
proxy).

With Tiger, I don't think there's any way we can link to a map page.  
Anyone know otherwise?


> Like reltag, geotag could apply to the whole blog post or some  
> portion thereof as delineated by enclosing elements.

Right.

>>> I expect that this is the level of detail most people are going  
>>> to be able to give on their location.
>>
>> Yes. That is the majority case, but the  minority case is large  
>> enough to be supported.


-ryan
From dougal at gunters.org  Thu Jul  7 12:35:29 2005
From: dougal at gunters.org (Dougal Campbell)
Date: Thu Jul  7 12:26:51 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat
	BOF	session at Where 2.0
In-Reply-To: <FEA23E97-F638-448D-AEA4-AF7D47AAFBF3@technorati.com>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>	<e8ca2e1105070704437cced4a2@mail.gmail.com>	<E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>	<CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>	<613C8FD6-20F2-45B6-B12D-0FE515C3E564@thecommunityengine.com>
	<FEA23E97-F638-448D-AEA4-AF7D47AAFBF3@technorati.com>
Message-ID: <42CD8401.8000402@gunters.org>

Ryan King wrote:

> I don't think we need to divide this effort at this point, for  several 
> reasons:
> 1. Most people who are interested in one, will be interested in both
> 2. They have implications for each other.
> 3. Implementors will want to implement both of them.
> 4. They're trying to solve the same problem.

I think you're right on all counts (though some implementors will be 
more interested in one aspect or the other). Depending on your point of 
view for your particular application of geolocation data, a street 
address might be considered metadata for lat/lon, or vice versa.

I think the best format is going to allow for both types of addressing, 
but only require one. Just off the top of my head, a pseudo outline 
might look something like:

   <location>
     <geo>
       <lat />
       <lon />
     </geo>
     <address>
       ...something using hCard, maybe?...
     </address>
   </location>

With a requirement that either geo or address (or both) must be present. 
Implementations that only utilize geo coordinates can simply ignore 
locations that don't include it (and vice versa). Or, they can do their 
own geocoding translations.

-- 
Dougal Campbell <dougal@gunters.org>
http://dougal.gunters.org/

From ryan at technorati.com  Thu Jul  7 13:50:23 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul  7 13:40:53 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat
	BOF	session at Where 2.0
In-Reply-To: <42CD8401.8000402@gunters.org>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>	<e8ca2e1105070704437cced4a2@mail.gmail.com>	<E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>	<CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>	<613C8FD6-20F2-45B6-B12D-0FE515C3E564@thecommunityengine.com>
	<FEA23E97-F638-448D-AEA4-AF7D47AAFBF3@technorati.com>
	<42CD8401.8000402@gunters.org>
Message-ID: <00408A03-36CD-465B-B4BD-6EA4DA474799@technorati.com>

On Jul 7, 2005, at 12:35 PM, Dougal Campbell wrote:
> Ryan King wrote:
>> I don't think we need to divide this effort at this point, for   
>> several reasons:
>> 1. Most people who are interested in one, will be interested in both
>> 2. They have implications for each other.
>> 3. Implementors will want to implement both of them.
>> 4. They're trying to solve the same problem.
>
> I think you're right on all counts (though some implementors will  
> be more interested in one aspect or the other). Depending on your  
> point of view for your particular application of geolocation data,  
> a street address might be considered metadata for lat/lon, or vice  
> versa.
>
> I think the best format is going to allow for both types of  
> addressing, but only require one. Just off the top of my head, a  
> pseudo outline might look something like:
>
>   <location>
>     <geo>
>       <lat />
>       <lon />

There's actually a geo field in hCard, though outside the adr structure.

>     </geo>
>     <address>
>       ...something using hCard, maybe?...

or the adr substructure of hCard

>     </address>
>   </location>
>
> With a requirement that either geo or address (or both) must be  
> present. Implementations that only utilize geo coordinates can  
> simply ignore locations that don't include it (and vice versa). Or,  
> they can do their own geocoding translations.

This seems reasonable.

-ryan

From bud at thecommunityengine.com  Thu Jul  7 14:26:19 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul  7 14:16:46 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat
	BOF	session at Where 2.0
In-Reply-To: <42CD8401.8000402@gunters.org>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>	<e8ca2e1105070704437cced4a2@mail.gmail.com>	<E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>	<CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>	<613C8FD6-20F2-45B6-B12D-0FE515C3E564@thecommunityengine.com>
	<FEA23E97-F638-448D-AEA4-AF7D47AAFBF3@technorati.com>
	<42CD8401.8000402@gunters.org>
Message-ID: <D4B19A92-444A-4225-B1DD-F2A9885D2821@thecommunityengine.com>

> Ryan King wrote:
>
>
>> I don't think we need to divide this effort at this point, for   
>> several reasons:
>> 1. Most people who are interested in one, will be interested in both
>> 2. They have implications for each other.
>> 3. Implementors will want to implement both of them.
>> 4. They're trying to solve the same problem.
>>
>
> I think you're right on all counts (though some implementors will  
> be more interested in one aspect or the other). Depending on your  
> point of view for your particular application of geolocation data,  
> a street address might be considered metadata for lat/lon, or vice  
> versa.

My main point in raising this was actually to try to push discussion  
forward on this list, particularly in a direction that real people  
could use.  While I appreciate (and in some sense even like) the idea  
of geographic precision and the data it would bring, I have to ask  
myself the real question of how achievable it is.   Also, you get an  
issue of coverage.

Whether the effort needs to be split or not is a question I'll leave  
to the group.  Personally, I could see splitting it because I believe  
the precise place location coordinates are most likely to come from  
some source other than the users as is indicated by this tell tale  
interchange between someone named "bewest" , Ryan, and myself on IRC  
last night:

> budGibson
> Who's going to fill in all of this information?  I imagine  
> geowankers all out there with their GPSs, but what about the rest  
> of us.
> bewest
> well it's not necessary for humans to fill out lat long computers  
> can do it if it's a part of the standard
> kingryan
> right, bewest, but microformats are for humans first
> budGibson
> right on ryan baby

Ryan, let me hit a few of your points:

> This idea has come up several times before and was actually my  
> original idea (in f2f conversations with Tantek and Kevin). It has  
> also come up as  a current practice on http://microformats.org/wiki/ 
> location-formats and come up during the BOF.

I remember raising it during the BOF as something akin to what I now  
describe as bdgeotag (brain dead geotagging).  There's a difference  
between a URL representation of a place and a tag that represents a  
place.

bdgeotag is meant to allow people latitude in describing place names  
while tying them to having their tag actually resolve to something.   
My point is that the tag only need to resolve to something via some  
transformation.  The ultra lazy method of achieving this  
transformation is to say its gotta work in a geo search service.

Like any tagging operation, tags will have ambiguity.  Let's say I  
have two tags (assume URL encoding as required by reltag):

1.  701 Tappan Street, Ann Arbor, Michigan
2.  University of Michigan Business School, Ann Arbor, Michigan

They appear different but are, in fact, equivalent.  Well, this is  
the standard tagging problem.  Geniuses like Kevin Marks can resolve  
it :).

The URL scheme is exactly like reltag.  Maybe we add a class  
attribute so you can indicate the search service where this works.

As for the tiger database, there is a map interface, and that map  
interface is at:

http://brainoff.com/worldkit/mapproxy/

among other places.

To some extent, I am just shaking the tree here.

Bud
On Jul 7, 2005, at 15:35, Dougal Campbell wrote:

>
> I think the best format is going to allow for both types of  
> addressing, but only require one. Just off the top of my head, a  
> pseudo outline might look something like:
>
>   <location>
>     <geo>
>       <lat />
>       <lon />
>     </geo>
>     <address>
>       ...something using hCard, maybe?...
>     </address>
>   </location>
>
> With a requirement that either geo or address (or both) must be  
> present. Implementations that only utilize geo coordinates can  
> simply ignore locations that don't include it (and vice versa). Or,  
> they can do their own geocoding translations.
>
> -- 
> Dougal Campbell <dougal@gunters.org>
> http://dougal.gunters.org/
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050707/d12abcf5/attachment.htm
From ryan at technorati.com  Thu Jul  7 15:09:06 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul  7 14:59:43 2005
Subject: [microformats-discuss] Re: [Geowanking] geo microformat
	BOF	session at Where 2.0
In-Reply-To: <D4B19A92-444A-4225-B1DD-F2A9885D2821@thecommunityengine.com>
References: <BAY104-F31E6633055D5852344164AD7D90@phx.gbl>	<db02e76f5c6fb5fba9b46b1d0d4f74c4@mac.com>	<e8ca2e1105070704437cced4a2@mail.gmail.com>	<E15D6051-FD41-4766-A7A7-DE855D2D3647@thecommunityengine.com>	<CBBBDC93-BFA4-4426-9E16-C6D800C68DAE@technorati.com>	<613C8FD6-20F2-45B6-B12D-0FE515C3E564@thecommunityengine.com>
	<FEA23E97-F638-448D-AEA4-AF7D47AAFBF3@technorati.com>
	<42CD8401.8000402@gunters.org>
	<D4B19A92-444A-4225-B1DD-F2A9885D2821@thecommunityengine.com>
Message-ID: <506C8AA3-15A3-4089-B661-6425F4958D37@technorati.com>

On Jul 7, 2005, at 2:26 PM, Bud Gibson wrote:
> My main point in raising this was actually to try to push  
> discussion forward on this list, particularly in a direction that  
> real people could use.  While I appreciate (and in some sense even  
> like) the idea of geographic precision and the data it would bring,  
> I have to ask myself the real question of how achievable it is.

This is why our solution is 'address primary and geo secondary.' Geo  
is not achievable for uses (one of the reasons why geourl has a good  
deal of inaccurate data), but should be accommodated.

> Also, you get an issue of coverage.

?

> Whether the effort needs to be split or not is a question I'll  
> leave to the group.  Personally, I could see splitting it because I  
> believe the precise place location coordinates are most likely to  
> come from some source other than the users as is indicated by this  
> tell tale interchange between someone named "bewest" , Ryan, and  
> myself on IRC last night:
>
>> budGibson
>> Who's going to fill in all of this information?  I imagine  
>> geowankers all out there with their GPSs, but what about the rest  
>> of us.
>> bewest
>> well it's not necessary for humans to fill out lat long computers  
>> can do it if it's a part of the standard
>> kingryan
>> right, bewest, but microformats are for humans first
>> budGibson
>> right on ryan baby

Just a note of clarification- I think bewest was arguing for geo-only  
and I was trying to point out that street address is just as important.

> Ryan, let me hit a few of your points:
>
>> This idea has come up several times before and was actually my  
>> original idea (in f2f conversations with Tantek and Kevin). It has  
>> also come up as  a current practice on http://microformats.org/ 
>> wiki/location-formats and come up during the BOF.
>
> I remember raising it during the BOF as something akin to what I  
> now describe as bdgeotag (brain dead geotagging).  There's a  
> difference between a URL representation of a place and a tag that  
> represents a place.
>
> bdgeotag is meant to allow people latitude in describing place  
> names while tying them to having their tag actually resolve to  
> something.  My point is that the tag only need to resolve to  
> something via some transformation.  The ultra lazy method of  
> achieving this transformation is to say its gotta work in a geo  
> search service.

I was talking about the "ultra lazy method." You're right these two  
schemes are different and were getting confused here. (maybe "use  
lazy methods when possible should be added to the microformats  
principles" :-))

So we really have to proposals here:

1. tagging using named places
2. tagging with address info

They could certainly be used together, but would lead to different  
applications.

> <snip>
> To some extent, I am just shaking the tree here.

Shake away. Hopefully someone else will speak up.
-ryan
From ryan at technorati.com  Thu Jul  7 18:07:56 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul  7 17:58:25 2005
Subject: [microformats-discuss] test
Message-ID: <FB093E34-82BD-4A97-9511-EC50E321510D@technorati.com>

test, please ignore.

-ryan
From bud at thecommunityengine.com  Thu Jul  7 22:14:44 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul  7 22:05:05 2005
Subject: [microformats-discuss] xFolk revision on the wiki
Message-ID: <05C37F51-97ED-44BD-991C-54E5B2833FAB@thecommunityengine.com>

Hi:

In case you did not know, xFolk is a simple and open format for  
publishing tagged collections of bookmarks that enables many  
potential new services.

With Tantek's encouragement, I decided to move the xFolk, an  
independently developed microformat, to microformats.org's wiki.  It  
seemed it would benefit from becoming part of the overall community.

If you are familiar with previous iterations of xFolk, you should  
still check out the wiki version, as there have been some minor  
changes based on implementation experience.  The format is pretty  
simple, and I expect any future revisions to the format itself to be  
small, based again largely on implementation experience.

There could be a lot of changes to the examples, and there may be  
many use cases that need to be elaborated.  I look forward to working  
with you.

Bud


From bud at thecommunityengine.com  Fri Jul  8 06:52:02 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul  8 06:42:24 2005
Subject: [microformats-discuss] xFolk revision on the wiki
In-Reply-To: <05C37F51-97ED-44BD-991C-54E5B2833FAB@thecommunityengine.com>
References: <05C37F51-97ED-44BD-991C-54E5B2833FAB@thecommunityengine.com>
Message-ID: <B2A8BAD9-B219-4820-BCF2-450AE9D06780@thecommunityengine.com>

BTW, the link to xFolk on the wiki is:

http://microformats.org/wiki/xfolk

Bud
On Jul 8, 2005, at 1:14, Bud Gibson wrote:

> Hi:
>
> In case you did not know, xFolk is a simple and open format for  
> publishing tagged collections of bookmarks that enables many  
> potential new services.
>
> With Tantek's encouragement, I decided to move the xFolk, an  
> independently developed microformat, to microformats.org's wiki.   
> It seemed it would benefit from becoming part of the overall  
> community.
>
> If you are familiar with previous iterations of xFolk, you should  
> still check out the wiki version, as there have been some minor  
> changes based on implementation experience.  The format is pretty  
> simple, and I expect any future revisions to the format itself to  
> be small, based again largely on implementation experience.
>
> There could be a lot of changes to the examples, and there may be  
> many use cases that need to be elaborated.  I look forward to  
> working with you.
>
> Bud
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From bud at thecommunityengine.com  Fri Jul  8 07:27:51 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul  8 07:18:08 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
Message-ID: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>

Dear all:

When I was visiting Technorati 10 days ago, Ryan King was trying to  
make the point to Chris Messina that microformats provide a sort of  
API for web applications on the server and client side.  Neat  
insight, but on reflection,  not entirely true.  Microformats provide  
an xhtml format for data structures that can be passed back and forth  
through API calls.  An API  needs to also specify the available  
objects, their methods, input, and return values (substitute your  
favorite programming pardigm terms as needed).

As we start to do things like use microformats with ajax or to carry  
the return values from what amounts to a server side function call,  
we might want to thing about more explicitly specifying what lies at  
the other end of a URL that returns microformatted data.  Carl Beeth  
recently raised this exact point (it might have been in a private  
email, sorry) from a very pragmatic perspective when he was wrestling  
with hCard:

> I think we need to identify the link so as to not put to much burden
> on the user agent. ex:
> you decide to grab a minimal hcard from a web page. How does the
> browser know which link inside the hcard contains the full card, for
> that matter how does the browser know that there is a link to a
> complete hcard. In essence we would need to program the agent to fetch
> and scan all the urls within the hcard.
> So identifying the link is much easier on the user-agent/crawler. Of
> course, identifying the link adds some work for the author but less
> than if he needed to duplicate all the information.

Basically, Carl is proposing something like:

<a href="http://thecommunityengine.com/webcites"  
class="xfolk">returns xFolk entries</a>

to specify that the URL returns xFolk entries to extend his point  
beyond the purely hCard specific.  I was sceptical of this idea at  
first, but now think it makes a lot of sense and might actually be a  
good convention to adopt as either a meta or basic microformat (can't  
quite decide which, maybe a new category meta-basic).

Any thoughts?  I may just check with Carl and see if he wants to add  
this as a more formalized microformats proposal.  I bet a lot of  
people are experiencing this problem.  I can certainly see it in a  
project I'm about to start.

Bud
From tantek at cs.stanford.edu  Fri Jul  8 07:49:56 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Jul  8 07:40:20 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>
Message-ID: <BEF3E079.5C8A0%tantek@cs.stanford.edu>

On 7/8/05 7:27 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

>> I think we need to identify the link so as to not put to much burden
>> on the user agent. ex:
>> you decide to grab a minimal hcard from a web page. How does the
>> browser know which link inside the hcard contains the full card, for
>> that matter how does the browser know that there is a link to a
>> complete hcard. In essence we would need to program the agent to fetch
>> and scan all the urls within the hcard.
>> So identifying the link is much easier on the user-agent/crawler. Of
>> course, identifying the link adds some work for the author but less
>> than if he needed to duplicate all the information.
> 
> Basically, Carl is proposing something like:
> 
> <a href="http://thecommunityengine.com/webcites"
> class="xfolk">returns xFolk entries</a>
> 
> to specify that the URL returns xFolk entries to extend his point
> beyond the purely hCard specific.  I was sceptical of this idea at
> first, but now think it makes a lot of sense and might actually be a
> good convention to adopt as either a meta or basic microformat (can't
> quite decide which, maybe a new category meta-basic).
> 
> Any thoughts?  I may just check with Carl and see if he wants to add
> this as a more formalized microformats proposal.  I bet a lot of
> people are experiencing this problem.  I can certainly see it in a
> project I'm about to start.

I'm not convinced.

This feels like one of those "theoretically this could be a problem"
problems.

Basically, I want to avoid designing any kind of feature like this without
someone actually *building* a solution and *actually* having the problem.

There are *tons* of such "theoretical" problems, that, when you actually
develop build your solution, turn out to not be problems at all.

For example, this exact fear of "theoretically this could be a problem"
reasoning is why people rush off and over-use namespaces when 99% of the
time they are completely unnecessary.

The problem with design by "theoretically this could be a problem" is that
it always prematurely complicates designs, formats, solutions, etc.  Or
worse, it causes you to worry for *years* about "theoretical" problems, and
never finish your solution until other folks in the market have passed you
by.

So in many ways, it is anti-design pattern.

It is against the microformats way.

I'd also say this might be a better discussion for the microformats-dev
list, but that would require that there be one or more specific
implementations that we would be able to try out and use to understand the
problem.

Carl, Bud, do you have an implementation that we can try out to actually see
the problem?

Thanks,

Tantek


From Joe at Germuska.com  Fri Jul  8 07:49:52 2005
From: Joe at Germuska.com (Joe Germuska)
Date: Fri Jul  8 07:54:00 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>
References: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>
Message-ID: <a06210207bef4428aacb8@[192.168.2.85]>

>Basically, Carl is proposing something like:
>
><a href="http://thecommunityengine.com/webcites" 
>class="xfolk">returns xFolk entries</a>
>
>to specify that the URL returns xFolk entries to extend his point 
>beyond the purely hCard specific.  I was sceptical of this idea at 
>first, but now think it makes a lot of sense and might actually be a 
>good convention to adopt as either a meta or basic microformat 
>(can't quite decide which, maybe a new category meta-basic).

I'm afraid that saying "check out XLink" will get a similar response 
to "doesn't RDF do those things?" but it's true that the spec 
considers this issue in great detail.

http://www.w3.org/TR/xlink/

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex
From bud at thecommunityengine.com  Fri Jul  8 08:45:03 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul  8 08:35:24 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <BEF3E079.5C8A0%tantek@cs.stanford.edu>
References: <BEF3E079.5C8A0%tantek@cs.stanford.edu>
Message-ID: <B48549C5-E5CB-4F58-8F11-59F2D86DB616@thecommunityengine.com>

On Jul 8, 2005, at 10:49, Tantek ?elik wrote:

> Carl, Bud, do you have an implementation that we can try out to  
> actually see
> the problem?
>
> Thanks,
>
> Tantek

Tantek:

I don't think this is an anti-design pattern as Carl actually raised  
the point relative to a problem he was having.  So, I present that to  
you as the implementation issue.  There is also an implementation  
issue oddly enough with reblg that sends microformats wherever you  
want.  If you want to reblg a link, how does reblg know what is at  
the end of the link prior to fetching it?

I understand your concern about getting lost in theoretical issues.   
It seems like the likelihood of that happening with microformats is  
very slight.  Basically, if you propose a microformat, and it falls  
flat, then that's over.  You'll also note that the solution I propose  
is very light weight.  It's meant to be a try it and fail fast idea.   
I'm not sure what the fuss about "anti-design" patterns is in light  
of these facts.  Concerns about anti-design are really concerns about  
the cost of design mistakes, and those seem low here.

At the end, we may just be harboring different conceptions of what a  
microformat is.  I tend to think of them as standardized but  
frequently still experimental approaches to solving existing and  
emerging problems.  You are not so keen on the emerging problems idea.

Thanks about the pointer to microformats-dev, a list that did not  
seem to exist a week ago.

Bud
From Joe at Germuska.com  Fri Jul  8 09:18:24 2005
From: Joe at Germuska.com (Joe Germuska)
Date: Fri Jul  8 09:08:55 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <F82EB34B-45F9-4592-BE23-EA2A5FA49803@thecommunityengine.com>
References: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>
	<a06210207bef4428aacb8@[192.168.2.85]>
	<F82EB34B-45F9-4592-BE23-EA2A5FA49803@thecommunityengine.com>
Message-ID: <a0621020bbef453cbb826@[192.168.2.85]>

At 11:48 AM -0400 7/8/05, Bud Gibson wrote:
>Joe:
>
>Not a bad suggestion.  However, I have never seen xlink really take 
>off.  Is there a part of that spec that you find most relevant to 
>this issue?

Well, Tantek's followup kind of makes the point, about heavy 
theoretical issues and the sometimes corresponding lack of adoption, 
I think!  You can tell from reading the spec that it's pretty much 
the anti-microformat.

But in short, the spec defines a bunch of XML attributes which can be 
used; specifically, the "class" attribute from the earlier example 
would be rendered as "xlink:role", with a URI as a value.

SVG uses XLink specifically.  But then, SVG hasn't really taken off 
either.  According to this page, Mozilla has some support for XLink 
syntax: http://www.w3.org/XML/2000/09/LinkingImplementations.html
(can anyone point to a page which demonstrates this?)  But at the end 
of the day,  I think the fact that the really sophisticated behavior 
demonstrated in the spec's examples requires DTD hacking is pretty 
much a death sentence.

Still, it seems like if all you want to do is add an attribute with 
this purpose to a link, maybe you don't have to reinvent the wheel?

Joe


>On Jul 8, 2005, at 10:49, Joe Germuska wrote:
>
>>>Basically, Carl is proposing something like:
>>>
>>><a href="http://thecommunityengine.com/webcites" 
>>>class="xfolk">returns xFolk entries</a>
>>>
>>>to specify that the URL returns xFolk entries to extend his point 
>>>beyond the purely hCard specific.  I was sceptical of this idea at 
>>>first, but now think it makes a lot of sense and might actually be 
>>>a good convention to adopt as either a meta or basic microformat 
>>>(can't quite decide which, maybe a new category meta-basic).
>>>
>>
>>I'm afraid that saying "check out XLink" will get a similar 
>>response to "doesn't RDF do those things?" but it's true that the 
>>spec considers this issue in great detail.
>>
>>http://www.w3.org/TR/xlink/
>>
>>Joe
>>
>>--
>>Joe Germuska            Joe@Germuska.com  http://blog.germuska.com 
>>"Narrow minds are weapons made for mass destruction"  -The Ex


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex
From tantek at cs.stanford.edu  Fri Jul  8 09:25:34 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Jul  8 09:15:50 2005
Subject: [microformats-discuss] Extending the embedded information
In-Reply-To: <e8ca2e11050701150345c53a2a@mail.gmail.com>
Message-ID: <BEF3F6A4.5C8AF%tantek@cs.stanford.edu>

On 7/1/05 3:03 PM, "Carl Beeth" <carl.beeth@gmail.com> wrote:

> I'm very excited about the microformats, seems I have been looking for
> something like this for ages. I Even found a old mail from 98 in the
> w3c html discussion list where we talk along those lines.
> <http://lists.w3.org/Archives/Public/www-html/1998Apr/0016.html>
> 
> Although I am all for embedding semantics in web pages, I'm missing
> one thing in the microformats: a way to semantically link to more
> complete version of the information when one does not want to pollute
> the page with all the information.
> 
> Here is an example from the site:
> <div class="vcard">
> <a class="url fn" href="http://tantek.com/">
> Tantek ?elik
> </a>
> <div class="org">Technorati</div>
> </div>
> 
> Now what if we wanted to have a to make more information available
> with out necessarily displaying it in the web page. maybe something
> like this:
> 
> <div class="vcard">
> <a class="url fn" href="http://tantek.com/">
> Tantek ?elik
> </a>
> <div class="org">Technorati</div>
> <a href="http://tantek.com/vcard.txt" class="vcardfile">vcard</a>
> </div>
> 
> The reason the class is important in on the link is that it allows the
> user agent/crawler to identify what is behind the link. a possible
> alternative would be to use type="text/vcard" but sadly I think they
> are supposed to be mimetypes but could not find the mime type for
> vcard

One of the key prerequisites for proposing a microformat is to first exhaust
the possibilities of using 1. a semantic XHTML element (or attribute), and
2. a semantic XHTML compound.

In otherwords, if you can do it with semantic XHTML, you don't need (and
shouldn't propose) a microformat.  Re-use before inventing.

In this case you are trying to develop a mechanism for linking to an
"alternate" version of something.

This is precisely what rel="alternate" (defined in HTML4) does.

As far as claiming what is at the other end of a link, that is not something
that you can reliably do from the source of a link.  Heck, the destination
of the link might not even exist.  This is fundamental to the web.  All you
can do is provide a hint.

Now you might say that rel="alternate" is insufficient because it doesn't
distinguish between an "abstract" and a "full" version, or, as others have
found in other contexts (e.g. localization/translation), the "original"
version, and a "copy" or a "translation".

That's a discussion worth having, as I think there is enough of a need there
to propose an elemental microformat to address one or more of those use
cases.  However, I do think that a single rel value might suffice for this,
rather than a class name for each microformat.  The latter seems like an
unnecessary explosion in the number of class names.

For now though, just use rel="alternate" to link to a page that contains
another version of your hCard, perhaps a more complete version.  That should
actually be sufficient for a user agent/crawler to go get the complete
version.

Thanks,

Tantek

From bud at thecommunityengine.com  Fri Jul  8 09:41:15 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul  8 09:31:33 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <a0621020bbef453cbb826@[192.168.2.85]>
References: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>
	<a06210207bef4428aacb8@[192.168.2.85]>
	<F82EB34B-45F9-4592-BE23-EA2A5FA49803@thecommunityengine.com>
	<a0621020bbef453cbb826@[192.168.2.85]>
Message-ID: <C2D524F7-9455-4E57-BCFA-5967BC3FC212@thecommunityengine.com>

So, this tells me that using the class attribute makes sense.  BTW,  
per my follow-up post to Tantek's, this does seem like a real issue  
to me.  But, since I am adopting a try-a-little, fail fast approach,  
I will likely just push this in some implementations and then say six  
months from now, "Hey we have a solution".

Bud
On Jul 8, 2005, at 12:18, Joe Germuska wrote:

> Still, it seems like if all you want to do is add an attribute with  
> this purpose to a link, maybe you don't have to reinvent the wheel?
>

From tantek at cs.stanford.edu  Fri Jul  8 09:47:36 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Jul  8 09:37:51 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <B48549C5-E5CB-4F58-8F11-59F2D86DB616@thecommunityengine.com>
Message-ID: <BEF3FBFD.5C8BC%tantek@cs.stanford.edu>

On 7/8/05 8:45 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> On Jul 8, 2005, at 10:49, Tantek ?elik wrote:
> 
>> Carl, Bud, do you have an implementation that we can try out to
>> actually see
>> the problem?
>> 
>> Thanks,
>> 
>> Tantek
> 
> Tantek:
> 
> I don't think this is an anti-design pattern as Carl actually raised
> the point relative to a problem he was having.

Agreed.  Carl's question was a good one (I just went back and found his
email and responded to his question in particular).

> So, I present that to
> you as the implementation issue.

It's an authoring issue, not an implementation issue.  If you go back and
read Carl's email, he is talking about a [theoretical] "user agent/crawler",
not one that he is writing.


> I understand your concern about getting lost in theoretical issues.
> It seems like the likelihood of that happening with microformats is
> very slight.

I do not share your optimism.  I think we have a very small core group of
microformats enthusiasts right now that understand the problem of falling
into the theoretical issues trap, and yet, 99% of the people in our industry
designing specs for W3C, or IETF, or whatever, are *constantly* falling into
this trap.  And the funny thing is, most folks *enjoy* it!  (I have to admit
this myself -- there is a certain "mental exercise" satisfaction that one
gains by analyzing and attempting to solve theoretical problems).

Thus the odds that any person new to microformats will fall into this trap
is *very* high.  Therefore we have no choice but to be eternally vigilant,
and shoot down theoretical issues as quickly as possible, or push back and
say, show me a real example/implementation that demonstrates the problem.


> Basically, if you propose a microformat, and it falls
> flat, then that's over.

Yes, that is definitely a very pragmatic aspect.  But I would say that the
goal of this community is to provide a place where you can propose the
precursors to a microformat, e.g. problem statements, and have folks give
you feedback that would increase the chance of your microformat proposal
*not* falling flat, and the only expense being sending one or two emails and
hopefully only waiting a day or two.  That doesn't seem that high a price to
pay.


> You'll also note that the solution I propose
> is very light weight.

It is by itself, but the pattern it implies is not light weight.  The
introduction of a new class for each microformat just to identify it seems
heavy weight.


> I'm not sure what the fuss about "anti-design" patterns is in light
> of these facts.  Concerns about anti-design are really concerns about
> the cost of design mistakes, and those seem low here.

Yes, the cost of design mistakes is definitely low here.  The "anti-design
pattern" is specifically the use of theoretical problems as a required
constraint.


> At the end, we may just be harboring different conceptions of what a
> microformat is.  I tend to think of them as standardized but
> frequently still experimental approaches to solving existing and
> emerging problems.

I think we agree more than disagree.

Microformats are somewhere between experimental and standardized.

> You are not so keen on the emerging problems idea.

Rather, for microformats, I prioritize "existing problems" above
"theoretical problems", and I think it is wise to do so.

Tantek

From ryan at technorati.com  Fri Jul  8 13:55:30 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul  8 13:45:51 2005
Subject: [microformats-discuss] Extending the embedded information
In-Reply-To: <BEF3F6A4.5C8AF%tantek@cs.stanford.edu>
References: <BEF3F6A4.5C8AF%tantek@cs.stanford.edu>
Message-ID: <D78803C3-198D-4786-832C-28007047FE94@technorati.com>

On Jul 8, 2005, at 9:25 AM, Tantek ?elik wrote:
> On 7/1/05 3:03 PM, "Carl Beeth" <carl.beeth@gmail.com> wrote:
>>
>> ...
>>
>> The reason the class is important in on the link is that it allows  
>> the
>> user agent/crawler to identify what is behind the link. a possible
>> alternative would be to use type="text/vcard" but sadly I think they
>> are supposed to be mimetypes but could not find the mime type for
>> vcard
>
> One of the key prerequisites for proposing a microformat is to  
> first exhaust
> the possibilities of using 1. a semantic XHTML element (or  
> attribute), and
> 2. a semantic XHTML compound.

See http://microformats.org/wiki/process for some more details on  
this sort of stuff.

Also, if that document doesn't help/needs improvment, feel free to  
complain. :-)

> In otherwords, if you can do it with semantic XHTML, you don't need  
> (and
> shouldn't propose) a microformat.  Re-use before inventing.
>
> In this case you are trying to develop a mechanism for linking to an
> "alternate" version of something.
>
> This is precisely what rel="alternate" (defined in HTML4) does.
>
> As far as claiming what is at the other end of a link, that is not  
> something
> that you can reliably do from the source of a link.  Heck, the  
> destination
> of the link might not even exist.  This is fundamental to the web.   
> All you
> can do is provide a hint.

To add to this... trying to assert something precise about something  
on the other end of a url is a form of tight coupling that doesn't  
work well on the Web in general. Its possible that the assertion will  
be wrong at some point in the future. Its better to just not try and  
make a strong assertion and only provide a hint.

> Now you might say that rel="alternate" is insufficient because it  
> doesn't
> distinguish between an "abstract" and a "full" version, or, as  
> others have
> found in other contexts (e.g. localization/translation), the  
> "original"
> version, and a "copy" or a "translation".
>
> That's a discussion worth having, as I think there is enough of a  
> need there
> to propose an elemental microformat to address one or more of those  
> use
> cases.  However, I do think that a single rel value might suffice  
> for this,
> rather than a class name for each microformat.  The latter seems  
> like an
> unnecessary explosion in the number of class names.

Two thoughts, elaboration again:
1. This kinda universal microformat ideas (things that will or could  
apply to all microformats) need to be approached very carefully.
2. Let's remember that we want to the most meaningful xhtml we can.  
In this case, rel is more meaningful than class. Generic elements and  
attributes like <div>, <span> and class= are somewhat of last resorts.

> For now though, just use rel="alternate" to link to a page that  
> contains
> another version of your hCard, perhaps a more complete version.   
> That should
> actually be sufficient for a user agent/crawler to go get the complete
> version.
From ryan at technorati.com  Fri Jul  8 14:03:42 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul  8 13:54:00 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <BEF3FBFD.5C8BC%tantek@cs.stanford.edu>
References: <BEF3FBFD.5C8BC%tantek@cs.stanford.edu>
Message-ID: <6D4E1AE9-2602-45AA-BAF1-F11AC5FEEBE5@technorati.com>

On Jul 8, 2005, at 9:47 AM, Tantek ?elik wrote:
> I do not share your optimism.  I think we have a very small core  
> group of
> microformats enthusiasts right now that understand the problem of  
> falling
> into the theoretical issues trap, and yet, 99% of the people in our  
> industry
> designing specs for W3C, or IETF, or whatever, are *constantly*  
> falling into
> this trap.  And the funny thing is, most folks *enjoy* it!  (I have  
> to admit
> this myself -- there is a certain "mental exercise" satisfaction  
> that one
> gains by analyzing and attempting to solve theoretical problems).
>
> Thus the odds that any person new to microformats will fall into  
> this trap
> is *very* high.  Therefore we have no choice but to be eternally  
> vigilant,
> and shoot down theoretical issues as quickly as possible, or push  
> back and
> say, show me a real example/implementation that demonstrates the  
> problem.

Every time I introduce microformats to someone new, I try to  
emphasize that microformats are a way of thinking about the web and  
xhtml. Part of the nature of microformats and what makes me think  
that they'll be successful (other than the current success stories)  
is that there are design principles which can ground the discussion  
in reality and prevent eternal disagreements.

-ryan

From lucas.gonze at gmail.com  Fri Jul  8 14:34:08 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Fri Jul  8 14:24:24 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <BEF3E079.5C8A0%tantek@cs.stanford.edu>
References: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>
	<BEF3E079.5C8A0%tantek@cs.stanford.edu>
Message-ID: <ab069aa005070814343d04e3ff@mail.gmail.com>

On 7/8/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> I'd also say this might be a better discussion for the microformats-dev
> list, but that would require that there be one or more specific
> implementations that we would be able to try out and use to understand the
> problem.
> 
> Carl, Bud, do you have an implementation that we can try out to actually see
> the problem?

Check out http://reblg.com/hrouter.  Given that that app gets a hint
about what the content type is, it can immediately route an incoming
item to a handler appropriate to the type, which is pretty useful. 
Without the type hint, though, it needs to fetch the resource and
figure out what kind of thing it is.  There are two problems with that
-- it increases the complexity and overhead of the application quite a
lot, and it violates javascript security restrictions.

- Lucas
From carl.beeth at gmail.com  Fri Jul  8 19:02:58 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul  8 18:53:13 2005
Subject: [microformats-discuss] Extending the embedded information
In-Reply-To: <D78803C3-198D-4786-832C-28007047FE94@technorati.com>
References: <BEF3F6A4.5C8AF%tantek@cs.stanford.edu>
	<D78803C3-198D-4786-832C-28007047FE94@technorati.com>
Message-ID: <e8ca2e11050708190240a940c1@mail.gmail.com>

rel="alternate" might be enough. Basically the user-agent or crawler
should interpret a link with rel="alternate" inside a micro-format as
more data available at the url.

Just to clarify that this is not a completely theoretical issue here
are two probable examples:

In a web site you want to list an event in many places but you might
not want to encode all the data in every place. Now even though you
don't list all the data everywhere you still want to allow the user
agent to grab all the data from many places.
Example:
BigCorp site has an events section somewhere where all events are
listed each on their own pages nicely encoded with hcalendar. now
somewhere else on the site there is a little box with a promo to an
event, maybe something like this:
<div >
<div class="vevent">
<p>Come and see us at  <a class="url summary"
href="http://www.web2con.com/">Web 2.0 Conference</a>
on <abbr class="dtstart" title="20051005">October 5</abbr> in San Francisco.<p>
<p><a href="http://bigcorp.com/events/web20/" rel="alternate">More info</a></p>
</div>

Another example would be in a someone writing about a event on a another site.
ex:
  <p>don't forget <a href="http://somesite.com/someeventpage/"
class="vevent" rel="alternate">Gnomedex on June 10th</a></p>

I am aware that these two examples are user-agent centric and maybe
not as relevant in crawler/remixing situations.

BTW has anyone worked on making a browser microformats aware? maybe a
firefox extention?

Carl
From tantek at cs.stanford.edu  Sat Jul  9 15:00:31 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Jul  9 14:50:36 2005
Subject: [microformats-discuss] xFolk revision on the wiki
In-Reply-To: <B2A8BAD9-B219-4820-BCF2-450AE9D06780@thecommunityengine.com>
Message-ID: <BEF596A8.5C990%tantek@cs.stanford.edu>

On 7/8/05 6:52 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> BTW, the link to xFolk on the wiki is:
> 
> http://microformats.org/wiki/xfolk

This looks very good Bud!

Congrats on a successful move from blog to wiki.


One minor naming nit:

> http://microformats.org/wiki/xfolk-XMDP

I think we should put the XMDP profile for a spec in a wiki page that is the
name of the spec with "-profile" appended, e.g.

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

I've added this suggestion to the naming-conventions page.

Thanks,

Tantek

From bud at thecommunityengine.com  Sat Jul  9 20:31:29 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sat Jul  9 20:21:29 2005
Subject: [microformats-discuss] xFolk revision on the wiki
In-Reply-To: <BEF596A8.5C990%tantek@cs.stanford.edu>
References: <BEF596A8.5C990%tantek@cs.stanford.edu>
Message-ID: <C03B3A1C-C1AD-492E-B929-7CAB28683B91@thecommunityengine.com>

On Jul 9, 2005, at 18:00, Tantek ?elik wrote:

> On 7/8/05 6:52 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:
>
>
> One minor naming nit:
>
>
>> http://microformats.org/wiki/xfolk-XMDP
>>
>
> I think we should put the XMDP profile for a spec in a wiki page  
> that is the
> name of the spec with "-profile" appended, e.g.
>
>  http://microformats.org/wiki/hcard-profile

You know, I wondered about this.  I'll fix it tomorrow.  I suppose  
the intention is for people to link to the wiki page for their xmdp,  
right?  That just now hit me as how it would work.

BTW, I've come to the conclusion that the wiki format is much more  
natural for doing this sort of thing.  The super-easy revisions,  
letting other (sane, hopefully) folks contribute, and versioning are  
big pluses.

Also, I think the template you have worked out through your previous  
efforts is spot-on for succinct communication with the developer  
community.  I put myself through the pain of recasting xFolk into  
wiki form because that goal seemed worth it.

One thought:  why not boilerplate a version of that for microformats  
proposals (I may just do this) and then as people have bright ideas  
they could just fill that out and post it for reaction.  We would  
then have an archive of all of the ideas that is searchable.

We could put this in a section of the site called microformat  
brainstorming.  People who had bright ideas would have to fill out  
the form (has to be something in there about past practice) which  
imposes a sort of cost (not too high though).  Getting your thing out  
of microformat brainstorming would require getting some sort of  
critical mass of test cases and a few implementations.

Debate could take place in the talk pages of the wiki.

I could go on and on, but I'll wait for reactions.

Pluses:  (1) A structured way for ideas to bubble up; (2) An archive  
of ideas (good and bad); (3) A format for improving and perhaps  
radically altering proposals that does not take up email bandwidth.

Negatives: (1) Do people really understand micrformats well enough to  
do this? (2) Once something is on an archive, people think it is real  
maybe making it harder to give up on loser ideas; (3) The potential  
for pages to become objects of acrimonious debate (e.g., Dave Winer's  
complaints about podcasting).

Bud
From limbo at actcom.co.il  Sun Jul 10 18:13:02 2005
From: limbo at actcom.co.il (Eran)
Date: Sun Jul 10 18:02:54 2005
Subject: [microformats-discuss] xFolk 0.4
Message-ID: <036a01c585b5$af27c0c0$6564a8c0@hellonwheels>

Hey Guys.

At Ryan's suggestion I took a look at xFolk for publishing a list of
tagged resources (links, text, images, etc.) Since I'm interested in
tagging different types of media (some might even be in-lined in the
microformat content) I started thinking about the "taggedLink" class.
I've seen comments on this issue on the original post -
http://thecommunityengine.com/home/archives/2005/05/xfolk_entry_04.html#
comments but I think it might merit some additional discussion.

>From a semantic standpoint I find that "taggedLink" is misleading, the
tags are not comments on the link, they are comments on the _linked
page_ (as represented by its URL). The subject, if you will, is the
resource _pointed at_ by the link. To represent this concept  better we
should use a class name like "taggedResource" or even just "tagged".
This might look like nitpicking but we are, after all, discussing
semantics here.

As a follow-up, I'd like to bring up a question: would it be possible to
use class="tagged" on different types of elements? Say, an IMG, or even
just a SPAN? That would make it easier to tag rich-media objects in
their "natural form", improving the microformats readability for people
(when looking at a tagged image I expect to see an image not a link to
one).

Eran.

From mike at stamen.com  Sun Jul 10 18:20:27 2005
From: mike at stamen.com (Michal Migurski)
Date: Sun Jul 10 18:10:20 2005
Subject: [microformats-discuss] Basic question about microformat validity
Message-ID: <98ADEF6F-E9A4-47D7-9DCE-CE2DE58D2FA9@stamen.com>

Hi,

In thinking about parsing microformats, I've been butting up against  
a level of imprecision in the specs on the wiki.

For example, in the case of hCal it's unclear from the examples given  
at http://microformats.org/wiki/hcalendar#Format what constitutes a  
valid hCal event. Do the tags *have* to be SPAN's and ABBR's, or can  
they be DIV's? Can there be multiple classes applied to elements, or  
is '<span class="vevent such-and-such">...</span>' an invalid hCal  
event? Is there a stable spec here, or is it still being settled?

-mike.

----------------------------------------------------------------
michal migurski- mike@stamen.com
                  415.558.1610


From ryan at technorati.com  Sun Jul 10 18:55:06 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 10 18:44:58 2005
Subject: [microformats-discuss] Basic question about microformat validity
In-Reply-To: <98ADEF6F-E9A4-47D7-9DCE-CE2DE58D2FA9@stamen.com>
References: <98ADEF6F-E9A4-47D7-9DCE-CE2DE58D2FA9@stamen.com>
Message-ID: <58854D47-CF84-48F4-8CC6-45DE3AC15CB7@technorati.com>

On Jul 10, 2005, at 6:20 PM, Michal Migurski wrote:
> Hi,
>
> In thinking about parsing microformats, I've been butting up  
> against a level of imprecision in the specs on the wiki.
>
> For example, in the case of hCal it's unclear from the examples  
> given at http://microformats.org/wiki/hcalendar#Format what  
> constitutes a valid hCal event. Do the tags *have* to be SPAN's and  
> ABBR's, or can they be DIV's?

Regarding your question above, there's actually two different issues  
here:

1. The Use of Span and Div:

<span> and <div> in (x)html are very generic and have almost no  
semantics. So, these are typically used in a last resort (ie, there  
is no html element or compound which would be more semantic).

2. Use of <abbr>

<abbr> is used in cases where we need to pass two representations of  
the same data element? one for human consumption and another for  
machine consumption. Of course, we only want to pass two version is  
we really must, but in this case, we must- human and machine readable  
dates are usually quite different. For the full argument on this, see  
http://tantek.com/log/2005/01.html#d26t0100

> Can there be multiple classes applied to elements,

Yes.

> or is '<span class="vevent such-and-such">...</span>' an invalid  
> hCal event?

not invalid.

> Is there a stable spec here, or is it still being settled?

Things are by no means completely settled, but we're committed to  
maintaining backwards compatibility, so it should be safe to start  
implementing things.

-ryan
From bud at thecommunityengine.com  Sun Jul 10 19:29:46 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul 10 19:19:34 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <036a01c585b5$af27c0c0$6564a8c0@hellonwheels>
References: <036a01c585b5$af27c0c0$6564a8c0@hellonwheels>
Message-ID: <C7229FC0-6953-4597-8D24-12D37C2C9BDC@thecommunityengine.com>

Hi Eran:

First off, xFolk has now graduated to RC1 and is on the wiki here:

http://microformats.org/wiki/xfolk

Your points still holds for the latest version, and I'm open to  
discussion on them.  Let me provide a few reactions inline.  I'll put  
these on the issues list also.

On Jul 10, 2005, at 21:13, Eran wrote:

>> From a semantic standpoint I find that "taggedLink" is misleading,  
>> the
>>
> tags are not comments on the link, they are comments on the _linked
> page_ (as represented by its URL). The subject, if you will, is the
> resource _pointed at_ by the link. To represent this concept   
> better we
> should use a class name like "taggedResource" or even just "tagged".
> This might look like nitpicking but we are, after all, discussing
> semantics here.

Back in xFolk 0.3, the class was actually called xTagged which hits  
at exactly what you are talking about.  What might be the issue with  
using just the word "tagged" or "xTagged"?  At the time, there was  
some discussion in email about just what was being tagged.  At the  
end of the day, in a distributed web tagging system like xFolk or  
reltag, you need  an address to point to because the data cannot be  
assumed to be on your site.  The way to do this for items on the web  
is to point at a URL.

I suppose one could say taggedurl, but isn't that the same as  
taggedlink?

Taggedresource seems less precise in light of this discussion as does  
tagged.  And I do think we need to be precise here because in xFolk,  
we are talking about things with a web presence.

In emerging standards like the geo microformat or even hReview, there  
is a notion that you may be talking about things that are not on the  
web.  The interesting point there, is that the web seems to be  
frequently assumed as a way of resolving their location.

>
> As a follow-up, I'd like to bring up a question: would it be  
> possible to
> use class="tagged" on different types of elements? Say, an IMG, or  
> even
> just a SPAN? That would make it easier to tag rich-media objects in
> their "natural form", improving the microformats readability for  
> people
> (when looking at a tagged image I expect to see an image not a link to
> one).

I see no immediate reason not to take the <img> element into  
account.  This is a very good point.  As for <span>, I see it  
potentially having an identification issue as I discussed above.  As  
a side note, in a discussion of semantics, <span> seems to be the  
least semantic of elements.

I'd like to hear some other opinions on both of these if people have  
any views.  Eran, what's your reaction to the whole link discussion?

Bud

From bud at thecommunityengine.com  Sun Jul 10 19:58:40 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul 10 19:48:28 2005
Subject: [microformats-discuss] Carl Beeth raises an interesting point
In-Reply-To: <ab069aa005070814343d04e3ff@mail.gmail.com>
References: <90F54668-D572-4F6F-AC16-84A1214D251E@thecommunityengine.com>
	<BEF3E079.5C8A0%tantek@cs.stanford.edu>
	<ab069aa005070814343d04e3ff@mail.gmail.com>
Message-ID: <785C2304-C67F-4108-A3C8-F215E993B9B6@thecommunityengine.com>

On Jul 8, 2005, at 17:34, Lucas Gonze wrote:

> Check out http://reblg.com/hrouter.  Given that that app gets a hint
> about what the content type is, it can immediately route an incoming
> item to a handler appropriate to the type, which is pretty useful.
> Without the type hint, though, it needs to fetch the resource and
> figure out what kind of thing it is.  There are two problems with that
> -- it increases the complexity and overhead of the application quite a
> lot, and it violates javascript security restrictions.
>
> - Lucas

Lucas, "right on" basically.  My read on microformats is that they  
have largely not been developed from a web application perspective.   
This is apparent in Brian Suda's X2V which must scan the whole web  
page.  My email that started this little thread was written from a  
just getting started perspective, but I think there is a lot to do here.

I am going to take Tantek's "more rock, less talk" advice and  
forestall further of these discussions until I have a couple of  
worked examples, but actually writing applications that consume  
microformats as data will likely be challenging.  I suspect that  
microformat developers can do some things to help here, and you may  
see some of that in xFolk.

Bud

From limbo at actcom.co.il  Sun Jul 10 20:18:19 2005
From: limbo at actcom.co.il (Eran)
Date: Sun Jul 10 20:08:16 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <C7229FC0-6953-4597-8D24-12D37C2C9BDC@thecommunityengine.com>
Message-ID: <038401c585c7$33be1ad0$6564a8c0@hellonwheels>

Hi Bud,

Thanks for the prompt response.

> First off, xFolk has now graduated to RC1 and is on the wiki here:
> 
> http://microformats.org/wiki/xfolk
>

I've noticed that a coule of days ago and I must say I like the xFolk
format. It's simple, to the point and does its job very well.

> using just the word "tagged" or "xTagged"?  At the time, there was
> some discussion in email about just what was being tagged. 

That is exactly my question but I'm not looking to tag anything that has
no URL as you suggest next.

> At the
> end of the day, in a distributed web tagging system like xFolk or  
> reltag, you need  an address to point to because the data cannot be  
> assumed to be on your site.  The way to do this for items on the web  
> is to point at a URL.
> 

Pointing to a URL is a good way to identify a resource but I suggest
that there's a difference between a link, the URL in the link's href
attribute and the resource linked to. The link is an entity on its own.
The URL is an identifier for the resource and can be used as a proxy for
the resource. The resource is the page or image or snippet of text at
the other end of the link. The object of the entry is the resource (or
by proxy its URL) not the link to the resource so on a purely semantic
level, taggedLink or taggedURL is misleading. Like I said this is a
purely semantic point that can be easily be waved.

> 
> Taggedresource seems less precise in light of this discussion
> as does  
> tagged.  And I do think we need to be precise here because in xFolk,  
> we are talking about things with a web presence.
>

As per my argument above, I believe that taggedResource is more precise
than taggedLink as it points out that the object being tagged is the
pointed resource, not the link. Think of a case where I would make a
reference to someone's bookmark, in this case the object would be the
link (his link, not mine).
 
> >
> > As a follow-up, I'd like to bring up a question: would it be
> > possible to
> > use class="tagged" on different types of elements? Say, an IMG, or  
> > even
> > just a SPAN? That would make it easier to tag rich-media objects in
> > their "natural form", improving the microformats readability for  
> > people
> > (when looking at a tagged image I expect to see an image 
> not a link to
> > one).
> 
> I see no immediate reason not to take the <img> element into  
> account.  This is a very good point.  

This part of the discussion actually brings up a more important argument
for changing taggedLink. For simplicity let's assume I'm using xFolk for
my photo tagging service. Following the microformat philosophy, I would
like to present the information in a way that's meaningful both to
people and machines. For a machine, a URL is enough to identify a a
resource so something like the following is enough:

<span class="xfolkentry">
<a class="taggedlink" href="http://example.com/image.png">my image</a>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span>

But to a human browing this page this makes little sense. The following
alternative representation might work better:

<span class="xfolkentry">
<img class="taggedresource" src="http://example.com/image.png" alt="my
image">
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span>

Using class="taggedlink" on an IMG element doesn't seem right. Of
course, we can combine the two:

<span class="xfolkentry">
<a class="taggedlink" href="http://example.com/image.png">
	<img src="http://example.com/image.png" alt="my image">
</a>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span>

Which works very well for images but might not work so well for other
media types (video, text snippets, etc.) 

> As for <span>, I see it  
> potentially having an identification issue as I discussed above.  As  
> a side note, in a discussion of semantics, <span> seems to be the  
> least semantic of elements.
> 

I only bring up span as a way to markup a arbitrary text snippet. I'm
not sure why I want to tag arbitrary text but apparently, I do. Let's
just say I want to tag someone's comments regarding some image. I might
want to be able to do something like:

<span class="xfolkentry">
<span class="note taggedresource">this is my note. There are many like
it but this one is mine</span>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span>

I hope this helps to clarify my thoughts on the subject. 

Eran.

PS.
Mod: sorry for the double posts.

From ryan at technorati.com  Sun Jul 10 20:37:56 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 10 20:27:48 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <C7229FC0-6953-4597-8D24-12D37C2C9BDC@thecommunityengine.com>
References: <036a01c585b5$af27c0c0$6564a8c0@hellonwheels>
	<C7229FC0-6953-4597-8D24-12D37C2C9BDC@thecommunityengine.com>
Message-ID: <F0CA59E1-C1F5-4440-AA7C-EEBD0C45CE3E@technorati.com>

On Jul 10, 2005, at 7:29 PM, Bud Gibson wrote:
> Hi Eran:
>
> First off, xFolk has now graduated to RC1 and is on the wiki here:
>
> http://microformats.org/wiki/xfolk
>
> Your points still holds for the latest version, and I'm open to  
> discussion on them.  Let me provide a few reactions inline.  I'll  
> put these on the issues list also.
>
> On Jul 10, 2005, at 21:13, Eran wrote:
>
>
>>> From a semantic standpoint I find that "taggedLink" is  
>>> misleading, the
>> tags are not comments on the link, they are comments on the _linked
>> page_ (as represented by its URL). The subject, if you will, is the
>> resource _pointed at_ by the link. To represent this concept   
>> better we
>> should use a class name like "taggedResource" or even just "tagged".
>> This might look like nitpicking but we are, after all, discussing
>> semantics here.
>
> Back in xFolk 0.3, the class was actually called xTagged which hits  
> at exactly what you are talking about.  What might be the issue  
> with using just the word "tagged" or "xTagged"?  At the time, there  
> was some discussion in email about just what was being tagged.  At  
> the end of the day, in a distributed web tagging system like xFolk  
> or reltag, you need  an address to point to because the data cannot  
> be assumed to be on your site.  The way to do this for items on the  
> web is to point at a URL.
>
> I suppose one could say taggedurl, but isn't that the same as  
> taggedlink?

I thin Eran is suggested a return to something like xtagged.

> Taggedresource seems less precise in light of this discussion as  
> does tagged.  And I do think we need to be precise here because in  
> xFolk, we are talking about things with a web presence.
>
> In emerging standards like the geo microformat or even hReview,  
> there is a notion that you may be talking about things that are not  
> on the web.  The interesting point there, is that the web seems to  
> be frequently assumed as a way of resolving their location.
>
>> As a follow-up, I'd like to bring up a question: would it be  
>> possible to
>> use class="tagged" on different types of elements? Say, an IMG, or  
>> even
>> just a SPAN? That would make it easier to tag rich-media objects in
>> their "natural form", improving the microformats readability for  
>> people
>> (when looking at a tagged image I expect to see an image not a  
>> link to
>> one).
>
> I see no immediate reason not to take the <img> element into  
> account.  This is a very good point.  As for <span>, I see it  
> potentially having an identification issue as I discussed above.   
> As a side note, in a discussion of semantics, <span> seems to be  
> the least semantic of elements.

Span's could also be done as a link:

<span title="mypermalink" class ="tagged"> the thing you're taggin' </ 
span>

Of course, if you're doing author-tagging inline, you don't even  
really need xFolk, you could just use rel-tag.

-ryan


> I'd like to hear some other opinions on both of these if people  
> have any views.  Eran, what's your reaction to the whole link  
> discussion?
>
> Bud
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://mic

From bud at thecommunityengine.com  Sun Jul 10 20:40:43 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul 10 20:30:30 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <038401c585c7$33be1ad0$6564a8c0@hellonwheels>
References: <038401c585c7$33be1ad0$6564a8c0@hellonwheels>
Message-ID: <3A52B667-24C6-49DA-A4FC-FE84F93BE035@thecommunityengine.com>

Late here on the east cost.  Early in Israel I'm assuming.  The  
examples help, and I want to accommodate practice.

I think we agree on accommodating the <img> element.  I'm less  
adamant now about the taggelink name and its essential rightness.   
The key there is that we have a URL pointer, as you agree.

Do you really want to tag <span>'s?  Could you elaborate on that use  
case some more?  Here's what I currently understand:

1.  You want to tag the comment.  If the comment had a url, that  
would be easy.  Without a URL, harder, BUT the comment could easily  
have its own URL (give it an ID and then the URL is of the form  
http://somedomain.com/itemTagged#commentID).

2.  You want to identify tags by user for a single resource  (seems  
less likely).

Which of these is it?

Let's forestall a decision on taggedlink for now.  I see your  
argument, but I have to weigh it in light of changing the standard or  
adding an alias.  That complicates parsing, and others are just  
accepting taggedlink.  I still do like the idea of reinforcing we are  
talking about something linked to from the page.

Bud
On Jul 10, 2005, at 23:18, Eran wrote:

> Hi Bud,
>
> Thanks for the prompt response.
>
>
>> First off, xFolk has now graduated to RC1 and is on the wiki here:
>>
>> http://microformats.org/wiki/xfolk
>>
>>
>
> I've noticed that a coule of days ago and I must say I like the xFolk
> format. It's simple, to the point and does its job very well.
>
>
>> using just the word "tagged" or "xTagged"?  At the time, there was
>> some discussion in email about just what was being tagged.
>>
>
> That is exactly my question but I'm not looking to tag anything  
> that has
> no URL as you suggest next.
>
>
>> At the
>> end of the day, in a distributed web tagging system like xFolk or
>> reltag, you need  an address to point to because the data cannot be
>> assumed to be on your site.  The way to do this for items on the web
>> is to point at a URL.
>>
>>
>
> Pointing to a URL is a good way to identify a resource but I suggest
> that there's a difference between a link, the URL in the link's href
> attribute and the resource linked to. The link is an entity on its  
> own.
> The URL is an identifier for the resource and can be used as a  
> proxy for
> the resource. The resource is the page or image or snippet of text at
> the other end of the link. The object of the entry is the resource (or
> by proxy its URL) not the link to the resource so on a purely semantic
> level, taggedLink or taggedURL is misleading. Like I said this is a
> purely semantic point that can be easily be waved.
>
>
>>
>> Taggedresource seems less precise in light of this discussion
>> as does
>> tagged.  And I do think we need to be precise here because in xFolk,
>> we are talking about things with a web presence.
>>
>>
>
> As per my argument above, I believe that taggedResource is more  
> precise
> than taggedLink as it points out that the object being tagged is the
> pointed resource, not the link. Think of a case where I would make a
> reference to someone's bookmark, in this case the object would be the
> link (his link, not mine).
>
>
>>>
>>> As a follow-up, I'd like to bring up a question: would it be
>>> possible to
>>> use class="tagged" on different types of elements? Say, an IMG, or
>>> even
>>> just a SPAN? That would make it easier to tag rich-media objects in
>>> their "natural form", improving the microformats readability for
>>> people
>>> (when looking at a tagged image I expect to see an image
>>>
>> not a link to
>>
>>> one).
>>>
>>
>> I see no immediate reason not to take the <img> element into
>> account.  This is a very good point.
>>
>
> This part of the discussion actually brings up a more important  
> argument
> for changing taggedLink. For simplicity let's assume I'm using  
> xFolk for
> my photo tagging service. Following the microformat philosophy, I  
> would
> like to present the information in a way that's meaningful both to
> people and machines. For a machine, a URL is enough to identify a a
> resource so something like the following is enough:
>
> <span class="xfolkentry">
> <a class="taggedlink" href="http://example.com/image.png">my image</a>
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> But to a human browing this page this makes little sense. The  
> following
> alternative representation might work better:
>
> <span class="xfolkentry">
> <img class="taggedresource" src="http://example.com/image.png" alt="my
> image">
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> Using class="taggedlink" on an IMG element doesn't seem right. Of
> course, we can combine the two:
>
> <span class="xfolkentry">
> <a class="taggedlink" href="http://example.com/image.png">
>     <img src="http://example.com/image.png" alt="my image">
> </a>
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> Which works very well for images but might not work so well for other
> media types (video, text snippets, etc.)
>
>
>> As for <span>, I see it
>> potentially having an identification issue as I discussed above.  As
>> a side note, in a discussion of semantics, <span> seems to be the
>> least semantic of elements.
>>
>>
>
> I only bring up span as a way to markup a arbitrary text snippet. I'm
> not sure why I want to tag arbitrary text but apparently, I do. Let's
> just say I want to tag someone's comments regarding some image. I  
> might
> want to be able to do something like:
>
> <span class="xfolkentry">
> <span class="note taggedresource">this is my note. There are many like
> it but this one is mine</span>
> <a rel="tag" href="http://example.com/tag/foo">foo</a>
> </span>
>
> I hope this helps to clarify my thoughts on the subject.
>
> Eran.
>
> PS.
> Mod: sorry for the double posts.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From limbo at speakeasy.net  Sun Jul 10 21:33:34 2005
From: limbo at speakeasy.net (Eran)
Date: Sun Jul 10 21:23:24 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <3A52B667-24C6-49DA-A4FC-FE84F93BE035@thecommunityengine.com>
Message-ID: <038b01c585d1$b2dd6500$6564a8c0@hellonwheels>

> 
> Late here on the east cost.  Early in Israel I'm assuming.  The
> examples help, and I want to accommodate practice.
> 

West coast, actually, getting late here as well. No idea how wide
microformat adoption is in israel... :)

> Do you really want to tag <span>'s?  Could you elaborate on that use
> case some more?  Here's what I currently understand:
> 
> 1.  You want to tag the comment.  If the comment had a url, that
> would be easy.  Without a URL, harder, BUT the comment could easily  
> have its own URL (give it an ID and then the URL is of the form  
> http://somedomain.com/itemTagged#commentID).
> 

I'm trying to accommodate an existing system that I have little control
over. I might have URI to access a specific comment but I want to be
ready for the case that I don't. I'll definitely know more tomorrow. If
I do not have a URI for the comment, this becomes complicated as the
main use for the microformat will be in RSS. I don't know if I can point
to a specific anchor in an RSS file but that's beyond the scope of this
discussion anyway. I like the idea of having the textual content in-line
with the tags, it seems better from a presentation standpoint but I can
always hack it into place somehow.

> Let's forestall a decision on taggedlink for now.  I see your
> argument, but I have to weigh it in light of changing the 
> standard or  
> adding an alias.  That complicates parsing, and others are just  
> accepting taggedlink.  I still do like the idea of 
> reinforcing we are  
> talking about something linked to from the page.
> 

No problem. I know how hard it is to change a format that's already in
use. 

Thanks,
Eran.

From tantek at cs.stanford.edu  Sun Jul 10 23:56:20 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sun Jul 10 23:46:15 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <038b01c585d1$b2dd6500$6564a8c0@hellonwheels>
Message-ID: <BEF765B8.5CC52%tantek@cs.stanford.edu>

Excellent discussion guys, I think we're making some great progress.

On 7/10/05 9:33 PM, "Eran" <limbo@speakeasy.net> wrote:

>> Let's forestall a decision on taggedlink for now.  I see your
>> argument, but I have to weigh it in light of changing the
>> standard or  
>> adding an alias.  That complicates parsing, and others are just
>> accepting taggedlink.  I still do like the idea of
>> reinforcing we are
>> talking about something linked to from the page.
> 
> No problem. I know how hard it is to change a format that's already in
> use. 

Consider that it's even harder to change it later.

Also, as part of the microformats method is to try something, try some
implementation and then *iterate*, that means we explicitly should not, and
more to the point, in order to iterate, CANNOT use the reason of "already in
use" as an excuse to avoid change.

If you're going to go for rapid design and implementation, you have to also
embrace the flexibility of change after implementation.

Otherwise you doom yourself rapid design which is then locked into place
prematurely.

In otherwords, evolution is more important than backwards compatibility with
a few hours of work.  Let's not forget that.

This also means that microformat spec authors MUST be up front about the
iterative and evolutionary nature of this process, and thus we have the
wording about a "work in progress" on the various microformat specs that are
still be iterated on, *including* xFolk.

Thanks,

Tantek

From julian_bond at voidstar.com  Mon Jul 11 02:16:44 2005
From: julian_bond at voidstar.com (Julian Bond)
Date: Mon Jul 11 02:07:25 2005
Subject: [microformats-discuss] Two usage scenarios
Message-ID: <J7erqTC8jj0CFAwL@jblaptop.voidstar.com>

In my continuing attempt to keep up with the latest greatest idea, I 
have two scenarios on Ecademy.com that would benefit from microformats. 
But it leads to questions.

1) We have a lot of meeting data and I'd really like to syndicate it. 
I've tried generating iCal files containing multiple events, but I've 
failed to get the format just right so it will import correctly in both 
Outlook and Sunbird. So then I started thinking about creating an RSS 
feed with embedded hCal data in the descriptions field. Is this a good 
approach? Are there others?

2) I'd like to start putting hCard data into our member profiles. I 
already have FOAF and vCard available. The catch here is that the basic 
page probably doesn't validate and by the time the user has inserted 
some fairly arbitrary html into their free form notes field, it almost 
certainly doesn't validate. The next problem is that laying out the 
human readable version doesn't quite lend itself to making the tags 
hCard compatible. So what I'm thinking is to link (rel alternate) to a 
separate hCard URL that contains a simple cut down version of the 
profile page containing just the hCard data where I would have complete 
control of both the html display and the hcard tags. Does this sound 
like a good idea? Lastly, I can't see any good tags in the vCard spec or 
elsewhere for defining a free form "long bio" (type TEXT in Mysql terms) 
data item containing limited html. Is there one?

-- 
Julian Bond E&MSN: julian_bond at voidstar.com  M: +44 (0)77 5907 2173
Webmaster:             http://www.ecademy.com/  T: +44 (0)192 0412 433
Personal WebLog:      http://www.voidstar.com/  S: callto://julian.bond
                      *** Just Say No To DRM ***

From bud at thecommunityengine.com  Mon Jul 11 05:18:24 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 11 05:08:06 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <BEF765B8.5CC52%tantek@cs.stanford.edu>
References: <BEF765B8.5CC52%tantek@cs.stanford.edu>
Message-ID: <9EFA4881-4CDB-49CC-B57A-91DB118DEA7B@thecommunityengine.com>

On Jul 11, 2005, at 2:56, Tantek ?elik wrote:

> This also means that microformat spec authors MUST be up front  
> about the
> iterative and evolutionary nature of this process, and thus we have  
> the
> wording about a "work in progress" on the various microformat specs  
> that are
> still be iterated on, *including* xFolk.

And I think we are doing just this with xFolk.  You'll note that this  
iteration brought to the fore the idea of adding the <img> element to  
the spec which seems like it should happen.  Sounds like rapid  
iteration to me.

I am less thrilled by the idea of changing attribute values.  Only  
infrequently is there a real value-add from that.  People all have  
their view on what an attribute value should be.  If you changed  
every time, you would have as many attribute values as potential  
implementers.

So, the bottom line for right now is this:

1.  The image element is going to come into a soon to be updated  
element of the spec.  Assume you can use it now with the same  
semantics as the <a> element.

2.  Eran, let me suggest that you and I chat in real time about the  
comment issue.  Usually, there is some html representation of the  
content as well as the RSS feed, and it might help to consider that.   
What would help here is a detailed use case.  We could get on IRC  
late in the day today or we could make another attempt by email.

3.  I think we agree that the "taggedlink" issue can be tabled (left  
as is) for now.  Something that I would find compelling is the idea  
that there is already a lot of usage, perhaps in a related community  
around another value.

Bud

From skeltoac at gmail.com  Mon Jul 11 06:48:53 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Mon Jul 11 06:39:05 2005
Subject: [microformats-discuss] Proposing RelSource
Message-ID: <e6ec604d050711064868fe374f@mail.gmail.com>

Hi everyone, I'm Andy Skelton, creator of http://blogsoftheday.com.
With this email I hope to spark some discussion on a microformat
proposal.

Keeping an eye on BOTD's HotList, which uses traffic stats to rank
recent posts on participating blogs, I have discovered that most news
bloggers are getting their news from other bloggers or mainstream news
sites and very few are reporting first-hand. Most bloggers are already
posting links to their sources (cowpath) but these links are by no
means standardized (paving).

While this kind of news propagation is good, I believe the source
links should be recognized by machines and considered when listings
are generated by engines such as Technorati. To achieve this, I
propose a new microformat: RelSource. Authors can use it when they
quote, reference or discuss a news article reported by another online
source by adding rel="source" when they link to their sources.

Examples:
<a href="http://blogsoftheday.com/?p=43" rel="source">BOTD
proposes</a> a new microformat.
or
Discussion of new RelSource microformat proposal... Source: <a
href="http://blogsoftheday.com/?p=43" rel="source">Blogs Of The
Day</a>

I await your ideas on this matter.

Andy Skelton
http://www.skeltoac.com
From bud at thecommunityengine.com  Mon Jul 11 06:56:30 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 11 06:46:13 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <038b01c585d1$b2dd6500$6564a8c0@hellonwheels>
References: <038b01c585d1$b2dd6500$6564a8c0@hellonwheels>
Message-ID: <65C501D0-AA42-4374-9F17-0597FA706968@thecommunityengine.com>

On Jul 11, 2005, at 0:33, Eran wrote:

> I'm trying to accommodate an existing system that I have little  
> control
> over. I might have URI to access a specific comment but I want to be
> ready for the case that I don't. I'll definitely know more  
> tomorrow. If
> I do not have a URI for the comment, this becomes complicated as the
> main use for the microformat will be in RSS. I don't know if I can  
> point
> to a specific anchor in an RSS file but that's beyond the scope of  
> this
> discussion anyway. I like the idea of having the textual content in- 
> line
> with the tags, it seems better from a presentation standpoint but I  
> can
> always hack it into place somehow.

Thinking further on this after a meeting, I think there are ways to  
make the presentation aspect (your last point) work.  The more  
fundamental issue as far as I can tell is what happens if there is no  
URL conceivable for the comment.

Bud
From mail at webmapper.net  Mon Jul 11 07:22:32 2005
From: mail at webmapper.net (Edward Mac Gillavry)
Date: Mon Jul 11 07:12:20 2005
Subject: [microformats-discuss] Proposing RelSource
References: <e6ec604d050711064868fe374f@mail.gmail.com>
Message-ID: <001f01c58623$faf11c90$2201a8c0@webmapper>

Hi there,

Happy to comment on geospatial stuff, but I like a challenge in other fields 
now and then... Why not use the "cite" attribute in <blockquote> and <q>?:

< blockquote cite=http://www.w3.org/TR/html401/struct/text.html#adef-cite-Q" 
 >

cite = uri [CT]
The value of this attribute is a URI that designates a source document or 
message. This attribute is intended to give information about the source 
from which the quotation was borrowed.

</ blockquote >

Kind regards,

Edward


----- Original Message ----- 
From: "Andy Skelton" <skeltoac@gmail.com>
To: "Microformats-Discuss" <microformats-discuss@microformats.org>
Sent: Monday, July 11, 2005 3:48 PM
Subject: [microformats-discuss] Proposing RelSource


Hi everyone, I'm Andy Skelton, creator of http://blogsoftheday.com.
With this email I hope to spark some discussion on a microformat
proposal.

Keeping an eye on BOTD's HotList, which uses traffic stats to rank
recent posts on participating blogs, I have discovered that most news
bloggers are getting their news from other bloggers or mainstream news
sites and very few are reporting first-hand. Most bloggers are already
posting links to their sources (cowpath) but these links are by no
means standardized (paving).

While this kind of news propagation is good, I believe the source
links should be recognized by machines and considered when listings
are generated by engines such as Technorati. To achieve this, I
propose a new microformat: RelSource. Authors can use it when they
quote, reference or discuss a news article reported by another online
source by adding rel="source" when they link to their sources.

Examples:
<a href="http://blogsoftheday.com/?p=43" rel="source">BOTD
proposes</a> a new microformat.
or
Discussion of new RelSource microformat proposal... Source: <a
href="http://blogsoftheday.com/?p=43" rel="source">Blogs Of The
Day</a>

I await your ideas on this matter.

Andy Skelton
http://www.skeltoac.com
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss 

From bud at thecommunityengine.com  Mon Jul 11 07:29:15 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 11 07:18:56 2005
Subject: [microformats-discuss] Two usage scenarios
In-Reply-To: <J7erqTC8jj0CFAwL@jblaptop.voidstar.com>
References: <J7erqTC8jj0CFAwL@jblaptop.voidstar.com>
Message-ID: <6EC2536E-348B-4E54-8F88-A3BC4EAC3ECD@thecommunityengine.com>

On Jul 11, 2005, at 5:16, Julian Bond wrote:

> 2) I'd like to start putting hCard data into our member profiles. I  
> already have FOAF and vCard available. The catch here is that the  
> basic page probably doesn't validate and by the time the user has  
> inserted some fairly arbitrary html into their free form notes  
> field, it almost certainly doesn't validate. The next problem is  
> that laying out the human readable version doesn't quite lend  
> itself to making the tags hCard compatible. So what I'm thinking is  
> to link (rel alternate) to a separate hCard URL that contains a  
> simple cut down version of the profile page containing just the  
> hCard data where I would have complete control of both the html  
> display and the hcard tags. Does this sound like a good idea?  
> Lastly, I can't see any good tags in the vCard spec or elsewhere  
> for defining a free form "long bio" (type TEXT in Mysql terms) data  
> item containing limited html. Is there one?

Brian Suda's solution in X2V is to use an XSLT transformation on the  
whole page looking for hCalendar and hCard markup.  You point up the  
obvious issue that pages have to be at least well-formed (elements  
properly nested, no illegal characters, legal element names all from  
a purely xml perspective) for this type of solution to work.  Here's  
the link to the Suda page:

http://suda.co.uk/projects/X2V/

Therefore, what you are proposing makes a ton of sense in light of  
existing tools.  It would seem you could adapt Suda's mechanism to  
your case.

I'll also point out that modern browsers do a decent job with  
imperfect DOM trees (i.e., pages with unclosed elements, illegal  
characters, etc.).  There might be a strategy that involved using the  
browsers native DOM parsing capacities, but that would likely lead to  
browser specific solutions.

HTH,
Bud

From bud at thecommunityengine.com  Mon Jul 11 07:30:38 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 11 07:20:18 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <001f01c58623$faf11c90$2201a8c0@webmapper>
References: <e6ec604d050711064868fe374f@mail.gmail.com>
	<001f01c58623$faf11c90$2201a8c0@webmapper>
Message-ID: <042E8DC0-D520-48E3-A179-1300D74ED04F@thecommunityengine.com>

This sounds like the use case for Ryan King's hVia.  Ryan, is that  
still a proposal?

Bud
On Jul 11, 2005, at 10:22, Edward Mac Gillavry wrote:

> Hi there,
>
> Happy to comment on geospatial stuff, but I like a challenge in  
> other fields now and then... Why not use the "cite" attribute in  
> <blockquote> and <q>?:
>
> < blockquote cite=http://www.w3.org/TR/html401/struct/ 
> text.html#adef-cite-Q" >
>
> cite = uri [CT]
> The value of this attribute is a URI that designates a source  
> document or message. This attribute is intended to give information  
> about the source from which the quotation was borrowed.
>
> </ blockquote >
>
> Kind regards,
>
> Edward
>
>
> ----- Original Message ----- From: "Andy Skelton" <skeltoac@gmail.com>
> To: "Microformats-Discuss" <microformats-discuss@microformats.org>
> Sent: Monday, July 11, 2005 3:48 PM
> Subject: [microformats-discuss] Proposing RelSource
>
>
> Hi everyone, I'm Andy Skelton, creator of http://blogsoftheday.com.
> With this email I hope to spark some discussion on a microformat
> proposal.
>
> Keeping an eye on BOTD's HotList, which uses traffic stats to rank
> recent posts on participating blogs, I have discovered that most news
> bloggers are getting their news from other bloggers or mainstream news
> sites and very few are reporting first-hand. Most bloggers are already
> posting links to their sources (cowpath) but these links are by no
> means standardized (paving).
>
> While this kind of news propagation is good, I believe the source
> links should be recognized by machines and considered when listings
> are generated by engines such as Technorati. To achieve this, I
> propose a new microformat: RelSource. Authors can use it when they
> quote, reference or discuss a news article reported by another online
> source by adding rel="source" when they link to their sources.
>
> Examples:
> <a href="http://blogsoftheday.com/?p=43" rel="source">BOTD
> proposes</a> a new microformat.
> or
> Discussion of new RelSource microformat proposal... Source: <a
> href="http://blogsoftheday.com/?p=43" rel="source">Blogs Of The
> Day</a>
>
> I await your ideas on this matter.
>
> Andy Skelton
> http://www.skeltoac.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 skeltoac at gmail.com  Mon Jul 11 07:32:09 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Mon Jul 11 07:22:21 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <001f01c58623$faf11c90$2201a8c0@webmapper>
References: <e6ec604d050711064868fe374f@mail.gmail.com>
	<001f01c58623$faf11c90$2201a8c0@webmapper>
Message-ID: <e6ec604d050711073238940af5@mail.gmail.com>

On 7/11/05, Edward Mac Gillavry <mail@webmapper.net> wrote:
> Why not use the "cite" attribute in <blockquote> and <q>?:

True, but the cite attribute is a) not often utilized by bloggers and
b) not visible to the user. Does Technorati spider a URL in a cite
attribute?

People already use visible source links and they are beginning to
understand rel, so this seemed like a simple step.


Andy
From bud at thecommunityengine.com  Mon Jul 11 07:41:46 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 11 07:31:26 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d050711073238940af5@mail.gmail.com>
References: <e6ec604d050711064868fe374f@mail.gmail.com>
	<001f01c58623$faf11c90$2201a8c0@webmapper>
	<e6ec604d050711073238940af5@mail.gmail.com>
Message-ID: <2E43852E-B2C1-425C-8392-3B144C4D848A@thecommunityengine.com>

On Jul 11, 2005, at 10:32, Andy Skelton wrote:

> True, but the cite attribute is a) not often utilized by bloggers and
> b) not visible to the user. Does Technorati spider a URL in a cite
> attribute?

The cite *element* is visible.  Have a look at http:// 
thecommunityengine.com/home.  The blockquote at the top uses a cite  
element.  Put an <a> inside of that for the link.  I know that  
technorati and other search engines pick those up.

Ryan King proposed something like you are proposing but called it  
hVia.  It never made it beyond the blogged idea stage though as far  
as I can tell.  Maybe you two could put some melding of ideas forward  
based on the use cases you provide.

Bud

From julian_bond at voidstar.com  Mon Jul 11 08:11:18 2005
From: julian_bond at voidstar.com (Julian Bond)
Date: Mon Jul 11 08:01:53 2005
Subject: [microformats-discuss] Two usage scenarios
In-Reply-To: <6EC2536E-348B-4E54-8F88-A3BC4EAC3ECD@thecommunityengine.com>
References: <J7erqTC8jj0CFAwL@jblaptop.voidstar.com>
	<6EC2536E-348B-4E54-8F88-A3BC4EAC3ECD@thecommunityengine.com>
Message-ID: <yQkVAxAWwo0CFAkW@jblaptop.voidstar.com>

Bud Gibson <bud@thecommunityengine.com> Mon, 11 Jul 2005 10:29:15
>I'll also point out that modern browsers do a decent job with imperfect 
>DOM trees (i.e., pages with unclosed elements, illegal characters, 
>etc.).  There might be a strategy that involved using the browsers 
>native DOM parsing capacities, but that would likely lead to browser 
>specific solutions.

This is another story and off topic for this group, but I could really 
do with a PHP HTMLTidy library to clean up users HTML input. It's either 
that or go to a Wiki/phpbb intermediate ML.

-- 
Julian Bond E&MSN: julian_bond at voidstar.com  M: +44 (0)77 5907 2173
Webmaster:             http://www.ecademy.com/  T: +44 (0)192 0412 433
Personal WebLog:      http://www.voidstar.com/  S: callto://julian.bond
                      *** Just Say No To DRM ***

From tantek at cs.stanford.edu  Mon Jul 11 08:13:10 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jul 11 08:02:55 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <9EFA4881-4CDB-49CC-B57A-91DB118DEA7B@thecommunityengine.com>
Message-ID: <BEF7DA72.5CCA2%tantek@cs.stanford.edu>

On 7/11/05 5:18 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> On Jul 11, 2005, at 2:56, Tantek ?elik wrote:
> 
>> This also means that microformat spec authors MUST be up front
>> about the
>> iterative and evolutionary nature of this process, and thus we have
>> the
>> wording about a "work in progress" on the various microformat specs
>> that are
>> still be iterated on, *including* xFolk.
> 
> And I think we are doing just this with xFolk.  You'll note that this
> iteration brought to the fore the idea of adding the <img> element to
> the spec which seems like it should happen.  Sounds like rapid
> iteration to me.

Yes.

> I am less thrilled by the idea of changing attribute values.

Why?

> Only  
> infrequently is there a real value-add from that.


If it benefits usability, and human authoring, that is sufficient benefit.

Both of those trump implementations.  Humans first, machines
(implementations) second.


> People all have  
> their view on what an attribute value should be.

True.


> If you changed  every time, you would have as many attribute values
> as potential implementers.

That's a bit of a reductio ad absurdum Bud.  Nothing from this discussion
suggests changing a class name "every time".

And yes, there *MUST* be a good reason to change the name, REGARDLESS of
whether there are implementations or not.

But if there is a good reason, the name MUST be changed, REGARDLESS of
whether there are implementations or not.  That is also part of the
iteration/evolution.  For "compatibility" with past implementations or
content, earlier names may be kept in "deprecated" form.  You may find that
with how fast both specs and implementations iterate, that you can drop the
deprecated forms after a few iterations.


> So, the bottom line for right now is this:
> 
> 1.  The image element is going to come into a soon to be updated
> element of the spec.  Assume you can use it now with the same
> semantics as the <a> element.

Great.


> 2.  Eran, let me suggest that you and I chat in real time about the
> comment issue.  Usually, there is some html representation of the
> content as well as the RSS feed, and it might help to consider that.
> What would help here is a detailed use case.  We could get on IRC
> late in the day today or we could make another attempt by email.

I tend to agree with your earlier comment that RelTag already handles this
on its own.  There is no need to "reinvent" this with xfolk.  In fact, why
use something with more structure (xfolk) to represent a tagged comment (AKA
blog post) when something with less structure (RelTag) will do just fine?


> 3.  I think we agree that the "taggedlink" issue can be tabled (left
> as is) for now.  Something that I would find compelling is the idea
> that there is already a lot of usage, perhaps in a related community
> around another value.

I think the naming discussion is a good one and should continue.

One thing most technology folks are very bad at (not directed at you Bud),
is naming things understandably from a *users* point of view.  Usually they
name things understandably from a the programmer/implementer's point of
view, with the reasoning (especially with formats, and markup languages),
that the user will "never need to deal with it".

This is the majority view among technical people, and they are wrong.

One of the reasons HTML has succeeded so well is that the tag and attribute
names are (for the most part) fairly well named in terms of easily
understanding what they mean immediately.

"taggedLink" is a good example (my only nit being the camelCase - that's a
programmerism which IMHO has no place in names of tags/attributes/values for
user authoring, that's a longer discussion. suffice it to say, we chose all
lowercase URLs on the wiki for a reason (or several)).

taggedLink is fairly obvious what it means.

With the addition of images, what to do?

1. change to a new name for both links and images
2. keep taggedLink (perhaps rename to taggedlink) pick a new name just for
images

(1) keeps the spec "simplest".  The challenge is perhaps it becomes too
abstract.  RDF has the notion of "about" which many folk have difficulty
"grokking", perhaps because it is too abstract.

Would "tagged" be sufficient?

(2) you could have taggedimage, but when do you stop?  what if I use an
<object> to embed an audio file?  should that be taggedaudio?


BTW, Eran, your question of are you tagging the link or the thing at the end
of the link is a bit of an academic discussion.  For all intents and
purposes, the link *is* the thing at the end of the link.  If it helps,
consider the link the closes thing you have to a "proxy" for the thing at
the end of the link.  So yes, of course you are tagging the thing at the end
of the link.  The link is merely a reference/representation of it.


Thanks,

Tantek

P.S. Perhaps we need to start a wiki page on good naming conventions in
general, not just for URLs on the wiki.

From tantek at cs.stanford.edu  Mon Jul 11 08:17:11 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jul 11 08:06:54 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <2E43852E-B2C1-425C-8392-3B144C4D848A@thecommunityengine.com>
Message-ID: <BEF7DB19.5CCA9%tantek@cs.stanford.edu>

On 7/11/05 7:41 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> On Jul 11, 2005, at 10:32, Andy Skelton wrote:
> 
>> True, but the cite attribute is a) not often utilized by bloggers and
>> b) not visible to the user. Does Technorati spider a URL in a cite
>> attribute?
> 
> The cite *element* is visible.  Have a look at http://
> thecommunityengine.com/home.  The blockquote at the top uses a cite
> element.  Put an <a> inside of that for the link.  I know that
> technorati and other search engines pick those up.

Yes, this is a good suggestion.  As is using the <cite> tag to indicate a
source.  Using the XHTML building blocks where they will do fine rather than
inventing new formats.


> Ryan King proposed something like you are proposing but called it
> hVia.  It never made it beyond the blogged idea stage though as far
> as I can tell.  Maybe you two could put some melding of ideas forward
> based on the use cases you provide.

Exactly.  That's the right place for this discussion/analysis.

Ryan, where is cite-rel on the wiki?

Thanks,

Tantek

From skeltoac at gmail.com  Mon Jul 11 08:17:23 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Mon Jul 11 08:07:30 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <2E43852E-B2C1-425C-8392-3B144C4D848A@thecommunityengine.com>
References: <e6ec604d050711064868fe374f@mail.gmail.com>
	<001f01c58623$faf11c90$2201a8c0@webmapper>
	<e6ec604d050711073238940af5@mail.gmail.com>
	<2E43852E-B2C1-425C-8392-3B144C4D848A@thecommunityengine.com>
Message-ID: <e6ec604d0507110817472158c@mail.gmail.com>

On 7/11/05, Bud Gibson <bud@thecommunityengine.com> wrote:
> The cite *element* is visible.  Have a look at http://
> thecommunityengine.com/home.  The blockquote at the top uses a cite
> element.  Put an <a> inside of that for the link.  I know that
> technorati and other search engines pick those up.

Okay, I see what you mean. That works for folks who do quote sources
and use the cite element with an anchor and that /is/ the most
semantically correct way to do that with existing markup. In my
travels I have not seen people crediting sources that way.

In many cases (http://scoble.weblogs.com/
http://www.blogherald.com/2005/07/11/cubans-blogging-hurricane-dennis/)
sources are not quoted at all but a plain link is provided. Other
times (http://www.ioerror.us/2005/07/10/have-some-manners-will-ya/)
the source link is included but not defined.

RelSource would instantly tell Technorati etc. "this is not a primary
source" and which direction leads upstream to the primary source. In
researching anything, the ability to identify a primary source is
invaluable. Adding this kind of ordinality would add value to any list
of related links such as a tag page.

Andy
From tantek at cs.stanford.edu  Mon Jul 11 08:27:11 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jul 11 08:16:53 2005
Subject: [microformats-discuss] Two usage scenarios
In-Reply-To: <J7erqTC8jj0CFAwL@jblaptop.voidstar.com>
Message-ID: <BEF7DD83.5CCAE%tantek@cs.stanford.edu>

On 7/11/05 2:16 AM, "Julian Bond" <julian_bond@voidstar.com> wrote:

> In my continuing attempt to keep up with the latest greatest idea, I
> have two scenarios on Ecademy.com that would benefit from microformats.
> But it leads to questions.
> 
> 1) We have a lot of meeting data and I'd really like to syndicate it.
> I've tried generating iCal files containing multiple events, but I've
> failed to get the format just right so it will import correctly in both
> Outlook and Sunbird.

You have hit upon one of the reasons we came up with hCalendar.  It is too
much of a burden to ask every content author/publisher to generate valid
.ics files that work in all consuming applications.  It is *much* easier to
markup existing event information on your pages with hCalendar.

(Perhaps this is worthy of adding to the hCalendar FAQ?)


> So then I started thinking about creating an RSS
> feed with embedded hCal data in the descriptions field. Is this a good
> approach? Are there others?

Yes, this works.  It immediately allows anyone with an RSS feed to get the
data, and there is the possibility that aggregator vendors might actually
parse the hCalendar and do good things with it.

Now what we don't have yet is any kind of RSS with hCalendar -> iCalendar
converter yet, but I'm sure it would be easy to alter X2V to support "R2V"
or "A2V" (for RSS and Atom embedding scenarios) as well.

Do you have a URL to pages where you have event data right now so we can
take a look?


> 2) I'd like to start putting hCard data into our member profiles.

Example URL?


> I already have FOAF and vCard available. The catch here is that the basic
> page probably doesn't validate and by the time the user has inserted
> some fairly arbitrary html into their free form notes field, it almost
> certainly doesn't validate.

I would bet there are things you can do to improve the validation of the
page, perhaps not perfectly, but at least achieve well-formedness.


> The next problem is that laying out the
> human readable version doesn't quite lend itself to making the tags
> hCard compatible.

Let the folks here give it a shot.  Provide a URL to the human readable
version and we'll see what folks come up with.


> So what I'm thinking is to link (rel alternate) to a
> separate hCard URL that contains a simple cut down version of the
> profile page containing just the hCard data where I would have complete
> control of both the html display and the hcard tags. Does this sound
> like a good idea?

That's certainly doable, but shouldn't be necessary.  Sounds like more work
that you should have to do.


> Lastly, I can't see any good tags in the vCard spec or
> elsewhere for defining a free form "long bio" (type TEXT in Mysql terms)
> data item containing limited html. Is there one?

vCard doesn't have any provision for including any other form of markup,
like HTML, so the short answer is no.

However, you *could* simply use the "note" field as defined in section 3.6.2
of RFC 2426 for defining a free form "long bio".

See Technorati's staff page for an example of this:

 http://technorati.com/about/staff.html

This works fine in general, as the extra HTML markup is simply ignored when
converted to vCard.

Thanks,

Tantek




From tantek at cs.stanford.edu  Mon Jul 11 08:31:11 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jul 11 08:20:54 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d0507110817472158c@mail.gmail.com>
Message-ID: <BEF7DE9C.5CCB1%tantek@cs.stanford.edu>

On 7/11/05 8:17 AM, "Andy Skelton" <skeltoac@gmail.com> wrote:

> On 7/11/05, Bud Gibson <bud@thecommunityengine.com> wrote:
>> The cite *element* is visible.  Have a look at http://
>> thecommunityengine.com/home.  The blockquote at the top uses a cite
>> element.  Put an <a> inside of that for the link.  I know that
>> technorati and other search engines pick those up.
> 
> Okay, I see what you mean. That works for folks who do quote sources
> and use the cite element with an anchor and that /is/ the most
> semantically correct way to do that with existing markup. In my
> travels I have not seen people crediting sources that way.

The "people don't do it that way" argument does not apply here because
 if they don't use standard semantic XHTML now (e.g. <cite>)
 why would they use a microformat later (e.g. a new rel value) ?


> In many cases (http://scoble.weblogs.com/
> http://www.blogherald.com/2005/07/11/cubans-blogging-hurricane-dennis/)
> sources are not quoted at all but a plain link is provided. Other
> times (http://www.ioerror.us/2005/07/10/have-some-manners-will-ya/)
> the source link is included but not defined.

Yes, I agree this is typical behavior.


> RelSource would instantly tell Technorati etc. "this is not a primary
> source" and which direction leads upstream to the primary source.

Yes.

> In researching anything, the ability to identify a primary source is
> invaluable. Adding this kind of ordinality would add value to any list
> of related links such as a tag page.

Absolutely.  This is a good idea.

The cite-rel (or rel-cite or rel-via?) ideas/proposals are also similar.

Perhaps you can find Ryan and Eran on IRC and make sure both scenarios are
covered, since you have all thought about the same or heavily overlapping
problems.

Thanks,

Tantek

From tantek at cs.stanford.edu  Mon Jul 11 08:43:24 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jul 11 08:33:07 2005
Subject: [microformats-discuss] microformat for CODE snippets
In-Reply-To: <42B96DCF.3000807@caribmedia.com>
Message-ID: <BEF7E134.5CCB7%tantek@cs.stanford.edu>

Hi Michiel


On 6/22/05 6:55 AM, "Michiel van der Blonk" <michiel@caribmedia.com> wrote:

> Content-Type: text/html; charset=ISO-8859-1

Polite reminder.  Please use only "plain text" (text/plain) on the
microformats mailing lists.


> Hi
> 
> I am a developer and would like to have a way of sharing code snippets
> or whole programs through XHTML. That way we can create a 'free source
> code' search engine, or just use google for it. And of course it should
> use the <code> tag.

Makes sense.


> We could use a lot of predefined class names to relate to the piece of code:
> - language
> - type (snippet/function/program/package)
> - title could describe the program
> 
> Example:
> <code class="PHP snippet" title="why eval is evil">
> $evil = eval($good);
> </code>
> 
> And while we are at it, why not use the same tags on links or meta tags,
> so that we can define this in multiple levels.
> 
> Hm, if the rel tag can be used on code, we might have to use that. What
> do you think?

These are some GREAT ideas Michiel.

I think you should start a wiki page, like:

 http://microformats.org/wiki/code-formats

And list exactly what you listed -- your usage scenarios (language, type,
etc.), and your strawman proposed format.

You should also look at what people are already doing.

There are two current practices that I know of:

1. <pre><code> to mean a "block of code" including whitespace

2. using the classname for the language, e.g. <code class="css">

Thanks,

Tantek

From bud at thecommunityengine.com  Mon Jul 11 09:04:32 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 11 08:54:14 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <BEF7DA72.5CCA2%tantek@cs.stanford.edu>
References: <BEF7DA72.5CCA2%tantek@cs.stanford.edu>
Message-ID: <90E1C2F4-473A-4EFF-9096-6EF8BC893EC0@thecommunityengine.com>

On Jul 11, 2005, at 11:13, Tantek ?elik wrote:

> taggedLink is fairly obvious what it means.
>
> With the addition of images, what to do?
>
> 1. change to a new name for both links and images
> 2. keep taggedLink (perhaps rename to taggedlink) pick a new name  
> just for
> images
>
> (1) keeps the spec "simplest".  The challenge is perhaps it becomes  
> too
> abstract.  RDF has the notion of "about" which many folk have  
> difficulty
> "grokking", perhaps because it is too abstract.
>
> Would "tagged" be sufficient?
>
> (2) you could have taggedimage, but when do you stop?  what if I  
> use an
> <object> to embed an audio file?  should that be taggedaudio?

Per some IRC conversation, I think it makes sense to put some of  
these naming suggestions on a brainstorming page.  I want to collect  
data before name changing.

Eran, let's focus on your substantive issues first in these email  
discussions.  I suggest we move to chat.  Tantek's point about using  
just reltag for comments without links sounds like a good effort.

Bud
From markpinc at yahoo.com  Mon Jul 11 09:07:42 2005
From: markpinc at yahoo.com (mark pincus)
Date: Mon Jul 11 08:57:26 2005
Subject: [microformats-discuss] microformat for CODE snippets
In-Reply-To: <BEF7E134.5CCB7%tantek@cs.stanford.edu>
Message-ID: <20050711160742.90189.qmail@web52608.mail.yahoo.com>

this is insane. isnt there a way to put this all on a
wiki so we dont have to sift through 15 msgs a day!

--- Tantek ?elik <tantek@cs.stanford.edu> wrote:

> Hi Michiel
> 
> 
> On 6/22/05 6:55 AM, "Michiel van der Blonk"
> <michiel@caribmedia.com> wrote:
> 
> > Content-Type: text/html; charset=ISO-8859-1
> 
> Polite reminder.  Please use only "plain text"
> (text/plain) on the
> microformats mailing lists.
> 
> 
> > Hi
> > 
> > I am a developer and would like to have a way of
> sharing code snippets
> > or whole programs through XHTML. That way we can
> create a 'free source
> > code' search engine, or just use google for it.
> And of course it should
> > use the <code> tag.
> 
> Makes sense.
> 
> 
> > We could use a lot of predefined class names to
> relate to the piece of code:
> > - language
> > - type (snippet/function/program/package)
> > - title could describe the program
> > 
> > Example:
> > <code class="PHP snippet" title="why eval is
> evil">
> > $evil = eval($good);
> > </code>
> > 
> > And while we are at it, why not use the same tags
> on links or meta tags,
> > so that we can define this in multiple levels.
> > 
> > Hm, if the rel tag can be used on code, we might
> have to use that. What
> > do you think?
> 
> These are some GREAT ideas Michiel.
> 
> I think you should start a wiki page, like:
> 
>  http://microformats.org/wiki/code-formats
> 
> And list exactly what you listed -- your usage
> scenarios (language, type,
> etc.), and your strawman proposed format.
> 
> You should also look at what people are already
> doing.
> 
> There are two current practices that I know of:
> 
> 1. <pre><code> to mean a "block of code" including
> whitespace
> 
> 2. using the classname for the language, e.g. <code
> class="css">
> 
> Thanks,
> 
> Tantek
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
>
http://microformats.org/mailman/listinfo/microformats-discuss
> 



	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail
From tantek at cs.stanford.edu  Mon Jul 11 09:15:08 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jul 11 09:04:50 2005
Subject: [microformats-discuss] List traffic etc.
In-Reply-To: <20050711160742.90189.qmail@web52608.mail.yahoo.com>
Message-ID: <BEF7E90F.5CCC4%tantek@cs.stanford.edu>

On 7/11/05 9:07 AM, "mark pincus" <markpinc@yahoo.com> wrote:

> this is insane. isnt there a way to put this all on a
> wiki so we dont have to sift through 15 msgs a day!

Hi Mark,

I think the intent is that the microformats-discuss list may be a high
volume list at times.

For a lower volume list, where only announcements of new efforts are sent,
you might want to sign up for the microformats-announce list.

I think there is also a digest option in mailman, perhaps you could use that
for the microformats-discuss list if the volume is too high.

Thanks,

Tantek

From ryan at technorati.com  Mon Jul 11 09:36:26 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Jul 11 09:26:09 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <042E8DC0-D520-48E3-A179-1300D74ED04F@thecommunityengine.com>
References: <e6ec604d050711064868fe374f@mail.gmail.com>
	<001f01c58623$faf11c90$2201a8c0@webmapper>
	<042E8DC0-D520-48E3-A179-1300D74ED04F@thecommunityengine.com>
Message-ID: <342A61FC-7519-4A8B-A52F-E4C38D462201@technorati.com>


On Jul 11, 2005, at 7:30 AM, Bud Gibson wrote:

> This sounds like the use case for Ryan King's hVia.  Ryan, is that  
> still a proposal?

It's called citeRel now, and yes its still a proposal, though it  
hasn't made it to the mf.org wiki yet. Perhaps I should work on that  
today. For now see http://hellonline.com/blog/?p=18

-ryan


> Bud
> On Jul 11, 2005, at 10:22, Edward Mac Gillavry wrote:
>
>
>> Hi there,
>>
>> Happy to comment on geospatial stuff, but I like a challenge in  
>> other fields now and then... Why not use the "cite" attribute in  
>> <blockquote> and <q>?:
>>
>> < blockquote cite=http://www.w3.org/TR/html401/struct/ 
>> text.html#adef-cite-Q" >
>>
>> cite = uri [CT]
>> The value of this attribute is a URI that designates a source  
>> document or message. This attribute is intended to give  
>> information about the source from which the quotation was borrowed.
>>
>> </ blockquote >
>>
>> Kind regards,
>>
>> Edward
>>
>>
>> ----- Original Message ----- From: "Andy Skelton"  
>> <skeltoac@gmail.com>
>> To: "Microformats-Discuss" <microformats-discuss@microformats.org>
>> Sent: Monday, July 11, 2005 3:48 PM
>> Subject: [microformats-discuss] Proposing RelSource
>>
>>
>> Hi everyone, I'm Andy Skelton, creator of http://blogsoftheday.com.
>> With this email I hope to spark some discussion on a microformat
>> proposal.
>>
>> Keeping an eye on BOTD's HotList, which uses traffic stats to rank
>> recent posts on participating blogs, I have discovered that most news
>> bloggers are getting their news from other bloggers or mainstream  
>> news
>> sites and very few are reporting first-hand. Most bloggers are  
>> already
>> posting links to their sources (cowpath) but these links are by no
>> means standardized (paving).
>>
>> While this kind of news propagation is good, I believe the source
>> links should be recognized by machines and considered when listings
>> are generated by engines such as Technorati. To achieve this, I
>> propose a new microformat: RelSource. Authors can use it when they
>> quote, reference or discuss a news article reported by another online
>> source by adding rel="source" when they link to their sources.
>>
>> Examples:
>> <a href="http://blogsoftheday.com/?p=43" rel="source">BOTD
>> proposes</a> a new microformat.
>> or
>> Discussion of new RelSource microformat proposal... Source: <a
>> href="http://blogsoftheday.com/?p=43" rel="source">Blogs Of The
>> Day</a>
>>
>> I await your ideas on this matter.
>>
>> Andy Skelton
>> http://www.skeltoac.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
>>
>>
>>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From ryan at technorati.com  Mon Jul 11 09:37:38 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Jul 11 09:27:22 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <BEF7DB19.5CCA9%tantek@cs.stanford.edu>
References: <BEF7DB19.5CCA9%tantek@cs.stanford.edu>
Message-ID: <2E22094D-0AA8-4E4C-AD48-505BE1890B64@technorati.com>

On Jul 11, 2005, at 8:17 AM, Tantek ?elik wrote:

> Ryan, where is cite-rel on the wiki?

Ask me that again later today. :-)

-ryan

From limbo at speakeasy.net  Mon Jul 11 10:16:59 2005
From: limbo at speakeasy.net (Eran)
Date: Mon Jul 11 10:06:49 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <90E1C2F4-473A-4EFF-9096-6EF8BC893EC0@thecommunityengine.com>
Message-ID: <039c01c5863c$5938edb0$6564a8c0@hellonwheels>


> Eran, let's focus on your substantive issues first in these email  
> discussions.  I suggest we move to chat.  Tantek's point about using  
> just reltag for comments without links sounds like a good effort.
> 

Bud, I'll get on IRC later today. I want to finalize my research on what
is available to me and what isn't, this way we won't need to concentrate
on end-cases which never happen.

Eran.

From bud at thecommunityengine.com  Mon Jul 11 10:21:46 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 11 10:11:25 2005
Subject: [microformats-discuss] xFolk 0.4
In-Reply-To: <039c01c5863c$5938edb0$6564a8c0@hellonwheels>
References: <039c01c5863c$5938edb0$6564a8c0@hellonwheels>
Message-ID: <D6402917-FDA8-4CF4-B660-91CD5DDBE7DC@thecommunityengine.com>

My schedule suggests I'll be ready 8 our time, 5 PM yours.

Bud
On Jul 11, 2005, at 13:16, Eran wrote:

>
>
>> Eran, let's focus on your substantive issues first in these email
>> discussions.  I suggest we move to chat.  Tantek's point about using
>> just reltag for comments without links sounds like a good effort.
>>
>>
>
> Bud, I'll get on IRC later today. I want to finalize my research on  
> what
> is available to me and what isn't, this way we won't need to  
> concentrate
> on end-cases which never happen.
>
> Eran.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From limbo at speakeasy.net  Mon Jul 11 10:29:02 2005
From: limbo at speakeasy.net (Eran)
Date: Mon Jul 11 10:18:50 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <342A61FC-7519-4A8B-A52F-E4C38D462201@technorati.com>
Message-ID: <039d01c5863e$07ff18a0$6564a8c0@hellonwheels>


> It's called citeRel now, and yes its still a proposal, though it  
> hasn't made it to the mf.org wiki yet. Perhaps I should work on that  
> today. For now see http://hellonline.com/blog/?p=18
> 
> -ryan
> 
> 

Thanks Ryan.

One of the reasons this proposal never made it beyond the blogged idea
stage is the scarce feedback we got. With more people interested we can
move this idea somewhat faster. 

Andy, if you want to get a better idea of the proposal, where it came
from and where we are currently taking it, check out the following (in
chronological order):
http://theryanking.com/blog/archives/2005/05/06/hvia/
http://theryanking.com/blog/archives/2005/05/09/citevia/
http://hellonline.com/blog/?p=18
http://hellonline.com/blog/?p=19

Btw, this proposal is a good example of Bud's earlier point about
changing attribute names on every iteration.

Eran.

From ryan at technorati.com  Mon Jul 11 12:01:56 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Jul 11 11:51:42 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <2E22094D-0AA8-4E4C-AD48-505BE1890B64@technorati.com>
References: <BEF7DB19.5CCA9%tantek@cs.stanford.edu>
	<2E22094D-0AA8-4E4C-AD48-505BE1890B64@technorati.com>
Message-ID: <1CF404A2-EBFB-4B23-8213-6EF136B038BF@technorati.com>

On Jul 11, 2005, at 9:37 AM, Ryan King wrote:
> On Jul 11, 2005, at 8:17 AM, Tantek ?elik wrote:
>
>> Ryan, where is cite-rel on the wiki?
>
> Ask me that again later today. :-)

Brainstorming stuff going in here: http://microformats.org/wiki/ 
citation-brainstorming

More formal stuff later

-ryan
From geof at geof.net  Mon Jul 11 12:21:31 2005
From: geof at geof.net (Geoffrey Glass)
Date: Mon Jul 11 12:12:24 2005
Subject: [microformats-discuss] Hello & blog post format
Message-ID: <42D2C6BB.7000702@geof.net>

Hello,

I just joined the list.  The archive seems to be down or non-existent, 
so you'll have to forgive me if I haven't a clue.

I am interested in a microformat for blog and forum posts.  I have been 
working on an web annotation tool for web forums which needs to be able 
to find individual posts in a discussion forum in order to annotate them 
and record metadata (title, author, post date, permalink).  I found 
myself moving towards microformat-style markup, then discovered this 
effort.

Another part of the project is collecting metadata along with content 
when a user perfoms a copy-paste operation from a post.  So, for 
example, the copy operation could automatically prefix with the title, 
author, and date of the post.  For example:

 From Online Discussion in Education by Cindy Xin on 16 June 2005:
Online discussion in education is a paradox.

I see the current discussion about RelSource addresses how this should 
be formatted.  My main concern is with how to extract the title, author, 
etc. in the first place.  I have a Javascript hack which does this 
automatically on Firefox, but it's a nasty hack.  A clean solution 
requires a browser extension - which would be relatively useless without 
a standard.

It may clarify to show what I'm doing at the moment.  The class names 
(post excepted) match tag names in the Atom spec. T is any tag:

<T class="post" id="id">
 <T class="title">title</T>
 <T class="author>author name</T>
 <abbr class="created" title="iso date">human-readable date</abbr>
 <a href="permalink">...</a>
 <T class="content">post body</T>
</T>

The other major use I have been thinking about has probably been 
discussed.  Search engines can't discover metadata that has expired from 
RSS or Atom syndication feeds, but which is still present on the web in 
X/HTML pages.  A post format would provide that metadata.

My annotation and context-sensitive copy work is at 
http://www.geof.net/code/annotation/, my blog includes some discussion 
of the issues at http://www.geof.net/blog/category/annotation.

Geof

From limbo at speakeasy.net  Mon Jul 11 13:19:58 2005
From: limbo at speakeasy.net (Eran)
Date: Mon Jul 11 13:09:41 2005
Subject: [microformats-discuss] Hello & blog post format
In-Reply-To: <42D2C6BB.7000702@geof.net>
Message-ID: <03ac01c58655$e9395d00$6564a8c0@hellonwheels>

Hi Geof.

I've been thinking of putting some suggestions on blog post formats as
part of the citeRel proposition (at the very least a container, so that
we know what is a single post object) but I do believe it's  out of the
scope of that format. A separate format for blog posts (and maybe other
types of posts) would help immensly in tracking blog conversations.

For some information on citation formatting see:
http://microformats.org/wiki/citation-brainstorming

Eran.

> -----Original Message-----
> From: microformats-discuss-bounces@microformats.org 
> [mailto:microformats-discuss-bounces@microformats.org] On 
> Behalf Of Geoffrey Glass
> Sent: Monday, July 11, 2005 12:22 PM
> To: microformats-discuss@microformats.org
> Subject: [microformats-discuss] Hello & blog post format
> 
> 
> Hello,
> 
> I just joined the list.  The archive seems to be down or 
> non-existent, 
> so you'll have to forgive me if I haven't a clue.
> 
> I am interested in a microformat for blog and forum posts.  I 
> have been 
> working on an web annotation tool for web forums which needs 
> to be able 
> to find individual posts in a discussion forum in order to 
> annotate them 
> and record metadata (title, author, post date, permalink).  I found 
> myself moving towards microformat-style markup, then discovered this 
> effort.
> 
> Another part of the project is collecting metadata along with content 
> when a user perfoms a copy-paste operation from a post.  So, for 
> example, the copy operation could automatically prefix with 
> the title, 
> author, and date of the post.  For example:
> 
>  From Online Discussion in Education by Cindy Xin on 16 June 
> 2005: Online discussion in education is a paradox.
> 
> I see the current discussion about RelSource addresses how 
> this should 
> be formatted.  My main concern is with how to extract the 
> title, author, 
> etc. in the first place.  I have a Javascript hack which does this 
> automatically on Firefox, but it's a nasty hack.  A clean solution 
> requires a browser extension - which would be relatively 
> useless without 
> a standard.
> 
> It may clarify to show what I'm doing at the moment.  The class names 
> (post excepted) match tag names in the Atom spec. T is any tag:
> 
> <T class="post" id="id">
>  <T class="title">title</T>
>  <T class="author>author name</T>
>  <abbr class="created" title="iso date">human-readable 
> date</abbr>  <a href="permalink">...</a>  <T 
> class="content">post body</T> </T>
> 
> The other major use I have been thinking about has probably been 
> discussed.  Search engines can't discover metadata that has 
> expired from 
> RSS or Atom syndication feeds, but which is still present on 
> the web in 
> X/HTML pages.  A post format would provide that metadata.
> 
> My annotation and context-sensitive copy work is at 
> http://www.geof.net/code/annotation/, my blog includes some 
> discussion 
> of the issues at http://www.geof.net/blog/category/annotation.
> 
> Geof
> 
> _______________________________________________
> microformats-discuss mailing list 
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 

From julian_bond at voidstar.com  Mon Jul 11 14:19:50 2005
From: julian_bond at voidstar.com (Julian Bond)
Date: Mon Jul 11 14:10:24 2005
Subject: [microformats-discuss] Two usage scenarios
In-Reply-To: <BEF7DD83.5CCAE%tantek@cs.stanford.edu>
References: <J7erqTC8jj0CFAwL@jblaptop.voidstar.com>
	<BEF7DD83.5CCAE%tantek@cs.stanford.edu>
Message-ID: <$W82BjD2Ju0CFAld@jblaptop.voidstar.com>

Tantek ?elik <tantek@cs.stanford.edu> Mon, 11 Jul 2005 08:27:11
>Do you have a URL to pages where you have event data right now so we can
>take a look?

The next Ecademy event
http://www.ecademy.com/module.php?mod=meeting&mid=6199


>> 2) I'd like to start putting hCard data into our member profiles.
>Example URL?

My profile
http://www.ecademy.com/account.php?id=1
My Vcard
http://www.ecademy.com/module.php?mod=network&op=vcard&uid=1
My FOAF
http://www.ecademy.com/module.php?mod=network&op=foafrdf&uid=1

If you were logged in you'd see rather more data. Which does raise some 
privacy issues.

>Let the folks here give it a shot.  Provide a URL to the human readable
>version and we'll see what folks come up with.

See above.

-- 
Julian Bond E&MSN: julian_bond at voidstar.com  M: +44 (0)77 5907 2173
Webmaster:             http://www.ecademy.com/  T: +44 (0)192 0412 433
Personal WebLog:      http://www.voidstar.com/  S: callto://julian.bond
                      *** Just Say No To DRM ***

From ryan at technorati.com  Mon Jul 11 15:14:46 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Jul 11 15:04:31 2005
Subject: [microformats-discuss] Two usage scenarios
In-Reply-To: <$W82BjD2Ju0CFAld@jblaptop.voidstar.com>
References: <J7erqTC8jj0CFAwL@jblaptop.voidstar.com>
	<BEF7DD83.5CCAE%tantek@cs.stanford.edu>
	<$W82BjD2Ju0CFAld@jblaptop.voidstar.com>
Message-ID: <551A00F0-58EC-4969-8456-7E47BBAC75A4@technorati.com>

On Jul 11, 2005, at 2:19 PM, Julian Bond wrote:
> Tantek ?elik <tantek@cs.stanford.edu> Mon, 11 Jul 2005 08:27:11
>
>> Do you have a URL to pages where you have event data right now so  
>> we can
>> take a look?
>
> The next Ecademy event
> http://www.ecademy.com/module.php?mod=meeting&mid=6199

Here's a possible way to hCal-ify this.

Caveats:
1.some liberties taken with the markup so that it will be semi- 
readable here.
2.Styles not preserved.
3.UTC assumed
4. I probably made a mistake somewhere. Feel free to correct me. :-)

<div class="vcalendar">
<h1 class="summary">Ecademy Event</h1>

<h2>When:</h2>
<abbr title="2005-0907T1800Z" class="dtstart">Wednesday, 7 September  
- 6:00pm</abbr> to
<abbr class="dtend" title="2005-0907T2230Z">10:30pm</abbr>

<h2>Where:</h2>

<span class="location vcard">
   <a href="..." class="fn n org">Marriott Hotel Marble Arch</a>,
   <span class="adr">
     <span class="street-address">134 George Street</span>,
     <span class="locality">London</span>,
     <span class="postal-code">W1H 5DN</span>,

     <a href="...">Map</a>, <br />
     <span class="note">Nearest Tube station: Marble Arch, W1H 5DN,  
UK, <a href="http://maps.google.co.uk/maps?q=W1H 5DN"  
target="new">Map</a></span>

</span>

<h2>Organizer:</h2>
<!-- not completely sure on this one -->
   <a class="organizer vcard url" href=".." title="..."  ><span  
class="fn n">Sophia Watkins</span></a>

<h2>Registered:</h2>
<!-- could use attendees element here, if this were public -->

You need to be a member to register. <a href="...">Join here</a><br / 
 ><b><a href="module.php? 
mod=meeting&op=attendee&mid=6199">Attendees:</a> </b> 59<br /><br />

<h2>Description:</h2>
<div class="description">
   <p><strong><a href="...">REGISTER HERE</a></strong></p>
   <p><strong>Ecademy Networking Event - <a href="...">Paul Sherman</ 
a>, <a href="...">Leon Benjamin</a> & <a href="...">Thomas Power </ 
a></strong></p>
   <p><strong>Admission is free of charge to all <img src="...">Power  
Networkers and ?20 on the door for all other attendees</strong></p>
   Click to become a <img src="...">Power Networker:<br />
   <a href="...">http://www.ecademy.com/node.php?id=9313</a><br />

   <h3>Agenda:</h3>
   <ol>
     <li>6.00 - 7.30 Ecademist Networking</li>
     <li>7.30 - 7.45 Ecademy Announcements</li>
     <li>7.45 - 8.30 Paul Sherman, Leon Benjamin & Thomas Power</li>
     <li>8.00 - 8.45 Questions from the floor</li>
     <li>9.00 - 10.30 Ecademist Networking</li>
   </ol>
   <p>Please note these meetings are restricted to Ecademists  
(members of Ecademy). If you have friends or colleagues who wish to  
attend please ask them to join Ecademy BEFORE the event here: <a  
href="http://www.ecademy.com/account.php?op=signup">http:// 
www.ecademy.com/account.php?op=signup</a></p>

   <p>Details on <img src="...">Power Networker services are here:</p>
   <p><a href="...">http://www.ecademy.com/node.php?title=Power 
+Networker</a></p>
</div>
</div>


From nancy_tubbs at fullcalendar.com  Mon Jul 11 15:37:52 2005
From: nancy_tubbs at fullcalendar.com (Nancy Tubbs)
Date: Mon Jul 11 15:28:39 2005
Subject: [microformats-discuss] Tag Tuesday tomorrow?
In-Reply-To: <42D2C6BB.7000702@geof.net>
Message-ID: <GAEEIIOFDEIDBOFHNJKLCECFGKAA.nancy_tubbs@fullcalendar.com>

I know this isn't the right place to ask, but I'm not sure where is: is
there a Tag Tuesday tomorrow?

Thanks,
Nancy

From ryan at technorati.com  Mon Jul 11 15:40:04 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Jul 11 15:29:44 2005
Subject: [microformats-discuss] Tag Tuesday tomorrow?
In-Reply-To: <GAEEIIOFDEIDBOFHNJKLCECFGKAA.nancy_tubbs@fullcalendar.com>
References: <GAEEIIOFDEIDBOFHNJKLCECFGKAA.nancy_tubbs@fullcalendar.com>
Message-ID: <626656F1-0EE6-4C66-804E-0D401E6A3931@technorati.com>

Nope. Scheduled for July 26th, location TBD.

-ryan

On Jul 11, 2005, at 3:37 PM, Nancy Tubbs wrote:

> I know this isn't the right place to ask, but I'm not sure where  
> is: is
> there a Tag Tuesday tomorrow?
>
> Thanks,
> Nancy
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http

From skeltoac at gmail.com  Tue Jul 12 06:42:41 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Tue Jul 12 06:33:02 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <1CF404A2-EBFB-4B23-8213-6EF136B038BF@technorati.com>
References: <BEF7DB19.5CCA9%tantek@cs.stanford.edu>
	<2E22094D-0AA8-4E4C-AD48-505BE1890B64@technorati.com>
	<1CF404A2-EBFB-4B23-8213-6EF136B038BF@technorati.com>
Message-ID: <e6ec604d050712064234e1d3d3@mail.gmail.com>

It should have come to attention sooner but I dug around W3C.org and
found that rel="cite" is already defined in the XHTML 2.0 Hypertext
Attribute Collection
(http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html).

Also from that collection, href and cite attributes are defined and
may coexist but they behave differently: The href attribute "specifies
a URI that is actuated when the element is activated." For the cite
attribute, "User Agents MUST provide a means for the user to actuate
the link."

In light of this, I see no reason to pursue a microformat for source
links/citations/hat tips. If authors adopt rel="cite" they are
preemptively applying a well-defined, semantic model that is both
user-friendly and easily parsed by machines.

The subject of distributed discussion and markup indicating replies,
updates, etc., is discussed at
http://microformats.org/wiki/citation-brainstorming.

Thank you,
Andy
From bud at thecommunityengine.com  Tue Jul 12 07:55:19 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 12 07:44:49 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d050712064234e1d3d3@mail.gmail.com>
References: <BEF7DB19.5CCA9%tantek@cs.stanford.edu>
	<2E22094D-0AA8-4E4C-AD48-505BE1890B64@technorati.com>
	<1CF404A2-EBFB-4B23-8213-6EF136B038BF@technorati.com>
	<e6ec604d050712064234e1d3d3@mail.gmail.com>
Message-ID: <02592647-1402-4D3B-8F1F-A3EA3ABAB553@thecommunityengine.com>

Does this really clear up who is an original source or not?  It just  
shows you are citing someone else.  They could be original or not.

Also, it does not help with the citation chain.  For instance, you  
may be citing an original source that you found out about through  
some other cite.  I personally almost never do that, but others do.

Just 2 cents.

Bud
On Jul 12, 2005, at 9:42, Andy Skelton wrote:

> It should have come to attention sooner but I dug around W3C.org and
> found that rel="cite" is already defined in the XHTML 2.0 Hypertext
> Attribute Collection
> (http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html).
>
> Also from that collection, href and cite attributes are defined and
> may coexist but they behave differently: The href attribute "specifies
> a URI that is actuated when the element is activated." For the cite
> attribute, "User Agents MUST provide a means for the user to actuate
> the link."
>
> In light of this, I see no reason to pursue a microformat for source
> links/citations/hat tips. If authors adopt rel="cite" they are
> preemptively applying a well-defined, semantic model that is both
> user-friendly and easily parsed by machines.
>
> The subject of distributed discussion and markup indicating replies,
> updates, etc., is discussed at
> http://microformats.org/wiki/citation-brainstorming.
>
> Thank you,
> Andy
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From tantek at cs.stanford.edu  Tue Jul 12 08:04:08 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 12 07:53:41 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d050712064234e1d3d3@mail.gmail.com>
Message-ID: <BEF929F6.5CDF1%tantek@cs.stanford.edu>

Hi Andy,

On 7/12/05 6:42 AM, "Andy Skelton" <skeltoac@gmail.com> wrote:

> It should have come to attention sooner but I dug around W3C.org and
> found that rel="cite" is already defined in the XHTML 2.0 Hypertext
> Attribute Collection
> (http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html).

That is a *really* interesting observation that implies something a bit
more.

One of the principles of microformats is reuse.

And even though XHTML2 is far from *done*, and is far from achieving
widespread interoperable adoption (if it ever does), I can see a good point
being made to reuse 'rel' values from XHTML2 to mean the same thing in
HTML4/XHTML1.


> Also from that collection, href and cite attributes are defined and
> may coexist but they behave differently: The href attribute "specifies
> a URI that is actuated when the element is activated." For the cite
> attribute, "User Agents MUST provide a means for the user to actuate
> the link."

That's less interesting.  For reasons of validity, we must use href and cite
attributes only on the elements that have them in HTML4/XHTML1.


> In light of this, I see no reason to pursue a microformat for source
> links/citations/hat tips. If authors adopt rel="cite" they are
> preemptively applying a well-defined, semantic model that is both
> user-friendly and easily parsed by machines.

I see the conclusion as quite the opposite.  Because rel="cite" *is* defined
in XHTML2 drafts, and microformats allow you add rel values to HTML4/XHTML1
*now*, adopting the same convention makes a lot of sense.

If anything it bolsters the case for rel="cite" (as opposed to some other
value like rel="source").

> The subject of distributed discussion and markup indicating replies,
> updates, etc., is discussed at
> http://microformats.org/wiki/citation-brainstorming.

Very good.  I've added my point to the end of that document as well.

Thanks Andy,

Tantek

From ryan at technorati.com  Tue Jul 12 08:09:15 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 07:58:48 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d050712064234e1d3d3@mail.gmail.com>
References: <BEF7DB19.5CCA9%tantek@cs.stanford.edu>
	<2E22094D-0AA8-4E4C-AD48-505BE1890B64@technorati.com>
	<1CF404A2-EBFB-4B23-8213-6EF136B038BF@technorati.com>
	<e6ec604d050712064234e1d3d3@mail.gmail.com>
Message-ID: <05BC9E32-739F-4A8C-AA70-2684C00FAD52@technorati.com>

On Jul 12, 2005, at 6:42 AM, Andy Skelton wrote:

> It should have come to attention sooner but I dug around W3C.org and
> found that rel="cite" is already defined in the XHTML 2.0 Hypertext
> Attribute Collection
> (http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html).

Right, but XHTML 2 is by no means supported anywhere.

> Also from that collection, href and cite attributes are defined and
> may coexist but they behave differently: The href attribute "specifies
> a URI that is actuated when the element is activated." For the cite
> attribute, "User Agents MUST provide a means for the user to actuate
> the link."
>
> In light of this, I see no reason to pursue a microformat for source
> links/citations/hat tips. If authors adopt rel="cite" they are
> preemptively applying a well-defined, semantic model that is both
> user-friendly and easily parsed by machines.

Seeing as XHTML is not supported yet, I think there's room for an  
intermediate solution. Eran meantions in this post http:// 
hellonline.com/blog/?p=18 the fact that what's being proposed could  
be done more easily in XHTML 2.

-ryan

> The subject of distributed discussion and markup indicating replies,
> updates, etc., is discussed at
> http://microformats.org/wiki/citation-brainstorming.
>
> Thank you,
> Andy
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> htt

From ryan at technorati.com  Tue Jul 12 08:12:59 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 08:02:30 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <BEF929F6.5CDF1%tantek@cs.stanford.edu>
References: <BEF929F6.5CDF1%tantek@cs.stanford.edu>
Message-ID: <13B9C07A-A7AF-4BD4-B883-A2FFE43F52B4@technorati.com>

On Jul 12, 2005, at 8:04 AM, Tantek ?elik wrote:
> Hi Andy,
>
> On 7/12/05 6:42 AM, "Andy Skelton" <skeltoac@gmail.com> wrote:
>
>
>> It should have come to attention sooner but I dug around W3C.org and
>> found that rel="cite" is already defined in the XHTML 2.0 Hypertext
>> Attribute Collection
>> (http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html).
>
> That is a *really* interesting observation that implies something a  
> bit
> more.
>
> One of the principles of microformats is reuse.
>
> And even though XHTML2 is far from *done*, and is far from achieving
> widespread interoperable adoption (if it ever does), I can see a  
> good point
> being made to reuse 'rel' values from XHTML2 to mean the same thing in
> HTML4/XHTML1.

That's one of the ideas behind citeRel <http://hellonline.com/blog/? 
p=18>. Of course, when we first started talking about it, we didn't  
know about the XHTML 2 development.

-ryan

From skeltoac at gmail.com  Tue Jul 12 08:33:12 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Tue Jul 12 08:23:38 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <BEF929F6.5CDF1%tantek@cs.stanford.edu>
References: <e6ec604d050712064234e1d3d3@mail.gmail.com>
	<BEF929F6.5CDF1%tantek@cs.stanford.edu>
Message-ID: <e6ec604d0507120833274fbc24@mail.gmail.com>

On 7/12/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> > In light of this, I see no reason to pursue a microformat for source
> > links/citations/hat tips. If authors adopt rel="cite" they are
> > preemptively applying a well-defined, semantic model that is both
> > user-friendly and easily parsed by machines.
> 
> I see the conclusion as quite the opposite.  Because rel="cite" *is* defined
> in XHTML2 drafts, and microformats allow you add rel values to HTML4/XHTML1
> *now*, adopting the same convention makes a lot of sense.
> 
> If anything it bolsters the case for rel="cite" (as opposed to some other
> value like rel="source").

Oops, that was the exact point I was trying to make. I *do* plan to
adopt and promote rel="cite" but I don't see a need to go through the
hooplah of defining it as a microformat. Or am I missing something?

As for whether people /should/ indicate primary sources differently
than non-primary sources, i.e. hat tips, consider the definition of
the word /cite/:
"to quote or refer to as a precedent or authority"
(Merriam-Webster's Dictionary of Law, (c) 1996 Merriam-Webster, Inc.)
With that in mind, it would not be incorrect to cite both the primary
source (authority) and a hat tip or "via" (precedent) with the same
markup.

Robots can construct "citation chains" to discover a likely primary
source if a standard markup is used. The position of any resource
relative to Primary on a chain could be of great value to search
engines. It was this idea that excited me to propose RelSource in the
first place. I'm just as happy with RelCite.

Andy
From bud at thecommunityengine.com  Tue Jul 12 09:20:46 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 12 09:10:15 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d0507120833274fbc24@mail.gmail.com>
References: <e6ec604d050712064234e1d3d3@mail.gmail.com>
	<BEF929F6.5CDF1%tantek@cs.stanford.edu>
	<e6ec604d0507120833274fbc24@mail.gmail.com>
Message-ID: <D3451519-D817-44C6-A904-42E4DA8B7758@thecommunityengine.com>

On Jul 12, 2005, at 11:33, Andy Skelton wrote:

> Oops, that was the exact point I was trying to make. I *do* plan to
> adopt and promote rel="cite" but I don't see a need to go through the
> hooplah of defining it as a microformat. Or am I missing something?

I think the point is that the bigger format is not adopted yet and  
may never become a standard.  Therefore, the microformat can encode  
it now with a referenceable place on the web.

Of course, the microformat is now burdened with keeping up with the  
standard as it changes, not just the practices that revolve as a  
result of using the microformatted standard.  Perhaps a minor worry.

>
> As for whether people /should/ indicate primary sources differently
> than non-primary sources, i.e. hat tips, consider the definition of
> the word /cite/:
> "to quote or refer to as a precedent or authority"
> (Merriam-Webster's Dictionary of Law, (c) 1996 Merriam-Webster, Inc.)
> With that in mind, it would not be incorrect to cite both the primary
> source (authority) and a hat tip or "via" (precedent) with the same
> markup.

Tantek has a good counterexample here.  He adds comment links to his  
post by hand based on them showing up in technorati linking to him.   
Using a time of update heuristic, one could find Tantek's linking to  
comments as placing his post in the chain after people who commented  
on his post.

The example suggests that more structured markup could help.

There is still the question of how you determine the initial source,  
but I am not sure that is really of much practical concern.

The chain of precedence, however, is important for figuring out  
chains of influence for companies who want to influence bloggers.

>
> Robots can construct "citation chains" to discover a likely primary
> source if a standard markup is used. The position of any resource
> relative to Primary on a chain could be of great value to search
> engines. It was this idea that excited me to propose RelSource in the
> first place. I'm just as happy with RelCite.
>

From ryan at technorati.com  Tue Jul 12 09:35:51 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 09:25:24 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d0507120833274fbc24@mail.gmail.com>
References: <e6ec604d050712064234e1d3d3@mail.gmail.com>
	<BEF929F6.5CDF1%tantek@cs.stanford.edu>
	<e6ec604d0507120833274fbc24@mail.gmail.com>
Message-ID: <2BB6D75E-8CC1-4194-A46D-2EDF3A946F4D@technorati.com>

On Jul 12, 2005, at 8:33 AM, Andy Skelton wrote:
>> If anything it bolsters the case for rel="cite" (as opposed to  
>> some other
>> value like rel="source").
>>
>
> Oops, that was the exact point I was trying to make. I *do* plan to
> adopt and promote rel="cite" but I don't see a need to go through the
> hooplah of defining it as a microformat. Or am I missing something?

Depends on how you define 'hooplah.'

A generalization of citeRel would be this:

The XHTML 2 fragment:

<cite rel="foo">

is equivalent to this is XHTML 1

<cite class="relfoo">

(or rel-foo, I dare not suggest caMel-case :))

Perhaps we should define this as a microformat before moving on,  
since it seems elemental.

(I'm ignoring the XHMLT 2.0 vs HTML 5 issue for now.)

> As for whether people /should/ indicate primary sources differently
> than non-primary sources, i.e. hat tips, consider the definition of
> the word /cite/:
> "to quote or refer to as a precedent or authority"
> (Merriam-Webster's Dictionary of Law, (c) 1996 Merriam-Webster, Inc.)
> With that in mind, it would not be incorrect to cite both the primary
> source (authority) and a hat tip or "via" (precedent) with the same
> markup.

Who cares whether people /should/, they already /do/. We just trying  
to put a little structure to what people already do.


> Robots can construct "citation chains" to discover a likely primary
> source if a standard markup is used.

Right, but its a real bitch to do so.

It was done here http://www.hpl.hp.com/research/idl/papers/blogs/.  
And I've seen Adar give a talk about it and the majority of their  
work was making inferences about the citation chain.

Now, we can't force anyone to put these structured citations in, but


> The position of any resource
> relative to Primary on a chain could be of great value to search
> engines. It was this idea that excited me to propose RelSource in the
> first place. I'm just as happy with RelCite.

It's all good.

-ryan
From tantek at cs.stanford.edu  Tue Jul 12 09:45:58 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 12 09:35:40 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <02592647-1402-4D3B-8F1F-A3EA3ABAB553@thecommunityengine.com>
Message-ID: <BEF93679.5CDFE%tantek@cs.stanford.edu>

Good points Bud.

On 7/12/05 7:55 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> Does this really clear up who is an original source or not?  It just
> shows you are citing someone else.  They could be original or not.

There is also the question of whether you can actually tell when blogging
what someone else (even a PR News etc. source) said, whether  they are the
original source or not.

> Also, it does not help with the citation chain.  For instance, you
> may be citing an original source that you found out about through
> some other cite.  I personally almost never do that, but others do.

I see lots of examples of citation chains on blogs.

So yes, rel="cite" does not solve the citation chain problem.

Since these examples of citation chains on blogs are typically ordered, e.g.

 c via b via a

It may make sense to use an ordered list.

Then the only question remains as to how to represent that the list is a
chain.

> Just 2 cents.

I'll take that kind of cents anytime.

Tantek


> On Jul 12, 2005, at 9:42, Andy Skelton wrote:
> 
>> It should have come to attention sooner but I dug around W3C.org and
>> found that rel="cite" is already defined in the XHTML 2.0 Hypertext
>> Attribute Collection
>> (http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html).
>> 
>> Also from that collection, href and cite attributes are defined and
>> may coexist but they behave differently: The href attribute "specifies
>> a URI that is actuated when the element is activated." For the cite
>> attribute, "User Agents MUST provide a means for the user to actuate
>> the link."
>> 
>> In light of this, I see no reason to pursue a microformat for source
>> links/citations/hat tips. If authors adopt rel="cite" they are
>> preemptively applying a well-defined, semantic model that is both
>> user-friendly and easily parsed by machines.
>> 
>> The subject of distributed discussion and markup indicating replies,
>> updates, etc., is discussed at
>> http://microformats.org/wiki/citation-brainstorming.
>> 
>> Thank you,
>> Andy
>> _______________________________________________
>> 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 skeltoac at gmail.com  Tue Jul 12 09:59:11 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Tue Jul 12 09:48:42 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <BEF93679.5CDFE%tantek@cs.stanford.edu>
References: <02592647-1402-4D3B-8F1F-A3EA3ABAB553@thecommunityengine.com>
	<BEF93679.5CDFE%tantek@cs.stanford.edu>
Message-ID: <e6ec604d0507120959273c9f67@mail.gmail.com>

On 7/12/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
<< snip >>
> I see lots of examples of citation chains on blogs.
> So yes, rel="cite" does not solve the citation chain problem.
> Since these examples of citation chains on blogs are typically ordered, e.g.
>  c via b via a
> It may make sense to use an ordered list.
> Then the only question remains as to how to represent that the list is a
> chain.

Citing one's reference's references may be strictly proper to some
minds but to me it seems an undue burden on the author. With wide
acceptance, the practice of citing one degree of reference will
provide sufficient interlinking to enable a spider to infer a
reasonably accurate citation chain.

Trying to squash an Ad Infinitum between two pennies,
Andy
From danny.ayers at gmail.com  Tue Jul 12 10:42:33 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 10:32:04 2005
Subject: [microformats-discuss] hTest
Message-ID: <1f2ed5cd05071210426498a762@mail.gmail.com>

An idea I'd appreciate a little sanity checking on -

In brief:

* Microformats [1] are a way of making data explicit in human-readable XHTML
* Fitnesse [2] is a software testing tool, based on describing test
data on a Wiki
* DOAP [3] is Description of a Project, an RDF vocabulary for machine
readable descriptions of software projects

So why not construct a little vocabulary to extend what's already in
DOAP to describe tests? The vocabulary could be expressed as a
microformat (so it could appear on Wikis a la Fitnesse) but would also
be available for arbitrary machine processing via RDF.

I've already played around with mapping between DOAP expressed as
RDF/XML and as XHTML (hDOAP, see [4]). It works quite nicely, the
XHTML being human-presentable, with a GRDDL-disambiguated [5] XSLT to
transform it into directly machine-processable RDF/XML.

The RDF in [3] provides a common data model, meaning that data from
one source is easy to integrate with that from another, such as
personal profiles (FOAF), event information (iCal/RDF), or blog posts
(RSS), or just about anything else. The triplestore offers a very
agile approach to data storage and query (via SPARQL [6]), you don't
have to worry about building schemas in advance.
  
I got to wondering about this as although I'm a big fan of agile
technologies, I've still managed to let the thing I'm working [7] on
grow fairly sizeable without having any proper tests in place. Because
I've got an RDF store in the background, it would make sense for me to
use this for managing tests. On the one hand it'll be easy enough to
set up Wiki-like content management, on the other it's relatively
straightforward to build declarative, rule-based processing on RDF
(there's RDF/OWL inference and rule engines available).

I'm on the thin ice of my knowledge in many places here, so I thought
I'd run this by Folks That Know About These Things before going any
further.

Cheers,
Danny.


[1] http://microformats.org
[2] http://fitnesse.org
[3] http://usefulinc.com/doap
[4] http://purl.org/stuff/hdoap/profile
[5] http://www.w3.org/2004/01/rdxh/spec
[6] http://www.w3.org/TR/rdf-sparql-query/
[7] http://pragmatron.org/docs/sparqlsphere.html
-- 

http://dannyayers.com
From tjameswhite at yahoo.com  Tue Jul 12 11:17:24 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Tue Jul 12 11:06:55 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <20050712173204.C5CF6F0864C@microformats>
Message-ID: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>


Andy said:
"Citing one's reference's references may be strictly proper to some
minds but to me it seems an undue burden on the author. With wide
acceptance, the practice of citing one degree of reference will
provide sufficient interlinking to enable a spider to infer a
reasonably accurate citation chain.

Trying to squash an Ad Infinitum between two pennies,
Andy"

I've got to agree with Andy, I don't know of anybody who cites a
reference's reference. (I'm sure it happens, just not in my circle.) It
would be most proper to cite the primary source, but barring that you
should only worry about citing the reference you are talking about.

Just look at the threads of this message over time -- I'm only
referencing Andy, not all of the previous threads, as has pretty much
everyone else.

Just my view from the sidelines.

(While most of this seems to be talking about blog-to-blog style
conversations, it has some parallel to ideas I have about the cite
element in general and whether a microformat is in order for books,
movies, et al. When I get some time I'll try to post my thoughts in
general for commentary.)



~ 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>


		
____________________________________________________
Sell on Yahoo! Auctions ? no fees. Bid on great items.  
http://auctions.yahoo.com/
From limbo at speakeasy.net  Tue Jul 12 11:26:34 2005
From: limbo at speakeasy.net (Eran)
Date: Tue Jul 12 11:16:14 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
Message-ID: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>

Tim said:
> I've got to agree with Andy, I don't know of anybody who 
> cites a reference's reference. (I'm sure it happens, just not 

I think it's actually quite common in the blogosphere. Consider the case
where Ryan might quote a blog post made by tantek. I read Ryan's post
but would like to respond to Tantek's opinions. The markup would be
something like so:

---- * ----
<cite class="revreplyto"><a
href="http://tantek.com/interesting-blog-post">Tantek said:</a></cite>
<blockquote>
Quoting from Tantek's post here...
</blockquote>

Blah blah blah... 

Via: <cite class="relvia"><a
href="http://theryanking.com/blog/blog-post-i-read">Ryan King</a></cite>
---- * ----

From porter at bokardo.com  Tue Jul 12 11:41:56 2005
From: porter at bokardo.com (Joshua Porter)
Date: Tue Jul 12 11:31:28 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
Message-ID: <58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>

In trying to understand why I should, as a developer, produce  
microformat code, I realized that I don't know how to find out which  
sites use microformats and which don't.  (Tantek's pointer on  
microformats.org the other day reminded me of this)

How would I (or my browsing/aggregating software) discover that a  
site is using microformats?

Thanks,

josh

From skeltoac at gmail.com  Tue Jul 12 12:12:58 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Tue Jul 12 12:02:28 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
	<003201c5870f$3c1140b0$6464a8c0@hellonwheels>
Message-ID: <e6ec604d0507121212558d8c05@mail.gmail.com>

I have drafted a spec for a very simple citation microformat after
study of some other specs on mf.org.
http://microformats.org/wiki/User:Skeltoac/RelCite

It does not classify relationships such as "reply" or "via" as
proposed by Eran but it does capitalize on the directional quality of
a citation by adding rel="cite" and rev="cite" to hyperlinks.

For example, consider a Pingback. A blogger generates a favorable
article citing one of your articles. He writes < a href="foo"
rel="cite vote-for">foo< /a> and your blog is notified via pingback.
If your blog reacts by generating a comment with a hyperlink back to
his article, it should be < a href="bar" rev="cite">bar< /a>.

Andy
From ryan at technorati.com  Tue Jul 12 12:32:02 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 12:21:34 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
Message-ID: <44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>

On Jul 12, 2005, at 11:41 AM, Joshua Porter wrote:

> In trying to understand why I should, as a developer, produce  
> microformat code, I realized that I don't know how to find out  
> which sites use microformats and which don't.  (Tantek's pointer on  
> microformats.org the other day reminded me of this)
>
> How would I (or my browsing/aggregating software) discover that a  
> site is using microformats?

A couple of ways:

1. You could tell it that there are microformats there. :)
2. The UA could parse the page, looking for microformats that it  
knows about.
3. Profile URL- microformats can have a profile url, which is in the  
profile attribute of the head element.

spec: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4
example:http://gmpg.org/xmdp/description

-ryan

> Thanks,
>
> josh
From danny.ayers at gmail.com  Tue Jul 12 12:35:42 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 12:25:12 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <e6ec604d0507121212558d8c05@mail.gmail.com>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
	<003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<e6ec604d0507121212558d8c05@mail.gmail.com>
Message-ID: <1f2ed5cd050712123539642826@mail.gmail.com>

Sorry, I'm arriving late to the party - I missed this list when I
first looked at microformats.org

Anyhow given the microformat credo of building on existing standards,
I thought it worth mentioning that there was considerable discussion
of useful values for a "rel" attribute over on the Atom list/wiki,
specifically for the <link> element. The decision was made to endorse
by IANA registration five initial values (alternate, related, self,
enclosure, via), but to also allow unregistered values that could be
specificied using an IRI. (The registered values would be considered
equivalent to the IRIs formed by the names preceded by
http://www.iana.org/assignments/relation/).

The general feeling was that this offered a good compromise between a
(ever growing!) list of preset values and an openly-extensible
approach. Use of IRIs prevents naming clashes.

Cheers,
Danny.

http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-09.txt
4.2.7.2  The "rel" Attribute

Some background:
http://www.intertwingly.net/wiki/pie/PaceFieldingLinks



-- 

http://dannyayers.com
From danny.ayers at gmail.com  Tue Jul 12 12:39:34 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 12:29:06 2005
Subject: [microformats-discuss] list archives
Message-ID: <1f2ed5cd0507121239220c46d8@mail.gmail.com>

Can anyone please point me to them - the link on
http://microformats.org/mailman/listinfo/microformats-discuss/
is 404'ing.


-- 

http://dannyayers.com
From bud at thecommunityengine.com  Tue Jul 12 12:53:34 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 12 12:43:01 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
Message-ID: <1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>

I for one would like to reinforce that the profile mechanism is a  
good one and should be used more often.

Let me also take this opportunity to point out that the profile  
mechanism could be improved.  It requires that you use a profile  
attribute in the head element.  If you are creating a web page of  
harvested microformatted content or one where microformatted content  
is inserted by something like hCard creator, you typically do not  
have access to the head element.  What to do?  Perhaps we need to  
consider a use of the anchor <a> or some other element, i.e.,

<a href="profile.url" rel="profile">profile for microformat z</a>

contained in the inserted text.

I'm a little concerned with relying on UA parsing as the sole  
fallback.  It requires that the UA have an updated notion of what the  
microformats are.  How would that happen?  The profile mechanism  
seems easier.

Bud
On Jul 12, 2005, at 15:32, Ryan King wrote:

> On Jul 12, 2005, at 11:41 AM, Joshua Porter wrote:
>
>
>> In trying to understand why I should, as a developer, produce  
>> microformat code, I realized that I don't know how to find out  
>> which sites use microformats and which don't.  (Tantek's pointer  
>> on microformats.org the other day reminded me of this)
>>
>> How would I (or my browsing/aggregating software) discover that a  
>> site is using microformats?
>>
>
> A couple of ways:
>
> 1. You could tell it that there are microformats there. :)
> 2. The UA could parse the page, looking for microformats that it  
> knows about.
> 3. Profile URL- microformats can have a profile url, which is in  
> the profile attribute of the head element.
>
> spec: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4
> example:http://gmpg.org/xmdp/description
>
> -ryan
>
>
>> Thanks,
>>
>> josh
>>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From danny.ayers at gmail.com  Tue Jul 12 13:00:54 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 12:50:25 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
Message-ID: <1f2ed5cd0507121300666c1694@mail.gmail.com>

On 7/12/05, Bud Gibson <bud@thecommunityengine.com> wrote:
> I for one would like to reinforce that the profile mechanism is a
> good one and should be used more often.

Absolutely. It's the only way (so far) the data can be unambiguously
extracted, e.g. using GRDDL:
http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/
 
Perhaps we need to
> consider a use of the anchor <a> or some other element, i.e.,
> 
> <a href="profile.url" rel="profile">profile for microformat z</a>
> 
> contained in the inserted text.

What about <link  href="profile.url" rel="profile">? - it might be a
little less disruptive to regular rendering.

Cheers,
Danny.

-- 

http://dannyayers.com
From bud at thecommunityengine.com  Tue Jul 12 13:04:28 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 12 12:53:54 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
Message-ID: <CB0BEE35-3D3A-4D5A-AE3B-B357533987F8@thecommunityengine.com>

On Jul 12, 2005, at 14:17, Tim White wrote:

> "Citing one's reference's references may be strictly proper to some
> minds but to me it seems an undue burden on the author. With wide
> acceptance, the practice of citing one degree of reference will
> provide sufficient interlinking to enable a spider to infer a
> reasonably accurate citation chain.
>
> Trying to squash an Ad Infinitum between two pennies,
> Andy"
>
> I've got to agree with Andy, I don't know of anybody who cites a
> reference's reference. (I'm sure it happens, just not in my circle.)

I have to say, I would not do this either, but I saw Tim O'Reilly do  
it just the other day on the O'Reilly Radar when he cited Steve  
Mallet for passing a reference to him.

I suspect the real reason you see interest in this idea is that it  
would be commercially "exciting" to be able to reliably extract  
reference chains to help decipher chains of influence.   
Alternatively, it might be a way of charging people for content.  I  
spent time with a guy at SXSW this year who wanted to give  
intermediaries in decentralized music distribution a cut of the take  
for each song that was downloaded through them.  He had a business  
model built on this.  What's being talked about here is the same  
thing, just in social whuffie terms.

My personal recommendation to folks interested in this idea would be  
to work up the proposal and then see if there is an easy, feasible  
way for people to actually do it.  If not, keep it on the books and  
refer people to it every time it comes up.  See if they can find a way.

The real issue I think is creating a tenable value-proposition for  
the non-super-geek.

Bud
From bud at thecommunityengine.com  Tue Jul 12 13:06:28 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 12 12:55:53 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1f2ed5cd0507121300666c1694@mail.gmail.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<1f2ed5cd0507121300666c1694@mail.gmail.com>
Message-ID: <337C9CC5-3577-4A9B-B0F0-91D129374CD6@thecommunityengine.com>

On Jul 12, 2005, at 16:00, Danny Ayers wrote:

> What about <link  href="profile.url" rel="profile">? - it might be a
> little less disruptive to regular rendering.
>
> Cheers,
> Danny.

I agree that this sounds better.  Some in the community will object  
that it is invisible and therefore subject to abuse.  I suspect that  
that is not so likely here and would like to see open debate on it.

Bud

From mike at stamen.com  Tue Jul 12 13:08:55 2005
From: mike at stamen.com (Michal Migurski)
Date: Tue Jul 12 12:58:32 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
Message-ID: <9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>

> I'm a little concerned with relying on UA parsing as the sole  
> fallback.  It requires that the UA have an updated notion of what  
> the microformats are.  How would that happen?  The profile  
> mechanism seems easier.

Easier if you're writing code to parse microformats. Less easy if  
you're trying to generate them - a lot of blogging software does not  
make it simple to affect the document's HEAD based on the contents of  
the BODY by default. I use Blosxom, and it has no such abilities  
without using a dedicated plug-in.

I'd say that option #2 (UA could parse the page, looking for  
microformats that it knows about) is the only reasonable possibility  
in the context of the open web. Am I off base?

-mike.

----------------------------------------------------------------
michal migurski- mike@stamen.com
                  415.558.1610


From bud at thecommunityengine.com  Tue Jul 12 13:14:34 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 12 13:04:00 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>
Message-ID: <C5163AC9-E04A-4796-ABBE-F04FE5CFA745@thecommunityengine.com>

On Jul 12, 2005, at 16:08, Michal Migurski wrote:

> I'd say that option #2 (UA could parse the page, looking for  
> microformats that it knows about) is the only reasonable  
> possibility in the context of the open web. Am I off base?

Try this Ayer's idea by putting the link with the microformatted content

> Perhaps we need to
>
>> consider a use of the anchor <a> or some other element, i.e.,
>>
>> <a href="profile.url" rel="profile">profile for microformat z</a>
>>
>> contained in the inserted text.
>>
>
> What about <link  href="profile.url" rel="profile">? - it might be a
> little less disruptive to regular rendering.

Bud
From dougal at gunters.org  Tue Jul 12 13:18:35 2005
From: dougal at gunters.org (Dougal Campbell)
Date: Tue Jul 12 13:08:15 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1f2ed5cd0507121300666c1694@mail.gmail.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<1f2ed5cd0507121300666c1694@mail.gmail.com>
Message-ID: <42D4259B.8000208@gunters.org>

Danny Ayers wrote:
> What about <link  href="profile.url" rel="profile">? - it might be a
> little less disruptive to regular rendering.

The <link/> element is only allowed inside the <head/>, which is why 
<a/> was being suggested....

-- 
Dougal Campbell <dougal@gunters.org>
http://dougal.gunters.org/

From bud at thecommunityengine.com  Tue Jul 12 13:27:16 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 12 13:16:42 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <42D4259B.8000208@gunters.org>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<1f2ed5cd0507121300666c1694@mail.gmail.com>
	<42D4259B.8000208@gunters.org>
Message-ID: <34805382-0C25-4916-B87C-029B553C5A03@thecommunityengine.com>

On Jul 12, 2005, at 16:18, Dougal Campbell wrote:

> Danny Ayers wrote:
>
>> What about <link  href="profile.url" rel="profile">? - it might be a
>> little less disruptive to regular rendering.
>>
>
> The <link/> element is only allowed inside the <head/>, which is  
> why <a/> was being suggested....

Dougal, thanks for coming to my aid on principle even if I missed the  
principle myself :).

My main point is that I think there needs to be some way to provide a  
link to the profile that is outside of the head, similar to Mike  
Migurski's response to all of this.

Bud
From dougal at gunters.org  Tue Jul 12 13:32:47 2005
From: dougal at gunters.org (Dougal Campbell)
Date: Tue Jul 12 13:22:21 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <34805382-0C25-4916-B87C-029B553C5A03@thecommunityengine.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>	<1f2ed5cd0507121300666c1694@mail.gmail.com>	<42D4259B.8000208@gunters.org>
	<34805382-0C25-4916-B87C-029B553C5A03@thecommunityengine.com>
Message-ID: <42D428EF.2010906@gunters.org>

Bud Gibson wrote:
> On Jul 12, 2005, at 16:18, Dougal Campbell wrote:

> Dougal, thanks for coming to my aid on principle even if I missed the  
> principle myself :).
> 
> My main point is that I think there needs to be some way to provide a  
> link to the profile that is outside of the head, similar to Mike  
> Migurski's response to all of this.

Yeah, though I realized after the fact that I should have expanded my 
point a little more. Anyhow, a profile <link/> is definitely a good 
thing. But an inline alternative would be a welcome addition, I think.

And again, I should probably put more thought into this and contribute 
more to the conversation, but I'm about to shut down and hit the road, 
so I'll leave it to more able minds to hash out the details :)

-- 
Dougal Campbell <dougal@gunters.org>
http://dougal.gunters.org/

From lucas.gonze at gmail.com  Tue Jul 12 13:42:50 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Tue Jul 12 13:32:22 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>
Message-ID: <ab069aa0050712134252d1216e@mail.gmail.com>

On 7/12/05, Michal Migurski <mike@stamen.com> wrote:
> Easier if you're writing code to parse microformats. Less easy if
> you're trying to generate them - a lot of blogging software does not
> make it simple to affect the document's HEAD based on the contents of
> the BODY by default.

Good timing -- I butted up against this problem yesterday and meant to
post it here.

At the same time, the profiles+XMDP approach is pretty fundamental,
and I'd hate to lose the benefits.  Finding an way to do this in the
body is going to be a tough nut.  On the other hand, I suspect that
users who don't have access to the <head/> will just blow off the
profile, so we won't actually get the benefits.

- Lucas
From limbo at speakeasy.net  Tue Jul 12 13:53:27 2005
From: limbo at speakeasy.net (Eran)
Date: Tue Jul 12 13:42:58 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <CB0BEE35-3D3A-4D5A-AE3B-B357533987F8@thecommunityengine.com>
Message-ID: <004a01c58723$c0c94c30$6464a8c0@hellonwheels>


> The real issue I think is creating a tenable value-proposition for  
> the non-super-geek.
> 
> Bud

The alternative is building the feature into the tools. For example a
reBlogging tool that automatically embeds source attribution and
copyright information in the reBlogged content...

Eran.

From danny.ayers at gmail.com  Tue Jul 12 14:04:43 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 13:54:12 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <42D4259B.8000208@gunters.org>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<1f2ed5cd0507121300666c1694@mail.gmail.com>
	<42D4259B.8000208@gunters.org>
Message-ID: <1f2ed5cd05071214045f94fcce@mail.gmail.com>

On 7/12/05, Dougal Campbell <dougal@gunters.org> wrote:
> Danny Ayers wrote:
> > What about <link  href="profile.url" rel="profile">? - it might be a
> > little less disruptive to regular rendering.
> 
> The <link/> element is only allowed inside the <head/>, which is why
> <a/> was being suggested....

Ah right, missed that, thanks. 


-- 

http://dannyayers.com
From danny.ayers at gmail.com  Tue Jul 12 14:08:00 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 13:57:29 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <ab069aa0050712134252d1216e@mail.gmail.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>
	<ab069aa0050712134252d1216e@mail.gmail.com>
Message-ID: <1f2ed5cd050712140850af32f5@mail.gmail.com>

On 7/12/05, Lucas Gonze <lucas.gonze@gmail.com> wrote:
> On 7/12/05, Michal Migurski <mike@stamen.com> wrote:
> > Easier if you're writing code to parse microformats. Less easy if
> > you're trying to generate them - a lot of blogging software does not
> > make it simple to affect the document's HEAD based on the contents of
> > the BODY by default.
> 
> Good timing -- I butted up against this problem yesterday and meant to
> post it here.
> 
> At the same time, the profiles+XMDP approach is pretty fundamental,
> and I'd hate to lose the benefits.  

Just stepping back a second - I can see the benefit of having a
profile URI (to disambiguate the interpretation). What are the
benefits of the XMDP part - documentation? Or is anyone doing some
kind of processing with it?

Cheers,
Danny.
-- 

http://dannyayers.com
From ryan at technorati.com  Tue Jul 12 14:11:17 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 14:00:46 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <1f2ed5cd050712123539642826@mail.gmail.com>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
	<003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<e6ec604d0507121212558d8c05@mail.gmail.com>
	<1f2ed5cd050712123539642826@mail.gmail.com>
Message-ID: <37E2AC03-C67F-4616-BBE8-2144623D7B19@technorati.com>

On Jul 12, 2005, at 12:35 PM, Danny Ayers wrote:
> Sorry, I'm arriving late to the party - I missed this list when I
> first looked at microformats.org
>
> Anyhow given the microformat credo of building on existing standards,
> I thought it worth mentioning that there was considerable discussion
> of useful values for a "rel" attribute over on the Atom list/wiki,
> specifically for the <link> element. The decision was made to endorse
> by IANA registration five initial values (alternate, related, self,
> enclosure, via), but to also allow unregistered values that could be
> specificied using an IRI. (The registered values would be considered
> equivalent to the IRIs formed by the names preceded by
> http://www.iana.org/assignments/relation/).

It might be a good idea to map these values into html as-is (using  
atom as a normative reference).

-ryan

> The general feeling was that this offered a good compromise between a
> (ever growing!) list of preset values and an openly-extensible
> approach. Use of IRIs prevents naming clashes.
>
> Cheers,
> Danny.
>
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-09.txt
> 4.2.7.2  The "rel" Attribute
>
> Some background:
> http://www.intertwingly.net/wiki/pie/PaceFieldingLinks
>
>
>
> -- 
>
> http://dannyayers.com
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> ht

From porter at bokardo.com  Tue Jul 12 14:12:24 2005
From: porter at bokardo.com (Joshua Porter)
Date: Tue Jul 12 14:01:55 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
Message-ID: <8AECF1D0-BBCF-4A19-AFCC-3AF9FBF26F9C@bokardo.com>

Is it fair to say that microformats are no further along in auto- 
discovery than are standalone XML formats?

I ask because I'm confused about the "support" of microformats. I  
understand that microformats are "supported" by browsers in the sense  
that browsers read them as XHTML. But that's not really doing  
anything with the semantics we've added to our markup. (we might as  
well be writing in any arbitrary format).

Taken further, it seems to me that for anything to be done with  
microformats, our UAs will need to be updated in some fashion.  Of  
course, Technorati is supporting some of them already....but we don't  
want something that will be supported by only one vendor...and  
presumably Technorati would support another XML format, too.

Thus, microformats, to me, sound like just as much work as would be a  
separate format (like RSS). Indeed, many of the microformats are  
based on living formats written in plaintext or xml. So some are  
already developed...like iCal, xCal, and OPML.

Therefore, I wonder if there are some applications for which a  
separate format are better suited, and presumably some applications  
for which microformats are better suited.  Does anybody have a take  
on this?

However, I'm hearing this push about microformats...which is all well  
and good...but I don't know, as a developer, where I should *spend my  
time*.

A possible issue to address would be: should I provide OPML or XOXO?

josh





On Jul 12, 2005, at 3:32 PM, Ryan King wrote:

> On Jul 12, 2005, at 11:41 AM, Joshua Porter wrote:
>
>
>> In trying to understand why I should, as a developer, produce  
>> microformat code, I realized that I don't know how to find out  
>> which sites use microformats and which don't.  (Tantek's pointer  
>> on microformats.org the other day reminded me of this)
>>
>> How would I (or my browsing/aggregating software) discover that a  
>> site is using microformats?
>>
>
> A couple of ways:
>
> 1. You could tell it that there are microformats there. :)
> 2. The UA could parse the page, looking for microformats that it  
> knows about.
> 3. Profile URL- microformats can have a profile url, which is in  
> the profile attribute of the head element.
>
> spec: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4
> example:http://gmpg.org/xmdp/description
>
> -ryan
>
>
>> Thanks,
>>
>> josh
>>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From ryan at technorati.com  Tue Jul 12 14:13:46 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 14:03:19 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
Message-ID: <79609B17-39FF-42E7-83EF-1AD973896CE9@technorati.com>


On Jul 12, 2005, at 12:32 PM, Ryan King wrote:

> On Jul 12, 2005, at 11:41 AM, Joshua Porter wrote:
>
>
>> In trying to understand why I should, as a developer, produce  
>> microformat code, I realized that I don't know how to find out  
>> which sites use microformats and which don't.  (Tantek's pointer  
>> on microformats.org the other day reminded me of this)
>>
>> How would I (or my browsing/aggregating software) discover that a  
>> site is using microformats?

Actually, before getting into that, I should have asked: "What do you  
mean by 'auto-discovery'?" In other words, give us a particular use- 
case.

-ryan

>
> A couple of ways:
>
> 1. You could tell it that there are microformats there. :)
> 2. The UA could parse the page, looking for microformats that it  
> knows about.
> 3. Profile URL- microformats can have a profile url, which is in  
> the profile attribute of the head element.
>
> spec: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4
> example:http://gmpg.org/xmdp/description
>
> -ryan

From ryan at technorati.com  Tue Jul 12 14:17:50 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 14:07:29 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
Message-ID: <66C73C22-63E2-4005-AD2F-6C4B30C22B15@technorati.com>

On Jul 12, 2005, at 12:53 PM, Bud Gibson wrote:

> I for one would like to reinforce that the profile mechanism is a  
> good one and should be used more often.
>
> Let me also take this opportunity to point out that the profile  
> mechanism could be improved.  It requires that you use a profile  
> attribute in the head element.  If you are creating a web page of  
> harvested microformatted content or one where microformatted  
> content is inserted by something like hCard creator, you typically  
> do not have access to the head element.  What to do?  Perhaps we  
> need to consider a use of the anchor <a> or some other element, i.e.,

Bud-

It's not like we just made up the profile attribute as a way for  
referencing profiles- this stuff is in the html spec.

> <a href="profile.url" rel="profile">profile for microformat z</a>
>
> contained in the inserted text.
>
> I'm a little concerned with relying on UA parsing as the sole  
> fallback.  It requires that the UA have an updated notion of what  
> the microformats are.  How would that happen?  The profile  
> mechanism seems easier.

Yes, but the UA will need to know how to handle specific microformats  
before it can do so.

-ryan


> Bud
> On Jul 12, 2005, at 15:32, Ryan King wrote:
>
>
>> On Jul 12, 2005, at 11:41 AM, Joshua Porter wrote:
>>
>>
>>
>>> In trying to understand why I should, as a developer, produce  
>>> microformat code, I realized that I don't know how to find out  
>>> which sites use microformats and which don't.  (Tantek's pointer  
>>> on microformats.org the other day reminded me of this)
>>>
>>> How would I (or my browsing/aggregating software) discover that a  
>>> site is using microformats?
>>>
>>>
>>
>> A couple of ways:
>>
>> 1. You could tell it that there are microformats there. :)
>> 2. The UA could parse the page, looking for microformats that it  
>> knows about.
>> 3. Profile URL- microformats can have a profile url, which is in  
>> the profile attribute of the head element.
>>
>> spec: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4
>> example:http://gmpg.org/xmdp/description
>>
>> -ryan
>>
>>
>>
>>> Thanks,
>>>
>>> josh
>>>
>>>
>> _______________________________________________
>> 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 lucas.gonze at gmail.com  Tue Jul 12 14:22:01 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Tue Jul 12 14:11:43 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1f2ed5cd050712140850af32f5@mail.gmail.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>
	<ab069aa0050712134252d1216e@mail.gmail.com>
	<1f2ed5cd050712140850af32f5@mail.gmail.com>
Message-ID: <ab069aa0050712142274bc1514@mail.gmail.com>

On 7/12/05, Danny Ayers <danny.ayers@gmail.com> wrote:
> Just stepping back a second - I can see the benefit of having a
> profile URI (to disambiguate the interpretation). What are the
> benefits of the XMDP part - documentation? Or is anyone doing some
> kind of processing with it?

Just documentation, but that's worth a lot since fewer developers will
be morons in the http://diveintomark.org/archives/2004/08/16/specs
sense.

- Lucas
From porter at bokardo.com  Tue Jul 12 14:25:28 2005
From: porter at bokardo.com (Joshua Porter)
Date: Tue Jul 12 14:15:02 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <79609B17-39FF-42E7-83EF-1AD973896CE9@technorati.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<79609B17-39FF-42E7-83EF-1AD973896CE9@technorati.com>
Message-ID: <3073A207-C277-4570-95E2-4AEC5D28E122@bokardo.com>


On Jul 12, 2005, at 5:13 PM, Ryan King wrote:

>
> On Jul 12, 2005, at 12:32 PM, Ryan King wrote:
>
>
>> On Jul 12, 2005, at 11:41 AM, Joshua Porter wrote:
>>
>>
>>
>>> In trying to understand why I should, as a developer, produce  
>>> microformat code, I realized that I don't know how to find out  
>>> which sites use microformats and which don't.  (Tantek's pointer  
>>> on microformats.org the other day reminded me of this)
>>>
>>> How would I (or my browsing/aggregating software) discover that a  
>>> site is using microformats?
>>>
>
> Actually, before getting into that, I should have asked: "What do  
> you mean by 'auto-discovery'?" In other words, give us a particular  
> use-case.
>

Well, auto-discovery is only one way to discover, I shouldn't have  
used that as the subject. I wanted to know about discovery by either  
me *or* a UA.

A particular use-case would be like what I do with RSS in Safari or  
Firefox...I browse to a web site and I get notification that there is  
another format in play...

(The resulting discussion was exactly what I was looking for)

thanks,

josh

> -ryan
>
>
>>
>> A couple of ways:
>>
>> 1. You could tell it that there are microformats there. :)
>> 2. The UA could parse the page, looking for microformats that it  
>> knows about.
>> 3. Profile URL- microformats can have a profile url, which is in  
>> the profile attribute of the head element.
>>
>> spec: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4
>> example:http://gmpg.org/xmdp/description
>>
>> -ryan
>>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From danny.ayers at gmail.com  Tue Jul 12 14:54:36 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 14:44:05 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <8AECF1D0-BBCF-4A19-AFCC-3AF9FBF26F9C@bokardo.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<8AECF1D0-BBCF-4A19-AFCC-3AF9FBF26F9C@bokardo.com>
Message-ID: <1f2ed5cd0507121454cb0263e@mail.gmail.com>

On 7/12/05, Joshua Porter <porter@bokardo.com> wrote:

> Therefore, I wonder if there are some applications for which a
> separate format are better suited, and presumably some applications
> for which microformats are better suited.  Does anybody have a take
> on this?

I was originally very skeptical of the whole notion of microformats -
I mean, what do you need XFN (embedded) for when you've got FOAF
(linked)? But they've grown on me, and I do think there's a range of
applications for which they do make a lot of sense. As a rough
characterisation I'd guess:

* persistent
- because there are loads of things that you might e.g. want to put in
an RSS feed that you wouldn't necessarily want to hold onto forever on
a HTML page.

* having both human-readable (doc) and machine-readable (data)
components, with significant overlap
- I'd look for the overlap, because if you can avoid repeating
yourself that's usually a good thing. A lot of the time you could
generate both a human-readable and a machine readable representation
from the same source, e.g. a database producing a blog in HTML and
RSS. I'm not sure, but where there's more metadata than content it's
probably better separate, and vice versa (i.e.  in retrospect Really
Simple Syndication might have been simpler done completely as HTML).

* when it's easier that way
- a tricky one to judge - I think hReview works very well as a
microformat (even though I've personally done an RDF/XML format for
reviews), perhaps because it's simply structured. I suspect where
multiple vocabularies are needed then an external file may be more
appropriate.

Regarding tool support, PiggyBank is promising :
http://simile.mit.edu/piggy-bank/

> A possible issue to address would be: should I provide OPML or XOXO?

I've a heuristic for that too : What is the data you wish to provide?
For what purpose? If the answer to either question is "Radio Userland"
then the answer's OPML. Otherwise XOXO's probably a better bet.

Cheers,
Danny.

-- 

http://dannyayers.com
From ryan at technorati.com  Tue Jul 12 14:17:52 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 14:48:54 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <337C9CC5-3577-4A9B-B0F0-91D129374CD6@thecommunityengine.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<1f2ed5cd0507121300666c1694@mail.gmail.com>
	<337C9CC5-3577-4A9B-B0F0-91D129374CD6@thecommunityengine.com>
Message-ID: <05C5CA63-DD7D-4DA8-BF0C-71C145259517@technorati.com>

On Jul 12, 2005, at 1:06 PM, Bud Gibson wrote:
> On Jul 12, 2005, at 16:00, Danny Ayers wrote:
>
>> What about <link  href="profile.url" rel="profile">? - it might be a
>> little less disruptive to regular rendering.
>>
>> Cheers,
>> Danny.
>>
>
> I agree that this sounds better.  Some in the community will object  
> that it is invisible and therefore subject to abuse.  I suspect  
> that that is not so likely here and would like to see open debate  
> on it.

How could one abuse it?

-ryan
From danny.ayers at gmail.com  Tue Jul 12 14:59:39 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Tue Jul 12 14:49:08 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <3073A207-C277-4570-95E2-4AEC5D28E122@bokardo.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<79609B17-39FF-42E7-83EF-1AD973896CE9@technorati.com>
	<3073A207-C277-4570-95E2-4AEC5D28E122@bokardo.com>
Message-ID: <1f2ed5cd05071214592b3bf98@mail.gmail.com>

On 7/12/05, Joshua Porter <porter@bokardo.com> wrote:

> A particular use-case would be like what I do with RSS in Safari or
> Firefox...I browse to a web site and I get notification that there is
> another format in play...

Yep, check PiggyBank :
http://simile.mit.edu/piggy-bank/

I'm not sure which if any of the microformats are supported so far,
but the way the tool's built would make it ideal for them.
 
Cheers,
Danny.

-- 

http://dannyayers.com
From lucas.gonze at gmail.com  Tue Jul 12 15:06:48 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Tue Jul 12 14:56:17 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <37E2AC03-C67F-4616-BBE8-2144623D7B19@technorati.com>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
	<003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<e6ec604d0507121212558d8c05@mail.gmail.com>
	<1f2ed5cd050712123539642826@mail.gmail.com>
	<37E2AC03-C67F-4616-BBE8-2144623D7B19@technorati.com>
Message-ID: <ab069aa00507121506728a8e30@mail.gmail.com>

> On Jul 12, 2005, at 12:35 PM, Danny Ayers wrote:
> > Anyhow given the microformat credo of building on existing standards,
> > I thought it worth mentioning that there was considerable discussion
> > of useful values for a "rel" attribute over on the Atom list/wiki,
> > specifically for the <link> element. The decision was made to endorse
> > by IANA registration five initial values (alternate, related, self,
> > enclosure, via), but to also allow unregistered values that could be
> > specificied using an IRI. (The registered values would be considered
> > equivalent to the IRIs formed by the names preceded by
> > http://www.iana.org/assignments/relation/).
> 

On 7/12/05, Ryan King <ryan@technorati.com> wrote:
> It might be a good idea to map these values into html as-is (using
> atom as a normative reference).

I have always liked this bit of engineering by the Atom group.  It's
clean and decentralized, and keeps the explosion of rel values under
control in the long run.

So, amen.
From ryan at technorati.com  Tue Jul 12 15:48:50 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 16:40:12 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1f2ed5cd050712140850af32f5@mail.gmail.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<1C25C6B4-AB3B-4773-8244-9F5C3DD001FE@thecommunityengine.com>
	<9C7291FD-9178-411D-8375-6392E49617EB@stamen.com>
	<ab069aa0050712134252d1216e@mail.gmail.com>
	<1f2ed5cd050712140850af32f5@mail.gmail.com>
Message-ID: <8244713B-2098-42E4-99FE-2FCE0F65B251@technorati.com>

On Jul 12, 2005, at 2:08 PM, Danny Ayers wrote:
> On 7/12/05, Lucas Gonze <lucas.gonze@gmail.com> wrote:
>> On 7/12/05, Michal Migurski <mike@stamen.com> wrote:
>>> Easier if you're writing code to parse microformats. Less easy if
>>> you're trying to generate them - a lot of blogging software does not
>>> make it simple to affect the document's HEAD based on the  
>>> contents of
>>> the BODY by default.
>>
>> Good timing -- I butted up against this problem yesterday and  
>> meant to
>> post it here.
>>
>> At the same time, the profiles+XMDP approach is pretty fundamental,
>> and I'd hate to lose the benefits.
>
> Just stepping back a second - I can see the benefit of having a
> profile URI (to disambiguate the interpretation). What are the
> benefits of the XMDP part - documentation? Or is anyone doing some
> kind of processing with it?

I believe Brian Suda was working on a parser/validator for xmdp.

However, as I'm sure you've noticed, the real guts of an xmdp are the  
prose descriptions of the elements. So, just like other microformats,  
xmdp is for "humans first and machines second."

-ryan
From ryan at technorati.com  Tue Jul 12 15:31:34 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 16:40:13 2005
Subject: [microformats-discuss] list archives
In-Reply-To: <1f2ed5cd0507121239220c46d8@mail.gmail.com>
References: <1f2ed5cd0507121239220c46d8@mail.gmail.com>
Message-ID: <5B3726DB-8E50-434B-8B1E-DEFB7F284C76@technorati.com>

We haven't gotten them setup, hopefully soon.

-ryan

On Jul 12, 2005, at 12:39 PM, Danny Ayers wrote:

> Can anyone please point me to them - the link on
> http://microformats.org/mailman/listinfo/microformats-discuss/
> is 404'ing.
>
>
> -- 
>
> http://dannyayers.com
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From ryan at technorati.com  Tue Jul 12 15:46:46 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 12 16:40:13 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <8AECF1D0-BBCF-4A19-AFCC-3AF9FBF26F9C@bokardo.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
	<44C1AC61-B51C-4F59-AF64-D9CB35F09049@technorati.com>
	<8AECF1D0-BBCF-4A19-AFCC-3AF9FBF26F9C@bokardo.com>
Message-ID: <55D79271-F4EA-4139-9809-EBCAF08E4918@technorati.com>

On Jul 12, 2005, at 2:12 PM, Joshua Porter wrote:
> Is it fair to say that microformats are no further along in auto- 
> discovery than are standalone XML formats?

I still don't understand what you mean by "auto-discovery." Can you  
explain a specific case that you're imagining?

We need to ground this discussion in a real use case.

> I ask because I'm confused about the "support" of microformats. I  
> understand that microformats are "supported" by browsers in the  
> sense that browsers read them as XHTML. But that's not really doing  
> anything with the semantics we've added to our markup.

Right. Browsers aren't *currently* doing anything special with them.  
But there is certainly room for user stylesheets and scripts (like  
Greaemonkey) to begin taking advantage of them immediately.

> (we might as well be writing in any arbitrary format).

Actually, no. On of the goals of microformats is to add structure to  
data which is already being published. hCalendar has some great  
examples. The Squid List <http://laughingsquid.com/squidlist/>, for  
example, was already publishing events and it was trivial for them to  
add hCalendar markup to that page. There's no reason for the laughing  
squid guys to publish a second representation of their data when one  
will suffice (and is going to be published no matter what).

> Taken further, it seems to me that for anything to be done with  
> microformats, our UAs will need to be updated in some fashion.

Right. But, of course, in the meantime, they're not breaking anything  
and you can still view the data in a browser.

> Of course, Technorati is supporting some of them already....but we  
> don't want something that will be supported by only one  
> vendor...and presumably Technorati would support another XML  
> format, too.

Technorati is not the only organization supporting microformats. And,  
Technorati suppports other XML formats.

> Thus, microformats, to me, sound like just as much work as would be  
> a separate format (like RSS).

I understand how microformats can seem like a lot of work- we're  
adding all sorts of markup and constraints. I think, though, that in  
most cases you've already done most of the hard work to produce html  
documents and adding microformats will be relatively trivial.

An example would be upcoming.org. They implemented hCalendar in  
*under an hour.*

> Indeed, many of the microformats are based on living formats  
> written in plaintext or xml. So some are already developed...like  
> iCal, xCal, and OPML.
>
> Therefore, I wonder if there are some applications for which a  
> separate format are better suited, and presumably some applications  
> for which microformats are better suited.  Does anybody have a take  
> on this?

Yes. Remember, microformats are intentionally limited in scope. There  
are many problems which are unsuitable to microformats (like making  
coffee :)).

> However, I'm hearing this push about microformats...which is all  
> well and good...but I don't know, as a developer, where I should  
> *spend my time*.

Take a look at the things you're already doing- data you're already  
publishing and see if any of it could benefit from being published in  
a more structured manner.

> A possible issue to address would be: should I provide OPML or XOXO?

We can't answer that question for you- you're going to have to do so  
based on the constraints of your own project. I, personally, would  
encourage XOXO use, for many reasons... but that's a topic for  
another thread.

Josh- thank you for your interest in microformats and thanks for  
taking the time to be engaged in the community. I just hope that my  
comments here are helpful.

-ryan


From limbo at speakeasy.net  Tue Jul 12 17:18:55 2005
From: limbo at speakeasy.net (Eran)
Date: Tue Jul 12 17:08:26 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <8244713B-2098-42E4-99FE-2FCE0F65B251@technorati.com>
Message-ID: <006e01c58740$75a065f0$6464a8c0@hellonwheels>


> I believe Brian Suda was working on a parser/validator for xmdp.
> 
> However, as I'm sure you've noticed, the real guts of an xmdp 
> are the  
> prose descriptions of the elements. So, just like other 
> microformats,  
> xmdp is for "humans first and machines second."
> 
> -ryan

This shouldn't stop us from including more machine useable information
in profiles. I'd love to see additional information that can be used to
automate parsing or viewing of the microformat in question.

From tjameswhite at yahoo.com  Tue Jul 12 17:37:31 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Tue Jul 12 17:37:33 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <20050712190002.EE701F08639@microformats>
Message-ID: <20050713003731.33579.qmail@web30602.mail.mud.yahoo.com>


Eran said:
> I think it's actually quite common in the blogosphere. Consider the
> case
> where Ryan might quote a blog post made by tantek. I read Ryan's post
> but would like to respond to Tantek's opinions. The markup would be
> something like so:
> 
> ---- * ----
> <cite class="revreplyto"><a
> href="http://tantek.com/interesting-blog-post">Tantek
> said:</a></cite>
> <blockquote>
> Quoting from Tantek's post here...
> </blockquote>
> 
> Blah blah blah... 
> 
> Via: <cite class="relvia"><a
> href="http://theryanking.com/blog/blog-post-i-read">Ryan
> King</a></cite>
> ---- * ----
> 

OK - I see where you're going with this. But I would ask, what
difference does it make? Essentially you are creating a works cited
list for your post. So why not just code it:

---*---
<a href="http://tantek.com/interesting-blog-post" rel="cite">Tantek
said:</a>
<blockquote>
Quoting from Tantek's post here...
</blockquote>
 
Blah blah blah...

<a href="http://theryanking.com/blog/blog-post-i-read" rel="cite">Ryan
King</a>
---*---

Think back to writing research papers -- you've read lots of sources,
some referencing each other, but each ultimately it's own piece. At the
end you construct a bibliography/works cited. With your example, you
have read Tantek's comment and (presumably) Ryan's original post, so
you've created a works cited for your post. I really don't see a need
to differentiate between the two sources. I like the idea of keeping
the formats as simple as possible.

(Note: I realize that I eliminated the <cite> element. I suppose a
better structure would be <cite rel="source.uri"> or some such thing. I
don't have the spec handy at the moment.)



~ 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>


		
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
 
From coretxt at gmail.com  Wed Jul 13 00:10:25 2005
From: coretxt at gmail.com (Mark Rickerby)
Date: Wed Jul 13 00:10:29 2005
Subject: [microformats-discuss] hTest
In-Reply-To: <1f2ed5cd05071210426498a762@mail.gmail.com>
References: <1f2ed5cd05071210426498a762@mail.gmail.com>
Message-ID: <ffa20f2205071300102b6af952@mail.gmail.com>

> So why not construct a little vocabulary to extend what's already in
> DOAP to describe tests? The vocabulary could be expressed as a
> microformat (so it could appear on Wikis a la Fitnesse) but would also
> be available for arbitrary machine processing via RDF.

Hi Danny,

This is something I've run into with some work on the Sourceforge
project Arbiter [1]. Arbiter is a document repository and acceptance
test generator, loosely based on the principles of FIT [2]. The basic
concept is to declare test cases as bulleted or numbered lists in a
document. The Arbiter server will parse the test cases, build the
acceptance tests in code (eg: Simpletest [3] or JWebUnit [4]) and then
run the tests, appending the results (pass/fail) back into the
document itself.

eg: an Arbiter test case would look like:

Client Log In

1) Go to http://localhost/login/
2) Set name to mark
3) Set password to something
4) Click submit
5) Expect to see "Welcome"

This would generate code that automates the process of navigating the
site, filling out forms, and making assertions about content. Running
the test would result a pass/fail notice for each line.

Our initial experiments were focused on RTF, because that provides
direct access to MS Word/Openoffice docs, which are widely used by
managers (target audience). However, some recent feedback we've had
indicates that developers especially would be more interested in using
HTML lists to mark up test cases. That has always been part of the
plan, but was intended to be factored into the project further down
the track. Getting HTML lists in there would actually be fairly
trivial at the moment - RTF is a lot more of a hassle due to
divergences in document formats, and the fact that none of us have
worked with it at all before.

I'm not totally convinced there is a pressing need for a microformat
with our input situation, mainly because the approach to parsing we
are considering is more based on the natural language  used, than
actually analyzing semantic markup. For example a line in a document
like {Should see "Arbiter"} would be detected as a test assertion
because it is 1) an item in a list, and 2) contains the assertion
"should see".

eg:

<ol>
  <li>Start at http://microformats.org</li>
  <li>Should see "Latest microformats news"</li>
</ol>

I would want this basic list format to be capable of building a test
without having to add any additional semantic attributes. I don't know
whether I am being far too ambitious here, the main thing is that I am
*really* bored of manually typing in the same PHP code over and over
again to build tests, and this would make things *much easier*.

The possibilities for a microformat become more interesting when
considering reporting results back and distributing the tests. It
would be nice to be able to feed in tests from RTF or basic HTML
lists, and render them back with more standardized markup that could
be displayed directly in the browser, and also distributed to
downstream aggregators, collected for use in separate testing tools,
or added to/scraped from wiki pages, etc.

If there was a common microformat for defining acceptance test cases,
I would definitely make sure that Arbiter supported it. I don't know
anything about DOAP though, I'm just musing on things from my
perspective as a frequent user of Simpletest.

At the moment our vocabulary is not much more than: class="pass",
class="fail"...

Regards,
Mark

[1] http://arbiter.sf.net
[2] http://fit.c2.com
[3] http://simpletest.org
[4] http://jwebunit.sourceforge.net/
From coretxt at gmail.com  Wed Jul 13 01:00:25 2005
From: coretxt at gmail.com (Mark Rickerby)
Date: Wed Jul 13 01:00:27 2005
Subject: [microformats-discuss] personal intro
Message-ID: <ffa20f22050713010069aafadd@mail.gmail.com>

Hi list...
I'm new here, and thought I'd just drop a quick wot-up and introduction...

I'm Mark Rickerby, an information designer and web developer based in
Wellington New Zealand... I'm currently studying logic and computation
at Victoria University, and working part time at the design studio
Shift [1], as well as occasionally contributing to various open source
projects. I'm mostly known in these parts for my typographic and CSS
contributions to Te Ara in 2003 [2], I also write stuff occasionally
[3].

I joined this list, because I have been recently considering various
microformat possibilities in relation to some large scale information
projects on the horizon in NZ at the moment. Also because my work with
HTML and CSS often leads to common structures that feel like they
should be reused, so I'm eager to learn more about the rationale and
philosophy behind microformats, and see what is out there and working
already, without trying to reinvent the wheel (a bad tendency of
mine)...

Anyway, the interest and investment in microformats that I have seen
so far is extremely encouraging, and I just wanted to say thanks to
everyone here for putting microformats.org together.

Regards,
Mark

[1] http://www.shift.co.nz
[2] http://www.teara.govt.nz
[3] http://maetl.coretxt.net.nz
From limbo at speakeasy.net  Wed Jul 13 01:53:42 2005
From: limbo at speakeasy.net (Eran)
Date: Wed Jul 13 01:53:45 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <20050713003731.33579.qmail@web30602.mail.mud.yahoo.com>
Message-ID: <000d01c58788$5ec79f90$7401a8c0@hellonwheels>

Tim said:
> OK - I see where you're going with this. But I would ask, 
> what difference does it make? Essentially you are creating a 
> works cited list for your post. 

Not quite, I'm describing a distributed conversation. Quoting your
immediate source on the Blogosphere is interesting for several reasons
(e.g. meme propagation) and is just good netiquette. Encoding the
relationship between your post and the source post (reply, forward,
etc.) can be the basis for tracking a conversation that takes place
simultaneously on several different blogs. 

> So why not just code it:
> 
> ---*---
> <a href="http://tantek.com/interesting-blog-post" 
> rel="cite">Tantek said:</a> <blockquote> Quoting from 
> Tantek's post here... </blockquote>
>  
> Blah blah blah...
> 
> <a href="http://theryanking.com/blog/blog-post-i-read" 
> rel="cite">Ryan King</a>
> ---*---
> 

1. "cite" is not a valid value for a rel attribute.
2. if we're to expand XHTML, it's better to do it by reusing existing
elements as much as possible. The CITE element already exists and has
the semantic context we need.
3. rel="cite" is not specific enough to solve the problem.


> I like the idea of 
> keeping the formats as simple as possible.
>

The format is indeed as simple as possible while still solving the
problem at hand and conforming with (what I understand as) the
principles of microformats.
 
> (Note: I realize that I eliminated the <cite> element. I 
> suppose a better structure would be <cite rel="source.uri"> 
> or some such thing. I don't have the spec handy at the moment.)
> 

Rel="source.uri" doesn't seem to make much sense. Under XHTML2.0 we
could use
<cite cite="source.url" rel="via">
But as far as I can tell, those attributes are not available under
XHTML1.0.

Eran.

From danny.ayers at gmail.com  Wed Jul 13 02:13:28 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 02:13:29 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <006e01c58740$75a065f0$6464a8c0@hellonwheels>
References: <8244713B-2098-42E4-99FE-2FCE0F65B251@technorati.com>
	<006e01c58740$75a065f0$6464a8c0@hellonwheels>
Message-ID: <1f2ed5cd050713021322750320@mail.gmail.com>

On 7/13/05, Eran <limbo@speakeasy.net> wrote:
> 
> > I believe Brian Suda was working on a parser/validator for xmdp.
> >
> > However, as I'm sure you've noticed, the real guts of an xmdp
> > are the
> > prose descriptions of the elements. So, just like other
> > microformats,
> > xmdp is for "humans first and machines second."

Well yes, that's a nice slogan, but I've yet to see a microformat used
without machine involvement. XHTML+CSS can already provide
human-readable representations of information, what I believe
microformats bring to the table is a way of making that information
explicit in a machine-readable form.

> This shouldn't stop us from including more machine useable information
> in profiles. I'd love to see additional information that can be used to
> automate parsing or viewing of the microformat in question.

I don't personally believe XMDP was needed as there is an existing
standard for describing such information, RDF Schema, which can be
rendered in a human-friendly form, e.g. see [1]. But I'm not going to
argue the point, now there is XMDP there's no reason not to use RDFS
in conjunction with it to maximally exploit the available information.
The easiest approach is to associate the XMDP documents with XSLT
which can extract their data as RDF/XML.

The question still remains of how machines are going to use the data.
I'd suggest there's already considerable infrastructure in place in
the form of Semantic Web technologies.  GRDDL [2] can already provide
automatic parsing of microformats (assuming the profile is
conveniently identified using a URI). RDF stores can easily contain
and process data found in microformat docs. Tools like PiggyBank offer
useful ways of using/viewing the information.

But whether you want to use RDF etc doesn't really matter. The aspects
of microformats that make them useful compared to arbitrary scraping -
standardised vocabularies (hReview etc) unambiguously defined (the
profile has a URI) - are also the things that make the information
useful on the Semantic Web. Whether it's "humans first" or we use
computers to process the data, it's humans that benefit.

Cheers,
Danny.

[1] http://xml.mfd-consult.dk/ws/2003/01/rdfs/
[2] http://www.w3.org/2004/01/rdxh/spec

-- 

http://dannyayers.com
From tantek at cs.stanford.edu  Wed Jul 13 03:44:02 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 03:44:03 2005
Subject: [microformats-discuss] reuse *building blocks* from *widely
	adopted* standards
In-Reply-To: <1f2ed5cd050712123539642826@mail.gmail.com>
Message-ID: <BEFA3E62.5CF4D%tantek@cs.stanford.edu>

On 7/12/05 12:35 PM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> Sorry, I'm arriving late to the party - I missed this list when I
> first looked at microformats.org
> 
> Anyhow given the microformat credo of building on existing standards,

No.

That is not an accurate statement of the microformat principle of re-use,
and "existing standards" is an *insufficient* requirement.

There are *tons* of *nearly totally useless* and *nearly totally
unimplemented*, but existing, standards.

There are *tons* of ridiculously complex, but existing, standards.

Just look at the majority of http://w3.org/TR/


I want to make this clear because I don't want to see this point confused
again, nor misrepresented.


The summary of the Reuse principles is stated as:

 * reuse building blocks from widely adopted standards


This includes *two* key concepts here above and beyond simple "existing"
standards.

1. reuse of *building blocks*, not necessarily the whole thing

This might mean reuse of a whole element, or just an attribute/property, or
just a single value of an attribute/property, or perhaps just a *term* and
its definition.

2. *widely adopted* standards.

Widely adopted means there are multiple, interoperable implementations, in
wide/broad use.  I would hazard that the vast majority of so-called
"standards" do not come *close* to meeting this requirement.


Thanks,

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 03:50:03 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 03:50:03 2005
Subject: [microformats-discuss] IRI unsuitable for rel,
	"naming clashes" is chicken littling
In-Reply-To: <1f2ed5cd050712123539642826@mail.gmail.com>
Message-ID: <BEFA3FA1.5CF50%tantek@cs.stanford.edu>

On 7/12/05 12:35 PM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> I thought it worth mentioning that there was considerable discussion
> of useful values for a "rel" attribute over on the Atom list/wiki,
> specifically for the <link> element. The decision was made to endorse
> by IANA registration five initial values (alternate, related, self,
> enclosure, via), but to also allow unregistered values that could be
> specificied using an IRI.

The use of IRIs in 'rel' attribute values is an unnecessary and undesirable
level of complexity and syntactic vinegar.

> The general feeling was that this offered a good compromise between a
> (ever growing!) list of preset values and an openly-extensible
> approach.

No.  This was a mistake.  XSPF repeated this mistake.

I'm terminating this notion right here.

IMHO the use of IRIs for rel values is out of scope for microformats.

As list moderator: end of thread on IRI for rel.


> Use of IRIs prevents naming clashes.

"Naming clashes" is chicken littling and has been documented as such within
the context of microformats.

As list moderator: end of thread of general "naming clashes" discussions.


Thanks,

Tantek

From carl.beeth at gmail.com  Wed Jul 13 04:04:04 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Wed Jul 13 04:04:11 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
References: <003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<58B94342-7DF2-4656-959F-5EB325B41865@bokardo.com>
Message-ID: <e8ca2e110507130404756ad076@mail.gmail.com>

On 7/12/05, Joshua Porter <porter@bokardo.com> wrote:
> In trying to understand why I should, as a developer, produce
> microformat code,

For the same reason you produce RSS. It is a tiny investment that
increases the value of your site.
Right now microformats are pre early adopters stage but my hunch it is
going to spread faster than RSS did.
<http://en.wikipedia.org/wiki/Early_adopter>
From tantek at cs.stanford.edu  Wed Jul 13 04:06:08 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 04:06:12 2005
Subject: [microformats-discuss] uses of XMDP: human documentation,
	machine validation
In-Reply-To: <ab069aa0050712142274bc1514@mail.gmail.com>
Message-ID: <BEFA437B.5CF57%tantek@cs.stanford.edu>

(Recommended list practice: please change the subject line when forking new
threads.)


On 7/12/05 2:22 PM, "Lucas Gonze" <lucas.gonze@gmail.com> wrote:

> On 7/12/05, Danny Ayers <danny.ayers@gmail.com> wrote:
>> Just stepping back a second - I can see the benefit of having a
>> profile URI (to disambiguate the interpretation). What are the
>> benefits of the XMDP part - documentation? Or is anyone doing some
>> kind of processing with it?
> 
> Just documentation, but that's worth a lot since fewer developers will
> be morons in the http://diveintomark.org/archives/2004/08/16/specs
> sense.

Lucas makes a very good point that a dereferencable URL which has a *human*
readable spec at the other end has *significant* benefits above and beyond
an opaque URI.  In fact, for all the squabbling that has gone on for opaque,
not-necessarily-dereferencable URIs, there's been little to no practical
benefit.

However, XMDP's are not *just* documentation.  XMDP's have a predefined
structure, and thus can be used to do some amount of algorithmic
"validation" of the use of XHTML extensions in a document.  An XMDP
validator could report on whether all the new 'rel' values, class names, and
<meta name> properties are defined in the set of profiles referenced or not.

Such an XMDP validator could be generic to XMDP and not need any special
knowledge about any specific microformat.

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 04:10:08 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 04:10:08 2005
Subject: [microformats-discuss] additional machine info in XMDP
In-Reply-To: <006e01c58740$75a065f0$6464a8c0@hellonwheels>
Message-ID: <BEFA4440.5CF5C%tantek@cs.stanford.edu>

On 7/12/05 5:18 PM, "Eran" <limbo@speakeasy.net> wrote:

> 
>> I believe Brian Suda was working on a parser/validator for xmdp.
>> 
>> However, as I'm sure you've noticed, the real guts of an xmdp
>> are the  
>> prose descriptions of the elements. So, just like other
>> microformats,  
>> xmdp is for "humans first and machines second."
>> 
>> -ryan
> 
> This shouldn't stop us from including more machine useable information
> in profiles. I'd love to see additional information that can be used to
> automate parsing or viewing of the microformat in question.

While I agree that there is definitely some potential there, I am not sure
it is worth the effort.  Absent any well defined practical use case for
putting more machine usable information into XMDP, that *should* stop us
from allocating time to discuss or do it.

Let's focus our time and efforts on microformats on practical uses that
exist today as much as possible.  If you really want, perhaps keep track of
extra ideas like that in some side notes, perhaps a brainstorming page.

Thanks,

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 04:20:09 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 04:20:10 2005
Subject: [microformats-discuss] microformats: very low cost to publish,
	with many benefits
In-Reply-To: <e8ca2e110507130404756ad076@mail.gmail.com>
Message-ID: <BEFA468E.5CF60%tantek@cs.stanford.edu>

On 7/13/05 4:04 AM, "Carl Beeth" <carl.beeth@gmail.com> wrote:

> On 7/12/05, Joshua Porter <porter@bokardo.com> wrote:
>> In trying to understand why I should, as a developer, produce
>> microformat code,
> 
> For the same reason you produce RSS. It is a tiny investment that
> increases the value of your site.
> Right now microformats are pre early adopters stage but my hunch it is
> going to spread faster than RSS did.
> <http://en.wikipedia.org/wiki/Early_adopter>

Carl, that is an excellent characterization of what is going on.

RSS took nearly 10 years to become widely adopted.

We don't have that kind of patience. :)

Our goal with microformats is to design them according to current publisher
behaviors, rather than trying to make publishers learn a new language,
generate separate files etc.

By lowering the barrier to entry for publishers, from a purely economic
perspective, microformats gain a much more rapid adoption curve than other
efforts which ask the publisher to do a lot more.

In fact, even just as I personally have been seeing it, their adoption has
outpaced my ability to keep up with it.  Hence those of us early pioneers in
microformats build microformats.org to provide a place for the community to
grow itself, with guiding input as needed.

Getting back to the original question.

The answer to why is that the cost of adopting microformats for publishers
is so low (literally minutes to at most an hour or two of a single
developer's time) that nearly *any* level of benefit makes it worth it, and
there are numerous such benefits already for each microformat.

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 04:22:09 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 04:22:09 2005
Subject: [microformats-discuss] Proposing RelSource
In-Reply-To: <e6ec604d0507120959273c9f67@mail.gmail.com>
Message-ID: <BEFA4754.5CF62%tantek@cs.stanford.edu>

On 7/12/05 9:59 AM, "Andy Skelton" <skeltoac@gmail.com> wrote:

> On 7/12/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> << snip >>
>> I see lots of examples of citation chains on blogs.
>> So yes, rel="cite" does not solve the citation chain problem.
>> Since these examples of citation chains on blogs are typically ordered, e.g.
>>  c via b via a
>> It may make sense to use an ordered list.
>> Then the only question remains as to how to represent that the list is a
>> chain.
> 
> Citing one's reference's references may be strictly proper to some
> minds but to me it seems an undue burden on the author.

1. It's certainly not required.
2. Tools that allow blockquoting now could recognize citations in the source
and thus build a chain automatically.

And most importantly...

3. This is designed for authors that are ALREADY GOING TO THE EFFORT to cite
reference's references.  For author's that don't, see 1.


> With wide
> acceptance, the practice of citing one degree of reference will
> provide sufficient interlinking to enable a spider to infer a
> reasonably accurate citation chain.

Yes, there will be some very interesting conversational threading benefits.


Tantek

From tantek at cs.stanford.edu  Wed Jul 13 04:28:09 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 04:28:09 2005
Subject: [microformats-discuss] wiki etiquette: brainstorming proposals vs.
	writing specs, avoid user specific pages
In-Reply-To: <e6ec604d0507121212558d8c05@mail.gmail.com>
Message-ID: <BEFA48C2.5CF66%tantek@cs.stanford.edu>

On 7/12/05 12:12 PM, "Andy Skelton" <skeltoac@gmail.com> wrote:

> I have drafted a spec for a very simple citation microformat after
> study of some other specs on mf.org.
> http://microformats.org/wiki/User:Skeltoac/RelCite

Hmm... I didn't even know it was possible to create such user page specific
pages.

Andy, given that folks that have been working on the concepts of RelSource,
RelCite, CiteVia etc. still don't have consensus, we should:

 1. put all proposals on a *-formats page or *-brainstorming page.
 2. avoid formal spec-writing on this until there is more consensus.

In general, let's also not create user specific pages on the wiki.

Andy, could you move the key portions of your proposal to the citation
brainstorming page:

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

and then delete the user specific RelCite page? (empty it's contents if you
can't delete the page itself).

Thanks,

Tantek

From bud at thecommunityengine.com  Wed Jul 13 04:36:23 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Wed Jul 13 04:36:22 2005
Subject: [microformats-discuss] additional machine info in XMDP
In-Reply-To: <BEFA4440.5CF5C%tantek@cs.stanford.edu>
References: <BEFA4440.5CF5C%tantek@cs.stanford.edu>
Message-ID: <15105FAC-BC36-4B24-A98F-2E073D0250EE@thecommunityengine.com>

On Jul 13, 2005, at 7:10, Tantek ?elik wrote:

> Let's focus our time and efforts on microformats on practical uses  
> that
> exist today as much as possible.  If you really want, perhaps keep  
> track of
> extra ideas like that in some side notes, perhaps a brainstorming  
> page.

Tantek et al.,

I'd like to bring the discussion back to its original start which was  
discovery of microformats and the importance of the XMDP.  The simple  
practical concern is to know that microformats are being used, which  
ones, and what they cover.  Here's what I think I learned in that  
regard:

1.  The XMDP provides a great summary of the format that can be read  
by people as well as machines.

2.  Pointing at the XMDP currently is the best hint that the page  
contains microformatted content because it is explicit.

3.  A problem with using XMDPs is that the standard only allows for  
them to be linked from the profile attribute in the head element.   
People do not always have access to that.  A case in point is the h*- 
creators which create body markup but do not alter the contents of  
the head element.

4.  A seemingly easy solution is to put an <a> element somewhere in  
the microformatted content that points back to the XMDP.  This  
fulfills the initial practical question raised initially but adds <a>  
elements, an addition some find aesthetically displeasing.

It seems another outcome of all of this would be to consider some  
simple extension to the XMDP spec that allows it to be linked from an  
<a> element with discussion focusing on how that would work.

Bud
From tantek at cs.stanford.edu  Wed Jul 13 04:38:09 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 04:38:10 2005
Subject: [microformats-discuss] rel="cite", rev="cite". rel="comment"?
In-Reply-To: <e6ec604d0507121212558d8c05@mail.gmail.com>
Message-ID: <BEFA4ABF.5CF6A%tantek@cs.stanford.edu>

On 7/12/05 12:12 PM, "Andy Skelton" <skeltoac@gmail.com> wrote:

> It does not classify relationships such as "reply" or "via" as
> proposed by Eran but it does capitalize on the directional quality of
> a citation by adding rel="cite"

Question:

What semantic difference is there between:

1. <cite><a href="http://example.com">example citation</a></cite>

and

2. <a rel="cite" href="http://example.com">example citation</a>

?

AFAICT, there is no semantic difference.

However, (1) only uses pre-defined XHTML elements.

(2) uses a new rel value.

Thus (1) is preferred.


> and rev="cite" to hyperlinks.

I don't think rev="cite" is something that an author can be trusted to
claim.

>From a trust and authority perspective, you don't get to state that someone
else is citing you.  You can only state when you cite someone else.


> For example, consider a Pingback. A blogger generates a favorable
> article citing one of your articles. He writes < a href="foo"
> rel="cite vote-for">foo< /a> and your blog is notified via pingback.
> If your blog reacts by generating a comment with a hyperlink back to
> his article, it should be < a href="bar" rev="cite">bar< /a>.

While I can certainly appreciate the symmetry of using rel vs. rev = cite,
in practice, 'rev' is something that is not easy to understand for web
authors.

Another alternative is to use something like rel="comment", which would be
like saying that this resource over here, is a comment for the current
(portion of the) page.

Tantek

From danny.ayers at gmail.com  Wed Jul 13 04:49:37 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 04:49:39 2005
Subject: [microformats-discuss] reuse *building blocks* from *widely
	adopted* standards
In-Reply-To: <BEFA3E62.5CF4D%tantek@cs.stanford.edu>
References: <1f2ed5cd050712123539642826@mail.gmail.com>
	<BEFA3E62.5CF4D%tantek@cs.stanford.edu>
Message-ID: <1f2ed5cd05071304497e39447f@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:

> The summary of the Reuse principles is stated as:
> 
>  * reuse building blocks from widely adopted standards

I stand corrected. 

I'd note that many of http://w3.org/TR/ aren't really standards,
merely specifications, that being a standard itself implies some
degree of adoption.

Cheers,
Danny.

-- 

http://dannyayers.com
From vrypan at gmail.com  Wed Jul 13 05:02:00 2005
From: vrypan at gmail.com (Panayotis Vryonis)
Date: Wed Jul 13 05:02:54 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
Message-ID: <b5e3e031050713050217be00fc@mail.gmail.com>

Hi,

I've been thinking if it would make sense to have a microformat for resumes. 
I posted some of my thoughts in my blog, 
http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/<http://http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/>,
but I guess this forum would be a much more appropriate place.

Please let me know what you think. I really believe that a 
resume-microformat could be the format to attract wide interest on 
microformats since the publisher will expect to make an immediate profit out 
of it (a job) which is a good motive :-)

Panayotis.
-- 
The content of this email is:
[x]blogable []ask first []personal
--
panayotis vryonis
http://vrypan.net/log/
http://g-metrics.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050713/fac4194d/attachment.htm
From tantek at cs.stanford.edu  Wed Jul 13 05:08:10 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 05:08:11 2005
Subject: [microformats-discuss] microformats vs. plain XML formats
In-Reply-To: <8AECF1D0-BBCF-4A19-AFCC-3AF9FBF26F9C@bokardo.com>
Message-ID: <BEFA5233.5CF71%tantek@cs.stanford.edu>

On 7/12/05 2:12 PM, "Joshua Porter" <porter@bokardo.com> wrote:

> Is it fair to say that microformats are no further along in auto-
> discovery than are standalone XML formats?

I'm not sure that "auto-discovery" as you use it means the same thing as
others use it to mean.  It is a bit of an overloaded term, and as such, a
specific use-case would help with understanding what you mean.


> I ask because I'm confused about the "support" of microformats. I
> understand that microformats are "supported" by browsers in the sense
> that browsers read them as XHTML.

Yes, microformats are built from XHTML building blocks, and thus have all
the support that those have, which is a level of support far above "plain"
XML.

In addition, microformats can be added to web pages and still have those web
pages *validate*, something which is very important to modern web designers.

"plain XML" on the other hand, cannot be added to an XHTML web page and have
it still validate, short of doing nasty things like CDATA/escaping the
markup, or putting it into comments.  Both of which have already been
covered for all the problems they have.


> But that's not really doing
> anything with the semantics we've added to our markup. (we might as
> well be writing in any arbitrary format).

Not at all.  XHTML has numerous predefined semantics.  "plain XML" has none
(except perhaps the xml:lang attribute).


> Taken further, it seems to me that for anything to be done with
> microformats, our UAs will need to be updated in some fashion.

No.  *could be* updated, yes.

*need to be* updated? No.  For example, tons have been done with styling
microformats with built-in CSS support, utilizing microformats with
favelets/bookmarklets, Grease Monkey plugins etc.  None of which required
updating the browser.

Similarly, you can subscribe to hCalendar in existing calendaring
applications like Apple iCal and Mozilla Sunbird, without *any* updates to
those applications.

This is one of the advantages of basing a microformat standard on well
adopted other standards.  Instant interoperability.


>  Of  
> course, Technorati is supporting some of them already....but we don't
> want something that will be supported by only one vendor

Hence Technorati has from day 1 developed microformats as open standards on
an open wiki, open for anyone to view (and edit/contribute to).

Note that this is in *stark* contrast to *numerous* other "standards"
efforts which are typically developed either behind closed doors of a
paid-membership only committee, or developed on a closed mailing list, or a
closed wiki, or perhaps just in the closed-mind of a singular blow-hard
individual.


> ...and  
> presumably Technorati would support another XML format, too.

Not necessarily.  A big concern on the part of Technorati (and any other
search implementer) is data quality, signal to noise.  As such if XML (like
most) formats encourage invisible metadata, they will be of significantly
lower utility to Technorati than formats that simply markup already visible
data.


> Thus, microformats, to me, sound like just as much work as would be a
> separate format (like RSS).

What application / site are you looking at adding microformats too?


> Indeed, many of the microformats are
> based on living formats written in plaintext or xml. So some are
> already developed...like iCal,

Non-trivial to author.


> xCal

Tried and failed already.  Effectively zero uptake on the Web.


> and OPML.

<sigh />

A totally unnecessary reinvention of <ol><li><a href>.

Those whose ignore standards are doomed to reinvent them.


> Therefore, I wonder if there are some applications for which a
> separate format are better suited,

Perhaps non-web applications?


> and presumably some applications
> for which microformats are better suited.

Anything that involves publishing content on the Web.


> However, I'm hearing this push about microformats...which is all well
> and good...but I don't know, as a developer, where I should *spend my
> time*.

What do you develop Josh?  That will probably impact where you spend your
time.


> A possible issue to address would be: should I provide OPML or XOXO?

If you are publishing on the web, XOXO.

If not, use whatever outline format is the most convenient (cheapest to
implement) for you and your actual use cases.


Thanks,

Tantek

From danny.ayers at gmail.com  Wed Jul 13 05:15:06 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 05:15:08 2005
Subject: [microformats-discuss] IRI unsuitable for rel,
	"naming clashes" is chicken littling
In-Reply-To: <BEFA3FA1.5CF50%tantek@cs.stanford.edu>
References: <1f2ed5cd050712123539642826@mail.gmail.com>
	<BEFA3FA1.5CF50%tantek@cs.stanford.edu>
Message-ID: <1f2ed5cd05071305155587892c@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:

> As list moderator: end of thread on IRI for rel.

> As list moderator: end of thread of general "naming clashes" discussions.

Forgive me, I misinterpreted the word "discuss" in the mailing list
name. I personally believe that there is a lot of potential for
cross-fertilization between efforts like Atom, the Semantic Web
initiative and microformats. These projects have at least one goal in
common: putting more useful data on the Web. Whatever, if the attitude
around microformats is to not-invented-here, it's not a big deal.

Cheers,
Danny.

-- 

http://dannyayers.com
From tantek at cs.stanford.edu  Wed Jul 13 05:16:11 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 05:16:11 2005
Subject: [microformats-discuss] additional ways to reference XMDPs
In-Reply-To: <15105FAC-BC36-4B24-A98F-2E073D0250EE@thecommunityengine.com>
Message-ID: <BEFA53B9.5CF74%tantek@cs.stanford.edu>

Time out on the subject of more ways to reference XMDPs.

I'm behind on taking past proposed XMDP extensions and putting them out
there on the web.

LOTs of good ideas presented here, and I'm very happy to see that most of
what I discussed with folks earlier this year (e.g. at SXSW, at WWW2005) has
been brought up independently on this list by others.

In short:

1. Today the spec lets you use the profile attribute of <head>

2. <link rel="profile"> is another way to do so, and is actually formalized
in XHTML2.

3. <a rel="profile"> is another way to do so, and enables people to
reference profiles inline in content anywhere, and *visibly* as well, which
has added benefits.


These are all great ideas.  Thanks to Bud and everybody else who has
suggested them and confirmed past brainstormings.


I'm working on writing these up more formally as additions to XMDP.

I'll send something to the list when I've edited XMDP.

Thanks,

Tantek


On 7/13/05 4:36 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> On Jul 13, 2005, at 7:10, Tantek ?elik wrote:
> 
>> Let's focus our time and efforts on microformats on practical uses
>> that
>> exist today as much as possible.  If you really want, perhaps keep
>> track of
>> extra ideas like that in some side notes, perhaps a brainstorming
>> page.
> 
> Tantek et al.,
> 
> I'd like to bring the discussion back to its original start which was
> discovery of microformats and the importance of the XMDP.  The simple
> practical concern is to know that microformats are being used, which
> ones, and what they cover.  Here's what I think I learned in that
> regard:
> 
> 1.  The XMDP provides a great summary of the format that can be read
> by people as well as machines.
> 
> 2.  Pointing at the XMDP currently is the best hint that the page
> contains microformatted content because it is explicit.
> 
> 3.  A problem with using XMDPs is that the standard only allows for
> them to be linked from the profile attribute in the head element.
> People do not always have access to that.  A case in point is the h*-
> creators which create body markup but do not alter the contents of
> the head element.
> 
> 4.  A seemingly easy solution is to put an <a> element somewhere in
> the microformatted content that points back to the XMDP.  This
> fulfills the initial practical question raised initially but adds <a>
> elements, an addition some find aesthetically displeasing.
> 
> It seems another outcome of all of this would be to consider some
> simple extension to the XMDP spec that allows it to be linked from an
> <a> element with discussion focusing on how that would work.
> 
> Bud_______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From ian at hixie.ch  Wed Jul 13 05:23:02 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed Jul 13 05:23:04 2005
Subject: [microformats-discuss] UA requirements for microformats
In-Reply-To: <BEFA468E.5CF60%tantek@cs.stanford.edu>
References: <BEFA468E.5CF60%tantek@cs.stanford.edu>
Message-ID: <Pine.LNX.4.62.0507131217250.27019@dhalsim.dreamhost.com>

On Wed, 13 Jul 2005, Tantek ?elik wrote:
> 
> By lowering the barrier to entry for publishers, from a purely economic 
> perspective, microformats gain a much more rapid adoption curve than 
> other efforts which ask the publisher to do a lot more.
> 
> In fact, even just as I personally have been seeing it, their adoption 
> has outpaced my ability to keep up with it.  Hence those of us early 
> pioneers in microformats build microformats.org to provide a place for 
> the community to grow itself, with guiding input as needed.

The problem with the rapid adoption is that since the specs don't yet have 
exact UA conformance requirements (e.g. how to process an HTML document to 
turn it back into an iCalendar data structure) we're going to end up in 
the same tag soup mess that HTML UAs ended up in: UAs are going to have to 
be reverse-engineering each other to determine how to parse the data.

This IMHO is the single most important problem facing microformats today, 
and is the second biggest problem stopping microformats being adopted in 
the HTML5 specs. (The primary reason is I haven't had the time to get 
around to working on those parts of the spec yet.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
From tjameswhite at yahoo.com  Wed Jul 13 05:24:21 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Wed Jul 13 05:24:23 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <20050713104404.DBFCDF08642@microformats>
Message-ID: <20050713122421.24599.qmail@web30603.mail.mud.yahoo.com>



Eran said:
>Not quite, I'm describing a distributed conversation. ...

Ah - this makes more sense now, especially now that I've had time to
read the citation-brainstorm entry fully
(http://www.microformats.org/wiki/citation-brainstorming), as well as
the linked documents. I didn't get why you wanted to distinguish the
type of citation, but that's my own short-coming since I haven't really
participated in distributed conversations as you and Ryan illustrate
them. I'm used to a more print-centered research approach. (More on
that in a moment.)

>1. "cite" is not a valid value for a rel attribute.
>2. if we're to expand XHTML, it's better to do it by reusing existing
elements as much as possible. The CITE element already exists and has
the semantic context we need.
>3. rel="cite" is not specific enough to solve the problem.

Thank you for the corrections. I would have looked up the specs last
night, but I had a screaming one month old daughter to attend to. : )


>Rel="source.uri" doesn't seem to make much sense. Under XHTML2.0 we
could use
<cite cite="source.url" rel="via">
But as far as I can tell, those attributes are not available under
XHTML1.0.

That's exactly what I wanted to type (see reason above). I didn't
realize, however, that it wasn't available under XHTML 1.0.

So, I now agree with your ideas (class="relVia", class="relUpdate",
class="relReplyTo"). However, I don't quite follow why you want to keep
the rel prefix for now though? If class="Via" will work now, and in the
future simply become rel="Via", why not go that route? (I'm slow, dense
and new to this, so bear with me.)

And that brings me back to my print-center question.  Your scope
focuses on distributed online discussions (i.e.: blog-to-blog), but
what would be the format if I were to reference a print piece? For
example, if I were to post an entry after reading an article:

---* My blog entry *---

In his essay "Hemmingway and Fish" (<cite>Times Literary Supplement,
June 1998</cite>), Mr. Haute contents....

---* *---

I'm referencing a piece I've read, so <cite> would be the appropriate
element. Would anything else be needed? A link to the TLS website
perhaps[1]? Would something like "relPrint" be appropriate?

(Even if the piece where republished online, I would cite the printed
piece (my primary source). I've seen how things can change from print
to online.)

Thanks for your patience and corrections.

~ Tim
www.tjameswhite.com/blog


[1] I could see coding it as (XHTL 2) <cite
cite="http://www.the-tls.co.uk/">Times Literary Supplement, June
1998</cite>, but doesn't seem quite appropriate as it doesn't like to
the article. Perhaps <cite><a href="http://www.the-tls.co.uk/">Times
Literary Supplement</a>, June 1998</cite> simply to point out TLS's website?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
From tantek at cs.stanford.edu  Wed Jul 13 05:28:11 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 05:28:11 2005
Subject: [microformats-discuss] microformats vs. other formats
In-Reply-To: <1f2ed5cd0507121454cb0263e@mail.gmail.com>
Message-ID: <BEFA5696.5CF7A%tantek@cs.stanford.edu>

On 7/12/05 2:54 PM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> On 7/12/05, Joshua Porter <porter@bokardo.com> wrote:
> 
>> Therefore, I wonder if there are some applications for which a
>> separate format are better suited, and presumably some applications
>> for which microformats are better suited.  Does anybody have a take
>> on this?
> 
> I was originally very skeptical of the whole notion of microformats -
> I mean, what do you need XFN (embedded) for when you've got FOAF
> (linked)?

Poor example because they capture different information
<http://gmpg.org/xfn/and/foaf>, but the point of (embedded = mark up of the
visible content already being authored) vs.
(linked = create a whole new separate file, in a new language), is a very
good point.

(BTW, a better comparison might be hCard vs. FOAF, since FOAF itself is more
about contact/profile information and has no more to do with social network
relationships than plain blogrolls).


> But they've grown on me, and I do think there's a range of
> applications for which they do make a lot of sense. As a rough
> characterisation I'd guess:
> 
> * persistent
> - because there are loads of things that you might e.g. want to put in
> an RSS feed that you wouldn't necessarily want to hold onto forever on
> a HTML page.

Excellent point Danny.


> * having both human-readable (doc) and machine-readable (data)
> components, with significant overlap
> - I'd look for the overlap, because if you can avoid repeating
> yourself that's usually a good thing.

Another very good point.  A lot of folks seem to underestimate the hazards
and problems of duplicating data in multiple places in a publishing system.

Heck, at Technorati we see LOTS of problems and inconsistencies between
blogs and their RSS feeds.


> A lot of the time you could
> generate both a human-readable and a machine readable representation
> from the same source, e.g. a database producing a blog in HTML and
> RSS. I'm not sure, but where there's more metadata than content it's
> probably better separate, and vice versa (i.e.  in retrospect Really
> Simple Syndication might have been simpler done completely as HTML).

Indeed.  If it were 6+ years ago and we had come up with the vision of
microformats, we could have introduced a syndication "microformat" that
would have been *much* easier to develop for than RSS, and thus would have
outpaced its adoption.

With RSS, we are simply too late.  There is some chance that Atom will do a
better job, but from a microformat perspective, they're both new XML
formats.


> * when it's easier that way
> - a tricky one to judge - I think hReview works very well as a
> microformat (even though I've personally done an RDF/XML format for
> reviews), perhaps because it's simply structured. I suspect where
> multiple vocabularies are needed then an external file may be more
> appropriate.

I think this is an excellent characterization Danny.

We do know that simple things like reviews work today (e.g. hReview).

We don't know where the limits are yet.  There may certainly be some.

We're ok with pushing forward with that understanding.

Microformats don't have to be infinitely flexible nor infinitely extensible.


>> A possible issue to address would be: should I provide OPML or XOXO?
> 
> I've a heuristic for that too : What is the data you wish to provide?
> For what purpose?

Excellent design questions.


> If the answer to either question is "Radio Userland"
> then the answer's OPML. Otherwise XOXO's probably a better bet.

Indeed.

As I said, with RSS, we are too late to avoid having to deal with another
XML format.

OPML is much more poorly specified, and much less adopted than RSS.  And it
is a much more obvious example of needless wheel reinvention.

Thus we have very good chance of seeing far more uptake of XOXO than OPML,
even in the short term.

Thanks,

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 05:38:12 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 05:38:12 2005
Subject: [microformats-discuss] what gets pruned/closed,
	making existing web data useful
In-Reply-To: <1f2ed5cd05071305155587892c@mail.gmail.com>
Message-ID: <BEFA590A.5CF7F%tantek@cs.stanford.edu>

On 7/13/05 5:15 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> Forgive me, I misinterpreted the word "discuss" in the mailing list
> name.


Not at all.  There are tons of things for us to discuss!

However, there are topics where discussion is counterproductive and/or a
waste of time (I have sufficient experience on W3C and other standards
mailing lists to make this observation).  Some topics are don't have the
necessary cost/benefit to be worth discussing, and thus I will be doing some
amount of pruning as necessary to keep this list as productive as possible.


> I personally believe that there is a lot of potential for
> cross-fertilization between efforts like Atom, the Semantic Web
> initiative and microformats.

Agreed.


> These projects have at least one goal in
> common: putting more useful data on the Web.

Sort of.  There is actually a very key distinction here in the microformats
approach that sets a different approach.

Microformats are much more about:

 Making the data that people *are already publishing* on the *web* more
useful.

Rather than:

 Putting more useful data on the web.

That's a fine distinction, but a very important one that focuses our
efforts.


> Whatever, if the attitude
> around microformats is to not-invented-here, it's not a big deal.

Not at all.  It is the opposite in fact.

Another way of of rephrasing the principle of maximum reuse is
the principles of minimum invention.

However, simplicity will not be sacrificed.

Therefore, something that is complex will be simplified rather than adopted.

I hope that clarifies the pruning actions taken.  I really don't intend to
do that very often.

There are some very specific rathole topics that don't benefit us at all to
discuss, and when those come up, I will close discussion on those topics.

Thanks,

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 05:50:12 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 05:50:12 2005
Subject: [microformats-discuss] UA requirements for microformats
In-Reply-To: <Pine.LNX.4.62.0507131217250.27019@dhalsim.dreamhost.com>
Message-ID: <BEFA5BBA.5CF86%tantek@cs.stanford.edu>

On 7/13/05 5:23 AM, "Ian Hickson" <ian@hixie.ch> wrote:

> On Wed, 13 Jul 2005, Tantek ?elik wrote:
>> 
>> By lowering the barrier to entry for publishers, from a purely economic
>> perspective, microformats gain a much more rapid adoption curve than
>> other efforts which ask the publisher to do a lot more.
>> 
>> In fact, even just as I personally have been seeing it, their adoption
>> has outpaced my ability to keep up with it.  Hence those of us early
>> pioneers in microformats build microformats.org to provide a place for
>> the community to grow itself, with guiding input as needed.
> 
> The problem with the rapid adoption is that since the specs don't yet have
> exact UA conformance requirements (e.g. how to process an HTML document to
> turn it back into an iCalendar data structure) we're going to end up in
> the same tag soup mess that HTML UAs ended up in: UAs are going to have to
> be reverse-engineering each other to determine how to parse the data.

First, I agree we need to write up the exact UA conformance requirements.  I
believe the microformats community (editors, authors, publishers) accepts
that responsibility.

Second, while I agree there is that danger of ending up in the same kind of
mess, I believe quite a few factors have changed in terms of the state of
modern web design which will avoid a number of the problems that HTML tag
soup ran into.

Third, the rapid adoption among publishers is being used to find problems
*quickly* in the specs, and iterate the specs (and the published data), and
not after years of work when there are legacy implementations that need to
be supported.  In that way, we're seeking to *avoid* the reverse engineering
of legacy behaviors that HTML is now saddled with.

I'm not guaranteeing that this approach will for certain work, but I believe
it is our best bet at rapidly developing these specs which are in high
demand with minimum chance of having to deal with legacy.


> This IMHO is the single most important problem facing microformats today,

IMHO that's good news, because I believe this to be a solvable problem.


> and is the second biggest problem stopping microformats being adopted in
> the HTML5 specs. (The primary reason is I haven't had the time to get
> around to working on those parts of the spec yet.)

Do the HTML5 specs have any sort of specific timeline?

I hypothesize that by the time you get to working on those parts of the spec
(specifically hCard and hCalendar), that those specs will be frozen enough
for you to depend on them.

And as you think of additional issues, please add them to the issues pages
for those specs.

Your contributions and feedback are *greatly* appreciated Ian.

Thanks,

Tantek

From carl.beeth at gmail.com  Wed Jul 13 06:03:52 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Wed Jul 13 06:03:55 2005
Subject: [microformats-discuss] microformats vs. other formats
In-Reply-To: <BEFA5696.5CF7A%tantek@cs.stanford.edu>
References: <1f2ed5cd0507121454cb0263e@mail.gmail.com>
	<BEFA5696.5CF7A%tantek@cs.stanford.edu>
Message-ID: <e8ca2e110507130603763e352f@mail.gmail.com>

Talking of other formats, What will be the relationship between
microformats and xhtml2's property attribute?
<http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-metaAttributes.html#sec_23.3.>
Will there be some kind of plan to migrate from the "class" to
"property" and "title" to "content" once xhtml2 is finished?
Will xhtml2 ever get finished? ;-)

Carl
From ian at hixie.ch  Wed Jul 13 06:08:26 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed Jul 13 06:08:28 2005
Subject: [microformats-discuss] UA requirements for microformats
In-Reply-To: <BEFA5BBA.5CF86%tantek@cs.stanford.edu>
References: <BEFA5BBA.5CF86%tantek@cs.stanford.edu>
Message-ID: <Pine.LNX.4.62.0507131256210.27019@dhalsim.dreamhost.com>

On Wed, 13 Jul 2005, Tantek ?elik wrote:
> 
> First, I agree we need to write up the exact UA conformance 
> requirements.  I believe the microformats community (editors, authors, 
> publishers) accepts that responsibility.

I know, I just thought I'd raise it again to remind y'all. ;-)


> > and is the second biggest problem stopping microformats being adopted 
> > in the HTML5 specs. (The primary reason is I haven't had the time to 
> > get around to working on those parts of the spec yet.)
> 
> Do the HTML5 specs have any sort of specific timeline?

WF2 was supposed to be in CFI last August, but will probably reach CFI 
this August. So that's roughly twice as long as predicted. (CFI = call for 
implementations, although of course WF2 is being implemented already.)

So if I say that WA1 (aka HTML5) should be ready for CFI in December 2006, 
it'll probably actually reach CFI in mid 2008.

But of course implementations of _that_ have started already as well.

Maybe a more useful answer to your question would be to consider what 
order I'll be working on things. I expect the next few weeks to be spent 
on the Window interface (I just did window.history, I'm doing 
window.location now; I may do other window properties before moving on to 
other things). After that I expect I'll look at the Parsing chapter, 
followed probably by looking at events and the attribute event handlers 
and defining those. After that I expect I'll look at the new widgets, like 
<gauge> and <progress>. At this point I'll probably be looking at 
<calendar> and <vcard>. My ETA on that would be end of this year. My 
productivity is likely to soar after the damp of the Oslo summer is over.

However, it depends on demand. If suddenly there is a big demand for a 
spec for a calendar widget, then I'll jump straight to <calendar>. So...:

> I hypothesize that by the time you get to working on those parts of the 
> spec (specifically hCard and hCalendar), that those specs will be frozen 
> enough for you to depend on them.

...I could start working on those parts next week. ;-)

(Note that there is no guarentee that hCard and hCalendar will be used for 
the HTML5 vCard and iCalendar integration. Currently it seems to be the 
most mature option and I don't see any reason to make up our own, but if 
better proposals come along of course they would be considered too. I'm 
making this explicit because otherwise people say that I'm giving hCard 
and hCalendar preferential treatement and ignoring feedback, which is not 
my intention at all.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
From porter at bokardo.com  Wed Jul 13 06:48:59 2005
From: porter at bokardo.com (Joshua Porter)
Date: Wed Jul 13 06:49:05 2005
Subject: [microformats-discuss] microformats vs. plain XML formats
In-Reply-To: <BEFA5233.5CF71%tantek@cs.stanford.edu>
References: <BEFA5233.5CF71%tantek@cs.stanford.edu>
Message-ID: <8DBDFD1D-B2EC-4B32-8C65-0EF1C2B32966@bokardo.com>


On Jul 13, 2005, at 8:08 AM, Tantek ?elik wrote:

> On 7/12/05 2:12 PM, "Joshua Porter" <porter@bokardo.com> wrote:
>
>
>> Is it fair to say that microformats are no further along in auto-
>> discovery than are standalone XML formats?
>>
>
> I'm not sure that "auto-discovery" as you use it means the same  
> thing as
> others use it to mean.  It is a bit of an overloaded term, and as  
> such, a
> specific use-case would help with understanding what you mean.

I'm talking about auto-discovery in the sense that Safari and Firefox  
autodiscover RSS feeds and provide additional functionality to them.  
(Danny and Ryan answered this question by saying that browsers don't  
*currently* autodiscover them in this way.)

>
>
>
>> I ask because I'm confused about the "support" of microformats. I
>> understand that microformats are "supported" by browsers in the sense
>> that browsers read them as XHTML.
>>
>
> Yes, microformats are built from XHTML building blocks, and thus  
> have all
> the support that those have, which is a level of support far above  
> "plain"
> XML.
>
> In addition, microformats can be added to web pages and still have  
> those web
> pages *validate*, something which is very important to modern web  
> designers.

Not important to users, however.

>
> "plain XML" on the other hand, cannot be added to an XHTML web page  
> and have
> it still validate, short of doing nasty things like CDATA/escaping the
> markup, or putting it into comments.  Both of which have already been
> covered for all the problems they have.

My RSS feed is full of CDATA escaping, and it works well. Assuming  
this is bad, though, could you provide a pointer to the coverage?

>
>
>
>> But that's not really doing
>> anything with the semantics we've added to our markup. (we might as
>> well be writing in any arbitrary format).
>>
>
> Not at all.  XHTML has numerous predefined semantics.  "plain XML"  
> has none
> (except perhaps the xml:lang attribute).

By this I mean that if UAs aren't doing anything with the semantic  
markup, it doesn't matter that it is semantic. It's like a book being  
optically scanned, as opposed to being *read*.

>
>
>
>> Taken further, it seems to me that for anything to be done with
>> microformats, our UAs will need to be updated in some fashion.
>>
>
> No.  *could be* updated, yes.
>
> *need to be* updated? No.  For example, tons have been done with  
> styling
> microformats with built-in CSS support, utilizing microformats with
> favelets/bookmarklets, Grease Monkey plugins etc.  None of which  
> required
> updating the browser.

I would consider bookmarklets and Grease Monkey scripts as updating  
the UA. (or at least the functionality of the UA). This is a good  
thing...that it is easy to add functionality relatively quickly.

>
> Similarly, you can subscribe to hCalendar in existing calendaring
> applications like Apple iCal and Mozilla Sunbird, without *any*  
> updates to
> those applications.
>
> This is one of the advantages of basing a microformat standard on well
> adopted other standards.  Instant interoperability.
>
>
>
>>  Of
>> course, Technorati is supporting some of them already....but we don't
>> want something that will be supported by only one vendor
>>
>
> Hence Technorati has from day 1 developed microformats as open  
> standards on
> an open wiki, open for anyone to view (and edit/contribute to).
>
> Note that this is in *stark* contrast to *numerous* other "standards"
> efforts which are typically developed either behind closed doors of a
> paid-membership only committee, or developed on a closed mailing  
> list, or a
> closed wiki, or perhaps just in the closed-mind of a singular blow- 
> hard
> individual.

I find a lot of resistance to Mr. Winer. As I'm new to this stuff,  
I'm not taking sides. I want the best technology, not an anti-person  
format.

>
>
>
>> ...and
>> presumably Technorati would support another XML format, too.
>>
>
> Not necessarily.  A big concern on the part of Technorati (and any  
> other
> search implementer) is data quality, signal to noise.  As such if  
> XML (like
> most) formats encourage invisible metadata, they will be of  
> significantly
> lower utility to Technorati than formats that simply markup already  
> visible
> data.

(presumably Technorati would consider supporting another widely- 
adopted XML format)

>
>
>
>> Thus, microformats, to me, sound like just as much work as would be a
>> separate format (like RSS).
>>
>
> What application / site are you looking at adding microformats too?

I've got several. My personal blog (bokardo.com). Various commercial  
sites...

>
>
>
>> Indeed, many of the microformats are
>> based on living formats written in plaintext or xml. So some are
>> already developed...like iCal,
>>
>
> Non-trivial to author.

It is after one person writes a Wordpress plugin, which takes about a  
day. Remember, only a tiny fraction of RSS feeds are written *by  
hand*...

>
>
>
>> xCal
>>
>
> Tried and failed already.  Effectively zero uptake on the Web.

I think you'll find that after the success of RSS that there will be  
a lot more interest on these types of things. Most the standards work  
was ahead of the curve, in my opinion, and didn't have the attention  
of the average developer (or Wordpress/MT junkie) to write plugins  
for it.

For example, I co-wrote an article on Digital Web this spring  
( http://www.digital-web.com/articles/ 
web_2_for_designers/) ...effectively years behind the initial  
thinking on these subjects, and it gets a lot of attention, not  
because its a *new* idea, but because it is *new to them*. I would  
assume that you've been ahead of the curve for many years. *Most*  
people are not, and are still authoring in ways that would make you  
squirm.

>
>
>
>> and OPML.
>>
>
> <sigh />
>
> A totally unnecessary reinvention of <ol><li><a href>.
>
> Those whose ignore standards are doomed to reinvent them.

Do you have the same opinion of RSS?

>
>
>
>> Therefore, I wonder if there are some applications for which a
>> separate format are better suited,
>>
>
> Perhaps non-web applications?
>
>
>
>> and presumably some applications
>> for which microformats are better suited.
>>
>
> Anything that involves publishing content on the Web.

I'm not sure I understand the "everything through XHTML" point of  
view. Why not embrace the paradigm similar to RSS (and possibly  
Google sitemaps) to have semantic formats at certain conventional  
locations? One possibility is that the index page of a site is going  
to turn into a *true* index page, with a bunch of <link> tags  
pointing to the formats available for discovery. Is this not desirable?

In the same way that we know where to find the root XHTML page, we  
(our UAs) know where to find the root RSS feed. The new Google  
sitemaps format, for example, is the same way.

>
>
>
>> However, I'm hearing this push about microformats...which is all well
>> and good...but I don't know, as a developer, where I should *spend my
>> time*.
>>
>
> What do you develop Josh?  That will probably impact where you  
> spend your
> time.

I was talking, of course, about whether I should spend time updating  
my sites to microformats, or should I say, provide a .ics file  
instead of an hCalendar file (or should I provide both?).

This is a *big deal* for developers, to *change* the way that they do  
things (look at how many people are using table-based layouts). In  
the near future there will be too many formats to choose from (it  
could be that this is already happening).

>
>
>
>> A possible issue to address would be: should I provide OPML or XOXO?
>>
>
> If you are publishing on the web, XOXO.

:)

>
> If not, use whatever outline format is the most convenient  
> (cheapest to
> implement) for you and your actual use cases.
>
>
> Thanks,
>
> Tantek
>

Thanks,

josh


From tantek at cs.stanford.edu  Wed Jul 13 06:56:22 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 06:56:22 2005
Subject: [microformats-discuss] microformats vs. other formats
In-Reply-To: <e8ca2e110507130603763e352f@mail.gmail.com>
Message-ID: <BEFA6B2A.5CF9D%tantek@cs.stanford.edu>

On 7/13/05 6:03 AM, "Carl Beeth" <carl.beeth@gmail.com> wrote:

> Talking of other formats, What will be the relationship between
> microformats and xhtml2's property attribute?
> <http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-metaAttributes.html#sec_23.3
> .>
> Will there be some kind of plan to migrate from the "class" to
> "property" and "title" to "content"

Why bother migrating?


> once xhtml2 is finished?
> Will xhtml2 ever get finished? ;-)

And even when finished, will it be relevant for the web?

As someone who himself spent perhaps 2+ years working on XHTML2, I must
admit it is improving, but in the end, the constraints being pursued are not
conducive to something which will be practical for the web.

In spite of that, there are some good ideas in XHTML2, and if we can reuse
them as necessary, that certainly wouldn't hurt.

Thanks,

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 07:00:22 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 07:00:23 2005
Subject: [microformats-discuss] UA requirements for microformats
In-Reply-To: <Pine.LNX.4.62.0507131256210.27019@dhalsim.dreamhost.com>
Message-ID: <BEFA6C34.5CFA0%tantek@cs.stanford.edu>

On 7/13/05 6:08 AM, "Ian Hickson" <ian@hixie.ch> wrote:

> On Wed, 13 Jul 2005, Tantek ?elik wrote:
>> 
>> First, I agree we need to write up the exact UA conformance
>> requirements.  I believe the microformats community (editors, authors,
>> publishers) accepts that responsibility.
> 
> I know, I just thought I'd raise it again to remind y'all. ;-)

Feel free to remind us :)


>>> and is the second biggest problem stopping microformats being adopted
>>> in the HTML5 specs. (The primary reason is I haven't had the time to
>>> get around to working on those parts of the spec yet.)
>> 
>> Do the HTML5 specs have any sort of specific timeline?
> 
> WF2 was supposed to be in CFI last August, but will probably reach CFI
> this August. So that's roughly twice as long as predicted. (CFI = call for
> implementations, although of course WF2 is being implemented already.)
> 
> So if I say that WA1 (aka HTML5) should be ready for CFI in December 2006,
> it'll probably actually reach CFI in mid 2008.

Good to know.

> But of course implementations of _that_ have started already as well.

Yes.


> Maybe a more useful answer to your question would be to consider what
> order I'll be working on things. I expect the next few weeks to be spent
> on the Window interface (I just did window.history, I'm doing
> window.location now; I may do other window properties before moving on to
> other things). After that I expect I'll look at the Parsing chapter,
> followed probably by looking at events and the attribute event handlers
> and defining those. After that I expect I'll look at the new widgets, like
> <gauge> and <progress>. At this point I'll probably be looking at
> <calendar> and <vcard>. My ETA on that would be end of this year. My
> productivity is likely to soar after the damp of the Oslo summer is over.

Got it.


> However, it depends on demand. If suddenly there is a big demand for a
> spec for a calendar widget, then I'll jump straight to <calendar>.

Or, for folks who are impatient, point them upstream at hCalendar.  That way
we can make sure it works for them.


>> I hypothesize that by the time you get to working on those parts of the
>> spec (specifically hCard and hCalendar), that those specs will be frozen
>> enough for you to depend on them.
> 
> ...I could start working on those parts next week. ;-)

;)


> (Note that there is no guarentee that hCard and hCalendar will be used for
> the HTML5 vCard and iCalendar integration. Currently it seems to be the
> most mature option and I don't see any reason to make up our own, but if
> better proposals come along of course they would be considered too. I'm
> making this explicit because otherwise people say that I'm giving hCard
> and hCalendar preferential treatement and ignoring feedback, which is not
> my intention at all.)

Completely fair, and completely understood.

I'm more than willing to have hCard and hCalendar be measured by their
success in the market and level of maturity (especially since so much of
their maturity, e.g. the core schemas, is already far ahead of nearly any
other contact-info / event effort, short of vCard and iCalendar itself of
course).

Tantek

From rbach at rbach.priv.at  Wed Jul 13 07:22:47 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Wed Jul 13 07:22:15 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <b5e3e031050713050217be00fc@mail.gmail.com>
References: <b5e3e031050713050217be00fc@mail.gmail.com>
Message-ID: <42D523B7.8050009@rbach.priv.at>

Panayotis Vryonis wrote:
> Hi,
> 
> I've been thinking if it would make sense to have a microformat for resumes. 
> I posted some of my thoughts in my blog, 
> http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/<http://http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/>,

I have read it, it sounds interresting.
But I suppose it would be quite hard to design such a microformat.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From tantek at cs.stanford.edu  Wed Jul 13 07:48:04 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 07:48:04 2005
Subject: [microformats-discuss] microformats vs. plain XML formats
In-Reply-To: <8DBDFD1D-B2EC-4B32-8C65-0EF1C2B32966@bokardo.com>
Message-ID: <BEFA7745.5CFAC%tantek@cs.stanford.edu>

On 7/13/05 6:48 AM, "Joshua Porter" <porter@bokardo.com> wrote:

> 
> On Jul 13, 2005, at 8:08 AM, Tantek ?elik wrote:
> 
>> On 7/12/05 2:12 PM, "Joshua Porter" <porter@bokardo.com> wrote:
>> 
>> 
>>> Is it fair to say that microformats are no further along in auto-
>>> discovery than are standalone XML formats?
>>> 
>> 
>> I'm not sure that "auto-discovery" as you use it means the same
>> thing as
>> others use it to mean.  It is a bit of an overloaded term, and as
>> such, a
>> specific use-case would help with understanding what you mean.
> 
> I'm talking about auto-discovery in the sense that Safari and Firefox
> autodiscover RSS feeds and provide additional functionality to them.
> (Danny and Ryan answered this question by saying that browsers don't
> *currently* autodiscover them in this way.)

Ah.  Then the question doesn't make sense as defined, since microformats are
used *in* the content, not somewhere else where a rel="alternate" link
points to.


>>> I ask because I'm confused about the "support" of microformats. I
>>> understand that microformats are "supported" by browsers in the sense
>>> that browsers read them as XHTML.
>>> 
>> 
>> Yes, microformats are built from XHTML building blocks, and thus
>> have all
>> the support that those have, which is a level of support far above
>> "plain"
>> XML.
>> 
>> In addition, microformats can be added to web pages and still have
>> those web
>> pages *validate*, something which is very important to modern web
>> designers.
> 
> Not important to users, however.

Only indirectly important to users, as the likelihood of the page working in
more browsers, more devices etc. goes up.

For the sake of discussion, we take XHTML validity as a requirement.  This
has already been well discussed and understood by modern web designers and
developers.  If you want to explore that, there are other forums where
people would be more than happy to spend time explaining all the why's etc.


>> "plain XML" on the other hand, cannot be added to an XHTML web page
>> and have
>> it still validate, short of doing nasty things like CDATA/escaping the
>> markup, or putting it into comments.  Both of which have already been
>> covered for all the problems they have.
> 
> My RSS feed is full of CDATA escaping, and it works well. Assuming
> this is bad, though, could you provide a pointer to the coverage?

Check xml.com articles.  For more discussion on this, again, there are other
lists that have done a better job on it.  A little research on "escaped XML"
or "escaped markup" should be sufficient.


>>> But that's not really doing
>>> anything with the semantics we've added to our markup. (we might as
>>> well be writing in any arbitrary format).
>>> 
>> 
>> Not at all.  XHTML has numerous predefined semantics.  "plain XML"
>> has none
>> (except perhaps the xml:lang attribute).
> 
> By this I mean that if UAs aren't doing anything with the semantic
> markup, it doesn't matter that it is semantic.

Actually, it does.  Regardless of whether there is any default behavior by
the UA, the semantics are there for any number of other "UA-like" extensions
to take advantage of it.

The benefits of semantic XHTML are *also* well known in the web design and
web authoring community.  Another point I see no reason to argue.


>>> Taken further, it seems to me that for anything to be done with
>>> microformats, our UAs will need to be updated in some fashion.
>>> 
>> 
>> No.  *could be* updated, yes.
>> 
>> *need to be* updated? No.  For example, tons have been done with
>> styling
>> microformats with built-in CSS support, utilizing microformats with
>> favelets/bookmarklets, Grease Monkey plugins etc.  None of which
>> required
>> updating the browser.
> 
> I would consider bookmarklets and Grease Monkey scripts as updating
> the UA. (or at least the functionality of the UA).

That's a bit of a cop out.

No one I know would consider adding a few bookmarks to be "updating" their
UA.

My point was, we don't need to wait for any kind of "update of the UA" as
typical people think of UA updates (i.e. download a new browser).

> This is a good  
> thing...that it is easy to add functionality relatively quickly.

Yes.


>> Similarly, you can subscribe to hCalendar in existing calendaring
>> applications like Apple iCal and Mozilla Sunbird, without *any*
>> updates to
>> those applications.
>> 
>> This is one of the advantages of basing a microformat standard on well
>> adopted other standards.  Instant interoperability.
>> 
>> 
>> 
>>>  Of
>>> course, Technorati is supporting some of them already....but we don't
>>> want something that will be supported by only one vendor
>>> 
>> 
>> Hence Technorati has from day 1 developed microformats as open
>> standards on
>> an open wiki, open for anyone to view (and edit/contribute to).
>> 
>> Note that this is in *stark* contrast to *numerous* other "standards"
>> efforts which are typically developed either behind closed doors of a
>> paid-membership only committee, or developed on a closed mailing
>> list, or a
>> closed wiki, or perhaps just in the closed-mind of a singular blow-
>> hard
>> individual.
> 
> I find a lot of resistance to Mr. Winer.

It is amazing how certain individuals can generate so much self-resistance.

I'm sure there are lessons to be learned there.

But no matter, we try not to be distracted by the blow-hards.


> As I'm new to this stuff,
> I'm not taking sides. I want the best technology,

Precisely why we defined microformats in terms of a set of technology
principles.


> not an anti-person format.

No one I know here wants that either.  IMHO, it is a waste of time to pursue
such things.


>>> ...and
>>> presumably Technorati would support another XML format, too.
>>> 
>> 
>> Not necessarily.  A big concern on the part of Technorati (and any
>> other
>> search implementer) is data quality, signal to noise.  As such if
>> XML (like
>> most) formats encourage invisible metadata, they will be of
>> significantly
>> lower utility to Technorati than formats that simply markup already
>> visible
>> data.
> 
> (presumably Technorati would consider supporting another widely-
> adopted XML format)

Technorati already supports parsing of RSS and Atom to quite a level of
detail for example.  So the short answer is yes.  But I have to admit that
is a bit off topic for this list as well.  You're welcome to continue that
discussion by sending email to feedback at technorati.


>>> Thus, microformats, to me, sound like just as much work as would be a
>>> separate format (like RSS).
>>> 
>> 
>> What application / site are you looking at adding microformats too?
> 
> I've got several. My personal blog (bokardo.com). Various commercial
> sites...

Good.  A personal blog is a good place to start with microformat publishing
experiments.


>>> Indeed, many of the microformats are
>>> based on living formats written in plaintext or xml. So some are
>>> already developed...like iCal,
>>> 
>> 
>> Non-trivial to author.
> 
> It is after one person writes a Wordpress plugin, which takes about a
> day. Remember, only a tiny fraction of RSS feeds are written *by
> hand*...

There are now enough CMS's and blogging systems that no one custom plugin
will make that big a dent.

Thus the cost of publishing must be lowered.

And I would bet that it would take more than a day for someone to write a
valid iCal Wordpress plugin that outputted valid iCalendar that various
clients could consume, that actually provided a UI for useful functionality
etc.

Just look at how long other iCal efforts have taken.


>>> xCal
>>> 
>> 
>> Tried and failed already.  Effectively zero uptake on the Web.
> 
> I think you'll find that after the success of RSS that there will be
> a lot more interest on these types of things. Most the standards work
> was ahead of the curve, in my opinion, and didn't have the attention
> of the average developer (or Wordpress/MT junkie) to write plugins
> for it.

Perhaps.  OTOH, I predict the various "do it yourself" XML vocabularies will
deteriorate rapidly to a tower of babel problem, with everyone making up
their own.

And remember, RSS took almost 10 years to become as dominant as it has.


> For example, I co-wrote an article on Digital Web this spring
> ( http://www.digital-web.com/articles/
> web_2_for_designers/) ...effectively years behind the initial
> thinking on these subjects, and it gets a lot of attention, not
> because its a *new* idea, but because it is *new to them*.


>Writing Semantic Markup: Transition to XML

With all due respect, that section fails to make that case.

Generic XML effectively died on the Web under the weight of all the specs
required to make it "work" half as well as HTML, and the under the friction
of incompatibility with the way people already worked, and under the
syntactic vinegar of awkward (and mostly unnecessary) constructs like
namespaces.  Dozens of XML formats have been tried for *years* on the *web*
have failed.  Only two have gained any adoption on the *web*: RSS and XHTML.

Also, your article talks about the limits of semantics in XHTML.

Precisely why we are doing microformats!

To extend those semantics in an interoperable, evolutionary way.

Rather than throwing out everything that works and asking people to learn a
new set of tools.


> RSS is one of the key building blocks

Hah! RSS is nothing more than a degenerate envelope format (AKA feed
format).

It's certainly not a building block for other formats.  It's a top level
container format, and that's about it.

Seriously are there any other building blocks along that vision?

It took 10 years for the so-called building block of RSS to be practical.


Contrast that with microformats where within months we've got numerous
*actual* building blocks you can use *today*, you can mix and match *today*,
you can *publish* *today*.


Finally, with all due respect, there are *a lot* of fluff/hype pieces coming
out about the so-called "Web 2.0" (NOTE: Your article was *MUCH* better
written than the vast majority of such articles, I'm not lumping your
article in with the rest, let me be clear about that).  It's an excellent
way to get headlines and attention, but so far, the visions offered have
been such a mishmash that people get more confused than productive.


Your bits about mixing and matching RESTian web services are certainly right
on, and in many ways, were an evolutionary reaction to the prescribed
methods of WSDL, SOAP etc.

Microformats are a very similar evolutionary reaction to the prescribed
methods of generic XML or RDF.

Phil Windley provided an excellent summary of this:

 http://www.windley.com/archives/2005/07/microformats.shtml



> I would  
> assume that you've been ahead of the curve for many years. *Most*
> people are not, and are still authoring in ways that would make you
> squirm.

At a recent presentation to web designers in SXSW, in a room filled with
100s of people, I asked who was still using <table> tags for layout in their
work.  Only 2 people raised their hands.

I think you might be surprised where today's web design community is.



>>> and OPML.
>>> 
>> 
>> <sigh />
>> 
>> A totally unnecessary reinvention of <ol><li><a href>.
>> 
>> Those whose ignore standards are doomed to reinvent them.
> 
> Do you have the same opinion of RSS?

I believe Danny Ayers already provided a good statement about that.


>>> Therefore, I wonder if there are some applications for which a
>>> separate format are better suited,
>>> 
>> 
>> Perhaps non-web applications?
>> 
>> 
>> 
>>> and presumably some applications
>>> for which microformats are better suited.
>>> 
>> 
>> Anything that involves publishing content on the Web.
> 
> I'm not sure I understand the "everything through XHTML" point of
> view.

Are you a web designer?


> Why not embrace the paradigm similar to RSS (and possibly
> Google sitemaps) to have semantic formats at certain conventional
> locations?

That fails the embeddability principle (for all practical purposes) we put
forth as a requirement.


> One possibility is that the index page of a site is going
> to turn into a *true* index page, with a bunch of <link> tags
> pointing to the formats available for discovery. Is this not desirable?

It's more work for less benefit.

New languages = cost.

New file formats = cost.

Lots of separate files = maintenance, more cost.

Lots of separate files = you lose context.  You lose embeddability.

Lots of separate files != building blocks.

Lots of separate files == data silos.


> In the same way that we know where to find the root XHTML page, we
> (our UAs) know where to find the root RSS feed. The new Google
> sitemaps format, for example, is the same way.

And completely unsuitable for mixing and matching with anything else as a
building block. 

It's a data silo.


>>> However, I'm hearing this push about microformats...which is all well
>>> and good...but I don't know, as a developer, where I should *spend my
>>> time*.
>>> 
>> 
>> What do you develop Josh?  That will probably impact where you
>> spend your
>> time.
> 
> I was talking, of course, about whether I should spend time updating
> my sites to microformats, or should I say, provide a .ics file
> instead of an hCalendar file (or should I provide both?).

The point is that if you are already publishing event data as part of your
website, it is *easier* and *cheaper* to simply mark it up with hCalendar,
than to bother with .ics files.

*Plus* you keep all the context of your web pages, which is lost when you
dumb down to an .ics feed.

I think of this purely economically.

What's easiest/cheapest for you to provide with the maximum benefit?

The premise here is that if you simply markup your current event data in
your web page with hCalendar, then you get the .ics file for free via
translation.


> This is a *big deal* for developers, to *change* the way that they do
> things (look at how many people are using table-based layouts).

Right.  Hence microformats tries to ask web designers/authors to change the
least.


> In  
> the near future there will be too many formats to choose from (it
> could be that this is already happening).

It has.  It is.  

One of the reasons why when someone proposes a new microformat, the
community and process strongly discourages it until a *real-world*
*practical* need is shown.


>>> A possible issue to address would be: should I provide OPML or XOXO?
>>> 
>> 
>> If you are publishing on the web, XOXO.
> 
> :)
> 
>> 
>> If not, use whatever outline format is the most convenient
>> (cheapest to implement) for you and your actual use cases.
>> 
>> 
>> Thanks,
>> 
>> Tantek
>> 
> 
> Thanks,
> 
> josh

Thanks Josh, I appreciate the points you have made, and I think that the
discussion has hopefully helped to illuminate some of the reasons why we are
doing what we are doing.

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 07:52:05 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 07:52:04 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <42D523B7.8050009@rbach.priv.at>
Message-ID: <BEFA7845.5CFB0%tantek@cs.stanford.edu>

On 7/13/05 7:22 AM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:

> Panayotis Vryonis wrote:
>> Hi,
>> 
>> I've been thinking if it would make sense to have a microformat for resumes.
>> I posted some of my thoughts in my blog,
>> http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense
>> /<http://http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-m
>> ake-sense/>,
> 
> I have read it, it sounds interresting.
> But I suppose it would be quite hard to design such a microformat.

Indeed.  My first challenge to anyone wanting to design such a microformat
is to update their resume to use what they have in mind ;)

Pending that, a "resume-formats" wiki page might be a good place to start
with analysis and research of current examples on the web.

Thanks,

Tantek

From danny.ayers at gmail.com  Wed Jul 13 07:52:06 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 07:52:10 2005
Subject: [microformats-discuss] what gets pruned/closed,
	making existing web data useful
In-Reply-To: <BEFA590A.5CF7F%tantek@cs.stanford.edu>
References: <1f2ed5cd05071305155587892c@mail.gmail.com>
	<BEFA590A.5CF7F%tantek@cs.stanford.edu>
Message-ID: <1f2ed5cd050713075271bc3875@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> On 7/13/05 5:15 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:
> 
> > Forgive me, I misinterpreted the word "discuss" in the mailing list
> > name.
> 
> 
> Not at all.  There are tons of things for us to discuss!
> 
> However, there are topics where discussion is counterproductive and/or a
> waste of time (I have sufficient experience on W3C and other standards
> mailing lists to make this observation).  Some topics are don't have the
> necessary cost/benefit to be worth discussing, and thus I will be doing some
> amount of pruning as necessary to keep this list as productive as possible.

Hmm, I'm sorry about my irritable reaction, but there's another factor
in the cost/benefit equation, that of who bears the cost/gains the
benefit.

Using my own RDF/SPARQL play as an example, where there's mixing and
interconnection of data from a variety of sources, for microformats to
be a useful source of data term disambiguation is pretty vital. So
however chicken-little naming clashes might be, their occurrence could
potentially be catastrophic. I really don't think they will an issue,
having profile URI(s) easily available will push clashes way out into
improbability-land. But that does mean there's a far higher premium on
those profile URIs than there would be for say building a stylish
microcontent viewer.

> > These projects have at least one goal in
> > common: putting more useful data on the Web.
> 
> Sort of.  There is actually a very key distinction here in the microformats
> approach that sets a different approach.
> 
> Microformats are much more about:
> 
>  Making the data that people *are already publishing* on the *web* more
> useful.
> 
> Rather than:
> 
>  Putting more useful data on the web.
> 
> That's a fine distinction, but a very important one that focuses our
> efforts.

Thank you, that's a very helpful way of putting it.

Cheers,
Danny.

-- 

http://dannyayers.com
From carl.beeth at gmail.com  Wed Jul 13 07:52:52 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Wed Jul 13 07:52:55 2005
Subject: [microformats-discuss] microformats vs. other formats
In-Reply-To: <BEFA6B2A.5CF9D%tantek@cs.stanford.edu>
References: <e8ca2e110507130603763e352f@mail.gmail.com>
	<BEFA6B2A.5CF9D%tantek@cs.stanford.edu>
Message-ID: <e8ca2e1105071307524d865ff3@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> Why bother migrating?
because it is the more semantic alternative?

Don't get me wrong, I completely agree with the current microformat
approach but I also think it is relevant to look a little ahead
towards future standards and make sure they map on to each other. In
this case it seems to map perfectly.

Carl
From vrypan at gmail.com  Wed Jul 13 08:00:17 2005
From: vrypan at gmail.com (Panayotis Vryonis)
Date: Wed Jul 13 08:01:01 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <42D523B7.8050009@rbach.priv.at>
References: <b5e3e031050713050217be00fc@mail.gmail.com>
	<42D523B7.8050009@rbach.priv.at>
Message-ID: <b5e3e0310507130800d5eb943@mail.gmail.com>

Do you think so? I mean, of course it would be nearly impossible to include 
ALL information included in a normal resume. 
However, apart from the "id" (name, surname, birth date, etc.) fields that 
are easy to encode, one could also map "knowledge" and a rank 1-5 much like 
it's proposed in hreview for "categories" [
hreview<http://www.microformats.org/wiki/hreview>].

Suppose we had a reasonable mapping of "id", "knowledge", "experience", what 
kind of inportant information is left out?

I do not consider myself to be not even close to an XML expert, but to me it 
sounds feasible to roll out a resume microformat that could be useful and 
valuable.

P.

On 7/13/05, Robert Bachmann <rbach@rbach.priv.at> wrote:
> 
> Panayotis Vryonis wrote:
> > Hi,
> >
> > I've been thinking if it would make sense to have a microformat for 
> resumes.
> > I posted some of my thoughts in my blog,
> > 
> http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/
> <
> http://http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/
> >,
> 
> I have read it, it sounds interresting.
> But I suppose it would be quite hard to design such a microformat.
> 
> Robert
> --
> Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
> 



-- 
The content of this email is:
[]blogable [x]ask first []personal
--
panayotis vryonis
http://vrypan.net/log/
http://g-metrics.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050713/e9c37b38/attachment.htm
From tantek at cs.stanford.edu  Wed Jul 13 08:03:03 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 08:03:04 2005
Subject: [microformats-discuss] microformats vs. other formats
In-Reply-To: <e8ca2e1105071307524d865ff3@mail.gmail.com>
Message-ID: <BEFA7AFC.5CFB7%tantek@cs.stanford.edu>

On 7/13/05 7:52 AM, "Carl Beeth" <carl.beeth@gmail.com> wrote:

> On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
>> Why bother migrating?
> because it is the more semantic alternative?

I agree with your premise of more semantic being better.

But more semantic compared to what?

IMHO, XHTML1 + current microformats (hCard, hCalendar, hReview, RelTag,
xFolk, etc.) is already  *MUCH MORE* semantic than XHTML2 seeks to be.


> Don't get me wrong, I completely agree with the current microformat
> approach but I also think it is relevant to look a little ahead
> towards future standards and make sure they map on to each other.

It doesn't hurt to consider similar efforts for at least "conceptual" parity
where it helps the principles we have put forth.


> In this case it seems to map perfectly.

>From my discussions with key XHTML2 folks and key RDF folks at the WWW2005
conference, I must agree.

There is *far* more ability to reuse microformats in XHTML2 and RDF than any
kind of conflict per se.

In many ways, microformats may help provide a common way for folks to both
evolve current XHTML practices, and allow folks working with XHTML2, RDF
etc. to take better advantage of this "enhanced" XHTML that is being
published on the web today.

Thanks,

Tantek

From danny.ayers at gmail.com  Wed Jul 13 08:04:20 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 08:04:22 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <BEFA7845.5CFB0%tantek@cs.stanford.edu>
References: <42D523B7.8050009@rbach.priv.at>
	<BEFA7845.5CFB0%tantek@cs.stanford.edu>
Message-ID: <1f2ed5cd0507130804720ef74c@mail.gmail.com>

Might be useful:

http://captsolo.net/semweb/

"Modelling of Resume Data in the Semantic Web Using RDF"

I've only glanced at it, but the model seems fairly straightforward,
easily mappable to/from a microformat.


-- 

http://dannyayers.com
From michael.gorsuch at gmail.com  Wed Jul 13 08:05:03 2005
From: michael.gorsuch at gmail.com (Michael Gorsuch)
Date: Wed Jul 13 08:05:06 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <b5e3e0310507130800d5eb943@mail.gmail.com>
References: <b5e3e031050713050217be00fc@mail.gmail.com>
	<42D523B7.8050009@rbach.priv.at>
	<b5e3e0310507130800d5eb943@mail.gmail.com>
Message-ID: <2a3f927b050713080566a29953@mail.gmail.com>

I was thinking of this earlier this week.  Why not keep it as simple
as possible:

Can we embed an hcard for contact info, and essentially leave room for
a 'body' or 'content' attribute that would house the resume itself.

The point is to make it easy to aggregate, correct?  So just keep the
format very lean, and allow 'recruiters' search for certain keywords
in the 'content' via their aggregation system.

On 7/13/05, Panayotis Vryonis <vrypan@gmail.com> wrote:
> Do you think so? I mean, of course it would be nearly impossible to include
> ALL information included in a normal resume. 
>  However, apart from the "id" (name, surname, birth date, etc.) fields that
> are easy to encode, one could also map "knowledge" and a rank 1-5 much like
> it's proposed in hreview for "categories" [ hreview ].
>  
>  Suppose we had a reasonable mapping of "id", "knowledge", "experience",
> what kind of inportant information is left out?
>  
>  I do not consider myself to be not even close to an XML expert, but to me
> it sounds feasible to roll out a resume microformat that could be useful and
> valuable.
>  
>  P.
> 
> On 7/13/05, Robert Bachmann <rbach@rbach.priv.at> wrote:
> > Panayotis Vryonis wrote:
> > > Hi,
> > >
> > > I've been thinking if it would make sense to have a microformat for
> resumes.
> > > I posted some of my thoughts in my blog,
> > >
> http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/<http://http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it-make-sense/
> >,
> > 
> > I have read it, it sounds interresting.
> > But I suppose it would be quite hard to design such a microformat.
> > 
> > Robert
> > --
> > Robert Bachmann <rbach@rbach.priv.at > (OpenPGP KeyID: 0x4A5CCF10)
> > 
> 
> 
> 
> -- 
> The content of this email is:
> []blogable [x]ask first []personal
> 
> --
> panayotis vryonis
> http://vrypan.net/log/ 
> http://g-metrics.com/ 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 
> 
>
From tantek at cs.stanford.edu  Wed Jul 13 08:25:43 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 08:25:44 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <1f2ed5cd0507130804720ef74c@mail.gmail.com>
Message-ID: <BEFA7FE8.5CFC1%tantek@cs.stanford.edu>

On 7/13/05 8:04 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> Might be useful:
> 
> http://captsolo.net/semweb/
> 
> "Modelling of Resume Data in the Semantic Web Using RDF"
> 
> I've only glanced at it, but the model seems fairly straightforward,
> easily mappable to/from a microformat.

While I think it can be useful to look at *any* earlier attempt at a format,
it is important to place a higher priority on mapping to actual content
being published on the web today, and see what implied schemas can be
derived from that content (and hopefully simplified to the minimum for a
first attempt).

Often such "practical" implied schemas are much better "tuned"/"optimized"
than explicit schemas in (proposed) standards.

Thanks,

Tantek

From danny.ayers at gmail.com  Wed Jul 13 08:29:52 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 08:29:53 2005
Subject: [microformats-discuss] microformats vs. plain XML formats
In-Reply-To: <BEFA7745.5CFAC%tantek@cs.stanford.edu>
References: <8DBDFD1D-B2EC-4B32-8C65-0EF1C2B32966@bokardo.com>
	<BEFA7745.5CFAC%tantek@cs.stanford.edu>
Message-ID: <1f2ed5cd050713082911f288ab@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:

> Microformats are a very similar evolutionary reaction to the prescribed
> methods of generic XML or RDF.

If you're talking about the use of the RDF/XML format, then I'd
probably have to agree. But the RDF model solves at least one problem
that isn't addressed by generic XML or microformats, how to integrate
data from different sources and different domains in a useful fashion.

Ok, it's largely out of scope for any purpose-specific XML, or for doc
publication. But it is something needed to take the Web beyond being
just a document repository (without an index). Many Web systems are
backed by SQL databases, but there's an impedance mismatch between
their relational model and that of the Web. You can't directly mix
data from one SQL store with that of another. On the other hand, the
graph-shaped, URI-based relational model of RDF has been designed with
the (Semantic) Web in mind, and just that kind of mixing. It's long
timescale stuff, but most of the groundwork's been done and
deployments are starting to happen.

You know I couldn't leave that one unchallenged ;-)

Cheers,
Danny.

-- 

http://dannyayers.com
From tantek at cs.stanford.edu  Wed Jul 13 08:39:44 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 08:39:43 2005
Subject: [microformats-discuss] what gets pruned/closed, making
	existing web data useful
In-Reply-To: <1f2ed5cd050713075271bc3875@mail.gmail.com>
Message-ID: <BEFA8378.5CFC6%tantek@cs.stanford.edu>

On 7/13/05 7:52 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> Hmm, I'm sorry about my irritable reaction,

No apology necessary Danny.  I know you want to make all this stuff work.


> but there's another factor
> in the cost/benefit equation, that of who bears the cost/gains the
> benefit.

That's a very reasonable question to bring up.

With microformats we are deliberately optimizing to minimize costs for the
most humans.

What does that mean?

That typically translates to:
 - easier to hand author (even if few bits end up hand authors, most *start*
that way, especially developers, they start that way).
 - easier to build into *current* pages
 - easier to build into *current* publishing systems

In my opinion the publishers are providing the most value here, so therefore
they should have to bear as little of the cost as possible.

On the other hand, the indexers/consumers/aggregators etc. will derive more
of the value, and therefore it is reasonable to ask them to bear a bit more
of the cost.

This is a bit of the opposite of "traditional" format efforts which are
typically more programmer focused (rather than publisher focused), and end
up being easier to code to consume, but harder, or more inconvenient to code
to produce.


> Using my own RDF/SPARQL play as an example, where there's mixing and
> interconnection of data from a variety of sources, for microformats to
> be a useful source of data term disambiguation is pretty vital.

Ok, I'll take your real-world example (I'm assuming by "play" you mean
something you built) as a given.


> So
> however chicken-little naming clashes might be, their occurrence could
> potentially be catastrophic.

I'm really not afraid of them because I think with judicious discussion and
design, we can actually proactively avoid 99% of the problems.

We do things like:

 1. pick unique root class names like vcard, vcalendar, hreview, xfolkentry,
and let contained class names be defined by context if necessary.

 2. for the same concept, we use the same name.  we use "description" in
hCalendar, and thus in hReview, and now in xFolks as well, rather than
"description", and then "review-text", and then "extended".

 3. for different concepts, use different names.

We keep the number of vocabulary terms used as minimal as possible, as
opposed to encouraging an explosion.  We re-use current terms whenever
possible rather than reinventing new terms.


> I really don't think they will an issue,

Agreed.


> having profile URI(s) easily available will push clashes way out into
> improbability-land.

Yes.  That plus healthy communication/discussion.  No silos.  No Chinese
Walls.


> But that does mean there's a far higher premium on
> those profile URIs

I don't understand what you mean by higher premium here.


> than there would be for say building a stylish
> microcontent viewer.

microcontent is meaningless if it's not built from one or more microformats.

This is why I prefer to focus the discussion on the microformats, rather
than bandying about what is little more than a buzzword "microcontent".

Thanks,

Tantek

From danny.ayers at gmail.com  Wed Jul 13 08:42:57 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 08:42:59 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <BEFA7FE8.5CFC1%tantek@cs.stanford.edu>
References: <1f2ed5cd0507130804720ef74c@mail.gmail.com>
	<BEFA7FE8.5CFC1%tantek@cs.stanford.edu>
Message-ID: <1f2ed5cd0507130842517d0ebc@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:

> Often such "practical" implied schemas are much better "tuned"/"optimized"
> than explicit schemas in (proposed) standards.

Yep, agreed 100%. 

I'd also add that the notion of a "standard" for a particular domain
(like resumes, reviews, whatever) is less significant around RDF than
most schema languages - you can cherry pick what you like from where
you like, ignore what you don't want, add bits yourself as needed.



-- 

http://dannyayers.com
From tantek at cs.stanford.edu  Wed Jul 13 08:47:45 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 08:47:45 2005
Subject: [microformats-discuss] microformats vs. plain XML formats
In-Reply-To: <1f2ed5cd050713082911f288ab@mail.gmail.com>
Message-ID: <BEFA8547.5CFCA%tantek@cs.stanford.edu>

On 7/13/05 8:29 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

> On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> 
>> Microformats are a very similar evolutionary reaction to the prescribed
>> methods of generic XML or RDF.
> 
> If you're talking about the use of the RDF/XML format, then I'd
> probably have to agree.

Yes.  In typical conversation, especially in the context of the web, when
people mention RDF, they mean the (predominant RDF/XML) format.


> But the RDF model solves at least one problem
> that isn't addressed by generic XML or microformats, how to integrate
> data from different sources and different domains in a useful fashion.

At least attempts to address, but I really don't want to get into that
argument.  I've seen people be successful building their own internal
systems this way, and I've seen people struggle.  I leave it to you and
everybody else to pick whatever internal model works best for you.  I don't
think that is something we have to agree on, and arguing about it will only
be counterproductive.

I think we can have microformat discussions independent of any given
internal model.

Through discussions with you Danny, and numerous other folks like Dave
Beckett and many other SemWeb folks at WWW2005, I'm fully convinced that you
can map microformats into RDF if that is what you wish to do.  So for all
the power that affords you, more power to you.

I also know that for some folks, who want to only do a few simple things,
they don't need that power, and so they may use microformats directly with a
database.  Perhaps limited, but that is ok.  Perhaps that's all they need.


> You know I couldn't leave that one unchallenged ;-)

It was not meant to be a challenge, I apologize for that.

Tantek

From danny.ayers at gmail.com  Wed Jul 13 08:56:12 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Wed Jul 13 08:56:19 2005
Subject: [microformats-discuss] what gets pruned/closed,
	making existing web data useful
In-Reply-To: <BEFA8378.5CFC6%tantek@cs.stanford.edu>
References: <1f2ed5cd050713075271bc3875@mail.gmail.com>
	<BEFA8378.5CFC6%tantek@cs.stanford.edu>
Message-ID: <1f2ed5cd05071308561364f9bd@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> On 7/13/05 7:52 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:
> 
> > Hmm, I'm sorry about my irritable reaction,
> 
> No apology necessary Danny.  I know you want to make all this stuff work.

Yup. Impatiently ;-)

> We do things like:
> 
>  1. pick unique root class names like vcard, vcalendar, hreview, xfolkentry,
> and let contained class names be defined by context if necessary.
> 
>  2. for the same concept, we use the same name.  we use "description" in
> hCalendar, and thus in hReview, and now in xFolks as well, rather than
> "description", and then "review-text", and then "extended".
> 
>  3. for different concepts, use different names.
> 
> We keep the number of vocabulary terms used as minimal as possible, as
> opposed to encouraging an explosion.  We re-use current terms whenever
> possible rather than reinventing new terms.

Interesting, that's quite algorithmic. Getting the microformat
designers and the parser-generators reading from the same script would
be nice ;-)

> > But that does mean there's a far higher premium on
> > those profile URIs
> 
> I don't understand what you mean by higher premium here.

The cost/benefit is levered, so from this point of view, (slightly
exagerrated), *with* profile URIs, the microformats represent valuable
data, *without* they're just noise.
 
> > than there would be for say building a stylish
> > microcontent viewer.
> 
> microcontent is meaningless if it's not built from one or more microformats.
> 
> This is why I prefer to focus the discussion on the microformats, rather
> than bandying about what is little more than a buzzword "microcontent".

Oops, sorry, that was a slip of the keys (que faux pas!!). What I was
trying to describe was something that just gave an immediate
representation of microformat data, rather than having mixed the data
with other material and made inferences based on the combination.
Errors in the former would generally be proportional from input to
output, in the latter...watch that sky!

Cheers,
Danny.

-- 

http://dannyayers.com
From carl.beeth at gmail.com  Wed Jul 13 09:02:22 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Wed Jul 13 09:02:30 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <2a3f927b050713080566a29953@mail.gmail.com>
References: <b5e3e031050713050217be00fc@mail.gmail.com>
	<42D523B7.8050009@rbach.priv.at>
	<b5e3e0310507130800d5eb943@mail.gmail.com>
	<2a3f927b050713080566a29953@mail.gmail.com>
Message-ID: <e8ca2e1105071309027db1c0f9@mail.gmail.com>

On 7/13/05, Michael Gorsuch <michael.gorsuch@gmail.com> wrote:
> I was thinking of this earlier this week.  Why not keep it as simple
> as possible:
> 
> Can we embed an hcard for contact info, and essentially leave room for
> a 'body' or 'content' attribute that would house the resume itself.
> 
> The point is to make it easy to aggregate, correct?  So just keep the
> format very lean, and allow 'recruiters' search for certain keywords
> in the 'content' via their aggregation system.

Just don't simplify it to uselessness, in the end if it is aggregated
you will want to be process the information in it. and hcard +
body-field does not leave much information on which to do meaningful
processing.
From tantek at cs.stanford.edu  Wed Jul 13 09:08:49 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 09:08:48 2005
Subject: [microformats-discuss] what gets pruned/closed, making
	existing web data useful
In-Reply-To: <1f2ed5cd05071308561364f9bd@mail.gmail.com>
Message-ID: <BEFA8A58.5CFD3%tantek@cs.stanford.edu>

On 7/13/05 8:56 AM, "Danny Ayers" <danny.ayers@gmail.com> wrote:

>> We do things like:
>> 
>>  1. pick unique root class names like vcard, vcalendar, hreview, xfolkentry,
>> and let contained class names be defined by context if necessary.
>> 
>>  2. for the same concept, we use the same name.  we use "description" in
>> hCalendar, and thus in hReview, and now in xFolks as well, rather than
>> "description", and then "review-text", and then "extended".
>> 
>>  3. for different concepts, use different names.
>> 
>> We keep the number of vocabulary terms used as minimal as possible, as
>> opposed to encouraging an explosion.  We re-use current terms whenever
>> possible rather than reinventing new terms.
> 
> Interesting, that's quite algorithmic. Getting the microformat
> designers and the parser-generators reading from the same script would
> be nice ;-)

Indeed.  These algorithms/principles are not obvious at all (IMHO). It's
taken years of mistakes to come up with them. :)


>>> But that does mean there's a far higher premium on
>>> those profile URIs
>> 
>> I don't understand what you mean by higher premium here.
> 
> The cost/benefit is levered, so from this point of view, (slightly
> exagerrated), *with* profile URIs, the microformats represent valuable
> data, *without* they're just noise.

I understand the exaggeration to make the point.

The reason for (1) above (relatively unique root class names) is give us an
"out" for things to be able to work potentially even without the explicit
profile declaration, should it be necessary.

It is very doubtful any designer etc. will use a class name like vcard,
vcalendar, therefore, when you see such names, it is a good bet that they
unique relate to a specific profile.  That's by no means 100% precise, nor
ideal, but it provides a fallback.


>>> than there would be for say building a stylish
>>> microcontent viewer.
>> 
>> microcontent is meaningless if it's not built from one or more microformats.
>> 
>> This is why I prefer to focus the discussion on the microformats, rather
>> than bandying about what is little more than a buzzword "microcontent".
> 
> Oops, sorry, that was a slip of the keys (que faux pas!!). What I was
> trying to describe was something that just gave an immediate
> representation of microformat data,

I think we'll see a lot of that at first.

> rather than having mixed the data
> with other material and made inferences based on the combination.

Those applications will come later I think.

> Errors in the former would generally be proportional from input to
> output, in the latter...watch that sky!

Indeed.  Combinations can introduce interesting levels of complexity.  So
let's try to keep the building blocks simple. ;)

Thanks,

Tantek

From ryan at technorati.com  Wed Jul 13 09:08:59 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 13 09:09:00 2005
Subject: [microformats-discuss] Discovery of microformats
In-Reply-To: <1f2ed5cd050713021322750320@mail.gmail.com>
References: <8244713B-2098-42E4-99FE-2FCE0F65B251@technorati.com>
	<006e01c58740$75a065f0$6464a8c0@hellonwheels>
	<1f2ed5cd050713021322750320@mail.gmail.com>
Message-ID: <8A17F771-43BE-4620-B4C6-F5A1483FAA0F@technorati.com>

On Jul 13, 2005, at 2:13 AM, Danny Ayers wrote:
> On 7/13/05, Eran <limbo@speakeasy.net> wrote:
>>> I believe Brian Suda was working on a parser/validator for xmdp.
>>>
>>> However, as I'm sure you've noticed, the real guts of an xmdp
>>> are the
>>> prose descriptions of the elements. So, just like other
>>> microformats,
>>> xmdp is for "humans first and machines second."
>>>
>
> Well yes, that's a nice slogan, but I've yet to see a microformat used
> without machine involvement. XHTML+CSS can already provide
> human-readable representations of information, what I believe
> microformats bring to the table is a way of making that information
> explicit in a machine-readable form.

You're right- we let machines into the microformats party from time  
to time. :) But, as a design principle "humans first, machines  
second" helps us keep focused on developing technology that can be  
easily comprehended and composed by mere mortals.

-ryan
From tantek at cs.stanford.edu  Wed Jul 13 09:12:50 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 09:12:50 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <e8ca2e1105071309027db1c0f9@mail.gmail.com>
Message-ID: <BEFA8B42.5CFD7%tantek@cs.stanford.edu>

On 7/13/05 9:02 AM, "Carl Beeth" <carl.beeth@gmail.com> wrote:

> On 7/13/05, Michael Gorsuch <michael.gorsuch@gmail.com> wrote:
>> I was thinking of this earlier this week.  Why not keep it as simple
>> as possible:
>> 
>> Can we embed an hcard for contact info, and essentially leave room for
>> a 'body' or 'content' attribute that would house the resume itself.
>> 
>> The point is to make it easy to aggregate, correct?  So just keep the
>> format very lean, and allow 'recruiters' search for certain keywords
>> in the 'content' via their aggregation system.
> 
> Just don't simplify it to uselessness, in the end if it is aggregated
> you will want to be process the information in it. and hcard +
> body-field does not leave much information on which to do meaningful
> processing.

Indeed, no one wants it to be useless.

However, there is something to be said for simplifying it so much that you
fail to provide enough features for some folks, or at least what they think
they need.

And then iterate and slowly add minimal features as necessary.

Then again, I have a feeling that much of what goes into a resume can be
built from the current microformat building blocks in quite a
straightforward fashion.

But for example, if a list of skills for now was nothing but an unordered
list, that might be ok.  Just one example for the sake of discussion.

Thanks,

Tantek

From vrypan at gmail.com  Wed Jul 13 09:34:35 2005
From: vrypan at gmail.com (Panayotis Vryonis)
Date: Wed Jul 13 09:35:19 2005
Subject: [microformats-discuss] Brainstorming on a "resume" microformat
In-Reply-To: <BEFA8B42.5CFD7%tantek@cs.stanford.edu>
References: <e8ca2e1105071309027db1c0f9@mail.gmail.com>
	<BEFA8B42.5CFD7%tantek@cs.stanford.edu>
Message-ID: <b5e3e031050713093448f82c3@mail.gmail.com>

I'll send an example as soon as possible. I'm "recruiting" now :-)

P.

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> 
> On 7/13/05 9:02 AM, "Carl Beeth" <carl.beeth@gmail.com> wrote:
> 
> > On 7/13/05, Michael Gorsuch <michael.gorsuch@gmail.com> wrote:
> >> I was thinking of this earlier this week. Why not keep it as simple
> >> as possible:
> >>
> >> Can we embed an hcard for contact info, and essentially leave room for
> >> a 'body' or 'content' attribute that would house the resume itself.
> >>
> >> The point is to make it easy to aggregate, correct? So just keep the
> >> format very lean, and allow 'recruiters' search for certain keywords
> >> in the 'content' via their aggregation system.
> >
> > Just don't simplify it to uselessness, in the end if it is aggregated
> > you will want to be process the information in it. and hcard +
> > body-field does not leave much information on which to do meaningful
> > processing.
> 
> Indeed, no one wants it to be useless.
> 
> However, there is something to be said for simplifying it so much that you
> fail to provide enough features for some folks, or at least what they 
> think
> they need.
> 
> And then iterate and slowly add minimal features as necessary.
> 
> Then again, I have a feeling that much of what goes into a resume can be
> built from the current microformat building blocks in quite a
> straightforward fashion.
> 
> But for example, if a list of skills for now was nothing but an unordered
> list, that might be ok. Just one example for the sake of discussion.
> 
> Thanks,
> 
> Tantek
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 



-- 
The content of this email is:
[]blogable [x]ask first []personal
--
panayotis vryonis
http://vrypan.net/log/
http://g-metrics.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/pipermail/microformats-discuss/attachments/20050713/74e914b7/attachment.htm
From skeltoac at gmail.com  Wed Jul 13 09:47:51 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Wed Jul 13 09:48:28 2005
Subject: [microformats-discuss] wiki etiquette: brainstorming proposals
	vs. writing specs, avoid user specific pages
In-Reply-To: <BEFA48C2.5CF66%tantek@cs.stanford.edu>
References: <e6ec604d0507121212558d8c05@mail.gmail.com>
	<BEFA48C2.5CF66%tantek@cs.stanford.edu>
Message-ID: <e6ec604d050713094771bc9a7c@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> Hmm... I didn't even know it was possible to create such user page specific
> pages.

I didn't mean to step on toes. Working out a dummy spec helped me
visualize the results of the idea I was tossing around.

> Andy, could you move the key portions of your proposal to the citation
> brainstorming page:
> 
>  http://microformats.org/wiki/citation-brainstorming
> 
> and then delete the user specific RelCite page? (empty it's contents if you
> can't delete the page itself).

It's empty now.

Andy
From limbo at speakeasy.net  Wed Jul 13 09:52:49 2005
From: limbo at speakeasy.net (Eran)
Date: Wed Jul 13 09:52:55 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <20050713122421.24599.qmail@web30603.mail.mud.yahoo.com>
Message-ID: <002b01c587cb$4e995670$6464a8c0@hellonwheels>

Tim Said:
> So, I now agree with your ideas (class="relVia", 
> class="relUpdate", class="relReplyTo"). However, I don't 
> quite follow why you want to keep the rel prefix for now 
> though? If class="Via" will work now, and in the future 
> simply become rel="Via", why not go that route? (I'm slow, 
> dense and new to this, so bear with me.)
> 

My reasoning on this is somewhat roundabout and possibly wrong but here
goes. I'm using revReplyTo and relReplyTo (and others) because both have
meaning (I'm replying to the linked post vs the linked post is a reply
to this one) and I want to distinguish between them clearly. In the case
of via the direction is obvious (I don't see anyone saying "the linked
post was 'inpspired' by this one") so via can be assumed to always be
relVia and thus can be written simply as via. You may be right and for
consistency maybe we should change it to relVia.

I should probably create an open issues section on the brainstorming
page so we can get some more specific feedback.

> And that brings me back to my print-center question.  Your 
> scope focuses on distributed online discussions (i.e.: 
> blog-to-blog), but what would be the format if I were to 
> reference a print piece? For example, if I were to post an 
> entry after reading an article:
> 
> ---* My blog entry *---
> 
> In his essay "Hemmingway and Fish" (<cite>Times Literary 
> Supplement, June 1998</cite>), Mr. Haute contents....
> 
> ---* *---
> 
> I'm referencing a piece I've read, so <cite> would be the 
> appropriate element. Would anything else be needed? A link to 
> the TLS website perhaps[1]? Would something like "relPrint" 
> be appropriate?
> 

I think that it's good practice to cite the most exact resource you can
come up with. In the case of printed resources, there's several accepted
examples, all of which simply use the cite element to reference the name
of the source. Based on these examples I don't see a need for relPrint
but I'm definitely open to other opinions on the subject.

> 
> [1] I could see coding it as (XHTL 2) <cite 
> cite="http://www.the-tls.co.uk/">Times Literary Supplement, 
> June 1998</cite>, but doesn't seem quite appropriate as it 
> doesn't like to the article. 

The rendering of a cite attribute in XHTML2 is still very an open issue
as far as I understand. I'm assuming that the example you use above
_will_ be rendered with a link to the url but that remains to be seen.

From skeltoac at gmail.com  Wed Jul 13 10:31:46 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Wed Jul 13 10:32:31 2005
Subject: [microformats-discuss] rel="cite", rev="cite". rel="comment"?
In-Reply-To: <BEFA4ABF.5CF6A%tantek@cs.stanford.edu>
References: <e6ec604d0507121212558d8c05@mail.gmail.com>
	<BEFA4ABF.5CF6A%tantek@cs.stanford.edu>
Message-ID: <e6ec604d050713103119ccb81@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> On 7/12/05 12:12 PM, "Andy Skelton" <skeltoac@gmail.com> wrote:
> What semantic difference is there between:
> 
> 1. <cite><a href="http://example.com">example citation</a></cite>
> 
> and
> 
> 2. <a rel="cite" href="http://example.com">example citation</a>
> 
> ?
> 
> AFAICT, there is no semantic difference.

I agree.

> However, (1) only uses pre-defined XHTML elements.
> 
> (2) uses a new rel value.
> 
> Thus (1) is preferred.

Also agreed. Furthermore, looking forward to times when hypertext may
be more than just <a href></a>, people should get accustomed to
semantic use of all valid elements.

> > and rev="cite" to hyperlinks.
> 
> I don't think rev="cite" is something that an author can be trusted to
> claim.
> 
> From a trust and authority perspective, you don't get to state that someone
> else is citing you.  You can only state when you cite someone else.

I see the trust/authority issue in that. Still, there should be a way
to indicate the reciprocal relationship from a cited resource. It's
something to consider.

> While I can certainly appreciate the symmetry of using rel vs. rev = cite,
> in practice, 'rev' is something that is not easy to understand for web
> authors.

The 'rev' attribute could be more clearly documented but that is not
an excuse to treat it like it's deprecated. The power of 'rev' is
begging to be exploited, not feared.

<link rel="Next" href="page2.html"> means "yonder document is the next
document in the sequence."

In cross-domain linking, <a rev="whatiam" href></a> gives the author
of the referring document the power to define his document's role in
the relationship. "The current document is a comment on the linked
document." "This is a rebuttal to that." "This is evidence to support
that."

> Another alternative is to use something like rel="comment", which would be
> like saying that this resource over here, is a comment for the current
> (portion of the) page.

That works on the other end of the same vector--the pingback receiver.
The off-site comment author would use rev="comment" to describe his
own document. Maybe we don't need a "cite" value for rel/rev because
we have the cite element but we could make good use of some other
rel/rev values to map discussions across domains.

Andy
From dougal at gunters.org  Wed Jul 13 10:43:06 2005
From: dougal at gunters.org (Dougal Campbell)
Date: Wed Jul 13 10:43:10 2005
Subject: [microformats-discuss] microformats for various types of media?
Message-ID: <42D552AA.8090207@gunters.org>

Now for something a little more frivolous. Is anyone else interested in 
a microformat for marking up information about music tracks?

I'm sure there's plenty of prior-art formats to borrow from (the iTunes 
library export XML comes to mind, as does the ID3 tagging info itself). 
But, where to start? What's required and optional? How to handle album 
information for "various artists" collections consistently?

On a related note, microformats for books and movies would also be 
interesting. A site like All Consuming would be able to aggregate this 
type of data in interesting ways.

Is this a dumb application for a microformat, or should I plow ahead?

-- 
Dougal Campbell <dougal@gunters.org>
http://dougal.gunters.org/

From scott at jot.com  Wed Jul 13 10:51:12 2005
From: scott at jot.com (Scott McMullan)
Date: Wed Jul 13 10:51:13 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <20050713175113.74143A90D0@gate1.excedent.us>

Hi I'm Scott McMullan, and was introduced to Microformats from one of Adam
Rifkin's posts late last year.  I'm currently heading up developer relations
at JotSpot (the "Application Wiki" company).

My background is a developer, majority back end, and I've been hacking
network apps since pre-web.  I got into web heavily in '97 building a
real-time web project collaboration product called TeamCenter.

TeamCenter was "real-time" similar SubEthaEdit, and was "firewall-friendly"
similar to mod-pubsub.  Except I used little Java applets instead of
Javascript... Ouch!  

I've also spent some time over at Berkeley at the Center for Document
Engineering working with more heavy-weight uses of XML & Schema.

My dual experience/wrestling w/rather heavyweight uses of XML in TeamCenter
and at Berekeley have made me extra super duper excited about Microformats,
and I want to start playing and evangelizing their use in JotSpot apps.

Best.

-Scott

Scott McMullan
scott@jot.com
M: 415-902-2188
W: 650-320-9300 x122
B: http://developer.jot.com  
PB: http://scottmcmullan.com

> -----Original Message-----
> From: microformats-discuss-bounces@microformats.org 
> Behalf Of Ryan King
> Sent: Friday, July 01, 2005 8:15 PM
> 
> We've had a lot of people join the list recently and most 
> people probably don't know who else is subscribed to the list 
> (there's 51 total). So, some personal introductions are in 
> order... I'll start:
> 

From skeltoac at gmail.com  Wed Jul 13 10:53:01 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Wed Jul 13 10:53:11 2005
Subject: [microformats-discuss] microformats for various types of media?
In-Reply-To: <42D552AA.8090207@gunters.org>
References: <42D552AA.8090207@gunters.org>
Message-ID: <e6ec604d050713105346262abb@mail.gmail.com>

On 7/13/05, Dougal Campbell <dougal@gunters.org> wrote:
> Now for something a little more frivolous. Is anyone else interested in
> a microformat for marking up information about music tracks?
<< snip >> 
> Is this a dumb application for a microformat, or should I plow ahead?

I see you've spun off from your Now Playing plugin... will you polish
it for public consumption?

As for your microformat, what do you do about DualDisc and other
multimedia products? ID3 is extremely weak IMO. How about a single,
unified microformat for anything that can have an ISBN number?


Andy Skelton
http://www.skeltoac.com
From ryan at technorati.com  Wed Jul 13 11:20:11 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 13 11:20:14 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <002b01c587cb$4e995670$6464a8c0@hellonwheels>
References: <002b01c587cb$4e995670$6464a8c0@hellonwheels>
Message-ID: <29D91DF3-2A47-4DD5-A8AF-6FB3FFA2F29E@technorati.com>

On Jul 13, 2005, at 9:52 AM, Eran wrote:

> Tim Said:
>> [1] I could see coding it as (XHTL 2) <cite
>> cite="http://www.the-tls.co.uk/">Times Literary Supplement,
>> June 1998</cite>, but doesn't seem quite appropriate as it
>> doesn't like to the article.
>
> The rendering of a cite attribute in XHTML2 is still very an open  
> issue
> as far as I understand. I'm assuming that the example you use above
> _will_ be rendered with a link to the url but that remains to be seen.

Though I can't find it in the spec, I remember reading that rendering  
it as a link will be required.

-ryan
From kmarks at technorati.com  Wed Jul 13 10:13:18 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Wed Jul 13 11:23:41 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <1f2ed5cd050712123539642826@mail.gmail.com>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
	<003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<e6ec604d0507121212558d8c05@mail.gmail.com>
	<1f2ed5cd050712123539642826@mail.gmail.com>
Message-ID: <21e725b62ba3dd859a7fb96b843a873a@technorati.com>


On Jul 12, 2005, at 12:35 PM, Danny Ayers wrote:
> Anyhow given the microformat credo of building on existing standards,
> I thought it worth mentioning that there was considerable discussion
> of useful values for a "rel" attribute over on the Atom list/wiki,
> specifically for the <link> element. The decision was made to endorse
> by IANA registration five initial values (alternate, related, self,
> enclosure, via), but to also allow unregistered values that could be
> specificied using an IRI. (The registered values would be considered
> equivalent to the IRIs formed by the names preceded by
> http://www.iana.org/assignments/relation/).

I wrote up rel-enclosure a while back, and have been using it on <a> 
links in my blog for a while now.

http://microformats.org/wiki/rel-enclosure

From skeltoac at gmail.com  Wed Jul 13 11:25:42 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Wed Jul 13 11:26:22 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <29D91DF3-2A47-4DD5-A8AF-6FB3FFA2F29E@technorati.com>
References: <002b01c587cb$4e995670$6464a8c0@hellonwheels>
	<29D91DF3-2A47-4DD5-A8AF-6FB3FFA2F29E@technorati.com>
Message-ID: <e6ec604d05071311251a6ae78b@mail.gmail.com>

On 7/13/05, Ryan King <ryan@technorati.com> wrote:
> Though I can't find it in the spec, I remember reading that rendering
> it as a link will be required.

Not exactly. It could be in a context menu or some other "means". From
http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-hyperAttributes.html:

13.1. Hypertext Attribute Collection
cite = URI 
The value of this attribute is a URI that designates a source document
or message. This attribute is intended to give further information
about the element's contents (e.g., the source from which a quotation
was borrowed, or the reason text was inserted or deleted). /User
Agents MUST provide a means for the user to actuate the link./
Example
cite="comments.html"

href = URI 
/This attribute specifies a URI that is actuated when the element is activated./
Actuation occurs as the default action of a [DOM] DOMActivate event
for the element on which the attribute occurs (for instance as the
result of the user clicking on the associated element).



Andy Skelton
http://www.skeltoac.com
From kmarks at technorati.com  Wed Jul 13 11:23:11 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Wed Jul 13 11:26:58 2005
Subject: [microformats-discuss] Badges - [was additional ways to reference
	XMDPs
In-Reply-To: <BEFA53B9.5CF74%tantek@cs.stanford.edu>
References: <BEFA53B9.5CF74%tantek@cs.stanford.edu>
Message-ID: <8964c497fe8c5b44245308c2c2828077@technorati.com>

How about combining the XMDP link with a 'badge' image (or 
consistently-CSS-styled logo) ?
Bloggers and others love to have little badges on their sites endorsing 
and proclaiming their support of standards or causes; if the XMDP 
profile link is what the badge points to, this seems a microformat-like 
way of reusing existing practices.

This does imply that the XMDP profiles SHOULD have a link to a 
user-oriented explanation of the format too, to avoid the 'RSS button 
aversion therapy' problem, where you click one of them, get an 
incomprehensible page of code or  an error message from your browser, 
and avoid doing so ever again.

On Jul 13, 2005, at 5:16 AM, Tantek ?elik wrote:
> 3. <a rel="profile"> is another way to do so, and enables people to
> reference profiles inline in content anywhere, and *visibly* as well, 
> which
> has added benefits.
> On 7/13/05 4:36 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:
>>
>> 4.  A seemingly easy solution is to put an <a> element somewhere in
>> the microformatted content that points back to the XMDP.  This
>> fulfills the initial practical question raised initially but adds <a>
>> elements, an addition some find aesthetically displeasing.
>>
>> It seems another outcome of all of this would be to consider some
>> simple extension to the XMDP spec that allows it to be linked from an
>> <a> element with discussion focusing on how that would work.

From kmarks at technorati.com  Wed Jul 13 11:25:11 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Wed Jul 13 11:27:00 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <1f2ed5cd050712123539642826@mail.gmail.com>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
	<003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<e6ec604d0507121212558d8c05@mail.gmail.com>
	<1f2ed5cd050712123539642826@mail.gmail.com>
Message-ID: <458c5db2e5248f35c38ff66df4591850@technorati.com>


On Jul 12, 2005, at 12:35 PM, Danny Ayers wrote:
> Anyhow given the microformat credo of building on existing standards,
> I thought it worth mentioning that there was considerable discussion
> of useful values for a "rel" attribute over on the Atom list/wiki,
> specifically for the <link> element. The decision was made to endorse
> by IANA registration five initial values (alternate, related, self,
> enclosure, via), but to also allow unregistered values that could be
> specificied using an IRI. (The registered values would be considered
> equivalent to the IRIs formed by the names preceded by
> http://www.iana.org/assignments/relation/).

I wrote up rel-enclosure a while back, and have been using it on <a> 
links in my blog for a while now.

http://microformats.org/wiki/rel-enclosure

From ryan at technorati.com  Wed Jul 13 11:31:29 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 13 11:31:31 2005
Subject: [microformats-discuss] microformats for various types of media?
In-Reply-To: <42D552AA.8090207@gunters.org>
References: <42D552AA.8090207@gunters.org>
Message-ID: <499BE8E9-5F85-44CF-9B80-695C53FD9126@technorati.com>

On Jul 13, 2005, at 10:43 AM, Dougal Campbell wrote:
> Now for something a little more frivolous. Is anyone else  
> interested in a microformat for marking up information about music  
> tracks?

Yes. Not frivolous. I think there's been some brainstorming on this  
already: http://microformats.org/wiki/media-metadata-examples

I know Kevin Marks is really interested in this.

> I'm sure there's plenty of prior-art formats to borrow from (the  
> iTunes library export XML comes to mind, as does the ID3 tagging  
> info itself). But, where to start?

Start with the above wiki page and add other examples of widely used  
prior-art.

> What's required and optional? How to handle album information for  
> "various artists" collections consistently?

Good questions.

> On a related note, microformats for books and movies would also be  
> interesting. A site like All Consuming would be able to aggregate  
> this type of data in interesting ways.

I'm not sure what you mean by this. What data about the book or movie?

> Is this a dumb application for a microformat, or should I plow ahead?

Where there's data on the web, there's room for discussion of a  
microformat.

I assume you've read http://microformats.org/wiki/process - it should  
(hopefully) give you an idea of the general process involved in  
developing a microformat.

-ryan
From skeltoac at gmail.com  Wed Jul 13 12:00:20 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Wed Jul 13 12:00:59 2005
Subject: [microformats-discuss] Re: Proposing RelSource
In-Reply-To: <458c5db2e5248f35c38ff66df4591850@technorati.com>
References: <20050712181724.44439.qmail@web30602.mail.mud.yahoo.com>
	<003201c5870f$3c1140b0$6464a8c0@hellonwheels>
	<e6ec604d0507121212558d8c05@mail.gmail.com>
	<1f2ed5cd050712123539642826@mail.gmail.com>
	<458c5db2e5248f35c38ff66df4591850@technorati.com>
Message-ID: <e6ec604d05071312002260014d@mail.gmail.com>

Getting back to the rel="source" or rel="cite" idea: Ryan and I
discussed it off-list and I sorted out a lot of my own half-baked
thoughts. Posted here for interest.


On 7/13/05, Ryan King <ryan@theryanking.com> wrote:
> And to take things  a step back, I don't think your proposal is a bad
> one- in fact its very good. I just think there may be some other good
> ideas around this problem and we need to explore all of them. Also,
> if you think <cite><a></a></cite> is not the best idea, I want to
> hear your reason. I'm not defensive about it by any means, but I want
> dialogue about microformats to be full and reasoned-out. I hope you
> understand.

The rel="cite" idea was easy to generate but it's difficult to defend.
I needed to step back and think about what problem I was trying to
solve. When I did that, I saw rel="cite" becoming less and less
attractive. Several times during the process, I wanted to give up and
remove myself from the discussion but I think I'll eventually come up
with something worthwhile. I'll try to work out my thoughts in the
next several paragraphs. I hope some good comes from all this...

My rel="source" idea was born out of some observations I have made
while watching the blogsoftheday.com lists evolve and react to
breaking news and surging memes. The most significant cases to come to
my attention in the past week have been the London bombing and the
Longhorn screenshots. What I saw were primary sources at first,
followed by many bare gateway articles (just the link and maybe a few
words) pointing toward primary sources and a lesser number of articles
offering the same link but with some additional content such as
editorial/commentary, supporting/refuting evidence, or additional,
related links.

When I'm looking for topical information the masses of bare gateway
articles are like so many iron filings when what I want is the magnet
at the center. The filings have little or no intrinsic force or value
but they do serve an excellent purpose: their numbers help to indicate
the strength of the magnets. By counting the filings, machines like
Technorati can measure the strength of the magnets. To a human,
however, they are generally not worth the time it takes a UA to load
the page.

The way I see it, the division between bare gateways and other kinds
of resources is the division between mere dissemination and actual
participation. That is an important distinction to make because it is
also the difference between "interesting to machines" and "interesting
to humans."

There is a big monkey wrench in here: the proliferation of blogs and
their posts as forums for discussion. What might otherwise be a mere
gateway (a one-line blog entry linking to a more substantial article
elsewhere) now has the /potential/ to house a rich discussion.

While we're throwing monkey wrenches around, consider the author's
motives for writing and hosting these one-line gateway posts. Aside
from being just plain helpful, these authors are usually trying to
snag a few passers-by with ads or other content. Take for example one
of the biggest gateway blogs ever: Slashdot. All they do is publish
links (provided by readers even!), add some snappy comments and give
readers a place to discuss.

What's the lesson here? Don't count on authors to spend their time
telling people "don't visit my site, it's just a gateway." They won't
do it.

Now that I've settled my own selfish desire to make the chaff kindly
separate itself from the wheat, let me explore another aspect of the
problem: if each and every one of these interlinked resources is
potentially interesting, can we at least classify the links such that
we can map cross-domain discussions in a useful manner?

Now we're back into the exact territory you were exploring a couple of
months ago with hVia. I'll end and send this email and organize my
thoughts for the next one after lunch.

Andy
From lucas.gonze at gmail.com  Wed Jul 13 12:20:44 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Wed Jul 13 12:20:46 2005
Subject: [microformats-discuss] IRI unsuitable for rel,
	"naming clashes" is chicken littling
In-Reply-To: <BEFA3FA1.5CF50%tantek@cs.stanford.edu>
References: <1f2ed5cd050712123539642826@mail.gmail.com>
	<BEFA3FA1.5CF50%tantek@cs.stanford.edu>
Message-ID: <ab069aa00507131220725822e0@mail.gmail.com>

On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> I'm terminating this notion right here.
> 
> IMHO the use of IRIs for rel values is out of scope for microformats.
> 
> As list moderator: end of thread on IRI for rel.
> 
> 
> > Use of IRIs prevents naming clashes.
> 
> "Naming clashes" is chicken littling and has been documented as such within
> the context of microformats.
> 
> As list moderator: end of thread of general "naming clashes" discussions.

That's not an appropriate use of moderation, Tantek.  Some of your
ideas will become consensus, others won't.

For example, I didn't find these technical arguments WRT naming
clashes persuasive, so I'm still looking for a good reason to not use
IRIs for rel values.
From lucas.gonze at gmail.com  Wed Jul 13 12:30:48 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Wed Jul 13 12:30:49 2005
Subject: [microformats-discuss] Badges - [was additional ways to reference
	XMDPs
In-Reply-To: <8964c497fe8c5b44245308c2c2828077@technorati.com>
References: <BEFA53B9.5CF74%tantek@cs.stanford.edu>
	<8964c497fe8c5b44245308c2c2828077@technorati.com>
Message-ID: <ab069aa005071312303dd3facf@mail.gmail.com>

On 7/13/05, Kevin Marks <kmarks@technorati.com> wrote:
> How about combining the XMDP link with a 'badge' image (or
> consistently-CSS-styled logo) ?
> Bloggers and others love to have little badges on their sites endorsing
> and proclaiming their support of standards or causes; if the XMDP
> profile link is what the badge points to, this seems a microformat-like
> way of reusing existing practices.

This seems very sensible to me -- a link to an XMDP document is a hint
that data in that format is likely to be found in the enclosing
document.
From tantek at cs.stanford.edu  Wed Jul 13 12:59:38 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 12:59:42 2005
Subject: [microformats-discuss] wiki etiquette: brainstorming
	proposals vs. writing specs, avoid user specific pages
In-Reply-To: <e6ec604d050713094771bc9a7c@mail.gmail.com>
Message-ID: <BEFAC0B0.5D02B%tantek@cs.stanford.edu>

On 7/13/05 9:47 AM, "Andy Skelton" <skeltoac@gmail.com> wrote:

> On 7/13/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
>> Hmm... I didn't even know it was possible to create such user page specific
>> pages.
> 
> I didn't mean to step on toes. Working out a dummy spec helped me
> visualize the results of the idea I was tossing around.

No problem at all.  We're still figuring this out a bit as we go.


>> Andy, could you move the key portions of your proposal to the citation
>> brainstorming page:
>> 
>>  http://microformats.org/wiki/citation-brainstorming
>> 
>> and then delete the user specific RelCite page? (empty it's contents if you
>> can't delete the page itself).
> 
> It's empty now.

Great.

Folks, I like the evolution of the citation-brainstorming page.  It clearly
shows a thought process is going on, and capturing how we got to a
decision/consensus will help us to avoid revisiting the same steps.

Thanks,

Tantek

From tantek at cs.stanford.edu  Wed Jul 13 12:59:39 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 13 12:59:42 2005
Subject: [microformats-discuss] microformats for various types of
	media?
In-Reply-To: <42D552AA.8090207@gunters.org>
Message-ID: <BEFAC0B8.5D02B%tantek@cs.stanford.edu>

On 7/13/05 10:43 AM, "Dougal Campbell" <dougal@gunters.org> wrote:

> Now for something a little more frivolous. Is anyone else interested in
> a microformat for marking up information about music tracks?

Not frivolous at all.


> I'm sure there's plenty of prior-art formats to borrow from (the iTunes
> library export XML comes to mind, as does the ID3 tagging info itself).

Absolutely.  Some folks have already started capturing this:

 http://microformats.org/wiki/media-metadata-examples

And not only is there prior art, but you have at least two domain experts on
this mailing list:

 Kevin Marks - QuickTime background, podcasting innovator, etc.
 Lucas Gonze - XSPF lead

(guys please feel free to correct my imprecise characterizations)
(and any other domain experts, consider this your invite to speak up)


> But, where to start?

 http://microformats.org/wiki/process


> What's required and optional?

start as simple as possible


> How to handle album
> information for "various artists" collections consistently?

How do people publish that information today on the web?

E.g. How does Amazon publish it?  How do bloggers publish it?


> On a related note, microformats for books and movies would also be
> interesting. A site like All Consuming would be able to aggregate this
> type of data in interesting ways.
> 
> Is this a dumb application for a microformat, or should I plow ahead?

Not dumb at all.

See above.  Check the process page for some useful first steps.

Go through the media-metadata-examples document.

Perhaps even check out the IRC channel.  I know Kevin is on there a whole
bunch.  Sometimes IRC works better than email to brainstorm a bunch of stuff
quickly.

Thanks,

Tantek

From dougal at gunters.org  Wed Jul 13 13:00:36 2005
From: dougal at gunters.org (Dougal Campbell)
Date: Wed Jul 13 13:00:38 2005
Subject: [microformats-discuss] microformats for various types of media?
In-Reply-To: <499BE8E9-5F85-44CF-9B80-695C53FD9126@technorati.com>
References: <42D552AA.8090207@gunters.org>
	<499BE8E9-5F85-44CF-9B80-695C53FD9126@technorati.com>
Message-ID: <42D572E4.5070903@gunters.org>

Ryan King wrote:
> On Jul 13, 2005, at 10:43 AM, Dougal Campbell wrote:
> 
>> Now for something a little more frivolous. Is anyone else  interested 
>> in a microformat for marking up information about music  tracks?
> 
> 
> Yes. Not frivolous. I think there's been some brainstorming on this  
> already: http://microformats.org/wiki/media-metadata-examples
> 
> I know Kevin Marks is really interested in this.

Well heck. I promise I *did* search the Wiki previously, but somehow, I 
didn't turn that page up. I must have been in too much of a hurry and 
made my search terms too narrow (e.g., I know I searched for things like 
"mp3" and "playlist").

>> On a related note, microformats for books and movies would also be  
>> interesting. A site like All Consuming would be able to aggregate  
>> this type of data in interesting ways.
> 
> 
> I'm not sure what you mean by this. What data about the book or movie?

Title, author, director, ISBN/ASIN, publisher, genre, rating, length, 
pages, release date, etc. Note that I'm thinking in more general terms 
about media, not only of electronic media, as the media-metadata page is 
oriented at this time.

-- 
Dougal Campbell <dougal@gunters.org>
http://dougal.gunters.org/

From dimitri.glazkov at gmail.com  Wed Jul 13 15:20:55 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Wed Jul 13 15:21:54 2005
Subject: [microformats-discuss] Comments microformat
Message-ID: <fb15ac210507131520c572622@mail.gmail.com>

It seems the archives of the list are inacessible, so I'll shoot in the dark.

I wanted to start discussion over on my blog about semantic "proper"
of your typical blog comments
(http://glazkov.com/blog/archive/2005/07/13/1861.aspx), and Tantek
pointed me to this list.

I would like to hear your pointers, comments, thoughts, ideas on the subject.

:DG<
From ryan at technorati.com  Wed Jul 13 15:57:31 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 13 15:57:36 2005
Subject: [microformats-discuss] IRC meetups?
In-Reply-To: <BEFAC0B8.5D02B%tantek@cs.stanford.edu>
References: <BEFAC0B8.5D02B%tantek@cs.stanford.edu>
Message-ID: <25A1D509-CA6F-49AB-9A57-B3B0F4C94F9F@technorati.com>

On Jul 13, 2005, at 12:59 PM, Tantek ?elik wrote:
> Perhaps even check out the IRC channel.  I know Kevin is on there a  
> whole
> bunch.  Sometimes IRC works better than email to brainstorm a bunch  
> of stuff
> quickly.

Indeed, we've found that IRC has been very useful for getting a lot  
of discussion done very quickly.

Feel free to make appointments for people to meetup in IRC. I know  
the wordpress folks have a regular weekly IRC meetup. I don't think  
we need anything regular, but when the need arises, call for an irc  
meetup.

-ryan
From tjameswhite at yahoo.com  Wed Jul 13 15:59:17 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Wed Jul 13 15:59:19 2005
Subject: [microformats-discuss] Re: microformats for various types of media?
In-Reply-To: <20050713182013.9952DF08645@microformats>
Message-ID: <20050713225917.48517.qmail@web30608.mail.mud.yahoo.com>


Doug said:
"On a related note, microformats for books and movies would also be
interesting. A site like All Consuming would be able to aggregate this
type of data in interesting ways.

Is this a dumb application for a microformat, or should I plow ahead?"

I've had similar thoughts for quite a while before I knew about
microformats. In the relSource thread I've alluded to the fact that
I've been working on a thought relating to citing print sources. My
original thought stemmed from the poor way of handling book titles in
html/xhtml and what to do about it. A microformat just may be the
ticket.

I'll try to find time over the next couple of days to write my thoughts
up and point everyone to them.



~ 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!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250
From andyhume at thedredge.org  Wed Jul 13 16:08:24 2005
From: andyhume at thedredge.org (Andy Hume)
Date: Wed Jul 13 16:08:34 2005
Subject: [microformats-discuss] Developer Adoption
Message-ID: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>

Hi guys,

Sorry to interrupt the heavy spec brainstorming going on here (it  
makes my evening train journey's fly by ;)) but I'd like to run  
something by you guys.

My thoughts are increasingly turning to getting some of the more  
refined formats (ie, hcal, ical, hreview, etc) into the minds of the  
real world developers out there. It's all very well them coming along  
to mf.org, but so many of them are not understanding what this is all  
about. They're lost in the noise of some pretty exciting, but  
daunting 'speccy' talk.

IMHO these early formats will be the key to encouraging developer  
uptake because they work here and now, and can be useful in a real  
world way. Do we need a developer adoption drive?

I run a developer site called UsableType (http://usabletype.com),  
(which unfortunately, due to work has had a near 6 month hiatus - but  
still appears to have hundreds of feed subscribers) and I am  
currently writing a piece for it regarding microformats and more  
specifically the hcard format. It is very basic stuff - but the crux  
of it is showing how hcard can be useful *now* (mainly through X2V),  
and something of a 'call to action' encouraging designers/developers  
top spare the 10 minutes it would take to add their contact details  
to an hcard on their blogs/portfolio's home page.

What are your feelings on this? And what specific mark-up example do  
you believe would be appropriate for this?

Would <address class="vcard"> be an appropriate way of declaring an  
hcard as specifically the authors details? And would it best be  
located just once on the home page, or on every page in the footer?

Thoughts on this, and in general, are appreciated.

Cheers,

Andy.


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
From ryan at technorati.com  Wed Jul 13 16:09:20 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 13 16:09:23 2005
Subject: [microformats-discuss] Comments microformat
In-Reply-To: <fb15ac210507131520c572622@mail.gmail.com>
References: <fb15ac210507131520c572622@mail.gmail.com>
Message-ID: <A524C1F1-B66C-4173-A5CD-FFB3C7DF4ED9@technorati.com>

On Jul 13, 2005, at 3:20 PM, Dimitri Glazkov wrote:

> It seems the archives of the list are inacessible, so I'll shoot in  
> the dark.

Sorry. I'm trying to get this happening soon.

> I wanted to start discussion over on my blog about semantic "proper"
> of your typical blog comments
> (http://glazkov.com/blog/archive/2005/07/13/1861.aspx), and Tantek
> pointed me to this list.

We've actually had a few proposals along this line. The proposals  
were a bit premature, as we need to do some research on current  
comments practice first (see http://microformats.org/wiki/process for  
guidelines on how to go about developing a microformat).

And to take a step back, this page documents current comment practice:
http://microformats.org/wiki/comments-formats

Feel free to add your own observations to that page.

Just FYI, here are the proposals (don't worry about them at this point):
http://microformats.org/wiki/mfcomment
http://microformats.org/wiki/hcomment


> I would like to hear your pointers, comments, thoughts, ideas on  
> the subject.

Look at the comments-formats page. Talk to others who are interested  
in it (esp. on this list). Research, propose, iterate.

-ryan

From ryan at technorati.com  Wed Jul 13 16:17:15 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 13 16:17:16 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
Message-ID: <2B6F3746-2086-47F7-B9EA-0979753A11B0@technorati.com>

On Jul 13, 2005, at 4:08 PM, Andy Hume wrote:
> Hi guys,
>
> Sorry to interrupt the heavy spec brainstorming going on here (it  
> makes my evening train journey's fly by ;)) but I'd like to run  
> something by you guys.
>
> My thoughts are increasingly turning to getting some of the more  
> refined formats (ie, hcal, ical, hreview, etc) into the minds of  
> the real world developers out there. It's all very well them coming  
> along to mf.org, but so many of them are not understanding what  
> this is all about. They're lost in the noise of some pretty  
> exciting, but daunting 'speccy' talk.
>
> IMHO these early formats will be the key to encouraging developer  
> uptake because they work here and now, and can be useful in a real  
> world way. Do we need a developer adoption drive?

Yes and no. To some degree, its already happening without an explicit  
drive pushing it. On the other hand, education and evangelism is  
always helpful.

And there's nothing holding anyone back from doing this on their own.  
I know Tantek and I both regularly email people suggesting that they  
implement a specific microformat on their site.

> I run a developer site called UsableType (http://usabletype.com),  
> (which unfortunately, due to work has had a near 6 month hiatus -  
> but still appears to have hundreds of feed subscribers) and I am  
> currently writing a piece for it regarding microformats and more  
> specifically the hcard format. It is very basic stuff - but the  
> crux of it is showing how hcard can be useful *now* (mainly through  
> X2V), and something of a 'call to action' encouraging designers/ 
> developers top spare the 10 minutes it would take to add their  
> contact details to an hcard on their blogs/portfolio's home page.
>
> What are your feelings on this? And what specific mark-up example  
> do you believe would be appropriate for this?

hCalendar makes for good examples, too, because many sites are  
already publishing events, so it would only be a matter of adding  
some structured, semantic markup.

> Would <address class="vcard"> be an appropriate way of declaring an  
> hcard as specifically the authors details? And would it best be  
> located just once on the home page, or on every page in the footer?

Yes, that's great.

> Thoughts on this, and in general, are appreciated.


Also, there's a microformats-dev list, which is for people that have  
implementations using microformats (see http://microformats.org/ 
discuss/).

-ryan
From ryan at technorati.com  Wed Jul 13 16:41:48 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 13 16:41:49 2005
Subject: [microformats-discuss] Comments microformat
In-Reply-To: <A524C1F1-B66C-4173-A5CD-FFB3C7DF4ED9@technorati.com>
References: <fb15ac210507131520c572622@mail.gmail.com>
	<A524C1F1-B66C-4173-A5CD-FFB3C7DF4ED9@technorati.com>
Message-ID: <A12401EF-6B48-413A-AD03-21384F8ECC04@technorati.com>

On Jul 13, 2005, at 4:09 PM, Ryan King wrote:
> Look at the comments-formats page. Talk to others who are  
> interested in it (esp. on this list). Research, propose, iterate.

Additionally, see http://tantek.com/log/2003/12.html#L20031215t0830  
for a collection of Tantek-thoughts on blog markup.

-ryan
From bud at thecommunityengine.com  Wed Jul 13 18:01:38 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Wed Jul 13 18:01:38 2005
Subject: [microformats-discuss] Announcing microformats discovery
	brainstorming
Message-ID: <4E99596B-706F-492C-8CB4-D2EB1C779020@thecommunityengine.com>

Dear all:

Josh Porter raised the great issue of how UAs and developers might  
discover microformats.  This is key for hacking new applications  
based on microformats.  Applications will ultimately lead to wider  
adoption.  I tried to summarize the list's discussion on this wiki page:

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

I cover several proposals plus raise the issue of parsing user data.   
Many of the prototype discovery mechanisms like Brian Suda's X2V  
depend on having a decent DOM tree.  May not happen.

I would really like to get some participation in editing and  
authoring the page.  The activity on the list suggests this is a hot  
topic.

Bud

From porter at bokardo.com  Wed Jul 13 19:10:42 2005
From: porter at bokardo.com (Joshua Porter)
Date: Wed Jul 13 19:10:46 2005
Subject: [microformats-discuss] Announcing microformats discovery
	brainstorming
In-Reply-To: <4E99596B-706F-492C-8CB4-D2EB1C779020@thecommunityengine.com>
References: <4E99596B-706F-492C-8CB4-D2EB1C779020@thecommunityengine.com>
Message-ID: <1D9411BA-BB8C-4A81-8946-05C88275434C@bokardo.com>

Thanks, Bud. I was going to summarize that thread, but you've already  
done so. :)

josh


On Jul 13, 2005, at 9:01 PM, Bud Gibson wrote:

> Dear all:
>
> Josh Porter raised the great issue of how UAs and developers might  
> discover microformats.  This is key for hacking new applications  
> based on microformats.  Applications will ultimately lead to wider  
> adoption.  I tried to summarize the list's discussion on this wiki  
> page:
>
> http://microformats.org/wiki/xmdp-brainstorming
>
> I cover several proposals plus raise the issue of parsing user  
> data.  Many of the prototype discovery mechanisms like Brian Suda's  
> X2V depend on having a decent DOM tree.  May not happen.
>
> I would really like to get some participation in editing and  
> authoring the page.  The activity on the list suggests this is a  
> hot topic.
>
> Bud
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From bud at thecommunityengine.com  Wed Jul 13 19:29:17 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Wed Jul 13 19:29:17 2005
Subject: [microformats-discuss] Announcing microformats discovery
	brainstorming
In-Reply-To: <1D9411BA-BB8C-4A81-8946-05C88275434C@bokardo.com>
References: <4E99596B-706F-492C-8CB4-D2EB1C779020@thecommunityengine.com>
	<1D9411BA-BB8C-4A81-8946-05C88275434C@bokardo.com>
Message-ID: <527AEE78-4287-4E57-9E01-D4F24148C131@thecommunityengine.com>

Thanks Josh, I think the points you raise about:  a) knowing a  
micrformat is there; and b) needing to be able to do something with  
them once you know they are there are key.

The thing I am excited about in this forum is that I believe we have  
what is necessary to produce solutions, and I expect you will see  
some soon.  The point of the page is to, to the extent possible,  
provide a collection point for answers.

Feel free to add,
Bud

On Jul 13, 2005, at 22:10, Joshua Porter wrote:

> Thanks, Bud. I was going to summarize that thread, but you've  
> already done so. :)
>
> josh
>
>
> On Jul 13, 2005, at 9:01 PM, Bud Gibson wrote:
>
>
>> Dear all:
>>
>> Josh Porter raised the great issue of how UAs and developers might  
>> discover microformats.  This is key for hacking new applications  
>> based on microformats.  Applications will ultimately lead to wider  
>> adoption.  I tried to summarize the list's discussion on this wiki  
>> page:
>>
>> http://microformats.org/wiki/xmdp-brainstorming
>>
>> I cover several proposals plus raise the issue of parsing user  
>> data.  Many of the prototype discovery mechanisms like Brian  
>> Suda's X2V depend on having a decent DOM tree.  May not happen.
>>
>> I would really like to get some participation in editing and  
>> authoring the page.  The activity on the list suggests this is a  
>> hot topic.
>>
>> Bud
>>
>> _______________________________________________
>> 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 bud at thecommunityengine.com  Wed Jul 13 20:34:50 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Wed Jul 13 20:34:48 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
Message-ID: <FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>

On Jul 13, 2005, at 19:08, Andy Hume wrote:

> I run a developer site called UsableType (http://usabletype.com),  
> (which unfortunately, due to work has had a near 6 month hiatus -  
> but still appears to have hundreds of feed subscribers) and I am  
> currently writing a piece for it regarding microformats and more  
> specifically the hcard format. It is very basic stuff - but the  
> crux of it is showing how hcard can be useful *now* (mainly through  
> X2V), and something of a 'call to action' encouraging designers/ 
> developers top spare the 10 minutes it would take to add their  
> contact details to an hcard on their blogs/portfolio's home page.

Andy:

My cut is that there are a lot of developer issues lurking, and it  
would help to get developers attempting to make actual applications  
and contributing so that we can flesh those out as well as potential  
solutions.  There is a microformats-dev list just for them, although  
it is unfortunately now a little underpopulated.

Bud


From bud at thecommunityengine.com  Wed Jul 13 20:52:41 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Wed Jul 13 20:52:38 2005
Subject: [microformats-discuss] microformats for various types of media?
In-Reply-To: <BEFAC0B8.5D02B%tantek@cs.stanford.edu>
References: <BEFAC0B8.5D02B%tantek@cs.stanford.edu>
Message-ID: <D755628B-2784-4A7A-8B88-9605332CD556@thecommunityengine.com>

I should take this opportunity to point out that the next iteration  
of xFolk will support <img> and <object> elements inasmuch as they  
are pointing to URLs (I need to do a little review here).  The idea  
behind xFolk is to provide descriptions and tags to things that are  
linked to.  As such it probably does not fulfill the needs of people  
posting here.

Bud

On Jul 13, 2005, at 15:59, Tantek ?elik wrote:

> On 7/13/05 10:43 AM, "Dougal Campbell" <dougal@gunters.org> wrote:
>
>
>> Now for something a little more frivolous. Is anyone else  
>> interested in
>> a microformat for marking up information about music tracks?
>>
>
> Not frivolous at all.
>
>
>
>> I'm sure there's plenty of prior-art formats to borrow from (the  
>> iTunes
>> library export XML comes to mind, as does the ID3 tagging info  
>> itself).
>>
>
> Absolutely.  Some folks have already started capturing this:
>
>  http://microformats.org/wiki/media-metadata-examples
>
> And not only is there prior art, but you have at least two domain  
> experts on
> this mailing list:
>
>  Kevin Marks - QuickTime background, podcasting innovator, etc.
>  Lucas Gonze - XSPF lead
>
> (guys please feel free to correct my imprecise characterizations)
> (and any other domain experts, consider this your invite to speak up)
>
>
>
>> But, where to start?
>>
>
>  http://microformats.org/wiki/process
>
>
>
>> What's required and optional?
>>
>
> start as simple as possible
>
>
>
>> How to handle album
>> information for "various artists" collections consistently?
>>
>
> How do people publish that information today on the web?
>
> E.g. How does Amazon publish it?  How do bloggers publish it?
>
>
>
>> On a related note, microformats for books and movies would also be
>> interesting. A site like All Consuming would be able to aggregate  
>> this
>> type of data in interesting ways.
>>
>> Is this a dumb application for a microformat, or should I plow ahead?
>>
>
> Not dumb at all.
>
> See above.  Check the process page for some useful first steps.
>
> Go through the media-metadata-examples document.
>
> Perhaps even check out the IRC channel.  I know Kevin is on there a  
> whole
> bunch.  Sometimes IRC works better than email to brainstorm a bunch  
> of stuff
> quickly.
>
> Thanks,
>
> Tantek
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From danny.ayers at gmail.com  Thu Jul 14 03:14:18 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Thu Jul 14 03:14:20 2005
Subject: [microformats-discuss] URIs please!
Message-ID: <1f2ed5cd05071403146d5ced02@mail.gmail.com>

A little plea. 

I just noticed that in the example for Bud's XFolk [1] that the blocks
containing microformats are demarcated using class attributes, i.e.

<div class="xfolkentry">

As it stands, the only way of discovering whether such a document
contains microformat data is to scrape it and look for that value.
Consider the following scenario:

You have a subscription to certain del.icio.us RSS feeds; checking the
linked pages to see if they contain microcontent markup, if they do
extracting the data and putting it into a queryable store. All
automatic.

Now you are likely to get a lot more docs which don't contain
microformat data than those which do. Ok, so "xfolkentry" is unlikely
to be misinterpreted. But what if the documents contain e.g.

<div class="name">

Is this microformat data? Which microformat?

There is a mechanism for recognising microformats in the docs - use a
profile, e.g.

<head profile="http://example.org/some/microformat/schema">

The microformats docs do cover a simple schema language XDMP, but how
the schema is done in this context is less significant than it having
a URI. Having it in the <head> is good too, it isn't necessary to
parse the whole doc looking for any "known" attributes. It also makes
it possible to offer support for microformats unknown to the system at
design time (for RDF-based apps this is straightforward using GRDDL).

Sure, there's an advantage in having well-known semantic markup terms,
the vocabularies defined in microformats. But for automatic discovery
and processing it's also hugely beneficial to be able to recognise
microformat data unambiguously. The doc can be processed in a way
appropriate for the microformat. The profile URI provides this
disambiguation and allows deterministic processing. This doesn't in
any way compromise the "simplicity" aim of microformats, in fact the
net effect is overall simplification. Hunting for arbitrary strings in
attributes is hard work!

I understand there's ongoing discussion about declaring that a
microformat is in use in doc fragments (where the <head> is
unavailable). I don't know whether the use of an <a> hyperlink is the
best mechanism or not (a possible alternative might be to use a URI
for the outermost microformat term, e.g.  <div
class="http://example.org/some/microformat/schema/xfolkentry">).

But however it's done, identification of the microformat used within
the doc by means of a URI (the GUID of the Web) is essential IMHO to
make the difference between making quality, globally unambiguous data
available and something barely less fragile than screenscraping as it
stands.

Cheers,
Danny.

[1] http://microformats.org/wiki/xfolk
 
-- 

http://dannyayers.com
From bud at thecommunityengine.com  Thu Jul 14 05:28:34 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 05:28:32 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
Message-ID: <39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>

On Jul 14, 2005, at 6:14, Danny Ayers wrote:

> Sure, there's an advantage in having well-known semantic markup terms,
> the vocabularies defined in microformats. But for automatic discovery
> and processing it's also hugely beneficial to be able to recognise
> microformat data unambiguously. The doc can be processed in a way
> appropriate for the microformat. The profile URI provides this
> disambiguation and allows deterministic processing. This doesn't in
> any way compromise the "simplicity" aim of microformats, in fact the
> net effect is overall simplification. Hunting for arbitrary strings in
> attributes is hard work!

Danny:

I could not agree more with the issue you raise and was just thinking  
on this issue as I went to sleep last night and woke this morning.  I  
included this issue in the XMDP brainstorming on this wiki page:

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

The person who joined me as page author is not in agreement with us  
and has marked this issue as REJECTED, with a signed objection on the  
page from me.  In my objection I use almost this exact example for  
why it should not be rejected:

> Now you are likely to get a lot more docs which don't contain
> microformat data than those which do. Ok, so "xfolkentry" is unlikely
> to be misinterpreted. But what if the documents contain e.g.
>
> <div class="name">
>
> Is this microformat data? Which microformat?

I believe an equivalent solution to what you suggest is, within the  
XMDP, to designate an element unambiguously as the container element  
(all microformats seem to have one).  Automated parsers could pick  
that attribute value up and parse for it as an indicator that  
microformat is in use. This solution is really just the automation of  
the "by-hand" method you employed. Admittedly, the solution does not  
have the force of a URI, but with most microformat container names,  
the difference from a URI is academic and more human friendly.

Right now, since not everyone uses the XMDP, people developing  
parsers for microformats have to create a hand generated list of  
container class elements to parse for.  That's still workable at the  
current scale of things.

Thanks for the observations.  I think they are well made.

Bud
From andyhume at thedredge.org  Thu Jul 14 05:43:43 2005
From: andyhume at thedredge.org (Andy Hume)
Date: Thu Jul 14 05:43:57 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <2B6F3746-2086-47F7-B9EA-0979753A11B0@technorati.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<2B6F3746-2086-47F7-B9EA-0979753A11B0@technorati.com>
Message-ID: <01C95B4B-6E3D-42EE-923B-113A8FEE7207@thedredge.org>


On 14 Jul 2005, at 00:17, Ryan King wrote:


> On Jul 13, 2005, at 4:08 PM, Andy Hume wrote:
>
>>
>> IMHO these early formats will be the key to encouraging developer  
>> uptake because they work here and now, and can be useful in a real  
>> world way. Do we need a developer adoption drive?
>>
>>
>
> Yes and no. To some degree, its already happening without an  
> explicit drive pushing it. On the other hand, education and  
> evangelism is always helpful.
>
> And there's nothing holding anyone back from doing this on their  
> own. I know Tantek and I both regularly email people suggesting  
> that they implement a specific microformat on their site.
>

For sure Ryan, I just don't want to encourage potentially thousands  
of people to author their microformats in a particular way - and then  
you guys to tell me it may have been better some other way. ;)


>>
>> What are your feelings on this? And what specific mark-up example  
>> do you believe would be appropriate for this?
>>
>
> hCalendar makes for good examples, too, because many sites are  
> already publishing events,
>

...and all sites are publishing contact details, hence my choice of  
hcard.


Andy


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
From andyhume at thedredge.org  Thu Jul 14 05:48:14 2005
From: andyhume at thedredge.org (Andy Hume)
Date: Thu Jul 14 05:48:29 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
Message-ID: <39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>


On 14 Jul 2005, at 04:34, Bud Gibson wrote:

> On Jul 13, 2005, at 19:08, Andy Hume wrote:
>
>
>> I run a developer site called UsableType (http://usabletype.com),  
>> (which unfortunately, due to work has had a near 6 month hiatus -  
>> but still appears to have hundreds of feed subscribers) and I am  
>> currently writing a piece for it regarding microformats and more  
>> specifically the hcard format. It is very basic stuff - but the  
>> crux of it is showing how hcard can be useful *now* (mainly  
>> through X2V), and something of a 'call to action' encouraging  
>> designers/developers top spare the 10 minutes it would take to add  
>> their contact details to an hcard on their blogs/portfolio's home  
>> page.
>>
>
> Andy:
>
> My cut is that there are a lot of developer issues lurking, and it  
> would help to get developers attempting to make actual applications  
> and contributing so that we can flesh those out as well as  
> potential solutions.  There is a microformats-dev list just for  
> them, although it is unfortunately now a little underpopulated.
>
> Bud

I'm more concerned with getting your 'average designer in the street'  
to start authoring contact details within an hcard as a matter of  
course. Teach them that the cost is negligible, the benefits are good  
today, and may be great tomorrow. Without an uptake of microformat  
authors they'll be no reason to implement applications or parsing  
machines. Correct?

Andy.





>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
From microformats-discuss at peterjanes.ca  Thu Jul 14 06:33:01 2005
From: microformats-discuss at peterjanes.ca (Peter Janes)
Date: Thu Jul 14 06:33:15 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>
Message-ID: <42D6698D.2050205@peterjanes.ca>

Bud Gibson wrote:
> On Jul 14, 2005, at 6:14, Danny Ayers wrote:
>> Sure, there's an advantage in having well-known semantic markup terms,
>> the vocabularies defined in microformats. But for automatic discovery
>> and processing it's also hugely beneficial to be able to recognise
>> microformat data unambiguously. The doc can be processed in a way
>> appropriate for the microformat. The profile URI provides this
>> disambiguation and allows deterministic processing.
[...]
 > I could not agree more with the issue you raise and was just thinking
 > on this issue as I went to sleep last night and woke this morning.  I
 > included this issue in the XMDP brainstorming on this wiki page:
 >
 > http://microformats.org/wiki/xmdp-brainstorming
 >
 > The person who joined me as page author is not in agreement with us  and
 > has marked this issue as REJECTED, with a signed objection on the  page
 > from me.

I've had a bit of previous offline discussion with Tantek, and it's been my 
impression that he's in favour of requiring linked profiles (since that was 
exactly what we discussed).  I think the rejection of "Just because a profile 
value mentioned in a microformat's linked XMDP also appears in the document 
does not mean that that microformat is in use." is more one of 
wording/interpretation, since it could be taken to mean:

- "just because I've listed the XFN profile doesn't mean that I use any of the 
values defined in it"
- "just because I've listed the XFN profile doesn't mean that rel='met' means 
what it says in XFN" or

I think the purpose of the statement was to express the former argument, and 
the objection is to interpreting it as the latter.

Peter J.
From bud at thecommunityengine.com  Thu Jul 14 08:14:44 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 08:14:45 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D6698D.2050205@peterjanes.ca>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>
	<42D6698D.2050205@peterjanes.ca>
Message-ID: <07038068-C009-4B35-B824-50239B49E9A8@thecommunityengine.com>

On Jul 14, 2005, at 9:33, Peter Janes wrote:

> I've had a bit of previous offline discussion with Tantek, and it's  
> been my impression that he's in favour of requiring linked profiles  
> (since that was exactly what we discussed).  I think the rejection  
> of "Just because a profile value mentioned in a microformat's  
> linked XMDP also appears in the document does not mean that that  
> microformat is in use." is more one of wording/interpretation,  
> since it could be taken to mean:
>
> - "just because I've listed the XFN profile doesn't mean that I use  
> any of the values defined in it"
> - "just because I've listed the XFN profile doesn't mean that  
> rel='met' means what it says in XFN" or
>
> I think the purpose of the statement was to express the former  
> argument, and the objection is to interpreting it as the latter.
>

I agree that we probably need to clear up interpretations which is  
why I am continuing to press this issue.  Having reread the spec a  
couple of times, here is my best interpretation of what linking to an  
XMDP means:

1.  The presence of an XMDP profile only means that a particular  
microformat may be present in the document (Danny Ayers' point).

2.  The presence of an XMDP cannot practically be assumed to mean  
that any occurrence of an attribute value defined in the XMDP is to  
be interpreted according to the XMDP's definition.  There are two  
simple cases that suggest this point:
a.  Two XMDPs are referenced, each one referring to the attribute  
value.  Which takes precedence?  I can come up with some rules of  
thumb, some of which I have heard at conferences, but where are those  
explicitly stated?  My point here simply is that there is a lot of  
unwritten lore that will leave newcomers guessing.
b.  The fact that XMDPs appear at least implicitly to be oriented  
toward defining a specific context that may occur in part of a  
document.  While in discussions concerning the development of xFolk,  
I initially attempted to create unique attribute value names and was  
told that this was "unnecessary syntactic vinegar", the attribute  
value names would be interpreted in context.

3.  The XMDP does not give explicit syntactic significance to the  
attribute value that indicates when it is to be interpreted as  
applying.  Therefore, without reading the XMDP, knowing when it is  
actually in effect is impossible.  This is not just "humans first",  
it is "humans only".

Given all these points, XMDPs need refinement before they can be used  
for automated microformat discovery.  At this stage, the only  
available discovery method is to hand-code the attributes that  
indicate particular microformat contexts into your parser and assume  
some rules of thumb.  This method is still viable at the current scale.

Boy, it seems to make autodiscovery harder than it needs to be,  
particularly as microfomats proliferate.  The simplest solution would  
seem to be to syntactically mark the microformat's enclosing element  
in the XMDP so that it can be extracted during the parsing process.

Bud
From bud at thecommunityengine.com  Thu Jul 14 08:22:08 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 08:22:06 2005
Subject: [microformats-discuss] This group needs tutorial references
Message-ID: <4BD6202A-7D48-4406-9C83-740EBEFCB9CE@thecommunityengine.com>

In interacting with various folk in this community, one realizes that  
there is a lot of lore about the use of microformats.  Extracting the  
lore is typically a hard fought process as witnessed by the 30+  
emails around Josh Porter's initial question concerning microformats  
discovery.

My cut is that we need some tutorial examples that do real things.  I  
am embarking on a project that should generate some of these.  I  
would encourage anyone who has some to write them up on your site and  
send us an email here.

They would be greatly appreciated.

Bud
From bud at thecommunityengine.com  Thu Jul 14 08:27:57 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 08:27:55 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
Message-ID: <8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>

On Jul 14, 2005, at 8:48, Andy Hume wrote:

> I'm more concerned with getting your 'average designer in the  
> street' to start authoring contact details within an hcard as a  
> matter of course. Teach them that the cost is negligible, the  
> benefits are good today, and may be great tomorrow. Without an  
> uptake of microformat authors they'll be no reason to implement  
> applications or parsing machines. Correct?
>

Chicken and egg.  My discussions with authors often suggest that they  
are looking for the compelling value proposition to make the extra  
coding worth it.  That value proposition will come through  
applications and services that consume the microformat.

I humbly submit hCalendar and hCard as examples to support this claim.

Adoption of microformats depends on a clear value proposition to the  
author and ultimate end-user.  This in turn depends partly on the  
availability of applications and services.

Bud
From dimitri.glazkov at gmail.com  Thu Jul 14 08:35:07 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Thu Jul 14 08:35:43 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is "too
	soft'?
Message-ID: <fb15ac2105071408357fd4561a@mail.gmail.com>

>From what I can see MFs are about qualifying markup elements with
attributes (class, rel, and even title), and leaving most markup
decisions up to the developer. There are design principles
(http://microformats.org/wiki/semantic-xhtml-design-principles), but
they don't seem directly consequential to the use of specific
elements. For instance, hCard's container could be a div, a span, or
even an address element -- the hCard spec does not specify that
explicitly. Naturally, some semantics can not be expressed with any
element -- references to external resources still need to be in their
corresponding XHTML form, be that a or img elements.

I can see the value in this "soft" approach, where you don't impose
specific markup requriements on a markup developer. As the MF mission
states correctly, microformats are not about "boiling the ocean".

However, it seems this approach has a drawback: it requires the
implementor of a MF to be knowledgeable in semantics, and most Web app
developers aren't. The problem of free-wheeling instructions is that
they aren't any good for those who can only follow cookbooks.

What could be done to make this more approachable by the average Joe
developer? Is this just basic semantic markup education?

For instance, in some cases, using tables would be perfectly valid
semantic markup to display addresses. There is nothing in hCard that
prevents trs from serving as containers, and tds serving as
properties. What bothers me is that this jump is not easily made
(tables are bad! spans are good! rah-rah!), and will either cause the
developer to abandon using microformats for a particular application,
or make decisions like switching to spans/divs or, worse yet,
embedding additional spans/divs into the tables, to make this work.

Any thoughts on this?

:DG<
From bud at thecommunityengine.com  Thu Jul 14 08:54:47 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 08:54:44 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is
	"too soft'?
In-Reply-To: <fb15ac2105071408357fd4561a@mail.gmail.com>
References: <fb15ac2105071408357fd4561a@mail.gmail.com>
Message-ID: <D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>

On Jul 14, 2005, at 11:35, Dimitri Glazkov wrote:

> The problem of free-wheeling instructions is that
> they aren't any good for those who can only follow cookbooks.
>
> What could be done to make this more approachable by the average Joe
> developer? Is this just basic semantic markup education?
>

My best practical advice is to look at Brian Suda's X2V, available here:

http://suda.co.uk/projects/X2V/

As suggested by this example, right now, you need the following  
knowledge to effectively code with microformats:

1.  Knowledge of XPATH
2.  An understanding of the allowed class attribute values in each  
microformat's XMDP file (linked from the microformat's wiki page).   
In some cases, as in hCalendar, you will need to infer what these are  
from another spec, the iCal spec.
3.  An understanding of any markup elements that are mandated by the  
microformat.  For instance, XOXO requires the use of ordered lists.

Given this state of affairs, I think microformats are now best suited  
to advanced developers who are attempting to do the just barely  
possible, not those who are looking for a development cowpath.

I think the cowpath will come, but we are in more of a Lewis and  
Clark down the Big Muddy stage now.

Bud
From porter at bokardo.com  Thu Jul 14 09:07:18 2005
From: porter at bokardo.com (Joshua Porter)
Date: Thu Jul 14 09:07:27 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
Message-ID: <67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>

To add to Bud's post: I wrote up a short piece for my blog ( http:// 
bokardo.com/archives/intro-to-microformats/ ) right after the  
microformats.org site went up. It was my initial impression, and  
contains some wrong impressions...but ones that could be used, if  
combined with other impressions from other designers, to come up with  
a framework for explaining what they are more clearly.

It doesn't matter if microformats are *right*, it matters if they are  
*supported*. Support comes in part from developers who code for them,  
but without *demand* from users support will die on the vine. Support  
is not just having microformats on a site. It includes the ability of  
users to do something useful with them.

A "showcase" application is a great way to grow demand. Upcoming.org  
is not a showcase application for microformats, because they already  
have .ics and feed files available. There is no incentive for users  
to use a scraping tool over simply grabbing the .ics file.

As I say in my post, a great example of a showcase application is  
http://housingmaps.com

After seeing housingmaps, you don't need to know anything else...you  
just want to use the Google Maps API.


josh



On Jul 14, 2005, at 11:27 AM, Bud Gibson wrote:

> On Jul 14, 2005, at 8:48, Andy Hume wrote:
>
>
>> I'm more concerned with getting your 'average designer in the  
>> street' to start authoring contact details within an hcard as a  
>> matter of course. Teach them that the cost is negligible, the  
>> benefits are good today, and may be great tomorrow. Without an  
>> uptake of microformat authors they'll be no reason to implement  
>> applications or parsing machines. Correct?
>>
>>
>
> Chicken and egg.  My discussions with authors often suggest that  
> they are looking for the compelling value proposition to make the  
> extra coding worth it.  That value proposition will come through  
> applications and services that consume the microformat.
>
> I humbly submit hCalendar and hCard as examples to support this claim.
>
> Adoption of microformats depends on a clear value proposition to  
> the author and ultimate end-user.  This in turn depends partly on  
> the availability of applications and services.
>
> Bud
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From dimitri.glazkov at gmail.com  Thu Jul 14 09:10:14 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Thu Jul 14 09:10:59 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is
	"too soft'?
In-Reply-To: <D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>
References: <fb15ac2105071408357fd4561a@mail.gmail.com>
	<D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>
Message-ID: <fb15ac2105071409106663b66d@mail.gmail.com>

On 7/14/05, Bud Gibson <bud@thecommunityengine.com> wrote:
>
> Given this state of affairs, I think microformats are now best suited
> to advanced developers who are attempting to do the just barely
> possible, not those who are looking for a development cowpath.
> 
> I think the cowpath will come, but we are in more of a Lewis and
> Clark down the Big Muddy stage now.

I guess the spirit of my email was "how do we start working on the cowpaths".

:DG<
From dimitri.glazkov at gmail.com  Thu Jul 14 09:14:21 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Thu Jul 14 09:15:18 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is
	"too soft'?
In-Reply-To: <D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>
References: <fb15ac2105071408357fd4561a@mail.gmail.com>
	<D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>
Message-ID: <fb15ac21050714091441bd1d86@mail.gmail.com>

By the way, have you seen the XPath expressions in Brian's code? If
anything, they demonstrate that XPath is not the best tool for the
job. It may be the only viable tool at the moment, but it wasn't bulit
to flexibly handle of the space-separated attribute values out of the
box. Maybe it's time we summon XSLT extensibility.

:DG<
From ryan at technorati.com  Thu Jul 14 10:14:53 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 10:14:56 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
Message-ID: <CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>

On Jul 14, 2005, at 3:14 AM, Danny Ayers wrote:
> A little plea.
>
> I just noticed that in the example for Bud's XFolk [1] that the blocks
> containing microformats are demarcated using class attributes, i.e.
>
> <div class="xfolkentry">
>
> As it stands, the only way of discovering whether such a document
> contains microformat data is to scrape it and look for that value.
> Consider the following scenario:
>
> You have a subscription to certain del.icio.us RSS feeds; checking the
> linked pages to see if they contain microcontent markup, if they do
> extracting the data and putting it into a queryable store. All
> automatic.
>
> Now you are likely to get a lot more docs which don't contain
> microformat data than those which do. Ok, so "xfolkentry" is unlikely
> to be misinterpreted. But what if the documents contain e.g.
>
> <div class="name">
>
> Is this microformat data? Which microformat?

Depends on the context. For example, we have "description" in several  
microformats, which can be disambiguated by its context. For example,  
this:

<div class="hreview">
<p class="description>
..
</p>
</div>

and this:

<div class="vcalendar>
<span class="description">...</span>
</div>

Are not ambiguous.

> There is a mechanism for recognising microformats in the docs - use a
> profile, e.g.
>
> <head profile="http://example.org/some/microformat/schema">

Yes, and its likely that this will be expanded to at least:

<link rel="profile" href="..." />

if not also:

<a rel="profile" href="...">...</a>

> The microformats docs do cover a simple schema language XDMP, but how
> the schema is done in this context is less significant than it having
> a URI. Having it in the <head> is good too, it isn't necessary to
> parse the whole doc looking for any "known" attributes. It also makes
> it possible to offer support for microformats unknown to the system at
> design time (for RDF-based apps this is straightforward using GRDDL).
>
> Sure, there's an advantage in having well-known semantic markup terms,
> the vocabularies defined in microformats. But for automatic discovery
> and processing it's also hugely beneficial to be able to recognise
> microformat data unambiguously. The doc can be processed in a way
> appropriate for the microformat. The profile URI provides this
> disambiguation and allows deterministic processing. This doesn't in
> any way compromise the "simplicity" aim of microformats, in fact the
> net effect is overall simplification. Hunting for arbitrary strings in
> attributes is hard work!

I'm not sure what point you're trying to make here. I don't think  
anyone's arguing against profile urls.

> I understand there's ongoing discussion about declaring that a
> microformat is in use in doc fragments (where the <head> is
> unavailable). I don't know whether the use of an <a> hyperlink is the
> best mechanism or not (a possible alternative might be to use a URI
> for the outermost microformat term, e.g.  <div
> class="http://example.org/some/microformat/schema/xfolkentry">).

How is this different from

<div class="xfolkentry">

?

> But however it's done, identification of the microformat used within
> the doc by means of a URI (the GUID of the Web) is essential IMHO to
> make the difference between making quality, globally unambiguous data
> available and something barely less fragile than screenscraping as it
> stands.

I don't think anyone is disagreeing with you.

-ryan
From ryan at technorati.com  Thu Jul 14 10:33:25 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 10:33:28 2005
Subject: [microformats-discuss] This group needs tutorial references
In-Reply-To: <4BD6202A-7D48-4406-9C83-740EBEFCB9CE@thecommunityengine.com>
References: <4BD6202A-7D48-4406-9C83-740EBEFCB9CE@thecommunityengine.com>
Message-ID: <91AD9EAD-90A5-4828-9E29-0A4717A9B7D2@technorati.com>

On Jul 14, 2005, at 8:22 AM, Bud Gibson wrote:
> In interacting with various folk in this community, one realizes  
> that there is a lot of lore about the use of microformats.

Lore? I think of it more as legend. :)

There certainly are some things about microformats which have not  
been written in a way that's accessible to newcomers (or written at  
all).

> Extracting the lore is typically a hard fought process as witnessed  
> by the 30+ emails around Josh Porter's initial question concerning  
> microformats discovery.
>
> My cut is that we need some tutorial examples that do real things.   
> I am embarking on a project that should generate some of these.  I  
> would encourage anyone who has some to write them up on your site  
> and send us an email here.

This is great.

-ryan

From joshua.owens at gmail.com  Thu Jul 14 10:44:12 2005
From: joshua.owens at gmail.com (Josh Owens)
Date: Thu Jul 14 10:44:14 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
Message-ID: <ac1175eb05071410444d813251@mail.gmail.com>

Josh,

My question would be, will there ever be much of an advantage to the user to 
utilize a scraping tool over .ics files? All the calendar clients inherintly 
support iCal, not to mention the fact that you could use Brian's x2v tool to 
output an iCal file. I don't think it should be up to the user to utilize 
the scraping tool, it should be up to developers to deliver the content to 
them in tools they already have. I recently had a discussion with Brian Deer 
of evdb.com <http://evdb.com> and we discussed this very thing, why force 
the user to switch/add tools? It just doesn't make sense to me.

--Josh

On 7/14/05, Joshua Porter <porter@bokardo.com> wrote:
> 
> To add to Bud's post: I wrote up a short piece for my blog ( http://
> bokardo.com/archives/intro-to-microformats/<http://bokardo.com/archives/intro-to-microformats/>) right after the
> microformats.org <http://microformats.org> site went up. It was my initial 
> impression, and
> contains some wrong impressions...but ones that could be used, if
> combined with other impressions from other designers, to come up with
> a framework for explaining what they are more clearly.
> 
> It doesn't matter if microformats are *right*, it matters if they are
> *supported*. Support comes in part from developers who code for them,
> but without *demand* from users support will die on the vine. Support
> is not just having microformats on a site. It includes the ability of
> users to do something useful with them.
> 
> A "showcase" application is a great way to grow demand. Upcoming.org<http://Upcoming.org>
> is not a showcase application for microformats, because they already
> have .ics and feed files available. There is no incentive for users
> to use a scraping tool over simply grabbing the .ics file.
> 
> As I say in my post, a great example of a showcase application is
> http://housingmaps.com
> 
> After seeing housingmaps, you don't need to know anything else...you
> just want to use the Google Maps API.
> 
> 
> josh
> 
> 
> 
> On Jul 14, 2005, at 11:27 AM, Bud Gibson wrote:
> 
> > On Jul 14, 2005, at 8:48, Andy Hume wrote:
> >
> >
> >> I'm more concerned with getting your 'average designer in the
> >> street' to start authoring contact details within an hcard as a
> >> matter of course. Teach them that the cost is negligible, the
> >> benefits are good today, and may be great tomorrow. Without an
> >> uptake of microformat authors they'll be no reason to implement
> >> applications or parsing machines. Correct?
> >>
> >>
> >
> > Chicken and egg. My discussions with authors often suggest that
> > they are looking for the compelling value proposition to make the
> > extra coding worth it. That value proposition will come through
> > applications and services that consume the microformat.
> >
> > I humbly submit hCalendar and hCard as examples to support this claim.
> >
> > Adoption of microformats depends on a clear value proposition to
> > the author and ultimate end-user. This in turn depends partly on
> > the availability of applications and services.
> >
> > Bud
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050714/86ed50b7/attachment-0001.html
From ryan at technorati.com  Thu Jul 14 11:00:47 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 11:00:50 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <01C95B4B-6E3D-42EE-923B-113A8FEE7207@thedredge.org>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<2B6F3746-2086-47F7-B9EA-0979753A11B0@technorati.com>
	<01C95B4B-6E3D-42EE-923B-113A8FEE7207@thedredge.org>
Message-ID: <FF9FBACA-9084-4037-87CC-C12C66BF8E67@technorati.com>

On Jul 14, 2005, at 5:43 AM, Andy Hume wrote:
> On 14 Jul 2005, at 00:17, Ryan King wrote:
>> On Jul 13, 2005, at 4:08 PM, Andy Hume wrote:
>>
>>> IMHO these early formats will be the key to encouraging developer  
>>> uptake because they work here and now, and can be useful in a  
>>> real world way. Do we need a developer adoption drive?
>>
>> Yes and no. To some degree, its already happening without an  
>> explicit drive pushing it. On the other hand, education and  
>> evangelism is always helpful.
>>
>> And there's nothing holding anyone back from doing this on their  
>> own. I know Tantek and I both regularly email people suggesting  
>> that they implement a specific microformat on their site.
>
> For sure Ryan, I just don't want to encourage potentially thousands  
> of people to author their microformats in a particular way - and  
> then you guys to tell me it may have been better some other way. ;)

Feel free to ask questions, or run things by the group before sending  
them out.

>>> What are your feelings on this? And what specific mark-up example  
>>> do you believe would be appropriate for this?
>>
>> hCalendar makes for good examples, too, because many sites are  
>> already publishing events,
>
> ...and all sites are publishing contact details, hence my choice of  
> hcard.

Good choice. :)

-ryan
From carl.beeth at gmail.com  Thu Jul 14 11:01:31 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Thu Jul 14 11:01:38 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
Message-ID: <e8ca2e1105071411011cd82fca@mail.gmail.com>

Please be aware I'm not a developer so these question may seem very stupid:

Why as a site administrator I should care about profiles as they are
not needed for the microformat to be valid?

Why as a crawler developer should I care about profiles as they are
not compulsory and I will need to parse the whole page anyway?

Why as a UA developer should I care about profiles as I will need to
parse the whole page anyway?
From ryan at technorati.com  Thu Jul 14 11:12:41 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 11:12:44 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e8ca2e1105071411011cd82fca@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
Message-ID: <5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>

On Jul 14, 2005, at 11:01 AM, Carl Beeth wrote:
> Please be aware I'm not a developer so these question may seem very  
> stupid:
>
> Why as a site administrator I should care about profiles as they are
> not needed for the microformat to be valid?

Because it will help UAs which are trying to parse your documents.

I would also say "to follow the spec" (as in the HTML spec), but that  
probably doesn't help you much.

> Why as a crawler developer should I care about profiles as they are
> not compulsory and I will need to parse the whole page anyway?

Maybe they should be compulsory?

> Why as a UA developer should I care about profiles as I will need to
> parse the whole page anyway?

Don't think just in terms of performance- a profile can still make  
your life easier, as it will make things less ambiguous.

-ryan
From carl.beeth at gmail.com  Thu Jul 14 11:17:20 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Thu Jul 14 11:17:23 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <ac1175eb05071410444d813251@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
Message-ID: <e8ca2e1105071411174a844c59@mail.gmail.com>

> My question would be, will there ever be much of an advantage to the user
> to utilize a scraping tool over .ics files?
The fact that the event is embedded in the HTML page allows the
user-agent to do cool stuff with the data. If it is a link to a iCal
file the only thing he can do is hand it over to the OS.

Remember that you already have the human readable html version and
only have to make tiny changes to make that one machine readable.

> it should be up to developers to deliver the
> content to them in tools they already have.  
I agree but it is not a question of either or, you can offer both.
From ryan at technorati.com  Thu Jul 14 11:25:23 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 11:25:27 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is
	"too soft'?
In-Reply-To: <fb15ac2105071408357fd4561a@mail.gmail.com>
References: <fb15ac2105071408357fd4561a@mail.gmail.com>
Message-ID: <950EAF80-2089-470B-A486-3DE59FBD1953@technorati.com>

On Jul 14, 2005, at 8:35 AM, Dimitri Glazkov wrote:

>> From what I can see MFs are about qualifying markup elements with
> attributes (class, rel, and even title), and leaving most markup
> decisions up to the developer. There are design principles
> (http://microformats.org/wiki/semantic-xhtml-design-principles), but
> they don't seem directly consequential to the use of specific
> elements. For instance, hCard's container could be a div, a span, or
> even an address element -- the hCard spec does not specify that
> explicitly. Naturally, some semantics can not be expressed with any
> element -- references to external resources still need to be in their
> corresponding XHTML form, be that a or img elements.
>
> I can see the value in this "soft" approach, where you don't impose
> specific markup requriements on a markup developer. As the MF mission
> states correctly, microformats are not about "boiling the ocean".
>
> However, it seems this approach has a drawback: it requires the
> implementor of a MF to be knowledgeable in semantics, and most Web app
> developers aren't.

I think *they* (whoever these imaginary people are) are smart enough  
to figure things out.

I think *they* know what a date is, what a time is, what a person is.

> The problem of free-wheeling instructions is that
> they aren't any good for those who can only follow cookbooks.

Right, so we need cookbooks? I'm certain that all of the formats  
could use more examples, even though they come with some examples and  
link to examples /in the wild/.

> What could be done to make this more approachable by the average Joe
> developer? Is this just basic semantic markup education?

Education in semantic markup and web standards will certainly help.  
But, even without understanding these broad principles, people can  
still "cookbook it," esp. with hcard and hcalendar.

> For instance, in some cases, using tables would be perfectly valid
> semantic markup to display addresses.

right.

> There is nothing in hCard that
> prevents trs from serving as containers, and tds serving as
> properties.

Yes. I think upcoming.org is doing this with hcalendar.

> What bothers me is that this jump is not easily made
> (tables are bad! spans are good! rah-rah!), and will either cause the
> developer to abandon using microformats for a particular application,
> or make decisions like switching to spans/divs or, worse yet,
> embedding additional spans/divs into the tables, to make this work.
>
> Any thoughts on this?

Many. :)

-ryan
From ryan at technorati.com  Thu Jul 14 11:26:38 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 11:26:41 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is
	"too soft'?
In-Reply-To: <fb15ac2105071409106663b66d@mail.gmail.com>
References: <fb15ac2105071408357fd4561a@mail.gmail.com>
	<D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>
	<fb15ac2105071409106663b66d@mail.gmail.com>
Message-ID: <8952A4EC-2621-4B6A-AD1F-671642E98125@technorati.com>

On Jul 14, 2005, at 9:10 AM, Dimitri Glazkov wrote:
> On 7/14/05, Bud Gibson <bud@thecommunityengine.com> wrote:
>> Given this state of affairs, I think microformats are now best suited
>> to advanced developers who are attempting to do the just barely
>> possible, not those who are looking for a development cowpath.
>>
>> I think the cowpath will come, but we are in more of a Lewis and
>> Clark down the Big Muddy stage now.
>>
>
> I guess the spirit of my email was "how do we start working on the  
> cowpaths".

Start walking wherever you want to go. :)

-ryan
From ryan at technorati.com  Thu Jul 14 11:31:41 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 11:31:45 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is
	"too soft'?
In-Reply-To: <fb15ac21050714091441bd1d86@mail.gmail.com>
References: <fb15ac2105071408357fd4561a@mail.gmail.com>
	<D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>
	<fb15ac21050714091441bd1d86@mail.gmail.com>
Message-ID: <348AE730-C5A6-4E22-84DB-21014F1B97C3@technorati.com>

On Jul 14, 2005, at 9:14 AM, Dimitri Glazkov wrote:

> By the way, have you seen the XPath expressions in Brian's code? If
> anything, they demonstrate that XPath is not the best tool for the
> job.

I think Brian may agree with you here. :) I think he chose XSLT for  
its cross-platform-ness*.

/me runs off to be sure that Brian's on the list

> It may be the only viable tool at the moment, but it wasn't bulit
> to flexibly handle of the space-separated attribute values out of the
> box. Maybe it's time we summon XSLT extensibility.

-ryan

* Which is much like Java's cross-platform-ness: http:// 
www.elecdesign.com/Articles/ArticleID/2255/2255.html.
From joshua.owens at gmail.com  Thu Jul 14 11:38:04 2005
From: joshua.owens at gmail.com (Josh Owens)
Date: Thu Jul 14 11:38:09 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <e8ca2e1105071411174a844c59@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
Message-ID: <ac1175eb05071411387a14da88@mail.gmail.com>

On 7/14/05, Carl Beeth <carl.beeth@gmail.com> wrote:
> 
> > My question would be, will there ever be much of an advantage to the 
> user
> > to utilize a scraping tool over .ics files?
> The fact that the event is embedded in the HTML page allows the
> user-agent to do cool stuff with the data. 


What is this cool stuff you speak of? I guess I am looking at this from a 
crawler/aggregator point of view, for something like
Agnda.com<http://www.agnda.com/>.
In terms of hCal, what would the user do with the info, besides move it into 
their calendar app of choice?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050714/be06bfea/attachment.htm
From ryan at technorati.com  Thu Jul 14 11:40:45 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 11:40:50 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <ac1175eb05071411387a14da88@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
Message-ID: <13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>

On Jul 14, 2005, at 11:38 AM, Josh Owens wrote:
> On 7/14/05, Carl Beeth <carl.beeth@gmail.com> wrote:
>>> My question would be, will there ever be much of an advantage to  
>>> the user
>>> to utilize a scraping tool over .ics files?
>> The fact that the event is embedded in the HTML page allows the
>> user-agent to do cool stuff with the data.
>
> What is this cool stuff you speak of?

Just imagine that someone wrote a browser which recognized microformats.

-ryan


> I guess I am looking at this from a
> crawler/aggregator point of view, for something like
> Agnda.com<http://www.agnda.com/>.
> In terms of hCal, what would the user do with the info, besides  
> move it into
> their calendar app of choice?
From tantek at technorati.com  Thu Jul 14 11:39:55 2005
From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=)
Date: Thu Jul 14 11:40:55 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
Message-ID: <2d50710487ce9179fe5527037143b235@technorati.com>

Carl,

These are *excellent* questions.   And good answers Ryan.

I've reworded/simplified them a bit and added them to the (new) XMDP 
FAQ page.

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

And I have lots more in my queue to add to that page.

Thanks,

Tantek

On Jul 14, 2005, at 11:12 AM, Ryan King wrote:

> On Jul 14, 2005, at 11:01 AM, Carl Beeth wrote:
>> Please be aware I'm not a developer so these question may seem very 
>> stupid:
>>
>> Why as a site administrator I should care about profiles as they are
>> not needed for the microformat to be valid?
>
> Because it will help UAs which are trying to parse your documents.
>
> I would also say "to follow the spec" (as in the HTML spec), but that 
> probably doesn't help you much.
>
>> Why as a crawler developer should I care about profiles as they are
>> not compulsory and I will need to parse the whole page anyway?
>
> Maybe they should be compulsory?
>
>> Why as a UA developer should I care about profiles as I will need to
>> parse the whole page anyway?
>
> Don't think just in terms of performance- a profile can still make 
> your life easier, as it will make things less ambiguous.
>
> -ryan
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

--
Tantek ?elik
Technorati, Inc.
[censored]


From tantek at technorati.com  Thu Jul 14 11:40:58 2005
From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=)
Date: Thu Jul 14 11:40:58 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <e8ca2e1105071411174a844c59@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
Message-ID: <d7405529868da1db33ad123c42f9c826@technorati.com>

Carl is precisely correct.

Tantek

On Jul 14, 2005, at 11:17 AM, Carl Beeth wrote:

>> My question would be, will there ever be much of an advantage to the 
>> user
>> to utilize a scraping tool over .ics files?
> The fact that the event is embedded in the HTML page allows the
> user-agent to do cool stuff with the data. If it is a link to a iCal
> file the only thing he can do is hand it over to the OS.
>
> Remember that you already have the human readable html version and
> only have to make tiny changes to make that one machine readable.
>
>> it should be up to developers to deliver the
>> content to them in tools they already have.
> I agree but it is not a question of either or, you can offer both.
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From joshua.owens at gmail.com  Thu Jul 14 11:47:11 2005
From: joshua.owens at gmail.com (Josh Owens)
Date: Thu Jul 14 11:47:12 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <ac1175eb050714114647b80908@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<FE577433-B013-41AB-8DF5-E86C45E4DCCC@thecommunityengine.com>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
Message-ID: <ac1175eb050714114758e12c8@mail.gmail.com>

> On Jul 14, 2005, at 11:38 AM, Josh Owens wrote:
> > On 7/14/05, Carl Beeth < carl.beeth@gmail.com> wrote:
> >>> My question would be, will there ever be much of an advantage to
> >>> the user
> >>> to utilize a scraping tool over .ics files? 
> >> The fact that the event is embedded in the HTML page allows the
> >> user-agent to do cool stuff with the data.
> >
> > What is this cool stuff you speak of?
> 
> Just imagine that someone wrote a browser which recognized microformats. 
> 
> -ryan


I am trying to imagine that... but what does the browser *DO* with the 
microformat once it finds it? Hands it over to the user's calendar app? Adds 
a button next to it, ala greasemonkey? I am trying to get a firm 
understanding of the user-space tools for microformats.

Thanks for your patience with me :)

--Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050714/86da3247/attachment.htm
From ryan at technorati.com  Thu Jul 14 11:51:57 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 11:52:25 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <07038068-C009-4B35-B824-50239B49E9A8@thecommunityengine.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>
	<42D6698D.2050205@peterjanes.ca>
	<07038068-C009-4B35-B824-50239B49E9A8@thecommunityengine.com>
Message-ID: <5FA351E8-3037-4D5D-8F70-757E12EDAB2E@technorati.com>

On Jul 14, 2005, at 8:14 AM, Bud Gibson wrote:
> On Jul 14, 2005, at 9:33, Peter Janes wrote:
>> I've had a bit of previous offline discussion with Tantek, and  
>> it's been my impression that he's in favour of requiring linked  
>> profiles (since that was exactly what we discussed).  I think the  
>> rejection of "Just because a profile value mentioned in a  
>> microformat's linked XMDP also appears in the document does not  
>> mean that that microformat is in use." is more one of wording/ 
>> interpretation, since it could be taken to mean:
>>
>> - "just because I've listed the XFN profile doesn't mean that I  
>> use any of the values defined in it"
>> - "just because I've listed the XFN profile doesn't mean that  
>> rel='met' means what it says in XFN" or
>>
>> I think the purpose of the statement was to express the former  
>> argument, and the objection is to interpreting it as the latter.
>
> I agree that we probably need to clear up interpretations which is  
> why I am continuing to press this issue.  Having reread the spec a  
> couple of times, here is my best interpretation of what linking to  
> an XMDP means:
>
> 1.  The presence of an XMDP profile only means that a particular  
> microformat may be present in the document (Danny Ayers' point).

You're right, it doesn't necessarily mean that the microformat  
appears in the document. But it it does show up, then the semantics  
of the profile should be applied to it.

> 2.  The presence of an XMDP cannot practically be assumed to mean  
> that any occurrence of an attribute value defined in the XMDP is to  
> be interpreted according to the XMDP's definition.

Right, but we're not looking for individual attribute values, we're  
looking for attribute values in context. So, given that an hreview  
profile has been referenced, this would not be interpreted as an  
hreview description:

<div class="description>...</div>

but this would

<div class="hreview><span class="description"></span></div>

>   There are two simple cases that suggest this point:
> a.  Two XMDPs are referenced, each one referring to the attribute  
> value.  Which takes precedence?

I believe this has already been covered in the XMDP spec? the  
profiles are applied in order, so the first one takes precedence.  
This is assuming that there really is an ambiguity that is not  
cleared up by the context in quick a microformat is used.

>   I can come up with some rules of thumb, some of which I have  
> heard at conferences, but where are those explicitly stated?

Perhaps nowhere.

> My point here simply is that there is a lot of unwritten lore that  
> will leave newcomers guessing.

Right, and feel free to bring these issues up.

> b.  The fact that XMDPs appear at least implicitly to be oriented  
> toward defining a specific context that may occur in part of a  
> document.  While in discussions concerning the development of  
> xFolk, I initially attempted to create unique attribute value names  
> and was told that this was "unnecessary syntactic vinegar", the  
> attribute value names would be interpreted in context.

Right.

> 3.  The XMDP does not give explicit syntactic significance to the  
> attribute value that indicates when it is to be interpreted as  
> applying.  Therefore, without reading the XMDP, knowing when it is  
> actually in effect is impossible.  This is not just "humans first",  
> it is "humans only".

Right. XMDP's value is almost exclusively for humans. But I think  
that's much more important at this point.

> Given all these points, XMDPs need refinement before they can be  
> used for automated microformat discovery.

I think you're missing the point of the XMDP. The XMDP is largely for  
documentation. Its the profile url that is used to identify when that  
profile's semantics should be applied to a document.

> At this stage, the only available discovery method is to hand-code  
> the attributes that indicate particular microformat contexts into  
> your parser and assume some rules of thumb.  This method is still  
> viable at the current scale.
>
> Boy, it seems to make autodiscovery harder than it needs to be,

I still have no idea what people mean by 'autodiscovery.'

> particularly as microfomats proliferate.  The simplest solution  
> would seem to be to syntactically mark the microformat's enclosing  
> element in the XMDP so that it can be extracted during the parsing  
> process.

During which parsing process? Parsing the XMDP?

-ryan

From dimitri.glazkov at gmail.com  Thu Jul 14 12:30:36 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Thu Jul 14 12:31:23 2005
Subject: [microformats-discuss] In need of an explainer: How "soft" is
	"too soft'?
In-Reply-To: <8952A4EC-2621-4B6A-AD1F-671642E98125@technorati.com>
References: <fb15ac2105071408357fd4561a@mail.gmail.com>
	<D798D2CC-FA10-4D7A-92A8-B6AC4ECBA7A9@thecommunityengine.com>
	<fb15ac2105071409106663b66d@mail.gmail.com>
	<8952A4EC-2621-4B6A-AD1F-671642E98125@technorati.com>
Message-ID: <fb15ac21050714123025e4ce62@mail.gmail.com>

On 7/14/05, Ryan King <ryan@technorati.com> wrote:

> Start walking wherever you want to go. :)

I'm trying, I'm trying ;)

http://main.uab.edu/Shrp/

:DG<
From dimitri.glazkov at gmail.com  Thu Jul 14 13:21:54 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Thu Jul 14 13:22:30 2005
Subject: [microformats-discuss] Presentation material
Message-ID: <fb15ac21050714132162583626@mail.gmail.com>

I will be doing one of them "cutting edge of Web" workshops next week,
and I was wondering which presentations and how could be used/reused
in my workshop? From what I can see, CC Attribution 2.0 license is
applied to most (all?) of them.

Microformats will be just one of the topics, but seems like a perfect
opportunity for evangelizin' -- most of the attendees will be Web folk
from various universities.

I think I will have a window of 10-15 minutes to talk about MF. What
do you guys see as "big points" that I need to hit?

Here's the workshop info:
http://www.salisbury.edu/webconf/program/welcome.htm, scroll to the
very bottom.

:DG<
From lucas.gonze at gmail.com  Thu Jul 14 13:25:36 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Thu Jul 14 13:25:38 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <ac1175eb050714114758e12c8@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
Message-ID: <ab069aa00507141325af9898c@mail.gmail.com>

> > >> The fact that the event is embedded in the HTML page allows the
> > >> user-agent to do cool stuff with the data.
> > >
> > > What is this cool stuff you speak of?

Given standardized HTML formats, we can share CSS for formatting the
data.  Since high-quality CSS is actually pretty hard, this would save
a lot of work.

Given browser-visible data, we can use javascript to manipulate it. 
This allows browser-based tools into a market where only OS-based
tools have been able to go.

We can copy data from one site or page to another without losing the
structure.  For example, we can reblog a blog entry without losing the
original comment-submission URL.  Or, we can copy an event listing
from the promoter's site to an event aggregator and from the
aggregator to the user's calendar.  ...all with plain old web apps.

- Lucas
From kmarks at technorati.com  Thu Jul 14 13:52:38 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Thu Jul 14 13:52:44 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <ab069aa00507141325af9898c@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<ab069aa00507141325af9898c@mail.gmail.com>
Message-ID: <8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>

On Jul 14, 2005, at 1:25 PM, Lucas Gonze wrote:

>>>>> The fact that the event is embedded in the HTML page allows the
>>>>> user-agent to do cool stuff with the data.
>>>>
>>>> What is this cool stuff you speak of?
>
> Given standardized HTML formats, we can share CSS for formatting the
> data.  Since high-quality CSS is actually pretty hard, this would save
> a lot of work.

How about a CSS Zen Garden for microformats?

> Given browser-visible data, we can use javascript to manipulate it.
> This allows browser-based tools into a market where only OS-based
> tools have been able to go.

Several people have been doing this already:

Chris Holland did a javascript that adds expand/collapse arrows to a 
XOXO page:

http://homepage.mac.com/ctholland/thelab/outlines/

David Glasser did a javascript table renderer for hCalendar

http://web.mit.edu/glasser/www/JSCalendar/

An extension of this focused on conference layouts would be a splendid 
thing

Les Orchard has an Outline editor:

http://www.decafbad.com/blog/2005/07/12/xoxo_outliner_experiment


> We can copy data from one site or page to another without losing the
> structure.  For example, we can reblog a blog entry without losing the
> original comment-submission URL.  Or, we can copy an event listing
> from the promoter's site to an event aggregator and from the
> aggregator to the user's calendar.  ...all with plain old web apps.

Lucas, I've been meaning to ask you about citation-wrapping on that - 
some of the examples I've seen have made it hard to tell which is a 
reblogged element and which is commentary by the reblogger. Perhaps you 
can join in the
http://www.microformats.org/wiki/citation-brainstorming

From ryan at technorati.com  Thu Jul 14 14:11:19 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 14:11:22 2005
Subject: [microformats-discuss] resume format
Message-ID: <3D74644D-2492-4CC9-B70B-1A291A41EB38@technorati.com>

Panayotis Vryonis asked:

A CV microformat -does it make sense?

[http://vrypan.net/log/archives/2005/07/12/a-cv-microformat-does-it- 
make-sense/]

And the answer is...

yes.

In fact, about a month ago, after bumping into Dave McClure from  
simplyhired.com, stated that there is a great need for it. So,  
finally, we (Tantek, Kevin and I) met with Dave and his crew (James  
and Sachin, welcome to the list), to get some discussion started  
about a resume microformat*.

I've collected our notes from the meeting on the wiki:

* http://microformats.org/wiki/resume-formats documents common resum?  
formats, as described by the simplyhired guys (who see lots of  
resum?s). Please add any examples to that page, but keep it all  
descriptive. For analysis and other ideas, see

* http://microformats.org/wiki/resume-brainstorming, which captures  
some initial thoughts on how a format could be put together. Feel  
free to add commentary there or on this list.


-ryan


* Someone's already asked if a resum? format would still be  
considered 'micro,' but IMHO, microformats are more about the  
principles than the size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050714/bafce22a/attachment.html
From tantek at technorati.com  Thu Jul 14 14:15:00 2005
From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=)
Date: Thu Jul 14 14:14:57 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<ab069aa00507141325af9898c@mail.gmail.com>
	<8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
Message-ID: <2fe452c7e76f1e69a87d4eb918383904@technorati.com>


On Jul 14, 2005, at 1:52 PM, Kevin Marks wrote:

>> We can copy data from one site or page to another without losing the
>> structure.  For example, we can reblog a blog entry without losing the
>> original comment-submission URL.  Or, we can copy an event listing
>> from the promoter's site to an event aggregator and from the
>> aggregator to the user's calendar.  ...all with plain old web apps.
>
> Lucas, I've been meaning to ask you about citation-wrapping on that - 
> some of the examples I've seen have made it hard to tell which is a 
> reblogged element and which is commentary by the reblogger. Perhaps 
> you can join in the
> http://www.microformats.org/wiki/citation-brainstorming
>

Agreed. There needs to be proper <blockquote>ing built into any such 
reblogging with use of the 'cite' attribute to link to the original, 
and perhaps a user-visible hyperlinked <cite><a href="...">blogged 
from</a></cite> as well.

Reblogging should not mean stealing, but right now, this is what often 
appears to happen -- bloggers stealing content and not giving 
attribution, nor linking to the source, nor distinguishing it from 
their own content.  I'm sure we've all seen examples of this.

As Kevin pointed out, this problem has a lot of overlap with the 
citation-brainstorming efforts, and solving this problem seems 
*especially* critical for reblogging, especially perhaps citing the 
"original" source (rel="original"?) in addition to citing whereever the 
content was reblogged from.

The "what was the original" problem also has overlap with the problem 
of localizations/translations of sites, where it is not always obvious 
what was the original (certainly not mechanically), though while 
rel="alternate" helps to at least say "here is an alternate 
representation".

Thanks,

Tantek



From danny.ayers at gmail.com  Thu Jul 14 14:25:09 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Thu Jul 14 14:25:11 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
Message-ID: <1f2ed5cd050714142568c002d1@mail.gmail.com>

On 7/14/05, Ryan King <ryan@technorati.com> wrote:

> I'm not sure what point you're trying to make here. I don't think
> anyone's arguing against profile urls.

I'm trying to suggest that all microformat documents SHOULD (in the
RFC2119 sense) contain a URI/URIs by which their profile(s) can be
identified.
 
> > I understand there's ongoing discussion about declaring that a
> > microformat is in use in doc fragments (where the <head> is
> > unavailable). I don't know whether the use of an <a> hyperlink is the
> > best mechanism or not (a possible alternative might be to use a URI
> > for the outermost microformat term, e.g.  <div
> > class="http://example.org/some/microformat/schema/xfolkentry">).
> 
> How is this different from
> 
> <div class="xfolkentry">
> 
> ?

It's a URI. See:
http://www.w3.org/TR/webarch/#uri-benefits

> > But however it's done, identification of the microformat used within
> > the doc by means of a URI (the GUID of the Web) is essential IMHO to
> > make the difference between making quality, globally unambiguous data
> > available and something barely less fragile than screenscraping as it
> > stands.
> 
> I don't think anyone is disagreeing with you.

That's very good news, but doesn't appear to be reflected in the current docs.

Cheers,
Danny.

-- 

http://dannyayers.com
From limbo at speakeasy.net  Thu Jul 14 14:38:13 2005
From: limbo at speakeasy.net (Eran)
Date: Thu Jul 14 14:38:19 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <2fe452c7e76f1e69a87d4eb918383904@technorati.com>
Message-ID: <00b201c588bc$56d58470$6464a8c0@hellonwheels>

Tantek Wrote:
> Reblogging should not mean stealing, but right now, this is 
> what often 
> appears to happen -- bloggers stealing content and not giving 
> attribution, nor linking to the source, nor distinguishing it from 
> their own content.  I'm sure we've all seen examples of this.
>

I've been thinking about a similar scenario lately. We're somewhat stuck
with regards to copyright and license information. Wide adoption of
rel=License would definitely be a big help in this case. Maybe some work
on HTMLizing CC's RDF based format? Anything to replace scraping and
guessing. Getting a reference to the original license/copyright would
enable to link to iy (assuming that re-blogging is within its limits,
otherwise, we might not won't to draw any undue attention) and even
modify access premisions to the re-blogged content accordingly.
 
> As Kevin pointed out, this problem has a lot of overlap with the 
> citation-brainstorming efforts, and solving this problem seems 
> *especially* critical for reblogging, especially perhaps citing the 
> "original" source (rel="original"?) in addition to citing 
> whereever the 
> content was reblogged from.
>

I think relForward is a good candidate for this kind of citation. See
http://theryanking.com/blog/archives/2005/06/19/citerel/

Eran.

From tantek at technorati.com  Thu Jul 14 14:38:33 2005
From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=)
Date: Thu Jul 14 14:38:31 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <1f2ed5cd050714142568c002d1@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<1f2ed5cd050714142568c002d1@mail.gmail.com>
Message-ID: <ecf38b5532f7c516390e9dab70bcd3ae@technorati.com>

On Jul 14, 2005, at 2:25 PM, Danny Ayers wrote:

> On 7/14/05, Ryan King <ryan@technorati.com> wrote:
>
>> I'm not sure what point you're trying to make here. I don't think
>> anyone's arguing against profile urls.
>
> I'm trying to suggest that all microformat documents SHOULD (in the
> RFC2119 sense) contain a URI/URIs by which their profile(s) can be
> identified.

Agreed. In fact, that's what I put in the xmdp-faq.

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

>
>>> I understand there's ongoing discussion about declaring that a
>>> microformat is in use in doc fragments (where the <head> is
>>> unavailable). I don't know whether the use of an <a> hyperlink is the
>>> best mechanism or not (a possible alternative might be to use a URI
>>> for the outermost microformat term, e.g.  <div
>>> class="http://example.org/some/microformat/schema/xfolkentry">).
>>
>> How is this different from
>>
>> <div class="xfolkentry">
>>
>> ?
>
> It's a URI. See:
> http://www.w3.org/TR/webarch/#uri-benefits
>
>>> But however it's done, identification of the microformat used within
>>> the doc by means of a URI (the GUID of the Web) is essential IMHO to
>>> make the difference between making quality, globally unambiguous data
>>> available and something barely less fragile than screenscraping as it
>>> stands.
>>
>> I don't think anyone is disagreeing with you.
>
> That's very good news, but doesn't appear to be reflected in the 
> current docs.

See above.

Thanks Danny,

Tantek

From bud at thecommunityengine.com  Thu Jul 14 14:42:18 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 14:42:17 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <1f2ed5cd050714142568c002d1@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<1f2ed5cd050714142568c002d1@mail.gmail.com>
Message-ID: <272B920D-13D2-4634-9490-21144387F946@thecommunityengine.com>

On Jul 14, 2005, at 17:25, Danny Ayers wrote:

> It's a URI. See:
> http://www.w3.org/TR/webarch/#uri-benefits
>
>
>>> But however it's done, identification of the microformat used within
>>> the doc by means of a URI (the GUID of the Web) is essential IMHO to
>>> make the difference between making quality, globally unambiguous  
>>> data
>>> available and something barely less fragile than screenscraping  
>>> as it
>>> stands.
>>>
>>
>> I don't think anyone is disagreeing with you.
>>
>
> That's very good news, but doesn't appear to be reflected in the  
> current docs.
>
> Cheers,
> Danny.

Of course, the URI could just be the URL to the XMDP.

One wonders if a way around this is to designate the container class  
attribute value in the XMDP and then have parsers assume that, within  
the context of the document, that class value resolved to the URI.

Bud
From lucas.gonze at gmail.com  Thu Jul 14 14:43:13 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Thu Jul 14 14:43:14 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<ab069aa00507141325af9898c@mail.gmail.com>
	<8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
Message-ID: <ab069aa00507141443b912f5e@mail.gmail.com>

On 7/14/05, Kevin Marks <kmarks@technorati.com> wrote:
> On Jul 14, 2005, at 1:25 PM, Lucas Gonze wrote:
> > Given standardized HTML formats, we can share CSS for formatting the
> > data.  Since high-quality CSS is actually pretty hard, this would save
> > a lot of work.
> 
> How about a CSS Zen Garden for microformats?

Exactly!  Just having that one thing would make microformats immediately useful.

It takes a long time and a lot of specialized knowledge to make
semantic HTML work in most browsers.  If browser specialists could
contribute reusable components in the same way that tty specialists
contribute reusable libraries, it would be a big win.

> > Given browser-visible data, we can use javascript to manipulate it.
> > This allows browser-based tools into a market where only OS-based
> > tools have been able to go.
> 
> Several people have been doing this already:

Yup.  There are also Ryan's and Tantek's h* editors.  

> > We can copy data from one site or page to another without losing the
> > structure.  For example, we can reblog a blog entry without losing the
> > original comment-submission URL.  Or, we can copy an event listing
> > from the promoter's site to an event aggregator and from the
> > aggregator to the user's calendar.  ...all with plain old web apps.
> 
> Lucas, I've been meaning to ask you about citation-wrapping on that -
> some of the examples I've seen have made it hard to tell which is a
> reblogged element and which is commentary by the reblogger. Perhaps you
> can join in the
> http://www.microformats.org/wiki/citation-brainstorming

Ok, I will wade in.  

- Lucas
From bud at thecommunityengine.com  Thu Jul 14 15:05:48 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 15:05:45 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <2fe452c7e76f1e69a87d4eb918383904@technorati.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<ab069aa00507141325af9898c@mail.gmail.com>
	<8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
	<2fe452c7e76f1e69a87d4eb918383904@technorati.com>
Message-ID: <2272F4D2-7EBA-41C2-AF32-D549A463B4EC@thecommunityengine.com>

[In a questioning tone]

I'm not entirely sure why you would need a blockquote.  Would I need  
a blockquote for your hCard if I reblogged it?

Bud
On Jul 14, 2005, at 17:15, Tantek ?elik wrote:

>
> On Jul 14, 2005, at 1:52 PM, Kevin Marks wrote:
>
>
>>> We can copy data from one site or page to another without losing the
>>> structure.  For example, we can reblog a blog entry without  
>>> losing the
>>> original comment-submission URL.  Or, we can copy an event listing
>>> from the promoter's site to an event aggregator and from the
>>> aggregator to the user's calendar.  ...all with plain old web apps.
>>>
>>
>> Lucas, I've been meaning to ask you about citation-wrapping on  
>> that - some of the examples I've seen have made it hard to tell  
>> which is a reblogged element and which is commentary by the  
>> reblogger. Perhaps you can join in the
>> http://www.microformats.org/wiki/citation-brainstorming
>>
>>
>
> Agreed. There needs to be proper <blockquote>ing built into any  
> such reblogging with use of the 'cite' attribute to link to the  
> original, and perhaps a user-visible hyperlinked <cite><a  
> href="...">blogged from</a></cite> as well.
>
> Reblogging should not mean stealing, but right now, this is what  
> often appears to happen -- bloggers stealing content and not giving  
> attribution, nor linking to the source, nor distinguishing it from  
> their own content.  I'm sure we've all seen examples of this.
>
> As Kevin pointed out, this problem has a lot of overlap with the  
> citation-brainstorming efforts, and solving this problem seems  
> *especially* critical for reblogging, especially perhaps citing the  
> "original" source (rel="original"?) in addition to citing whereever  
> the content was reblogged from.
>
> The "what was the original" problem also has overlap with the  
> problem of localizations/translations of sites, where it is not  
> always obvious what was the original (certainly not mechanically),  
> though while rel="alternate" helps to at least say "here is an  
> alternate representation".
>
> Thanks,
>
> Tantek
>
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From ryan at technorati.com  Thu Jul 14 15:09:46 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 15:09:54 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<ab069aa00507141325af9898c@mail.gmail.com>
	<8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
Message-ID: <EAA0FC0E-9211-47CF-8F98-972BA978652E@technorati.com>

On Jul 14, 2005, at 1:52 PM, Kevin Marks wrote:
> On Jul 14, 2005, at 1:25 PM, Lucas Gonze wrote:
>>>>>> The fact that the event is embedded in the HTML page allows the
>>>>>> user-agent to do cool stuff with the data.
>>>>>
>>>>> What is this cool stuff you speak of?
>>
>> Given standardized HTML formats, we can share CSS for formatting the
>> data.  Since high-quality CSS is actually pretty hard, this would  
>> save
>> a lot of work.
>>
>
> How about a CSS Zen Garden for microformats?

That's been on my todo list for a couple of weeks. Anyone want to help?

-ryan

>
>> Given browser-visible data, we can use javascript to manipulate it.
>> This allows browser-based tools into a market where only OS-based
>> tools have been able to go.
>
> Several people have been doing this already:
>
> Chris Holland did a javascript that adds expand/collapse arrows to  
> a XOXO page:
>
> http://homepage.mac.com/ctholland/thelab/outlines/
>
> David Glasser did a javascript table renderer for hCalendar
>
> http://web.mit.edu/glasser/www/JSCalendar/
>
> An extension of this focused on conference layouts would be a  
> splendid thing
>
> Les Orchard has an Outline editor:
>
> http://www.decafbad.com/blog/2005/07/12/xoxo_outliner_experiment
>
>
>
>> We can copy data from one site or page to another without losing the
>> structure.  For example, we can reblog a blog entry without losing  
>> the
>> original comment-submission URL.  Or, we can copy an event listing
>> from the promoter's site to an event aggregator and from the
>> aggregator to the user's calendar.  ...all with plain old web apps.
>>
>
> Lucas, I've been meaning to ask you about citation-wrapping on that  
> - some of the examples I've seen have made it hard to tell which is  
> a reblogged element and which is commentary by the reblogger.  
> Perhaps you can join in the
> http://www.microformats.org/wiki/citation-brainstorming

From ryan at technorati.com  Thu Jul 14 15:14:31 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 15:14:34 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <00b201c588bc$56d58470$6464a8c0@hellonwheels>
References: <00b201c588bc$56d58470$6464a8c0@hellonwheels>
Message-ID: <0611D9E8-500B-4D13-A9D9-34BC2BE1AB5D@technorati.com>

On Jul 14, 2005, at 2:38 PM, Eran wrote:
> Tantek Wrote:
>
>> Reblogging should not mean stealing, but right now, this is
>> what often
>> appears to happen -- bloggers stealing content and not giving
>> attribution, nor linking to the source, nor distinguishing it from
>> their own content.  I'm sure we've all seen examples of this.
>>
>>
>
> I've been thinking about a similar scenario lately. We're somewhat  
> stuck
> with regards to copyright and license information. Wide adoption of
> rel=License would definitely be a big help in this case. Maybe some  
> work
> on HTMLizing CC's RDF based format?

uh. rel-license?

http://microformats.org/wiki/rel-license

-ryan

> Anything to replace scraping and
> guessing. Getting a reference to the original license/copyright would
> enable to link to iy (assuming that re-blogging is within its limits,
> otherwise, we might not won't to draw any undue attention) and even
> modify access premisions to the re-blogged content accordingly.
>
>
>> As Kevin pointed out, this problem has a lot of overlap with the
>> citation-brainstorming efforts, and solving this problem seems
>> *especially* critical for reblogging, especially perhaps citing the
>> "original" source (rel="original"?) in addition to citing
>> whereever the
>> content was reblogged from.
>>
>>
>
> I think relForward is a good candidate for this kind of citation. See
> http://theryanking.com/blog/archives/2005/06/19/citerel/
>
> Eran.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From ryan at technorati.com  Thu Jul 14 15:16:41 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 15:16:44 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <0611D9E8-500B-4D13-A9D9-34BC2BE1AB5D@technorati.com>
References: <00b201c588bc$56d58470$6464a8c0@hellonwheels>
	<0611D9E8-500B-4D13-A9D9-34BC2BE1AB5D@technorati.com>
Message-ID: <D54BF415-9D55-40D0-A2EF-FE1D0C017B19@technorati.com>

On Jul 14, 2005, at 3:14 PM, Ryan King wrote:
> On Jul 14, 2005, at 2:38 PM, Eran wrote:
>
>> Tantek Wrote:
>>
>>> Reblogging should not mean stealing, but right now, this is
>>> what often
>>> appears to happen -- bloggers stealing content and not giving
>>> attribution, nor linking to the source, nor distinguishing it from
>>> their own content.  I'm sure we've all seen examples of this.
>>
>> I've been thinking about a similar scenario lately. We're somewhat  
>> stuck
>> with regards to copyright and license information. Wide adoption of
>> rel=License would definitely be a big help in this case. Maybe  
>> some work
>> on HTMLizing CC's RDF based format?
>
> uh. rel-license?
>
> http://microformats.org/wiki/rel-license

And, BTW, Yahoo's CC search uses rel-license only.

-ryan

From danny.ayers at gmail.com  Thu Jul 14 15:21:24 2005
From: danny.ayers at gmail.com (Danny Ayers)
Date: Thu Jul 14 15:21:26 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
Message-ID: <1f2ed5cd05071415214992208f@mail.gmail.com>

Just my personal opinions -

On 7/14/05, Ryan King <ryan@technorati.com> wrote:

> > Why as a crawler developer should I care about profiles as they are
> > not compulsory and I will need to parse the whole page anyway?
> 
> Maybe they should be compulsory?

I'd like to see the *reference* to a profile being strongly
recommended, as ranted at length in my previous "URIs" post. This
would mean that you wouldn't necessarily have to parse the whole page,
unless it contained the profile identifier and hence data you were
interested in.

> Don't think just in terms of performance- a profile can still make
> your life easier, as it will make things less ambiguous.

Indeed. 

But I'd be wary of about mandating an XMDP profile, at least until
reference to other schema docs and the like can be easily supported in
a machine-readable fashion. I believe it will be easy enough to do
this for RDF (I forget exactly - something like a reference to the
XSLT in a  <meta> element). Not so sure about XML Schema/DTDs/RelaxNG
though.

Cheeers,
Danny.

-- 

http://dannyayers.com
From brian.suda at gmail.com  Thu Jul 14 15:29:49 2005
From: brian.suda at gmail.com (brian suda)
Date: Thu Jul 14 15:34:27 2005
Subject: [microformats-discuss] Late to the party!
Message-ID: <42D6E75D.6010401@suda.co.uk>

I was just added to the discuss list (i thought i signed-up, but that
must have been the dev list?). I read through the archive as to not
repeat anything and to try to bring myself up to speed with everyones
questions, comments, and thoughts. My X2V came-up several times, so i'll
try to explain the state of it and other Microformat related projects in
the hopper.

X2V is a gigantic XSLT file (actually two, one for hCard, one for hCal -
in hind-sight this was a pretty bad name for the software. It originally
was X for XHTML and XSLT, the 2 was to represent the two x's the two v's
and the work 'to' and the v's are for vCard and vCal. As we know now it
is actually iCal, and also works with bad HTML via Tidy to make it
XHTML. So all-in-all the name is less catchy, but i keep it so not to
confuse everyone using it). The reasons for an XSLT file are multiple:
- it is cross-platform and cross-language, anything that has a good XML
lib could use these files
- it tries to mimic GRDDL
- it can be used in other webservices
- it is RESTful, so it is like a UNIX pipe for the web
- it taught me alot more about XSLT

The XPath expressions have become more and more convoluted with each
iteration of the version. This is due to LOTS of things, one being my
limited use of XSLT (it probably could be optimised), and PHP's
implementation. I tested many XPath expressions offline in Firefox
locally, then ran the same code through the PHP XML lib and it failed,
so some expressions are used because they work in PHP. Others aspects
deal with the nesting of elements, our change over from
'first-letter-capital' to 'all-lower-case' class values. Then also,
class elements can be seperated by spaces, tabs, and/or returns, so
those had to be normalized to spaces then split on spaces. It is a long
process that is never finished. (hence the BETA)

I have also been working on a generic XMDP parser, so you could validate
any page. That page's profile would be extracted, the URIs fetched and
then compared against the XMDPs and some sort of output would be shown.
There were SEVERAL problems (if anyone is interested i can explain
further), mostly dealing with collisions of class values (e.g. url in
vCard and url in iCal) and deciphering if a class value was part of the
CSS style or for a microformat?

i'm certainly on this mailing list now, so i can respond directly to any
Questions about implementations, or is it Consuming?

-brian



From limbo at speakeasy.net  Thu Jul 14 15:41:15 2005
From: limbo at speakeasy.net (Eran)
Date: Thu Jul 14 15:41:25 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <0611D9E8-500B-4D13-A9D9-34BC2BE1AB5D@technorati.com>
Message-ID: <00b601c588c5$2520f960$6464a8c0@hellonwheels>


> > I've been thinking about a similar scenario lately. We're somewhat
> > stuck
> > with regards to copyright and license information. Wide adoption of
> > rel=License would definitely be a big help in this case. 
> Maybe some  
> > work
> > on HTMLizing CC's RDF based format?
> 
> uh. rel-license?
> 

Yep that's what I meant with rel=license. I'd love to see more people
using it so I don't have to scrape license info. That's only the start
though, we need a format for the license itself, I don't think
rel-license deal with that.

Eran.

From lucas.gonze at gmail.com  Thu Jul 14 15:54:22 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Thu Jul 14 15:54:24 2005
Subject: [microformats-discuss] Late to the party!
In-Reply-To: <42D6E75D.6010401@suda.co.uk>
References: <42D6E75D.6010401@suda.co.uk>
Message-ID: <ab069aa00507141554672cdd74@mail.gmail.com>

On 7/14/05, brian suda <brian.suda@gmail.com> wrote:
> i'm certainly on this mailing list now, so i can respond directly to any
> Questions about implementations, or is it Consuming?

Question -- how hard was it to write X2V?  You mentioned collisions
between names used in multiple profiles, but only in the context of a
generic XMDP->parser-generator program.  Does that mean they were
manageable otherwise?  Does your code handle any valid XHTML for a
given h* microformat, or did you have to limit it to specific XHTML
serializations?

What I'm interested in is the question from another thread of how
plausible parsers are in real life.  My impression right now is that
takes a really good developer to pull it off, but it is possible to
do.

- Lucas
From lucas.gonze at gmail.com  Thu Jul 14 16:01:14 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Thu Jul 14 16:01:16 2005
Subject: [microformats-discuss] reblg clarification
In-Reply-To: <8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<ab069aa00507141325af9898c@mail.gmail.com>
	<8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
Message-ID: <ab069aa0050714160125bd5ab4@mail.gmail.com>

On 7/14/05, Kevin Marks <kmarks@technorati.com> wrote:
> > We can copy data from one site or page to another without losing the
> > structure.  For example, we can reblog a blog entry without losing the
> > original comment-submission URL.  Or, we can copy an event listing
> > from the promoter's site to an event aggregator and from the
> > aggregator to the user's calendar.  ...all with plain old web apps.
> 
> Lucas, I've been meaning to ask you about citation-wrapping on that -
> some of the examples I've seen have made it hard to tell which is a
> reblogged element and which is commentary by the reblogger.

A clarification about reblg.com, just in case -- reblg is a gateway to
reblogger apps, not a reblogger itself.  (We'll have a new name for it
as soon as I find the time to implement the change).
From ryan at technorati.com  Thu Jul 14 16:35:30 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 14 16:35:34 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <00b601c588c5$2520f960$6464a8c0@hellonwheels>
References: <00b601c588c5$2520f960$6464a8c0@hellonwheels>
Message-ID: <1B844EAC-9248-4B1D-875E-DC7CC53EA5AF@technorati.com>

On Jul 14, 2005, at 3:41 PM, Eran wrote:
>>> I've been thinking about a similar scenario lately. We're somewhat
>>> stuck
>>> with regards to copyright and license information. Wide adoption of
>>> rel=License would definitely be a big help in this case.
>>>
>> Maybe some
>>
>>> work
>>> on HTMLizing CC's RDF based format?
>>
>> uh. rel-license?
>
> Yep that's what I meant with rel=license.


> I'd love to see more people using it so I don't have to scrape  
> license info.

License info? I think its been used by more people than you'd expect-  
it comes built into the code snippet that CC provides.

> That's only the start
> though,

Isn't everything?

> we need a format for the license itself, I don't think
> rel-license deal with that.

No, it doesn't deal with that. Is not having a machine-readable  
license a problem?

I mean, CC's RDF is a machine readable license, but Yahoo decided to  
ignore it in favor of just using rel-license.

-ryan
From brian.suda at gmail.com  Thu Jul 14 16:47:27 2005
From: brian.suda at gmail.com (brian suda)
Date: Thu Jul 14 16:47:57 2005
Subject: [microformats-discuss] Late to the party!
In-Reply-To: <ab069aa00507141554672cdd74@mail.gmail.com>
References: <42D6E75D.6010401@suda.co.uk>
	<ab069aa00507141554672cdd74@mail.gmail.com>
Message-ID: <42D6F98F.5000601@gmail.com>

Lucas Gonze wrote:

>Question -- how hard was it to write X2V?  
>
It is just several several template calls, so each is pretty independant
(similar to function calls). It has evolved over time, so loads of hours
have been to put into it, but it is never difficult (with the exception
of maths in handling dates)

>You mentioned collisions
>between names used in multiple profiles, but only in the context of a
>generic XMDP->parser-generator program.  Does that mean they were
>manageable otherwise?  Does your code handle any valid XHTML for a
>given h* microformat, or did you have to limit it to specific XHTML
>serializations?
>  
>
This is not really a problem, it is just the similicity of  XMDP. XMDP
is NOT a schema, so it does not define certain things like references
(e.g. transitive in XFN) or other things like 'X' is a child of 'Y'.  So
with hCard/hCal when things must be children of others it is difficult
to represent this in XMDP as machine readable.

This is a hack of an XMDP parser/validator (it is not pretty) but it
will fetch a URL and attempt to apply another XSLT file and output some
very simple output describing what is found.

http://suda.co.uk/projects/XMDP/

One of the potential problems with a generic validator for XMDP file
would be something like the following:
- XMDP defines a class value called "work". The english proses tells you
that this must be a child of an element called class="tel". None of this
is machine readable, so all i can determine from the XMDP is that
class="work" is a valid property in the hCard XMDP profile. Now, on a
given page, you could have class="work" twice, once as a subproperty of
class="tel" (which is the one you actually mean as work phone) and a
second time that describes a footer div or some other CSS style instead
of a microformat. This generic XMDP validator will find BOTH and say
BOTH are actually valid (it is not likely that people would use
microformat terms as CSS styles, but the microformat terms are NOT
reserved words, so there is potential for this).
- A similar situation occurs with class="url". This is defined in both
hCard and hCal, so if you pass a page to the validator and say 'validate
this page against, XFN, hCard, hCal' it will pull out class="url" but it
can not determine (because the XMDP can enforce a structure, only named
values) that the URL is a sub-element of the class='vevent' or 
sub-element  of class="vcard". So when validating with the hCal profile,
it will find the class='url' inside the hCard profile because all the
validator can do is look for "class='url'", it can't (easy) determine
(with advanced knowledge) that this class="url" is ment for hCal and NOT
ment for hCard. (which url is semantically the same in both profiles, it
would be finding them in different places outside of the properties)

The idea of a univeral validator is that it would parse the <head
profile="..."> and fetch those urls, use an XSLT file to convert the
XMDP to another XSLT file and then compare your HTML against the new
XSLT file that was generated from the XMDP. (that's what it currnetly
does, except the XSLT files are cached) That way when  new XMDP files
created for specific purposes they don't need to be regisitered with the
validator. Instead the validator could fetch, parse, and validate
against all of that dynamically on the fly. This is where you would NOT
have any advanced knowledge of the english prose in the descriptions and
would not be able to correct the things stated above.

>What I'm interested in is the question from another thread of how
>plausible parsers are in real life.  My impression right now is that
>takes a really good developer to pull it off, but it is possible to
>do.
>  
>
It is more a case of a solid foundation for getting machine readable
data. XMDP is first ment as human readable, not machines. Other things
like the XML schema (which is HUGE) but it is very well defined so
machine know what to do. CSS parsers are the same, they are a defined
standard, not an ad hoc design like microformats can be.

I hope this answers so of your questions, if you need things explained
further feel free to ask and i'll see what i can do.

-brian
From microformats-discuss at peterjanes.ca  Thu Jul 14 17:42:14 2005
From: microformats-discuss at peterjanes.ca (Peter Janes)
Date: Thu Jul 14 17:42:20 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <5FA351E8-3037-4D5D-8F70-757E12EDAB2E@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>	<42D6698D.2050205@peterjanes.ca>	<07038068-C009-4B35-B824-50239B49E9A8@thecommunityengine.com>
	<5FA351E8-3037-4D5D-8F70-757E12EDAB2E@technorati.com>
Message-ID: <42D70666.7030705@peterjanes.ca>

Ryan King wrote:
> On Jul 14, 2005, at 8:14 AM, Bud Gibson wrote:
>> 2.  The presence of an XMDP cannot practically be assumed to mean  
>> that any occurrence of an attribute value defined in the XMDP is to  
>> be interpreted according to the XMDP's definition.
> 
> Right, but we're not looking for individual attribute values, we're  
> looking for attribute values in context.

I don't think it's necessarily true that a microformat will define a hierarchy 
of attribute values.  Take rel="nofollow"[1], which defines a single value, as 
an example: there's no structure involved, it is significant no matter where 
it appears in a document.  My proposed robots-exclusion profile[2] is an even 
more general case than rel="nofollow" since it defines attribute values (class 
names) that can be used on any subset of elements in a document in any 
combination or order.

(Some may debate that robots-exclusion is a microformat, since even in its 
name it's targeted at crawlers.  To those folks I'd note that rel="nofollow", 
which was created entirely for use by spiders, is perhaps the most 
widely-adopted microformat out there; it certainly has the most significant 
industry backing.)

Peter J.

[1] http://microformats.org/wiki/relnofollow
[2] http://microformats.org/wiki/robots-exclusion
-- 
"Fighting a war is easy.  Destroying is easy.  Building a new world out of
  what's left of the old, that is what's hard."  -- J. Michael Straczynski
      Lenni Jabour and The Third Floor: <http://peterjanes.ca/LenniFan/>
Sirens: <http://www.sirens3.com/>  Petroglyphs: <http://peterjanes.ca/blog/>
From tjameswhite at yahoo.com  Thu Jul 14 17:51:50 2005
From: tjameswhite at yahoo.com (Tim White)
Date: Thu Jul 14 17:51:52 2005
Subject: [microformats-discuss] Re: microformats for various types of media?
In-Reply-To: <20050713182013.9952DF08645@microformats>
Message-ID: <20050715005150.44273.qmail@web30605.mail.mud.yahoo.com>

Dougal's media idea got me to finally make some time and write up a
post[1] that's been a long time coming. It captures my thoughts from
the beginning -- working with semantic markup -- and progresses to
microformats as the solution.

I really think that a media microformat can solve a very simple problem
that I have, as well as introducing some interesting possibilities for
indexers, agregators, etc. The short version: I'm looking for a
meaningful way to distinguish different types of media (books, movies,
etc). The basic XHTML elements are pretty limited on this, but a
microformat would allow us to add meaning to existing elements.

I'm very new to the whole scene and am but a humble self-taught web
developer, so the post may be a bit basic. But hopefully it illustrates
well enough were I'm coming from and where I'd like to go.

Please let me know what you think. Are we onto something? What's next?
(Let me guess: http://www.microformats.org/wiki/process.)

[1] Read the entry:
http://www.tjameswhite.com/blog/archives/2005/07/semantic-markup-microformats/



~ 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 kmarks at technorati.com  Thu Jul 14 17:57:23 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Thu Jul 14 17:57:25 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D70666.7030705@peterjanes.ca>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>	<42D6698D.2050205@peterjanes.ca>	<07038068-C009-4B35-B824-50239B49E9A8@thecommunityengine.com>
	<5FA351E8-3037-4D5D-8F70-757E12EDAB2E@technorati.com>
	<42D70666.7030705@peterjanes.ca>
Message-ID: <367ef496219cc1ee4286fd1e92282c8e@technorati.com>


On Jul 14, 2005, at 5:42 PM, Peter Janes wrote:

> Ryan King wrote:
>> On Jul 14, 2005, at 8:14 AM, Bud Gibson wrote:
>>> 2.  The presence of an XMDP cannot practically be assumed to mean  
>>> that any occurrence of an attribute value defined in the XMDP is to  
>>> be interpreted according to the XMDP's definition.
>> Right, but we're not looking for individual attribute values, we're  
>> looking for attribute values in context.
>
> I don't think it's necessarily true that a microformat will define a 
> hierarchy of attribute values.  Take rel="nofollow"[1], which defines 
> a single value, as an example: there's no structure involved, it is 
> significant no matter where it appears in a document.  My proposed 
> robots-exclusion profile[2] is an even more general case than 
> rel="nofollow" since it defines attribute values (class names) that 
> can be used on any subset of elements in a document in any combination 
> or order.
>
> (Some may debate that robots-exclusion is a microformat, since even in 
> its name it's targeted at crawlers.  To those folks I'd note that 
> rel="nofollow", which was created entirely for use by spiders, is 
> perhaps the most widely-adopted microformat out there; it certainly 
> has the most significant industry backing.)

Right, Peter, but there is a difference between an elemental format , 
which defines a single value, and a compound format like hCard.

Validating the existence of an elemental format is easy, as it is a 
single value; validating a more complex structure requires parsing.

http://www.microformats.org/wiki/elemental-microformat

Also, note the composability of the elements; you can make sense of 
rel="tag" within another format, even if you don't necessarily parse 
that format fully.

From limbo at speakeasy.net  Thu Jul 14 18:39:41 2005
From: limbo at speakeasy.net (Eran)
Date: Thu Jul 14 18:39:45 2005
Subject: [microformats-discuss] reblogging & License
In-Reply-To: <1B844EAC-9248-4B1D-875E-DC7CC53EA5AF@technorati.com>
Message-ID: <00c401c588de$12473160$6464a8c0@hellonwheels>


> 
> License info? I think its been used by more people than you'd 
> expect-  
> it comes built into the code snippet that CC provides.
> 

That's cool but most online content is not under CC. I doubt CNN will
use CC as a license but they will definitely be a popular target for
reblogging.

> No, it doesn't deal with that. Is not having a machine-readable  
> license a problem?
> 

Not having machine reable license is not a problem just as not having
machine readable reviews or events is not a problem. Having machine
reable license has advantages though. For example, a republishing tool
that wants to play nice (and as a result not get shut down by the
supreme court) could use machine readable license info to decide what
can be done with a specific bit of content. Can it be edited? Can it
even be republished? Etc.

Eran.

From solitude at solitude.dk  Thu Jul 14 19:02:32 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Thu Jul 14 19:02:35 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <2fe452c7e76f1e69a87d4eb918383904@technorati.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<ab069aa00507141325af9898c@mail.gmail.com>
	<8dfb55dc798f5a97be549eb2c5d4aff9@technorati.com>
	<2fe452c7e76f1e69a87d4eb918383904@technorati.com>
Message-ID: <op.stxmmiwuares2h@mail.solitude.dk>

On Thu, 14 Jul 2005 23:15:00 +0200, Tantek ?elik <tantek@technorati.com>  
wrote:

> Agreed. There needs to be proper <blockquote>ing built into any such  
> reblogging with use of the 'cite' attribute to link to the original, and  
> perhaps a user-visible hyperlinked <cite><a href="...">blogged  
> from</a></cite> as well.

Of course quotes need to be handled appropriately. In many cases a reblog  
is just a straight copy of an entire post from somewhere else and not a  
quote though. In that case I don't think a <blockquote> is the cleanest  
way to handle it.

When you are making straight copies the trick is *not* to create a second  
permalink for this copy. After all you are not creating a new entry, you  
are simply referencing a post somewhere else. That means you need a way of  
distinguishing permalinks from other links (ie. a microformat for blogs -  
more on that later).

See also: <URL: http://www.solitude.dk/archives/20050103-0020/ > (the XMDP  
profile linked is old, and doesn't reflect my current stance on a format  
for blogs).

See also: <URL: http://www.solitude.dk/ > where permalinks on photo  
entries go straight to the domain where they are reblogged from  
(scatterjoy.net) instead of having a second permalink on solitude.dk.

- Andreas
-- 
<URL:http://www.solitude.dk/>
Commentary on media, communication, culture and technology.
From solitude at solitude.dk  Thu Jul 14 19:06:06 2005
From: solitude at solitude.dk (Andreas Haugstrup)
Date: Thu Jul 14 19:06:13 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <00b201c588bc$56d58470$6464a8c0@hellonwheels>
References: <00b201c588bc$56d58470$6464a8c0@hellonwheels>
Message-ID: <op.stxmsguuares2h@mail.solitude.dk>

On Thu, 14 Jul 2005 23:38:13 +0200, Eran <limbo@speakeasy.net> wrote:

> I've been thinking about a similar scenario lately. We're somewhat stuck
> with regards to copyright and license information. Wide adoption of
> rel=License would definitely be a big help in this case.

My problem is that I can't accurately describe licenses with rel license.  
rel license applies to the page as a whole, but that doesn't work good for  
sharing. Often my own words are under one license, while I loan  
illustrations from others (under another license). I would prefer  
supplying license information as an HTTP header (ala pingbacks) rather  
than having it in the HTML.

- Andreas
-- 
<URL:http://www.solitude.dk/>
Commentary on media, communication, culture and technology.
From bud at thecommunityengine.com  Thu Jul 14 20:13:27 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 14 20:13:25 2005
Subject: [microformats-discuss] Late to the party!
In-Reply-To: <42D6F98F.5000601@gmail.com>
References: <42D6E75D.6010401@suda.co.uk>
	<ab069aa00507141554672cdd74@mail.gmail.com>
	<42D6F98F.5000601@gmail.com>
Message-ID: <53D73032-3357-4D9F-B0CB-77790DB8AD91@thecommunityengine.com>

On Jul 14, 2005, at 19:47, brian suda wrote:

> - XMDP defines a class value called "work". The english proses  
> tells you
> that this must be a child of an element called class="tel". None of  
> this
> is machine readable, so all i can determine from the XMDP is that
> class="work" is a valid property in the hCard XMDP profile. Now, on a
> given page, you could have class="work" twice, once as a  
> subproperty of
> class="tel" (which is the one you actually mean as work phone) and a
> second time that describes a footer div or some other CSS style  
> instead
> of a microformat. This generic XMDP validator will find BOTH and say
> BOTH are actually valid (it is not likely that people would use
> microformat terms as CSS styles, but the microformat terms are NOT
> reserved words, so there is potential for this).

Danny Ayres [sic] raised this issue earlier today.  The context was  
in discovery of microformats.

Basically, my read is that you have to construct your xslt rules  
according to the microformat structure that you read from the XMDP.

I have sometimes wondered if something like schematron would not  
provide a solution.  You could encode these nesting issues, etc.

Bud
From microformats-discuss at peterjanes.ca  Thu Jul 14 20:45:29 2005
From: microformats-discuss at peterjanes.ca (Peter Janes)
Date: Thu Jul 14 20:45:42 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <367ef496219cc1ee4286fd1e92282c8e@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>	<42D6698D.2050205@peterjanes.ca>	<07038068-C009-4B35-B824-50239B49E9A8@thecommunityengine.com>	<5FA351E8-3037-4D5D-8F70-757E12EDAB2E@technorati.com>	<42D70666.7030705@peterjanes.ca>
	<367ef496219cc1ee4286fd1e92282c8e@technorati.com>
Message-ID: <42D73159.2010307@peterjanes.ca>

Kevin Marks wrote:
> On Jul 14, 2005, at 5:42 PM, Peter Janes wrote:
> 
>> Ryan King wrote:
>>> On Jul 14, 2005, at 8:14 AM, Bud Gibson wrote:
>>>> 2.  The presence of an XMDP cannot practically be assumed to mean  
>>>> that any occurrence of an attribute value defined in the XMDP is to  
>>>> be interpreted according to the XMDP's definition.
>>> Right, but we're not looking for individual attribute values, we're  
>>> looking for attribute values in context.
>>
>> I don't think it's necessarily true that a microformat will define a 
>> hierarchy of attribute values.  Take rel="nofollow"[1], which defines 
>> a single value, as an example: there's no structure involved, it is 
>> significant no matter where it appears in a document.  My proposed 
>> robots-exclusion profile[2] is an even more general case than 
>> rel="nofollow" since it defines attribute values (class names) that 
>> can be used on any subset of elements in a document in any combination 
>> or order.
[...]
> Right, Peter, but there is a difference between an elemental format , 
> which defines a single value, and a compound format like hCard.

As far as I can tell the main difference is what the context is.  For 
elemental formats the context is the entire document; for compound documents 
it's the content of all elements that match a top-level element in the XMDP 
hierarchy.

There's nothing stopping an elemental format--where all occurrences of its 
attribute values on a page are significant--from having an XMDP that defines 
its meaning.  (In fact, it's encouraged that all microformats have XMDPs, 
whether they're elemental or not.)  That means that elemental formats are the 
counterexample to the statement that, on a page referencing an XMDP profile, 
individual attribute values are meaningless unless they're contained by some 
other particular attribute value (which is how I read "we're not looking for 
individual attribute values, we're looking for attribute values in context").

I'd propose a new version of Bud Gibson's statement 2, on what linking to an 
XMDP means:

The presence of a link to an XMDP means that any occurrence of a *top-level* 
attribute value defined in the XMDP is to be interpreted according to the 
XMDP's definition.  Within that context, any occurrence of an attribute value 
defined below that top-level attribute in the XMDP's hierarchy is also to be 
interpreted according to the XMDP's definition.

> Validating the existence of an elemental format is easy, as it is a 
> single value; validating a more complex structure requires parsing.
> 
> http://www.microformats.org/wiki/elemental-microformat

I'm not sure "elemental" means "defines a single value".  On that page only 
the Rel* microformats define single values; VoteLinks, XFN and XOXO define 
many values yet are also considered to be elemental.  The distinction seems to 
be more one of structure: elemental formats define values that are applied to 
an attribute of a single element, while compound formats define values that 
are applied to the attributes in a hierarchy of elements.  (robots-exclusion, 
then, would be an elemental format.)

> Also, note the composability of the elements; you can make sense of 
> rel="tag" within another format, even if you don't necessarily parse 
> that format fully.

Unless, for some reason, another XMDP is being used that defines rel="tag" to 
have a different meaning.  One would hope that microformats.org will be able 
to avoid any internal overlap, but there's sure to be some group with their 
own format that redefines an attribute value to something more specific to 
their purpose.  Suppose the IETF defined a "references microformat" for RFCs 
that used rel="tag" to refer to documents created by the W3C's Technical 
Architecture Group; now your tag parser's going to eat a lot of bogus data 
because it presumes it knows what rel="tag" means.  Which gets back to the 
request that started this thread: to explicitly identify each microformat used 
in a document by its URI.

Sorry if this has rambled somewhat between topics; while writing I've been 
skipping through the list and various websites looking for references and 
examples to cite.  Feel free to divide and conquer as necessary. :)

Peter J.
From carl.beeth at gmail.com  Fri Jul 15 02:32:04 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul 15 02:32:07 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <ac1175eb050714114758e12c8@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<39B9EC13-0D68-4FA6-9F51-D5F336634DFC@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
Message-ID: <e8ca2e110507150232705f8e79@mail.gmail.com>

>  I am trying to imagine that... but what does the browser *DO* with the
> microformat once it finds it?  Hands it over to the user's calendar app? 
> Adds a button next to it, ala greasemonkey?  I am trying to get a firm
> understanding of the user-space tools for microformats.

The first thing the browser needs to do is make the user aware that
it's there, maybe by displaying a little icon next to the cursor on
hover. The browser can then give the user a CHOICE of actions on right
click. In the case of a hcard they COULD be:
- Compose a new mail
- Add it to you address book
- Map the location
- Dial the number
- Display the local time
- Forward as vCard

Sorry for the late reply
From carl.beeth at gmail.com  Fri Jul 15 03:55:08 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul 15 03:55:13 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
Message-ID: <e8ca2e1105071503553dc241f3@mail.gmail.com>

I still have doubts on these XMDP Profiles, I can understand that they
are useful but they add a lot of complexity to the authoring. As I see
it one of the big ideas behind microformats is that someone could drop
a hCalendar event in a blog post. Now adding the XMDP Profile may not
seem as a big deal to some but in my opinion it makes it substantially
more complicated. A much more serious case is a XFN reference where
you add a huge overhead for a tiny item.

You will say that I don't need the profile on the element and that it
can be declared in the header of the page. But then you have a new
problem you will always need to know in advance if you will and what
microformat you might use where. I fear what will end up happening is
that implementors will do this on CMS level and all the templates will
contain all the possible XMDP Profiles adding a lot of cruft to the
pages. Or worse it will slow down adoption because it is more
complicated to implement.

So I can understand that there is a need to disambiguate and that XMDP
Profiles do that. But would it not be possible to make a super profile
that contains a bunch of profiles? This way you declare once for the
page that you respect a bunch of microformats.
From brian.suda at gmail.com  Fri Jul 15 04:14:42 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Jul 15 04:15:11 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e8ca2e1105071503553dc241f3@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>	<e8ca2e1105071411011cd82fca@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
Message-ID: <42D79AA2.2060603@gmail.com>

Carl Beeth wrote:

>So I can understand that there is a need to disambiguate and that XMDP
>Profiles do that. But would it not be possible to make a super profile
>that contains a bunch of profiles? This way you declare once for the
>page that you respect a bunch of microformats.
>  
>
The problem with making a super profile is that each DL/DD/DT are NOT
named, so you would have a list of DLs on a page not knowning which
represents which microformat. Then, you could also potentially have
collistions between properties (eg URL in both hCard and hCal, in that
example they both mean the same thing, but this will not always be
true!). Also, if you reference the super profile you could be changing
some of your CSS styles into microformats which is something you maynot
have intended.

I do agree that microformats will probably be controled through a CMS
and therefore parts (such as the head element) maynot be editable. But
without a profile there is no way for a machine to be 100% sure you
meant this to be a microformat and not just CSS styling, nor would we be
able to do auto-discovery via the profile="...". That would have to be
moved to a LINK element (something else that is not usually accessible
via CMSs).

-brian
From carl.beeth at gmail.com  Fri Jul 15 04:30:02 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul 15 04:30:04 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D79AA2.2060603@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
Message-ID: <e8ca2e110507150430111baed3@mail.gmail.com>

> nor would we be
> able to do auto-discovery via the profile="...". 

Again sorry if this is a stupid question but what do we mean with
auto-discovery?
From bud at thecommunityengine.com  Fri Jul 15 04:47:25 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul 15 04:47:22 2005
Subject: [microformats-discuss] Presentation material
In-Reply-To: <fb15ac21050714132162583626@mail.gmail.com>
References: <fb15ac21050714132162583626@mail.gmail.com>
Message-ID: <AF293611-2A77-4774-BD95-945D96B26150@thecommunityengine.com>

On Jul 14, 2005, at 16:21, Dimitri Glazkov wrote:

> I think I will have a window of 10-15 minutes to talk about MF. What
> do you guys see as "big points" that I need to hit?
>
> Here's the workshop info:
> http://www.salisbury.edu/webconf/program/welcome.htm, scroll to the
> very bottom.
>

this depends a lot on what you think the audience will want.  I  
looked at the program and note you are in the marketing track.

What do microformats have to do with marketing?

1.  Meme spreading via reblogging
2.  Vertical search aggregation via tagging
3.  Search visibility via tagging

That's the super summary version.  Are you at UAB?  I go to  
Huntsville all the time these days.

Bud
From brian.suda at gmail.com  Fri Jul 15 05:00:03 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Jul 15 05:00:39 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e8ca2e110507150430111baed3@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>	<e8ca2e1105071411011cd82fca@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
Message-ID: <42D7A543.2030001@gmail.com>

Carl Beeth wrote:

>>nor would we be
>>able to do auto-discovery via the profile="...". 
>>    
>>
>
>Again sorry if this is a stupid question but what do we mean with
>auto-discovery?
>
My description of Auto-Discovery (which might not be the right
description) would be a way for the UA (User-Agent) or plug-in to
automatically display something to the user saying this page is encoded
with a microformat. Safari (and i think Firefox with a plugin) does this
with RSS. If you have something like <link rel="rss"
href="link.to/feed.rss"/> Safari will add a small blue RSS icon in the
title bar. There is a GeoURL plug-in for Mozilla so when you surf to a
page that is GeoURL encoded it displays a small globe in the lower
right-hand corner which links to GeoURL.org with their lat/lon. With
hCa* the auto-discovery would show a small vCard icon, or calendar icon
letting the user know if they click this it will scrap the page and add
the data to their PIM.

Ofcourse, auto-discovery is NOT just icons and pictures, it can be used
by other programs as well. NewsNetWire can use this to fetch RSS feeds
without an actual link to the rss file, only to the homepage. Imagine
using iCal and subscribing just to http://microformats.org, then the
iCal will fetch and parse the HTML code, 'auto-discover' the iCal link
and use that to sync with instead of the homepage link.

If someone is thinking auto-discovery is something different please give
your thoughts.

-brian
From dimitri.glazkov at gmail.com  Fri Jul 15 05:11:48 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Fri Jul 15 05:11:50 2005
Subject: [microformats-discuss] Presentation material
In-Reply-To: <AF293611-2A77-4774-BD95-945D96B26150@thecommunityengine.com>
References: <fb15ac21050714132162583626@mail.gmail.com>
	<AF293611-2A77-4774-BD95-945D96B26150@thecommunityengine.com>
Message-ID: <fb15ac210507150511f3b745d@mail.gmail.com>

On 7/15/05, Bud Gibson <bud@thecommunityengine.com> wrote:

> this depends a lot on what you think the audience will want.  I
> looked at the program and note you are in the marketing track.

Yeah, it's confusing, but this workshop is actually for nitty-gritty
Web developers, not marketing folk. This workshop is the last-minute
addition to the program -- it replaces a marketing session that was
cancelled.

I just couldn't pass up an opportunity to preach. That's also why it
is the only free workshop in the program.

> What do microformats have to do with marketing?
> 
> 1.  Meme spreading via reblogging
> 2.  Vertical search aggregation via tagging
> 3.  Search visibility via tagging
> 
> That's the super summary version.  Are you at UAB?  I go to
> Huntsville all the time these days.

I still like the points that you mentioned, even for the non-marketing
folk. Probably need to shift the focus a bit, but I can use this.

No, UAB is just one of my company's clients. I used to be the UAB
Webmaster for about 5 years, but then the greener pastures (what's up
with this farm talk? first cowpaths, now the pastures) of dot-coms
lured me away.

:DG<
From carl.beeth at gmail.com  Fri Jul 15 05:24:57 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul 15 05:25:00 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D7A543.2030001@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
Message-ID: <e8ca2e110507150524632a3439@mail.gmail.com>

> My description of Auto-Discovery (which might not be the right
> description) would be a way for the UA (User-Agent) or plug-in to
> automatically display something to the user saying this page is encoded
> with a microformat.

No that does not work, in RSS and GEOURL the declaration and object
are one and the same. In our case it is not. If there is a hcard
profile in the head does not mean there will be a hcard in the
document only that there might be one. Actually what it says is that
if you bump into a container with the class "vcard" it is an hcard.
From porter at bokardo.com  Fri Jul 15 05:50:57 2005
From: porter at bokardo.com (Joshua Porter)
Date: Fri Jul 15 05:51:08 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D7A543.2030001@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>	<e8ca2e1105071411011cd82fca@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
Message-ID: <06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>


On Jul 15, 2005, at 8:00 AM, brian suda wrote:

> Carl Beeth wrote:
>
>
>>> nor would we be
>>> able to do auto-discovery via the profile="...".
>>>
>>>
>>>
>>
>> Again sorry if this is a stupid question but what do we mean with
>> auto-discovery?
>>
>>
> My description of Auto-Discovery (which might not be the right
> description) would be a way for the UA (User-Agent) or plug-in to
> automatically display something to the user saying this page is  
> encoded
> with a microformat. Safari (and i think Firefox with a plugin) does  
> this
> with RSS. If you have something like <link rel="rss"
> href="link.to/feed.rss"/> Safari will add a small blue RSS icon in the
> title bar. There is a GeoURL plug-in for Mozilla so when you surf to a
> page that is GeoURL encoded it displays a small globe in the lower
> right-hand corner which links to GeoURL.org with their lat/lon. With
> hCa* the auto-discovery would show a small vCard icon, or calendar  
> icon
> letting the user know if they click this it will scrap the page and  
> add
> the data to their PIM.

This is my interpretation of auto-discovery, too.

However, there is not consensus on this point:

---- earlier exchange------

> On Jul 13, 2005, at 8:08 AM, Tantek ?elik wrote:
>
>
>> On 7/12/05 2:12 PM, "Joshua Porter" <porter@bokardo.com> wrote:
>>
>>
>>
>>> Is it fair to say that microformats are no further along in auto-
>>> discovery than are standalone XML formats?
>>>
>>>
>>
>> I'm not sure that "auto-discovery" as you use it means the same
>> thing as
>> others use it to mean.  It is a bit of an overloaded term, and as
>> such, a
>> specific use-case would help with understanding what you mean.
>>
>
> I'm talking about auto-discovery in the sense that Safari and Firefox
> autodiscover RSS feeds and provide additional functionality to them.
> (Danny and Ryan answered this question by saying that browsers don't
> *currently* autodiscover them in this way.)
>

Ah.  Then the question doesn't make sense as defined, since  
microformats are
used *in* the content, not somewhere else where a rel="alternate" link
points to.


--------end earlier exchange---------

Tantek seems to be saying that since microformats are embedded, then  
you can't auto-discover them like you can with RSS.

However, UAs that notify users of possible actions based on the  
microformats seems to be the right thing to do. If we don't call that  
auto-discovery, what other terms fit better? Auto-notification, perhaps?


>
> Ofcourse, auto-discovery is NOT just icons and pictures, it can be  
> used
> by other programs as well. NewsNetWire can use this to fetch RSS feeds
> without an actual link to the rss file, only to the homepage. Imagine
> using iCal and subscribing just to http://microformats.org, then the
> iCal will fetch and parse the HTML code, 'auto-discover' the iCal link
> and use that to sync with instead of the homepage link.

This sounds like using the index page as an index to all content,  
which feels like the way things are headed. However, if there is no  
explicit link to the content, publishers can't ever change where they  
publish their hCalendar, or there needs to be some sort of  
notification system in place in the case they do.

Not everyone will want to have their calendar information on their  
home page. From what I've gathered from folks on this list, one of  
the strengths of microformats is that they can be embedded on any page.

josh

>
> If someone is thinking auto-discovery is something different please  
> give
> your thoughts.
>
> -brian
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From skeltoac at gmail.com  Fri Jul 15 06:24:15 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Fri Jul 15 06:24:16 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
Message-ID: <e6ec604d0507150624c964500@mail.gmail.com>

> On Jul 15, 2005, at 8:00 AM, brian suda wrote:
> > If someone is thinking auto-discovery is something different please
> > give your thoughts.
> >
> > -brian

I imagine browsing somewhere and seeing a Contact page. If they list
five people with emails, snail mails, phones, faxes, etc., those can
all be imbedded microformats and visible at the same time. I want my
browser to let me handle the data in these microformats without
leaving the page in which they are imbedded.

Autodiscovery might be done by a browser plugin that exposes several
options via a mouseover menu (like IE's Image Toolbar), a transparent
icon over the microformat in context, a Microformats toolbar, you name
it. Same goes for other apps such as email clients, RSS readers, PDF
renderers, on and on.

So when I visit this contact page, I become aware of the hCards and I
know that with a click or a gesture I can compose email, add to
address book, print an envelope, send money via PayPal, etc. Maybe I
have an option to automatically add any encountered hCards to a
special category in my address book for later review. This is my idea
of autodiscovery: behaviors or controls being automatically exposed
when the UA encounters a supported microformat.

Andy Skelton
http://www.skeltoac.com
From carl.beeth at gmail.com  Fri Jul 15 07:16:37 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul 15 07:16:40 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e6ec604d0507150624c964500@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
	<e6ec604d0507150624c964500@mail.gmail.com>
Message-ID: <e8ca2e1105071507169bbb62c@mail.gmail.com>

On 7/15/05, Andy Skelton <skeltoac@gmail.com> wrote:

> So when I visit this contact page, I become aware of the hCards and I
> know that with a click or a gesture I can compose email, add to
> address book, print an envelope, send money via PayPal, etc. Maybe I
> have an option to automatically add any encountered hCards to a
> special category in my address book for later review. This is my idea
> of autodiscovery: behaviors or controls being automatically exposed
> when the UA encounters a supported microformat.

I still fail to see how the profile helps me do this. I still need to
parse the content of the hcard to decide if I can send an email to it.
it might be a hcard without an email.

As I see it the only thing the profile is good for is to make the
class="vcard" unambiguous.

To have to shove a profile declaration into the header for every type
of microformat that might be in use in the page seems overly
complicated to me. If ambiguity is the only issue there must be a more
elegant way to deal with it. I still think one super declaration
should do it, sort of this page contains microformats be aware that
some classes have meaning.
From rbach at rbach.priv.at  Fri Jul 15 07:28:59 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Jul 15 07:28:27 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e8ca2e1105071507169bbb62c@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>	<e8ca2e1105071411011cd82fca@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>	<e8ca2e110507150430111baed3@mail.gmail.com>	<42D7A543.2030001@gmail.com>	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>	<e6ec604d0507150624c964500@mail.gmail.com>
	<e8ca2e1105071507169bbb62c@mail.gmail.com>
Message-ID: <42D7C82B.8070308@rbach.priv.at>

Carl Beeth wrote:
> If ambiguity is the only issue there must be a more
> elegant way to deal with it. I still think one super declaration
> should do it, sort of this page contains microformats be aware that
> some classes have meaning.

Just to make sure I understand you correctly:

I've I want to use hCal and hLicense on a page I would
simply write e.g: <head profile="http://example.org/Microformats/2005">
or something similar, instead of writing e.g:
<head profile="http://example.org/Microformats/hCal-2005
 http://example.org/Microformats/hLicense-2005">?

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From carl.beeth at gmail.com  Fri Jul 15 07:33:48 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul 15 07:33:51 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D7C82B.8070308@rbach.priv.at>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
	<e6ec604d0507150624c964500@mail.gmail.com>
	<e8ca2e1105071507169bbb62c@mail.gmail.com>
	<42D7C82B.8070308@rbach.priv.at>
Message-ID: <e8ca2e11050715073325ed6f54@mail.gmail.com>

> I've I want to use hCal and hLicense on a page I would
> simply write e.g: <head profile="http://example.org/Microformats/2005">
> or something similar, instead of writing e.g:
> <head profile="http://example.org/Microformats/hCal-2005
>  http://example.org/Microformats/hLicense-2005">?

Yes!!
From brian.suda at gmail.com  Fri Jul 15 08:08:42 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Jul 15 08:09:11 2005
Subject: [microformats-discuss] Profiles, what are they good for,
 why do we need them, and how should they be implemented
In-Reply-To: <e8ca2e11050715073325ed6f54@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>	<e8ca2e110507150430111baed3@mail.gmail.com>	<42D7A543.2030001@gmail.com>	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>	<e6ec604d0507150624c964500@mail.gmail.com>	<e8ca2e1105071507169bbb62c@mail.gmail.com>	<42D7C82B.8070308@rbach.priv.at>
	<e8ca2e11050715073325ed6f54@mail.gmail.com>
Message-ID: <42D7D17A.4060806@gmail.com>

Carl Beeth wrote:

>>I've I want to use hCal and hLicense on a page I would
>>simply write e.g: <head profile="http://example.org/Microformats/2005">
>>or something similar, instead of writing e.g:
>><head profile="http://example.org/Microformats/hCal-2005
>> http://example.org/Microformats/hLicense-2005">?
>>    
>>
>
>Yes!!
>
This is a very bad idea. Right now microformats are a bottom-up design,
NOT a top-down. There is no way to make a single profile for every
single possible XMDP that might emerge. Secondly, there is no name
spacing, so if i use XFN and a new microformat called FOO are used
together, there can and WILL be collistions with rel="XXXX" in the future.

If FOO XMDP defines three possible values
rel="you"
rel="me"
rel="them"

Then in my HTML i use the single XMDP profile which somehow knows about
FOO and XFN. What does the following markup mean?
<a href="/1/index.html" rel="you">FOO profile</a>
<a href="/2/index.html" rel="me">FOO or XFN profile</a>

You could then imagine a thrid XMDP profile in this master XMDP profile
called BAR. BAR profile defines these values.
class="alertbox"
class="errorbox"

Now, somewhere on your site you have the following code:
<div class="messagebox errorbox">Not intened to be a microformat, just
two css styles</div>

You want errorbox to be a style NOT a microformat, but since you
declared the master profile your adding semantics to things you never
intended. This would require everyone to know EVERY single value in the
master list, thus creating a bunch of 'CSS reserved words'.

Lumping all the XMDPs into a single place would begin to make it a
top-down centalised syetem, but microformats are small, distributed,
specialized peices of information. I would prefer to see ever
microformat have their own URI then i could pick and choose which i
wanted to include.

There has also been brief discussions about creating a sort of ontology
or way to point to other XMDPs and pull-out only what is needed. A new
XHTML format that could cross-reference properties. So you could define
a new XMDP which is a mixture of a sub-set of two other formats, or say
that the URL in this XMDP is equivalent to the URL in this other XMDP.
RDF has OWL to do this. That way if you wanted you could create your own
uber XMDP and keep it locally on your site, and that XMDP references
other (or parts of) XMDP files scattered across the web.

This is why a generic universal validator would be handy, but XMDP is
meant for human-readbility first, and machine-readablity second. So
somethings people are trying to make microformats do are just out of the
scope of possiblities, lets not forget this.

-brian
From carl.beeth at gmail.com  Fri Jul 15 08:37:27 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Fri Jul 15 08:37:31 2005
Subject: [microformats-discuss] Profiles, what are they good for,
	why do we need them, and how should they be implemented
In-Reply-To: <42D7D17A.4060806@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
	<e6ec604d0507150624c964500@mail.gmail.com>
	<e8ca2e1105071507169bbb62c@mail.gmail.com>
	<42D7C82B.8070308@rbach.priv.at>
	<e8ca2e11050715073325ed6f54@mail.gmail.com>
	<42D7D17A.4060806@gmail.com>
Message-ID: <e8ca2e1105071508377ffe2cd1@mail.gmail.com>

> There is no way to make a single profile for every
> single possible XMDP that might emerge.

OK fair enough but could there be another way to do it? maybe like this:
My pages point to one document on my site that in turn will point the
xmdp's I will use in my site.
I don't think you guys realize how quickly these xmdp's are going to
mushroom. I can easily see a small private site having these:

hCalendar
hCard
RelLicense
RelNoFollow
RelTag
VoteLinks
XFN
hReview
Robots Exclusion
rel-enclosure
xfolk

And that is today, in a couple of weeks there might be more. That
makes for a lot of URL's in the header. Remember people are pragmatic
even though they won't use all these formats on the same page they
will put it all in the template just in case they they need it. Also
you are putting a very large hurdle on adoption if the user has to
muck around in his templates each time he want's to ad a new kind of
microformated content to his site.
From ryan at technorati.com  Fri Jul 15 13:33:20 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 13:33:27 2005
Subject: [microformats-discuss] Re: microformats for various types of
	media?
In-Reply-To: <20050715005150.44273.qmail@web30605.mail.mud.yahoo.com>
References: <20050715005150.44273.qmail@web30605.mail.mud.yahoo.com>
Message-ID: <7BC9AF4A-BB6D-4E5C-9773-9F0795AD3A28@technorati.com>

On Jul 14, 2005, at 5:51 PM, Tim White wrote:

> Dougal's media idea got me to finally make some time and write up a
> post[1] that's been a long time coming. It captures my thoughts from
> the beginning -- working with semantic markup -- and progresses to
> microformats as the solution.
>
> I really think that a media microformat can solve a very simple  
> problem
> that I have, as well as introducing some interesting possibilities for
> indexers, agregators, etc. The short version: I'm looking for a
> meaningful way to distinguish different types of media (books, movies,
> etc). The basic XHTML elements are pretty limited on this, but a
> microformat would allow us to add meaning to existing elements.
>
> I'm very new to the whole scene and am but a humble self-taught web
> developer, so the post may be a bit basic. But hopefully it  
> illustrates
> well enough were I'm coming from and where I'd like to go.
>
> Please let me know what you think. Are we onto something?

Yes.

> What's next?

I'm sure you've seen http://microformats.org/wiki/media-metadata- 
examples

At this point, we still need to do some research. So, add whatever  
media metadata examples you can to that page.

-ryan

> (Let me guess: http://www.microformats.org/wiki/process.)
>
> [1] Read the entry:
> http://www.tjameswhite.com/blog/archives/2005/07/semantic-markup- 
> microformats/

From ryan at technorati.com  Fri Jul 15 13:39:36 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 13:39:38 2005
Subject: [microformats-discuss] reblogging & License
In-Reply-To: <00c401c588de$12473160$6464a8c0@hellonwheels>
References: <00c401c588de$12473160$6464a8c0@hellonwheels>
Message-ID: <976EBE0A-2B72-4312-A4C5-19A20680FB25@technorati.com>

On Jul 14, 2005, at 6:39 PM, Eran wrote:
>> License info? I think its been used by more people than you'd
>> expect- it comes built into the code snippet that CC provides.
>
> That's cool but most online content is not under CC. I doubt CNN will
> use CC as a license but they will definitely be a popular target for
> reblogging.

Right. Of course, you don't need to link to a license. By default,  
its "all rights reserved." So, I don't think CNN would even need to  
link to a license.

>> No, it doesn't deal with that. Is not having a machine-readable
>> license a problem?
>
> Not having machine reable license is not a problem just as not having
> machine readable reviews or events is not a problem.

Of course, there are millions of reviews, so there's no way that a  
human being could read all of them, whereas there are (at most)  
dozens of licenses; someone could read all of those (or pay their  
lawyer to).

> Having machine
> reable license has advantages though. For example, a republishing tool
> that wants to play nice (and as a result not get shut down by the
> supreme court) could use machine readable license info to decide what
> can be done with a specific bit of content. Can it be edited? Can it
> even be republished? Etc.

Right. Currently, the software developers have to know about the  
possible licenses and code to deal with them individually. Currently  
there are not enough licenses out there for this to be a problem.  
(and, having few licenses is good :))

-ryan
From ryan at technorati.com  Fri Jul 15 13:43:41 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 13:43:44 2005
Subject: [microformats-discuss] reblogging needs proper citation,
	source attribution, as does localization/translation
In-Reply-To: <op.stxmsguuares2h@mail.solitude.dk>
References: <00b201c588bc$56d58470$6464a8c0@hellonwheels>
	<op.stxmsguuares2h@mail.solitude.dk>
Message-ID: <0099F7BC-F2DB-4170-BBC1-B77DB49A0ECB@technorati.com>

On Jul 14, 2005, at 7:06 PM, Andreas Haugstrup wrote:
> On Thu, 14 Jul 2005 23:38:13 +0200, Eran <limbo@speakeasy.net> wrote:
>> I've been thinking about a similar scenario lately. We're somewhat  
>> stuck
>> with regards to copyright and license information. Wide adoption of
>> rel=License would definitely be a big help in this case.
>
> My problem is that I can't accurately describe licenses with rel  
> license. rel license applies to the page as a whole,

Maybe we need to iterate the spec so that it can refer to parts of a  
page, much the way the other "rel-" elemental microformats do.

> but that doesn't work good for sharing. Often my own words are  
> under one license, while I loan illustrations from others (under  
> another license). I would prefer supplying license information as  
> an HTTP header (ala pingbacks) rather than having it in the HTML.

I would stay away from a solution that requires special HTTP headers,  
it seems needlessly complex. Plus, you're probably going to want to  
put some (probably human readable) in the HTML, anyways, so why don't  
you just make that structured?

-ryan
From rbach at rbach.priv.at  Fri Jul 15 14:02:57 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Jul 15 14:02:40 2005
Subject: [microformats-discuss] Invalid XHTML
Message-ID: <42D82481.9000201@rbach.priv.at>

I noticed some XHTML markup errors on microformats.org.

index.html - Invalid, there are nested <p>s

<p><!-- technorati tags start --><br />
<p style="text-align:right;font-size:10px;">Technorati Tags: <a
href="http://technorati.com/tag/geo" rel="tag">geo</a>, <a
href="http://technorati.com/tag/microformat" rel="tag">microformat</a>,
<a href="http://technorati.com/tag/microformats"
rel="tag">microformats</a></p>
<!-- technorati tags end -->
</p>

code/: Ill-formed, </p> instead of </li>

<li><a href="http://gmpg.org/xfn/creator">XFN creator</a> - A Web-based
interface for quickly creating a link with the proper XFN values.<br />
Available in the following languages:</p>

There were also some XHTML errors on some Wikipages, I've fixed those
in [[hCalender]] and [[hCard]].
When you make a new entry please be so kind and validate the resluting
XHTML.

I've also discovered a small bug in the Wiki, see
http://bugzilla.wikipedia.org/long_list.cgi?buglist=2870

Could someone with SSH or FTP access to microformats.org please contact
me offlist, so we can fix this bug.
Perhaps updating form MediaWiki from version 1.4.2 to 1.4.7 (the latest
stable release) would also be good.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From bud at thecommunityengine.com  Fri Jul 15 14:09:50 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul 15 14:09:48 2005
Subject: [microformats-discuss] Invalid XHTML
In-Reply-To: <42D82481.9000201@rbach.priv.at>
References: <42D82481.9000201@rbach.priv.at>
Message-ID: <458DDCC2-69DF-4925-8393-90C3E5CA2D02@thecommunityengine.com>

Thanks Robert, I'll check the xfolk page also over the weekend.
On Jul 15, 2005, at 17:02, Robert Bachmann wrote:

> I noticed some XHTML markup errors on microformats.org.
>
> index.html - Invalid, there are nested <p>s
>
> <p><!-- technorati tags start --><br />
> <p style="text-align:right;font-size:10px;">Technorati Tags: <a
> href="http://technorati.com/tag/geo" rel="tag">geo</a>, <a
> href="http://technorati.com/tag/microformat" rel="tag">microformat</ 
> a>,
> <a href="http://technorati.com/tag/microformats"
> rel="tag">microformats</a></p>
> <!-- technorati tags end -->
> </p>
>
> code/: Ill-formed, </p> instead of </li>
>
> <li><a href="http://gmpg.org/xfn/creator">XFN creator</a> - A Web- 
> based
> interface for quickly creating a link with the proper XFN  
> values.<br />
> Available in the following languages:</p>
>
> There were also some XHTML errors on some Wikipages, I've fixed those
> in [[hCalender]] and [[hCard]].
> When you make a new entry please be so kind and validate the resluting
> XHTML.
>
> I've also discovered a small bug in the Wiki, see
> http://bugzilla.wikipedia.org/long_list.cgi?buglist=2870
>
> Could someone with SSH or FTP access to microformats.org please  
> contact
> me offlist, so we can fix this bug.
> Perhaps updating form MediaWiki from version 1.4.2 to 1.4.7 (the  
> latest
> stable release) would also be good.
>
> Robert
> -- 
> Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From ryan at technorati.com  Fri Jul 15 14:14:01 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 14:14:04 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D73159.2010307@peterjanes.ca>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<39B2A104-3453-4277-8F74-D0408B6EF492@thecommunityengine.com>	<42D6698D.2050205@peterjanes.ca>	<07038068-C009-4B35-B824-50239B49E9A8@thecommunityengine.com>	<5FA351E8-3037-4D5D-8F70-757E12EDAB2E@technorati.com>	<42D70666.7030705@peterjanes.ca>
	<367ef496219cc1ee4286fd1e92282c8e@technorati.com>
	<42D73159.2010307@peterjanes.ca>
Message-ID: <13936520-A7AD-4C61-9FB8-5B9964D046C3@technorati.com>

On Jul 14, 2005, at 8:45 PM, Peter Janes wrote:
> Kevin Marks wrote:
> [...]
>> Right, Peter, but there is a difference between an elemental  
>> format , which defines a single value, and a compound format like  
>> hCard.
>
> As far as I can tell the main difference is what the context is.

Actually, I think the elemental vs. compound is more about size and  
reusability than anything else. I think Kevin came up with that  
distinction, so he'd be able to answer more clearly.

>   For elemental formats the context is the entire document; for  
> compound documents it's the content of all elements that match a  
> top-level element in the XMDP hierarchy.

I think you're reading too much into the elemental vs. compound  
thing. Elemental microformats are "small and useful for building  
other microformats." Compound are "bigger and sometimes composed of  
elemental microformats."

> There's nothing stopping an elemental format--where all occurrences  
> of its attribute values on a page are significant--from having an  
> XMDP that defines its meaning.  (In fact, it's encouraged that all  
> microformats have XMDPs, whether they're elemental or not.)

Right. And no one is discouraging use from doing that.

>   That means that elemental formats are the counterexample to the  
> statement that, on a page referencing an XMDP profile, individual  
> attribute values are meaningless unless they're contained by some  
> other particular attribute value (which is how I read "we're not  
> looking for individual attribute values, we're looking for  
> attribute values in context").

No. I think you've misunderstood what I wrote. I was trying to  
emphasize context as a way to disambiguate terms. "Context" does not  
imply "containment."


> I'd propose a new version of Bud Gibson's statement 2, on what  
> linking to an XMDP means:
>
> The presence of a link to an XMDP means that any occurrence of a  
> *top-level* attribute value defined in the XMDP is to be  
> interpreted according to the XMDP's definition.  Within that  
> context, any occurrence of an attribute value defined below that  
> top-level attribute in the XMDP's hierarchy is also to be  
> interpreted according to the XMDP's definition.

I really don't think it has to be this complex.

Why can't we just use the definiton of 'profile' from HTML [http:// 
www.w3.org/TR/REC-html40/struct/global.html#h-7.4.4.3]? That was the  
original intent with having profile urls. I don't think there's any  
value in diverging from that definition (of course, we are extending  
it in that we use profiles to define things outside <meta>).

>> Validating the existence of an elemental format is easy, as it is  
>> a single value; validating a more complex structure requires parsing.
>> http://www.microformats.org/wiki/elemental-microformat
>
> I'm not sure "elemental" means "defines a single value".

It doesn't. I just means "small and reusable."

> On that page only the Rel* microformats define single values;  
> VoteLinks, XFN and XOXO define many values yet are also considered  
> to be elemental.

Single value, multiple *possible values.* With XFN, you're looking  
for single values (scalars, if you will).

XOXO, of course, isn't very "small," but is heavy on "reusable." :)

> The distinction seems to be more one of structure: elemental  
> formats define values that are applied to an attribute of a single  
> element, while compound formats define values that are applied to  
> the attributes in a hierarchy of elements.  (robots-exclusion,  
> then, would be an elemental format.)

The distinction is not that clear, nor does it need to be.

>> Also, note the composability of the elements; you can make sense  
>> of rel="tag" within another format, even if you don't necessarily  
>> parse that format fully.
>
> Unless, for some reason, another XMDP is being used that defines  
> rel="tag" to have a different meaning.  One would hope that  
> microformats.org will be able to avoid any internal overlap,

Yes.

> but there's sure to be some group with their own format that  
> redefines an attribute value to something more specific to their  
> purpose.  Suppose the IETF defined a "references microformat" for  
> RFCs that used rel="tag" to refer to documents created by the W3C's  
> Technical Architecture Group;

Hmm. IETF an W3C working together? Sounds like a conspiracy. Of  
course IETF publishes all their docs in plain text, not HTML.

> now your tag parser's going to eat a lot of bogus data because it  
> presumes it knows what rel="tag" means.

Right.

>   Which gets back to the request that started this thread: to  
> explicitly identify each microformat used in a document by its URI.

Ok. That's enough.

We have consensus.

There is no disagreement.

We need to have URLs to identify microformats.

-ryan


> Sorry if this has rambled somewhat between topics; while writing  
> I've been skipping through the list and various websites looking  
> for references and examples to cite.  Feel free to divide and  
> conquer as necessary. :)
>
> Peter J.
From ryan at technorati.com  Fri Jul 15 14:16:28 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 14:16:40 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e8ca2e1105071503553dc241f3@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
Message-ID: <B613D43A-633D-4859-95BF-434A2B6975BD@technorati.com>

On Jul 15, 2005, at 3:55 AM, Carl Beeth wrote:

> I still have doubts on these XMDP Profiles, I can understand that they
> are useful but they add a lot of complexity to the authoring. As I see
> it one of the big ideas behind microformats is that someone could drop
> a hCalendar event in a blog post. Now adding the XMDP Profile may not
> seem as a big deal to some but in my opinion it makes it substantially
> more complicated. A much more serious case is a XFN reference where
> you add a huge overhead for a tiny item.

Huge overhead? A single link is huge overhead?

> You will say that I don't need the profile on the element and that it
> can be declared in the header of the page. But then you have a new
> problem you will always need to know in advance if you will and what
> microformat you might use where. I fear what will end up happening is
> that implementors will do this on CMS level and all the templates will
> contain all the possible XMDP Profiles adding a lot of cruft to the
> pages. Or worse it will slow down adoption because it is more
> complicated to implement.

More complicated than what?

Once again. We know that allowing other options than <head  
profile=""> is necessary.

No need to bring it up again. It will happen.

> So I can understand that there is a need to disambiguate and that XMDP
> Profiles do that. But would it not be possible to make a super profile
> that contains a bunch of profiles? This way you declare once for the
> page that

Did you get cut off here?

-ryan
From ryan at technorati.com  Fri Jul 15 14:18:10 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 14:18:12 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <42D79AA2.2060603@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>	<e8ca2e1105071411011cd82fca@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
Message-ID: <A38E9AAC-504B-459F-95B2-745D9ADBD32A@technorati.com>

On Jul 15, 2005, at 4:14 AM, brian suda wrote:
> Carl Beeth wrote:
>> So I can understand that there is a need to disambiguate and that  
>> XMDP
>> Profiles do that. But would it not be possible to make a super  
>> profile
>> that contains a bunch of profiles? This way you declare once for the
>> page that you respect a bunch of microformats.
> The problem with making a super profile is that each DL/DD/DT are NOT
> named, so you would have a list of DLs on a page not knowning which
> represents which microformat. Then, you could also potentially have
> collistions between properties (eg URL in both hCard and hCal, in that
> example they both mean the same thing, but this will not always be
> true!). Also, if you reference the super profile you could be changing
> some of your CSS styles into microformats which is something you  
> maynot
> have intended.
>
> I do agree that microformats will probably be controled through a CMS
> and therefore parts (such as the head element) maynot be editable. But
> without a profile there is no way for a machine to be 100% sure you
> meant this to be a microformat and not just CSS styling, nor would  
> we be
> able to do auto-discovery via the profile="...". That would have to be
> moved to a LINK element (something else that is not usually accessible
> via CMSs).
>

Once more...

We've already covered this.

<link rel="profile" href=".." /> has already been proposed by Tantek  
and Eric at W3C.

<a rel="profile" href=".."> will likely be added, but don't expect it  
to happen today.

-ryan
From ryan at technorati.com  Fri Jul 15 14:18:56 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 14:18:58 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e8ca2e110507150430111baed3@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
Message-ID: <31AE1986-C622-48EF-9EDA-76F37D8160CE@technorati.com>

On Jul 15, 2005, at 4:30 AM, Carl Beeth wrote:

>> nor would we be
>> able to do auto-discovery via the profile="...".
>
> Again sorry if this is a stupid question but what do we mean with
> auto-discovery?

Not a stupid question. I've asked it several times in this thread,  
though it hasn't been answered.

-ryan
From ryan at technorati.com  Fri Jul 15 14:29:44 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 14:29:49 2005
Subject: [microformats-discuss] URIs please!
In-Reply-To: <e8ca2e11050715073325ed6f54@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
	<e6ec604d0507150624c964500@mail.gmail.com>
	<e8ca2e1105071507169bbb62c@mail.gmail.com>
	<42D7C82B.8070308@rbach.priv.at>
	<e8ca2e11050715073325ed6f54@mail.gmail.com>
Message-ID: <DF85CCAE-1B7D-4ABF-ADC0-01EB0897E429@technorati.com>

On Jul 15, 2005, at 7:33 AM, Carl Beeth wrote:

>> I've I want to use hCal and hLicense on a page I would
>> simply write e.g: <head profile="http://example.org/Microformats/ 
>> 2005">
>> or something similar, instead of writing e.g:
>> <head profile="http://example.org/Microformats/hCal-2005
>>  http://example.org/Microformats/hLicense-2005">?
>>
>
> Yes!!

I think this is a case of premature optimization.

Let's worry about optimizing microformats after they have some adoption.

-ryan
From ryan at technorati.com  Fri Jul 15 14:34:20 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 14:34:25 2005
Subject: [microformats-discuss] Profiles, what are they good for,
	why do we need them, and how should they be implemented
In-Reply-To: <e8ca2e1105071508377ffe2cd1@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
	<e6ec604d0507150624c964500@mail.gmail.com>
	<e8ca2e1105071507169bbb62c@mail.gmail.com>
	<42D7C82B.8070308@rbach.priv.at>
	<e8ca2e11050715073325ed6f54@mail.gmail.com>
	<42D7D17A.4060806@gmail.com>
	<e8ca2e1105071508377ffe2cd1@mail.gmail.com>
Message-ID: <1A751970-1D93-4FDE-881C-DDF306B5558F@technorati.com>

On Jul 15, 2005, at 8:37 AM, Carl Beeth wrote:
>> There is no way to make a single profile for every
>> single possible XMDP that might emerge.
>
> OK fair enough but could there be another way to do it? maybe like  
> this:
> My pages point to one document on my site that in turn will point the
> xmdp's I will use in my site.

A couple comments:

1. What problem are we trying to solve here?
2. According to the spec the profile references URIs.

> I don't think you guys realize how quickly these xmdp's are going to
> mushroom. I can easily see a small private site having these:
>
> hCalendar
> hCard
> RelLicense
> RelNoFollow
> RelTag
> VoteLinks
> XFN
> hReview
> Robots Exclusion
> rel-enclosure
> xfolk
>
> And that is today, in a couple of weeks there might be more. That
> makes for a lot of URL's in the header.

I may be slow here, but I don't see what the problem with that is.

> Remember people are pragmatic
> even though they won't use all these formats on the same page they
> will put it all in the template just in case they they need it. Also
> you are putting a very large hurdle on adoption if the user has to
> muck around in his templates each time he want's to ad a new kind of
> microformated content to his site.

Once again, we've already covered the <head profile> vs. <link  
rel="profile" vs. <a rel="profile">

That feedback has been accepted and will be added to the XMDP spec.

-ryan
From ryan at technorati.com  Fri Jul 15 14:56:31 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 14:56:33 2005
Subject: [microformats-discuss] Invalid XHTML
In-Reply-To: <42D82481.9000201@rbach.priv.at>
References: <42D82481.9000201@rbach.priv.at>
Message-ID: <08422D28-7EEB-4047-B6D5-B1846231BAC0@technorati.com>

On Jul 15, 2005, at 2:02 PM, Robert Bachmann wrote:

> I noticed some XHTML markup errors on microformats.org.
>
> index.html - Invalid, there are nested <p>s
>
> <p><!-- technorati tags start --><br />
> <p style="text-align:right;font-size:10px;">Technorati Tags: <a
> href="http://technorati.com/tag/geo" rel="tag">geo</a>, <a
> href="http://technorati.com/tag/microformat" rel="tag">microformat</ 
> a>,
> <a href="http://technorati.com/tag/microformats"
> rel="tag">microformats</a></p>
> <!-- technorati tags end -->
> </p>

I broke it, I fixed it. :)

> code/: Ill-formed, </p> instead of </li>
>
> <li><a href="http://gmpg.org/xfn/creator">XFN creator</a> - A Web- 
> based
> interface for quickly creating a link with the proper XFN  
> values.<br />
> Available in the following languages:</p>
>
> There were also some XHTML errors on some Wikipages, I've fixed those
> in [[hCalender]] and [[hCard]].
> When you make a new entry please be so kind and validate the resluting
> XHTML.

Good idea.

> I've also discovered a small bug in the Wiki, see
> http://bugzilla.wikipedia.org/long_list.cgi?buglist=2870

I've applied the patch for this bug. Please let me know if something  
doesn't look right on the wiki.

-ryan

> Could someone with SSH or FTP access to microformats.org please  
> contact
> me offlist, so we can fix this bug.
> Perhaps updating form MediaWiki from version 1.4.2 to 1.4.7 (the  
> latest
> stable release) would also be good.
>
> Robert
> -- 
> Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From bud at thecommunityengine.com  Fri Jul 15 15:52:28 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul 15 15:52:25 2005
Subject: [microformats-discuss] Profiles, what are they good for,
	why do we need them, and how should they be implemented
In-Reply-To: <e8ca2e1105071508377ffe2cd1@mail.gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
	<e6ec604d0507150624c964500@mail.gmail.com>
	<e8ca2e1105071507169bbb62c@mail.gmail.com>
	<42D7C82B.8070308@rbach.priv.at>
	<e8ca2e11050715073325ed6f54@mail.gmail.com>
	<42D7D17A.4060806@gmail.com>
	<e8ca2e1105071508377ffe2cd1@mail.gmail.com>
Message-ID: <17C91EE2-2D69-4783-B9F2-CE8936D7AD3F@thecommunityengine.com>

On Jul 15, 2005, at 11:37, Carl Beeth wrote:


> And that is today, in a couple of weeks there might be more. That
> makes for a lot of URL's in the header. Remember people are pragmatic
> even though they won't use all these formats on the same page they
> will put it all in the template just in case they they need it. Also
> you are putting a very large hurdle on adoption if the user has to
> muck around in his templates each time he want's to ad a new kind of
> microformated content to his site.
>
>

Carl:

I find this point to very well taken, and it comes back to Danny  
Ayers' idea of using URIs to ID when the microformat is being used.   
If the URI were simply the URL to the XMDP, we would kill two birds  
with one stone.

In another communication, Ryan King indicated that XFN actually uses  
the URI as the class attribute value that encloses an XFN entry.   
Somebody with foresight of the problem you are describing made that  
decision.

One mechanism available now is to simply place a link to the XMDP in  
the microformatted text as described here:

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

(the page is a little messy, but you should find it).  Short of  
adopting Ayers' suggestion, this solution at least allows you to just  
plop in links to the XMDP without having access to the head.

As I think about it, I like Ayers' suggestion more and more.  Maybe  
that will become a best practice someday.

Bud

From bud at thecommunityengine.com  Fri Jul 15 15:52:46 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul 15 15:52:42 2005
Subject: [microformats-discuss] Profiles, what are they good for,
	why do we need them, and how should they be implemented
In-Reply-To: <42D7D17A.4060806@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>	<e8ca2e110507150430111baed3@mail.gmail.com>	<42D7A543.2030001@gmail.com>	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>	<e6ec604d0507150624c964500@mail.gmail.com>	<e8ca2e1105071507169bbb62c@mail.gmail.com>	<42D7C82B.8070308@rbach.priv.at>
	<e8ca2e11050715073325ed6f54@mail.gmail.com>
	<42D7D17A.4060806@gmail.com>
Message-ID: <32E2F3B3-B8E1-49D2-839A-E01F4E45FFF7@thecommunityengine.com>

On Jul 15, 2005, at 11:08, brian suda wrote:


> This is why a generic universal validator would be handy, but XMDP is
> meant for human-readbility first, and machine-readablity second. So
> somethings people are trying to make microformats do are just out  
> of the
> scope of possiblities, lets not forget this.
>
>

Probably, but it begs the question of what you think are in and out  
of scope of possibilities.  I think, given your extensive experience  
and leadership, that that would be useful information.

I would think the XMDP might be a starting place for coming up with  
validation rules as you have done.  It's more a terse kind of author/ 
developer documentation than a tool for validation.  Developers could  
create rules for validation (a la schematron) from them.

Let me point out that I think one problem we are having here is  
considering the very general case.  A lot of the issue in recognizing  
microformats comes from having multiple microformats on a page with  
all the potential for collisions.

Let's consider that this might not always be the case, and in fact  
will likely not be the case.  If a page contained only one kind of  
microformatted content (say xFolk or hCard), then the recognition and  
parsing issue starts to become a lot easier.

just some thoughts,
Bud

From rbach at rbach.priv.at  Fri Jul 15 16:03:25 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Jul 15 16:02:46 2005
Subject: [microformats-discuss] Invalid XHTML
In-Reply-To: <08422D28-7EEB-4047-B6D5-B1846231BAC0@technorati.com>
References: <42D82481.9000201@rbach.priv.at>
	<08422D28-7EEB-4047-B6D5-B1846231BAC0@technorati.com>
Message-ID: <42D840BD.4060506@rbach.priv.at>

Ryan King wrote:
> On Jul 15, 2005, at 2:02 PM, Robert Bachmann wrote:
>> [...]
>  [...]
>> I've also discovered a small bug in the Wiki, see
>> http://bugzilla.wikipedia.org/long_list.cgi?buglist=2870
> 
> I've applied the patch for this bug. 
Thanks Ryan, seems to work.


Some more notes on the wiki:

1. The wiki allows you to write <code><pre>, this isn't valid XHTML
because <code> is an inline element and <pre> is a block element.
Using <pre><code>...</code></pre> would be valid XHTML but the wiki gets
it wrong by including &lt;code&gt; in the output.
Therefor <pre><nowiki>...</nowiki></pre> seems to me as the only
possible way.

2. http://microformats.org/wiki/comments-formats seems to be invalid,
first error:
 comments-formats:38: parser error : Opening and ending tag mismatch: td
 line 32 and div
 </div>

I've removed the TOC with __NOTOC__, and the output was valid
afterwards, therefor this seems to be a bug in Mediawiki.
(anybody may restore the TOC by removing the first line with __NOTOC__
in it, I've just done it for testing purposes)

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Fri Jul 15 17:20:27 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 17:20:29 2005
Subject: [microformats-discuss] Profiles, what are they good for,
	why do we need them, and how should they be implemented
In-Reply-To: <17C91EE2-2D69-4783-B9F2-CE8936D7AD3F@thecommunityengine.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<42D7A543.2030001@gmail.com>
	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>
	<e6ec604d0507150624c964500@mail.gmail.com>
	<e8ca2e1105071507169bbb62c@mail.gmail.com>
	<42D7C82B.8070308@rbach.priv.at>
	<e8ca2e11050715073325ed6f54@mail.gmail.com>
	<42D7D17A.4060806@gmail.com>
	<e8ca2e1105071508377ffe2cd1@mail.gmail.com>
	<17C91EE2-2D69-4783-B9F2-CE8936D7AD3F@thecommunityengine.com>
Message-ID: <4E23B14D-920A-4677-BF10-2CB0BF91E39F@technorati.com>

On Jul 15, 2005, at 3:52 PM, Bud Gibson wrote:
> On Jul 15, 2005, at 11:37, Carl Beeth wrote:
>
>> And that is today, in a couple of weeks there might be more. That
>> makes for a lot of URL's in the header. Remember people are pragmatic
>> even though they won't use all these formats on the same page they
>> will put it all in the template just in case they they need it. Also
>> you are putting a very large hurdle on adoption if the user has to
>> muck around in his templates each time he want's to ad a new kind of
>> microformated content to his site.
>
> Carl:
>
> I find this point to very well taken, and it comes back to Danny  
> Ayers' idea of using URIs to ID when the microformat is being  
> used.  If the URI were simply the URL to the XMDP, we would kill  
> two birds with one stone.

I'm not sure what's been miss communicated here, but....

Yes. Exactly. That's precisely the idea behind xmdp. See xmdp http:// 
www.gmpg.org/xmdp/description#using

Danny has a good idea, but its not original. This is *precisely* the  
idea behind xmdp. And, this is precisiely the idea behind <head  
profile="...">.

> In another communication, Ryan King indicated that XFN actually  
> uses the URI as the class attribute value that encloses an XFN entry.

No. No URIs in class values with XFN. Since there is a profile URL  
for xfn, it should be referenced in the <head profile="">.

-ryan

>   Somebody with foresight of the problem you are describing made  
> that decision.
>
> One mechanism available now is to simply place a link to the XMDP  
> in the microformatted text as described here:
>
> http://microformats.org/wiki/xmdp-brainstorming
>
> (the page is a little messy, but you should find it).  Short of  
> adopting Ayers' suggestion, this solution at least allows you to  
> just plop in links to the XMDP without having access to the head.
>
> As I think about it, I like Ayers' suggestion more and more.  Maybe  
> that will become a best practice someday.
>
> Bud
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From brian.suda at gmail.com  Fri Jul 15 17:27:00 2005
From: brian.suda at gmail.com (brian suda)
Date: Fri Jul 15 17:27:33 2005
Subject: [microformats-discuss] Profiles, what are they good for, why
	do we need them, and how should they be implemented
In-Reply-To: <32E2F3B3-B8E1-49D2-839A-E01F4E45FFF7@thecommunityengine.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>	<e8ca2e110507150430111baed3@mail.gmail.com>	<42D7A543.2030001@gmail.com>	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>	<e6ec604d0507150624c964500@mail.gmail.com>	<e8ca2e1105071507169bbb62c@mail.gmail.com>	<42D7C82B.8070308@rbach.priv.at>	<e8ca2e11050715073325ed6f54@mail.gmail.com>	<42D7D17A.4060806@gmail.com>
	<32E2F3B3-B8E1-49D2-839A-E01F4E45FFF7@thecommunityengine.com>
Message-ID: <42D85454.4020409@gmail.com>

Bud Gibson wrote:

> On Jul 15, 2005, at 11:08, brian suda wrote:
>
>> This is why a generic universal validator would be handy, but XMDP is
>> meant for human-readbility first, and machine-readablity second. So
>> somethings people are trying to make microformats do are just out  of
>> the
>> scope of possiblities, lets not forget this.
>
>
> Probably, but it begs the question of what you think are in and out 
> of scope of possibilities.  I think, given your extensive experience 
> and leadership, that that would be useful information.

With the current set of tools, there are just certain things that cannot
be achieved. This does not mean they are impossible, just not feasible
with the current implementations. For example:

XFN is a very simple microformat. There is no nesting of properties like
hCa* ('work' is a sub-property of 'tel', which is a sub-property of
'vcard') and there are few places the resulting data can be stored (with
hCa* things can be in the 'title' attribute in the case of abbr, or the
'href' or 'src' or 'node value'). XFN is on rel="" attributes only and
their value is the corresponding href="". So it looks very simple. If we
dig deeper into the english prose that accompanies each property we find
addtional text like: Often symmetric. Symmetric. Not transitive, No
inverse, etc. These 'constraints' are not represented in any machine
readble form. Partly because there is no way to enforce XFN between two
sites. (If you add my site as a rel='met' i have no requirement to link
back with a rel='met' even though that property is transitive.) and
because it was never addressed or part of the original intent. (i never
worked on XFN or XMDP, so someone else might clarify that last
statement, but i know i have talked with Tantek if it would in any way
possible to add it)

Other things that XMDP cannot do that XML schema can do is custom data
types, or even simple data types.  Right now in hCa* all dates should be
a UTC date format. This is explained only in the english prose reference
to the actual RFC. XMDP provides no way to enforce a YYYY-MM-DD style
string or a $___.00 money string, or int, float, string, double, etc.
All of which, other schema languages can. This doesn't make XMDP bad and
worthless, they are just out of the scope.

Ontologies are another item that is not available in a machine readable
format. To say that this hCard class='url' is the same as a hCal
class="url", or that FOOBAR realestate class="title" is NOT the same as
Dublin Core class="title". This is easily handled in the prose, but not
in the XHTML.

> I would think the XMDP might be a starting place for coming up with 
> validation rules as you have done.  It's more a terse kind of author/
> developer documentation than a tool for validation.  Developers could 
> create rules for validation (a la schematron) from them.

i'm not sure what you mean here?

> Let me point out that I think one problem we are having here is 
> considering the very general case.  A lot of the issue in recognizing 
> microformats comes from having multiple microformats on a page with 
> all the potential for collisions.

very true. I just point them out to keep people aware of potential
problems (not because i have any answers). Most of the feedback and
questions i have fielded about microformats have been more about how to
even get started... no one has had problems with TOO MANY encodings.

> Let's consider that this might not always be the case, and in fact 
> will likely not be the case.  If a page contained only one kind of 
> microformatted content (say xFolk or hCard), then the recognition and 
> parsing issue starts to become a lot easier.

This is certainly true, but i personally would prefer to build a more
general case parser validator especially if this will more of a
bottom-up style design where anyone can be creating XMDPs and
Microformats without a consenses or committee.

Are there any thoughts about this? i have thought long and hard about
how any and all of the above could be built with simple XHTML
technologies and avoiding too much complexity, without much luck.

-brian
From ryan at technorati.com  Fri Jul 15 17:43:58 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 15 17:44:02 2005
Subject: [microformats-discuss] profiles- resolved
Message-ID: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>

Our discussion around profiles is going in circles.

Let me end the thread here (and give Tantek a chance to catch up on  
the discussion :)). Please give xmdp and profiles a break until  
Tantek is caught up- we have plenty of other things to discuss  
(resumes, anyone? geo, anyone? blog comments, anyone?)

Here's a summary of xmdp, profile stuff, which I hope should clear up  
misconceptions:

1. Microformats should be a profile URI. Not all of them do yet (this  
is due to the 24-hours-in-a-day problem- http://james.lab6.com/ 
2003/09/16/24hours/).

2. The profile URI could be a URL that resolves to an XMDP.

3. Profiles should probably be reference-able outside of the <head  
profile="...">

<link rel="profile" .../> was proposed by Tantek and Eric Meyer at  
WWW2005 (or was it 2004?).

Likewise, <a rel="profile" ...></a> has been proposed and accepted as  
a suggestion.

Please see http://microformats.org/wiki/xmdp-brainstorming

4. Please read the info on xmdp at gmpg.org (http://gmpg.org/xmdp)  
and ask questions if there's anything you don't understand. I'll let  
Tantek explain more.

Again, this discussion has become non-productive- the signal-to-noise  
ratio has gone way down. Let's just take a break.

-ryan

From bud at thecommunityengine.com  Sat Jul 16 05:42:17 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sat Jul 16 05:42:16 2005
Subject: [microformats-discuss] Profiles, what are they good for,
	why do we need them, and how should they be implemented
In-Reply-To: <42D85454.4020409@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>	<e8ca2e110507150430111baed3@mail.gmail.com>	<42D7A543.2030001@gmail.com>	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>	<e6ec604d0507150624c964500@mail.gmail.com>	<e8ca2e1105071507169bbb62c@mail.gmail.com>	<42D7C82B.8070308@rbach.priv.at>	<e8ca2e11050715073325ed6f54@mail.gmail.com>	<42D7D17A.4060806@gmail.com>
	<32E2F3B3-B8E1-49D2-839A-E01F4E45FFF7@thecommunityengine.com>
	<42D85454.4020409@gmail.com>
Message-ID: <7EB2D480-BEED-403A-883F-B979D5BAD20E@thecommunityengine.com>

Thanks, Brian

I think this nicely summarizes in one place the limitations of XMDPs  
for machine validation.  And, as you observe, they were never  
intended that way.  Maybe the list maintainers will use this email in  
some sort of FAQ.

I have sometimes speculated that one could read the prose in the XMDP  
and translate that into some set of rules that could at least  
validate that one had all of the elements, properly nested etc.  That  
kind of idea may be useful for people who want to use microformats as  
data.  For those just attempting to make an incremental improvement  
to markup, it may seem a kind of anathema because it imposes a kind  
of all or nothing burden on web page authors.

Bud

On Jul 15, 2005, at 20:27, brian suda wrote:


> Bud Gibson wrote:
>
>
>
>> On Jul 15, 2005, at 11:08, brian suda wrote:
>>
>>
>>
>>> This is why a generic universal validator would be handy, but  
>>> XMDP is
>>> meant for human-readbility first, and machine-readablity second. So
>>> somethings people are trying to make microformats do are just  
>>> out  of
>>> the
>>> scope of possiblities, lets not forget this.
>>>
>>>
>>
>>
>> Probably, but it begs the question of what you think are in and out
>> of scope of possibilities.  I think, given your extensive experience
>> and leadership, that that would be useful information.
>>
>>
>
> With the current set of tools, there are just certain things that  
> cannot
> be achieved. This does not mean they are impossible, just not feasible
> with the current implementations. For example:
>
> XFN is a very simple microformat. There is no nesting of properties  
> like
> hCa* ('work' is a sub-property of 'tel', which is a sub-property of
> 'vcard') and there are few places the resulting data can be stored  
> (with
> hCa* things can be in the 'title' attribute in the case of abbr, or  
> the
> 'href' or 'src' or 'node value'). XFN is on rel="" attributes only and
> their value is the corresponding href="". So it looks very simple.  
> If we
> dig deeper into the english prose that accompanies each property we  
> find
> addtional text like: Often symmetric. Symmetric. Not transitive, No
> inverse, etc. These 'constraints' are not represented in any machine
> readble form. Partly because there is no way to enforce XFN between  
> two
> sites. (If you add my site as a rel='met' i have no requirement to  
> link
> back with a rel='met' even though that property is transitive.) and
> because it was never addressed or part of the original intent. (i  
> never
> worked on XFN or XMDP, so someone else might clarify that last
> statement, but i know i have talked with Tantek if it would in any way
> possible to add it)
>
> Other things that XMDP cannot do that XML schema can do is custom data
> types, or even simple data types.  Right now in hCa* all dates  
> should be
> a UTC date format. This is explained only in the english prose  
> reference
> to the actual RFC. XMDP provides no way to enforce a YYYY-MM-DD style
> string or a $___.00 money string, or int, float, string, double, etc.
> All of which, other schema languages can. This doesn't make XMDP  
> bad and
> worthless, they are just out of the scope.
>
> Ontologies are another item that is not available in a machine  
> readable
> format. To say that this hCard class='url' is the same as a hCal
> class="url", or that FOOBAR realestate class="title" is NOT the  
> same as
> Dublin Core class="title". This is easily handled in the prose, but  
> not
> in the XHTML.
>
>
>
>> I would think the XMDP might be a starting place for coming up with
>> validation rules as you have done.  It's more a terse kind of author/
>> developer documentation than a tool for validation.  Developers could
>> create rules for validation (a la schematron) from them.
>>
>>
>
> i'm not sure what you mean here?
>
>
>
>> Let me point out that I think one problem we are having here is
>> considering the very general case.  A lot of the issue in recognizing
>> microformats comes from having multiple microformats on a page with
>> all the potential for collisions.
>>
>>
>
> very true. I just point them out to keep people aware of potential
> problems (not because i have any answers). Most of the feedback and
> questions i have fielded about microformats have been more about  
> how to
> even get started... no one has had problems with TOO MANY encodings.
>
>
>
>> Let's consider that this might not always be the case, and in fact
>> will likely not be the case.  If a page contained only one kind of
>> microformatted content (say xFolk or hCard), then the recognition and
>> parsing issue starts to become a lot easier.
>>
>>
>
> This is certainly true, but i personally would prefer to build a more
> general case parser validator especially if this will more of a
> bottom-up style design where anyone can be creating XMDPs and
> Microformats without a consenses or committee.
>
> Are there any thoughts about this? i have thought long and hard about
> how any and all of the above could be built with simple XHTML
> technologies and avoiding too much complexity, without much luck.
>
> -brian
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>


From rbach at rbach.priv.at  Sat Jul 16 06:21:57 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sat Jul 16 06:21:18 2005
Subject: [microformats-discuss] Profiles, what are they good for, why
	do we need them, and how should they be implemented
In-Reply-To: <42D85454.4020409@gmail.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>	<e8ca2e110507150430111baed3@mail.gmail.com>	<42D7A543.2030001@gmail.com>	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>	<e6ec604d0507150624c964500@mail.gmail.com>	<e8ca2e1105071507169bbb62c@mail.gmail.com>	<42D7C82B.8070308@rbach.priv.at>	<e8ca2e11050715073325ed6f54@mail.gmail.com>	<42D7D17A.4060806@gmail.com>	<32E2F3B3-B8E1-49D2-839A-E01F4E45FFF7@thecommunityengine.com>
	<42D85454.4020409@gmail.com>
Message-ID: <42D909F5.1030307@rbach.priv.at>

brian suda wrote:
> Other things that XMDP cannot do that XML schema can do is custom data
> types, or even simple data types.  Right now in hCa* all dates should be
> a UTC date format. This is explained only in the english prose reference
> to the actual RFC. XMDP provides no way to enforce a YYYY-MM-DD style
> string or a $___.00 money string, or int, float, string, double, etc.
> All of which, other schema languages can. This doesn't make XMDP bad and
> worthless, they are just out of the scope.

I suddenly got an idea but unfortunately I don't know much about XML
schema and XMDP, so this idea is perhaps a a bad one.
I'll present it anyway so others with more knowledge about XMDP and XML
Schema can judge it:

Would it be possible to link a XMDP with a XML schema?

Here is an example for illustration of my idea:

For example if I would want to use hCalender on a page, I would
use the URL http://example.org/Microformats/hCalender.xhtml (or whatever).

http://example.org/Microformats/hCalender.xhtml contains the profile
and some kind of link to an XML schema:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>XMDP profile for hCalender</title>
</head>
<body>
 <dl class="profile">
    <!-- .... -->
 </dl>
 <a rel="XMLschema"
    href="http://example.org/Microformats/hCalender.xsd">XML
    Schema</a>
</body>
</html>

A (generic) validator which is used to validate my page could then read
the link(s) to the XMDP(s), fetch them and afterwards could also fetch
the XML Schema(s) and validate the specific parts of my page against
the various XML Schemas.

Is that possible and does that actually make sense?

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From bud at thecommunityengine.com  Sat Jul 16 12:03:12 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sat Jul 16 12:03:09 2005
Subject: [microformats-discuss] Profiles, what are they good for,
	why do we need them, and how should they be implemented
In-Reply-To: <42D909F5.1030307@rbach.priv.at>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>	<e8ca2e1105071503553dc241f3@mail.gmail.com>	<42D79AA2.2060603@gmail.com>	<e8ca2e110507150430111baed3@mail.gmail.com>	<42D7A543.2030001@gmail.com>	<06293749-43D5-4180-AA6B-904CBF2FD201@bokardo.com>	<e6ec604d0507150624c964500@mail.gmail.com>	<e8ca2e1105071507169bbb62c@mail.gmail.com>	<42D7C82B.8070308@rbach.priv.at>	<e8ca2e11050715073325ed6f54@mail.gmail.com>	<42D7D17A.4060806@gmail.com>	<32E2F3B3-B8E1-49D2-839A-E01F4E45FFF7@thecommunityengine.com>
	<42D85454.4020409@gmail.com> <42D909F5.1030307@rbach.priv.at>
Message-ID: <97D4D479-2253-499C-9981-96F72EB1C143@thecommunityengine.com>

I'll generically throw in just the following:

1.  The XMDP really works for human reading and some very limited  
machine discovery of microformatted content as demonstrated by Brian  
Suda.

2. There is no reason that you could not link in the XMDP to some  
sort of machine validation scheme if you so chose.

3.  If you want to use things like schema to validate xhtml documents  
with something extra, you need to look at this document:

http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/

As you will see looking at that page, adding components described by  
a schema to xhtml leads to a "hybrid" document that must be validated  
against a hybrid schema, not just the plain old xhtml schema.  Hybrid  
documents introduce the notion of namespaces to avoid naming  
conflicts which in turn makes writing the document a lot harder.

A key component of the microformat philosophy is to avoid making  
authors validate against hybrid document types with namespaces.  The  
idea is to use just xhtml and have the document validate against the  
standard xhtml schema with no namespaces, thereby retaining a  
business-as-usual workflow for authors.

4.  Most people on this list are not looking to actually validate  
microformats, rather they seem to want the following:

a.  To know when a microformat is being used, or not.

b.  To know that, if a microformat is being used, that it has all the  
right components.

My cut is that both of these issues might be very easy to resolve.   
Resolving point "a" may be as simple as introducing URLs (URIs that  
point at real resources) to indicate the containing element of a  
microformat.  This usage will likely be more heuristic than specified  
in current W3C documents.

Resolving point "b" may simply involve writing better specs and  
providing test cases, something that is not always done.

Bud

On Jul 16, 2005, at 9:21, Robert Bachmann wrote:


> brian suda wrote:
>
>
>> Other things that XMDP cannot do that XML schema can do is custom  
>> data
>> types, or even simple data types.  Right now in hCa* all dates  
>> should be
>> a UTC date format. This is explained only in the english prose  
>> reference
>> to the actual RFC. XMDP provides no way to enforce a YYYY-MM-DD style
>> string or a $___.00 money string, or int, float, string, double, etc.
>> All of which, other schema languages can. This doesn't make XMDP  
>> bad and
>> worthless, they are just out of the scope.
>>
>>
>
> I suddenly got an idea but unfortunately I don't know much about XML
> schema and XMDP, so this idea is perhaps a a bad one.
> I'll present it anyway so others with more knowledge about XMDP and  
> XML
> Schema can judge it:
>
> Would it be possible to link a XMDP with a XML schema?
>
> Here is an example for illustration of my idea:
>
> For example if I would want to use hCalender on a page, I would
> use the URL http://example.org/Microformats/hCalender.xhtml (or  
> whatever).
>
> http://example.org/Microformats/hCalender.xhtml contains the profile
> and some kind of link to an XML schema:
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
> <head>
> <title>XMDP profile for hCalender</title>
> </head>
> <body>
>  <dl class="profile">
>     <!-- .... -->
>  </dl>
>  <a rel="XMLschema"
>     href="http://example.org/Microformats/hCalender.xsd">XML
>     Schema</a>
> </body>
> </html>
>
> A (generic) validator which is used to validate my page could then  
> read
> the link(s) to the XMDP(s), fetch them and afterwards could also fetch
> the XML Schema(s) and validate the specific parts of my page against
> the various XML Schemas.
>
> Is that possible and does that actually make sense?
>
> Robert
> -- 
> Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>


From brian.suda at gmail.com  Sat Jul 16 13:32:32 2005
From: brian.suda at gmail.com (brian suda)
Date: Sat Jul 16 13:33:01 2005
Subject: [microformats-discuss] Referencing hCards
In-Reply-To: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>
References: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>
Message-ID: <42D96EE0.50007@gmail.com>

One idea for referencing remote hCards was to use the rel="hcard" attribute.

With the X2V program and the id='' attribute it is possible to reference
a single hCard within an HTML page with many hCards.

<div class="vcard" id="brian_suda">
...
</div>

by passing http://example.com/hcard.html#brian_suda to X2V i would get a
single vCard result instead of all the vCards that would be encoded into
that page.

This could also lead to the following link on
http://another.site.example.com/:

<a href="http://example.com/hcard.html#brian_suda" rel="me hcard">my
hCard</a>

This gives a link to an HTML page, but it is an anchor directly to the
hCard. The idea being, that X2V could then also search for any
rel="hcard" attributes and spider those links as well. Then you could
build a disconnected network of hCard nodes.

One vCard attribute rarely used is AGENT. This is a person that acts on
the other person's behalf.

<div class="vcard" id="brian_suda">
<a href='http://agents.site.example.com/#agent1' class="agent"
rel="hcard">contact my agent</a>
</div>

Now X2V could travers that link to get the rest of the agent hcard. This
allows the agent to keep their information up-to-date on their site
without me constantly making changes to my own site. Instead i reference
their hcard via an href anchor link.

Another example would be a single HTML page with links to all my
friends' hcard pages. If i add the rel="hcard" attribute to each link,
then point X2V to my own page. X2V would spider all of the external
links and fetch the hcards building a vcard for each one. Then i no
longer need to keep friends data current. It is a distributed
addressbook via REST, microformats, and HTML.

Does this make sense? Any thoughts?
-brian
From ryan at technorati.com  Sat Jul 16 15:27:28 2005
From: ryan at technorati.com (Ryan King)
Date: Sat Jul 16 15:27:32 2005
Subject: [microformats-discuss] Referencing hCards
In-Reply-To: <42D96EE0.50007@gmail.com>
References: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>
	<42D96EE0.50007@gmail.com>
Message-ID: <A9F053C9-965B-4EED-8583-EDCFCA545337@technorati.com>

On Jul 16, 2005, at 1:32 PM, brian suda wrote:

> One idea for referencing remote hCards was to use the rel="hcard"  
> attribute.

There's a couple of difficulties with this.

First of all, rel="" defines the relationship between the two  
resources, not the format of the target.

Second, page A can't assert anything about the format of page B in  
any reliable manner.

Third, for you use-case, below, I don't think its necessary. I think  
we already have the building blocks we need.

> With the X2V program and the id='' attribute it is possible to  
> reference
> a single hCard within an HTML page with many hCards.
>
> <div class="vcard" id="brian_suda">
> ...
> </div>
>
> by passing http://example.com/hcard.html#brian_suda to X2V i would  
> get a
> single vCard result instead of all the vCards that would be encoded  
> into
> that page.

This definitely sounds like an interesting idea for X2V to support.

> This could also lead to the following link on
> http://another.site.example.com/:
>
> <a href="http://example.com/hcard.html#brian_suda" rel="me hcard">my
> hCard</a>
>
> This gives a link to an HTML page, but it is an anchor directly to the
> hCard. The idea being, that X2V could then also search for any
> rel="hcard" attributes and spider those links as well. Then you could
> build a disconnected network of hCard nodes.

If we're building a network, why not just use XFN?

> One vCard attribute rarely used is AGENT. This is a person that  
> acts on
> the other person's behalf.
>
> <div class="vcard" id="brian_suda">
> <a href='http://agents.site.example.com/#agent1' class="agent"
> rel="hcard">contact my agent</a>
> </div>

/me goes to get himself an agent, just so he can use this feature

> Now X2V could travers that link to get the rest of the agent hcard.  
> This
> allows the agent to keep their information up-to-date on their site
> without me constantly making changes to my own site. Instead i  
> reference
> their hcard via an href anchor link.
>
> Another example would be a single HTML page with links to all my
> friends' hcard pages. If i add the rel="hcard" attribute to each link,
> then point X2V to my own page. X2V would spider all of the external
> links and fetch the hcards building a vcard for each one. Then i no
> longer need to keep friends data current. It is a distributed
> addressbook via REST, microformats, and HTML.

> Does this make sense? Any thoughts?

Yes, it makes sense, but I don't think the rel="hcard" is necessary  
in any of it. First of all, its unreliable (which was the point I was  
trying to make above) and secondly, a spider could just hit all of  
your friends links to find hcards.

-ryan

From brian.suda at gmail.com  Sat Jul 16 15:47:36 2005
From: brian.suda at gmail.com (brian suda)
Date: Sat Jul 16 15:48:06 2005
Subject: [microformats-discuss] Referencing hCards
In-Reply-To: <A9F053C9-965B-4EED-8583-EDCFCA545337@technorati.com>
References: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>	<42D96EE0.50007@gmail.com>
	<A9F053C9-965B-4EED-8583-EDCFCA545337@technorati.com>
Message-ID: <42D98E88.3080700@gmail.com>

Ryan King wrote:

> On Jul 16, 2005, at 1:32 PM, brian suda wrote:
>
>> One idea for referencing remote hCards was to use the rel="hcard" 
>> attribute.
>
> There's a couple of difficulties with this.
>
> First of all, rel="" defines the relationship between the two 
> resources, not the format of the target.

You are absolutely right. There is the HTML 'type' attribute for
content-type of the resulting link, but like 'hreflang' there is no way
to control someone else's content. So i guess i ment:
<a href="../hcard.html" type="text/hCard">Another hCard</a>

> Second, page A can't assert anything about the format of page B in 
> any reliable manner.

This is absolutely true.

>> With the X2V program and the id='' attribute it is possible to 
>> reference
>> a single hCard within an HTML page with many hCards.
>>
>> <div class="vcard" id="brian_suda">
>> ...
>> </div>
>>
>> by passing http://example.com/hcard.html#brian_suda to X2V i would 
>> get a
>> single vCard result instead of all the vCards that would be encoded 
>> into
>> that page.
>
>
> This definitely sounds like an interesting idea for X2V to support.

It should be built-in already for both extracting a single VEVENT and a
single VCARD

>> This could also lead to the following link on
>> http://another.site.example.com/:
>>
>> <a href="http://example.com/hcard.html#brian_suda" rel="me hcard">my
>> hCard</a>
>>
>> This gives a link to an HTML page, but it is an anchor directly to the
>> hCard. The idea being, that X2V could then also search for any
>> rel="hcard" attributes and spider those links as well. Then you could
>> build a disconnected network of hCard nodes.
>
>
> If we're building a network, why not just use XFN?

XFN just shows relationships between two people ('websites'), but the
hCard would also build a distributed address book.

> Yes, it makes sense, but I don't think the rel="hcard" is necessary 
> in any of it. First of all, its unreliable (which was the point I was 
> trying to make above) and secondly, a spider could just hit all of 
> your friends links to find hcards.

The unreliablity is certainly a factor. I would perfer NOT to spider all
links, otherwise i might be traversing the internet. It could be limited
to a depth of 1, but that is still un-needed work or bandwidth.

-brian
From andyhume at thedredge.org  Sat Jul 16 16:18:05 2005
From: andyhume at thedredge.org (Andy Hume)
Date: Sat Jul 16 16:18:15 2005
Subject: [microformats-discuss] Referencing hCards
In-Reply-To: <42D96EE0.50007@gmail.com>
References: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>
	<42D96EE0.50007@gmail.com>
Message-ID: <9DBC2454-B125-4CD5-A01B-F15C8826A5BD@thedredge.org>

> Does this make sense? Any thoughts?
>

Yeah, it sounds very interesting.

The issue of multiple hcards on a page is an interesting one. It is  
obviously important that machines and humans can distinguish how the  
hcard's relate to the page they are on. Do they belong to the page  
author, an agent or just someone who has commented on a page?

For example, if you are marking author contact details as <address  
class="vcard"> then it is important that X2V and other format parses  
can distinguish that as the page authors hcard as separate from other  
hcards on the page.

Of course this could just as easily be done with <div class="vcard"  
id"author_hcard">, but the address element is more logical in this  
case. Can X2V make that kind of distinction from the element type of  
the hcard container?

Andy.

_______________________________________________

> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>
>



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
From ryan at technorati.com  Sat Jul 16 18:32:39 2005
From: ryan at technorati.com (Ryan King)
Date: Sat Jul 16 18:32:43 2005
Subject: [microformats-discuss] Referencing hCards
In-Reply-To: <42D98E88.3080700@gmail.com>
References: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>	<42D96EE0.50007@gmail.com>
	<A9F053C9-965B-4EED-8583-EDCFCA545337@technorati.com>
	<42D98E88.3080700@gmail.com>
Message-ID: <8854CC6C-3607-4CB4-B990-0AC8D7C0BC25@technorati.com>

On Jul 16, 2005, at 3:47 PM, brian suda wrote:
> Ryan King wrote:
>> On Jul 16, 2005, at 1:32 PM, brian suda wrote:
>>> One idea for referencing remote hCards was to use the rel="hcard"
>>> attribute.
>>
>> There's a couple of difficulties with this.
>>
>> First of all, rel="" defines the relationship between the two
>> resources, not the format of the target.
>
> You are absolutely right. There is the HTML 'type' attribute for
> content-type of the resulting link, but like 'hreflang' there is no  
> way
> to control someone else's content. So i guess i ment:
> <a href="../hcard.html" type="text/hCard">Another hCard</a>
>
>
>> Second, page A can't assert anything about the format of page B in
>> any reliable manner.
>
> This is absolutely true.

So don't even try. Even your above example of using the type  
attribute falls into the same trap.

> ...
>
>>> This could also lead to the following link on
>>> http://another.site.example.com/:
>>>
>>> <a href="http://example.com/hcard.html#brian_suda" rel="me hcard">my
>>> hCard</a>
>>>
>>> This gives a link to an HTML page, but it is an anchor directly  
>>> to the
>>> hCard. The idea being, that X2V could then also search for any
>>> rel="hcard" attributes and spider those links as well. Then you  
>>> could
>>> build a disconnected network of hCard nodes.
>>
>>
>> If we're building a network, why not just use XFN?
>
> XFN just shows relationships between two people ('websites'), but the
> hCard would also build a distributed address book.
>
>> Yes, it makes sense, but I don't think the rel="hcard" is necessary
>> in any of it. First of all, its unreliable (which was the point I was
>> trying to make above) and secondly, a spider could just hit all of
>> your friends links to find hcards.
>
> The unreliablity is certainly a factor. I would perfer NOT to  
> spider all
> links,

Right. So, just spider XFN'ed links. So:

1. I link to you.
2. You have an hCard on your homepage OR
3. link to your hCard with rel="me"

voila! distributed addressbook with XFN + hCard.

> otherwise i might be traversing the internet. It could be limited
> to a depth of 1, but that is still un-needed work or bandwidth.

-ryan
From mike at stamen.com  Sat Jul 16 18:47:13 2005
From: mike at stamen.com (Michal Migurski)
Date: Sat Jul 16 18:47:19 2005
Subject: [microformats-discuss] Advertisement microformat
Message-ID: <50A9C7B9-39BF-44AC-82B3-C50C2DB37511@stamen.com>

Since we're on the topic of microformats... :)

This photo:
     http://www.flickr.com/photos/adammathes/26270412/

...made me think that an advertisement microformat would be  
interesting. I expect that companies that inject ads into their RSS  
feeds wouldn't like this at all. However, Google counter-intuitively  
showed that text-only ads could be a huge moneymaker. Perhaps ads  
that identify themselves as such might also have some advantage over  
those that don't?

My personal motivation for musing about an advertisement microformat  
is that it would allow me (as a maintainer of RSS reader software) to  
help keep the content in feeds readable, and to apply a style to the  
ads that is less intrusive than the red beasties on Adam's screenshot.

-mike.

----------------------------------------------------------------
michal migurski- mike@stamen.com
                  415.558.1610


From ryan at technorati.com  Sat Jul 16 21:18:10 2005
From: ryan at technorati.com (Ryan King)
Date: Sat Jul 16 21:18:13 2005
Subject: [microformats-discuss] Advertisement microformat
In-Reply-To: <50A9C7B9-39BF-44AC-82B3-C50C2DB37511@stamen.com>
References: <50A9C7B9-39BF-44AC-82B3-C50C2DB37511@stamen.com>
Message-ID: <3C9977E2-9584-4C36-A4D9-859D63EDF180@technorati.com>


On Jul 16, 2005, at 6:47 PM, Michal Migurski wrote:

> Since we're on the topic of microformats... :)

Since we're on the topic of microformats photos on flickr...

Check out this one:

http://flickr.com/photos/termie/26121308/

And this for an explanation:

http://www.microformats.org/blog/2005/07/15/flickr-and-microformats/

-ryan
From brian.suda at gmail.com  Sun Jul 17 01:04:40 2005
From: brian.suda at gmail.com (Brian Suda)
Date: Sun Jul 17 01:04:42 2005
Subject: [microformats-discuss] Referencing hCards
In-Reply-To: <8854CC6C-3607-4CB4-B990-0AC8D7C0BC25@technorati.com>
References: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>
	<42D96EE0.50007@gmail.com>
	<A9F053C9-965B-4EED-8583-EDCFCA545337@technorati.com>
	<42D98E88.3080700@gmail.com>
	<8854CC6C-3607-4CB4-B990-0AC8D7C0BC25@technorati.com>
Message-ID: <21e770780507170104389953aa@mail.gmail.com>

> Right. So, just spider XFN'ed links. So:
> 
> 1. I link to you.
> 2. You have an hCard on your homepage OR
> 3. link to your hCard with rel="me"
> 
> voila! distributed addressbook with XFN + hCard.

XFN is a seperate microformat than hCard, so there is no implcation
that XFN means hCard. Spidering those links needlessly would generate
more bandwidth, processor time, and execution time. I was looking for
a way to say without a doubt, that on the other end of the link is an
hCard. Since there is no way to do this with certainty this idea is
moot. It was just a thought.

-brian
From rbach at rbach.priv.at  Sun Jul 17 06:31:29 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 17 06:31:03 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
References: <9A6EC9CB-7F25-4779-9158-B646DB06D10D@technorati.com>
Message-ID: <42DA5DB1.1090405@rbach.priv.at>

Ryan King wrote:
> We've had a lot of people join the list recently and most people 
> probably don't know who else is subscribed to the list (there's 51 
> total). So, some personal introductions are in order...

Maybe I should also introduce my self.

My name is Robert Bachmann, I'm twenty years old and I live in Austria.
I recently finished school (*):
HTL Moedling, Department of Electronics with key course element on
computer engineering.

Since some years (4?) I'm playing with (X)HTML and XHTML, then
I've learned about microformats by accident and now I'm here. ;-)
I have a good knowledge of C, VB, PHP and (X)HTML and
also a (little) working knowledge of C++, XML, XSLT and Python.

Robert

(*)
I've found a short description in English on
http://www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=16878

"HTL Moedling is the largest technical high school in Europe with more
than 3,200 students, 400 teachers, and 100 contract employees." [1]
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From rbach at rbach.priv.at  Sun Jul 17 06:43:48 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 17 06:43:04 2005
Subject: [microformats-discuss] hCalendar - Proposal for "YYYY-MM-DD"
Message-ID: <42DA6094.8090207@rbach.priv.at>

The current date format for machine-readable dates
is YYYYMMDD.

Example:

<span class="vevent">
 <a class="url" href="http://www.web2con.com/">
  <span class="summary">Web 2.0 Conference</span>:
  <abbr class="dtstart" title="20051005">October 5</abbr>-
  <abbr class="dtend" title="20051007">7</abbr>,
 at the <span class="location">Argent Hotel, San Francisco, CA</span>
 </a>
</span>

hCalendar should also allow the YYYY-MM-DD format.
Even better hCalendar should recommend the YYYY-MM-DD format over
the YYYYMMDD format, i.e. authors and iCal-to-hCalendar converters
SHOULD produce YYYY-MM-DD.

Example:

<span class="vevent">
 <a class="url" href="http://www.web2con.com/">
  <span class="summary">Web 2.0 Conference</span>:
  <abbr class="dtstart" title="2005-10-05">October 5</abbr>-
  <abbr class="dtend" title="2005-10-07">7</abbr>,
 at the <span class="location">Argent Hotel, San Francisco, CA</span>
 </a>
</span>

Benefits:

 YYYY-MM-DD is easier to read for humans, than YYYYMMDD.

 Rationale: As some UAs disclose the contents of the title attribute
 (e.g. in form of a tooltip) the contents of the title attribute should
 also be easly readable by humans.

Drawbacks:

 Parsers MUST both recognize the YYYYMMDD format and the YYYY-MM-DD
 format. (When translating hCalendar to iCal, the dashes MUST be
 removed)
 That should not be too hard to implement.

Thanks in advance for your comments,
 Robert

P.S:
"SHOULD" and "MUST" are to be interpreted as described in
RFC 2119.
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From tantek at cs.stanford.edu  Sun Jul 17 08:38:12 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sun Jul 17 08:38:11 2005
Subject: [microformats-discuss] hCalendar - Proposal for "YYYY-MM-DD"
In-Reply-To: <42DA6094.8090207@rbach.priv.at>
Message-ID: <BEFFC928.5D38F%tantek@cs.stanford.edu>

On 7/17/05 6:43 AM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:

> hCalendar should also allow the YYYY-MM-DD format.
> Even better hCalendar should recommend the YYYY-MM-DD format over
> the YYYYMMDD format, i.e. authors and iCal-to-hCalendar converters
> SHOULD produce YYYY-MM-DD.

Robert, it already does, since hCalendar specifies ISO8601 date format, and
YYYY-MM-DD is valid ISO8601 date syntax.

Tantek

From rbach at rbach.priv.at  Sun Jul 17 09:16:45 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 17 09:16:29 2005
Subject: [microformats-discuss] hCalendar - Proposal for "YYYY-MM-DD"
In-Reply-To: <BEFFC928.5D38F%tantek@cs.stanford.edu>
References: <BEFFC928.5D38F%tantek@cs.stanford.edu>
Message-ID: <42DA846D.4010207@rbach.priv.at>

Tantek ?elik wrote:
> On 7/17/05 6:43 AM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:
> 
> 
>>hCalendar should also allow the YYYY-MM-DD format.
>>Even better hCalendar should recommend the YYYY-MM-DD format over
>>the YYYYMMDD format, i.e. authors and iCal-to-hCalendar converters
>>SHOULD produce YYYY-MM-DD.
> 
> Robert, it already does, since hCalendar specifies ISO8601 date format, and
> YYYY-MM-DD is valid ISO8601 date syntax.

Oh, so I tried to fix a non-existing problem. ;-)
I suppose it's okay if I change the example to use "YYYY-MM-DD"

-	<abbr class="dtstart" title="20051005">October 5</abbr>-	+	<abbr
class="dtstart" title="2005-10-05">October 5</abbr>-	
-	<abbr class="dtend" title="20051007">7</abbr>,	
+	<abbr class="dtend" title="2005-10-07">7</abbr>,

For the reasons stated in my previous email I've added
"The notation YYYY-MM-DD should be used instead of YYYYMMDD for better
readability." to note 4 of "1.5 Example".

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Sun Jul 17 10:48:48 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 17 10:48:54 2005
Subject: [microformats-discuss] Referencing hCards
In-Reply-To: <21e770780507170104389953aa@mail.gmail.com>
References: <27E7A480-38D5-4F29-B5D8-63064F0CFE02@technorati.com>
	<42D96EE0.50007@gmail.com>
	<A9F053C9-965B-4EED-8583-EDCFCA545337@technorati.com>
	<42D98E88.3080700@gmail.com>
	<8854CC6C-3607-4CB4-B990-0AC8D7C0BC25@technorati.com>
	<21e770780507170104389953aa@mail.gmail.com>
Message-ID: <ECFBBDCF-9516-4081-8F14-93E22ACB5AE2@technorati.com>

On Jul 17, 2005, at 1:04 AM, Brian Suda wrote:
>> Right. So, just spider XFN'ed links. So:
>>
>> 1. I link to you.
>> 2. You have an hCard on your homepage OR
>> 3. link to your hCard with rel="me"
>>
>> voila! distributed addressbook with XFN + hCard.
>
> XFN is a seperate microformat than hCard, so there is no implcation
> that XFN means hCard.

You're right, it doesn't. But the assumption is that the link refers  
to a page for that person and if a person has an hcard it will either  
be on that page or linked with a rel='me'.

> Spidering those links needlessly would generate
> more bandwidth,

But less than spidering all links.

> processor time, and execution time. I was looking for
> a way to say without a doubt, that on the other end of the link is an
> hCard.

Good luck. There's no way to do this reliably on the WWW.

> Since there is no way to do this with certainty this idea is
> moot. It was just a thought.

Who needs certainty? I think this could still be done without having  
certainty.

-ryan
From ryan at technorati.com  Sun Jul 17 10:58:01 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 17 10:58:05 2005
Subject: [microformats-discuss] hCalendar - Proposal for "YYYY-MM-DD"
In-Reply-To: <42DA6094.8090207@rbach.priv.at>
References: <42DA6094.8090207@rbach.priv.at>
Message-ID: <372F4208-FE4B-4ACF-8144-E76715C44BC8@technorati.com>


On Jul 17, 2005, at 6:43 AM, Robert Bachmann wrote:
>
> hCalendar should also allow the YYYY-MM-DD format.

It does.

Please read the ISO 8601 spec (or a guide to it (like this: http:// 
www.cl.cam.ac.uk/~mgk25/iso-time.html)).

-ryan

From rbach at rbach.priv.at  Sun Jul 17 11:18:36 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 17 11:17:57 2005
Subject: [microformats-discuss] hCalendar - Proposal for "YYYY-MM-DD"
In-Reply-To: <372F4208-FE4B-4ACF-8144-E76715C44BC8@technorati.com>
References: <42DA6094.8090207@rbach.priv.at>
	<372F4208-FE4B-4ACF-8144-E76715C44BC8@technorati.com>
Message-ID: <42DAA0FC.4090400@rbach.priv.at>

Ryan King wrote:
> 
> On Jul 17, 2005, at 6:43 AM, Robert Bachmann wrote:
> 
>>
>> hCalendar should also allow the YYYY-MM-DD format.
> 
> 
> It does.
> 
> Please read the ISO 8601 spec (or a guide to it (like this: http://
> www.cl.cam.ac.uk/~mgk25/iso-time.html)).

Thanks for the link. I've read the guide.

The problem I was objecting to is the usage of the compact YYYYMMDD format.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From chris.messina at gmail.com  Sun Jul 17 11:32:10 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Sun Jul 17 11:32:11 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <e8ca2e110507150232705f8e79@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<e8ca2e110507150232705f8e79@mail.gmail.com>
Message-ID: <1bc4603e050717113270f714bd@mail.gmail.com>

On 7/15/05, Carl Beeth <carl.beeth@gmail.com> wrote:
> >  I am trying to imagine that... but what does the browser *DO* with the
> > microformat once it finds it?  Hands it over to the user's calendar app?
> > Adds a button next to it, ala greasemonkey?  I am trying to get a firm
> > understanding of the user-space tools for microformats.
> 
> The first thing the browser needs to do is make the user aware that
> it's there, maybe by displaying a little icon next to the cursor on
> hover. The browser can then give the user a CHOICE of actions on right
> click. In the case of a hcard they COULD be:
> - Compose a new mail
> - Add it to you address book
> - Map the location
> - Dial the number
> - Display the local time
> - Forward as vCard

That's only the beginning, really. Imagine a webpage offering you the
kind of rich interaction that your desktop gives you (drag n' drop,
more powerful contextual menus, interapp functionality, etc). For an
example of a rich user experience on a webpage, check out Panic's
shopping cart (http://panic.com/goods/) and then imagine being able to
have that interaction on *any* webpage on any arbitrary piece of data
that's been marked up as a microformat (in this example, an equivalent
would be to drag an hCal event into iCal).

All of this can be done once the browser wisens up to microformats.
And as Ryan said (paraphrasing me, no less
(http://theryanking.com/blog/archives/2005/06/29/yahoo-my-web-20/#comment-512)),
just imagine if someone builds that browser. ;)

Chris
From bud at thecommunityengine.com  Sun Jul 17 14:59:59 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul 17 14:59:55 2005
Subject: [microformats-discuss] reblogging & License
In-Reply-To: <976EBE0A-2B72-4312-A4C5-19A20680FB25@technorati.com>
References: <00c401c588de$12473160$6464a8c0@hellonwheels>
	<976EBE0A-2B72-4312-A4C5-19A20680FB25@technorati.com>
Message-ID: <80F8416F-2B39-4DAE-8B89-A97ECB016534@thecommunityengine.com>

A couple of things strike me:

1.  We talk about reblogging, but I think we mean republishing in  
general.

2.  It seems a lot of content is published with the intent of being  
republished.  Calendar information, hCards, summaries of our own  
site's content.  Does licensing really apply here?

3.  The issue of identifying when a microformat is in use and what it  
applies to raises its head again here in this specific application  
(sorry Ryan, had to sneak that in :).

4.  Having different licenses apply to different pieces of content on  
a single page sounds complicated.  How would the average person  
know?  Just getting one license installed on a page seems like it is  
now the limit of most tools.

Just some thoughts,
Bud
On Jul 15, 2005, at 16:39, Ryan King wrote:


> On Jul 14, 2005, at 6:39 PM, Eran wrote:
>
>
>>> License info? I think its been used by more people than you'd
>>> expect- it comes built into the code snippet that CC provides.
>>>
>>>
>>
>> That's cool but most online content is not under CC. I doubt CNN will
>> use CC as a license but they will definitely be a popular target for
>> reblogging.
>>
>>
>
> Right. Of course, you don't need to link to a license. By default,  
> its "all rights reserved." So, I don't think CNN would even need to  
> link to a license.
>
>
>
>>> No, it doesn't deal with that. Is not having a machine-readable
>>> license a problem?
>>>
>>>
>>
>> Not having machine reable license is not a problem just as not having
>> machine readable reviews or events is not a problem.
>>
>>
>
> Of course, there are millions of reviews, so there's no way that a  
> human being could read all of them, whereas there are (at most)  
> dozens of licenses; someone could read all of those (or pay their  
> lawyer to).
>
>
>
>> Having machine
>> reable license has advantages though. For example, a republishing  
>> tool
>> that wants to play nice (and as a result not get shut down by the
>> supreme court) could use machine readable license info to decide what
>> can be done with a specific bit of content. Can it be edited? Can it
>> even be republished? Etc.
>>
>>
>
> Right. Currently, the software developers have to know about the  
> possible licenses and code to deal with them individually.  
> Currently there are not enough licenses out there for this to be a  
> problem. (and, having few licenses is good :))
>
> -ryan
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>


From bud at thecommunityengine.com  Sun Jul 17 15:00:28 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul 17 15:00:23 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <1bc4603e050717113270f714bd@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<8D718498-CC44-4BAA-B46D-5E1377ED42E7@thecommunityengine.com>
	<67F8E47B-67FD-4CEC-BE8A-D3CC1AD95EF0@bokardo.com>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<e8ca2e110507150232705f8e79@mail.gmail.com>
	<1bc4603e050717113270f714bd@mail.gmail.com>
Message-ID: <F71305DF-04E8-4DFB-A8CA-4857E47862FF@thecommunityengine.com>

On Jul 17, 2005, at 14:32, Chris Messina wrote:


> All of this can be done once the browser wisens up to microformats.
> And as Ryan said (paraphrasing me, no less
> (http://theryanking.com/blog/archives/2005/06/29/yahoo-my-web-20/ 
> #comment-512)),
> just imagine if someone builds that browser. ;)
>
>

So, IE is coming out with this? :D

Will there be an open source version?

Bud

From porter at bokardo.com  Mon Jul 18 09:47:38 2005
From: porter at bokardo.com (Joshua Porter)
Date: Mon Jul 18 09:47:44 2005
Subject: [microformats-discuss] Auto-Discovery
In-Reply-To: <31AE1986-C622-48EF-9EDA-76F37D8160CE@technorati.com>
References: <1f2ed5cd05071403146d5ced02@mail.gmail.com>
	<CBFB3D0F-9D11-4B82-AF26-6338E17431C3@technorati.com>
	<e8ca2e1105071411011cd82fca@mail.gmail.com>
	<5215203A-97B2-4744-A3E3-5FA52BA7AB31@technorati.com>
	<e8ca2e1105071503553dc241f3@mail.gmail.com>
	<42D79AA2.2060603@gmail.com>
	<e8ca2e110507150430111baed3@mail.gmail.com>
	<31AE1986-C622-48EF-9EDA-76F37D8160CE@technorati.com>
Message-ID: <5F00A805-33A5-4547-8E82-E86DB4E8F9AC@bokardo.com>


On Jul 15, 2005, at 5:18 PM, Ryan King wrote:

> On Jul 15, 2005, at 4:30 AM, Carl Beeth wrote:
>
>
>>> nor would we be
>>> able to do auto-discovery via the profile="...".
>>>
>>
>> Again sorry if this is a stupid question but what do we mean with
>> auto-discovery?
>>
>
> Not a stupid question. I've asked it several times in this thread,  
> though it hasn't been answered.

Mark Pilgrim and Phil Ringnalda on auto-discovery regarding Atom:

"The purpose of Atom autodiscovery is for clients who know the URI of
    a web page to find the location of that page's associated Atom feed.
    For example, say an end user wishes to subscribe to the Atom feed of
    a site.  Their Atom-aware aggregator client could prompt them to
    enter the home page of the site.  The client could retrieve the HTML
    source of the home page, find the Atom autodiscovery element, and
    then retrieve the Atom feed or cache the URI of the Atom feed for
    later retrieval."

Full text here: http://www.ietf.org/internet-drafts/draft-ietf- 
atompub-autodiscovery-01.txt

josh

From chris.messina at gmail.com  Mon Jul 18 12:20:11 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Mon Jul 18 12:21:22 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <62D0D5CA-7BD3-418A-A015-20040D114C73@umich.edu>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<e8ca2e110507150232705f8e79@mail.gmail.com>
	<1bc4603e050717113270f714bd@mail.gmail.com>
	<62D0D5CA-7BD3-418A-A015-20040D114C73@umich.edu>
Message-ID: <1bc4603e050718122043135870@mail.gmail.com>

That's highly doubtful unless Tantek gets his way. ;)

Besides my browser, I hear folks at Apple might be getting wise to MFs
so... who knows, this might all come sooner than we think! (of course
that's completely unsubstantiated at this point.)

Chris

On 7/17/05, Bud Gibson <fpgibson@umich.edu> wrote:
> On Jul 17, 2005, at 14:32, Chris Messina wrote:
> 
> > All of this can be done once the browser wisens up to microformats.
> > And as Ryan said (paraphrasing me, no less
> > (http://theryanking.com/blog/archives/2005/06/29/yahoo-my-web-20/
> > #comment-512)),
> > just imagine if someone builds that browser. ;)
> >
> 
> So, IE is coming out with this? :D
> 
> Will there be an open source version?
> 
> Bud
>
From bud at thecommunityengine.com  Mon Jul 18 14:01:50 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 18 14:01:59 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <1bc4603e050718122043135870@mail.gmail.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<e8ca2e110507150232705f8e79@mail.gmail.com>
	<1bc4603e050717113270f714bd@mail.gmail.com>
	<62D0D5CA-7BD3-418A-A015-20040D114C73@umich.edu>
	<1bc4603e050718122043135870@mail.gmail.com>
Message-ID: <19BB5668-12E5-4089-A9C2-FCAFE89B6735@thecommunityengine.com>

It would help to have more examples that people could use.  I doubt  
closed source will remain a competitive advantage in this space for  
long.

Bud
On Jul 18, 2005, at 15:20, Chris Messina wrote:


> That's highly doubtful unless Tantek gets his way. ;)
>
> Besides my browser, I hear folks at Apple might be getting wise to MFs
> so... who knows, this might all come sooner than we think! (of course
> that's completely unsubstantiated at this point.)
>
> Chris
>
>


From bud at thecommunityengine.com  Mon Jul 18 14:51:27 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Mon Jul 18 14:51:32 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <19BB5668-12E5-4089-A9C2-FCAFE89B6735@thecommunityengine.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<ac1175eb05071410444d813251@mail.gmail.com>
	<e8ca2e1105071411174a844c59@mail.gmail.com>
	<ac1175eb05071411387a14da88@mail.gmail.com>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<e8ca2e110507150232705f8e79@mail.gmail.com>
	<1bc4603e050717113270f714bd@mail.gmail.com>
	<62D0D5CA-7BD3-418A-A015-20040D114C73@umich.edu>
	<1bc4603e050718122043135870@mail.gmail.com>
	<19BB5668-12E5-4089-A9C2-FCAFE89B6735@thecommunityengine.com>
Message-ID: <6C263428-66A1-4B09-A8F2-19EBE1453BF2@thecommunityengine.com>

Hey Chris, just to clarify, Round 2 is open source, right?

We're cranking out some open source examples in our spare time.  It  
would help to have more.  Just a general observation.

Bud
On Jul 18, 2005, at 17:01, Bud Gibson wrote:

> It would help to have more examples that people could use.  I doubt  
> closed source will remain a competitive advantage in this space for  
> long.
>
> Bud
> On Jul 18, 2005, at 15:20, Chris Messina wrote:
>
>
>
>> That's highly doubtful unless Tantek gets his way. ;)
>>
>> Besides my browser, I hear folks at Apple might be getting wise to  
>> MFs
>> so... who knows, this might all come sooner than we think! (of course
>> that's completely unsubstantiated at this point.)
>>
>> Chris
>>
>>
>>
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From chris.messina at gmail.com  Mon Jul 18 15:08:07 2005
From: chris.messina at gmail.com (Chris Messina)
Date: Mon Jul 18 15:08:09 2005
Subject: [microformats-discuss] Developer Adoption
In-Reply-To: <6C263428-66A1-4B09-A8F2-19EBE1453BF2@thecommunityengine.com>
References: <B6320BE7-51D9-4CD9-8254-1BE419E18072@thedredge.org>
	<13AC6247-E710-4BC5-92F0-8C9D5759949F@technorati.com>
	<ac1175eb050714114647b80908@mail.gmail.com>
	<ac1175eb050714114758e12c8@mail.gmail.com>
	<e8ca2e110507150232705f8e79@mail.gmail.com>
	<1bc4603e050717113270f714bd@mail.gmail.com>
	<62D0D5CA-7BD3-418A-A015-20040D114C73@umich.edu>
	<1bc4603e050718122043135870@mail.gmail.com>
	<19BB5668-12E5-4089-A9C2-FCAFE89B6735@thecommunityengine.com>
	<6C263428-66A1-4B09-A8F2-19EBE1453BF2@thecommunityengine.com>
Message-ID: <1bc4603e05071815083d8108f0@mail.gmail.com>

Yes, our work will be open source and available soon enough. The MF
stuff will happen over time, (i.e. not likely in our first releases)
but it's certainly something high on my priorities list and will
happen sooner than later since, as has been numerously pointed out, is
easy enough to implement.

Chris

On 7/18/05, Bud Gibson <bud@thecommunityengine.com> wrote:
> Hey Chris, just to clarify, Round 2 is open source, right?
> 
> We're cranking out some open source examples in our spare time.  It
> would help to have more.  Just a general observation.
> 
> Bud
> On Jul 18, 2005, at 17:01, Bud Gibson wrote:
> 
> > It would help to have more examples that people could use.  I doubt
> > closed source will remain a competitive advantage in this space for
> > long.
> >
> > Bud
> > On Jul 18, 2005, at 15:20, Chris Messina wrote:
> >
> >
> >
> >> That's highly doubtful unless Tantek gets his way. ;)
> >>
> >> Besides my browser, I hear folks at Apple might be getting wise to
> >> MFs
> >> so... who knows, this might all come sooner than we think! (of course
> >> that's completely unsubstantiated at this point.)
> >>
> >> Chris
> >>
> >>
> >>
> >
> >
> > _______________________________________________
> > 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 brian.suda at gmail.com  Tue Jul 19 05:22:27 2005
From: brian.suda at gmail.com (Brian Suda)
Date: Tue Jul 19 05:23:41 2005
Subject: [microformats-discuss] Microformats and the Semantic Web
Message-ID: <21e7707805071905224bd23f8b@mail.gmail.com>

Since this is the Discussion list, i would like to pose this question
to see what everyone else thinks. We are all interested in
Microformats, so we are probably biased, but as a community we should
open this discussion.

Q: In what way do Microformats help advance the idea of the Semantic
Web, or do they at all?

I know there has been alot of talk about the lower-case semantic web
and how you use semantic mark-up in microformats, but how, or does,
this effect the BIG Semantic Web?

And i guess in the discussion, we should describe what the "BIG SW"
and "little sw" mean to each of us.

I have my own opinions, but don't want to say now incase it leads the
discussion too much.

-brian

-- 
brian suda
http://suda.co.uk
From tantek at cs.stanford.edu  Tue Jul 19 08:31:56 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 19 08:32:00 2005
Subject: [microformats-discuss] [admin] Microformats and the Semantic Web =
	open ended discussion
In-Reply-To: <21e7707805071905224bd23f8b@mail.gmail.com>
Message-ID: <BF026AC1.5D51B%tantek@cs.stanford.edu>

Brian,

While I agree that there may be folks interested in this kind of a
compare/contrast discussion, it feels like the kind of thing that could drag
on endlessly without any productive result.

I'd *really* like to avoid strictly theoretical discussion topics like this
one.

Below is my summary of situation.


On 7/19/05 5:22 AM, "Brian Suda" <brian.suda@gmail.com> wrote:

> Since this is the Discussion list, i would like to pose this question
> to see what everyone else thinks. We are all interested in
> Microformats, so we are probably biased, but as a community we should
> open this discussion.
> 
> Q: In what way do Microformats help advance the idea of the Semantic
> Web, or do they at all?

The short answer is this.

Microformats help make *today's* Web more semantic, rather than pushing a
separate parallel universe Semantic Web.

The very existence of microformats questions the need (or even desire) for a
separate parallel universe Semantic Web.

That being said, anyone using Semantic Web-like concepts/code in their own
applications can (as far as experts on all sides could tell at WWW2005),
simply "read" microformatted content into their semantic applications.
Given that, I don't see any particular *practical* need for further
discussion on this topic.

So in a very "microformat" way of thinking, I'd like to discourage further
navel gazing on this topic.

Let's focus on getting things done.

Thanks,

Tantek

From bud at thecommunityengine.com  Tue Jul 19 08:55:15 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Tue Jul 19 08:55:30 2005
Subject: [microformats-discuss] [admin] Microformats and the Semantic Web
	= open ended discussion
In-Reply-To: <BF026AC1.5D51B%tantek@cs.stanford.edu>
References: <BF026AC1.5D51B%tantek@cs.stanford.edu>
Message-ID: <28ABC214-3B39-4E97-812A-2061BD503966@thecommunityengine.com>

Tantek:

I understand why you have little stomach for this.  It seems not to  
lead to  a conclusion.  It seems relatively uninformed and maybe even  
demanding change when issues have not been adequately thought through.

However, I for one have found many gems of processing strategy that  
came out as side effects in this type of discussion.

Brian, I'll respond to you separately, as I do not want to burden  
people who have little stomach for this.  I feel you are hitting on a  
central point of confusion for people who are in the dirty business  
trying to write code and don't have the benefit of a lot of  
experience with microformats.  Perhaps, we could start a google group  
called microformat-hacking (microntent-hacking?) for people who are  
more in that mode.

Bud
On Jul 19, 2005, at 11:31, Tantek ?elik wrote:

> Brian,
>
> While I agree that there may be folks interested in this kind of a
> compare/contrast discussion, it feels like the kind of thing that  
> could drag
> on endlessly without any productive result.
>
> I'd *really* like to avoid strictly theoretical discussion topics  
> like this
> one.
>
> Below is my summary of situation.
>
>
> On 7/19/05 5:22 AM, "Brian Suda" <brian.suda@gmail.com> wrote:
>
>
>> Since this is the Discussion list, i would like to pose this question
>> to see what everyone else thinks. We are all interested in
>> Microformats, so we are probably biased, but as a community we should
>> open this discussion.
>>
>> Q: In what way do Microformats help advance the idea of the Semantic
>> Web, or do they at all?
>>
>
> The short answer is this.
>
> Microformats help make *today's* Web more semantic, rather than  
> pushing a
> separate parallel universe Semantic Web.
>
> The very existence of microformats questions the need (or even  
> desire) for a
> separate parallel universe Semantic Web.
>
> That being said, anyone using Semantic Web-like concepts/code in  
> their own
> applications can (as far as experts on all sides could tell at  
> WWW2005),
> simply "read" microformatted content into their semantic applications.
> Given that, I don't see any particular *practical* need for further
> discussion on this topic.
>
> So in a very "microformat" way of thinking, I'd like to discourage  
> further
> navel gazing on this topic.
>
> Let's focus on getting things done.
>
> Thanks,
>
> Tantek
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>

From carl.beeth at gmail.com  Tue Jul 19 08:57:25 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Tue Jul 19 08:57:31 2005
Subject: [microformats-discuss] Microformats and the Semantic Web
In-Reply-To: <21e7707805071905224bd23f8b@mail.gmail.com>
References: <21e7707805071905224bd23f8b@mail.gmail.com>
Message-ID: <e8ca2e110507190857625be4fe@mail.gmail.com>

> Q: In what way do Microformats help advance the idea of the Semantic
> Web, or do they at all?

I think it will help more than the Semantic Web crowd realizes.
Microformats offers us a way to start authoring semantically without
banging our head too hard against the table and with almost immediate
ROI. Once our CMS systems are in place and the content is stored
semantically we can easily add RDF to our templates.

A good example is RSS1.0. I think if someone found a compelling reason
why we should start outputting our RSS feeds in RDF today it is a
trivial template change. However if RSS1.0 would have been the first
flavor of RSS it would have slowed down adoption considerably because
of the added complexity.

Carl
From tantek at cs.stanford.edu  Tue Jul 19 09:08:00 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 19 09:08:04 2005
Subject: [microformats-discuss] [admin] Microformats and the Semantic
	Web = open ended discussion
In-Reply-To: <28ABC214-3B39-4E97-812A-2061BD503966@thecommunityengine.com>
Message-ID: <BF02732B.5D52A%tantek@cs.stanford.edu>

On 7/19/05 8:55 AM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> Tantek:
> 
> I understand why you have little stomach for this.

Bud, it is a simple matter of signal to noise.  This kind of discussion
usually ends up with lots of noise, with very little signal.  This kind of
discussion is also much better suited to interactive, preferably face to
face discussions.  I realize the face-to-face aspect is not available to
everyone, so for that, I encourage folks to use the IRC channel.


> It seems not to  
> lead to  a conclusion.

Correct.

> It seems relatively uninformed

Not necessarily.  Often such discussions take place by and for informed
experts.

> and maybe even  
> demanding change when issues have not been adequately thought through.

The irony is that often such discussions don't often demand change either.
That's not the problem.


> Brian, I'll respond to you separately, as I do not want to burden
> people who have little stomach for this.  I feel you are hitting on a
> central point of confusion for people who are in the dirty business
> trying to write code and don't have the benefit of a lot of
> experience with microformats.  Perhaps, we could start a google group
> called microformat-hacking (microntent-hacking?) for people who are
> more in that mode.

Bud, I'm unclear on how you see "Microformats and Semantic Web" (this
thread) has having to do with "the dirty business trying to write code"
(what you appear to be interested in).  Perhaps you just wanted to introduce
the subject currently on your mind?

If you want to talk about coding issues, please do, though the
microformats-dev list is a better place to raise those.

Thanks,

Tantek

From joshua.owens at gmail.com  Tue Jul 19 09:38:47 2005
From: joshua.owens at gmail.com (Josh Owens)
Date: Tue Jul 19 09:39:10 2005
Subject: [microformats-discuss] Dev list problems
In-Reply-To: <BF02732B.5D52A%tantek@cs.stanford.edu>
References: <28ABC214-3B39-4E97-812A-2061BD503966@thecommunityengine.com>
	<BF02732B.5D52A%tantek@cs.stanford.edu>
Message-ID: <ac1175eb05071909381c817ce3@mail.gmail.com>

On 7/19/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> 
> 
> 
> If you want to talk about coding issues, please do, though the
> microformats-dev list is a better place to raise those.
> 
> 
> Who should I contact about problems joining the dev list? I keep 
requesting it, but I am not getting a confirmation email back.

Thanks,
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050719/1fa9b764/attachment.htm
From ryan at technorati.com  Tue Jul 19 14:30:57 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 19 14:31:05 2005
Subject: [microformats-discuss] resume format examples
Message-ID: <9070A6FA-5320-40CC-88B1-596C5E18EFD8@technorati.com>

I've taken the ideas presented on http://microformats.org/wiki/resume- 
brainstorming and applied them to some real resumes. First, my own:

original: http://theryanking.com/blog/resume/
microformatted: http://cs.usfca.edu/~rking/resume.html

I've also taken (with permission) Niall Kennedy's resume and  
microformated it:

original: http://niallkennedy.com/about/resume.html
microformatted: http://cs.usfca.edu/~rking/niall.html

In both cases I've tried to apply our pre-existing microformats in a  
reasonable way. For this exercise, I've removed some other markup,  
though it's still good and semantic. I've also stripped all but a few  
styles on my resume and all of the styles on Niall's resume.

Please take a look at the new files and see what you think.

-ryan
From brian.suda at gmail.com  Tue Jul 19 15:14:24 2005
From: brian.suda at gmail.com (brian suda)
Date: Tue Jul 19 15:14:53 2005
Subject: [microformats-discuss] resume format examples
In-Reply-To: <9070A6FA-5320-40CC-88B1-596C5E18EFD8@technorati.com>
References: <9070A6FA-5320-40CC-88B1-596C5E18EFD8@technorati.com>
Message-ID: <42DD7B40.7020601@gmail.com>

One of the key points to microformats is not re-inventing the wheel.
This is a link to an XML implementation of a resume/cv, it is well
thought through, so it would be a good place to get more information for
class="" values.

http://xmlresume.sourceforge.net/

I like this:
<ul class="xoxo skills">
but then there are nested lists under that. I think that each of those
should also have some sort of <... class="skill">languages</...> values.

-brian

Ryan King wrote:

> I've taken the ideas presented on http://microformats.org/wiki/resume-
> brainstorming and applied them to some real resumes. First, my own:
>
> original: http://theryanking.com/blog/resume/
> microformatted: http://cs.usfca.edu/~rking/resume.html
>
> I've also taken (with permission) Niall Kennedy's resume and 
> microformated it:
>
> original: http://niallkennedy.com/about/resume.html
> microformatted: http://cs.usfca.edu/~rking/niall.html
>
> In both cases I've tried to apply our pre-existing microformats in a 
> reasonable way. For this exercise, I've removed some other markup, 
> though it's still good and semantic. I've also stripped all but a few 
> styles on my resume and all of the styles on Niall's resume.
>
> Please take a look at the new files and see what you think.
>
> -ryan
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From rbach at rbach.priv.at  Tue Jul 19 16:06:15 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Tue Jul 19 16:05:35 2005
Subject: [microformats-discuss] hCard and spam
Message-ID: <42DD8767.4050009@rbach.priv.at>

I see a possible disadvantage of hCard usage.

"mailto:" and "@" make it easy for spammers to collect email addresses.
I suposse a lot of email address collection programs uses either
"mailto:" or "@" to recognize email addresses.
But perhaps there is a work around:
Instead of writing

 <a class="email"
 href="mailto:rbach@rbach.priv.at">rbach@rbach.priv.at</a>

one could write:

 <a class="e&#109;ail"
href="&#109;ailto:rbach&#064;rbach.priv.at">rbach&#064;rbach.priv.at</a>

It's still valid XHTML but AFAIK most email address collection programs
do not resolve entities.

This is just a tought.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From rbach at rbach.priv.at  Tue Jul 19 16:23:31 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Tue Jul 19 16:22:44 2005
Subject: [microformats-discuss] Comments on robot exclusion
Message-ID: <42DD8B73.6060207@rbach.priv.at>

http://microformats.org/wiki/robots-exclusion is quite interesting.

I wonder if an simple application (perhaps a PHP or Python script)
for visualization makes sense.

For example this application could be invoked with an URL of a HTML
document. The application phrases the HTML document and displays:
- links which would be followed in green.
- links which wouldn't be followed in red.
- text which would be indexed in black.
- text which wouldn't be indexed in grey.

Do you think such an application would make sense?
If yes, I could try to implement it.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Tue Jul 19 16:47:00 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 19 16:47:03 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <42DD8767.4050009@rbach.priv.at>
References: <42DD8767.4050009@rbach.priv.at>
Message-ID: <2F1C691B-B1A6-456D-97A8-5815A967A18F@technorati.com>

On Jul 19, 2005, at 4:06 PM, Robert Bachmann wrote:

> I see a possible disadvantage of hCard usage.
>
> "mailto:" and "@" make it easy for spammers to collect email  
> addresses.
> I suposse a lot of email address collection programs uses either
> "mailto:" or "@" to recognize email addresses.
> But perhaps there is a work around:
> Instead of writing
>
>  <a class="email"
>  href="mailto:rbach@rbach.priv.at">rbach@rbach.priv.at</a>
>
> one could write:
>
>  <a class="e&#109;ail"
> href="&#109;ailto:rbach&#064;rbach.priv.at">rbach&#064;rbach.priv.at</ 
> a>

This is out of scope for hCard. You don't need hCard to do this, nor  
should it be required in hCard.

-ryan

> It's still valid XHTML but AFAIK most email address collection  
> programs
> do not resolve entities.
>
> This is just a tought.
>
> Robert
From rbach at rbach.priv.at  Tue Jul 19 17:20:35 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Tue Jul 19 17:19:50 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <2F1C691B-B1A6-456D-97A8-5815A967A18F@technorati.com>
References: <42DD8767.4050009@rbach.priv.at>
	<2F1C691B-B1A6-456D-97A8-5815A967A18F@technorati.com>
Message-ID: <42DD98D3.50403@rbach.priv.at>

Ryan King wrote:
> On Jul 19, 2005, at 4:06 PM, Robert Bachmann wrote:
>  [...]
>> one could write:
>>
>>  <a class="e&#109;ail"
>> href="&#109;ailto:rbach&#064;rbach.priv.at">rbach&#064;rbach.priv.at</ a>
> 
> This is out of scope for hCard. You don't need hCard to do this, nor 
> should it be required in hCard.
> 
I am agreed, it's out of scope.
Don't get me wrong this is neither a criticism on hCard nor is it a
proposal for changing the hCard specification.

I just wanted to make sure that the people here are aware of the
downside of "mailto:" and the possible(*) workaround.
As "mailto:" is used with hCard, hCard automatically "inherits" this
disadvantage.

If someone writes a tutorial on the topic "how to use/implement hCards
on your website", perhaps this should be also mentioned.

Robert

(*) This workaround will not work for ever. I suppose that sooner or
later email address collector programs will know how to deal with
character entities.
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From tantek at cs.stanford.edu  Tue Jul 19 17:54:01 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 19 17:54:08 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <42DD98D3.50403@rbach.priv.at>
Message-ID: <BF02EEB1.5D5BE%tantek@cs.stanford.edu>

On 7/19/05 5:20 PM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:

> Ryan King wrote:
>> On Jul 19, 2005, at 4:06 PM, Robert Bachmann wrote:
>>  [...]
>>> one could write:
>>> 
>>>  <a class="e&#109;ail"
>>> href="&#109;ailto:rbach&#064;rbach.priv.at">rbach&#064;rbach.priv.at</ a>
>> 
>> This is out of scope for hCard. You don't need hCard to do this, nor
>> should it be required in hCard.
>> 
> I am agreed, it's out of scope.
> Don't get me wrong this is neither a criticism on hCard nor is it a
> proposal for changing the hCard specification.
> 
> I just wanted to make sure that the people here are aware of the
> downside of "mailto:" and the possible(*) workaround.
> As "mailto:" is used with hCard, hCard automatically "inherits" this
> disadvantage.
> 
> If someone writes a tutorial on the topic "how to use/implement hCards
> on your website", perhaps this should be also mentioned.

You're absolutely right Robert.

This would be useful in a "how to" for hCards.

Could you like to add a short note (perhaps in a new section) to that effect
on the hcard-brainstorming wiki page?


I've done something similar with the hCards on the latest draft of the
CSS2.1 specification:

 http://w3.org/TR/CSS21/

View source and take a look.


> (*) This workaround will not work for ever. I suppose that sooner or
> later email address collector programs will know how to deal with
> character entities.

Right.

The flip side is that so many of us "older" folks on the net have email
addresses that have been archived on the web in *so* many places (like for
me, tantek@cs.stanford.edu all over W3C mailing lists), that it literally
makes *no* difference (in terms of additional spam) to have one more page
with that address.

Thanks,

Tantek

From brian.suda at gmail.com  Tue Jul 19 17:54:56 2005
From: brian.suda at gmail.com (brian suda)
Date: Tue Jul 19 17:55:24 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <42DD98D3.50403@rbach.priv.at>
References: <42DD8767.4050009@rbach.priv.at>	<2F1C691B-B1A6-456D-97A8-5815A967A18F@technorati.com>
	<42DD98D3.50403@rbach.priv.at>
Message-ID: <42DDA0E0.7060903@gmail.com>

After you posted the first message, i check X2V to see what would
happen. Even with your 'encoding' which is just the decimal value of the
character, the XSLT transformation function i am using (the one built
into PHP) converts all of your decimal escape sequence to the actual
letter. So X2V will actually extract your obfuscated email address just
fine. I would double check to make sure, but it works fine on my end.

http://suda.co.uk/projects/X2V/

-brian

Robert Bachmann wrote:

>Ryan King wrote:
>  
>
>>On Jul 19, 2005, at 4:06 PM, Robert Bachmann wrote:
>> [...]
>>    
>>
>>>one could write:
>>>
>>> <a class="e&#109;ail"
>>>href="&#109;ailto:rbach&#064;rbach.priv.at">rbach&#064;rbach.priv.at</ a>
>>>      
>>>
>>This is out of scope for hCard. You don't need hCard to do this, nor 
>>should it be required in hCard.
>>
>>    
>>
>I am agreed, it's out of scope.
>Don't get me wrong this is neither a criticism on hCard nor is it a
>proposal for changing the hCard specification.
>
>I just wanted to make sure that the people here are aware of the
>downside of "mailto:" and the possible(*) workaround.
>As "mailto:" is used with hCard, hCard automatically "inherits" this
>disadvantage.
>
>If someone writes a tutorial on the topic "how to use/implement hCards
>on your website", perhaps this should be also mentioned.
>
>Robert
>
>(*) This workaround will not work for ever. I suppose that sooner or
>later email address collector programs will know how to deal with
>character entities.
>  
>

From microformats-discuss at peterjanes.ca  Tue Jul 19 18:38:39 2005
From: microformats-discuss at peterjanes.ca (Peter Janes)
Date: Tue Jul 19 18:38:45 2005
Subject: [microformats-discuss] Comments on robot exclusion
In-Reply-To: <42DD8B73.6060207@rbach.priv.at>
References: <42DD8B73.6060207@rbach.priv.at>
Message-ID: <42DDAB1F.1090802@peterjanes.ca>

Robert Bachmann wrote:
> http://microformats.org/wiki/robots-exclusion is quite interesting.
> 
> I wonder if an simple application (perhaps a PHP or Python script)
> for visualization makes sense.

I think that might be overkill, considering the example page at
http://peterjanes.ca/2005/robots/example does something very similar already
using only CSS styles and a little bit of JavaScript to toggle them.  I'll
admit that the toggle that actually displays the alternate view wasn't all
that visible on the page; it should be better now.  (It's beyond my ken to
figure out how to get that page on the wiki.)

> For example this application could be invoked with an URL of a HTML
> document. The application phrases the HTML document and displays:
> - links which would be followed in green.
> - links which wouldn't be followed in red.

That's somewhat clearer than the styles I originally chose; I've updated the
example page accordingly.

> Do you think such an application would make sense?
> If yes, I could try to implement it.

A JavaScript bookmarklet is probably all it would take to apply on demand to a
page, or a GreaseMonkey user script to browse in "robot mode".

Thanks for the comments.

Peter J.
-- 
"Fighting a war is easy.  Destroying is easy.  Building a new world out of
  what's left of the old, that is what's hard."  -- J. Michael Straczynski
        Lenni Jabour & The Third Floor: http://peterjanes.ca/LenniFan/
Sirens: http://www.sirens3.com/      Petroglyphs: http://peterjanes.ca/blog/
From rbach at rbach.priv.at  Tue Jul 19 18:48:21 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Tue Jul 19 18:47:42 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <42DDA0E0.7060903@gmail.com>
References: <42DD8767.4050009@rbach.priv.at>	<2F1C691B-B1A6-456D-97A8-5815A967A18F@technorati.com>	<42DD98D3.50403@rbach.priv.at>
	<42DDA0E0.7060903@gmail.com>
Message-ID: <42DDAD65.6050402@rbach.priv.at>

brian suda wrote:
> After you posted the first message, i check X2V to see what would
> happen. Even with your 'encoding' which is just the decimal value of the
> character, the XSLT transformation function i am using (the one built
> into PHP) converts all of your decimal escape sequence to the actual
> letter. So X2V will actually extract your obfuscated email address just
> fine. I would double check to make sure, but it works fine on my end.

X2V is using XSLT, therfore it interprets XHTML files as XML documents,
but most (or at least some) email spiders/email address collection
programs are not fully-fledged (X)HTML interrepreters the simply see
(X)HTML files as simple text files.

Three years ago I recived lots of spam, so I did an experiment.
I downloaded some email spiders  and tested them on a simple HTML page.
I can't remember the details, but I guess I should repeat my experiment
to see how email spiders have developed.

The HTML looked like this:

 1. <a href="mailto:mail1@example.org">mail1@example.org</a>.
 2. <a href="mailto:mail2[at]example.org">mail2[at]example.org</a>.
 3. mail3@example.org
 4. <!-- mail4@example.org -->
 5. mail5[at]example.org

Every spider found mail1@example.org.
Some spiders found mail2[at]example.org.
Some other spiders found mail3@example.org and mail4@example.org.
No spider found mail5[at]example.org

So my conlusion was:
- Some programs simply search for "mailto:"
- Some programs search for X@Y (X and Y being some regular expressions)

So I used a technique which was already documented on the Internet.
I replaced "mailto:" with "&#109;ailto:" and "@" with "&#064;", and the
spiders it used where not able to find my email addresses.
This allowed me to protect email addresses from spiders *and* to be
still compatible with every browser.

As said, I'm gonna to repeat my experiment and I wouldn't wonder if
there were spiders which could also decode HTML.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From jkinberg at gmail.com  Tue Jul 19 22:13:04 2005
From: jkinberg at gmail.com (Joshua Kinberg)
Date: Tue Jul 19 22:13:54 2005
Subject: [microformats-discuss] Proposal: rel="payment"
Message-ID: <db72114f050719221376a80c45@mail.gmail.com>

I am new to this list and wanted to float out an idea for comments...

I am one of the developers of FireANT (http://GetFireANT.com), a media
aggregator and RSS reader geared primarily toward videoblogs.

Peter Van Dijk of MeFeedia.com (another videoblog aggregator), Jay
Dedman (my partner on FireANT), and I were thinking a few nights ago
about how we could develop a way for blog content creators
(specifically videobloggers, but the idea is more general) to
potentially get paid for their work. I think we came up with a great
idea:

rel="payment"

Blog authors could include a link to a payment URL in their blog
entries using this syntax:

<a href="http://blahblah/payme.html" rel="payment">Pay Me</a>

The payment URL could link to a PayPal page, BitPass, DropCash, or
some other payment method... maybe even a page with your mailing
address so someone could send a check the old fashioned way. Heck, it
could be a page that let's you donate to a "save the whales"
foundation, or to your Cafe Press store. That part is up to the author
to set up a payment URL that works for them.

Aggregators like FireANT, MeFeedia, and others could support this by
displaying a "payment button" that links to the specified payment URL
if the rel="payment" syntax is discovered within the RSS item level
<description> or <content:encoded> elements.

This is simple and flexible, and I think will be easy for blog authors
to implement.

However, an XML namespace would be a better and more elegant solution
and easier for aggregators to handle. If blog authors begin using
something like rel="payment" now, it will create a nice foundation for
evangelizing the namespace and getting support from blog software
developers and RSS/ATOM folks.

So I wanted to throw out the idea for comments to see what you think
and explore how we might be able to work together.

For more background, see Jay's post on the subject:
http://www.momentshowing.net/momentshowing/2005/07/video_relpaymen.html

Also, see how MeFeedia has already implemented support for rel="payment":
http://poorbuthappy.com/ease/archives/2005/07/18/2767/

Let's open the discussion.

A few things to note:

- This is not payment as a form of restricted access. It is an
optional payment after the fact of downloading. Perhaps it is more
like a "donation" but we felt "payment" was a more general term.

- This should not entail lock-in to a specific payment protocol (i.e.
PayPal), and is not mediated through any one source (e.g. iTunes Music
Store). Flexibility is good.

- I think an XML namespace for this concept should likely be both
channel level and item level. A user may want to track click-through's
per item to see where payments are coming from. Another use case might
be a blog entry about a specific fundraising campaign (e.g. Tsunami
Relief Fund). Or, perhaps a product review would include an affilliate
link to a URL where the reader can purchase that product.

Of course, the ever-present-and-unchanging "tip jar" link in the blog
sidebar could be placed in the channel level. Again, flexibility is
good.


I will begin drafting up a proposal spec for a namespace soon and
welcome your comments and suggestions.

Best regards,
Joshua Kinberg

http://GetFireANT.com
From limbo at speakeasy.net  Wed Jul 20 02:17:46 2005
From: limbo at speakeasy.net (Eran)
Date: Wed Jul 20 02:17:58 2005
Subject: [microformats-discuss] hCard clarifications
Message-ID: <002401c58d0b$e60c2740$6402a8c0@hellonwheels>

Looking at the specs for hCard and at some of the examples I've come
across a slight variations, I'm looking at complex elements like adr. 

http://www.crowley.nl/hcard.html includes an adr field composed of
several "sub"-fields (although it neglects to separate them with a
semicolon):

<div class="adr">
  <div class="street-address">Waarderweg 52d</div>
  <span class="postal-code">2031BP</span>
  <span class="locality">Haarlem <abbr
title="Netherlands">NL</abbr></span>
 </div>

http://home.alltel.net/jackwolfgang/blog/2005/06/microformats-resume-upd
ate.html used the sub-fields without the containing adr field:

<div class="vcard Centered">
 <a href="http://home.alltel.net/jackwolfgang/" target="_self" 
  class="url fn n" rel="me">
  <span class="given-name">Jack</span> L.
  <span class="family-name">Wolfgang</span>
  II</a><br />
 <span class="locality">Cairo</span>,
 <span class="region">Georgia</span>,
 <span class="country-name">

  <abbr title="United States of America">USA</abbr></span>
 <span class="postal-code">39827</span><br />
 <a href="../contact/" target="_self" class="email">E-Mail 
  via Web Form</a><br />
</div>

Are both correct? What exactly are the rules for using complex fields?

While I'm here, another question on multiple classes. For example the
following element:

<a href="http://home.alltel.net/jackwolfgang/" target="_self" 
  class="url fn n" rel="me">
  <span class="given-name">Jack</span> L.
  <span class="family-name">Wolfgang</span>
  II</a>

What are the rules for interpreting the "url fn n" class string? Is
there a relation between the order of classes in the class string and
the href & text properties of the A element?

TIA,
Eran.

From brian.suda at gmail.com  Wed Jul 20 05:19:25 2005
From: brian.suda at gmail.com (Brian Suda)
Date: Wed Jul 20 05:20:08 2005
Subject: [microformats-discuss] hCard clarifications
In-Reply-To: <002401c58d0b$e60c2740$6402a8c0@hellonwheels>
References: <002401c58d0b$e60c2740$6402a8c0@hellonwheels>
Message-ID: <21e7707805072005191533868e@mail.gmail.com>

On 7/20/05, Eran <limbo@speakeasy.net> wrote:
> Looking at the specs for hCard and at some of the examples I've come
> across a slight variations, I'm looking at complex elements like adr.
> 
> http://www.crowley.nl/hcard.html includes an adr field composed of
> several "sub"-fields (although it neglects to separate them with a
> semicolon):

The semicolons are not needed, those are added by the transforming
program. The semicolon is just a sperator in vCard. In HTML the
individual tags act as the seperators.

> 
> <div class="adr">
>  <div class="street-address">Waarderweg 52d</div>
>  <span class="postal-code">2031BP</span>
>  <span class="locality">Haarlem <abbr
> title="Netherlands">NL</abbr></span>
>  </div>
> 
> http://home.alltel.net/jackwolfgang/blog/2005/06/microformats-resume-upd
> ate.html used the sub-fields without the containing adr field:

This is actually incorrect, an additional <... class='adr'></...> is
needed wrapped around all the postal information.

> <div class="vcard Centered">
>  <a href="http://home.alltel.net/jackwolfgang/" target="_self"
>  class="url fn n" rel="me">
>  <span class="given-name">Jack</span> L.
>  <span class="family-name">Wolfgang</span>
>  II</a><br />
>  <span class="locality">Cairo</span>,
>  <span class="region">Georgia</span>,
>  <span class="country-name">
> 
>  <abbr title="United States of America">USA</abbr></span>
>  <span class="postal-code">39827</span><br />
>  <a href="../contact/" target="_self" class="email">E-Mail
>  via Web Form</a><br />
> </div>
> 
> Are both correct? What exactly are the rules for using complex fields?

No, the second one is not correct.

> While I'm here, another question on multiple classes. For example the
> following element:
> 
> <a href="http://home.alltel.net/jackwolfgang/" target="_self"
>  class="url fn n" rel="me">
>  <span class="given-name">Jack</span> L.
>  <span class="family-name">Wolfgang</span>
>  II</a>
> 
> What are the rules for interpreting the "url fn n" class string? Is
> there a relation between the order of classes in the class string and
> the href & text properties of the A element?

That is very acceptable, in the case of URL, since the 'a' is the most
semantic, the information is retrived from the href, but in the case
of fn and n the string Jack ... is used.

There is no exact rule on what follows what. In X2V for certain
properties certain attributes are looked at first. For dtstart, dtend,
dtstamp and other date-time elements the title='' element is looked at
first, for URL and eMail, the href='', for images the src='', for
others the node value is used or something like alt, or longdesc, etc.
There is not an exact science to it yet.

-brian

-- 
brian suda
http://suda.co.uk
From drernie at opendarwin.org  Wed Jul 20 12:54:31 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Wed Jul 20 12:54:36 2005
Subject: [microformats-discuss] personal intro
Message-ID: <84631F8D-66A3-4170-A39B-300CD82FD0C9@opendarwin.org>

Hi all,

I'm late to the game, but trying to catch up.  I run a couple of  
minor personal blogs (News from The Radical Center, Radically Happy),  
one group blog (www.bloginators.com), and contribute to Wikipedia.   
I've also written the odd Portfile and GUI for DarwinPorts on Mac OS X.

Perhaps of greater relevance, I'm trying to gain some clues about the  
future of XML/XHTML/RSS, which I hope will prove useful for my day  
job.  But that's another story for another time...

-- Ernie P.

From bjoernseibert at gmx.de  Wed Jul 20 14:33:17 2005
From: bjoernseibert at gmx.de (=?ISO-8859-15?Q?Bj=F6rn_Seibert?=)
Date: Wed Jul 20 14:32:44 2005
Subject: [microformats-discuss] Joined the list
Message-ID: <42DEC31D.1010500@gmx.de>

Just want to say hello to everyone here and test if it works for me.

Bj?rn Seibert
From simonlilja at gmail.com  Wed Jul 20 17:06:07 2005
From: simonlilja at gmail.com (Simon)
Date: Wed Jul 20 17:06:55 2005
Subject: [microformats-discuss] Joined the list
In-Reply-To: <42DEC31D.1010500@gmx.de>
References: <42DEC31D.1010500@gmx.de>
Message-ID: <80436ac1050720170643852495@mail.gmail.com>

Hi, Bj?rn! It appears to work just fine. :)

On 7/20/05, Bj?rn Seibert <bjoernseibert@gmx.de> wrote:
> 
> Just want to say hello to everyone here and test if it works for me.
> 
> Bj?rn Seibert
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050721/5a6cc429/attachment.htm
From bud at thecommunityengine.com  Wed Jul 20 19:50:43 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Wed Jul 20 19:50:48 2005
Subject: [microformats-discuss] Imitation is the sincerest sign of success
Message-ID: <E7C4117A-019C-4802-BF97-DDAD383B69D0@thecommunityengine.com>

Icerocket, a blog search engine that competes with technorati has  
adopted tagging via RELTAG as they explain in this help page:

http://www.icerocket.com/c?p=tags

 From the perspective of microformats and even technorati, this is a  
quite positive development as I explain in this blog post:

http://thecommunityengine.com/home/archives/2005/07/imitation_is_th.html

Bud
From jkinberg at gmail.com  Wed Jul 20 23:35:12 2005
From: jkinberg at gmail.com (Joshua Kinberg)
Date: Wed Jul 20 23:35:46 2005
Subject: [microformats-discuss] rel="payment" : specification draft
Message-ID: <db72114f0507202335339cbb8d@mail.gmail.com>

=== rel="payment" - Draft 2005-07-20 ===

Author: Andreas Haugstrup Pedersen
Concept: Joshua Kinberg, Peter Van Dijck, Jay Dedman

== Abstract ==

RelPayment is a microformat for making exchanges of support (be it
financial or otherwise) possible. By adding rel="payment" to a
hyperlink a page indicates that the destination of that hyperlink
provides a way to show or give support for the current page. For
example to give financial support to the owner of the current page.

One of the goals with this microformat is to give content aggregators
such as RSS readers a way to extract these support links and give them
special attention (such as displaying a standard button along with the
content).

== RelPayment ==

RelPayment is meant as a general way to facilitate acts of support,
and thus this specification makes no assumptions on the type of
support.

A page may contain any number of hyperlinks marked with rel="payment".
This allows authors to give readers more than one possible way to show
support (a DropCash link, a PayPal link, a link to a Cafe Press store,
a link to a page with an address to mail a check and so on). It also
allows authors to add payment links that only relate to a certain
section of a page, e.g. a book review website may have several book
reviews on one page with each review having their own Amazon Affiliate
link marked with rel="payment".

Authors should use the "title" attribute to provide a human readable
description of the type of support pointed to by the hyperlink.
Aggregators may use the contents of the "title" attribute to provide
additional information about the support link to their users, e.g. <a
href="[url]" rel="payment" title="Donate Money Via PayPal">.

If the hyperlink contains an image (e.g. <a href="[url]
rel="payment"><img src="[url]" alt="Support Badge" /></a>) aggregators
may display instead of their standardized links.

== Visible Metadata ==

Links marked with rel="payment" are meant to be visible on the page,
and because of that the <a> element is encouraged over the <link>
element. This gives readers the easiest access to show support and it
discourages link fraud. Authors should not use empty hyperlinks such
as <a href="[url]" rel="payment" /> and parsers may ignore empty
links.

== XMDP profile ==

<dl class="profile">
 <dt id="rel">rel</dt>
 <dd><p>
   <a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
     HTML4 definition of the 'rel' attribute.</a>  
   Here is an additional value.</p>
  <dl>
   <dt id="payment">payment</dt>
   <dd>Indicates that the referred resource provides a way to show
support for the referring page.</dd>
  </dl>
 </dd>
</dl>
From lists at elegantchaos.com  Thu Jul 21 03:25:54 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Thu Jul 21 03:26:06 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <42DD8767.4050009@rbach.priv.at>
References: <42DD8767.4050009@rbach.priv.at>
Message-ID: <658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>

On 20 Jul 2005, at 00:06, Robert Bachmann wrote:

> Instead of writing
>
>  <a class="email"
>  href="mailto:rbach@rbach.priv.at">rbach@rbach.priv.at</a>
>
> one could write:
>
>  <a class="e&#109;ail"
> href="&#109;ailto:rbach&#064;rbach.priv.at">rbach&#064;rbach.priv.at</ 
> a>

I think you're fighting a losing battle there. To be of value the  
information has to be machine readable, and if it's machine readable  
then the spammers will eventually write a spider to harvest it.
From joshua.owens at gmail.com  Thu Jul 21 06:00:13 2005
From: joshua.owens at gmail.com (Josh Owens)
Date: Thu Jul 21 06:00:14 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
References: <42DD8767.4050009@rbach.priv.at>
	<658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
Message-ID: <ac1175eb05072106007cee2d38@mail.gmail.com>

I agree with Sam... Kind of like DRM, not much point - spammers just write 
better tools.

On 7/21/05, Sam Deane <lists@elegantchaos.com> wrote:
> 
> On 20 Jul 2005, at 00:06, Robert Bachmann wrote:
> 
> > Instead of writing
> >
> > <a class="email"
> > href="mailto:rbach@rbach.priv.at">rbach@rbach.priv.at</a>
> >
> > one could write:
> >
> > <a class="e&#109;ail"
> > href="&#109;ailto:rbach&#064;rbach.priv.at">rbach&#064;rbach.priv.at</
> > a>
> 
> I think you're fighting a losing battle there. To be of value the
> information has to be machine readable, and if it's machine readable
> then the spammers will eventually write a spider to harvest it.
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050721/5c7d8049/attachment.htm
From bjoernseibert at gmx.de  Thu Jul 21 06:28:47 2005
From: bjoernseibert at gmx.de (=?ISO-8859-15?Q?Bj=F6rn_Seibert?=)
Date: Thu Jul 21 06:29:03 2005
Subject: [microformats-discuss] Microformat for blog-search and
	characterizing
Message-ID: <42DFA30F.1070502@gmx.de>

Hi, I was thinking about a format for blogs. The issue was that although 
e.g. Technorati is using a summary, for me personally I can't find out 
efficiently what's a blog about considering the fast growing number of 
blogs. So I'm following lots of links that aren't of interest for me.

Such a format offers a set of information for characterisation or 
classification of Weblogs.  Thus search services etc. could be supplied 
efficiently with the necessary information.  It would be possible for 
services to seek out and use the information for search results.  In 
addition, visitors of the Website/Weblogs could quickly find out, where 
the emphasis lay and get the feeds.

I already thought about the possible XHTML-Listing, but first want to 
share your opinions about a possible format for characterizing and 
finding blogs.

(sorry for my little bumpy English)

Bj?rn


From lists at elegantchaos.com  Thu Jul 21 06:34:24 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Thu Jul 21 06:34:33 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <ac1175eb05072106007cee2d38@mail.gmail.com>
References: <42DD8767.4050009@rbach.priv.at>
	<658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
	<ac1175eb05072106007cee2d38@mail.gmail.com>
Message-ID: <FA4FAC0C-2766-432D-9C38-94B2D0878DE4@elegantchaos.com>


On 21 Jul 2005, at 14:00, Josh Owens wrote:

> I agree with Sam... Kind of like DRM, not much point - spammers  
> just write better tools.

It's an SEP anyway, as far as microformats are concerned ;)

(http://en.wikipedia.org/wiki/Somebody_Else's_Problem_field)

From rbach at rbach.priv.at  Thu Jul 21 08:10:32 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Thu Jul 21 08:09:47 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
References: <42DD8767.4050009@rbach.priv.at>
	<658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
Message-ID: <42DFBAE8.80805@rbach.priv.at>

Sam Deane wrote:
> I think you're fighting a losing battle there. To be of value the 
> information has to be machine readable, and if it's machine readable 
> then the spammers will eventually write a spider to harvest it.

You're right, as long as data is machine-readable spammers would be able
to extract our email addresses.
But I tested some - I think popular - email spiders [1] they weren't
able to deal with "&#64;". So I think it's not a bad idea to include
this technique in further hCard "how tos". [2]

I'm well aware that we - as web authors - have no chance to stop
spammers from address harvesting, _but_ we shouldn't make it too easy
for them.

Robert

[1] http://rbach.priv.at/Misc/2005/EmailSpiderTest
[2] http://microformats.org/wiki/hcard-brainstorming#Spam_prevention

P.S:
I think this discussion will not produce futher results
relevant to microformats. Please email me directly if you have further
comments.
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From lists at elegantchaos.com  Thu Jul 21 08:53:51 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Thu Jul 21 08:54:02 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <42DFBAE8.80805@rbach.priv.at>
References: <42DD8767.4050009@rbach.priv.at>
	<658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
	<42DFBAE8.80805@rbach.priv.at>
Message-ID: <14CE6667-93EA-43F9-B811-FFA10B3172AB@elegantchaos.com>

On 21 Jul 2005, at 16:10, Robert Bachmann wrote:

> But I tested some - I think popular - email spiders [1] they weren't
> able to deal with "&#64;". So I think it's not a bad idea to include
> this technique in further hCard "how tos". [2]

I don't want to get into a "doesn't", "does", "doesn't", "does too",  
argument, so I'll shut up after this post.

I take your point that it might be a short-term work around. I'd say  
though that the spiders can't cope now because they don't need to,  
because not many addresses are encoded like that. As soon as that  
encoding becomes more common,  the spiders will catch up. In the  
meantime, we will have made the format less intuitive and less human- 
readable (yes, some humans will find themselves reading or writing  
the xml, for whatever reason).

I think that the way to fight spam is by fixing the holes in the  
email system, so that people can be held to account for the mail they  
send.  How to do that is an interesting topic, but probably not  
appropriate for this list!
From rbach at rbach.priv.at  Thu Jul 21 09:32:56 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Thu Jul 21 09:32:19 2005
Subject: [microformats-discuss] Profile URLs using PURLs?
Message-ID: <42DFCE38.2010901@rbach.priv.at>

I noticed that Dublin Core Metadata and RSS use PURLs as profile URLs.
Has anybody though about using PURLs[1] for microformat profile URLs?

Robert

[1] http://purl.org/
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Thu Jul 21 09:56:57 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 21 09:57:02 2005
Subject: [microformats-discuss] Microformat for blog-search and
	characterizing
In-Reply-To: <42DFA30F.1070502@gmx.de>
References: <42DFA30F.1070502@gmx.de>
Message-ID: <50C468A7-8784-4C4C-8287-59FF782ED297@technorati.com>

On Jul 21, 2005, at 6:28 AM, Bj?rn Seibert wrote:

> Hi, I was thinking about a format for blogs. The issue was that  
> although e.g. Technorati is using a summary, for me personally I  
> can't find out efficiently what's a blog about considering the fast  
> growing number of blogs. So I'm following lots of links that aren't  
> of interest for me.
>
> Such a format offers a set of information for characterisation or  
> classification of Weblogs.  Thus search services etc. could be  
> supplied efficiently with the necessary information.  It would be  
> possible for services to seek out and use the information for  
> search results.  In addition, visitors of the Website/Weblogs could  
> quickly find out, where the emphasis lay and get the feeds.

So, it seems you're looking for a way for bloggers to categorize  
themselves. Right? If so, there is a possiblity that we could do blog- 
level tagging (as opposed to the current post-level tagging).

> I already thought about the possible XHTML-Listing,

what's this?

-ryan

> but first want to share your opinions about a possible format for  
> characterizing and finding blogs.
>
> (sorry for my little bumpy English)
>
> Bj?rn
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://mi

From ryan at technorati.com  Thu Jul 21 09:58:41 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 21 09:58:44 2005
Subject: [microformats-discuss] Profile URLs using PURLs?
In-Reply-To: <42DFCE38.2010901@rbach.priv.at>
References: <42DFCE38.2010901@rbach.priv.at>
Message-ID: <4C12A216-33E1-4869-9154-B2B166CF64F8@technorati.com>

On Jul 21, 2005, at 9:32 AM, Robert Bachmann wrote:

> I noticed that Dublin Core Metadata and RSS use PURLs as profile URLs.
> Has anybody though about using PURLs[1] for microformat profile URLs?

Why would we want to use PURLs?

-ryan
From tantek at cs.stanford.edu  Thu Jul 21 11:29:03 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Jul 21 11:29:08 2005
Subject: [microformats-discuss] Profile URLs using PURLs?
In-Reply-To: <42DFCE38.2010901@rbach.priv.at>
Message-ID: <BF05375C.5D752%tantek@cs.stanford.edu>

On 7/21/05 9:32 AM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:

> I noticed that Dublin Core Metadata and RSS use PURLs as profile URLs.
> Has anybody though about using PURLs[1] for microformat profile URLs?
> 
> Robert
> 
> [1] http://purl.org/

Robert,

This is precisely the reason that GMPG was founded and created, to provide
permanent URLs/homes for microformat profiles, e.g.:

 http://gmpg.org/xfn/11

Thanks,

Tantek


From drernie at opendarwin.org  Thu Jul 21 11:34:33 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Thu Jul 21 11:34:38 2005
Subject: [microformats-discuss] GMPG/XMDP Re: PURLs?
In-Reply-To: <BF05375C.5D752%tantek@cs.stanford.edu>
References: <BF05375C.5D752%tantek@cs.stanford.edu>
Message-ID: <8F93488E-6F32-42C8-AE38-3F09CE8D197F@opendarwin.org>

Hi Tantek,

> This is precisely the reason that GMPG was founded and created, to  
> provide
> permanent URLs/homes for microformat profiles, e.g.:

Thanks, I was just wondering about that. What exactly is the relation  
between microformats.org and gmpg.org?   Is gmpg the official  
archives of mf.org decisions?  Does gmpg cover *more* than  
microformats?  Who owns it?  Who manages the evolution of XMDP and  
microformats? Is evolution even allowed?

-- Ernie P.

On Jul 21, 2005, at 11:29 AM, Tantek ?elik wrote:

> On 7/21/05 9:32 AM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:
>
>
>> I noticed that Dublin Core Metadata and RSS use PURLs as profile  
>> URLs.
>> Has anybody though about using PURLs[1] for microformat profile URLs?
>>
>> Robert
>>
>> [1] http://purl.org/
>>
>
> Robert,
>
> This is precisely the reason that GMPG was founded and created, to  
> provide
> permanent URLs/homes for microformat profiles, e.g.:
>
>  http://gmpg.org/xfn/11
>
> Thanks,
>
> Tantek
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From limbo at speakeasy.net  Thu Jul 21 12:24:33 2005
From: limbo at speakeasy.net (Eran)
Date: Thu Jul 21 12:24:39 2005
Subject: [microformats-discuss] hReview
Message-ID: <009d01c58e29$d34cdb80$6402a8c0@hellonwheels>

So after wrangling hCard enough to get some data of it, I'm moving on to
hReview.

First of all, I must say, thanks for the examples! One of the things I
was really missing with hCard was _valid_ examples, the ones in hReview
are a great help. 

Most of the spec seems clear enough but I've got some issues with
multiple category ratings. According to the spec one should use rel-tags
and put the rating inside the tag, why not do it the other way around?
As we're not rating a tag but tagging a rating. So the example given:

<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>
  ...
</ul>

Changes to:

<ul class="categories">
  <li>
    <abbr class="rating" title="18">
      <a href="http://en.wikipedia.org/wiki/Food" rel="tag">Food</a>:
18/<span class="best">30</span>
    </abbr>
  </li>
  ...
</ul>

Thanks,
Eran.


From bjoernseibert at gmx.de  Thu Jul 21 12:40:25 2005
From: bjoernseibert at gmx.de (=?ISO-8859-1?Q?Bj=F6rn_Seibert?=)
Date: Thu Jul 21 12:40:29 2005
Subject: [microformats-discuss] Microformat for blog-search
	and	characterizing
In-Reply-To: <50C468A7-8784-4C4C-8287-59FF782ED297@technorati.com>
References: <42DFA30F.1070502@gmx.de>
	<50C468A7-8784-4C4C-8287-59FF782ED297@technorati.com>
Message-ID: <42DFFA29.4090201@gmx.de>

Ryan King schrieb:

> On Jul 21, 2005, at 6:28 AM, Bj?rn Seibert wrote:
>
>> Hi, I was thinking about a format for blogs. The issue was that  
>> although e.g. Technorati is using a summary, for me personally I  
>> can't find out efficiently what's a blog about considering the fast  
>> growing number of blogs. So I'm following lots of links that aren't  
>> of interest for me.
>>
>> Such a format offers a set of information for characterisation or  
>> classification of Weblogs.  Thus search services etc. could be  
>> supplied efficiently with the necessary information.  It would be  
>> possible for services to seek out and use the information for  search 
>> results.  In addition, visitors of the Website/Weblogs could  quickly 
>> find out, where the emphasis lay and get the feeds.
>
>
> So, it seems you're looking for a way for bloggers to categorize  
> themselves. Right? If so, there is a possiblity that we could do blog- 
> level tagging (as opposed to the current post-level tagging).
>
>> I already thought about the possible XHTML-Listing,
>
>
> what's this?
>
> -ryan
>
>> but first want to share your opinions about a possible format for  
>> characterizing and finding blogs.
>>
>> (sorry for my little bumpy English)
>>
>> Bj?rn
>>
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://mi
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
Hi, I thought about something like that:

<div class="blogformat">
  <img class="logo" src="images/hblog.gif" alt="" /><!--optional-->
  <a class="url" href="URL" title="Zum Weblog">Blogname</a>
  <span class="language"><em> / DE: </em></span>
  <ul class="cat"><!--major categories-->
    <li>Webstandards</li>
    <li>CSS</li>
    <li>XHTML</li>
 </ul>
 <ul class="feeds"><!--one or more-->
   <li><a href="URL">RSS</a></li>
   <li><a href="URL">Atom</a></li>
 </ul>
 <span class="description">
 Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
 Internettechniken
 </span>
</div>

Bj?rn
From limbo at speakeasy.net  Thu Jul 21 12:56:15 2005
From: limbo at speakeasy.net (Eran)
Date: Thu Jul 21 12:56:23 2005
Subject: [microformats-discuss] Microformat for
	blog-searchand	characterizing
In-Reply-To: <42DFFA29.4090201@gmx.de>
Message-ID: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>

Hi Bjorn,

I like the idea of a description for blogs. With all the aggregation
that's going on right now and the certain growth of that market in the
future it is a good thing to be learn something about the source of a
piece of information without too much hassle. I see it as kind of an
hCard for blogs.

About the proposed format, here's a few possible changes:

> -----Original Message-----
> 
> <div class="blogformat">
>   <img class="logo" src="images/hblog.gif" alt="" /><!--optional-->
>   <a class="url" href="URL" title="Zum Weblog">Blogname</a>
>   <span class="language"><em> / DE: </em></span>
>   <ul class="cat"><!--major categories-->
>     <li>Webstandards</li>
>     <li>CSS</li>
>     <li>XHTML</li>
>  </ul>
>  <ul class="feeds"><!--one or more-->
>    <li><a href="URL">RSS</a></li>
>    <li><a href="URL">Atom</a></li>
>  </ul>
>  <span class="description">
>  Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
>  Internettechniken
>  </span>
> </div>
> 

<div class="blogformat" language="de"> <!-- added lanugage attribute, I
think this is the correct usage... -->
  <img class="logo" src="http://blog.url/images/hblog.gif" alt="" />
<!-- changed url to absolute rather than relative -->
  <a class="bookmark" href="URL" title="Zum Weblog">Blogname</a> <!--
changed class name to bookmark to reflect permalink type -->
  <a clss="author" href=author.url">author.name</a> <!-- added author
field, maybe link to an hcard or include one inline? -->
  <span class="language"><em> / DE: </em></span>
  <ul class="categories"> <!--changed to categories as used in hreview
sample-->
    <li><a rel="tag"
href="http://technorati.com/Webstandards">Webstandards</a></li> <!--
changed categories to tags per ryan's suggestion -->
    <li><a rel="tag" href="http://wikipedia.com/CSS">CSS</a></li>
    <li><a rel="tag" href="http://wikipedia.com/XHTML">XHTML</a></li>
 </ul>
 <ul class="feeds"><!--one or more-->
   <li><a rel="alternate" type="application/rss+xml" href="URL">RSS
2.0</a></li> <!-- added alternate, type and version as per current
usage-->
   <li><a rel="alternate" type="application/atom+xml" href="URL">Atom
1.0</a></li>
 </ul>
 <span class="description">
 Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
 Internettechniken
 </span>
</div>

Eran.

From craig.ogg at gmail.com  Thu Jul 21 13:02:28 2005
From: craig.ogg at gmail.com (Craig Ogg)
Date: Thu Jul 21 13:02:50 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
Message-ID: <8b18dc205072113025f988dbf@mail.gmail.com>

On reading the specification <http://www.microformats.org/wiki/reltag> to 
things jump out as unclear. Here is a modified version of the example from 
the spec:
  <a href="http://technorati.com/tag/tech" rel="tag">apple</a>
 According to the spec, the actual tag is determined by parsing the URL. In 
the case it would be "tech" and not "apple." This seems to me to lead to 
several problems:

   - Some tagging systems support spaces. How would spaces be supported 
   in this case? My assumption is through replacing spaces with "+", but this 
   is not explicitly stated. 
   - URLs are not the most convenient encoding for non-English languages 
   - Their is no guarantee that the apparent tag (the one displayed to 
   the user) and the real tag are the same. This defeats the peer pressure that 
   is intended. 
   - No guidance is given as to whether or not having different link text 
   and tag value is considered bad form.

Have these things been addressed and are just not mentioned in the wiki or 
am I just not getting it?
 Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050721/7e59a0d4/attachment.htm
From bjoernseibert at gmx.de  Thu Jul 21 13:05:25 2005
From: bjoernseibert at gmx.de (=?ISO-8859-1?Q?Bj=F6rn_Seibert?=)
Date: Thu Jul 21 13:05:29 2005
Subject: [microformats-discuss] Microformat
	for	blog-searchand	characterizing
In-Reply-To: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
Message-ID: <42E00005.2010101@gmx.de>

Eran schrieb:

>Hi Bjorn,
>
>I like the idea of a description for blogs. With all the aggregation
>that's going on right now and the certain growth of that market in the
>future it is a good thing to be learn something about the source of a
>piece of information without too much hassle. I see it as kind of an
>hCard for blogs.
>
>About the proposed format, here's a few possible changes:
>
>  
>
>>-----Original Message-----
>>
>><div class="blogformat">
>>  <img class="logo" src="images/hblog.gif" alt="" /><!--optional-->
>>  <a class="url" href="URL" title="Zum Weblog">Blogname</a>
>>  <span class="language"><em> / DE: </em></span>
>>  <ul class="cat"><!--major categories-->
>>    <li>Webstandards</li>
>>    <li>CSS</li>
>>    <li>XHTML</li>
>> </ul>
>> <ul class="feeds"><!--one or more-->
>>   <li><a href="URL">RSS</a></li>
>>   <li><a href="URL">Atom</a></li>
>> </ul>
>> <span class="description">
>> Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
>> Internettechniken
>> </span>
>></div>
>>
>>    
>>
>
><div class="blogformat" language="de"> <!-- added lanugage attribute, I
>think this is the correct usage... -->
>  <img class="logo" src="http://blog.url/images/hblog.gif" alt="" />
><!-- changed url to absolute rather than relative -->
>  <a class="bookmark" href="URL" title="Zum Weblog">Blogname</a> <!--
>changed class name to bookmark to reflect permalink type -->
>  <a clss="author" href=author.url">author.name</a> <!-- added author
>field, maybe link to an hcard or include one inline? -->
>  <span class="language"><em> / DE: </em></span>
>  <ul class="categories"> <!--changed to categories as used in hreview
>sample-->
>    <li><a rel="tag"
>href="http://technorati.com/Webstandards">Webstandards</a></li> <!--
>changed categories to tags per ryan's suggestion -->
>    <li><a rel="tag" href="http://wikipedia.com/CSS">CSS</a></li>
>    <li><a rel="tag" href="http://wikipedia.com/XHTML">XHTML</a></li>
> </ul>
> <ul class="feeds"><!--one or more-->
>   <li><a rel="alternate" type="application/rss+xml" href="URL">RSS
>2.0</a></li> <!-- added alternate, type and version as per current
>usage-->
>   <li><a rel="alternate" type="application/atom+xml" href="URL">Atom
>1.0</a></li>
> </ul>
> <span class="description">
> Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
> Internettechniken
> </span>
></div>
>
>Eran.
>
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>  
>
Eran, thx for your opinion. Like you've written, it should be an effort 
in the hunt for relevant information about and in blogs. I chose this 
pattern according to the hcard format. I think this set of information 
is the most important to categorize blogs. Other notions out there?

Bj?rn
From rbach at rbach.priv.at  Thu Jul 21 13:16:55 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Thu Jul 21 13:16:35 2005
Subject: [microformats-discuss] Microformat
	for	blog-searchand	characterizing
In-Reply-To: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
Message-ID: <42E002B7.2070609@rbach.priv.at>

Eran wrote:
> <div class="blogformat" language="de"> <!-- added lanugage attribute, I
> think this is the correct usage... -->
It should be for ...
- HTML: <div class="blogformat" lang="de">:
- XHTML 1.0: <div class="blogformat" lang="de" xml:lang="de">
- XHTML 1.1: <div class="blogformat" xml:lang="de">

>   <img class="logo" src="http://blog.url/images/hblog.gif" alt="" />
> <!-- changed url to absolute rather than relative -->

>   <a class="bookmark" href="URL" title="Zum Weblog">Blogname</a> <!--
> changed class name to bookmark to reflect permalink type -->
>   <a clss="author" href=author.url">author.name</a> <!-- added author
> field, maybe link to an hcard or include one inline? -->

>   <span class="language"><em> / DE: </em></span>
I'm not sure if this is acctualy needed. Humans will probably recognize
the language form <span class="descritpion">, machines may look at the
lang attribute of <div class="blogformat">

>   <ul class="categories"> <!--changed to categories as used in hreview
> sample-->
>     <li><a rel="tag"
> href="http://technorati.com/Webstandards">Webstandards</a></li> <!--
> changed categories to tags per ryan's suggestion -->

I think it should be http://technorati.com/tags/Webstandards

>     <li><a rel="tag" href="http://wikipedia.com/CSS">CSS</a></li>
>     <li><a rel="tag" href="http://wikipedia.com/XHTML">XHTML</a></li>
>  </ul>

I think it should be http://wikipedia.org/wiki/XHTML
instead of http://wikipedia.com/XHTML, same for CSS.

>  [...]

>  <span class="description">
>  Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
>  Internettechniken
>  </span>

If "description" is a sentence which explains the topic of the wiki it
using <p> instead of <span> would make sense.


Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From bud at thecommunityengine.com  Thu Jul 21 13:22:34 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 21 13:22:38 2005
Subject: [microformats-discuss] question regarding MF enclosing attributes
Message-ID: <99CCB16C-D9EC-490B-8B91-335D25A81E73@thecommunityengine.com>

Many microformats have a class attribute value indicating that the  
affected element encloses markup belonging to that microformat.  XFN  
uses the URL of its XMDP as this value.  Based on Danny Ayers'  
request for URIs in microformats, one idea was that the XFN practice  
could be extended to other microformats.

Would this indeed be a good or desirable practice?

A very practical motivation for this question is that I am in the  
process of embedding xFolk in an RSS 2.0 feed and would like a  
compact representation to indicate the microformat is in use and  
where information about it can be found.

Bud
From rbach at rbach.priv.at  Thu Jul 21 13:24:35 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Thu Jul 21 13:23:44 2005
Subject: [microformats-discuss]
	Microformat	for	blog-searchand	characterizing
In-Reply-To: <42E002B7.2070609@rbach.priv.at>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
	<42E002B7.2070609@rbach.priv.at>
Message-ID: <42E00483.3070709@rbach.priv.at>

I wrote:
>> <span class="description">
>> Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
>> Internettechniken
>> </span>
> 
> If "description" is a sentence which explains the topic of the wiki it
> using <p> instead of <span> would make sense.
Sorry, this is wrong. I meant:
If "description" is a sentence which explains the topic(s) covered by
the blog, using <p> instead of <span> would make sense.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From bjoernseibert at gmx.de  Thu Jul 21 13:23:54 2005
From: bjoernseibert at gmx.de (=?ISO-8859-1?Q?Bj=F6rn_Seibert?=)
Date: Thu Jul 21 13:24:01 2005
Subject: [microformats-discuss]
	Microformat	for	blog-searchand	characterizing
In-Reply-To: <42E002B7.2070609@rbach.priv.at>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
	<42E002B7.2070609@rbach.priv.at>
Message-ID: <42E0045A.5000601@gmx.de>

Robert Bachmann schrieb:

>Eran wrote:
>  
>
>><div class="blogformat" language="de"> <!-- added lanugage attribute, I
>>think this is the correct usage... -->
>>    
>>
>It should be for ...
>- HTML: <div class="blogformat" lang="de">:
>- XHTML 1.0: <div class="blogformat" lang="de" xml:lang="de">
>- XHTML 1.1: <div class="blogformat" xml:lang="de">
>
>  
>
>>  <img class="logo" src="http://blog.url/images/hblog.gif" alt="" />
>><!-- changed url to absolute rather than relative -->
>>    
>>
>
>  
>
>>  <a class="bookmark" href="URL" title="Zum Weblog">Blogname</a> <!--
>>changed class name to bookmark to reflect permalink type -->
>>  <a clss="author" href=author.url">author.name</a> <!-- added author
>>field, maybe link to an hcard or include one inline? -->
>>    
>>
>
>  
>
>>  <span class="language"><em> / DE: </em></span>
>>    
>>
>I'm not sure if this is acctualy needed. Humans will probably recognize
>the language form <span class="descritpion">, machines may look at the
>lang attribute of <div class="blogformat">
>
>  
>
>>  <ul class="categories"> <!--changed to categories as used in hreview
>>sample-->
>>    <li><a rel="tag"
>>href="http://technorati.com/Webstandards">Webstandards</a></li> <!--
>>changed categories to tags per ryan's suggestion -->
>>    
>>
>
>I think it should be http://technorati.com/tags/Webstandards
>
>  
>
>>    <li><a rel="tag" href="http://wikipedia.com/CSS">CSS</a></li>
>>    <li><a rel="tag" href="http://wikipedia.com/XHTML">XHTML</a></li>
>> </ul>
>>    
>>
>
>I think it should be http://wikipedia.org/wiki/XHTML
>instead of http://wikipedia.com/XHTML, same for CSS.
>
>  
>
>> [...]
>>    
>>
>
>  
>
>> <span class="description">
>> Artikel und Experimente zu Webstandards, CSS, XHTML und Themen der
>> Internettechniken
>> </span>
>>    
>>
>
>If "description" is a sentence which explains the topic of the wiki it
>using <p> instead of <span> would make sense.
>
>
>Robert
>  
>
ok, I'll review it and add the changes you submitted. Thank you. That 
makes sense. I'll post the changed listing again for further discussion.

Bj?rn
From ryan at technorati.com  Thu Jul 21 13:36:42 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 21 13:36:45 2005
Subject: [microformats-discuss] question regarding MF enclosing attributes
In-Reply-To: <99CCB16C-D9EC-490B-8B91-335D25A81E73@thecommunityengine.com>
References: <99CCB16C-D9EC-490B-8B91-335D25A81E73@thecommunityengine.com>
Message-ID: <61165C3B-CC36-4D3B-A866-96BA8C8D771E@technorati.com>

On Jul 21, 2005, at 1:22 PM, Bud Gibson wrote:

> Many microformats have a class attribute value indicating that the  
> affected element encloses markup belonging to that microformat.   
> XFN uses the URL of its XMDP as this value.  Based on Danny Ayers'  
> request for URIs in microformats, one idea was that the XFN  
> practice could be extended to other microformats.
>
> Would this indeed be a good or desirable practice?

Yes. It is a desirable practice, and has always been the plan. And I  
thought we'd covered this issue already?

Other microformats will have profile urls, but only once they are  
solid enough to be standardized.

> A very practical motivation for this question is that I am in the  
> process of embedding xFolk in an RSS 2.0 feed and would like a  
> compact representation to indicate the microformat is in use and  
> where information about it can be found.

As xFolk becomes a standard (ie, calsified), it will need to have a  
profile URL.

-ryan
From kmarks at technorati.com  Thu Jul 21 13:42:43 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Thu Jul 21 13:42:49 2005
Subject: [microformats-discuss] hCard and spam
In-Reply-To: <658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
References: <658C6A65-C416-44FC-AE57-FAA957C70260@elegantchaos.com>
Message-ID: <f9fe61f00b0168d7b890f883cfb6ac1b@technorati.com>


On Jul 21, 2005, at 3:25 AM, Sam Deane wrote:
>
> I think you're fighting a losing battle there. To be of value the 
> information has to be machine readable, and if it's machine readable 
> then the spammers will eventually write a spider to harvest it.

Or they just call X2V on it...

From skeltoac at gmail.com  Thu Jul 21 13:46:41 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Thu Jul 21 13:47:02 2005
Subject: [microformats-discuss] Microformat for blog-searchand
	characterizing
In-Reply-To: <42E0045A.5000601@gmx.de>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
	<42E002B7.2070609@rbach.priv.at> <42E0045A.5000601@gmx.de>
Message-ID: <e6ec604d05072113462f8cd3b4@mail.gmail.com>

On 7/21/05, Bj?rn Seibert <bjoernseibert@gmx.de> wrote:
> ok, I'll review it and add the changes you submitted. Thank you. That
> makes sense. I'll post the changed listing again for further discussion.

This is a very interesting development for me and very well-timed. A
few months ago, I needed to begin adding metadata to other's blogs via
a WordPress plugin. I knew this would be temporary but I needed
something right away so I used something like this:

<meta name='botd:version' content='1.0.1' />
<meta name='botd:generator' content='WordPress 1.5.1.2' />
<meta name='botd:lang' content='' />
<meta name='botd:home' content='http://www.skeltoac.com/' />
<meta name='botd:name' content='Skeltoac' />
<meta name='botd:desc' content='The personal and impersonal journal of
Andy Skelton.' />

I suggest using a discreet element, perhaps <span
class="sitename">Doodz-R-Uz</span> that could be within or without the
"bookmark" anchor, to indicate the site name. "Generator" would be
optional. We might also define "founded" and "updated" dates as
optional.

Andy Skelton

http://www.skeltoac.com
http://blogsoftheday.com
From bud at thecommunityengine.com  Thu Jul 21 13:51:44 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 21 13:51:48 2005
Subject: [microformats-discuss] question regarding MF enclosing attributes
In-Reply-To: <61165C3B-CC36-4D3B-A866-96BA8C8D771E@technorati.com>
References: <99CCB16C-D9EC-490B-8B91-335D25A81E73@thecommunityengine.com>
	<61165C3B-CC36-4D3B-A866-96BA8C8D771E@technorati.com>
Message-ID: <5313AC01-CC5E-4075-912C-076EBDA1E845@thecommunityengine.com>

On Jul 21, 2005, at 16:36, Ryan King wrote:


> Yes. It is a desirable practice, and has always been the plan. And  
> I thought we'd covered this issue already?
>

Indeed, I knew it was an issue that was raised.  What was unclear to  
me was any decision about the mechanism that one would use.  Further,  
since other microformats (e.g., hCard) do not necessarily use this  
mechanism, it was unclear that it was one to strive for.

Ryan, not trying to be difficult, just asking for a clarification.   
Lighten up.


>
> Other microformats will have profile urls, but only once they are  
> solid enough to be standardized.
>
>
>
>> A very practical motivation for this question is that I am in the  
>> process of embedding xFolk in an RSS 2.0 feed and would like a  
>> compact representation to indicate the microformat is in use and  
>> where information about it can be found.
>>
>>
>
> As xFolk becomes a standard (ie, calsified), it will need to have a  
> profile URL.
>

xfolk has a profile URL and has had one from the outset.  I'm now  
using the one on the wiki.  It has a version and everything.

>
>


From bud at thecommunityengine.com  Thu Jul 21 13:52:11 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 21 13:52:14 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
In-Reply-To: <8b18dc205072113025f988dbf@mail.gmail.com>
References: <8b18dc205072113025f988dbf@mail.gmail.com>
Message-ID: <8288305A-69CA-4DBB-B040-57C1B0A61AF4@thecommunityengine.com>

Hi Craig:

Please stick with text (not html) on the list.  Let me see if I can  
address some of these issues as I have wrestled with them recently:


>> How would spaces be supported in this case?   My assumption is  
>> through replacing spaces with "+", but this is not explicitly stated.
>>

Perhaps somewhat implicit in the spec is that you would use standard  
URL encoding practices.  It is after all a URL.


>> URLs are not the most convenient encoding for non-English languages
>>

And not always for English.  One of the motivations in the spec (per  
my very limited understanding) is that the tag point at a specific  
repository about items on that topic.  Making the tag be part of the  
URL helps guarantee this.

At the aggregator level, making the tag explicitly part of the URL  
also helps fight SPAM tagging since the tag is part of the pointer  
(see next).


>> Their is no guarantee that the apparent tag (the one displayed to  
>> the user) and the real tag are the same.  This defeats the peer  
>> pressure that is intended.
>>

The peer pressure comes at the aggregator level  Aggregators  
aggregate links based on the value in the URL not the link text.   
SPAM can then be reported if the tag is not accurate, and the  
perpetrating site is also immediately ID'd.  At individual sites, you  
are clearly in caveat emptor mode.


>> No guidance is given as to whether or not having different link  
>> text and tag value is considered bad form.
>>

For the most part, people make the two match.  The link text tends to  
be a readable form of the tag.  Having spoken with the spec authors,  
they indicate that not following this practice is also possible.  I'm  
not sure what the use case is though.


>> Have these things been addressed and are just not mentioned in the  
>> wiki or am I just not getting it?
>>

Have you looked at the technorati or IceRocket help pages for tags?

On Jul 21, 2005, at 16:02, Craig Ogg wrote:


> On reading the specification to things jump out as unclear.  Here  
> is a modified version of the example from the spec:
>
>      <a href="http://technorati.com/tag/tech" rel="tag">apple</a>
>
> According to the spec, the actual tag is determined by parsing the  
> URL. In the case it would be "tech" and not "apple."  This seems to  
> me to lead to several problems:
> Some tagging systems support spaces.  How would spaces be supported  
> in this case?   My assumption is through replacing spaces with "+",  
> but this is not explicitly stated.
> URLs are not the most convenient encoding for non-English languages
> Their is no guarantee that the apparent tag (the one displayed to  
> the user) and the real tag are the same.  This defeats the peer  
> pressure that is intended.
> No guidance is given as to whether or not having different link  
> text and tag value is considered bad form.
> Have these things been addressed and are just not mentioned in the  
> wiki or am I just not getting it?
>
> Craig
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>


From bjoernseibert at gmx.de  Thu Jul 21 13:53:23 2005
From: bjoernseibert at gmx.de (=?ISO-8859-1?Q?Bj=F6rn_Seibert?=)
Date: Thu Jul 21 13:53:26 2005
Subject: [microformats-discuss]
	Microformat	for	blog-searchand	characterizing
In-Reply-To: <42E002B7.2070609@rbach.priv.at>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>
	<42E002B7.2070609@rbach.priv.at>
Message-ID: <42E00B43.1080709@gmx.de>

Hi, I made the submitted changes to the markup:

<div class="blogformat" language="de"><!--humans will guess and machines will look it up-->
    <img class="logo" src="URLtoIMAGE(absolute)" alt="" /><!--optional-->
    <a class="bookmark" href="URLtoBlog" title="Zum Weblog">Blog Name</a>
    <ul class="categories"><!--major categories-->
      <li><a rel="tag" href="http://technorati.com/tags/Webstandards">Webstandards</a></li>
      <li><a rel="tag" href="http://technorati.com/tags/css">CSS</a></li>
      <li><a rel="tag" href="http://technorati.com/tags/xhtml">XHTML</a></li>
    </ul>
    <ul class="feeds"><!--one or more-->
      <li><a href="URLtoFEED">RSS</a></li>
      <li><a href="URLtoFEED">Atom</a></li>
    </ul>
    <p class="description">Webstandards, CSS, XHTML und Themen aus dem Bereich der Webentwicklung</p>
    <!--describes the topics of the blog--> 
</div>

Bj?rn


From bjoernseibert at gmx.de  Thu Jul 21 14:06:11 2005
From: bjoernseibert at gmx.de (=?ISO-8859-1?Q?Bj=F6rn_Seibert?=)
Date: Thu Jul 21 14:06:16 2005
Subject: [microformats-discuss] Microformat for
	blog-searchand	characterizing
In-Reply-To: <e6ec604d05072113462f8cd3b4@mail.gmail.com>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>	<42E002B7.2070609@rbach.priv.at>
	<42E0045A.5000601@gmx.de>
	<e6ec604d05072113462f8cd3b4@mail.gmail.com>
Message-ID: <42E00E43.7010407@gmx.de>

Andy Skelton schrieb:

>On 7/21/05, Bj?rn Seibert <bjoernseibert@gmx.de> wrote:
>  
>
>>ok, I'll review it and add the changes you submitted. Thank you. That
>>makes sense. I'll post the changed listing again for further discussion.
>>    
>>
>
>This is a very interesting development for me and very well-timed. A
>few months ago, I needed to begin adding metadata to other's blogs via
>a WordPress plugin. I knew this would be temporary but I needed
>something right away so I used something like this:
>
><meta name='botd:version' content='1.0.1' />
><meta name='botd:generator' content='WordPress 1.5.1.2' />
><meta name='botd:lang' content='' />
><meta name='botd:home' content='http://www.skeltoac.com/' />
><meta name='botd:name' content='Skeltoac' />
><meta name='botd:desc' content='The personal and impersonal journal of
>Andy Skelton.' />
>
>I suggest using a discreet element, perhaps <span
>class="sitename">Doodz-R-Uz</span> that could be within or without the
>"bookmark" anchor, to indicate the site name. "Generator" would be
>optional. We might also define "founded" and "updated" dates as
>optional.
>
>Andy Skelton
>
>http://www.skeltoac.com
>http://blogsoftheday.com
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>  
>
Andy, the blogname would be within the bookmark anchor. Generator as 
optional info is a good idea. Founded is not a neccessary information 
for potential readers, I think. But I like the idea of updated piece.

Bj?rn
From ryan at technorati.com  Thu Jul 21 14:08:59 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 21 14:09:05 2005
Subject: [microformats-discuss] question regarding MF enclosing attributes
In-Reply-To: <5313AC01-CC5E-4075-912C-076EBDA1E845@thecommunityengine.com>
References: <99CCB16C-D9EC-490B-8B91-335D25A81E73@thecommunityengine.com>
	<61165C3B-CC36-4D3B-A866-96BA8C8D771E@technorati.com>
	<5313AC01-CC5E-4075-912C-076EBDA1E845@thecommunityengine.com>
Message-ID: <7D7DE4AB-60F2-4221-A7EB-00A09B42EF58@technorati.com>

On Jul 21, 2005, at 1:51 PM, Bud Gibson wrote:
> On Jul 21, 2005, at 16:36, Ryan King wrote:
>> Yes. It is a desirable practice, and has always been the plan. And  
>> I thought we'd covered this issue already?
>
> Indeed, I knew it was an issue that was raised.  What was unclear  
> to me was any decision about the mechanism that one would use.

<link rel="profile" ..>
<a rel="profile" ..>

>   Further, since other microformats (e.g., hCard) do not  
> necessarily use this mechanism, it was unclear that it was one to  
> strive for.

You mean "don't *yet* have a profile URL to reference." They use this  
mechanism, there's just not a profile URL yet. Remember, XFN has an  
almost *2 year* head start on the rest of the formats. That's like  
2,000 years in Internet Time. :)

You have to remember that these formats are still very much in draft  
stage and as such they can't be easily given profile URLs (because  
you may need a new profile url for each revision of the spec .... and  
some don't even have profiles yet!).

> Ryan, not trying to be difficult, just asking for a clarification.   
> Lighten up.

This is me light. :)

>> Other microformats will have profile urls, but only once they are  
>> solid enough to be standardized.
>>
>>> A very practical motivation for this question is that I am in the  
>>> process of embedding xFolk in an RSS 2.0 feed and would like a  
>>> compact representation to indicate the microformat is in use and  
>>> where information about it can be found.
>>
>> As xFolk becomes a standard (ie, calsified), it will need to have  
>> a profile URL.
>
> xfolk has a profile URL and has had one from the outset.  I'm now  
> using the one on the wiki.  It has a version and everything.

Where is this?

-ryan
From ryan at technorati.com  Thu Jul 21 14:16:36 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 21 14:16:44 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
In-Reply-To: <8288305A-69CA-4DBB-B040-57C1B0A61AF4@thecommunityengine.com>
References: <8b18dc205072113025f988dbf@mail.gmail.com>
	<8288305A-69CA-4DBB-B040-57C1B0A61AF4@thecommunityengine.com>
Message-ID: <799A9C8D-429C-473C-BEFA-DDF10927F6A7@technorati.com>

On Jul 21, 2005, at 1:52 PM, Bud Gibson wrote:
> Hi Craig:
>
> Please stick with text (not html) on the list.  Let me see if I can  
> address some of these issues as I have wrestled with them recently:
>
>>> How would spaces be supported in this case?   My assumption is  
>>> through replacing spaces with "+", but this is not explicitly  
>>> stated.
>
> Perhaps somewhat implicit in the spec is that you would use  
> standard URL encoding practices.  It is after all a URL.

Yes, spaces can be encoded with a %20, just like any other URL.

>>> URLs are not the most convenient encoding for non-English languages

I'm not sure what exactly the issue is here. If you take a look at  
http://technorati.com/tags/?showall=1 you'll see that plenty of non- 
english speakers use rel-tag. Please let us know what you have in  
mind here.

> And not always for English.  One of the motivations in the spec  
> (per my very limited understanding) is that the tag point at a  
> specific repository about items on that topic.  Making the tag be  
> part of the URL helps guarantee this.
>
> At the aggregator level, making the tag explicitly part of the URL  
> also helps fight SPAM tagging since the tag is part of the pointer  
> (see next).
>
>>> Their is no guarantee that the apparent tag (the one displayed to  
>>> the user) and the real tag are the same.  This defeats the peer  
>>> pressure that is intended.

Not really. You can still see the link onhover and if you click on  
the link you'll see that it was not what the link-text indicated.

> The peer pressure comes at the aggregator level  Aggregators  
> aggregate links based on the value in the URL not the link text.   
> SPAM can then be reported if the tag is not accurate, and the  
> perpetrating site is also immediately ID'd.  At individual sites,  
> you are clearly in caveat emptor mode.
>
>>> No guidance is given as to whether or not having different link  
>>> text and tag value is considered bad form.
>
> For the most part, people make the two match.

Yes, most people make this identical, esp. when doing a list of tags.

OTOH, when doing inline tags, it is often beneficial to give a  
different text to the link (though usually synonymous). Look, for  
example at http://cs.usfca.edu/~rking/resume.html where I use tags to  
describe my skills. In several cases the text of the tag link is not  
identical to the tag, but it is often synonymous (b/c that's the best  
wikipedia page I could find).

>   The link text tends to be a readable form of the tag.  Having  
> spoken with the spec authors, they indicate that not following this  
> practice is also possible.

And is, at times, desirable.

>   I'm not sure what the use case is though.

See my resume example above.

>>> Have these things been addressed and are just not mentioned in  
>>> the wiki or am I just not getting it?
>
> Have you looked at the technorati or IceRocket help pages for tags?

No need to look at both.

-ryan

> On Jul 21, 2005, at 16:02, Craig Ogg wrote:
>
>> On reading the specification to things jump out as unclear.  Here  
>> is a modified version of the example from the spec:
>>
>>      <a href="http://technorati.com/tag/tech" rel="tag">apple</a>
>>
>> According to the spec, the actual tag is determined by parsing the  
>> URL. In the case it would be "tech" and not "apple."  This seems  
>> to me to lead to several problems:
>> Some tagging systems support spaces.  How would spaces be  
>> supported in this case?   My assumption is through replacing  
>> spaces with "+", but this is not explicitly stated.
>> URLs are not the most convenient encoding for non-English languages
>> Their is no guarantee that the apparent tag (the one displayed to  
>> the user) and the real tag are the same.  This defeats the peer  
>> pressure that is intended.
>> No guidance is given as to whether or not having different link  
>> text and tag value is considered bad form.
>> Have these things been addressed and are just not mentioned in the  
>> wiki or am I just not getting it?
>>
>> Craig

From rbach at rbach.priv.at  Thu Jul 21 14:26:24 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Thu Jul 21 14:25:34 2005
Subject: [microformats-discuss]	Microformat	for	blog-searchand	characterizing
In-Reply-To: <42E00B43.1080709@gmx.de>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>	<42E002B7.2070609@rbach.priv.at>
	<42E00B43.1080709@gmx.de>
Message-ID: <42E01300.3020502@rbach.priv.at>

Bj?rn Seibert wrote:
> Hi, I made the submitted changes to the markup:
> 
> <div class="blogformat" language="de">
It's lang or xml:lang not language.

> [...]
>      <li><a href="URLtoFEED">RSS</a></li>
>      <li><a href="URLtoFEED">Atom</a></li>
Attribute "type" should be given.

I have created a page on the wiki[1] and included you - fixed - example
there.

Robert

[1] http://microformats.org/wiki/blog-description-format
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From craig.ogg at gmail.com  Thu Jul 21 14:26:20 2005
From: craig.ogg at gmail.com (Craig Ogg)
Date: Thu Jul 21 14:26:45 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
In-Reply-To: <8288305A-69CA-4DBB-B040-57C1B0A61AF4@thecommunityengine.com>
References: <8b18dc205072113025f988dbf@mail.gmail.com>
	<8288305A-69CA-4DBB-B040-57C1B0A61AF4@thecommunityengine.com>
Message-ID: <8b18dc2050721142671aae893@mail.gmail.com>

Thanks, this makes things clearer.  Comments below.

> >> How would spaces be supported in this case?   My assumption is
> >> through replacing spaces with "+", but this is not explicitly stated.
> >>
> 
> Perhaps somewhat implicit in the spec is that you would use standard
> URL encoding practices.  It is after all a URL.
> 

This makes sense.  Given the intent for end user's to be able use this
microformat (to be able to tag if there software doesn't support it)
it would probably be helpful if the spec were explicit in this case.

> >> No guidance is given as to whether or not having different link
> >> text and tag value is considered bad form.
> >>
> 
> For the most part, people make the two match.  The link text tends to
> be a readable form of the tag.  Having spoken with the spec authors,
> they indicate that not following this practice is also possible.  I'm
> not sure what the use case is though.
> 

The only one that comes to mind is to deal with special purpose tags
like event based tags.  Asking everyone to tag your event as SXSW05
but use "South by Southwest 2005" as the link text would boost the tag
repository's ranking for that search query (if my understanding of
natural search is correct).

> Have you looked at the technorati or IceRocket help pages for tags?
> 

Yes.  They say: "The [tagname] can be anything, but it should be
descriptive. Please only use tags that are relevant to the post. You
do not need to include the brackets, just the descriptive *keyword*
for your post."  (Emphasis mine).  They definitely give the impression
that only single words are supported and are silent about how to deal
with multi-word tags or whether or not they are even "allowed."

Thanks for your help.

Craig
From bjoernseibert at gmx.de  Thu Jul 21 14:37:44 2005
From: bjoernseibert at gmx.de (=?ISO-8859-1?Q?Bj=F6rn_Seibert?=)
Date: Thu Jul 21 14:37:48 2005
Subject: [microformats-discuss]	Microformat	for	blog-searchand	characterizing
In-Reply-To: <42E01300.3020502@rbach.priv.at>
References: <00a501c58e2e$410f9ff0$6402a8c0@hellonwheels>	<42E002B7.2070609@rbach.priv.at>	<42E00B43.1080709@gmx.de>
	<42E01300.3020502@rbach.priv.at>
Message-ID: <42E015A8.9030007@gmx.de>

Robert Bachmann schrieb:

>Bj?rn Seibert wrote:
>  
>
>>Hi, I made the submitted changes to the markup:
>>
>><div class="blogformat" language="de">
>>    
>>
>It's lang or xml:lang not language.
>
>  
>
>>[...]
>>     <li><a href="URLtoFEED">RSS</a></li>
>>     <li><a href="URLtoFEED">Atom</a></li>
>>    
>>
>Attribute "type" should be given.
>
>I have created a page on the wiki[1] and included you - fixed - example
>there.
>
>Robert
>
>[1] http://microformats.org/wiki/blog-description-format
>  
>
Hey Robert, thank you for assistance and the entry in the wiki! So I'll 
add some more info about the intention and description of the Elements.

Bj?rn
From bud at thecommunityengine.com  Thu Jul 21 14:46:22 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 21 14:46:27 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
In-Reply-To: <799A9C8D-429C-473C-BEFA-DDF10927F6A7@technorati.com>
References: <8b18dc205072113025f988dbf@mail.gmail.com>
	<8288305A-69CA-4DBB-B040-57C1B0A61AF4@thecommunityengine.com>
	<799A9C8D-429C-473C-BEFA-DDF10927F6A7@technorati.com>
Message-ID: <E9B5FDF9-32C6-48A6-9BEC-69E9BB7075B4@thecommunityengine.com>

On Jul 21, 2005, at 17:16, Ryan King wrote:



> OTOH, when doing inline tags, it is often beneficial to give a  
> different text to the link (though usually synonymous). Look, for  
> example at http://cs.usfca.edu/~rking/resume.html where I use tags  
> to describe my skills. In several cases the text of the tag link is  
> not identical to the tag, but it is often synonymous (b/c that's  
> the best wikipedia page I could find).
>
>
>

Thanks for the example, but the question it raises in my mind is what  
is being tagged.  Generally, when used outside of a microformatted  
context, the scope of what reltag applies to appears to be the whole  
page.  At least, that is my read of the spec documents.

What you are describing here is just a convenience for tagging the  
whole resume document.  Is that correct?

Bud


From kmarks at technorati.com  Thu Jul 21 15:34:11 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Thu Jul 21 15:34:15 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
In-Reply-To: <8b18dc205072113025f988dbf@mail.gmail.com>
References: <8b18dc205072113025f988dbf@mail.gmail.com>
Message-ID: <47ddb9dc11363b9e03fe2696897c6bc0@technorati.com>


On Jul 21, 2005, at 1:02 PM, Craig Ogg wrote:

> On reading the specification to things jump out as unclear.? Here is a 
> modified version of the example from the spec:
> ?
> ???? <a href="http://technorati.com/tag/tech" rel="tag">apple</a>
> ?
> According to the spec, the actual tag is determined by parsing the 
> URL. In the case it would be "tech" and not "apple."? This seems to me 
> to lead to several problems:
> 	? 	Some tagging systems support spaces.? How would spaces be 
> supported in this case??? My assumption is through replacing spaces 
> with "+", but this is not explicitly stated.

Either '+' or %20 is legitimate - the Technorati spider supports plain 
spaces in the url too, but this is a Postel's law implementation, not 
recommended behaviour.

> 	? 	URLs are not the most convenient encoding for non-English languages

Encoding non-english languages in URLs is clearly specified in RFC 
3986. I've updated the spec to clarify this - thanks for the feedback. 
(tip - the technorati tags pages will show you the right URL for any 
unicode you type in)

From craig.ogg at gmail.com  Thu Jul 21 16:58:01 2005
From: craig.ogg at gmail.com (Craig Ogg)
Date: Thu Jul 21 16:58:49 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
In-Reply-To: <47ddb9dc11363b9e03fe2696897c6bc0@technorati.com>
References: <8b18dc205072113025f988dbf@mail.gmail.com>
	<47ddb9dc11363b9e03fe2696897c6bc0@technorati.com>
Message-ID: <8b18dc2050721165864591047@mail.gmail.com>

Okay, after some more experimentation I am confused.  In looking at
encodings, I did a technorati query for News & Politics
(http://www.technorati.com/tag/News%20&%20politics).  The first item
that came up was http://www.zigguratofdoom.com/?p=632.

I went and did a view source on that page to see how the tag had been
coded.  It appears that this is the coding:

<a href="http://www.zigguratofdoom.com/index.php?cat=13" title="View
all posts in News &#038; Politics" rel="category tag">News &#038;
Politics</a>

In this case, it appears that the link text rather than the URL was
the source of the tag.  Is this another case of handling what is out
there rather than following the spec or is the link text what is
actually used?

BTW, allowing "+" for space really messes up us C++ programmers
looking for blog entries. :-)

Craig
From tantek at cs.stanford.edu  Thu Jul 21 17:36:30 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Thu Jul 21 17:36:47 2005
Subject: [microformats-discuss] Microformat for blog-searchand
	characterizing
In-Reply-To: <e6ec604d05072113462f8cd3b4@mail.gmail.com>
Message-ID: <BF058D87.5D7AD%tantek@cs.stanford.edu>

On 7/21/05 1:46 PM, "Andy Skelton" <skeltoac@gmail.com> wrote:

> On 7/21/05, Bj?rn Seibert <bjoernseibert@gmx.de> wrote:
>> ok, I'll review it and add the changes you submitted. Thank you. That
>> makes sense. I'll post the changed listing again for further discussion.
> 
> This is a very interesting development for me and very well-timed. A
> few months ago, I needed to begin adding metadata to other's blogs via
> a WordPress plugin. I knew this would be temporary but I needed
> something right away so I used something like this:
> 
> <meta name='botd:version' content='1.0.1' />
> <meta name='botd:generator' content='WordPress 1.5.1.2' />
> <meta name='botd:lang' content='' />
> <meta name='botd:home' content='http://www.skeltoac.com/' />
> <meta name='botd:name' content='Skeltoac' />
> <meta name='botd:desc' content='The personal and impersonal journal of
> Andy Skelton.' />

This is definitely a pattern encouraged by the HTML specification (except
for the namespacing "botd:").

However, this kind of use of <meta> is for the most part not much different
in mechanism from meta keywords, and is thus has all the same
vulnerabilities.

In short, invisible metadata works in small experiments, maybe even just
among small crowds of people, but when it goes mainstream, the signal
inevitably deteriorates to noise.  More on this:

 http://tantek.com/log/2005/06.html#d03t2359

and about halfway down on this page:

 http://knowledge.wharton.upenn.edu/index.cfm?fa=viewArticle&id=1247&special
Id=38


> I suggest using a discreet element, perhaps <span
> class="sitename">Doodz-R-Uz</span>

Why not simply use the <title> in the HTML?


> "Generator" would be
> optional.

Perhaps there could even be a separate "generator" microformat, which would
make sense as an annotation on the *visible* "Built with XYZ" images/buttons
that people put on their sites.  I think "generator" goes beyond just
blogging.


> We might also define "founded" and "updated" dates as
> optional.

I would suggest looking at the schemas in both ATOM and RSS as far as blog
related datetime information.

Thanks,

Tantek

From kmarks at technorati.com  Thu Jul 21 19:03:54 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Thu Jul 21 19:03:59 2005
Subject: [microformats-discuss] Ambiguities in reltag specification
In-Reply-To: <8b18dc2050721165864591047@mail.gmail.com>
References: <8b18dc205072113025f988dbf@mail.gmail.com>
	<47ddb9dc11363b9e03fe2696897c6bc0@technorati.com>
	<8b18dc2050721165864591047@mail.gmail.com>
Message-ID: <4e5587f1e38134dfb371e3a5b84d5f67@technorati.com>


On Jul 21, 2005, at 4:58 PM, Craig Ogg wrote:

> Okay, after some more experimentation I am confused.  In looking at
> encodings, I did a technorati query for News & Politics
> (http://www.technorati.com/tag/News%20&%20politics).  The first item
> that came up was http://www.zigguratofdoom.com/?p=632.
>
> I went and did a view source on that page to see how the tag had been
> coded.  It appears that this is the coding:
>
> <a href="http://www.zigguratofdoom.com/index.php?cat=13" title="View
> all posts in News &#038; Politics" rel="category tag">News &#038;
> Politics</a>
>
> In this case, it appears that the link text rather than the URL was
> the source of the tag.  Is this another case of handling what is out
> there rather than following the spec or is the link text what is
> actually used?

The technorati tags code also indexes the <category> element of RSS and 
Atom feeds, as well as <dc:subject>

That use of tag is invalid, and is based on a bug in some versions of 
WordPress. If WordPress has mod-rewrite support for categories on, that 
would have a valid tag url.

From ryan at technorati.com  Thu Jul 21 20:13:27 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 21 20:13:30 2005
Subject: [microformats-discuss] Microformat for blog-searchand
	characterizing
In-Reply-To: <BF058D87.5D7AD%tantek@cs.stanford.edu>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>
Message-ID: <6B312736-5207-49AB-BBFF-15B358BAB7F0@technorati.com>

On Jul 21, 2005, at 5:36 PM, Tantek ?elik wrote:
> Perhaps there could even be a separate "generator" microformat,  
> which would
> make sense as an annotation on the *visible* "Built with XYZ"  
> images/buttons
> that people put on their sites.  I think "generator" goes beyond just
> blogging.

perhaps a rel="generator" ?


-ryan
From skeltoac at gmail.com  Thu Jul 21 21:21:10 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Thu Jul 21 21:21:49 2005
Subject: [microformats-discuss] Microformat for blog-searchand
	characterizing
In-Reply-To: <BF058D87.5D7AD%tantek@cs.stanford.edu>
References: <e6ec604d05072113462f8cd3b4@mail.gmail.com>
	<BF058D87.5D7AD%tantek@cs.stanford.edu>
Message-ID: <e6ec604d050721212171acaa94@mail.gmail.com>

On 7/21/05, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> On 7/21/05 1:46 PM, "Andy Skelton" <skeltoac@gmail.com> wrote:
> > <meta name='botd:name' content='Skeltoac' />
> > <meta name='botd:desc' content='The personal and impersonal journal of
> > Andy Skelton.' />
> 
> This is definitely a pattern encouraged by the HTML specification (except
> for the namespacing "botd:").

Yes, I threw it together as a temporary solution. I want to scrap it,
which is why this thread is exciting for me.

> > I suggest using a discreet element, perhaps <span
> > class="sitename">Doodz-R-Uz</span>
> 
> Why not simply use the <title> in the HTML?

<title> is usually used for other purposes than solely the name of the
site. Front pages will have keywords thrown in the <title> for SEO and
deeper pages will have page names, post titles, keywords, you name it.
<title> is almost never equal to site name.

> > "Generator" would be
> > optional.
> 
> Perhaps there could even be a separate "generator" microformat, which would
> make sense as an annotation on the *visible* "Built with XYZ" images/buttons
> that people put on their sites.  I think "generator" goes beyond just
> blogging.

You brink up a very good point here. I do not know how many people
consciously apply generator info to their visible designs. Many
mainstream packages use <meta name="generator"> to silently mark their
pages. This bypasses an author tendency to remove programatic
attribution from their visible designs. I wouldn't count on people to
design sites with visible generator info. If it's not there by
default, it probably won't be written in.

> > We might also define "founded" and "updated" dates as
> > optional.
> 
> I would suggest looking at the schemas in both ATOM and RSS as far as blog
> related datetime information.

I'll check into that.

Thank you,
Andy Skelton
From tantek at cs.stanford.edu  Fri Jul 22 01:20:25 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Jul 22 01:20:32 2005
Subject: [microformats-discuss] question regarding MF enclosing attributes
In-Reply-To: <99CCB16C-D9EC-490B-8B91-335D25A81E73@thecommunityengine.com>
Message-ID: <BF05926E.5D7B5%tantek@cs.stanford.edu>

On 7/21/05 1:22 PM, "Bud Gibson" <bud@thecommunityengine.com> wrote:

> Many microformats have a class attribute value indicating that the
> affected element encloses markup belonging to that microformat.

Rather, is an object as defined in that microformat specification.  E.g.
hCard defines that elements with a class name of "vcard" indicate an
hCard/vCard object.


> XFN  
> uses the URL of its XMDP as this value.

Not quite.

XFN is a simple elemental microformat which uses the 'rel' attribute on
hyperlinks.  That's it.


Both hCard *and* XFN have XMDP profiles which SHOULD be referenced by the
'profile' attribute on the <head> element per XMDP.

There are some ideas/thoughts/proposals to extend this to allow additional
ways of specifying which profile(s) are in use by the content, and those
proposals are under consideration for a future revision of XMDP.


> A very practical motivation for this question is that I am in the
> process of embedding xFolk in an RSS 2.0 feed and would like a
> compact representation to indicate the microformat is in use and
> where information about it can be found.

Bud, that is an excellent specific use case, and that's exactly the kind of
thing we need to distinguish endless academic wishlists from practical
implementation needs. I've added it to the wiki.

For now, I suggest simply embedding the xFolk in the RSS 2.0 feed and see
how it works.  See what *practical* problems you run into (if any), and
please report back!

Thanks,

Tantek

From bjoernseibert at gmx.de  Fri Jul 22 02:56:45 2005
From: bjoernseibert at gmx.de (=?ISO-8859-1?Q?Bj=F6rn_Seibert?=)
Date: Fri Jul 22 02:56:53 2005
Subject: [microformats-discuss] Microformat for
	blog-searchand	characterizing
In-Reply-To: <e6ec604d050721212171acaa94@mail.gmail.com>
References: <e6ec604d05072113462f8cd3b4@mail.gmail.com>	<BF058D87.5D7AD%tantek@cs.stanford.edu>
	<e6ec604d050721212171acaa94@mail.gmail.com>
Message-ID: <42E0C2DD.4080701@gmx.de>

Good morning,

><title> is usually used for other purposes than solely the name of the
>site. Front pages will have keywords thrown in the <title> for SEO and
>deeper pages will have page names, post titles, keywords, you name it.
><title> is almost never equal to site name.
>
>  
>
But in case of the front page it should be only the title of the 
website/blog. Page topic, keywords and description provide other (SEO) 
information. But I also see a problem in using the <title> because 
unfortunately it's used for other purposes regarding SEO, too.

So there's no other way than placing this piece of information within 
the format. The title-attribute within the achor to the blog, as Robert 
Bachmann submitted, would be a good practice.

<a class="bookmark" href="http://example.org/blog" title="Blog name">Blog name</a>


Bj?rn

>>>"Generator" would be
>>>optional.
>>>      
>>>
>>Perhaps there could even be a separate "generator" microformat, which would
>>make sense as an annotation on the *visible* "Built with XYZ" images/buttons
>>that people put on their sites.  I think "generator" goes beyond just
>>blogging.
>>    
>>
>
>You brink up a very good point here. I do not know how many people
>consciously apply generator info to their visible designs. Many
>mainstream packages use <meta name="generator"> to silently mark their
>pages. This bypasses an author tendency to remove programatic
>attribution from their visible designs. I wouldn't count on people to
>design sites with visible generator info. If it's not there by
>default, it probably won't be written in.
>
>  
>
>>>We might also define "founded" and "updated" dates as
>>>optional.
>>>      
>>>
>>I would suggest looking at the schemas in both ATOM and RSS as far as blog
>>related datetime information.
>>    
>>
>
>I'll check into that.
>
>Thank you,
>Andy Skelton
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>  
>

From rbach at rbach.priv.at  Fri Jul 22 04:36:25 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Jul 22 04:35:46 2005
Subject: [microformats-discuss] Deprecated XHTML attributes/tags and
	Microformats
Message-ID: <42E0DA39.4040408@rbach.priv.at>

Should we try to avoid using deprecated attributes and tags in
microformat specifications, or must we avoid them?

My specific problem is the notation of the used language:

In HTML 4.01 the lang attribute is used.
In XHTML 1.0 the lang or the xml:lang attribute may be used, but lang is
deprecated. In XHTML 1.1 the lang attribute was removed.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From tantek at cs.stanford.edu  Fri Jul 22 05:02:31 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Jul 22 05:02:36 2005
Subject: [microformats-discuss] Deprecated XHTML attributes/tags and
	Microformats
In-Reply-To: <42E0DA39.4040408@rbach.priv.at>
Message-ID: <BF062E44.5D801%tantek@cs.stanford.edu>

On 7/22/05 4:36 AM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:

> Should we try to avoid using deprecated attributes and tags in
> microformat specifications, or must we avoid them?

I think we *should* avoid them, but not *must*.

There may be exceptions (e.g. 'compact' in XOXO) which make sense.


> My specific problem is the notation of the used language:
> 
> In HTML 4.01 the lang attribute is used.
> In XHTML 1.0 the lang or the xml:lang attribute may be used, but lang is
> deprecated. In XHTML 1.1 the lang attribute was removed.

AFAIK, the 'lang' attribute is the most broadly interoperably supported
(e.g. for the :lang() selector), and therefore from the perspective of
microformat principle of reusing widely interoperably implemented standards,
IMHO the 'lang' attribute is preferred, though there is a good argument to
be made for using *both* the lang and xml:lang attributes which *must* have
the same value.

Thanks,

Tantek

From rbach at rbach.priv.at  Fri Jul 22 09:44:06 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Fri Jul 22 09:43:21 2005
Subject: [microformats-discuss] Comments on robot exclusion
In-Reply-To: <42DDAB1F.1090802@peterjanes.ca>
References: <42DD8B73.6060207@rbach.priv.at> <42DDAB1F.1090802@peterjanes.ca>
Message-ID: <42E12256.4030902@rbach.priv.at>

Peter Janes wrote:
> I think that might be overkill, considering the example page at
> http://peterjanes.ca/2005/robots/example does something very similar
> already using only CSS styles and a little bit of JavaScript to toggle
> them.

I have tried to display "noarchive" with a grey background color.
Displaying it with font-style: italic, isn't very usable because
<em> and <i> will be rendered also in italics.
See <http://rbach.priv.at/Misc/2005/REP/GreyForNoArchive>.

I have some comments on the issues of REP.

| Should earlier values take precedence or later? Does
| class="robots-nofollow robots-follow" means the same as
| class="robots-nofollow" or class="robots-follow"?

I think that the later value should have precedence, because it seems
more user-friendly to me.
This is because of the way I think about HTML. Although it isn't
a programming language I read, write and understand it as a sort-of
programming language.

If I wanted to translate >>class="robots-nofollow"<< to C++ I would write:
robot_follow = 0;

If I wanted to translate >>class="robots-follow"<< to C++ I would write:
robot_follow = 1;

If I wanted to translate >>class="robots-nofollow robots-follow"<<
in C++ I would write:
robot_follow = 0;
robot_follow = 1;

This two lines of C++ code would result into robot_follow having
the value 1.
So if C++ does it that way, REP should do it in the same way ;-) or
should forbid contradictory values.

| Interaction with relnofollow: what does class="robots-follow"
| rel="nofollow" mean? Currently relnofollow has no profile URI defined,
| so the Robot Exclusion Profile takes precedence.

I don't think this is an issue.

Consider the following examples:

<a class="robots-nofollow" href="http://example.com/">foo</a></p>
Obviously means: "Don't follow this link."

<a class="robots-nofollow" rel="nofollow"
   href="http://example.com/">foo</a>
Obviously means the same: "Don't follow this link."

<a class="robots-follow" rel="nofollow"
   href="http://example.com/">foo</a>
I think this means:
- You may follow this link [robots-follow]
but
- if follow it don't add any 'weight' to it [nofollow]

| Does not allow control of specific UAs ? la A Standard for Robot
| Exclusion

I presented a possibility for bot-specific rules [1] but I
think it would be a heavy burden for both authors and bot implementors,
because it makes things quite complicated.
IMO having "robots.txt" for "crude" bot exclusion
(e.g: ban archive.org's bot or Google's image search) is enough.
Once bots enter a page there shouldn't be any urgent need for
distinguishing them.

| The "efficacy" and "collateral damage" issues from rel="nofollow" also
| apply.

| Collateral Damage. If tools automatically add nofollow [or
| robots-nofollow, etc] to all 3rd party links, then many legitimate
| non-spam links will be ignored or given reduced weight, and thus the
| destination of such links will be unfortunate casualties.

This is out of scope for REP and RelNoFollow.
But I suggest that we provide some tips for content generator implementers.

I'll present my way to reduce the "collateral" damage.
If there is interest in it I could set up a wiki page for it
and improve it.
I'll talk about forums but please note that (at least for this example)
that a blog and a guest book can be interpreted as a special kind of forum.
Curly braces around a value mean that this value is only provided as an
example an must be adjustable by the administrator.

I separate forum users in four groups:

- untrusted:
  Unregistered users and every registered which
  isn't a member of the other groups.

- half-trusted:
  When a registered untrusted user has more than {20} posts
  the moderator group is notified and may add him to the
  half-trusted group.

- full-trusted
  When a half-trusted user has more than {200} posts
  the moderator group is notified and may add him to the
  half-trusted group.

- moderators (Every moderator and administrator)


When an untrusted or half-trusted user makes a post into a forum this
post is stored in a database with the CUC flag (contains untrusted
content) set.

When a post with the CUC flag is rendered as
HTML there will be "robots-nofollow", "nofollow", "noindex", etc. added.

When an moderator or full-trusted user makes a post the CUT flag
won't be set.

When a moderator reads a post with the CUC flag set he will be presented
a link (e.g "Mark as OK").
If a moderator marks the post as OK the CUC flag will be cleared.
The next time the the post is rendered it will be rendered
without "robots-nofollow", "nofollow", "noindex", ...

Optional: (may not be an good idea anyway)

- If more than {8} (different) half-trusted users reply to a
post which has the CUC flag set, the flag may be
automatically removed.

- If more than {2} (different) full-trusted users reply to a
post which has the CUC flag set, the flag may
be automatically removed.

Rationale: Some forums may be huge, and not every post is read by a
moderator, but if trusted users reply to post it means that the post
contains content which isn't spam.
Of course a "Report as spam" link should be added to every post, so that
spam can be reported to the moderators.


Robert

[1] http://microformats.org/wiki/robots-exclusion#Specificity
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From tantek at cs.stanford.edu  Sat Jul 23 14:27:31 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Jul 23 14:27:36 2005
Subject: [microformats-discuss] FW: [process] and blog-description-format
In-Reply-To: <BF07FDCC.5D8D2%tantek@cs.stanford.edu>
Message-ID: <BF08040F.5D8ED%tantek@cs.stanford.edu>

Regarding:

 http://microformats.org/wiki/blog-description-format

I have just gotten a chance to take a look at it, and left a few comments on
the wiki page, but realized I should provide more explicit feedback points
here on the list to encourage folks to better follow the microformat
principles/process.


In general:

PLEASE read http://microformats.org/wiki/process before and *during* any
proposal of any microformat.

If there's anywhere that the process and principles seem unclear,
please feel free to ask.


In particular:

1. Research must use existing examples. The examples in the background
research document (blog-description-format) are theoretical illustrative
documents, and that's inappropriate for background research.  Examples in a
background research document MUST be from existing web
pages/services/products.

2. DO NOT propose a microformat before performing and documenting the
relevant background research first.

3. Background research pages should not contain draft proposals.

4. For *any* microformat proposal having to do with a blog, try using the
the proposed microformat markup *on your own blog* and see how it works.  Do
this *first*, *before* proposing it.  You might find that doing so points
out problems which can be iterated on, without having to write up a proposal
etc.

5. Many folks have been iterating (per 4.) for a few years, and perhaps feel
they haven't reached a format good enough to propose as a standard.  This is
why it is important to follow points 1. and 2.  Research includes not just
looking at markup/code examples and deconstructing them into implicit
schema, but also reading people's writings/blog posts about the subject.

6.In contrast to 

 http://microformats.org/wiki/blog-description-format

take a look at:

 http://microformats.org/wiki/blog-post-formats

not much is there yet, but it is definitely following the process.


Thanks,

Tantek

From rbach at rbach.priv.at  Sun Jul 24 07:25:24 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 24 07:24:34 2005
Subject: [microformats-discuss] FW: [process] and blog-description-format
In-Reply-To: <BF08040F.5D8ED%tantek@cs.stanford.edu>
References: <BF08040F.5D8ED%tantek@cs.stanford.edu>
Message-ID: <42E3A4D4.10301@rbach.priv.at>

Tantek ?elik wrote:
> Regarding:
> 
>  http://microformats.org/wiki/blog-description-format
Note: The mentioned revision of the wiki-page is
http://microformats.org/wiki?title=blog-description-format&oldid=1057

> PLEASE read http://microformats.org/wiki/process before and *during* any
> proposal of any microformat.

Tantek, this was my fault.
I _did_ read the http://microformats.org/wiki/process before, but I
failed to adhere to it, because I was to focused on other things.

I'll edit the wiki-page and I will try to get it right this time.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From rbach at rbach.priv.at  Sun Jul 24 10:44:34 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 24 10:43:42 2005
Subject: [microformats-discuss] Visible metadata (was: Re: Microformat for
	blog-searchand characterizing)
In-Reply-To: <BF058D87.5D7AD%tantek@cs.stanford.edu>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>
Message-ID: <42E3D382.1050708@rbach.priv.at>

Tantek ?elik wrote:
> However, this kind of use of <meta> is for the most part not much different
> in mechanism from meta keywords, and is thus has all the same
> vulnerabilities.
> 
> In short, invisible metadata works in small experiments, maybe even just
> among small crowds of people, but when it goes mainstream, the signal
> inevitably deteriorates to noise.  [...]

One could - and I do - interpret relTags as the visible pendant of
 <meta name="keywords" value="..." />

Besides meta keywords there are also other meta tags.
The most common I'm aware of are "author", "description" and "date".
It could make sense to make them visible.
Here are my ideas:

Some web pages, my homepage for example, provide the date of the last edit:
 <p>Last modified: Sunday, July 24 2005</p>

This information could be made machine-readable using the <abbr>
technique from hCalendar:
 <p><abbr class="last-modified-date" title="2005-07-24">Sunday, July 24
    2005</abbr></p>

Somebody might think <abbr class="last-modified-date"> is redundant
because of the HTTP Last-Modified header.
I don't think so because the HTTP Last-Modified header describes when
_the file_ was last modified, <abbr class="last-modified-date">
describes when the last edit of _the content_ happened.

The author(s) of a page could be denoted with

 <p>Authors:
 <span class="author">John Doe</span> and
 <span class="author">Winston Smith</span>
 </p>

or

 <p>Authors:
 <a href="http://example.org/~jd" class="author">John Doe</a> and
 <a href="http://example.org/~ws" class="author">Winston Smith</a>
 </p>


The description meta tag is used to provide a summary of a page,
sometimes this summary is also part of the visible content, e.g:
http://useit.com/alertbox/20050523.html

There is a description meta tag containing a summary and a yellow box
containing the same text.

Using
 <p class="summary">...</p>
one could mark the summary, so that robots can extract it instead of the
description meta tag.


List subscribers, please tell me what you think.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Sun Jul 24 13:13:29 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 24 13:13:35 2005
Subject: [microformats-discuss] FW: [process] and blog-description-format
In-Reply-To: <BF08040F.5D8ED%tantek@cs.stanford.edu>
References: <BF08040F.5D8ED%tantek@cs.stanford.edu>
Message-ID: <736C81A2-C797-4A38-A84A-4A4080E16CCD@technorati.com>

On Jul 23, 2005, at 2:27 PM, Tantek ?elik wrote:

> Regarding:
>
>  http://microformats.org/wiki/blog-description-format
>
> I have just gotten a chance to take a look at it, and left a few  
> comments on
> the wiki page, but realized I should provide more explicit feedback  
> points
> here on the list to encourage folks to better follow the microformat
> principles/process.
>
>
> In general:
>
> PLEASE read http://microformats.org/wiki/process before and  
> *during* any
> proposal of any microformat.
>
> If there's anywhere that the process and principles seem unclear,
> please feel free to ask.

I'd just like to add some emphasis on the "solve a real problem"...

This means that we must:

1. Identify an existing problem
2. Show that it hasn't been solved
3. Look at ways people have tried to solve it


And specifically on #2, I think there's a lot of prior art that you  
need to grapple with (and the burden of proof is on the new proposal  
to show that previous efforts have not been succesful):

> Blog URI (e.g: http://example.org/ )

we have rel= "permalink", though I don't think this is a formal  
microformat (ie, there's no spec), still still in common use  
(according to this: http://en.wikipedia.org/wiki/Permalink, its been  
in use since at least 2000).

> Lanuage used for the blog, read-able by machines (e.g: "en-US" or  
> "de")

In html and xhml 1, there's a lang attribute and in xhtml 1.1,  
there's an xml:lang attribute.

See:
1. http://www.w3.org/TR/REC-html40/struct/dirlang.html
2. http://www.w3.org/TR/xhtml1/#C_7
3. http://www.w3.org/International/tutorials/tutorial-lang/

> Topics covered by the blog

This is certainly an open problem.

> A short description

I don't know of a solution to this.

> Available feeds

Its common to use <link rel="alternate" href="..." /> and <a  
rel="alternate" href="...">...</a>, so I think this might be a solved  
problem.

> A small logo image

What about favicons - I believe favicon files can actually have  
several sizes in them, not just the 16x16 (or whatever the tiny size  
is).

> Details about the author(s)
> Name (e.g: "John Doe")
> Contact details
> Geographical Location

<address class="vcard"></address>

see: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.6

and http://microformats.org/wiki/hcard

-ryan



From ryan at technorati.com  Sun Jul 24 13:19:13 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 24 13:19:16 2005
Subject: [microformats-discuss] Visible metadata (was: Re: Microformat for
	blog-searchand characterizing)
In-Reply-To: <42E3D382.1050708@rbach.priv.at>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>
	<42E3D382.1050708@rbach.priv.at>
Message-ID: <62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>

On Jul 24, 2005, at 10:44 AM, Robert Bachmann wrote:
> Tantek ?elik wrote:
>
>> However, this kind of use of <meta> is for the most part not much  
>> different
>> in mechanism from meta keywords, and is thus has all the same
>> vulnerabilities.
>>
>> In short, invisible metadata works in small experiments, maybe  
>> even just
>> among small crowds of people, but when it goes mainstream, the signal
>> inevitably deteriorates to noise.  [...]
>>
>
> One could - and I do - interpret relTags as the visible pendant of
>  <meta name="keywords" value="..." />
>
> Besides meta keywords there are also other meta tags.
> The most common I'm aware of are "author", "description" and "date".
> It could make sense to make them visible.
> Here are my ideas:
>
> Some web pages, my homepage for example, provide the date of the  
> last edit:
>  <p>Last modified: Sunday, July 24 2005</p>
>
> This information could be made machine-readable using the <abbr>
> technique from hCalendar:
>  <p><abbr class="last-modified-date" title="2005-07-24">Sunday,  
> July 24
>     2005</abbr></p>

I think this is a great idea.

As many have noticed, the <abbr> for date/time gets reused alot...so,  
I think it could stand to be refactored out into its own elemental  
microformat. What do you think?

> Somebody might think <abbr class="last-modified-date"> is redundant
> because of the HTTP Last-Modified header.
> I don't think so because the HTTP Last-Modified header describes when
> _the file_ was last modified, <abbr class="last-modified-date">
> describes when the last edit of _the content_ happened.

And, your proposed construct could apply to a part of a page (ie, a  
post), which the Last-Modified header cannot do.

> The author(s) of a page could be denoted with
>
>  <p>Authors:
>  <span class="author">John Doe</span> and
>  <span class="author">Winston Smith</span>
>  </p>
>
> or
>
>  <p>Authors:
>  <a href="http://example.org/~jd" class="author">John Doe</a> and
>  <a href="http://example.org/~ws" class="author">Winston Smith</a>
>  </p>

Take a look at <address> and hcard again and make sure it can't  
supply your needs.

http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.6
http://microformats.org/wiki/hcard

> The description meta tag is used to provide a summary of a page,
> sometimes this summary is also part of the visible content, e.g:
> http://useit.com/alertbox/20050523.html
>
> There is a description meta tag containing a summary and a yellow box
> containing the same text.
>
> Using
>  <p class="summary">...</p>
> one could mark the summary, so that robots can extract it instead  
> of the
> description meta tag.

I'm not sure about this. Do people use this meta tag? And do they  
publish the same content in html?

-ryan
From rbach at rbach.priv.at  Sun Jul 24 18:03:54 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 24 18:03:07 2005
Subject: [microformats-discuss] Visible metadata
In-Reply-To: <62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>	<42E3D382.1050708@rbach.priv.at>
	<62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>
Message-ID: <42E43A7A.1000800@rbach.priv.at>

Ryan King wrote:
> As many have noticed, the <abbr> for date/time gets reused alot...so,
> I think it could stand to be refactored out into its own elemental
> microformat. What do you think?
>

I think every date/time on the web should be expressed using
<abbr title="YYYY-MM-DDTHH:MM">...</abbr>.

There is a great benefit because authors can use their favorite
date notation and users which are used to other conventions
could still understand them.

Example:
AFAIK in the US a common date/time format is MM/DD/YYYY hh:mm
(with 12 hours and am/pm)
In Austria a common format is DD.MM.YYYY hh:mm (with 24 hours)

So if I read "02/07/2005 11:30 pm" I have to engage my brain:
But with <abbr title="2004-02-07T22:30">02/07/2005 11:30 pm</abbr>, I
simply move the mouse cursor over it and my browser will display the
date in an unambiguous notation.

(Note: I intentionally used the long notation with dashes because it's
easier to read. I strongly recommend this to everybody, because title
attributes are not only for machines but for humans too)

But perhaps we could go even one step further.
Imagine a plugin, an Opera UserJavaScript or a Seamonkey script which
extends the mouse over
tool tip from
 Title: 2004-02-07T22:30
to
 Title: 2004-02-07T22:30
 Regional notation #1: 7.2.2004 22:30
 Regional notation #2: 7. Februar 2004 22:30

Ryan, you once pointed me to http://www.cl.cam.ac.uk/~mgk25/iso-time.html
and I learned that ISO8601 even allows you to specify your time zone, so
a plugin could even translate the time provided to the user's regional
timezone.

>
>> The author(s) of a page could be denoted with
>>
>>  <p>Authors:
>>  <span class="author">John Doe</span> and
>>  <span class="author">Winston Smith</span>
>>  </p>
>>
>> or
>>
>>  <p>Authors:
>>  <a href="http://example.org/~jd" class="author">John Doe</a> and
>>  <a href="http://example.org/~ws" class="author">Winston Smith</a>
>>  </p>
>
> Take a look at <address> and hcard again and make sure it can't
> supply your needs.
>
> http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.6
> http://microformats.org/wiki/hcard

Thanks Ryan, you brought me on the right way.
I already thought about <address> and I thought about hCard but
I didn't think about address _and_ hCard(s) ;-).

 <address>Authors:
    <span class="vcard">
     <span class="fn">John Doe</span> and
    <span class="vcard">
     <span class="fn">Winston Smith</span>
    </span>
 </address>

 <address>Authors:
    <span class="vcard">
     <a class="url fn"
        href="http://example.org/~jd"
        rel="alternate">John Doe</a></span>
     and
    <span class="vcard">
     <a class="url fn"
        href="http://example.org/~ws"
        rel="alternate">Winston Smith</a>
    </span>
 </address>

Relationship rel="alternate" was added because http://example.org/~jd
and http://example.org/~ws should both contain hCards which provide
more contact details (email, phone, etc.).

One general note on hCard:

Parser could make the following assertion: If the container element
of a hCard is an inline element (e.g: <span>) and contains an <a>
element with class "url" and rel="alternate" _perhaps_ the page pointed
to by href contains the "full" version of the Person's hCard.

>> Using
>>  <p class="summary">...</p>
>> one could mark the summary, so that robots can extract it instead of
>> the description meta tag.
>
> I'm not sure about this.
> Do people use this meta tag?

Some people use it.
Goggle displays the contents of this meta tag in search results.

Example:
I've searched for "homepage" on http://www.google.com/search?q=homepage
The second result is "BBC - bbc.co.uk homepage - Home of the BBC on the
Internet"
The text displayed below ("bbc.co.uk offers a varied range of sites
including news, sport, community, education, children's,
and lifestyle sites, with TV programme support, ...") comes from
the description meta tag.

> And do they publish the same content in html?
(I suppose you mean inside of <body> ...)
At least Jakob Nielsen does it with his articles on useit.com and
I guess others do it too. I'll write more on this topic later, when I
know more about the existing practice.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From rbach at rbach.priv.at  Sun Jul 24 18:20:24 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Sun Jul 24 18:19:31 2005
Subject: [microformats-discuss] FW: [process] and blog-description-format
In-Reply-To: <BF08040F.5D8ED%tantek@cs.stanford.edu>
References: <BF08040F.5D8ED%tantek@cs.stanford.edu>
Message-ID: <42E43E58.7090400@rbach.priv.at>

Tantek ?elik wrote:
> In particular:
> 
> 1. Research must use existing examples. The examples in the background
> research document (blog-description-format) are theoretical illustrative
> documents, and that's inappropriate for background research.  Examples in a
> background research document MUST be from existing web
> pages/services/products.

Is it okay to have an extra wiki page for theoretical examples?
If yes, how should this page be called?

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From tantek at cs.stanford.edu  Sun Jul 24 18:55:57 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sun Jul 24 18:56:05 2005
Subject: [microformats-discuss] FW: [process] and blog-description-format
In-Reply-To: <42E43E58.7090400@rbach.priv.at>
Message-ID: <BF099475.5D9A6%tantek@cs.stanford.edu>

On 7/24/05 6:20 PM, "Robert Bachmann" <rbach@rbach.priv.at> wrote:

> Tantek ?elik wrote:
>> In particular:
>> 
>> 1. Research must use existing examples. The examples in the background
>> research document (blog-description-format) are theoretical illustrative
>> documents, and that's inappropriate for background research.  Examples in a
>> background research document MUST be from existing web
>> pages/services/products.
> 
> Is it okay to have an extra wiki page for theoretical examples?

Another way of phrasing theoretical examples is "strawman proposals".  And
yes, it is ok to do so, but only in conjunction with doing research.
Strawman proposals are a good way of "throwing ideas out there" that are
meant to spur discussion, rather to be taken seriously as format proposals.
That relieves them of heavier responsibilities, and frees us up to
experiment in the open and think out loud, both of which are encouraged.
Hence...

> If yes, how should this page be called?

 *-brainstorming

E.g. see pages on hcard-brainstorming, hcalendar-brainstorming.  The
*-brainstorming pages are good workspaces for jotting down various bits and
pieces, and it's understood that they experience a lot of flux.

Thanks,

Tantek

From ryan at technorati.com  Sun Jul 24 22:55:57 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 24 22:56:02 2005
Subject: [microformats-discuss] Visible metadata
In-Reply-To: <42E43A7A.1000800@rbach.priv.at>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>	<42E3D382.1050708@rbach.priv.at>
	<62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>
	<42E43A7A.1000800@rbach.priv.at>
Message-ID: <336BCCE2-0B2C-49C5-8E01-292026DD24E2@technorati.com>

On Jul 24, 2005, at 6:03 PM, Robert Bachmann wrote:
> Ryan King wrote:
>> As many have noticed, the <abbr> for date/time gets reused alot...so,
>> I think it could stand to be refactored out into its own elemental
>> microformat. What do you think?
>
> I think every date/time on the web should be expressed using
> <abbr title="YYYY-MM-DDTHH:MM">...</abbr>.

I would agree, but let's not get ahead of ourselves. :)

Remember, we're not telling anyone what they should do- we're just  
trying to provide tools for them to accomplish their goals (and  
semantic markup is a meaningful goal for many).

> ...
>
> Ryan, you once pointed me to http://www.cl.cam.ac.uk/~mgk25/iso- 
> time.html
> and I learned that ISO8601 even allows you to specify your time  
> zone, so
> a plugin could even translate the time provided to the user's regional
> timezone.

Yes, ISO8601 allows you to specify a timezone offset (you can see  
that in action in my hcalendar creator [http://theryanking.com/ 
microformats/hcalendar-creator.html]).

-ryan
From fantasai.lists at inkedblade.net  Mon Jul 25 04:54:43 2005
From: fantasai.lists at inkedblade.net (fantasai)
Date: Mon Jul 25 04:55:53 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <42E43A7A.1000800@rbach.priv.at>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>	<42E3D382.1050708@rbach.priv.at>	<62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>
	<42E43A7A.1000800@rbach.priv.at>
Message-ID: <42E4D303.3040207@inkedblade.net>

Robert Bachmann wrote:
> Ryan King wrote:
> 
>>As many have noticed, the <abbr> for date/time gets reused alot...so,
>>I think it could stand to be refactored out into its own elemental
>>microformat. What do you think?
> 
> I think every date/time on the web should be expressed using
> <abbr title="YYYY-MM-DDTHH:MM">...</abbr>.

Since ISO 8601 apparently allows replacing the 'T' with a space
   http://en.wikipedia.org/wiki/ISO_8601#Combined_representations
then the value of 'title', which is *supposed* to be human-readable
and which would not be otherwise ambiguous, should use a space,
not a 'T'.

~fantasai
From rbach at rbach.priv.at  Mon Jul 25 05:01:41 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Mon Jul 25 05:01:16 2005
Subject: [microformats-discuss] Visible metadata
In-Reply-To: <336BCCE2-0B2C-49C5-8E01-292026DD24E2@technorati.com>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>	<42E3D382.1050708@rbach.priv.at>	<62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>	<42E43A7A.1000800@rbach.priv.at>
	<336BCCE2-0B2C-49C5-8E01-292026DD24E2@technorati.com>
Message-ID: <42E4D4A5.7010301@rbach.priv.at>

Ryan King wrote:
> On Jul 24, 2005, at 6:03 PM, Robert Bachmann wrote:
> 
>> Ryan King wrote:
>>
>>> As many have noticed, the <abbr> for date/time gets reused alot...so,
>>> I think it could stand to be refactored out into its own elemental
>>> microformat. What do you think?
>>
>>
>> I think every date/time on the web should be expressed using
>> <abbr title="YYYY-MM-DDTHH:MM">...</abbr>.
> 
> 
> I would agree, but let's not get ahead of ourselves. :)
> 
> Remember, we're not telling anyone what they should do- we're just
> trying to provide tools for them to accomplish their goals (and
> semantic markup is a meaningful goal for many).
>

Just for clarification.
I was _not_ telling anyone what he/she should do, I solely expressed my
opinion. An opinion which grounds on the possible benefits outlined
below in my original post.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From drernie at opendarwin.org  Mon Jul 25 09:57:50 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Mon Jul 25 09:57:59 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <42E4D303.3040207@inkedblade.net>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>	<42E3D382.1050708@rbach.priv.at>	<62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>
	<42E43A7A.1000800@rbach.priv.at> <42E4D303.3040207@inkedblade.net>
Message-ID: <0DB7913C-2C12-4948-A734-1B6E9723B61A@opendarwin.org>

I also like the idea of a elemental microformat (nanoformat?) for dates.

I presume the official designation would be an "ISO_8601" date in the  
title, but the 'recommended' practice would be, with a space and  
timezone:

> <abbr title="YYYY-MM-DD HH:MM[:SS]+-Z">

Of course, Robert (unintentionally, I suspect) raised another point:

> But with <abbr title="2004-02-07T22:30">02/07/2005 11:30 pm</abbr>, I
> simply move the mouse cursor over it and my browser will display the
> date in an unambiguous notation.

Alas, "unambiguous" is an unfortunate term: is that 2004 or 2005?   
That is the price of multiple representations; unfortunately, I can't  
think of any way around it.   Ideally I suspect a parser should use  
in the human-readable date as normative, if it could read it, but  
that leads to inconsistent results. :-(

-- Ernie P.


On Jul 25, 2005, at 4:54 AM, fantasai wrote:

> Robert Bachmann wrote:
>
>> Ryan King wrote:
>>
>>> As many have noticed, the <abbr> for date/time gets reused  
>>> alot...so,
>>> I think it could stand to be refactored out into its own elemental
>>> microformat. What do you think?
>>>
>> I think every date/time on the web should be expressed using
>> <abbr title="YYYY-MM-DDTHH:MM">...</abbr>.
>>
>
> Since ISO 8601 apparently allows replacing the 'T' with a space
>   http://en.wikipedia.org/wiki/ISO_8601#Combined_representations
> then the value of 'title', which is *supposed* to be human-readable
> and which would not be otherwise ambiguous, should use a space,
> not a 'T'.
>
> ~fantasai
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From tantek at cs.stanford.edu  Mon Jul 25 10:14:30 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jul 25 10:14:43 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <0DB7913C-2C12-4948-A734-1B6E9723B61A@opendarwin.org>
Message-ID: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>

On 7/25/05 9:57 AM, "Dr. Ernie Prabhakar" <drernie@opendarwin.org> wrote:

> I also like the idea of a elemental microformat (nanoformat?) for dates.

I've been thinking about this a while too, but I'm not sure there is enough
of a "problem" that needs to be solved to require a separate elemental
microformat for dates.

Rather, for now, I see this use of <abbr> as a microformat design pattern
that should be utilized in other microformats, any time a date or time is
needed.

> I presume the official designation would be an "ISO_8601" date in the
> title, but the 'recommended' practice would be, with a space and
> timezone:
> 
>> <abbr title="YYYY-MM-DD HH:MM[:SS]+-Z">

I would prefer to point to the W3C Note on Date Time for recommended
practice for now.
 
 http://www.w3.org/TR/NOTE-datetime

Which does ask for the "T" date time separator to be used.


> Of course, Robert (unintentionally, I suspect) raised another point:
> 
>> But with <abbr title="2004-02-07T22:30">02/07/2005 11:30 pm</abbr>, I
>> simply move the mouse cursor over it and my browser will display the
>> date in an unambiguous notation.
> 
> Alas, "unambiguous" is an unfortunate term: is that 2004 or 2005?
> That is the price of multiple representations; unfortunately, I can't
> think of any way around it.   Ideally I suspect a parser should use
> in the human-readable date as normative, if it could read it, but
> that leads to inconsistent results. :-(

I thought his point was deliberate, given the *two* inconsistencies:

1. 2004 vs. 2005

2. 22:30 (10:30pm) vs. 11:30pm (23:30)

Thanks,

Tantek


> On Jul 25, 2005, at 4:54 AM, fantasai wrote:
> 
>> Robert Bachmann wrote:
>> 
>>> Ryan King wrote:
>>> 
>>>> As many have noticed, the <abbr> for date/time gets reused
>>>> alot...so,
>>>> I think it could stand to be refactored out into its own elemental
>>>> microformat. What do you think?
>>>> 
>>> I think every date/time on the web should be expressed using
>>> <abbr title="YYYY-MM-DDTHH:MM">...</abbr>.
>>> 
>> 
>> Since ISO 8601 apparently allows replacing the 'T' with a space
>>   http://en.wikipedia.org/wiki/ISO_8601#Combined_representations
>> then the value of 'title', which is *supposed* to be human-readable
>> and which would not be otherwise ambiguous, should use a space,
>> not a 'T'.
>> 
>> ~fantasai
>> _______________________________________________
>> 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 drernie at opendarwin.org  Mon Jul 25 10:27:08 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Mon Jul 25 10:27:16 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>
References: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>
Message-ID: <1D2F4A13-8068-4583-B495-980D8A05C455@opendarwin.org>


On Jul 25, 2005, at 10:14 AM, Tantek ?elik wrote:

> On 7/25/05 9:57 AM, "Dr. Ernie Prabhakar" <drernie@opendarwin.org>  
> wrote:
>> I also like the idea of a elemental microformat (nanoformat?) for  
>> dates.
>
> I've been thinking about this a while too, but I'm not sure there  
> is enough
> of a "problem" that needs to be solved to require a separate elemental
> microformat for dates.
>
> Rather, for now, I see this use of <abbr> as a microformat design  
> pattern
> that should be utilized in other microformats, any time a date or  
> time is
> needed.

A design pattern certainly sounds lower-weight than a nanoformat,  
though in the end I suspect it is just a matter of semantics. Oh,  
wait, *everything* here is merely semantics. :-)

>> I presume the official designation would be an "ISO_8601" date in the
>> title, but the 'recommended' practice would be, with a space and
>> timezone:
>>
>>> <abbr title="YYYY-MM-DD HH:MM[:SS]+-Z">
>>>
>
> I would prefer to point to the W3C Note on Date Time for recommended
> practice for now.
>
>  http://www.w3.org/TR/NOTE-datetime
>
> Which does ask for the "T" date time separator to be used.

Ah, of course.   You're right (as usual :-): don't invent a  
convention if one already exists.

Still,  it would be nice to at least document this 'design pattern'  
somewhere (with the W3C link), no matter what we call it.

-- Ernie P.


From rbach at rbach.priv.at  Mon Jul 25 11:51:19 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Mon Jul 25 11:50:28 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <0DB7913C-2C12-4948-A734-1B6E9723B61A@opendarwin.org>
References: <BF058D87.5D7AD%tantek@cs.stanford.edu>	<42E3D382.1050708@rbach.priv.at>	<62E36685-0B9F-4EF9-A106-D3A739E751D3@technorati.com>	<42E43A7A.1000800@rbach.priv.at>
	<42E4D303.3040207@inkedblade.net>
	<0DB7913C-2C12-4948-A734-1B6E9723B61A@opendarwin.org>
Message-ID: <42E534A7.4060801@rbach.priv.at>

Dr. Ernie Prabhakar wrote:
> I also like the idea of a elemental microformat (nanoformat?) for dates.
> 
> I presume the official designation would be an "ISO_8601" date in the 
> title, but the 'recommended' practice would be, with a space and  timezone:
> 
>> <abbr title="YYYY-MM-DD HH:MM[:SS]+-Z">
> 
> 
> Of course, Robert (unintentionally, I suspect) raised another point:

Yes, 2004 and 22:30 were "slips of the pen".

> 
>> But with <abbr title="2004-02-07T22:30">02/07/2005 11:30 pm</abbr>, I
>> simply move the mouse cursor over it and my browser will display the
>> date in an unambiguous notation.
> 
> 
> Alas, "unambiguous" is an unfortunate term: is that 2004 or 2005?   That
> is the price of multiple representations; unfortunately, I can't  think
> of any way around it.   

Multiple representations shouldn't be hand-crafted in most cases.
Authoring systems could provide ways to enter a date using a
calender, and generate <abbr title="...">...</abbr> from it.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From ryan at technorati.com  Mon Jul 25 12:36:56 2005
From: ryan at technorati.com (Ryan King)
Date: Mon Jul 25 12:36:59 2005
Subject: [microformats-discuss] datetime design pattern
In-Reply-To: <1D2F4A13-8068-4583-B495-980D8A05C455@opendarwin.org>
References: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>
	<1D2F4A13-8068-4583-B495-980D8A05C455@opendarwin.org>
Message-ID: <57AC7BC1-3337-4F1D-879E-939D1849C101@technorati.com>

On Jul 25, 2005, at 10:27 AM, Dr. Ernie Prabhakar wrote:
> Still,  it would be nice to at least document this 'design pattern'  
> somewhere (with the W3C link), no matter what we call it.

Yes, this certainly needs to be done. Now its just a matter of how,  
as we don't have any "design patterns for microformats" yet.

-ryan
From drernie at opendarwin.org  Mon Jul 25 12:47:46 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Mon Jul 25 12:47:51 2005
Subject: [microformats-discuss] datetime design pattern
In-Reply-To: <57AC7BC1-3337-4F1D-879E-939D1849C101@technorati.com>
References: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>
	<1D2F4A13-8068-4583-B495-980D8A05C455@opendarwin.org>
	<57AC7BC1-3337-4F1D-879E-939D1849C101@technorati.com>
Message-ID: <C476077C-40FA-4980-A72D-F544F60AC04F@opendarwin.org>

On Jul 25, 2005, at 12:36 PM, Ryan King wrote:
> Yes, this certainly needs to be done. Now its just a matter of how,  
> as we don't have any "design patterns for microformats" yet.

At the risk of stepping on toes, could we start by doing this:

http://microformats.org/wiki?title=Main_Page&action=edit&section=5
http://microformats.org/wiki?title=datetime-design-pattern&action=edit

If this is a bad idea, please feel free to revert; However, I presume  
the idea of the wiki is to make it easy to pull these sorts of things  
together ad hoc...

-- Ernie P.

From dimitri.glazkov at gmail.com  Mon Jul 25 12:51:46 2005
From: dimitri.glazkov at gmail.com (Dimitri Glazkov)
Date: Mon Jul 25 12:51:49 2005
Subject: [microformats-discuss] datetime design pattern
In-Reply-To: <C476077C-40FA-4980-A72D-F544F60AC04F@opendarwin.org>
References: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>
	<1D2F4A13-8068-4583-B495-980D8A05C455@opendarwin.org>
	<57AC7BC1-3337-4F1D-879E-939D1849C101@technorati.com>
	<C476077C-40FA-4980-A72D-F544F60AC04F@opendarwin.org>
Message-ID: <fb15ac210507251251689242@mail.gmail.com>

Isn't this a microformat in itself?

:DG<

On 7/25/05, Dr. Ernie Prabhakar <drernie@opendarwin.org> wrote:
> On Jul 25, 2005, at 12:36 PM, Ryan King wrote:
> > Yes, this certainly needs to be done. Now its just a matter of how,
> > as we don't have any "design patterns for microformats" yet.
> 
> At the risk of stepping on toes, could we start by doing this:
> 
> http://microformats.org/wiki?title=Main_Page&action=edit&section=5
> http://microformats.org/wiki?title=datetime-design-pattern&action=edit
> 
> If this is a bad idea, please feel free to revert; However, I presume
> the idea of the wiki is to make it easy to pull these sorts of things
> together ad hoc...
> 
> -- Ernie P.
> 
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
From fantasai.lists at inkedblade.net  Tue Jul 26 00:48:54 2005
From: fantasai.lists at inkedblade.net (fantasai)
Date: Tue Jul 26 00:50:34 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>
References: <BF0A6BF5.5D9D8%tantek@cs.stanford.edu>
Message-ID: <42E5EAE6.7010900@inkedblade.net>

Tantek ?elik wrote:
> 
>>I presume the official designation would be an "ISO_8601" date in the
>>title, but the 'recommended' practice would be, with a space and
>>timezone:
>>
>>><abbr title="YYYY-MM-DD HH:MM[:SS]+-Z">
> 
> I would prefer to point to the W3C Note on Date Time for recommended
> practice for now.
>  
>  http://www.w3.org/TR/NOTE-datetime
> 
> Which does ask for the "T" date time separator to be used.

That note's targetted at more computer-oriented uses than a specifically
human-targetted tooltip. The 'T' is helpful in software and data formats
because it makes the date-time parse as a single token. However, a 'title'
attribute's value ought to be primarily helpful to humans. I don't consider
date-times with a T to be human-friendly: they are harder for people to
recognize as a date and time rather than an arbitrary numerical string
because the separation into a date string and a time string (both of which,
unlike timestamps, are common outside computer formats) is more visually
distinct. Using a space still conforms to ISO 8601, so it's not reinventing
anything, just using an option that happens not to be part of the subset
described in the W3C Note.

~fantasai
From tantek at cs.stanford.edu  Tue Jul 26 01:31:12 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 26 01:31:20 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <42E5EAE6.7010900@inkedblade.net>
Message-ID: <BF0B4272.5DAAA%tantek@cs.stanford.edu>

On 7/26/05 12:48 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

> Tantek ?elik wrote:
>> 
>>> I presume the official designation would be an "ISO_8601" date in the
>>> title, but the 'recommended' practice would be, with a space and
>>> timezone:
>>> 
>>>> <abbr title="YYYY-MM-DD HH:MM[:SS]+-Z">
>> 
>> I would prefer to point to the W3C Note on Date Time for recommended
>> practice for now.
>>  
>>  http://www.w3.org/TR/NOTE-datetime
>> 
>> Which does ask for the "T" date time separator to be used.
> 
> That note's targetted at more computer-oriented uses than a specifically
> human-targetted tooltip. The 'T' is helpful in software and data formats
> because it makes the date-time parse as a single token.

Agreed.

> However, a 'title'
> attribute's value ought to be primarily helpful to humans.

Helpful to humans yes.  primarily? i'm not sure. probably.

> I don't consider
> date-times with a T to be human-friendly:

Easy enough to answer with a bit of surveying probably.

> they are harder for people to
> recognize as a date and time rather than an arbitrary numerical string
> because the separation into a date string and a time string (both of which,
> unlike timestamps, are common outside computer formats) is more visually
> distinct. Using a space still conforms to ISO 8601, so it's not reinventing
> anything, just using an option that happens not to be part of the subset
> described in the W3C Note.

Have you considered giving feedback on the W3C Note?

Parsing a "single normal space character ASCII 32" (rather than just "white
space") should be equivalently easy to parsing a "T", and thus since they
are equivalent from a computer point of view, you could make the argument
that the W3C Note should be extended to permit either since the space is
more human friendly.

Then we could simply profile that and recommend that folks SHOULD use a
space.

I'd just like to see this argument pushed up stream, because I think it has
a decent chance, and would benefit many others.

Thanks,

Tantek

From lists at elegantchaos.com  Tue Jul 26 03:44:00 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Tue Jul 26 03:44:10 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <BF0B4272.5DAAA%tantek@cs.stanford.edu>
References: <BF0B4272.5DAAA%tantek@cs.stanford.edu>
Message-ID: <6577E239-961D-464E-BB5D-446E3A25E55E@elegantchaos.com>

On 26 Jul 2005, at 09:31, Tantek ?elik wrote:

> I'd just like to see this argument pushed up stream, because I  
> think it has
> a decent chance, and would benefit many others.

Talking about pushing things up stream, it seems to me that a date is  
such a fundamental thing, and the display of it as text is so  
location (and user-preference) specific, that there really ought to  
be a standard way of representing it in HTML/XHTML which _requires_  
the browser to render the date in the user's local format.

One shouldn't need to resort to javascript and tool tips!

From ian at hixie.ch  Tue Jul 26 06:20:55 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue Jul 26 06:21:00 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <BF0B4272.5DAAA%tantek@cs.stanford.edu>
References: <BF0B4272.5DAAA%tantek@cs.stanford.edu>
Message-ID: <Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>

On Tue, 26 Jul 2005, Tantek ?elik wrote:
> 
> Parsing a "single normal space character ASCII 32" (rather than just 
> "white space") should be equivalently easy to parsing a "T", and thus 
> since they are equivalent from a computer point of view, you could make 
> the argument that the W3C Note should be extended to permit either since 
> the space is more human friendly.

Parsing a "T" is a LOT easier than parsing U+0020. Not because parsing 
U+0020 itself is hard, but because when authors think U+0020 is allowed, 
they think U+000A, U+0009, U+000D, U+000C are allowed as well, not to 
mention U+00A0 and a stream of other whitespace characters. And then they 
think that any number of them are acceptable, in any order. 
Implementations then end up all slightly disagreeing about what is 
whitespace and what isn't and pages end up being interpreted differently.

Whitespace should be avoided like the plague in attributes where 
interoperable results are expected from computers parsing the data.

Human consumption is not an issue here anyway. With a T or with 
whitespace, we should not be expecting ISO8601 dates to be the final 
presentation form.

   .date[title] { tooltip: datetime(attr(title)); }

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
From skeltoac at gmail.com  Tue Jul 26 06:57:12 2005
From: skeltoac at gmail.com (Andy Skelton)
Date: Tue Jul 26 06:57:13 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>
References: <BF0B4272.5DAAA%tantek@cs.stanford.edu>
	<Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>
Message-ID: <e6ec604d0507260657a807d5e@mail.gmail.com>

On 7/26/05, Ian Hickson <ian@hixie.ch> wrote:
> Human consumption is not an issue here anyway. With a T or with
> whitespace, we should not be expecting ISO8601 dates to be the final
> presentation form.

If human consumption is not an issue, why not just use unix epoch seconds GMT?

Andy Skelton
From rbach at rbach.priv.at  Tue Jul 26 07:03:52 2005
From: rbach at rbach.priv.at (Robert Bachmann)
Date: Tue Jul 26 07:03:00 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <e6ec604d0507260657a807d5e@mail.gmail.com>
References: <BF0B4272.5DAAA%tantek@cs.stanford.edu>	<Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>
	<e6ec604d0507260657a807d5e@mail.gmail.com>
Message-ID: <42E642C8.5090801@rbach.priv.at>

Andy Skelton wrote:
> On 7/26/05, Ian Hickson <ian@hixie.ch> wrote:
> 
>>Human consumption is not an issue here anyway. With a T or with
>>whitespace, we should not be expecting ISO8601 dates to be the final
>>presentation form.
> 
> 
> If human consumption is not an issue, why not just use unix epoch seconds GMT?
> 
> Andy Skelton

When I write XHTML using a text editor, it's easier to write ISO8601 dates.

Robert
-- 
Robert Bachmann <rbach@rbach.priv.at> (OpenPGP KeyID: 0x4A5CCF10)
From carl.beeth at gmail.com  Tue Jul 26 07:27:05 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Tue Jul 26 07:27:09 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>
References: <BF0B4272.5DAAA%tantek@cs.stanford.edu>
	<Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>
Message-ID: <e8ca2e110507260727b95a0b3@mail.gmail.com>

On 7/26/05, Ian Hickson <ian@hixie.ch> wrote:
> Human consumption is not an issue here anyway. 

I disagree, as said earlier there is an instant killer app for this
MF: making dates less ambiguous without need for any processing beyond
what the browser already has.

Having said that this MF seems like a perfect candidate for a
greasemonkey extension. takes the iso date in the title of the abbr
tag and re-parses it in a appropriate local format and re-injects it
between the abbr tags.
From soundrater at yahoo.com  Tue Jul 26 08:12:47 2005
From: soundrater at yahoo.com (Peter Jones)
Date: Tue Jul 26 08:12:49 2005
Subject: [microformats-discuss] personal intro
Message-ID: <20050726151247.36686.qmail@web51012.mail.yahoo.com>

Hi all,

I'm Peter Jones. I am interested in the rating of
resources in order to enable their discovery. Recently
I've been looking at the possibility of using tags as
criteria against which to make ratings; there are some
similarities with VoteLinks and use of the "rev"
attribute. I keep an occasional blog at
soundrater.blogspot.com which details some thoughts
about this.

Regards,

Peter.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
From tantek at cs.stanford.edu  Tue Jul 26 09:02:27 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 26 09:08:28 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <6577E239-961D-464E-BB5D-446E3A25E55E@elegantchaos.com>
Message-ID: <BF0BAC89.5DAE9%tantek@cs.stanford.edu>

On 7/26/05 3:44 AM, "Sam Deane" <lists@elegantchaos.com> wrote:

> On 26 Jul 2005, at 09:31, Tantek ?elik wrote:
> 
>> I'd just like to see this argument pushed up stream, because I
>> think it has
>> a decent chance, and would benefit many others.
> 
> Talking about pushing things up stream, it seems to me that a date is
> such a fundamental thing, and the display of it as text is so
> location (and user-preference) specific, that there really ought to
> be a standard way of representing it in HTML/XHTML which _requires_
> the browser to render the date in the user's local format.

Indeed.  I tried.

http://lists.w3.org/Archives/Public/www-html/2003Oct/0089.html

But even if XHTML2 did include a <time> element, it would be years (many
years) before we could reliably use it and depend on it.

> One shouldn't need to resort to javascript and tool tips!

Why not? (or rather, why do you consider it "resort"ing?)  As long as the
markup is valid, there is something to be said for going with a simple
solution that works.  There is nothing inherently wrong with javascript and
tool tips.

Thanks,

Tantek

From tantek at cs.stanford.edu  Tue Jul 26 09:09:34 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 26 09:09:51 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <e8ca2e110507260727b95a0b3@mail.gmail.com>
Message-ID: <BF0BAE4C.5DAF7%tantek@cs.stanford.edu>

On 7/26/05 7:27 AM, "Carl Beeth" <carl.beeth@gmail.com> wrote:

> On 7/26/05, Ian Hickson <ian@hixie.ch> wrote:
>> Human consumption is not an issue here anyway.
> 
> I disagree, as said earlier there is an instant killer app for this
> MF: making dates less ambiguous without need for any processing beyond
> what the browser already has.

As I said in the reply to Ian's message, I want to avoid making this an
issue of absolutes.

Human consumption is not *as much of* an issue here.

We do want to make the date time title reasonably possible for a human to
verify, but don't have to make it "ideally human readable".  That's what the
element contents of the <abbr> are for.

Think of the whole element (<abbr>) as something we want to make overall
good for human friendly (consumption and authoring).  We solve that by
putting the truly human friendly version inside the element contents which
works for the 99% case.  The 'title' is the alternate representation whose
primary purpose is to be machine parsable (and compatible with an existing
date time standard), and whose secondary purpose is to be reasonably human
verifiable that it is the same as the element contents.

BTW, in general we want to avoid duplicating information like this (i.e. the
DRY principle), and thus such a use of <abbr> to separate human vs. machine
readable versions of a piece of data MUST be the exception, not the rule,
and only something we resort to when necessary (i.e. when a greater
principle, like humans first, supercedes).


> Having said that this MF seems like a perfect candidate for a
> greasemonkey extension. takes the iso date in the title of the abbr
> tag and re-parses it in a appropriate local format and re-injects it
> between the abbr tags.

Yes.  That would be an excellent use of GM.

Thanks,

Tantek

From tantek at cs.stanford.edu  Tue Jul 26 09:02:27 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 26 09:10:04 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>
Message-ID: <BF0BAC9C.5DAE9%tantek@cs.stanford.edu>

On 7/26/05 6:20 AM, "Ian Hickson" <ian@hixie.ch> wrote:

> On Tue, 26 Jul 2005, Tantek ?elik wrote:
>> 
>> Parsing a "single normal space character ASCII 32" (rather than just
>> "white space") should be equivalently easy to parsing a "T", and thus
>> since they are equivalent from a computer point of view, you could make
>> the argument that the W3C Note should be extended to permit either since
>> the space is more human friendly.
> 
> Parsing a "T" is a LOT easier than parsing U+0020. Not because parsing
> U+0020 itself is hard, but because when authors think U+0020 is allowed,
> they think U+000A, U+0009, U+000D, U+000C are allowed as well, not to
> mention U+00A0 and a stream of other whitespace characters. And then they
> think that any number of them are acceptable, in any order.
> Implementations then end up all slightly disagreeing about what is
> whitespace and what isn't and pages end up being interpreted differently.
> 
> Whitespace should be avoided like the plague in attributes where
> interoperable results are expected from computers parsing the data.

This is a good argument.  We'll stick with using the T separator as
recommended by the W3C date time note.

> Human consumption is not an issue here anyway.

I want to avoid making this an issue of absolutes.

Human consumption is not as much of an issue here.

We do want to make the date time title reasonably possible for a human to
verify, but don't have to make it "ideally human readable".  That's what the
element contents of the <abbr> are for.

> With a T or with 
> whitespace, we should not be expecting ISO8601 dates to be the final
> presentation form.
> 
>  .date[title] { tooltip: datetime(attr(title)); }

Right.

Thanks Ian.

Tantek

From kmarks at technorati.com  Tue Jul 26 11:37:49 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Tue Jul 26 12:12:32 2005
Subject: [microformats-discuss] personal intro
In-Reply-To: <20050726151247.36686.qmail@web51012.mail.yahoo.com>
References: <20050726151247.36686.qmail@web51012.mail.yahoo.com>
Message-ID: <a6e70a3b860f137653a030b81a7b7a2b@technorati.com>

I've just realised I have never sent an intro to this list. I'm Kevin  
Marks, Principal Engineer at Technorati, and involved in microformats  
since before they had a name.
The main thing I work on at Technorati is making sense of data on the  
web through our spiders, so Microformats are a great fit for that.
Before joining Technorati, I spent 6 years working in QuickTime  
Engineering at Apple, and 8 years before that on New media development  
in England, so I know lots about the rich media side.

I am also co-chair (with Stewart Butterfield of Flickr) of Tag Tuesday,  
a monthly gathering of Tagging Implementers in San Francisco - we meet  
tonight at Varnish Gallery at 6.30pm. See http://tagtuesday.com for  
details (and 'hevent').

I wrote a post on Corante yesterday about how tags and other  
microformats complement each other, which you might find interesting:

http://www.corante.com/getreal/archives/2005/07/26/ 
kevin_marks_on_tag_decentralization.php

From kmarks at technorati.com  Tue Jul 26 12:11:37 2005
From: kmarks at technorati.com (Kevin Marks)
Date: Tue Jul 26 12:12:33 2005
Subject: [microformats-discuss] Re:ratings
In-Reply-To: <20050726151247.36686.qmail@web51012.mail.yahoo.com>
References: <20050726151247.36686.qmail@web51012.mail.yahoo.com>
Message-ID: <f52ce910fc29fa2820b5591457d35699@technorati.com>


On Jul 26, 2005, at 8:12 AM, Peter Jones wrote:

> I am interested in the rating of
> resources in order to enable their discovery. Recently
> I've been looking at the possibility of using tags as
> criteria against which to make ratings; there are some
> similarities with VoteLinks and use of the "rev"
> attribute.

Peter, do look at hReview, which details a way of expressing tagged 
ratings in a microformat:

http://microformats.org/wiki/hreview

From ian at hixie.ch  Tue Jul 26 16:19:11 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue Jul 26 16:19:18 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <e6ec604d0507260657a807d5e@mail.gmail.com>
References: <BF0B4272.5DAAA%tantek@cs.stanford.edu>
	<Pine.LNX.4.62.0507261315380.31816@dhalsim.dreamhost.com>
	<e6ec604d0507260657a807d5e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0507262312170.26726@dhalsim.dreamhost.com>

On Tue, 26 Jul 2005, Andy Skelton wrote:
> On 7/26/05, Ian Hickson <ian@hixie.ch> wrote:
> > Human consumption is not an issue here anyway. With a T or with
> > whitespace, we should not be expecting ISO8601 dates to be the final
> > presentation form.
> 
> If human consumption is not an issue, why not just use unix epoch seconds GMT?

Well I shouldn't say "not an issue". Not the major issue, maybe. Human 
consumption is still important (especially for authoring), but you have to 
balance it with issues like making interoperability easy.

My point was that if human consumption was the main issue, then ISO8601, 
whether with a space or without, wouldn't be good enough.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
From ian at hixie.ch  Tue Jul 26 16:32:12 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue Jul 26 16:32:15 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <BF0BAC9C.5DAE9%tantek@cs.stanford.edu>
References: <BF0BAC9C.5DAE9%tantek@cs.stanford.edu>
Message-ID: <Pine.LNX.4.62.0507262321220.26726@dhalsim.dreamhost.com>

On Tue, 26 Jul 2005, Tantek ?elik wrote:
> > 
> > Whitespace should be avoided like the plague in attributes where 
> > interoperable results are expected from computers parsing the data.
> 
> This is a good argument.  We'll stick with using the T separator as 
> recommended by the W3C date time note.

*nod*


> > Human consumption is not an issue here anyway.
> 
> I want to avoid making this an issue of absolutes.
> 
> Human consumption is not as much of an issue here.

Yeah, I spoke more strongly than I intended. Human consumption is always 
an issue; this is a hand-authored markup language. But these values aren't 
primarily aimed at humans, their main goal is unambiguous computer 
handling. Anyway, you understand.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
From lists at elegantchaos.com  Tue Jul 26 16:50:58 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Tue Jul 26 16:51:03 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <BF0BAC89.5DAE9%tantek@cs.stanford.edu>
References: <BF0BAC89.5DAE9%tantek@cs.stanford.edu>
Message-ID: <EE8172CD-2C3A-4126-884E-16A33293AB3E@elegantchaos.com>

On 26 Jul 2005, at 17:02, Tantek ?elik wrote:

> Why not? (or rather, why do you consider it "resort"ing?)  As long  
> as the
> markup is valid, there is something to be said for going with a simple
> solution that works.  There is nothing inherently wrong with  
> javascript and
> tool tips.

Sorry - maybe that sounded a bit harsh. There's nothing wrong with  
Javascript of course, but it would be nice if authors didn't have to  
add custom code to each page, or users install a plug-in of some sort  
on their browser, just to get locally formatted dates.

I do think there's something wrong from a user interface point of  
view with having to roll over a date to get a tool-tip, just to see  
the locally formatted date. However, as has been pointed out, similar  
code could probably inject the local format back between the <abbr>  
tags, making the tool tip solution unnecessary.

Incidentally, I think it might be preferable if the design pattern  
recommended using ISO8601 dates between the <abbr> tags as well as in  
the title attribute (maybe using a space instead of a "T" between the  
tags). This may not be quite as readable as the author's chosen  
"human-friendly" representation, but it does have the advantage of  
being fairly unambiguous, whereas other choices are more likely to  
cause confusion. I can see that there will be cases where the date  
needs to be specified more informally, so ISO8601 wouldn't be  
appropriate, but there are also lots of cases where the exact  
representation chosen doesn't matter very much, and in these cases it  
would help if the default choice was a good one.

I am speaking as a Brit who is easily (and often) confused by  
Americans writing the month before the day with no other context to  
indicate that I'm reading American and not English!

Mind you, I am speaking as a Brit who is easily confused, full stop. ;)

Or should that be "easily confused, period"?




From drernie at opendarwin.org  Tue Jul 26 17:13:54 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Tue Jul 26 17:13:56 2005
Subject: [microformats-discuss] Repeating cal events?
Message-ID: <7EA70958-60BB-4311-A89B-CE6C48119648@opendarwin.org>

Hi all,

Any suggestions on how best to represent the following recurring event?

from 12:10 pm - 12:50 pm every other Thursday for 34 weeks, starting  
June 23rd

I presume it is something like FREQ=WEEKLY*2, but I don't know enough  
iCalendar to figure it out, much less translate it into hCard.

-- Ernie P.
From lists at elegantchaos.com  Tue Jul 26 17:16:32 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Tue Jul 26 17:16:34 2005
Subject: [microformats-discuss] another personal intro
In-Reply-To: <a6e70a3b860f137653a030b81a7b7a2b@technorati.com>
References: <20050726151247.36686.qmail@web51012.mail.yahoo.com>
	<a6e70a3b860f137653a030b81a7b7a2b@technorati.com>
Message-ID: <EC3D6206-9C75-496A-9066-5E160CA4CA6C@elegantchaos.com>

Sorry, hadn't realised that I was supposed to introduce myself  
(having now realised, I was tempted to send my personal intro as some  
xml in cod hCard format, but my fatigue overcame my natural  
enthusiasm for a cheap joke).

I worked with Kevin Marks many moons ago in England. Since then I've  
worked writing multimedia applications at recording studios (Real  
World and Abbey Road), writing shareware, porting PC games to the Mac  
and then having them released by the publisher before they are ready,  
and more latterly writing cross platform user interface and  
foundation layers for original games (and then having them... blah  
blah).

I resigned from my games job last October because I'd clearly been  
working far too hard, for far too long, needed a break, and games  
people don't really understand the idea of a sabbatical. Since then I  
have been contracting, and catching up on all the interesting things  
that I've been too busy to play with whilst immersed in the games  
world. This party explains my presence on the list - the rest of the  
explanation being simply that in my experience, if Kevin is  
interested in something, it's probably interesting.

I am now, theoretically, a researcher working for a new learning  
technology research lab, based in Dublin, about to write the next  
great authoring environment to support user programming in the way  
that Hypercard once did.

Unfortunately this will remain theoretical until I get a contract, so  
technically I am still a freelancer, and available for weddings, bah- 
mitzvahs, etc.

Key fact: my favourite programming language is Dylan.
From carl.beeth at gmail.com  Tue Jul 26 17:39:14 2005
From: carl.beeth at gmail.com (Carl Beeth)
Date: Tue Jul 26 17:39:18 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <EE8172CD-2C3A-4126-884E-16A33293AB3E@elegantchaos.com>
References: <BF0BAC89.5DAE9%tantek@cs.stanford.edu>
	<EE8172CD-2C3A-4126-884E-16A33293AB3E@elegantchaos.com>
Message-ID: <e8ca2e11050726173974296fe5@mail.gmail.com>

On 7/27/05, Sam Deane <lists@elegantchaos.com> wrote:
> Incidentally, I think it might be preferable if the design pattern
> recommended using ISO8601 dates between the <abbr> tags as well as in
> the title attribute (maybe using a space instead of a "T" between the
> tags). This may not be quite as readable as the author's chosen
> "human-friendly" representation, but it does have the advantage of
> being fairly unambiguous, whereas other choices are more likely to
> cause confusion.

I always recommend to my clients to spell out the month whenever
possible and where not possible because of space restrictions to use
iso dates.
From tantek at cs.stanford.edu  Tue Jul 26 17:39:40 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jul 26 17:39:51 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <EE8172CD-2C3A-4126-884E-16A33293AB3E@elegantchaos.com>
Message-ID: <BF0C25DA.5DB67%tantek@cs.stanford.edu>

On 7/26/05 4:50 PM, "Sam Deane" <lists@elegantchaos.com> wrote:

> On 26 Jul 2005, at 17:02, Tantek ?elik wrote:
> 
>> Why not? (or rather, why do you consider it "resort"ing?)  As long
>> as the
>> markup is valid, there is something to be said for going with a simple
>> solution that works.  There is nothing inherently wrong with
>> javascript and
>> tool tips.
> 
> Sorry - maybe that sounded a bit harsh. There's nothing wrong with
> Javascript of course, but it would be nice if authors didn't have to
> add custom code to each page, or users install a plug-in of some sort
> on their browser, just to get locally formatted dates.

Yes, that's definitely in the "would be nice" category, but certainly not
required.


> I do think there's something wrong from a user interface point of
> view with having to roll over a date to get a tool-tip, just to see
> the locally formatted date.

No such requirement has been made.


> However, as has been pointed out, similar
> code could probably inject the local format back between the <abbr>
> tags, making the tool tip solution unnecessary.

Yes.


> Incidentally, I think it might be preferable if the design pattern
> recommended using ISO8601 dates between the <abbr> tags as well as in
> the title attribute (maybe using a space instead of a "T" between the
> tags).

Absolutely not.  We cannot ask that of content publishers.

The reality is, content publishers are *already* publishing their dates and
times however they want, and seems most natural to their audience, to their
context.

One of the principles of microformats is to adapt to current behaviors, and
*minimize* the changes we ask of publishers, in order to lower the barrier
to adoption as much as possible.

If you look at how people naturally talk about events, sometimes just
mentioning times and relative days like "today", "tomorrow", "Friday", it
quickly becomes obvious that there is a need for seamlessly allowing folks
to markup such human abbreviations for date and time with some embedding of
an absolute datetime that is reasonably easy for machines to parse, while
still remaining reasonably human verifiable.  The current <abbr> microformat
design pattern satisfies these objectives.


> This may not be quite as readable as the author's chosen
> "human-friendly" representation, but it does have the advantage of
> being fairly unambiguous,

Not an objective.

It is futile to try to get all authors/publishers to write their prose
unambiguously.

> I can see that there will be cases where the date
> needs to be specified more informally, so ISO8601 wouldn't be
> appropriate,

This is the 99% case.  Way more than even 80/20.

> but there are also lots of cases where the exact
> representation chosen doesn't matter very much,

I've yet to see this actually.  From a human readability standpoint, the
visible representation is very important.

> I am speaking as a Brit who is easily (and often) confused by
> Americans writing the month before the day with no other context to
> indicate that I'm reading American and not English!

Unfortunately, nothing we do will be able to solve the problem of different
cultures writing dates differently in their prose.

The best we can do in the short/medium term is adapt to various customs, and
provide a way for the ISO8601 date time to be closely bound to the visible
date which is culture-specific.

Thanks,

Tantek

From lists at elegantchaos.com  Tue Jul 26 18:02:58 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Tue Jul 26 18:03:02 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <BF0C25DA.5DB67%tantek@cs.stanford.edu>
References: <BF0C25DA.5DB67%tantek@cs.stanford.edu>
Message-ID: <D85B945A-F9AE-4E25-B68D-A55FA0AFE645@elegantchaos.com>

>> I do think there's something wrong from a user interface point of
>> view with having to roll over a date to get a tool-tip, just to see
>> the locally formatted date.
>
> No such requirement has been made.

Someone suggested it though - I was merely commenting on the suggestion.


> One of the principles of microformats is to adapt to current  
> behaviors, and
> *minimize* the changes we ask of publishers, in order to lower the  
> barrier
> to adoption as much as possible.

Fair enough. Personally I think you can remain true to that principle  
whilst giving good advice about how to use the microformat. I was  
talking about recommendations not requirements. Perhaps even  
"recommend" is too strong a word though.


>> but there are also lots of cases where the exact
>> representation chosen doesn't matter very much,
>>
>
> I've yet to see this actually.  From a human readability  
> standpoint, the
> visible representation is very important.

With relative dates, and dates in general in pure prose, I think you  
are right. But there are plenty of places where lists of dates are  
presented on the web (event lists or search results for example), and  
places where dates are displayed as meta-data tagging some prose  
(creation and modification dates on blog posts for example). In these  
cases the choice of representation often appears to be arbitrary and  
parochial, and it wouldn't do any harm to make people aware of the  
issues.
From coretxt at gmail.com  Tue Jul 26 22:30:39 2005
From: coretxt at gmail.com (Mark Rickerby)
Date: Tue Jul 26 22:30:42 2005
Subject: [microformats-discuss] encoding adr and tel types in hCard
Message-ID: <ffa20f2205072622301a786fbb@mail.gmail.com>

Hi all...

Am in the process of putting some contact pages online for a client,
and thought it would be a great idea to make them as vCard compatible
as possible. So far I haven't done anything with hCard beyond the most
basic personal contact information, and subsequently, have run into a
bit of confusion trying to encode business address and telephone
details without adding a whole lot of extra nested tags.

Basically, my approach was to focus on the visual display first and
foremost, and then once the visual design was complete, work
additional semantics into the HTML. I've been testing pages with the
XSL stylesheets from http://suda.co.uk/projects/X2V/ and it seems to
work fine - but trying to add the additional semantics of a "business"
has proved to be a little bit tricky.

Below is an abbreviated snippet of the markup I'm using:

    <h3>Visit:</h3>
    <div class="adr">
       <span class="street-address">Level 6, Press House, Willis St</span>,
       <span class="locality">Wellington</span>
    </div>

    <h3>Post:</h3>
    <div class="adr">
       <span class="postal">PO Box 27-290 Wellington</span>
    </div>

The way the street address is encoded here works absolutely fine, but
trying to add an additional layer of semantics to denote this as a
"business" contact is what I'm unsure about.

Firstly, is it wrong to use the "adr" element twice here? This postal
information isn't showing up at all from the X2V transform.

Ideally, I would like to add the "address types" to the base
containing element, which would alleviate the need to add an
additional <span> to denote this information...

eg:

  <div class="adr work">
      <span class="street">...</span>
      <span class="locality">...</span>
  </div>

rather than:

  <div class="adr">
     <span class="work">
       <span class="street">...</span>
       <span class="locality">...</span>
     </span>
  </div>

I'm not sure how sensible this idea is, but it may also relate to
encoding phone numbers. Currently X2V does great things if you encode
your phone numbers like:

  <div class="tel"><span class="fax">(+64) etc...</span></div>

This is cool, but I'm wondering if it is the best way. I would be
absolutely fine with this if I was adding separate icons to the layout
for different tel types, but very rarely would I ever need that much
specificity.

So does <div class="tel fax"></div>, etc make sense, or is it always
better to encode the specific types as a separate child elements?

In my case, the presentation *has* to drive the markup. The following
seems to be right...

  <div class="tel">
     <span class="fax">...</span>
     <span class="work">...</span>
     <span class="cell">...</span>
  </div>

... but this won't always be possible presentation wise, for example,
when the design needs to show phone numbers on separate lines (or
<gasp> uses a <table> to display the details). Which means lots of
separate < class="tel" > elements.

Hopefully this makes sense, sorry if it's confused, or I'm overly
repeating myself.

The examples on the wiki don't yet go into this level of detail. Once
I'm more clear on how addresses should be encoded, I'd be happy to add
some additional examples there.

Regards,
Mark
From ryan at technorati.com  Tue Jul 26 23:24:53 2005
From: ryan at technorati.com (Ryan King)
Date: Tue Jul 26 23:25:00 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <EE8172CD-2C3A-4126-884E-16A33293AB3E@elegantchaos.com>
References: <BF0BAC89.5DAE9%tantek@cs.stanford.edu>
	<EE8172CD-2C3A-4126-884E-16A33293AB3E@elegantchaos.com>
Message-ID: <7C1ADB06-9347-4787-B2C7-0C93906135C5@technorati.com>

On Jul 26, 2005, at 4:50 PM, Sam Deane wrote:
> I am speaking as a Brit who is easily (and often) confused by  
> Americans writing the month before the day with no other context to  
> indicate that I'm reading American and not English!

Cross cultural understanding is outside the scope of microformats.

Famine, war, volcanoes... those we can do something about. :-D

> Mind you, I am speaking as a Brit who is easily confused, full  
> stop. ;)
>
> Or should that be "easily confused, period"?

-ryan
From coretxt at gmail.com  Wed Jul 27 00:21:47 2005
From: coretxt at gmail.com (Mark Rickerby)
Date: Wed Jul 27 00:21:49 2005
Subject: [microformats-discuss] Re: encoding adr and tel types in hCard
In-Reply-To: <ffa20f2205072622301a786fbb@mail.gmail.com>
References: <ffa20f2205072622301a786fbb@mail.gmail.com>
Message-ID: <ffa20f2205072700211f936330@mail.gmail.com>

> So does <div class="tel fax"></div>, etc make sense, or is it always
> better to encode the specific types as a separate child elements?
> 

[from http://microformats.org/wiki/hcard]
- For properties which can be plural (e.g. "TEL"), each class instance
should create a instance of that property. Plural properties with
subtypes (e.g. TEL with WORK, HOME, CELL) can be optimized to share a
common element for the property itself, with each instance of subtype
being an appropriately classed descendant of the property element.

I guess I will just assume this applies to the ADR property as well,
and treat the case of a single instance of TEL or ADR with multiple
subtypes as an "optimization". Maybe I was trying to optimize too far.

Regards,
Mark
From lists at elegantchaos.com  Wed Jul 27 02:59:00 2005
From: lists at elegantchaos.com (Sam Deane)
Date: Wed Jul 27 02:59:11 2005
Subject: [microformats-discuss] International date formats
In-Reply-To: <7C1ADB06-9347-4787-B2C7-0C93906135C5@technorati.com>
References: <BF0BAC89.5DAE9%tantek@cs.stanford.edu>
	<EE8172CD-2C3A-4126-884E-16A33293AB3E@elegantchaos.com>
	<7C1ADB06-9347-4787-B2C7-0C93906135C5@technorati.com>
Message-ID: <1A7B2B5A-5D2F-45E3-B968-898A0433227C@elegantchaos.com>

On 27 Jul 2005, at 07:24, Ryan King wrote:

> Cross cultural understanding is outside the scope of microformats.
>
> Famine, war, volcanoes... those we can do something about. :-D

Hah! Point taken.

Anyway, I went back and read http://microformats.org/about again, and  
have now seen the error of my ways. Nuff said.
From soundrater at yahoo.com  Wed Jul 27 08:27:55 2005
From: soundrater at yahoo.com (Peter Jones)
Date: Wed Jul 27 08:28:11 2005
Subject: [microformats-discuss] Re:ratings
In-Reply-To: <f52ce910fc29fa2820b5591457d35699@technorati.com>
Message-ID: <20050727152755.14891.qmail@web51006.mail.yahoo.com>

Kevin Marks wrote:

> Peter, do look at hReview, which details a way of
> expressing tagged ratings in a microformat:

Thanks for pointing out hReview - I have looked at it
and there were a couple of reasons why I thought
VoteLinks was more suitable/applicable:

1. Reviews require quite a lot of effort to compile
(when compared to ratings) so capturing ratings under
a
*Review* microformat could put some people off. This
may reduce the amount of ratings data created by
users.

2. Whilst it is possible to strip out the body of the
review from hReview in order to use tags as criteria
against which to make ratings, there is still this
issue of using the "rel" or "rev" attribute.

So, stripping down the Multidimensional Restaurant
hReview example provided in hReview would leave the
restaurant url,

<a class="url"
href="http://cafeborrone.com">cafeborrone.com</a>

and the rating (which in this case is for food),

<a href="http://en.wikipedia.org/wiki/Food"
rel="tag">Food: <span class="rating">18</span>/<span>
class="best">30</span></a>

This may work fine, but is based on the tag assumption
that an external tagspace is required to define the
tag, hence the use of rel="tag". All I am looking to
do
is indicate a criterion against which to make the
rating of an external resource, and I doubt it needs
to
go as far as having a defined tagspace.

Could ratings be done more simply if structured along
the lines of VoteLinks? So, for example:

<a rev="vote-for" href="http://ragingcow.blogspot.com"
title="neat spoof">Raging Cow</a>

could be coded as:

<a rev="rating" href="http://ragingcow.blogspot.com"
title="4outof5">Spoof</a>

This could indicate a rating of *4outof5* for the
resource http://ragingcow.blogspot.com against the
criteria of *Spoof*. A selection of criteria, each
with
their own rating, could be highly informative and are
relatively easy to code. If such information were
included in a blog or website, that would serve as the
proxy for the person who wrote it and the time of the
blog entry would correspond to the time of the rating.

I think this issue of using *rel* for tags (i.e.
incoming tags) to say something about a post could be
confusing if people want to use tags as criteria for
rating an external resource along the lines of the
*rev* attribute. So it may be best if I avoid the idea
of using a *tag* as the criteria against which to make
a rating for an external resource, and just stick to
establishing rating criteria of some sort without
calling it a tag.

Anyway, back to why I joined this list - are there any
plans for a simple rating microformat that just
records
the resource being rated as the destination of a link,
the rating, and the criteria against which the
resource
has been rated? I'm assuming the rater ID and the time
of the rating would be indicated by the website/blog
where the rating was posted.

Many thanks,

Peter.










		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
From ryan at technorati.com  Wed Jul 27 09:14:31 2005
From: ryan at technorati.com (Ryan King)
Date: Wed Jul 27 09:14:35 2005
Subject: [microformats-discuss] Re:ratings
In-Reply-To: <20050727152755.14891.qmail@web51006.mail.yahoo.com>
References: <20050727152755.14891.qmail@web51006.mail.yahoo.com>
Message-ID: <846D41F4-FC01-4518-A46D-D6429A850F10@technorati.com>

On Jul 27, 2005, at 8:27 AM, Peter Jones wrote:

> Kevin Marks wrote:
>> Peter, do look at hReview, which details a way of
>> expressing tagged ratings in a microformat:
>
> Thanks for pointing out hReview - I have looked at it
> and there were a couple of reasons why I thought
> VoteLinks was more suitable/applicable:
>
> 1. Reviews require quite a lot of effort to compile
> (when compared to ratings) so capturing ratings under
> a
> *Review* microformat could put some people off. This
> may reduce the amount of ratings data created by
> users.

Right, its quite possible that you wouldn't want to use the entire  
hReview format. But I think Kevin was trying to point out the part of  
hReview where you can markup rated tags.

> 2. Whilst it is possible to strip out the body of the
> review from hReview in order to use tags as criteria
> against which to make ratings, there is still this
> issue of using the "rel" or "rev" attribute.

I'm not sure what the issue is here. Could you elaborate?

> So, stripping down the Multidimensional Restaurant
> hReview example provided in hReview would leave the
> restaurant url,
>
> <a class="url"
> href="http://cafeborrone.com">cafeborrone.com</a>
>
> and the rating (which in this case is for food),
>
> <a href="http://en.wikipedia.org/wiki/Food"
> rel="tag">Food: <span class="rating">18</span>/<span>
> class="best">30</span></a>
>
> This may work fine, but is based on the tag assumption
> that an external tagspace is required to define the
> tag,

Yes.

> hence the use of rel="tag". All I am looking to
> do
> is indicate a criterion against which to make the
> rating of an external resource, and I doubt it needs
> to
> go as far as having a defined tagspace.

Why couldn't you reuse an existing tagspace?

> Could ratings be done more simply if structured along
> the lines of VoteLinks? So, for example:
>
> <a rev="vote-for" href="http://ragingcow.blogspot.com"
> title="neat spoof">Raging Cow</a>
>
> could be coded as:
>
> <a rev="rating" href="http://ragingcow.blogspot.com"
> title="4outof5">Spoof</a>

Why hide the 4outof5 in the title?

> This could indicate a rating of *4outof5* for the
> resource http://ragingcow.blogspot.com against the
> criteria of *Spoof*. A selection of criteria, each
> with
> their own rating, could be highly informative and are
> relatively easy to code. If such information were
> included in a blog or website, that would serve as the
> proxy for the person who wrote it and the time of the
> blog entry would correspond to the time of the rating.
>
> I think this issue of using *rel* for tags (i.e.
> incoming tags) to say something about a post could be
> confusing if people want to use tags as criteria for
> rating an external resource along the lines of the
> *rev* attribute. So it may be best if I avoid the idea
> of using a *tag* as the criteria against which to make
> a rating for an external resource, and just stick to
> establishing rating criteria of some sort without
> calling it a tag.

I think I've just realized what you're trying to accomplish here. It  
appears you're trying to figure out a way to apply tags (with a  
rating) to an external resource.

If so, have you looked at xFolk [http://microformats.org/wiki/xfolk] ?

-ryan

> Anyway, back to why I joined this list - are there any
> plans for a simple rating microformat that just
> records
> the resource being rated as the destination of a link,
> the rating, and the criteria against which the
> resource
> has been rated? I'm assuming the rater ID and the time
> of the rating would be indicated by the website/blog
> where the rating was posted.
>
> Many thanks,
>
> Peter.

From tantek at cs.stanford.edu  Wed Jul 27 12:28:00 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Wed Jul 27 12:28:04 2005
Subject: [microformats-discuss] Re:ratings
In-Reply-To: <20050727152755.14891.qmail@web51006.mail.yahoo.com>
Message-ID: <BF0D2E0D.5DC42%tantek@cs.stanford.edu>

On 7/27/05 8:27 AM, "Peter Jones" <soundrater@yahoo.com> wrote:

> Kevin Marks wrote:
> 
>> Peter, do look at hReview, which details a way of
>> expressing tagged ratings in a microformat:
> 
> Thanks for pointing out hReview - I have looked at it
> and there were a couple of reasons why I thought
> VoteLinks was more suitable/applicable:
> 
> 1. Reviews require quite a lot of effort to compile
> (when compared to ratings) so capturing ratings under
> a *Review* microformat could put some people off.

Why? Ideally systems shouldn't bother the user with the underlying
format(s).

In other words, the user is rating something or reviewing it, rather than
"writing an hReview".

It would be trivial to take the current hReview creator

 http://microformats.org/code/hreview/creator

and strip it down to a "rating creator" that only allowed you to rate a
resource, and yet, still output valid hReview markup, which could be
properly parsed/aggregated/indexed etc.


> So, stripping down the Multidimensional Restaurant
> hReview example provided in hReview would leave the
> restaurant url,
> 
> <a class="url"
> href="http://cafeborrone.com">cafeborrone.com</a>

Note that this simplification has thrown out some valuable information about
the restaurant being a business with a location etc.


> and the rating (which in this case is for food),
> 
> <a href="http://en.wikipedia.org/wiki/Food"
> rel="tag">Food: <span class="rating">18</span>/<span>
> class="best">30</span></a>
> 
> This may work fine, but is based on the tag assumption
> that an external tagspace is required to define the
> tag, hence the use of rel="tag".

Yes.  Using tagspaces for disambiguation is core to the rel-tag spec.

> All I am looking to
> do
> is indicate a criterion against which to make the
> rating of an external resource, and I doubt it needs
> to
> go as far as having a defined tagspace.

I applaud your effort to make it as simple as possible.

But when it has already been tried and failed, it's worth not repeating
others' mistakes (unless you have some reason to believe your attempt will
have a different result).

Arbitrary keyword/category/tagging systems where the keywords themselves are
not tied to any kind of definition or other context have been shown to be
quite noisy and not very useful.

Delicious showed that by linking a tag to a page that showed URLs with that
tag, it "defined" what was meant by that tag.

Flickr demonstrated the same with tags on photos.

rel-tag has generalized this pattern to arbitrary tagspaces (even user
tagspaces) and thus enabled folks to pick their tagspace rather than being
bound to the tagspace of the service that they are using.


> Could ratings be done more simply if structured along
> the lines of VoteLinks? So, for example:
> 
> <a rev="vote-for" href="http://ragingcow.blogspot.com"
> title="neat spoof">Raging Cow</a>
> 
> could be coded as:
> 
> <a rev="rating" href="http://ragingcow.blogspot.com"
> title="4outof5">Spoof</a>

As Ryan pointed out, it is undesirable to hide (or even partially hide) such
key user authored information as the 4 out of 5 rating.

This technique is essentially trying to squeeze more into a hyperlink than
can be done in a good way.

> I think this issue of using *rel* for tags (i.e.
> incoming tags) to say something about a post could be
> confusing if people want to use tags as criteria for
> rating an external resource along the lines of the
> *rev* attribute.

Also as Ryan said, xFolk addresses this:

 http://microformats.org/wiki/xfolk

> So it may be best if I avoid the idea
> of using a *tag* as the criteria against which to make
> a rating for an external resource, and just stick to
> establishing rating criteria of some sort without
> calling it a tag.

Yes, the simple case in hReview is to just offer an overall rating for the
item.


> Anyway, back to why I joined this list - are there any
> plans for a simple rating microformat that just
> records
> the resource being rated as the destination of a link,
> the rating, and the criteria against which the
> resource
> has been rated?

I believe hReview already addresses that general use case.

Do you have a specific use case or example you can point to?

Thanks,

Tantek

From soundrater at yahoo.com  Thu Jul 28 04:38:23 2005
From: soundrater at yahoo.com (Peter Jones)
Date: Thu Jul 28 04:38:26 2005
Subject: [microformats-discuss] Re:ratings
In-Reply-To: <846D41F4-FC01-4518-A46D-D6429A850F10@technorati.com>
Message-ID: <20050728113823.21002.qmail@web51010.mail.yahoo.com>

Ryan King <ryan@technorati.com> wrote:

> I think I've just realized what you're trying to
> accomplish here. It appears you're trying to figure
> out a way to apply tags (with a rating) to an
> external resource.

Yes, that's right - sorry if I failed to make this
clear from the start.

> If so, have you looked at xFolk
> [http://microformats.org/wiki/xfolk] ?

If xFolk is the way to achieve this objective then
great. I presume it is anticipated that xFolk would be
combined with the rating part of hReview to do this.

Also,Tantek ?? elik wrote:

> Ideally systems shouldn't bother the user with the
> underlying format(s).

> In other words, the user is rating something or
> reviewing it, rather than "writing an hReview".

Yes, I accept this point that the user shouldn't be
concerned with the underlying format(s). Ideally there
is an underlying format in which the data can be
simply encoded.

> Do you have a specific use case or example you
> can point to?

I was thinking of trying to avoid the whole review
writing process by limiting myself to a number of
ratings against criteria (or what I was calling tags).
If the criteria are well chosen this could capture the
essence of a resource and enable its discovery. I was
looking for a ratings microformat that could encode
this info (rating, criteria, resource url).

I've cobbled an example together at
http://soundrater.blogspot.com in the posting dated
Thursday, July 28, 2005.

Regards,

Peter.




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
From bud at thecommunityengine.com  Thu Jul 28 16:06:13 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 28 16:06:15 2005
Subject: [microformats-discuss] A 10 line script to identify and process any
	microformat
Message-ID: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>

Dear all:

I've been inspired by various microformat scripting efforts (in  
particular George Hotelling's) and have come up with a 10 line  
greasemonkey script that can identify and process any microformatted  
content.  You can access the script here:

http://thecommunityengine.com/resources/xfolk-colorize.user.js

The key insight in the script is to use XPath to identify the  
microformatted content.  I provide an explanation of how to modify my  
XPath selector to work with your favorite microformat here:

http://thecommunityengine.com/home/archives/2005/07/greasemonkey_mi.html

under the heading:

"How xfolk-colorize works"

It really is as simple as my subject line indicates.  Of course, you  
may want to do rather more complex things with your microformat than  
what I have done, so your final script may be longer.  My goal in  
writing this was to provide a very simple, clear example.  I  
apologize if the rest of the blog post is a little long-winded.  I  
tend to pontificate.

Bud
From alf at hubmed.org  Thu Jul 28 17:48:26 2005
From: alf at hubmed.org (Alf Eaton)
Date: Thu Jul 28 17:48:34 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
Message-ID: <EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>

On 29 Jul 2005, at 01:06, Bud Gibson wrote:

> Dear all:
>
> I've been inspired by various microformat scripting efforts (in  
> particular George Hotelling's) and have come up with a 10 line  
> greasemonkey script that can identify and process any  
> microformatted content.  You can access the script here:
>
> http://thecommunityengine.com/resources/xfolk-colorize.user.js

Unfortunately, your XPath selector will also match classNames like  
mixfolkentry, boxfolkentry and xfolkentry2.

This is what I'm using:

-------------

var mf = 'hreview';

var micropath = "//*[contains(@class,'" + mf + "')]";
var micromatch = new RegExp('\\b' + mf + '\\b');

var mc = document.evaluate(micropath, document, null,  
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i = 0; i < mc.snapshotLength; i++) {
     iNode = mc.snapshotItem(i);
     if (iNode.className.match(micromatch))
         doSomething();
}

-------------

The problem with all of these approaches is that once you want to  
parse or extract more than one microformat, you have to check each  
element of the page for each of a big list of possible classnames.  
I'd like to propose, therefore (and maybe it's been proposed before),  
that each microformat should have one common classname: 'microdata',  
say. Then the main selector can be
var mc = document.evaluate(//*[contains(@class,'microdata')]",  
document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
and you only have to check the big list of possible classnames  
against that one node.

For example, <div class="microdata xfolkentry"> or <div  
class="microdata hreview"> .

alf.

From lucas.gonze at gmail.com  Thu Jul 28 18:38:23 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Thu Jul 28 18:38:25 2005
Subject: [microformats-discuss] wiki account problem
Message-ID: <ab069aa00507281838199b427e@mail.gmail.com>

Trying to create an account on the wiki, I always get "You have not
specified a valid user name."  Is the wiki locked, or is this a bug?
From limbo at speakeasy.net  Thu Jul 28 18:42:56 2005
From: limbo at speakeasy.net (Eran)
Date: Thu Jul 28 18:43:00 2005
Subject: [microformats-discuss] wiki account problem
In-Reply-To: <ab069aa00507281838199b427e@mail.gmail.com>
Message-ID: <002e01c593de$d894cb60$77abca8a@hellonwheels>

iirc wiki names must be in CamelCase.

Eran.

> -----Original Message-----
> From: microformats-discuss-bounces@microformats.org 
> [mailto:microformats-discuss-bounces@microformats.org] On 
> Behalf Of Lucas Gonze
> Sent: Thursday, July 28, 2005 6:38 PM
> To: Microformats Discuss
> Subject: [microformats-discuss] wiki account problem
> 
> 
> Trying to create an account on the wiki, I always get "You 
> have not specified a valid user name."  Is the wiki locked, 
> or is this a bug? _______________________________________________
> microformats-discuss mailing list 
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
> 

From lucas.gonze at gmail.com  Thu Jul 28 18:56:42 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Thu Jul 28 18:56:43 2005
Subject: [microformats-discuss] wiki account problem
In-Reply-To: <002e01c593de$d894cb60$77abca8a@hellonwheels>
References: <ab069aa00507281838199b427e@mail.gmail.com>
	<002e01c593de$d894cb60$77abca8a@hellonwheels>
Message-ID: <ab069aa0050728185661a7aeb5@mail.gmail.com>

On 7/28/05, Eran <limbo@speakeasy.net> wrote:
> iirc wiki names must be in CamelCase.

That was just the ticket.  Thanks, Eran.

There's a simple usability fix -- add a tip/example to the account
creation page to show the camel case -- "FirstLast".

- Lucas

> 
> Eran.
> 
> > -----Original Message-----
> > From: microformats-discuss-bounces@microformats.org
> > [mailto:microformats-discuss-bounces@microformats.org] On
> > Behalf Of Lucas Gonze
> > Sent: Thursday, July 28, 2005 6:38 PM
> > To: Microformats Discuss
> > Subject: [microformats-discuss] wiki account problem
> >
> >
> > Trying to create an account on the wiki, I always get "You
> > have not specified a valid user name."  Is the wiki locked,
> > or is this a bug? _______________________________________________
> > microformats-discuss mailing list
> > microformats-discuss@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-discuss
> >
> 
>
From bud at thecommunityengine.com  Thu Jul 28 19:13:38 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Thu Jul 28 19:13:39 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
Message-ID: <32371F0B-F47C-4751-85A9-C6644E75D732@thecommunityengine.com>

Alf:

I realized the xpath selector was imperfect in this way but figured  
the types of cases you mentioned would be rare enough to just ignore.

A nitpicking issue with your solution is that it assumes people are  
using class attribute values. I suppose that could be fixed easily  
enough.

Would you mind if I made an update to my post mentioning the issue  
you raise and your solution for how to avoid it?  I think it could  
arise in other circumstances that I cannot think of off the top of my  
head, and I'd like people to be aware of the workaround.

Bud

On Jul 28, 2005, at 20:48, Alf Eaton wrote:


> On 29 Jul 2005, at 01:06, Bud Gibson wrote:
>
>
>
>> Dear all:
>>
>> I've been inspired by various microformat scripting efforts (in  
>> particular George Hotelling's) and have come up with a 10 line  
>> greasemonkey script that can identify and process any  
>> microformatted content.  You can access the script here:
>>
>> http://thecommunityengine.com/resources/xfolk-colorize.user.js
>>
>>
>
> Unfortunately, your XPath selector will also match classNames like  
> mixfolkentry, boxfolkentry and xfolkentry2.
>
> This is what I'm using:
>
> -------------
>
> var mf = 'hreview';
>
> var micropath = "//*[contains(@class,'" + mf + "')]";
> var micromatch = new RegExp('\\b' + mf + '\\b');
>
> var mc = document.evaluate(micropath, document, null,  
> XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
> for (var i = 0; i < mc.snapshotLength; i++) {
>     iNode = mc.snapshotItem(i);
>     if (iNode.className.match(micromatch))
>         doSomething();
> }
>
> -------------
>
> The problem with all of these approaches is that once you want to  
> parse or extract more than one microformat, you have to check each  
> element of the page for each of a big list of possible classnames.  
> I'd like to propose, therefore (and maybe it's been proposed  
> before), that each microformat should have one common classname:  
> 'microdata', say. Then the main selector can be
> var mc = document.evaluate(//*[contains(@class,'microdata')]",  
> document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
> and you only have to check the big list of possible classnames  
> against that one node.
>
> For example, <div class="microdata xfolkentry"> or <div  
> class="microdata hreview"> .
>
> alf.
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>


From ryan at technorati.com  Thu Jul 28 19:56:58 2005
From: ryan at technorati.com (Ryan King)
Date: Thu Jul 28 19:57:01 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
Message-ID: <8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>

On Jul 28, 2005, at 5:48 PM, Alf Eaton wrote:
> The problem with all of these approaches is that once you want to  
> parse or extract more than one microformat, you have to check each  
> element of the page for each of a big list of possible classnames.  
> I'd like to propose, therefore (and maybe it's been proposed before),

It has.

> that each microformat should have one common classname:  
> 'microdata', say.

This has been proposed before and rejected for several reasons:

1. We're optimizing for publishers, not consumers. Yes, parsing  
microformats is *hard* and no one is claiming its easy.
2. This seems like needless complexity. Though its tough, you can get  
the data out.
3. A universal parsing  apparatus is not possible. You could probably  
get a system that's pretty flexible and can handle a good number of  
formats, but you will not likely be able to create something with  
unlimited abilities.
4. What happens when everyone's using microformats everywhere? :D

> Then the main selector can be
> var mc = document.evaluate(//*[contains(@class,'microdata')]",  
> document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
> and you only have to check the big list of possible classnames  
> against that one node.
>
> For example, <div class="microdata xfolkentry"> or <div  
> class="microdata hreview"> .

BTW, this is probably a good discussion to have on the microformats- 
discuss list.

As you may know (or may not), the dev list is not open subscription,  
but is limited to people who have a microformat implementation.  
Having said that, if you think you belong on the dev list, feel free  
to speak up (not on the list, though, email me directly).

-ryan
From coretxt at gmail.com  Thu Jul 28 21:57:10 2005
From: coretxt at gmail.com (Mark Rickerby)
Date: Thu Jul 28 21:57:49 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
Message-ID: <ffa20f22050728215713b66ad@mail.gmail.com>

> 1. We're optimizing for publishers, not consumers. Yes, parsing
> microformats is *hard* and no one is claiming its easy.
> 2. This seems like needless complexity. Though its tough, you can get
> the data out.
> 3. A universal parsing  apparatus is not possible. You could probably
> get a system that's pretty flexible and can handle a good number of
> formats, but you will not likely be able to create something with
> unlimited abilities.
> 4. What happens when everyone's using microformats everywhere? :D
> 
> > Then the main selector can be
> > var mc = document.evaluate(//*[contains(@class,'microdata')]",
> > document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
> > and you only have to check the big list of possible classnames
> > against that one node.
> >
> > For example, <div class="microdata xfolkentry"> or <div
> > class="microdata hreview"> .
> 
> BTW, this is probably a good discussion to have on the microformats-
> discuss list.
> 

One thing I think it is worth pointing out with regards this
discussion, is that there's a big difference between *identifying*
that a microformat is in use, and actually *processing* the
microformat.

Identification is fairly straightforward, as these GM scripts have
demonstrated. But what's involved in processing? You need to parse the
information into a data structure, and then do something with that
data structure, which would probably take a lot more than 3-4 lines of
javascript, not to mention the design/creativity involved in doing
something useful with the data. But therein lies the potential...

You can post suggestions/requests for Greasemonkey scripts at:
http://dunck.us/collab/GreaseMonkeyUserScriptRequest

If you have something microformats specific that you'd like to see a
Greasemonkey script to handle, please post it there.

As the wiki says, "smart people are listening".

/M
From lucas.gonze at gmail.com  Thu Jul 28 22:42:14 2005
From: lucas.gonze at gmail.com (Lucas Gonze)
Date: Thu Jul 28 22:42:17 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
Message-ID: <ab069aa005072822425358ecd5@mail.gmail.com>

On 7/28/05, Ryan King <ryan@technorati.com> wrote:
> This has been proposed before and rejected for several reasons:

It was rejected?  By who, and under what authority?
From bud at thecommunityengine.com  Fri Jul 29 05:13:27 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul 29 05:13:28 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <ffa20f22050728215713b66ad@mail.gmail.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
Message-ID: <33B70A8E-6742-4923-B077-703D36B4EE03@thecommunityengine.com>

On Jul 29, 2005, at 0:57, Mark Rickerby wrote:


> Identification is fairly straightforward, as these GM scripts have
> demonstrated. But what's involved in processing? You need to parse the
> information into a data structure, and then do something with that
> data structure, which would probably take a lot more than 3-4 lines of
> javascript, not to mention the design/creativity involved in doing
> something useful with the data. But therein lies the potential...
>
>

Mark (and others who may wish to join in):

Thanks for the recommendation regarding script requests.  Aside from  
some (in my opinion) minor corner cases, I agree that GM cracks the  
identification issue nicely, and I would like to see more people  
adopt the approaches shown in my script and Alf's more developed  
examples (there's a great one here: http://hublog.hubmed.org/files/ 
hreviewextractor.user.js that does essentially the same thing for  
hReview that Hotelling does for hCard but with a lot less code  
devoted to identification).

As for needing to parse the microformat into data structures, the  
proof is in the pudding there.  You could just continue to use XPath,  
and that might even be desirable given the semistructured nature of  
microformats.  There are also some times where you may be better off  
doing the heavy processing on a server.  All of these topics might be  
better discussed in another forum, I just raise them.

A couple of questions for any of you that I would be happy to  
continue off-list if appropriate:

1.  Would you be willing to make a special area on the wiki for  
microformat-oriented scripts?  That might be a real help for people  
trying to figure out how to script microformats.  Also, as I mention  
in my blog post concerning this little script,  MF and GM seem to go  
hand-in-hand.

2.  Do you have any ideas for how to promote learning to hack  
microformats?  I posted my script here and kept it super simple for  
didactic purposes.  I could see posting a whole set of hack-like  
tutorials.

Bud

From alf at hubmed.org  Fri Jul 29 05:23:47 2005
From: alf at hubmed.org (Alf Eaton)
Date: Fri Jul 29 05:23:53 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <C2163EB8-D994-4271-AB0E-EEF03D076725@umich.edu>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
	<C2163EB8-D994-4271-AB0E-EEF03D076725@umich.edu>
Message-ID: <D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>

On 29 Jul 2005, at 14:10, Bud Gibson wrote:

> Thanks for the recommendation regarding script requests.  Aside  
> from some (in my opinion) minor corner cases, I agree that GM  
> cracks the identification issue nicely, and I would like to see  
> more people adopt the approaches shown in my script and Alf's more  
> developed examples (there's a great one here: http:// 
> hublog.hubmed.org/files/hreviewextractor.user.js that does  
> essentially the same thing for hReview that Hotelling does for  
> hCard but with a lot less code devoted to identification).

That script's a bit old and doesn't do the extra className checking  
that I recommended yesterday. Also it's a different approach to  
George Hotelling's script as it picks out the microformat fragment  
and works on that, rather than passing the whole page off to an  
external processor. What you end up with is just the raw XML, rather  
than a processed hCard -> ICS conversion. However...

> As for needing to parse the microformat into data structures, the  
> proof is in the pudding there.  You could just continue to use  
> XPath, and that might even be desirable given the semistructured  
> nature of microformats.  There are also some times where you may be  
> better off doing the heavy processing on a server.  All of these  
> topics might be better discussed in another forum, I just raise them.

I have a Greasemonkey script at the moment which identifies a  
microcontent fragment, loads in an external XSLT file, processes the  
fragment and can then insert it back into the document/put it in a  
data URI, do whatever you want with it.  At the moment I'm trying to  
figure out how to make it not request the XSLT file from my server on  
every page view that contains a fragment, but it depends on  
Greasemonkey variable scoping which is changing too much this week.

The main point then is - what do you want to do with this data once  
you have extracted and processed it? POSTing it to a remote server is  
one idea, but then you could do the processing on the server anyway.  
I haven't really though of anything useful yet :-)

alf.
From bud at thecommunityengine.com  Fri Jul 29 06:17:57 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul 29 06:17:59 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
	<C2163EB8-D994-4271-AB0E-EEF03D076725@umich.edu>
	<D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
Message-ID: <990A1D7B-768D-47AD-BB2C-8B4EFD543996@thecommunityengine.com>

No slight intended to George, just a remark on processing strategy.   
This might be better continued on the dev list or by private  
correspondence.

Bud
On Jul 29, 2005, at 8:23, Alf Eaton wrote:

> That script's a bit old and doesn't do the extra className checking  
> that I recommended yesterday. Also it's a different approach to  
> George Hotelling's script as it picks out the microformat fragment  
> and works on that, rather than passing the whole page off to an  
> external processor. What you end up with is just the raw XML,  
> rather than a processed hCard -> ICS conversion. However...
>

From drernie at opendarwin.org  Fri Jul 29 10:19:28 2005
From: drernie at opendarwin.org (Dr. Ernie Prabhakar)
Date: Fri Jul 29 10:19:27 2005
Subject: [microformats-discuss] Are microformats "data-first"?
Message-ID: <40549740-AFAD-4DDB-A1A2-71E3B2BF7825@opendarwin.org>

Hi all,

I'm still trying to get my head around the "zen" of microformats.  In  
that vein, I really appreciated this post (hat tip to Sam Ruby) about  
"Data First vs. Structure First"

http://www.betaversion.org/~stefano/linotype/news/93/


> Some people find the act of categorizing and abstracting natural  
> and rewarding, others find it frustrating and unnecessary. The  
> problem with information technologies is that computer programmers  
> are likely to fall in the first category and users of such programs  
> are likely to fall into the second one.
> Data First strategies have higher usability efficiency (all rest  
> being equal) than Structure First strategies.
> On a local time-scale and once established, "Structure First"  
> systems are more efficient.
>
> we all know that a complete mess is not a very good way to find  
> stuff, so "data first" has to imply "structure later" to be able to  
> achieve any useful capacity to manage information. Here is where  
> things broke down in the past: not many believed that useful  
> structures could emerge out of collected data.
>
> But look around now: the examples of 'data emergence' are  
> multiplying and we use them every day. Google's PageRank, Amazon's  
> co-shopping, Citeseer's co-citation, del.icio.us and Flickr co- 
> tagging, Clusty clustering, these are all examples of systems that  
> try to make structure emerge from data, instead of imposing the  
> structure and pretend that people fill it up with data.


In other words, microformats seem to explicitly embody a "data-first  
-- but enable emergent structure later" philosophy, which is why it  
is both attractive and annoying to the traditional XML crowd.

Is that a fair statement?
-- Ernie P.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-discuss/attachments/20050729/d9308b75/attachment.htm
From tantek at cs.stanford.edu  Fri Jul 29 10:52:39 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Fri Jul 29 10:52:48 2005
Subject: [microformats-discuss] Are microformats "data-first"?
In-Reply-To: <40549740-AFAD-4DDB-A1A2-71E3B2BF7825@opendarwin.org>
Message-ID: <BF0FBAE4.5DE0A%tantek@cs.stanford.edu>

On 7/29/05 10:19 AM, "Dr. Ernie Prabhakar" <drernie@opendarwin.org> wrote:

> Hi all,

Hi Ernie,

(minor [admin] note: please only send plain text email to microformats
lists, thanks!)

> I'm still trying to get my head around the "zen" of microformats.  In
> that vein, I really appreciated this post (hat tip to Sam Ruby) about
> "Data First vs. Structure First"
> 
> http://www.betaversion.org/~stefano/linotype/news/93/
> 

<snip>

In many ways it is actually *far* worse than that post conveys.  The
"typical" programmer literally loves spending far more time worrying about
and designing the structure for structure's sake, than data, and even less
so, "real world" data (current behaviors etc.).

Hence we have taken the directly opposite tack with microformats when
looking to solve a problem.

Zeroeth, define the real-world problem.  If you can't do this, then stop.

First, look at real-world usage (data).

Second, what previous standards are people actually using today?  If there
is more than one, then lean towards those with the better adoption.

And only after those first two do we bother to pay attention to theoretical
standards, those that have been invented (whether by individuals,
committees), but haven't seen much if any actual adoption.


> In other words, microformats seem to explicitly embody a "data-first
> -- but enable emergent structure later" philosophy, which is why it
> is both attractive and annoying to the traditional XML crowd.
> 
> Is that a fair statement?

Yes, that is a very fair and perceptive statement.

Here is another recent post that draws a similar analogy:

  Web Services and the Innovators Dilemma by Justin Leavesley

<http://www.justinleavesley.com/journal/2005/7/28/web-services-and-the-innov
ators-dilemma.html>

Thanks,

Tantek

From ryan at technorati.com  Fri Jul 29 11:04:04 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 29 11:04:07 2005
Subject: [microformats-discuss] Are microformats "data-first"?
In-Reply-To: <40549740-AFAD-4DDB-A1A2-71E3B2BF7825@opendarwin.org>
References: <40549740-AFAD-4DDB-A1A2-71E3B2BF7825@opendarwin.org>
Message-ID: <B0134EA7-8E54-435E-89CB-7FDC55045501@technorati.com>

On Jul 29, 2005, at 10:19 AM, Dr. Ernie Prabhakar wrote:
> <snip>
>
> In other words, microformats seem to explicitly embody a "data- 
> first -- but enable emergent structure later" philosophy, which is  
> why it is both attractive and annoying to the traditional XML crowd.

I would say that this is right on. I recently blogged about the  
benefits of "content first, structure later" here: http:// 
theryanking.com/blog/archives/2005/06/15/content-first-structure- 
later/ .

To quote myself:

 > it is difficult to figure out exactly what the structure of your  
data should be until the data is large enough to cause you pain.

So, not only do programmers spend an inordinate amount of time  
defining structure, defining it ahead of time Just Doesn't Work(TM).

-ryan
From ryan at technorati.com  Fri Jul 29 11:07:40 2005
From: ryan at technorati.com (Ryan King)
Date: Fri Jul 29 11:07:42 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <33B70A8E-6742-4923-B077-703D36B4EE03@thecommunityengine.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
	<33B70A8E-6742-4923-B077-703D36B4EE03@thecommunityengine.com>
Message-ID: <38E5B84B-EDC9-4F86-87FF-AF959DC79598@technorati.com>

On Jul 29, 2005, at 5:13 AM, Bud Gibson wrote:
> <snip>
> A couple of questions for any of you that I would be happy to  
> continue off-list if appropriate:
>
> 1.  Would you be willing to make a special area on the wiki for  
> microformat-oriented scripts?  That might be a real help for people  
> trying to figure out how to script microformats.  Also, as I  
> mention in my blog post concerning this little script,  MF and GM  
> seem to go hand-in-hand.

This sounds like a great idea. We already have links to  
implementations on the spec pages and I think I started a collection  
of implementations at http://microformats.org/wiki/implementations,  
but this area could certainly use some work.

> 2.  Do you have any ideas for how to promote learning to hack  
> microformats?  I posted my script here and kept it super simple for  
> didactic purposes.  I could see posting a whole set of hack-like  
> tutorials.

Hack, publish, repeat. ;)

-ryan

PS- once again, if you have developing with microformats, feel free  
to ask about the microformats-dev list. You either email me directly  
or email microformats-dev-owner@microformats.org and we'll take a  
look at what you've got.
From limbo at speakeasy.net  Fri Jul 29 11:13:29 2005
From: limbo at speakeasy.net (Eran)
Date: Fri Jul 29 11:13:34 2005
Subject: [microformats-discuss] A 10 line script to identify and
	processany microformat
In-Reply-To: <D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
Message-ID: <005f01c59469$390edf00$77abca8a@hellonwheels>


> The main point then is - what do you want to do with this data once  
> you have extracted and processed it? POSTing it to a remote 
> server is  
> one idea, but then you could do the processing on the server anyway.  
> I haven't really though of anything useful yet :-)
> 
> alf.


In the browser, what I'd love to see right now is a library that can:
1. test for existence of microcontent.
2. get the actual raw data.
3. be able to apply any transformation to that piece of XHTML.
4. allow slight modifications to the XHTML source of the microcontent
(as in adding a badge or link).
5. provide objects populated with the data. 

Once you have that, anyone can jump in and do whatever they can think
about without having to re-write all this utility code that should be
shared and re-used.

Eran.

From bud at thecommunityengine.com  Fri Jul 29 12:50:14 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Fri Jul 29 12:50:16 2005
Subject: [microformats-discuss] A 10 line script to identify and
	processany microformat
In-Reply-To: <005f01c59469$390edf00$77abca8a@hellonwheels>
References: <005f01c59469$390edf00$77abca8a@hellonwheels>
Message-ID: <A0DA6B36-018F-4627-B4A7-72467B5E45A6@thecommunityengine.com>

I think we can get some movement on this next week.

The main point I think is to show some examples.  We have a couple of  
good identification examples, and I can whip one up that gives one  
example of how to get raw data.

We can pull this into the wiki.  I'd like to get some movement from  
the greasemonkey people too for a MF section on their wiki.   
Greasemonkey people should just flock to MF.

Bud
On Jul 29, 2005, at 14:13, Eran wrote:


> In the browser, what I'd love to see right now is a library that can:
> 1. test for existence of microcontent.
> 2. get the actual raw data.
> 3. be able to apply any transformation to that piece of XHTML.
> 4. allow slight modifications to the XHTML source of the microcontent
> (as in adding a badge or link).
> 5. provide objects populated with the data.
>
> Once you have that, anyone can jump in and do whatever they can think
> about without having to re-write all this utility code that should be
> shared and re-used.
>
> Eran.
>
>


From coretxt at gmail.com  Fri Jul 29 21:31:19 2005
From: coretxt at gmail.com (Mark Rickerby)
Date: Fri Jul 29 21:31:24 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
	<C2163EB8-D994-4271-AB0E-EEF03D076725@umich.edu>
	<D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
Message-ID: <ffa20f220507292131370b7910@mail.gmail.com>

> > Thanks for the recommendation regarding script requests.  Aside
> > from some (in my opinion) minor corner cases, I agree that GM
> > cracks the identification issue nicely, and I would like to see
> > more people adopt the approaches shown in my script and Alf's more
> > developed examples (there's a great one here: http://
> > hublog.hubmed.org/files/hreviewextractor.user.js that does
> > essentially the same thing for hReview that Hotelling does for
> > hCard but with a lot less code devoted to identification).
> 
> That script's a bit old and doesn't do the extra className checking
> that I recommended yesterday. Also it's a different approach to
> George Hotelling's script as it picks out the microformat fragment
> and works on that, rather than passing the whole page off to an
> external processor. What you end up with is just the raw XML, rather
> than a processed hCard -> ICS conversion. However...
> 

One thing I noticed about George Hotelling's script is that although
the identification wasn't as optimized as the XPath approach, it
looked like it would be easier to make it compatible with Internet
Explorer (which doesn't support XPath). User scripts can be enabled in
IE using a plugin called Turnabout.

Regards,
Mark
From bud at thecommunityengine.com  Sun Jul 31 07:18:57 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul 31 07:18:59 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <ffa20f220507292131370b7910@mail.gmail.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
	<C2163EB8-D994-4271-AB0E-EEF03D076725@umich.edu>
	<D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
	<ffa20f220507292131370b7910@mail.gmail.com>
Message-ID: <B69F15FB-5DF2-4FAD-9C62-76F267D81C9C@thecommunityengine.com>

On Jul 30, 2005, at 0:31, Mark Rickerby wrote:


> One thing I noticed about George Hotelling's script is that although
> the identification wasn't as optimized as the XPath approach, it
> looked like it would be easier to make it compatible with Internet
> Explorer (which doesn't support XPath). User scripts can be enabled in
> IE using a plugin called Turnabout.
>

Probably worth some research here as MSXML actually set the standard  
for XSLT support before Firefox was particularly good at it.  This  
might be a dev list discussion from this point.

From ryan at technorati.com  Sun Jul 31 17:22:37 2005
From: ryan at technorati.com (Ryan King)
Date: Sun Jul 31 17:22:42 2005
Subject: [microformats-discuss] Repeating cal events?
In-Reply-To: <7EA70958-60BB-4311-A89B-CE6C48119648@opendarwin.org>
References: <7EA70958-60BB-4311-A89B-CE6C48119648@opendarwin.org>
Message-ID: <5E844E22-17A5-47DF-BD86-22C8186D23F0@technorati.com>

On Jul 26, 2005, at 5:13 PM, Dr. Ernie Prabhakar wrote:

> Hi all,
>
> Any suggestions on how best to represent the following recurring  
> event?
>
> from 12:10 pm - 12:50 pm every other Thursday for 34 weeks,  
> starting June 23rd
>
> I presume it is something like FREQ=WEEKLY*2, but I don't know  
> enough iCalendar to figure it out, much less translate it into hCard.

I believe this has been figured out and implemented on the squid list  
calendar [http://laughingsquid.com/squidlist/calendar/], though I  
can't seem to find any clues in the source of the their html.

-ryan
From brian.suda at gmail.com  Sun Jul 31 17:31:11 2005
From: brian.suda at gmail.com (brian suda)
Date: Sun Jul 31 17:31:20 2005
Subject: [microformats-discuss] Repeating cal events?
In-Reply-To: <5E844E22-17A5-47DF-BD86-22C8186D23F0@technorati.com>
References: <7EA70958-60BB-4311-A89B-CE6C48119648@opendarwin.org>
	<5E844E22-17A5-47DF-BD86-22C8186D23F0@technorati.com>
Message-ID: <42ED6D4F.6010805@gmail.com>

As discussed outsite of, and before, microformats.org the hCalendar may
only be a 1:1 pairing to the ICAL BASIC RFC which is not yet complete.
This is just a subset of the iCalendar RFC, basically omitted things
like reoccuring dates and exclusion dates, etc. At the moment this is
still something that has not been dealt with in the hCalendar spec.

I think someone should add this to the hcal-issues page so we don't
forget about it, and allow for feedback from the community on how/if
this should be implemented.

-brian

Ryan King wrote:

> On Jul 26, 2005, at 5:13 PM, Dr. Ernie Prabhakar wrote:
>
>> Hi all,
>>
>> Any suggestions on how best to represent the following recurring  event?
>>
>> from 12:10 pm - 12:50 pm every other Thursday for 34 weeks,  starting
>> June 23rd
>>
>> I presume it is something like FREQ=WEEKLY*2, but I don't know 
>> enough iCalendar to figure it out, much less translate it into hCard.
>
>
> I believe this has been figured out and implemented on the squid list 
> calendar [http://laughingsquid.com/squidlist/calendar/], though I 
> can't seem to find any clues in the source of the their html.
>
> -ryan
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>

From bud at thecommunityengine.com  Sun Jul 31 18:31:20 2005
From: bud at thecommunityengine.com (Bud Gibson)
Date: Sun Jul 31 18:31:22 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <ffa20f2205073118006058b9e3@mail.gmail.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
	<C2163EB8-D994-4271-AB0E-EEF03D076725@umich.edu>
	<D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
	<ffa20f220507292131370b7910@mail.gmail.com>
	<1D5A4A31-F1D9-4513-8019-F9126BE868C4@umich.edu>
	<ffa20f2205073118006058b9e3@mail.gmail.com>
Message-ID: <069A982B-896B-4A6C-9C23-41611CE12509@thecommunityengine.com>

On Jul 31, 2005, at 21:00, Mark Rickerby wrote:

> Sorry, I could have been more clear on that: IE doesn't support XPath
> in javascript / DOM queries.
>

Yes, I did research on this.  Well, as it turns out, Dimitri Glazkov  
has produced a little javascript library here:

http://glazkov.com/blog/archive/2004/04/06/168.aspx

It basically adds the Mozilla XPATH functionality to IE.  The IE  
version is less efficient than Mozilla though and sometimes fails,  
suggesting another approach is likely best for IE.

In that regard, Danny Goodman has produced some code in his  
javascript dhtml cookbook that can create arrays of nodes by matching  
attribute values.  It is compact and general, with some need of  
modification for the microformats case.

I've updated the wiki to reflect some of this.

I think we have the conceptual wherewithal to put together a cross- 
platform tutorial (where the platforms are IE and Firefox) on easy  
microformat identification.

Bud
From tantek at cs.stanford.edu  Sun Jul 31 19:55:08 2005
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sun Jul 31 19:55:21 2005
Subject: [microformats-discuss] Repeating cal events?
In-Reply-To: <42ED6D4F.6010805@gmail.com>
Message-ID: <BF12DBFA.5DFB8%tantek@cs.stanford.edu>

Ryan wrote:

>> I believe this has been figured out and implemented on the squid list
>> calendar [http://laughingsquid.com/squidlist/calendar/], though I
>> can't seem to find any clues in the source of the their html.


/me digs through his Sent Mail for the answer given to Laughing Squid a few
moons ago.

...

Ok, here is a particularly complex example which I figured out almost three
months ago.

Note, this is an illustrative example for an event that has multiple
occurrences (RDATE), which is different from an event that occurs regularly
(RRULE), like Ernie's example.


=====================
Here are the event times shown on the web page:

http://laughingsquid.com/squidlist/calendar/9584/2005/4/7


 Thu, Apr 7 : Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm


In addition, later on in the description, it says:


 April 7-21, 2005


So for the sake of this example, I'm going to use that information in the
markup for the event times even though the submitter of the event failed to
explicitly list the end date at the top.

This is actually quite a non-trivial example, because the event lasts for
different durations on different days (4 hours, 7 hours, 6 hours).

Because of the differing durations, the specification requires that *each*
instance of this recurring event be explicitly specified.

But first we markup the starting date and time explicitly:

<abbr class="dtstart" title="20050407T1200-0700">Thu, Apr 7</abbr> :

Then we put in the quite lengthy explicit specification of every other time
the event occurs, marked up around the human readable description.

<abbr class="rdate" title="value=period:20050407T1200-0700/PT7H,
20050408T1200-0700/PT7H, 20050409T1200-0700/PT7H, 20050410T1200-0700/PT6H,
20050412T1200-0700/PT4H, 20050413T1200-0700/PT4H, 200504014T1200-0700/PT7H,
20050415T1200-0700/PT7H, 20050416T1200-0700/PT7H, 20050417T1200-0700/PT6H,
20050419T1200-0700/PT4H, 20050420T1200-0700/PT4H, 20050421T1200-0700/PT7H"
>Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm</abbr>


The RDATE "PERIOD" format is fairly straightforward.  You simply list *each*
occurrence of the event, separated by commas.   Each occurrence consists of
the ISO8601 datetime of the start of the event, followed by a slash "/",
followed by *either* the duration of the event (e.g. 7 hours = PT7H), *or* a
complete ISO8601 datetime of the end of the event.  I chose to use the
duration of the event for this example for reason of brevity.


============

Thanks,

Tantek

/me goes off to code Ernie's example now...

From alf at hubmed.org  Sun Jul 31 23:55:58 2005
From: alf at hubmed.org (Alf Eaton)
Date: Sun Jul 31 23:56:05 2005
Subject: [microformats-discuss] A 10 line script to identify and process
	any microformat
In-Reply-To: <069A982B-896B-4A6C-9C23-41611CE12509@thecommunityengine.com>
References: <61EF6D42-3721-4C15-AE3F-F33B87755EF8@thecommunityengine.com>
	<EBADDFAF-3C52-4CAA-B960-2A6B56896DD5@hubmed.org>
	<8DBEF8C3-96CB-4CA3-9351-808F6D9CF678@technorati.com>
	<ffa20f22050728215713b66ad@mail.gmail.com>
	<C2163EB8-D994-4271-AB0E-EEF03D076725@umich.edu>
	<D22C351B-2043-4317-80A9-2C6FE17F1B0F@hubmed.org>
	<ffa20f220507292131370b7910@mail.gmail.com>
	<1D5A4A31-F1D9-4513-8019-F9126BE868C4@umich.edu>
	<ffa20f2205073118006058b9e3@mail.gmail.com>
	<069A982B-896B-4A6C-9C23-41611CE12509@thecommunityengine.com>
Message-ID: <B8FD2415-91A2-4D89-810A-59A367EB4E1F@hubmed.org>


On 01 Aug 2005, at 03:31, Bud Gibson wrote:

> On Jul 31, 2005, at 21:00, Mark Rickerby wrote:
>
>
>> Sorry, I could have been more clear on that: IE doesn't support XPath
>> in javascript / DOM queries.
>>
>>
>
> Yes, I did research on this.  Well, as it turns out, Dimitri  
> Glazkov has produced a little javascript library here:
>
> http://glazkov.com/blog/archive/2004/04/06/168.aspx
>
> It basically adds the Mozilla XPATH functionality to IE.  The IE  
> version is less efficient than Mozilla though and sometimes fails,  
> suggesting another approach is likely best for IE.

Don't forget Google's AJAXSLT: http://goog-ajaxslt.sourceforge.net/

alf