From elli at sustainlane.com  Tue Jun  2 00:01:16 2009
From: elli at sustainlane.com (Elli Albek)
Date: Tue Jun  2 00:01:28 2009
Subject: [uf-discuss] Microformats and keyword spamming
Message-ID: <9FADEAEF483F4DCA877446C3A9ADA2A4@ealbek>

Problems again.

Building a simple yelp style business review page requires us to repeat a
lot of information on the page. This has a few results:

1. Non semantic HTML. The pages include a lot of repeating terms in the
wrong places. There is no way to avoid it if we want to use hreview.

2. The pages become less accessible, since the HTML starts deviating from
its semantic form. For example, include pattern requires:
  a. object tags (this should ALWAYS be avoided at all cost!!!)
  b. empty A tags
  C. A tags with redundant information that is constantly repeating on the
page. This is what we currently do as the lesser of all evils.

3. Needing to repeat so much text on the page affects search engine results:

Repeating terms that are almost irrelevant to the page, like
<span?class="type">business</span>
on each and every hreview.

4. Repeating important keywords on the page TOO MANY TIMES, such as the
business name on every review:
<span class="item">
<a class="include" href="#review_item">Maharishi Ayurveda Health Spa</a>
</span>

This added the page main keywords so many times that I suspect it borders
keyword spamming in the eyes of the search engine.

WHAT TO DO:

Those are the options now:

1. The risk of a good content site becoming a keyword spammer, outweighs any
benefit of using microformats that I can currently see. Making the pages non
semantic in order to support microformats, possibly already hurt our
rankings. Solution: remove microformats from reviews pages entirely.

2. Use Google's cut down version of microformats. This may not follow the
spec, but if we follow google most of our problems are solved. What I like
about many google APIs is their practical approach. In that case I think
their view of microformats is more practical then the spec. It certainly
solves a lot of our problems.

3. Alternative formats: RDF? 

4. Direct feed to search engines in proprietary formats. We will still
support hcard for the business directory, but will remove support for
hreview since this is the major source of problems.

This all started when we wanted to added review aggregate, and the pages are
starting to deteriorate.

Advice is welcome and appreciated.

I would really appreciate:

** An example that shows how to build a REAL reviews page. **

1. That page includes the business information once and only once on the
page, where the business name is in H1 (in hcard).
2. That page includes review aggregate, which does not require any
repetition or hidden text.
3. A few reviews of the said business, WHICH DO NOT REQUIRE ANY REPETITION
of any item information, the type of business, etc.
4. Business name shows once and only once on the page in the hcard and
nowhere else.
5. Listing type (business/product) shows once and only once on the page.
Natural place in the hcard, but according to the spec it is not possible.

E


From lists at ben-ward.co.uk  Tue Jun  2 01:42:14 2009
From: lists at ben-ward.co.uk (Ben Ward)
Date: Tue Jun  2 01:42:22 2009
Subject: [uf-discuss] Microformats and keyword spamming
In-Reply-To: <9FADEAEF483F4DCA877446C3A9ADA2A4@ealbek>
References: <9FADEAEF483F4DCA877446C3A9ADA2A4@ealbek>
Message-ID: <285AB944-3564-4E3D-B994-AC0563F13B42@ben-ward.co.uk>

Hi Elli,

On 2 Jun 2009, at 00:01, Elli Albek wrote:

> 1. Non semantic HTML. The pages include a lot of repeating terms in  
> the
> wrong places. There is no way to avoid it if we want to use hreview.

Repeated content is of course undesirable, but please don't conflate  
it with being ?non semantic?.

> 2. The pages become less accessible, since the HTML starts deviating  
> from
> its semantic form. For example, include pattern requires:

The include pattern offers you choices to reference other content in  
the page.  It's not perfect, I agree. I would appreciate some clarity  
on your problems below, though:

>  a. object tags (this should ALWAYS be avoided at all cost!!!)

We are aware of and have documented scenarios where `object` is  
problematic, but that doesn't equate to ?ALWAYS be avoided at all  
cost?. If you have a new case with the `object` version is as horrific  
as you make out, please document it on http://microformats.org/wiki/include-pattern-issues 
. If not, please keep your descriptions concise and free from  
overreaction, as it confuses attempts to assist you.

>  b. empty A tags

These are pretty much outlawed by the spec now, based on previous  
accessibility research,

> C. A tags with redundant information that is constantly repeating on  
> the
> page. This is what we currently do as the lesser of all evils.

This is a compromise, of course. Is it really evil though? Suboptimal,  
sure, but evil? You'd be repeating the name of the restaurant  
somewhere. It can be fit into the structure cleanly, and it can be  
hidden if you want.

<h2 class='summary'><a class='include' href='#item'>The Alembic:</a>  
Great food and cocktails!</h2>
<p>? etc.</p>

Yes, not perfect. But can be designed in cleanly.

> 3. Needing to repeat so much text on the page affects search engine  
> results:
>
> Repeating terms that are almost irrelevant to the page, like
> <span class="type">business</span>
> on each and every hreview.

The review 'type' is optional. If it doesn't fit your publishing  
pattern, just leave it out.

> 4. Repeating important keywords on the page TOO MANY TIMES, such as  
> the
> business name on every review:
> <span class="item">
> <a class="include" href="#review_item">Maharishi Ayurveda Health  
> Spa</a>
> </span>
>
> This added the page main keywords so many times that I suspect it  
> borders
> keyword spamming in the eyes of the search engine.

Can you provide more info than that you ?suspect?? Obviously that's a  
serious issue if true, but these hyperlinks are linking to fragments  
within the same page, not to other resources. To the best of my  
knowledge, that has nothing to do with establishing keywords for a  
page. Is there documentation to the contrary?

> 2. Use Google's cut down version of microformats. This may not  
> follow the
> spec, but if we follow google most of our problems are solved. What  
> I like
> about many google APIs is their practical approach. In that case I  
> think
> their view of microformats is more practical then the spec. It  
> certainly
> solves a lot of our problems.

Again, can you provide a link to this? Google's Rich Snippets  
documentation provides some small examples of hReview, but links to  
the microformats spec as the definitive reference. I'm unaware of any  
?cut down? version of microformat specs from Google, nor can I see  
anything in their examples suggesting this.

> 4. Direct feed to search engines in proprietary formats. We will still
> support hcard for the business directory, but will remove support for
> hreview since this is the major source of problems.

Since search engines don't currently accept any alternative ?direct  
feed? format I don't quite know what option 4 is supposed to entail,  
and again, precise clarity of major problems makes the issue easier to  
work with.

> Advice is welcome and appreciated.
>
> I would really appreciate:
>
> ** An example that shows how to build a REAL reviews page. **
>
> 1. That page includes the business information once and only once on  
> the
> page, where the business name is in H1 (in hcard).
> 2. That page includes review aggregate, which does not require any
> repetition or hidden text.
> 3. A few reviews of the said business, WHICH DO NOT REQUIRE ANY  
> REPETITION
> of any item information, the type of business, etc.
> 4. Business name shows once and only once on the page in the hcard and
> nowhere else.
> 5. Listing type (business/product) shows once and only once on the  
> page.
> Natural place in the hcard, but according to the spec it is not  
> possible.

I'm now a little confused. Up to now you're talking about hreview, and  
now you refer to hreview-aggregate.

As far as I'm aware, the `hreview-aggregate` can be created without  
any repetition or hidden text. The item will be a child of the  
aggregate.

The subsequent reviews would need to use the include pattern to  
reference the original item to avoid major repetition. Currently,  
there is no other way.



Now, I've asked questions here because you've been quite imprecise  
with some of your complaints, and I need to be clear about where  
you've found an explicit, documentable problem and where you're just  
expressing frustration. Please don't get me wrong, I completely agree  
that the include pattern is imperfect. And I do think better  
structural parsing should be pursued.

But, with regard to helping your problem right now, that means being  
clear about problems you have with the current spec.

If you can follow up more precisely to the above and provide more info  
where necessary, hopefully we can nail down a solution for you in the  
shorter term.

Please provide example mark-up if you can (add it to the wiki if you  
think it illustrates an issue, too).

Thanks,

Ben
From mail at tobyinkster.co.uk  Tue Jun  2 03:36:56 2009
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Tue Jun  2 03:37:01 2009
Subject: [uf-discuss] Microformats and keyword spamming
In-Reply-To: <9FADEAEF483F4DCA877446C3A9ADA2A4@ealbek>
References: <9FADEAEF483F4DCA877446C3A9ADA2A4@ealbek>
Message-ID: <1243939016.12193.14.camel@ophelia2.g5n.co.uk>

On Tue, 2009-06-02 at 00:01 -0700, Elli Albek wrote:
> 3. Alternative formats: RDF? 

RDFa is pretty good at avoiding repetition. e.g.

<body xmlns:r="http://purl.org/stuff/rev#"
      xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <div typeof="foaf:Organization">
    <h1 property="foaf:name">Maharishi Ayurveda Health Spa</h1>
    <ul rel="r:hasReview">
      <li typeof="r:Review">
        <h2 property="r:title">Awesomeness!</h2>
    ?    <p rel="r:reviewer">
          <a rel="foaf:homepage" href="http://bob.example.com/"
            property="foaf:name">Bob</a>
        </p>
        <p property="r:text">This spa is very good!</p>
        <p property="r:rating" content="4">?????</p>
      </li>
    ?  <li typeof="r:Review">
        <h2 property="r:title">Awfulness!</h2>
        <p rel="r:reviewer">
          <a rel="foaf:homepage" href="http://joe.example.com/"
            property="foaf:name">Joe</a>
        </p>
        <p property="r:text">This spa is horrible!</p>
        <p property="r:rating" content="1">????????</p>
      </li>
    </ul>
  </div>
</body>

-- 
Toby Inkster <mail@tobyinkster.co.uk>

From tantek at cs.stanford.edu  Tue Jun  2 14:13:31 2009
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Tue Jun  2 14:13:35 2009
Subject: [uf-discuss] Any bettter way to do an include in hreview?
In-Reply-To: <684A625CCE7F44A4B7B764A43398C7E1@ealbek>
References: <AcngzaP3kBIHK0rsR6S6RRhtNv1CWA==>
	<684A625CCE7F44A4B7B764A43398C7E1@ealbek>
Message-ID: <60cb038a0906021413n36dfb15aw8197d1e740620222@mail.gmail.com>

On Fri, May 29, 2009 at 7:23 PM, Elli Albek <elli@sustainlane.com> wrote:
> Hi,
> We have the typical page with one business information on top and many
> reviews for that business on the page.

Hi Elli,

Could you provide a URL[1] to one of your typical pages with one
business information on top and many reviews for that business on the
page?

A complete page/document example with actual content will make it much
easier to understand how to mark it up as semantically as possible
while avoiding as much as possible the introduction of duplicate
information and extraneous markup.

Thanks,

Tantek

[1] http://microformats.org/wiki/mailing-lists#Use_URLs_to_examples
From info at csarven.ca  Wed Jun  3 09:54:31 2009
From: info at csarven.ca (Sarven Capadisli)
Date: Wed Jun  3 09:54:44 2009
Subject: [uf-discuss] Mozilla Jetpack API and representative hCard add-on
Message-ID: <1244048071.4045.62.camel@csarven-laptop>

Hi all,

Using the Mozilla Jetpack API [0], I created a simple add-on that looks
for a representative hCard on the current Mozilla/Firefox tab and offers
a link to download it as a vCard [1]. If you want to test it out, you
need to first install the Jetpack API, the Jetpack script, and head over
to a page with a representative hCard [2].
 
The way it works right now is that the script gets a hold of
'.vcard .uri.url[rel=me]' href value (If that's not accurate, please let
me know), and pass that onto Toby Inkster's representative hCard to
vCard transformer [3]. The transformer actually grabs the representative
hCard of the input URI, which makes it a little redundant operation,
since we could simply pass on the current tab URI to the transformer.

Still with me?

What I'd really like to do is pass on only the representative hCard to
the transformer which outputs the vCard. I realize this is a grey area
between what the document can offer and what the parser can do with that
document, but, I know the latter is less of a concern.

So, I think there are some options which could make this fun extension a
bit better, but, I'd love to hear other possibilities.

* Passing the hCard object as a data: URI to the hCard to vCard
transformer using Brian Suda's X2V [4] (suggested by Tantek ?elik). This
however hits the HTTP GET length limit. Are there are any transformers
that can do this via HTTP POST?

* We can also output a copy of the representative hCard to a temporary
file on a server, then point the parser at the temporary file. Could use
a pastebin even (suggested by Toby Inkster). A little inconvenient, but,
possible.

* Probably the simplest solution that I can think of is to insert an @id
on the vCard node (if there isn't one already) on the fly with the
Jetpack script and send over the URI with a fragment identifier to the
transformer. The problem is that the '.vcard .uri.url[rel=me]' href
value might not be the same as the current URI + fragment identifier.
However, if I'm not mistaken '.vcard .uri.url[rel=me]' href value points
to the current URI as a representative hCard, so, it may be okay. Do you
see any issues with that?

All feedback more than welcome.

-Sarven

[0] https://jetpack.mozillalabs.com/

[1] http://csarven.ca/labs/jetpack/representative-hcard.php

[2] http://identi.ca/csarven
http://tantek.com
http://brigitteschuster.com
http://www.more.ca/my_more/user/JennGruden

[3] http://srv.buzzword.org.uk/representative-hcard-to-vcard.cgi?uri=

[4] http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=



From brian.suda at gmail.com  Wed Jun  3 10:33:35 2009
From: brian.suda at gmail.com (Brian Suda)
Date: Wed Jun  3 10:33:38 2009
Subject: [uf-discuss] Mozilla Jetpack API and representative hCard add-on
In-Reply-To: <1244048071.4045.62.camel@csarven-laptop>
References: <1244048071.4045.62.camel@csarven-laptop>
Message-ID: <21e770780906031033i1dceb656t20e8a7c63b5a2c60@mail.gmail.com>

On Wed, Jun 3, 2009 at 4:54 PM, Sarven Capadisli <info@csarven.ca> wrote:
> * Passing the hCard object as a data: URI to the hCard to vCard
> transformer using Brian Suda's X2V [4] (suggested by Tantek ?elik). This
> however hits the HTTP GET length limit. Are there are any transformers
> that can do this via HTTP POST?

--- X2V is available as a POST as well, but i don't like to advertise
it too much. If you or anyone else has a good reason why they need it
(like this), please contact me OFFLIST and i'll send you the info you
need and we can test that it works.

Thanks,
-brian

-- 
brian suda
http://suda.co.uk

From elli at sustainlane.com  Wed Jun  3 18:15:12 2009
From: elli at sustainlane.com (Elli Albek)
Date: Wed Jun  3 18:15:16 2009
Subject: [uf-discuss] Re: Microformats and keyword spamming (Toby Inkster)
In-Reply-To: <200906031711.n53HBPcT031871@microformats.org>
Message-ID: <3484012.39581244078112077.JavaMail.root@dexter>

Thanks for the example Toby. This is perfect. Solves all my problems. It maps exactly one to one to a reviews page (like yelp).

I think the main reason it does not have the issues I am facing is the way things include/reference each other in this RDF example.
From elli at sustainlane.com  Wed Jun  3 20:05:36 2009
From: elli at sustainlane.com (Elli Albek)
Date: Wed Jun  3 20:05:40 2009
Subject: [uf-discuss] Any bettter way to do an include in hreview?
Message-ID: <3684239.39731244084736910.JavaMail.root@dexter>

Hi Tantek.

Link to a page with reviews:
http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8

You can also look at Yelp. Similar page content. 

Notice hidden blocks with class="microformat_detail"

<div class="microformat_detail">
<span class="type">business</span>
	review of 
	<span class="item">
	<a class="include" href="#review_item">Aziza</a>
	</span>:
	<span class="rating">4</span> stars
</div>

Two things we want:
1.	Remove repetition
2.	Add review aggregates without more repetition

Generally I would like to stop using microformat_detail, and not restructure the HTML. 

The microformats spec can makes it easier to support variety of page structures without includes/hidden blocks by having other association rules. Toby's RDF example is 1:1 match to our pages, but that may be a special case.

A few suggestions that will make implementation simpler for different HTML trees:

1. hcard can contain associated information like reviews and aggregates. hreviews inside an hcard to not need to specify item.
<div class="hcard">
   <!-- hcard as a container -->
   <h1 class="fn">name</h1>
   <span class="average-rating">5</span> stars
   based on <span class="hreview-count">1313</span> reviews
   <div class="hreview">...</div>
   <div class="hreview"> ...</div>
</div>
 
2. Make a container, in which things are associated by default, so you can have a few of them on a page.
<div class="item-container">
   <h1 class="item hcard fn url"><a href="...">name</a></h1>
   <span class="average-rating">5</span> stars
   based on <span class="hreview-count">1313</span> reviews
   <div class="hreview">...</div>
   <div class="hreview"> ...</div>
</div>

3. Item can contain, instead of be part of other blocks.
<div class="item">
   <!-- item as a container -->
   <h1 class="hcard fn"><a class="url" href="...">name</a></h1>
   <span class="average-rating">5</span> stars
   based on <span class="hreview-count">1313</span> reviews
   <div class="hreview">...</div>
   <div class="hreview"> ...</div>
</div>

4. Aggregates have distinct names that are not used in hreview, so a block with an aggregate can be included in hreview without collisions with the hreview rating.

<div class="hcard item" id="review_item">
   <h1 class="fn">name</h1>
   <span class="average-rating">5</span> stars
   based on <span class="review-count">1313</span> reviews
   <span class="type microformat_detail">business</span>
</div>
<div class="hreview">...
   <a class="item microformat_detail" href="#review_item">Aziza</a>
</div>

5. This HTML structure may currently be the solution to the puzzle (hack?). Still requires includes.
 
<div class="hreview-aggregate">
   <div class="item hcard" id="review_item">
      <span class="fn">L'Amourita Pizza</span>
   </div>
   <span class="average-rating">4.4</span>
   <span class="review-count">1313</span>
</div>

<div class="hreview">...
   <a class="item microformat_detail" href="#review_item">Aziza</a>
</div>

The key in this trick is that aggregate block contains the hcard block and separately than the actual aggregate numbers. They are siblings. It is now possible to include the item in hreview, without importing a second rating from the aggregate. In this case aggregates can have names already used in hreview.

This dictates a certain markup tree, which will require web developers to rewrite pages to match it, as we do now (unless they are lucky enough to already have it this way). A better solution will not require you to reorganize your page blocks if they are already semantically readable. Something like example 3 is more flexible, it allows things to be in a flat structure without includes, all you need is one class outside.

If the spec does not offer something like 3 (no includes, no forced tree structures, etc) than reviews and aggregates need distinct names for the elements, to make including easier. Otherwise developers have to go to something like 5, which dictates a rigid page. There should be more than only one possible way to add microformats to a reviews page without hidden blocks, repeating text, etc.

I also think it is a goal to make the work of the parser as easy as possible without big decision trees to resolve includes.

Another suggestion: Collapse trees. If microformats are already flexible in what they allow as parent child, you might as well consider a rule that allows you to collapse an entire tree of microformats:

<a class="item hcard fn url" href="...">name</a>

-------------------------------------------------
Suggested solution using TODAYS spec:

<div class="hreview-aggregate">
   <div class="item hcard" id="review_item">
      <span class="fn">L'Amourita Pizza</span>
   </div>
   <div class="rating">
      <span class="average">4.4</span>
   </div> 
   <span class="count">1313</span>
</div>
<div class="hreview">...
   <a class=" microformat_detail" href="#review_item">Aziza</a>
</div>

E
From elli at sustainlane.com  Wed Jun  3 20:56:16 2009
From: elli at sustainlane.com (Elli Albek)
Date: Wed Jun  3 20:56:19 2009
Subject: [uf-discuss] Different syntax for review average
Message-ID: <BBAA43D348C3406D9FF30189C08FBBB7@ealbek>

This I assume is a correct syntax:
http://microformats.org/wiki/google-rich-snippets-examples

<div class="hreview-aggregate">
   <div class="item">...</div>
   <div class="rating">
      <span class="average">4.4</span>
   </div> 
   <span class="count">1313</span>
</div>

Are any of those legal as well?

<div class="hreview-aggregate">
   <div class="item">...</div>
   <span class="rating average">4.4</span>
</div>

<div class="hreview-aggregate">
   <div class="item">...</div>
   <span class="rating">4.4</span>
</div>

<div class="hreview-aggregate">
   <div class="item">...</div>
   <span class="average">4.4</span>
</div>

Thanks

Elli

From info at csarven.ca  Thu Jun  4 10:12:30 2009
From: info at csarven.ca (Sarven Capadisli)
Date: Thu Jun  4 10:13:09 2009
Subject: [uf-discuss] Mozilla Jetpack API and representative hCard add-on
In-Reply-To: <1244048071.4045.62.camel@csarven-laptop>
References: <1244048071.4045.62.camel@csarven-laptop>
Message-ID: <1244135550.3853.10.camel@csarven-laptop>

On Wed, 2009-06-03 at 12:54 -0400, Sarven Capadisli wrote:
> * Probably the simplest solution that I can think of is to insert an @id
> on the vCard node (if there isn't one already) on the fly with the
> Jetpack script and send over the URI with a fragment identifier to the
> transformer. The problem is that the '.vcard .uri.url[rel=me]' href
> value might not be the same as the current URI + fragment identifier.
> However, if I'm not mistaken '.vcard .uri.url[rel=me]' href value points
> to the current URI as a representative hCard, so, it may be okay. Do you
> see any issues with that?

This will not work for dynamically added @id, because the transformer
will not have a knowledge of it; a new GET request after all.

-Sarven

From bruno at likeorhate.com  Mon Jun  8 14:17:05 2009
From: bruno at likeorhate.com (Bruno Barberi Gnecco)
Date: Mon Jun  8 14:11:38 2009
Subject: [uf-discuss] Multiple vote-links
Message-ID: <4A2D7FD1.1010200@likeorhate.com>

Hi everybody,

	We are using vote-links extensively in our new site (likeorhate.com), and most pages 
have more than one target for voting. Since there's a question in the FAQ related to this:

Q: Is a VoteLink to a page a vote for/against etc. that page, or what that page 
represents?

	May I propose that vote-links refer not only to what the page represents, but  to 
what a parent tag represents? We are currently using a markup like this, I hope the 
example makes my idea clear:

<div about="http://likeorhate.com/thing/1/">
	<a rev="vote-for" rel="nofollow" href="...">Like</a>
	....
</div>

So a vote inside the div is made to what is in the "about" attribute. We're borrowing 
the "about" keyword from RDF, BTW.

	Forgive me if this has been proposed before; I couldn't find any reference.

	Best regards
From elli at sustainlane.com  Mon Jun  8 20:50:33 2009
From: elli at sustainlane.com (Elli Albek)
Date: Mon Jun  8 20:50:36 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <4A2D7FD1.1010200@likeorhate.com>
Message-ID: <15952270.50631244519433819.JavaMail.root@dexter>

Association is a problem with other Microformats as well. I had similar problem with hreviews, and interestingly proposed the exact solution that you did, container association: Items inside a container belong to it, similar to RDF. In your example the div is the container. It should be identified by a microformat as a containing item.

So you will have to add to the div something that will tell the microformat parser that the link inside belong to it. Just using parent tag is a problem, because it creates strong coupling of the microformat to the HTML. For example, you will not be able to add another div in between to group you actions (lets say for adding a background).

Example:
<div about="http://likeorhate.com/thing/1/" class="item">
  <div style="width: 20%; float: right; background-color: yellow; padding: 1em;">
    <a rev="vote-for" rel="nofollow" href="...">Like</a>
    <br/>
    <a rev="vote-against" rel="nofollow" href="...">Don't Like</a>
  </div>
  <h2>Google</h2>
  ....
</div>

class=item tells the microformat parser that you are voting on this item.

In case of vote links, Microformats that are allowed to have them should include at least hreview, item, hentry.

E
From mail at tobyinkster.co.uk  Tue Jun  9 01:41:27 2009
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Tue Jun  9 01:41:32 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <4A2D7FD1.1010200@likeorhate.com>
References: <4A2D7FD1.1010200@likeorhate.com>
Message-ID: <1244536887.350.19.camel@ophelia2.g5n.co.uk>

On Mon, 2009-06-08 at 18:17 -0300, Bruno Barberi Gnecco wrote:
> We are using vote-links extensively in our new site (likeorhate.com)

And doing so wrongly. VoteLinks are a badly named microformat. They are
*not* for polling. They are for linking to articles about stuff you like
or dislike.

e.g.

	I like <a rev="vote-for" href="/cheese">cheese</a>,
	but not <a rev="vote-against" href="/broccoli">?broccoli</a>.

That means that this page counts as a "vote for cheese" and a "vote
against broccoli". Although votelinks is unclear on the semantics - do I
like cheese, or do I like that particular page about cheese?

VoteLinks are quite muddy and their meaning is pretty unclear. With
RDFa, you can state each of those meanings unambiguously.

?If you like cheese (the page), then:

	<p about="#me" ?xmlns:like="http://ontologi.es/like#">
	  I like <a rel="like:likes" href="/cheese">cheese</a>.
	</p>

If you like cheese (the food), then (a little more complicated):

	<p about="#me"
	   ?xmlns:like="http://ontologi.es/like#"
	   xmlns:foaf="http://xmlns.com/foaf/0.1/">
	  I like
	  <span rel="like:likes">
	    <a rev="foaf:primaryTopic" href="/cheese"
	       property="foaf:name">cheese</a>
	  </span>
	</p>

However, for a polling site, neither votelinks nor the example above are
appropriate. You're not trying to capture the meaning that "this page is
about something I like" - you're trying to capture the meaning of "this
link is for voting". I don't know of a microformat, or indeed an RDF
vocabulary, that covers that meaning, but I can certainly see value in
creating one.

-- 
Toby Inkster <mail@tobyinkster.co.uk>

From bruno at likeorhate.com  Tue Jun  9 08:10:02 2009
From: bruno at likeorhate.com (Bruno Barberi Gnecco)
Date: Tue Jun  9 08:04:43 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <1244536887.350.19.camel@ophelia2.g5n.co.uk>
References: <4A2D7FD1.1010200@likeorhate.com>
	<1244536887.350.19.camel@ophelia2.g5n.co.uk>
Message-ID: <4A2E7B4A.6010205@likeorhate.com>

> On Mon, 2009-06-08 at 18:17 -0300, Bruno Barberi Gnecco wrote:
>> We are using vote-links extensively in our new site (likeorhate.com)
> 
> And doing so wrongly. VoteLinks are a badly named microformat. They are
> *not* for polling. They are for linking to articles about stuff you like
> or dislike.
> 
> e.g.
> 
> 	I like <a rev="vote-for" href="/cheese">cheese</a>,
> 	but not <a rev="vote-against" href="/broccoli">?broccoli</a>.
> 
> That means that this page counts as a "vote for cheese" and a "vote
> against broccoli". Although votelinks is unclear on the semantics - do I
> like cheese, or do I like that particular page about cheese?
> 
> VoteLinks are quite muddy and their meaning is pretty unclear. With
> RDFa, you can state each of those meanings unambiguously.
> 
> ?If you like cheese (the page), then:
> 
> 	<p about="#me" ?xmlns:like="http://ontologi.es/like#">
> 	  I like <a rel="like:likes" href="/cheese">cheese</a>.
> 	</p>
> 
> If you like cheese (the food), then (a little more complicated):
> 
> 	<p about="#me"
> 	   ?xmlns:like="http://ontologi.es/like#"
> 	   xmlns:foaf="http://xmlns.com/foaf/0.1/">
> 	  I like
> 	  <span rel="like:likes">
> 	    <a rev="foaf:primaryTopic" href="/cheese"
> 	       property="foaf:name">cheese</a>
> 	  </span>
> 	</p>

	Strangely, no "I don't like" in that ontology? I see Opinion could be used for it, but...

> However, for a polling site, neither votelinks nor the example above are
> appropriate. You're not trying to capture the meaning that "this page is
> about something I like" - you're trying to capture the meaning of "this
> link is for voting". I don't know of a microformat, or indeed an RDF
> vocabulary, that covers that meaning, but I can certainly see value in
> creating one.
> 

	Thanks for the clarification. Since their meaning is unclear (as you and the FAQ 
state), why not let them be used for this purpose as well? I suppose with a class or 
another attribute together one could separate what is a poll link (vote for this) and 
what is an opinion (I have voted for this).

	Otherwise, if vote-links are not used for polling and there is not (it seems) a 
microformat for it, how to propose a new one?

	It would be nice to have a more general microformat for associating a target with a 
"label", more or less like xfn. Again, the problem of "acting on" vs "having acted on" 
that confused me shows up. How about something like this rough draft to follow.

	For acting on (polling):

<div about="#something" class="item">
	<a href="..." rel="action:like">I like cheese</a>
	<a href="..." rel="action:blue">I think cheese is always blue</a>
</div>

	For having acted on (similar to vote-links)

<div about="#me" class="item">
	<a href="..." rev="opinion:like">I like cheese</a>
	<p href="..." rev="opinion:blue">I think cheese is always blue</a>
</div>

	Although I think this later one should also have information about who likes it 
(perhaps an hCard), since we could, for example, have a list of expert opinions about 
cheese. But I don't like the exchanges of roles of "about" (I hope I got it right).
From kevinmarks at gmail.com  Tue Jun  9 12:46:54 2009
From: kevinmarks at gmail.com (Kevin Marks)
Date: Tue Jun  9 12:46:57 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <4A2E7B4A.6010205@likeorhate.com>
References: <4A2D7FD1.1010200@likeorhate.com>
	<1244536887.350.19.camel@ophelia2.g5n.co.uk>
	<4A2E7B4A.6010205@likeorhate.com>
Message-ID: <73766b160906091246m7732d7q8d9c3a487f870029@mail.gmail.com>

On Tue, Jun 9, 2009 at 8:10 AM, Bruno Barberi Gnecco
<bruno@likeorhate.com> wrote:
>>
>> On Mon, 2009-06-08 at 18:17 -0300, Bruno Barberi Gnecco wrote:
>>>
>>> We are using vote-links extensively in our new site (likeorhate.com)
>>
>> And doing so wrongly. VoteLinks are a badly named microformat. They are
>> *not* for polling. They are for linking to articles about stuff you like
>> or dislike.

They are links that express votes - if you can suggest clarifications
to the text of the microformat page that make this clearer that would
be appreciated.

>>
>> e.g.
>>
>> ? ? ? ?I like <a rev="vote-for" href="/cheese">cheese</a>,
>> ? ? ? ?but not <a rev="vote-against" href="/broccoli">?broccoli</a>.
>>
>> That means that this page counts as a "vote for cheese" and a "vote
>> against broccoli". Although votelinks is unclear on the semantics - do I
>> like cheese, or do I like that particular page about cheese?

That page is the default assumption. Links are between pages. I
suppose you could combine with rel-tag to express an abstract category
instead:

<a rev="vote-for" rel="tag" href="/cheese">cheese</a>,

but in that case you may be better off using the ratings in hreview,
which are designed for that purpose

>>
>> VoteLinks are quite muddy and their meaning is pretty unclear.

I'd disagree there. The intent is clear -to be able to express
agreement and disagreement with a linked-to page from the current
context.

In practice, however, rel-nofollow has won out as disagreement, with
plain links as agreement. The formulation above:


?<a rev="vote-for" rel="nofollow" href="...">Like</a>

has 2 votes for the same thing, as rel="nofollow" is equivalent to
rev="vote-abstain" - very hard to work out what your intent is there,.

>>
>> With
>> RDFa, you can state each of those meanings unambiguously.

With hReview you can express what you want here

>>
>> ?If you like cheese (the page), then:
>>
>> ? ? ? ?<p about="#me" ?xmlns:like="http://ontologi.es/like#">
>> ? ? ? ? ?I like <a rel="like:likes" href="/cheese">cheese</a>.
>> ? ? ? ?</p>


<div class="hreview">
<span class="reviewer vcard"><span class="fn">Kevin Marks</span></span>
<abbr class="rating" title="5">likes</abbr>
<div class="item"><a href="/cheese" class="fn url">this cheese page</a></div>
</div>

>>
>> If you like cheese (the food), then (a little more complicated):
>>
>> ? ? ? ?<p about="#me"
>> ? ? ? ? ? ?xmlns:like="http://ontologi.es/like#"
>> ? ? ? ? ? xmlns:foaf="http://xmlns.com/foaf/0.1/">
>> ? ? ? ? ?I like
>> ? ? ? ? ?<span rel="like:likes">
>> ? ? ? ? ? ?<a rev="foaf:primaryTopic" href="/cheese"
>> ? ? ? ? ? ? ? property="foaf:name">cheese</a>
>> ? ? ? ? ?</span>
>> ? ? ? ?</p>


<div? class="hreview"><span class="reviewer vcard"><span
class="fn">Kevin Marks</span></span>
<abbr class="rating" title="5">likes</abbr>
<div class="item"><span class="fn">cheese</span></div>
</div>

>
> ? ? ? ?Strangely, no "I don't like" in that ontology? I see Opinion could be used for it, but...
>
>> However, for a polling site, neither votelinks nor the example above are
>> appropriate. You're not trying to capture the meaning that "this page is
>> about something I like" - you're trying to capture the meaning of "this
>> link is for voting". I don't know of a microformat, or indeed an RDF
>> vocabulary, that covers that meaning, but I can certainly see value in
>> creating one.
>>
>
> ? ? ? ?Thanks for the clarification. Since their meaning is unclear (as you and the FAQ state), why not let them be used for this purpose as well? I suppose with a class or another attribute together one could separate what is a poll link (vote for this) and what is an opinion (I have voted for this).

The meaning of the link isn't unclear, the intent on whether the page
or the idea or person represented by the page is a little unclear. How
would adding extra ambiguity be at all usefule?

>
> ?? ?? Otherwise, if vote-links are not used for polling and there is not (it seems) a microformat for it, how to propose a new one?

well, the process for defining a new microformat is explained here:

http://microformats.org/wiki/process

>
> ? ? ? ?It would be nice to have a more general microformat for associating a target with a "label", more or less like xfn.

you mean tagging a linked-to page? that's what xfolk is for:

http://microformats.org/wiki/xfolk

though in practice hReview seems to be used more widely for this.


> Again, the problem of "acting on" vs "having acted on" that confused me shows up. How about something like this rough draft to follow.
>
> ? ? ? ?For acting on (polling):
>
> <div about="#something" class="item">
> ? ? ? ?<a href="..." rel="action:like">I like cheese</a>
> ? ? ? ?<a href="..." rel="action:blue">I think cheese is always blue</a>
> </div>
>
> ? ? ? ?For having acted on (similar to vote-links)
>
> <div about="#me" class="item">
> ? ? ? ?<a href="..." rev="opinion:like">I like cheese</a>
> ? ? ? ?<p href="..." rev="opinion:blue">I think cheese is always blue</a>
> </div>
>
> ? ? ? ?Although I think this later one should also have information about who likes it (perhaps an hCard), since we could, for example, have a list of expert opinions about cheese. But I don't like the exchanges of roles of "about" (I hope I got it right).

I think that HTML forms would likely be the dominant way to express a
voting user interface when you did the analysis of existing markup
that is a key part of the process; re-expressing this for links seems
like a big step back.

From bruno at likeorhate.com  Tue Jun  9 14:47:18 2009
From: bruno at likeorhate.com (Bruno Barberi Gnecco)
Date: Tue Jun  9 14:41:48 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <73766b160906091246m7732d7q8d9c3a487f870029@mail.gmail.com>
References: <4A2D7FD1.1010200@likeorhate.com>	<1244536887.350.19.camel@ophelia2.g5n.co.uk>	<4A2E7B4A.6010205@likeorhate.com>
	<73766b160906091246m7732d7q8d9c3a487f870029@mail.gmail.com>
Message-ID: <4A2ED866.2010703@likeorhate.com>

>>> VoteLinks are quite muddy and their meaning is pretty unclear.
> 
> I'd disagree there. The intent is clear -to be able to express
> agreement and disagreement with a linked-to page from the current
> context.
> 
> In practice, however, rel-nofollow has won out as disagreement, with
> plain links as agreement. The formulation above:
> 
> 
>  <a rev="vote-for" rel="nofollow" href="...">Like</a>
> 
> has 2 votes for the same thing, as rel="nofollow" is equivalent to
> rev="vote-abstain" - very hard to work out what your intent is there,.

	rel="nofollow" is used by many search engines as "don't follow this link" instead of 
the definition in the wiki: "SHOULD NOT be afforded any additional weight...". This is 
why it's there. I know robots.txt should handle this instead (it does), but many 
crawlers don't.

>>        It would be nice to have a more general microformat for associating a target with a "label", more or less like xfn.
> 
> you mean tagging a linked-to page? that's what xfolk is for:
> 
> http://microformats.org/wiki/xfolk
> 
> though in practice hReview seems to be used more widely for this.

	I don't mean for tags that already exist, but the action of tagging itself.

>> Again, the problem of "acting on" vs "having acted on" that confused me shows up. How about something like this rough draft to follow.
>>
>>        For acting on (polling):
>>
>> <div about="#something" class="item">
>>        <a href="..." rel="action:like">I like cheese</a>
>>        <a href="..." rel="action:blue">I think cheese is always blue</a>
>> </div>
>>
>>        For having acted on (similar to vote-links)
>>
>> <div about="#me" class="item">
>>        <a href="..." rev="opinion:like">I like cheese</a>
>>        <p href="..." rev="opinion:blue">I think cheese is always blue</a>
>> </div>
>>
>>        Although I think this later one should also have information about who likes it (perhaps an hCard), since we could, for example, have a list of expert opinions about cheese. But I don't like the exchanges of roles of "about" (I hope I got it right).
> 
> I think that HTML forms would likely be the dominant way to express a
> voting user interface when you did the analysis of existing markup
> that is a key part of the process; re-expressing this for links seems
> like a big step back.

	I agree, the links were just shorter to type. For example:

<form action="/something" method="POST">
	<button type="submit" name="vote" value="like">I like it</button>
	<input type="submit" name="vote" value="hate">I hate it</button>
</form>

	I think it would be useful to have a microformat which says: "this form is a poll 
about xxx". Is there one already? Does anybody else think it'd be useful?
From elli at sustainlane.com  Wed Jun 10 03:12:36 2009
From: elli at sustainlane.com (Elli Albek)
Date: Wed Jun 10 03:13:15 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <1244536887.350.19.camel@ophelia2.g5n.co.uk>
Message-ID: <1540635.1021244628756100.JavaMail.root@dexter>

I also think this is unclear. The terminology is not correct. "Vote" is commonly used as an action term. I was wondering about why there is a microformat for a user action, now I know there actually isn't :)

So my "vote" is:
1.	Change the overall terminology used on this microformat
2.	Rename this microformat
3.	Change the wiki page that explains it. Instead of having something that is not clear, and clarifying it in FAQ, it should be clear when you first read it. I can maybe spend some time on this page.
4.	I still vote for my previous comments about document structure, but reduced to hcard and not the other microformats, since opinion is associated with an entity. You should be able to show on a single page 3 users and each users "likes" and "don't likes" different things. You should also  be able to do it without the include pattern.

I would also guess that in our SEO heavy web world, developers will use it as the opposite of rel=nofollow. It will hint the search engine that users' votes rank this page high, so it should get more weight in the index relative to other pages in the domain. rel=nofollow is commonly used for downplaying a page's relative rank, so it does not have high link count inside your website (without completely evicting it from the index). This can be used to say that the link counts more than a normal link. It will probably turn into the standard mouse and cat game between SEO engineers and Google :)

From elli at sustainlane.com  Wed Jun 10 03:16:39 2009
From: elli at sustainlane.com (Elli Albek)
Date: Wed Jun 10 03:16:43 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <4A2D7FD1.1010200@likeorhate.com>
Message-ID: <16642995.1081244628999815.JavaMail.root@dexter>

Forgot another "vote":
I don't think microformats for user actions, like "vote", "email", "comment" are in the spirit of current microformats.
From mail at tobyinkster.co.uk  Wed Jun 10 04:10:57 2009
From: mail at tobyinkster.co.uk (Toby Inkster)
Date: Wed Jun 10 04:11:03 2009
Subject: [uf-discuss] Multiple vote-links
In-Reply-To: <73766b160906091246m7732d7q8d9c3a487f870029@mail.gmail.com>
References: <4A2D7FD1.1010200@likeorhate.com>
	<1244536887.350.19.camel@ophelia2.g5n.co.uk>
	<4A2E7B4A.6010205@likeorhate.com>
	<73766b160906091246m7732d7q8d9c3a487f870029@mail.gmail.com>
Message-ID: <1244632257.350.44.camel@ophelia2.g5n.co.uk>

On Tue, 2009-06-09 at 12:46 -0700, Kevin Marks wrote:
> They are links that express votes - if you can suggest clarifications
> to the text of the microformat page that make this clearer that would
> be appreciated.

I think clarifying VoteLinks is a task that goes beyond my abilities.

But this issue has been raised before, it's not an isolated case of
confusion, so I do think some sort of clarification is needed.

<http://microformats.org/wiki/vote-links-issues#Issues>

-- 
Toby Inkster <mail@tobyinkster.co.uk>
From tantek at cs.stanford.edu  Thu Jun 11 09:37:20 2009
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Thu Jun 11 09:37:25 2009
Subject: [uf-discuss] Any bettter way to do an include in hreview?
In-Reply-To: <3684239.39731244084736910.JavaMail.root@dexter>
References: <3684239.39731244084736910.JavaMail.root@dexter>
Message-ID: <60cb038a0906110937j31d08f40g4fc699f2df96185a@mail.gmail.com>

On Wed, Jun 3, 2009 at 8:05 PM, Elli Albek <elli@sustainlane.com> wrote:
>
> Hi Tantek.
>
> Link to a page with reviews:
> http://www.sustainlane.com/reviews/aziza/TVLWN4ZKQLKTOIKFLWKBWFQ17DN8
>
> You can also look at Yelp. Similar page content.

Thanks for the real world URL example - that helps a lot.

I've collected the example you gave and another similar example from
Yelp on the container-brainstorming page:

http://microformats.org/wiki/container-brainstorming#examples

I encourage you to add any other similar examples that you think may
help illustrate the problem and provide variants to test with any
possible/proposed solution.


> Two things we want:
> 1. ? ? ?Remove repetition
> 2. ? ? ?Add review aggregates without more repetition

Agreed on both counts.


> Generally I would like to stop using microformat_detail, and not restructure the HTML.
>
> The microformats spec can makes it easier to support variety of page structures
> without includes/hidden blocks by having other association rules.

In general one of the goals of microformats is to have minimal if any
markup impact upon the HTML of otherwise well-formed (hopefully valid)
pages, by only adding a few class names and perhaps rel values.
Sometimes additional elements are necessary for wrapping discrete
pieces of content. We very much try to avoid duplicating content - one
of the big advantages of microformats over alternatives such as using
XML or other side-files to duplicate the content, or inline HTML
comments to duplicate the content.


> A few suggestions that will make implementation simpler for different HTML trees:

I think there are definitely some good options worth exploring in your
suggestions, and I encourage you to add your markup suggestions to the
wiki (with perhaps one new subsection per each alternative you
suggested) so that they are not lost in the email archives, and so
that others may review and build upon them:

http://microformats.org/wiki/container-brainstorming#markup_proposals


> Another suggestion: Collapse trees. If microformats are already flexible
> in what they allow as parent child, you might as well consider a rule
> that allows you to collapse an entire tree of microformats:
>
> <a class="item hcard fn url" href="...">name</a>

The collapsing of properties with a root node actually presents more
problems, especially in the context of microformats that contain other
microformats (e.g. an hCard location in an hCalendar event).

http://microformats.org/wiki/hcard-faq#Can_you_mix_properties_and_the_root_class_name

That being said, your general suggestion of "collapse trees" is one
that I very much agree with, and am looking at doing so in some cases
in hCard to help resolve some of the issues raised (e.g. the fact that
"n" is a grouping property for the sub-properties of "given-name",
"family-name" etc.). More in http://tr.im/hcardri

Thanks,

Tantek

--
http://tantek.com/

From mirko.gustony at gmail.com  Sun Jun 14 23:44:03 2009
From: mirko.gustony at gmail.com (Mirko Gustony)
Date: Sun Jun 14 23:44:08 2009
Subject: [uf-discuss] Wanted: a pattern indicating a
	subsidiary-parent-company relationship
Message-ID: <c45799c80906142344t10d7b5ebrfdf850559dd4de5@mail.gmail.com>

Hello,

does anyone know if there is a pattern for describing a subsidiary
company to parent company relationship?

I need to mark up the following: on the website for company B Ltd. I
want to sho that it's a subsidiary of A Inc.

<p>
Part of <a href="http://www.a-inc.com/">A Inc.</a>
</p>

I tried to find something for this, but all I found was XFN which is
just for human beings. Maybe a solution can be based upon it?


Regards,
Mirko
From tantek at cs.stanford.edu  Mon Jun 15 14:50:04 2009
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Mon Jun 15 14:50:08 2009
Subject: [uf-discuss] Wanted: a pattern indicating a
	subsidiary-parent-company relationship
In-Reply-To: <c45799c80906142344t10d7b5ebrfdf850559dd4de5@mail.gmail.com>
References: <c45799c80906142344t10d7b5ebrfdf850559dd4de5@mail.gmail.com>
Message-ID: <60cb038a0906151450s451a91f9wd6a6f15c2be8c39f@mail.gmail.com>

On Sun, Jun 14, 2009 at 11:44 PM, Mirko Gustony<mirko.gustony@gmail.com> wrote:
> Hello,
>
> does anyone know if there is a pattern for describing a subsidiary
> company to parent company relationship?

Hi Mirko,

I don't know of any patterns currently, but you're certainly asking in
the right place.

> I need to mark up the following: on the website for company B Ltd. I
> want to sho that it's a subsidiary of A Inc.
>
> <p>
> Part of <a href="http://www.a-inc.com/">A Inc.</a>
> </p>

Could you provide a URL to the website for company B? [1]


> I tried to find something for this, but all I found was XFN which is
> just for human beings. Maybe a solution can be based upon it?

I've captured this area as "business to business" relationships on the
XFN brainstorming page, along with POSH suggestions:

http://microformats.org/wiki/xfn-brainstorming#business_to_business

Thanks,

Tantek

[1] http://microformats.org/wiki/mailing-lists#Use_real_world_examples

--
http://tantek.com/
From mirko.gustony at gmail.com  Tue Jun 16 00:42:55 2009
From: mirko.gustony at gmail.com (Mirko Gustony)
Date: Tue Jun 16 00:43:00 2009
Subject: [uf-discuss] Wanted: a pattern indicating a
	subsidiary-parent-company relationship
In-Reply-To: <60cb038a0906151450s451a91f9wd6a6f15c2be8c39f@mail.gmail.com>
References: <c45799c80906142344t10d7b5ebrfdf850559dd4de5@mail.gmail.com>
	<60cb038a0906151450s451a91f9wd6a6f15c2be8c39f@mail.gmail.com>
Message-ID: <c45799c80906160042g2252ec84w5b3b4ebbb52ee2ed@mail.gmail.com>

Hello Tantek,

On Mon, Jun 15, 2009 at 11:50 PM, Tantek ?elik<tantek@cs.stanford.edu> wrote:
>> I need to mark up the following: on the website for company B Ltd. I
>> want to sho that it's a subsidiary of A Inc.
>>
>> <p>
>> Part of <a href="http://www.a-inc.com/">A Inc.</a>
>> </p>
>
> Could you provide a URL to the website for company B? [1]

Unfortunately not for this particular use case. I am currently in the
process of redesigning a website where the requirement is to have a
text like the one above on every page in the header.

> I've captured this area as "business to business" relationships on the
> XFN brainstorming page, along with POSH suggestions:
>
> http://microformats.org/wiki/xfn-brainstorming#business_to_business

Thanks for pointing me there. I immediately stopped reading after the
stop words "human relations" :)

IMHO rel="controlling" seems to be a bit misleading to me.

Using my previous example:
<p>Part of <a href="http://www.a-inc.com/" rel="controlling">A Inc.</a></p>

I would understand (from the definition of rel-attribute [1]) that B
Ltd. is controlling A Inc. but it should the other way round (or do I
get it wrong?). So a better wording should be used (maybe
"parentgroup" or something like that). Whereas rel="subsidiary" should
be quite clear.

Anyway: A real world example could be [2] where the corporate group
links to its subsidiaries, and the subsidiaries will link back
indicating the reverse relation (this looks like a lot of javascript,
but you will get the idea).

Another example could be [3] for the same use case.

There might be another use case when companies are accredited dealers
of another company (and the other way round) and want to show this
using a microformat. An example could be [4].

> Thanks,
>
> Tantek
>

Regards,
Mirko


[1] "This attribute describes the relationship from the current
document to the anchor specified by the href attribute."
<http://www.w3.org/TR/html4/struct/links.html#adef-rel>
[2] <http://www.zeppelin.com/E/konzern/081965de.html>
[3] <http://www.ge.com/directory/business_sites.html>
[4] <http://www.cat.com/dealer-locator> (you'll have to start a search
to get a list of dealers)

From loertsch.thomas at guj.de  Wed Jun 17 07:42:56 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Wed Jun 17 07:43:20 2009
Subject: [uf-discuss] hRecipe in RDF
Message-ID: <C65ECD90.162A%loertsch.thomas@guj.de>

Hi,

I mapped hRecipe to an RDF vocabulary and added it as RDFa to our site
www.essen-und-trinken.de. The RDF mapping is documented on the wiki
http://microformats.org/wiki/hrecipe-rdf. I'd be glad to get some feedback!
I'm not quite sure if I will continue to work on a mapping of *all*
microformats to a RDF vocabulary since that's a lot of work. Any responses
on the hRecipe mapping might help me to make an informed decision :-)

Cheers,
Thomas


.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de




From loertsch.thomas at guj.de  Wed Jun 17 10:32:58 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Wed Jun 17 10:33:15 2009
Subject: [uf-discuss] hRecipe - status quo - how many elements
Message-ID: <C65EF56A.162F%loertsch.thomas@guj.de>

Hi again,

I'm indulging in hRecipe optimization and advancement today...

Early this year, when hRecipe had just reached Draft-status, Tantek raised
his head and cautioned that the format may contain too many elements and
that it's a *principle* of microformats to start (and maybe stay) small. I
tend more to the opinion that "small" is not a good criterium per se but
that the element set size should be "just right" to be most useful. We
settled the dispute (in which no one else joined) by marking the majority of
the properties as 'experimental' and cautioning their use.

Just as a reminder, this is the element set:
    fn    
    ingredient (value, type)
    yield 
    instructions  
    duration 
    photo
    summary
    author
    published
    nutrition (value, type)
    tag

I checked the usage of the hRecipe format today and was delighted to see
that Yahoo! searchmonkey lists 56.000 of them (search Yahoo for
"searchmonkey:com.yahoo.page.uf.recipe"). The site I work for is responsible
for about 12.000 of them but when i checked the first 70 results none of
them was from our site :-) In fact they almost all came from personal sites,
blogs and the like and this is really great! It was also very interesting to
see that a lot of them came from WordPress Blogs which shows that the
WordPress Plugin for hRecipe is very useful. But back to the issue: I
checked the first 60 or so results and about 2/3 of them where really using
hRecipe. 17 of them were from different sites(*) (**).

It's never bad to gather some empirical data to make an informed decision,
so I took the burden to count element use. Actually this didn't take much
more then an hour, so if somebody wants to check the results from 61 to ...
feel free! Well, now, without futher ado, the results (***):

 16   fn    
 17   ingredient (3 value, 3 type)
  3   yield 
 15   instructions 
  3   duration 
  4   photo
  9   summary
  4   author
  3   published
  1   nutrition (0 value, 0 type)
  2   tag

Of course this is not representative, but it gives a fairly good impression.
If you add our site (or 20% of all published hRecipes ;) you can add +1 to
all elements since we use everything...


Evaluation:

"fn", "ingredient" and "instructions" are no-brainers. Also "summary" is
surprisingly strong and the intuition, that it's a strong part of how people
communicate on recipes, seems to be right.

"author" and "published" probably didn't get so much used because on a blog
they are provided anyway and most of the sites investigated were blogs. OTOH
they aren't important for the functionality of a recipe and can be added by
other means. So maybe they should be removed for the sake of terseness.

"photo" was definitely less used than there were photos added to recipes.
And I know a lot of people who, when showed 2 recipes, one with and one
without photo, almost certainly choose the one with photo. So IMHO it should
stay.

"yield" was used surprisingly seldomly. Isn't it an essential addition to
the ingredients list? Maybe the yield is often self-explanatory, maybe this
reflects the fact, that also the value and type of ingredients wasn't marked
up most of the time. 'Smallishness' would certainly suggest to omit all the
three: "value", "type" and yield". People seem to feel that the "ingredient"
field naturally holds information not only about the name of the ingredient
but about type and value too and don't bother to mark these up explicitely.
Again for big sites which generate their content from databases the
cost-usage relation is totally different...

"duration" would be a candidate for removal as well. But still, remeber that
this list only reflects usage of the elements. An information of duration
was part of the recipe more often than it was marked up as such.

"tag" obviously didn't get used much and is maybe strong enough on it's own.
People add tags no matter if they are part of a vocabulary, and the rel-tag
pattern is certainly easy enough to grasp and straightforward to implement.
But the WordPress plugin added a tagging vocabulary on it's own (how dare
they... ;-) which did get used most of the time. So tagging principally is
strong. Well, I still don't have a clue on this one.

"nutrition" is definitely a candidate for removal, maybe into it's own
vocabulary. OTOH, big commercially backed sites very often provide
nutritional information and when provided it is a much more integral part of
the information context than say the author. So maybe it should stay?


Comments, thoughts?

Thomas 




(*) well, more of them, I skipped some WordPress Blogs since they all came
from the same Plugin. But as the feature set of the Plugin continues to grow
it doesn't make much sense to investigate them too thoroughly now unless you
want to take into account which version of the plugin was used exactly etc
etc - an undertaking I'm not really up to ;-)

(**) I felt quite bad when I saw that a lot of them used the pre-0.2 version
with "title", "method" etc but I really don't know what I could do about it
now (or then, too). I guess these decisions are made and the pain will
diminish over time (cough).

(***) The full result-set, including URLs, is on the
microformats.org/wiki/hrecipe-issues page.




.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de




From mail at tobyinkster.co.uk  Wed Jun 17 10:43:29 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Wed Jun 17 10:42:43 2009
Subject: [uf-discuss] hRecipe in RDF
In-Reply-To: <C65ECD90.162A%loertsch.thomas@guj.de>
References: <C65ECD90.162A%loertsch.thomas@guj.de>
Message-ID: <9F22451D-2E8B-4CB0-84BA-ADD876C3698F@tobyinkster.co.uk>

On 17 Jun 2009, at 15:42, Thomas Loertsch wrote:

> I'm not quite sure if I will continue to work on a mapping of *all*
> microformats to a RDF vocabulary since that's a lot of work.


Seen http://poshrdf.org/ns/mf# ?

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From loertsch.thomas at guj.de  Thu Jun 18 02:45:53 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Thu Jun 18 02:46:01 2009
Subject: [uf-discuss] hRecipe in RDF
In-Reply-To: <9F22451D-2E8B-4CB0-84BA-ADD876C3698F@tobyinkster.co.uk>
Message-ID: <C65FD971.1639%loertsch.thomas@guj.de>

On 17.06.09 19:43, "Toby A Inkster" <mail@tobyinkster.co.uk> wrote:

> On 17 Jun 2009, at 15:42, Thomas Loertsch wrote:
> 
>> I'm not quite sure if I will continue to work on a mapping of *all*
>> microformats to a RDF vocabulary since that's a lot of work.
> 
> 
> Seen http://poshrdf.org/ns/mf# ?

yep, and spoken to benjamin too. poshrdf is a rather automatic conversion
and that shows at the edges. my approach is a little more involved and even
adds some owl-fancyness to describe constraints on value types, mappings to
other vocabularies etc.

thomas


.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de




From alpern at yahoo-inc.com  Thu Jun 18 11:30:08 2009
From: alpern at yahoo-inc.com (Micah Alpern)
Date: Thu Jun 18 11:31:47 2009
Subject: [uf-discuss] Vocamp in Sunnyvale (6/18 & 6/19) - Limited space
	avaliable
Message-ID: <F6B17686532FCE4FAB20EA9C04AEAE1003F83B8C@SNV-EXVS07.ds.corp.yahoo.com>

Hi all, sorry for the last minute notice, but I wanted to let people
know about a VoCamp that's being held in Sunnyvale and organized with
the help of Yahoo.

http://vocamp.org/wiki/VoCampSunnyvale2009

The conference is pretty much full up, but we may have 1 or 2 slots
available for people who work on microformats as vocabulary editors or
implementers. If you're interested please call my cell: 408.209.9509.
Sorry again for the last minute notice. Next time we host a Vocamp I'll
make sure we post it to this list early.

Thanks,

Micah


From bjonkman at sobac.com  Thu Jun 18 12:00:29 2009
From: bjonkman at sobac.com (Bob Jonkman)
Date: Thu Jun 18 12:01:08 2009
Subject: [uf-discuss] Google announces Microformats/RDFa support!
In-Reply-To: <4A09CEA1.9010303@digitalbazaar.com>
References: <4A09CEA1.9010303@digitalbazaar.com>
Message-ID: <4A3A8ECD.6040605@sobac.com>

This is great! But browsing through the Google site I believe there is 
an error, suggesting that hcard uses

  class="v:title"

http://google.com/support/webmasters/bin/answer.py?answer=146646  in the 
section "Example: Microformat/XFN"

It appears to be a cut'n'paste error from the RDF section.

There is no feedback link on the page -- how can we contact Google to 
get that fixed?

--Bob.


Manu Sporny wrote:
> The subject line says it all - Google just announced support for various
> Microformats and RDFa!
>
> Here's the Google FAQ page on structured data:
> http://google.com/support/webmasters/bin/answer.py?hl=en&answer=99170
>
> Here's the announcement on the RDFa mailing list:
> http://lists.w3.org/Archives/Public/public-rdfa/2009May/0011.html
>
> Congrats to everyone in the community and everyone that has helped
> create a Microformat!
>
> -- manu
>
>   

-- 
Bob Jonkman <bjonkman@sobac.com>         http://sobac.com/sobac/
SOBAC Microcomputer Services              Voice: +1-519-669-0388
6 James Street, Elmira ON  Canada  N3B 1L5  Cel: +1-519-635-9413
Software   ---   Office & Business Automation   ---   Consulting


From andr3.pt at gmail.com  Thu Jun 18 12:27:53 2009
From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=)
Date: Thu Jun 18 12:27:57 2009
Subject: [uf-discuss] Operator for Firefox 3.5?
Message-ID: <dc1a17860906181227y177e8aefw875f6261101eb293@mail.gmail.com>

Hello everyone,

does anyone know whether we'll have an Operator update for Firefox 3.5
anytime soon?

I've tried reaching out to Michael Kaply, but I got no reply.

Anyone has any info on this? If not, is there any addon out there that
comes close to Operator but instead uses the Microformats API of
Firefox 3?

Thanks in advance,
--
Andr? Lu?s

From rkhare at gmail.com  Thu Jun 18 13:54:02 2009
From: rkhare at gmail.com (Rohit Khare)
Date: Thu Jun 18 13:54:25 2009
Subject: [uf-discuss] Re: Vocamp at Yahoo! on Thur & Fri ( 6/18 - 6/19)?
Message-ID: <1440731627-1245358460-cardhu_decombobulator_blackberry.rim.net-359288843-@bxe1179.bisx.prod.on.blackberry>

There's a great event starting in an hour or so in Sunnyvale, VoCamp. Unfortunately, I can't make it but we can reassign a spare spot to microfolk who may be passionate and prepared to swap experience with other participants. 

I know it?s rather short notice for Vocamp hosting at Yahoo! this Thur and Friday (June 18/19th).? 

http://vocamp.org/wiki/VoCampSunnyvale2009

So if someone wants my spot (it's quite full already sorry) please ping Micah directly or me. 

Thanks, Rohit
Sent via BlackBerry by AT&T

From bjonkman at sobac.com  Fri Jun 19 13:08:38 2009
From: bjonkman at sobac.com (Bob Jonkman)
Date: Fri Jun 19 13:09:44 2009
Subject: [uf-discuss] Google announces Microformats/RDFa support!
In-Reply-To: <4A3A8ECD.6040605@sobac.com>
References: <4A09CEA1.9010303@digitalbazaar.com> <4A3A8ECD.6040605@sobac.com>
Message-ID: <4A3BF046.3050107@sobac.com>

Fixed!  There must be a Googleplexian reading this list :-)

--Bob.


Bob Jonkman wrote:
> This is great! But browsing through the Google site I believe there is 
> an error, suggesting that hcard uses
>
>  class="v:title"
>
> http://google.com/support/webmasters/bin/answer.py?answer=146646  in 
> the section "Example: Microformat/XFN"
>
> It appears to be a cut'n'paste error from the RDF section.
>
> There is no feedback link on the page -- how can we contact Google to 
> get that fixed?
>
> --Bob.
>
>
> Manu Sporny wrote:
>> The subject line says it all - Google just announced support for various
>> Microformats and RDFa!
>>
>> Here's the Google FAQ page on structured data:
>> http://google.com/support/webmasters/bin/answer.py?hl=en&answer=99170
>>
>> Here's the announcement on the RDFa mailing list:
>> http://lists.w3.org/Archives/Public/public-rdfa/2009May/0011.html
>>
>> Congrats to everyone in the community and everyone that has helped
>> create a Microformat!
>>
>> -- manu
>>
>>   
>

-- 
Bob Jonkman <bjonkman@sobac.com>         http://sobac.com/sobac/
SOBAC Microcomputer Services              Voice: +1-519-669-0388
6 James Street, Elmira ON  Canada  N3B 1L5  Cel: +1-519-635-9413
Software   ---   Office & Business Automation   ---   Consulting


From kavi at google.com  Fri Jun 19 13:38:39 2009
From: kavi at google.com (Kavi Goel)
Date: Fri Jun 19 13:38:47 2009
Subject: [uf-discuss] Google announces Microformats/RDFa support!
In-Reply-To: <4A3BF046.3050107@sobac.com>
References: <4A09CEA1.9010303@digitalbazaar.com> <4A3A8ECD.6040605@sobac.com>
	<4A3BF046.3050107@sobac.com>
Message-ID: <199b56630906191338k6d89502ud18a1e5ce92c48a5@mail.gmail.com>

Thanks Bob for the bug fix! Yes, we noticed your suggestion and made
the change in our docs. We have also read the very useful examples
page?(http://microformats.org/wiki/google-rich-snippets-examples) on
the microformats wiki, and have made many of the simple fixes that
were raised. I've been a bit swamped so we haven't addressed
everything in the doc quite yet, but we really appreciate the
bug-fixes, feedback and suggestions.

Kavi

On Fri, Jun 19, 2009 at 1:08 PM, Bob Jonkman <bjonkman@sobac.com> wrote:
>
> Fixed! ?There must be a Googleplexian reading this list :-)
>
> --Bob.
>
>
> Bob Jonkman wrote:
>>
>> This is great! But browsing through the Google site I believe there is an error, suggesting that hcard uses
>>
>> ?class="v:title"
>>
>> http://google.com/support/webmasters/bin/answer.py?answer=146646 ?in the section "Example: Microformat/XFN"
>>
>> It appears to be a cut'n'paste error from the RDF section.
>>
>> There is no feedback link on the page -- how can we contact Google to get that fixed?
>>
>> --Bob.
>>
>>
>> Manu Sporny wrote:
>>>
>>> The subject line says it all - Google just announced support for various
>>> Microformats and RDFa!
>>>
>>> Here's the Google FAQ page on structured data:
>>> http://google.com/support/webmasters/bin/answer.py?hl=en&answer=99170
>>>
>>> Here's the announcement on the RDFa mailing list:
>>> http://lists.w3.org/Archives/Public/public-rdfa/2009May/0011.html
>>>
>>> Congrats to everyone in the community and everyone that has helped
>>> create a Microformat!
>>>
>>> -- manu
>>>
>>>
>>
>
> --
> Bob Jonkman <bjonkman@sobac.com> ? ? ? ? http://sobac.com/sobac/
> SOBAC Microcomputer Services ? ? ? ? ? ? ?Voice: +1-519-669-0388
> 6 James Street, Elmira ON ?Canada ?N3B 1L5 ?Cel: +1-519-635-9413
> Software ? --- ? Office & Business Automation ? --- ? Consulting
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From jmyers at visi.com  Mon Jun 22 09:54:31 2009
From: jmyers at visi.com (Jay Myers)
Date: Mon Jun 22 09:54:42 2009
Subject: [uf-discuss] Proposed changes to hListing
Message-ID: <web-18375315@mailback1.g2host.com>

All,

A couple of months ago, changes were suggested to the 
hListing microformat to support more transaction-related 
attributes, including the addition of 'availability', 
'condition', and 'shipping'. In order to prove the 80%+ 
use case, research has been ongoing and has been posted up 
to the hListing examples [1] wiki page. To date, analysis 
on 87 commerce or listing sites has been performed, and 
has yielded these results:

* Availability (79.1%)
* Condition (71.2%)
* Shipping (82%)

I would like to see all three adopted into a new draft of 
hListing, at the very least availability and shipping. All 
three new proposed attributes are featured in other 
product listing ontologies, most notably the GoodRealtions 
ontology
for e-commerce. I will be proposing another version of 
hListing in the coming weeks with these three new 
attributes, and some minor modifications to the existing 
attribute set, taking into account any feedback from the 
microformats community, which can be posted on the 
hlisting-brainstorming wiki page [2].

Please let me know if you have any questions or feedback!

[1] http://microformats.org/wiki/hlisting-examples
[2] http://microformats.org/wiki/hlisting-brainstorming

Thanks,

Jay Myers

blog: http://jay.beweep.com
email: jmyers@visi.com
mobile: +1 612-296-5836
twitter: @jaymyers

From loertsch.thomas at guj.de  Wed Jun 24 06:51:35 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Wed Jun 24 06:51:55 2009
Subject: [uf-discuss] mixing vocabularies
Message-ID: <C667FC07.1686%loertsch.thomas@guj.de>

hi all,

a question: when contemplating over the feature set of hRecipe it occured to
me that i don't seem to get the rational of mixing vocabularies in all it's
subtleties. e.g. why should i add rel-tag to the hRecipe vocabulary when
people can use rel-tag anyway on any element they want to? likewise for
author and date. 
if i understand correctly the way meta information is added to the DOM
defines which elements are described. when investigating the use of hRecipe
i often found some top level div containing the recipe marked up with
classes hRecipe and some other vocabulary e.g. <div id="yet_another_recipe"
class="hrecipe vcard">. recipe specific elements where then marked up with
hrecipe vocabulary while the author was marked up as vcard. this seems like
a sensible approach to me. or does it make the job for parsers much harder?

that led to the idea of restructuring the hRecipe element set in a way that
the core element set remains the same (since in the editors opinion it
really features only those fields that are essential for describing a
recipe, and experience with implementation so far supports this view) but
the fields marked as "experimental" get re-labeled as "supplemental".
rational: they are considered useful and in common use for describing
recipes but they are not specific to recipes and already part of well
established vocabularies. therefor there use is encouraged and since they
are part of very popular vocabularies it's reasonable to expect that a
decent microformats parser will recognize and handle them properly. but they
are not intended to get a part of hRecipe now or at a future time.

i wonder if this is a viable approach? maybe it has been implemented in some
other microformat which i'm not aware of? or maybe there are reasons why it
shouldn't be pursued?

cheers
thomas


.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de




From brian.suda at gmail.com  Wed Jun 24 07:23:22 2009
From: brian.suda at gmail.com (Brian Suda)
Date: Wed Jun 24 07:23:26 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <C667FC07.1686%loertsch.thomas@guj.de>
References: <C667FC07.1686%loertsch.thomas@guj.de>
Message-ID: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>

On Wed, Jun 24, 2009 at 1:51 PM, Thomas Loertsch<loertsch.thomas@guj.de> wrote:
> hi all,
>
> a question: when contemplating over the feature set of hRecipe it occured to
> me that i don't seem to get the rational of mixing vocabularies in all it's
> subtleties. e.g. why should i add rel-tag to the hRecipe vocabulary when
> people can use rel-tag anyway on any element they want to? likewise for
> author and date.

--- When you have a single vocabulary for all microformats you get the
benefit of calling a URL in hCard the same thing as a URL in
hCalender. If you have an hRecipe on a page with Rel-Tag "cake" that
page is inpart about "cake" so a parser that is extracting Recipes get
the hRecipe and a rel-tag parser gets the tags too. Had hRecipe called
their rel-tags something else, then you?d be doubling-up class values
on tags, one for plain rel-tag and one for the hRecipe. So having just
1 vocabulary means that parses can be aware of the formats they know
and extract them from anywhere in the page, even if they are within
other formats.

> if i understand correctly the way meta information is added to the DOM
> defines which elements are described. when investigating the use of hRecipe
> i often found some top level div containing the recipe marked up with
> classes hRecipe and some other vocabulary e.g. <div id="yet_another_recipe"
> class="hrecipe vcard">. recipe specific elements where then marked up with
> hrecipe vocabulary while the author was marked up as vcard. this seems like
> a sensible approach to me. or does it make the job for parsers much harder?

Now, it makes it easier for parsers. a vCard is a vCard, even if it's
in an hRecipe or standing alone, the semantic data is the same.
Instead or re-inventing the wheel each time, existing formats are
used. Then hCard parsers don't need to be updated to know how to
extract person data out of an hRecipe, etc.

I hope that makes sense. You should add this to the Wiki under the
FAQs, then we can all iterate on the best answer.

-brian

-- 
brian suda
http://suda.co.uk

From lists at ben-ward.co.uk  Wed Jun 24 11:38:40 2009
From: lists at ben-ward.co.uk (Ben Ward)
Date: Wed Jun 24 11:38:48 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <C667FC07.1686%loertsch.thomas@guj.de>
References: <C667FC07.1686%loertsch.thomas@guj.de>
Message-ID: <6C57F19E-D87B-4061-BCB3-C377E5172CD1@ben-ward.co.uk>

Hi Thomas,

On 24 Jun 2009, at 06:51, Thomas Loertsch wrote:

> a question: when contemplating over the feature set of hRecipe it  
> occured to
> me that i don't seem to get the rational of mixing vocabularies in  
> all it's
> subtleties. e.g. why should i add rel-tag to the hRecipe vocabulary  
> when
> people can use rel-tag anyway on any element they want to? likewise  
> for
> author and date.
>
> if i understand correctly the way meta information is added to the DOM
> defines which elements are described. when investigating the use of  
> hRecipe
> i often found some top level div containing the recipe marked up with
> classes hRecipe and some other vocabulary e.g. <div  
> id="yet_another_recipe"
> class="hrecipe vcard">. recipe specific elements where then marked  
> up with
> hrecipe vocabulary while the author was marked up as vcard. this  
> seems like
> a sensible approach to me. or does it make the job for parsers much  
> harder?

The following explanation could definitely be refined a bit, since I  
just made it up, but the way I tend to think of it goes something like  
this:

I'd explain it is less in terms of ?combining vocabularies?, and more  
in terms of combing *objects*. Using hCard for the `author` of a  
recipe is not importing the hCard vocabulary into hRecipe, it's that  
the `author` is a discrete hCard object within an hRecipe object. Each  
object uses a separate vocabulary.

This is perhaps better illustrated by hReview, since that shares the  
`fn` terms with hCard, and the way in which they do not conflict makes  
a clearer example:

hReview has an fn (formatted-name) property, and uses hCard for  
author. As such, a complete hReview structure will include two  
class='fn' elements, one for the name of the reviewed item and one for  
the name of the hCard. As such, in parsing, you are not consuming one  
combined hReview+hCard vocabulary, but instead two distinct objects,  
and hReview, of which the author property is an hCard.

That's why the class="vcard" is inside the hreview is combined to make  
class="author vcard", rather than higher up the DOM.

> but
> the fields marked as "experimental" get re-labeled as "supplemental".
> rational: they are considered useful and in common use for describing
> recipes but they are not specific to recipes and already part of well
> established vocabularies. therefor there use is encouraged and since  
> they
> are part of very popular vocabularies it's reasonable to expect that a
> decent microformats parser will recognize and handle them properly.  
> but they
> are not intended to get a part of hRecipe now or at a future time.

Within a freeform merging-vocabularies model this follows (although I  
think it's a level of complexity that runs counter to microformats  
starting simple), but within the object-esque model that microformats  
map to, it doesn't.

Reuse of other microformats (rel-tag, hcard, etc.) occurs when those  
existing microformats are the most appropriate way to mark-up a  
compound part of a microformat (recipes have authors, those are  
people, or perhaps credited to restaurants, thus hCard).

So it boils down to: Is there a case for tagging recipes? If yes, then  
each recipe tag will be a rel-tag structure. If not, then tagging  
should be left out of the spec.

Regards,

Ben
From pmika at yahoo-inc.com  Wed Jun 24 18:55:51 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Wed Jun 24 18:56:25 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
References: <C667FC07.1686%loertsch.thomas@guj.de>
	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
Message-ID: <4A42D927.8080905@yahoo-inc.com>

Unfortunately, the combination of microformats is not as simple issue as 
it seems. I know that certain combinations are explicitly sanctioned by 
the specifications, but the users are trying all kinds of combinations 
that are not explicitly forbidden, but lead to confusion on the part of 
whoever needs to parse it.

Look at for example at [1]. This page contains the following markup:

<table class="infobox infobox vcard vevent" cellspacing="5" 
style="width: 22em; text-align: left; font-size: 88%; line-height: 
1.5em; font-size:90%; text-align:left;">
<tr>
<td colspan="2" class="fn summary" style="text-align:center; font-size: 
125%; font-weight: bold; font-size:110%; background:khaki;">Kevin Bacon</td>
</tr>

If I look at it strictly, I have a vcard and an event object which both 
have the name "Kevin Bacon". However, what the author intended is 
probably a person object, with some terms borrowed from vevent (not sure 
which ones).

So what do you guys think about this? Note that on our side this 
introduces the secondary problem that we now have to figure which object 
is the main topic of the page (it's very clear for the human!)

Thanks,
Peter

[1] http://www.answers.com/topic/kevin-bacon


Brian Suda wrote:
> On Wed, Jun 24, 2009 at 1:51 PM, Thomas Loertsch<loertsch.thomas@guj.de> wrote:
>   
>> hi all,
>>
>> a question: when contemplating over the feature set of hRecipe it occured to
>> me that i don't seem to get the rational of mixing vocabularies in all it's
>> subtleties. e.g. why should i add rel-tag to the hRecipe vocabulary when
>> people can use rel-tag anyway on any element they want to? likewise for
>> author and date.
>>     
>
> --- When you have a single vocabulary for all microformats you get the
> benefit of calling a URL in hCard the same thing as a URL in
> hCalender. If you have an hRecipe on a page with Rel-Tag "cake" that
> page is inpart about "cake" so a parser that is extracting Recipes get
> the hRecipe and a rel-tag parser gets the tags too. Had hRecipe called
> their rel-tags something else, then you?d be doubling-up class values
> on tags, one for plain rel-tag and one for the hRecipe. So having just
> 1 vocabulary means that parses can be aware of the formats they know
> and extract them from anywhere in the page, even if they are within
> other formats.
>
>   
>> if i understand correctly the way meta information is added to the DOM
>> defines which elements are described. when investigating the use of hRecipe
>> i often found some top level div containing the recipe marked up with
>> classes hRecipe and some other vocabulary e.g. <div id="yet_another_recipe"
>> class="hrecipe vcard">. recipe specific elements where then marked up with
>> hrecipe vocabulary while the author was marked up as vcard. this seems like
>> a sensible approach to me. or does it make the job for parsers much harder?
>>     
>
> Now, it makes it easier for parsers. a vCard is a vCard, even if it's
> in an hRecipe or standing alone, the semantic data is the same.
> Instead or re-inventing the wheel each time, existing formats are
> used. Then hCard parsers don't need to be updated to know how to
> extract person data out of an hRecipe, etc.
>
> I hope that makes sense. You should add this to the Wiki under the
> FAQs, then we can all iterate on the best answer.
>
> -brian
>
>   

From lists at ben-ward.co.uk  Wed Jun 24 22:37:47 2009
From: lists at ben-ward.co.uk (Ben Ward)
Date: Wed Jun 24 22:37:56 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A42D927.8080905@yahoo-inc.com>
References: <C667FC07.1686%loertsch.thomas@guj.de>
	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<4A42D927.8080905@yahoo-inc.com>
Message-ID: <B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>

Hi Peter,

On 24 Jun 2009, at 18:55, Peter Mika wrote:

> Look at for example at [1]. This page contains the following markup:
>
> <table class="infobox infobox vcard vevent" cellspacing="5"  
> style="width: 22em; text-align: left; font-size: 88%; line-height:  
> 1.5em; font-size:90%; text-align:left;">
> <tr>
> <td colspan="2" class="fn summary" style="text-align:center; font- 
> size: 125%; font-weight: bold; font-size:110%;  
> background:khaki;">Kevin Bacon</td>
> </tr>
>
> If I look at it strictly, I have a vcard and an event object which  
> both have the name "Kevin Bacon". However, what the author intended  
> is probably a person object, with some terms borrowed from vevent  
> (not sure which ones).

So, in this case the vevent in that page ? http://www.answers.com/topic/kevin-bacon 
  ? is invalid ? certainly incomplete. That structure doesn't contain  
any dates at all.

What I posit has happened is that at one point, answers.com marked up  
the ?Years Active? part of that info box with dtstart and dtend.

They're not marking up one object with a combined vocabulary, they're  
marking up two objects: One card (for Kevin Bacon) and one event  
(Kevin Bacon's Career).

I think they backed out dates at some point, but have left the root  
class and summary class in place. With the dates in place, two  
distinct but valid objects would be parsed out.

Answers.com could instruct someone on how to parse the two  
microformats in combination for additional context, but the structures  
standalone too.

> So what do you guys think about this? Note that on our side this  
> introduces the secondary problem that we now have to figure which  
> object is the main topic of the page (it's very clear for the human!)

Figuring out ?the microformat for the page? is not a consequence of  
?mixing vocabularies? in this context; that is, overlapping or  
integrated structures. It's a problem presented when you have multiple  
objects (of any structured data origin) anywhere in the same page.  
That's a really interesting problem in itself, but not directly  
correlated with this one.

I'll start up a brainstorming page for that though; we talked about it  
with the other SearchMonkey guys at the ?f dinner a few weeks ago.

Cheers,

Ben
From danbri at danbri.org  Wed Jun 24 23:02:04 2009
From: danbri at danbri.org (Dan Brickley)
Date: Wed Jun 24 23:02:10 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>
References: <C667FC07.1686%loertsch.thomas@guj.de>	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<4A42D927.8080905@yahoo-inc.com>
	<B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>
Message-ID: <4A4312DC.1070002@danbri.org>

Hi Ben,

On 25/6/09 07:37, Ben Ward wrote:
> Hi Peter,
>
> On 24 Jun 2009, at 18:55, Peter Mika wrote:
>
>> Look at for example at [1]. This page contains the following markup:
>>
>> <table class="infobox infobox vcard vevent" cellspacing="5"
>> style="width: 22em; text-align: left; font-size: 88%; line-height:
>> 1.5em; font-size:90%; text-align:left;">
>> <tr>
>> <td colspan="2" class="fn summary" style="text-align:center;
>> font-size: 125%; font-weight: bold; font-size:110%;
>> background:khaki;">Kevin Bacon</td>
>> </tr>
>>
>> If I look at it strictly, I have a vcard and an event object which
>> both have the name "Kevin Bacon". However, what the author intended is
>> probably a person object, with some terms borrowed from vevent (not
>> sure which ones).
>
> So, in this case the vevent in that page ?
> http://www.answers.com/topic/kevin-bacon ? is invalid ? certainly
> incomplete. That structure doesn't contain any dates at all.

Does a validator exist that can detect this? If not, could one be built?



> Figuring out ?the microformat for the page? is not a consequence of
> ?mixing vocabularies? in this context; that is, overlapping or
> integrated structures. It's a problem presented when you have multiple
> objects (of any structured data origin) anywhere in the same page.
> That's a really interesting problem in itself, but not directly
> correlated with this one.

Yep. Even if it's all hcard, ie. a single vocabulary, there are concerns 
like http://microformats.org/wiki/representative-hcard and 
http://microformats.org/wiki/hcards-and-pages --- figuring out what the 
relationships are between the different people mentioned, or between 
those people and the page that describes them.

> I'll start up a brainstorming page for that though; we talked about it
> with the other SearchMonkey guys at the ?f dinner a few weeks ago.

great :)

Dan
From pmika at yahoo-inc.com  Wed Jun 24 23:04:24 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Wed Jun 24 23:05:05 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>
References: <C667FC07.1686%loertsch.thomas@guj.de>	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<4A42D927.8080905@yahoo-inc.com>
	<B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>
Message-ID: <4A431368.8090506@yahoo-inc.com>

Hi Ben,

>
> What I posit has happened is that at one point, answers.com marked up 
> the ?Years Active? part of that info box with dtstart and dtend.
Yes, but let's assume they had the dtstart, i.e. a valid event and a 
card. Still, having an event named 'Kevin Bacon' is dubious. However, 
they might have gotten the idea that it's ok to do this, because the two 
microformats share the fn property. So they could have thought, why 
repeat it twice?

I would suggest a page that describes precise what combinations of 
microformats are allowed, e.g. that an adr inside hcard is ok, but a 
recipe inside an hresume is not.
>
> Figuring out ?the microformat for the page? is not a consequence of 
> ?mixing vocabularies? in this context; that is, overlapping or 
> integrated structures. It's a problem presented when you have multiple 
> objects (of any structured data origin) anywhere in the same page. 
> That's a really interesting problem in itself, but not directly 
> correlated with this one.
You are right, not directly related, although the problem is much less 
acute with RDFa, where the publisher would typically relate all the 
objects on the page so the data forms a single graph. Should have wrote 
a separate email on this problem ;)

Cheers,
Peter
From lists at ben-ward.co.uk  Wed Jun 24 23:47:57 2009
From: lists at ben-ward.co.uk (Ben Ward)
Date: Wed Jun 24 23:48:05 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A4312DC.1070002@danbri.org>
References: <C667FC07.1686%loertsch.thomas@guj.de>	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<4A42D927.8080905@yahoo-inc.com>
	<B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>
	<4A4312DC.1070002@danbri.org>
Message-ID: <E4A4E482-5F3B-4181-98C3-E9011EB50639@ben-ward.co.uk>

On 24 Jun 2009, at 23:02, Dan Brickley wrote:

>> So, in this case the vevent in that page ?
>> http://www.answers.com/topic/kevin-bacon ? is invalid ? certainly
>> incomplete. That structure doesn't contain any dates at all.
>
> Does a validator exist that can detect this? If not, could one be  
> built?

Yes. Optimus flags the error:

<http://microformatique.com/optimus/?format=validate&uri=http://www.answers.com/topic/kevin-bacon 
 >

>> I'll start up a brainstorming page for that though; we talked about  
>> it
>> with the other SearchMonkey guys at the ?f dinner a few weeks ago.
>
> great :)

I've started a new brainstorming page at http://microformats.org/wiki/representative-object-brainstorming 
  to collect any and all thoughts on how you might prioritise one  
object over another in a page. Everyone is encouraged to add their  
thoughts and any techniques they have.

I've referenced the representative-hcard page there.

Cheers,

Ben



From mail at tobyinkster.co.uk  Thu Jun 25 01:02:19 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Thu Jun 25 01:01:25 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A42D927.8080905@yahoo-inc.com>
References: <C667FC07.1686%loertsch.thomas@guj.de>
	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<4A42D927.8080905@yahoo-inc.com>
Message-ID: <3E5C8BBA-E913-4D0F-802C-0C8F2D63386D@tobyinkster.co.uk>

On 25 Jun 2009, at 02:55, Peter Mika wrote:

> class="infobox infobox vcard vevent"


Related wiki page:
http://microformats.org/wiki/compositing

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>



From lists at ben-ward.co.uk  Thu Jun 25 02:15:03 2009
From: lists at ben-ward.co.uk (Ben Ward)
Date: Thu Jun 25 02:15:12 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A431368.8090506@yahoo-inc.com>
References: <C667FC07.1686%loertsch.thomas@guj.de>	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<4A42D927.8080905@yahoo-inc.com>
	<B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>
	<4A431368.8090506@yahoo-inc.com>
Message-ID: <C4333D95-4B47-4674-9CA7-37C8CBAA311C@ben-ward.co.uk>

Hi Peter,

On 24 Jun 2009, at 23:04, Peter Mika wrote:

>> What I posit has happened is that at one point, answers.com marked  
>> up the ?Years Active? part of that info box with dtstart and dtend.
>
> Yes, but let's assume they had the dtstart, i.e. a valid event and a  
> card. Still, having an event named 'Kevin Bacon' is dubious.

It's not a high quality object, I agree. But, it's valid. It describes  
a timespan and that's a valid event.

> However, they might have gotten the idea that it's ok to do this,  
> because the two microformats share the fn property. So they could  
> have thought, why repeat it twice?

I don't agree, although we should acknowledge here that we're both  
second guessing another developer's intent. I don't think the scenario  
you describe is a concern, and we've never had any prior suggestion of  
it occurring. With reference to this case:

   * hCalendar does not have an `fn` property, no example here or  
elsewhere would instruct someone to use `fn` in hCal.
   * The mark-up here explicitly uses `summary` and `fn`. That "Kevin  
Bacon" is an incomplete name for an event from a content quality  
perspective is not in dispute, but the author explicitly made it the  
summary of their event. They didn't add a second summary attribute  
elsewhere in the content, expecting it to be amalgamated.

I think it's most likely that the developer is just trying to describe  
all the data they have available using the tools they have: There's an  
hCard there and there's an event. Someone trying to parse his page  
specifically could imply information from the hCard+hCalendar, and  
that's cool, but at the core he's tried to describe his complex  
content using the building blocks available.

Either way, we can't be certain without consulting with them. I don't  
think it's evidence of erroneous confusion.

> I would suggest a page that describes precise what combinations of  
> microformats are allowed, e.g. that an adr inside hcard is ok, but a  
> recipe inside an hresume is not.

I might not be following you quite right here, I keep interpreting  
this sentence in opposite ways each time I read it. I'm going to  
answer both interpretations for completeness:

1. I don't think there is any concept of 'allowed' vs. 'not'. There's  
obviously no specified relationship between Resum? and Recipe (at this  
time? cue every unemployed chef on the world wide web joining ?f- 
discuss? ha), but that doesn't mean a piece of content within that  
resume document couldn't be a recipe. A chef could include their  
favourite salad dressing recipe in their resum? as part of the  
description of some work experience. The example doesn't matter: There  
shouldn't be no restriction on describing one piece of structured  
data, independently of another, based on what the outer-most structure  
is.

In terms of ?f that have explicit function within another microformat,  
that is already documented as part of the specs. ADR is part of hCard,  
hAtom specifies authors must be hCard, hReview specifies that  
class="item vevent" means you're reviewing an event. And so on. Any  
unspecified combination should be treated as two discrete objects.

2. On the flip side, if you mean that we should provide fuller  
specifications of what microformats do mean in combination, that's a  
different issue, but one that again there's limited demand for.  
Combinations (say, using hCal inside of hResume for experience) get  
worked out in response to use cases, either in the initial development  
of a spec or later, either way not pre-emptively. Using hCalendar for  
life-spans (in place of an hCard date-of-death field), was an example  
that came up a few years ago.

People experiment with combinations in their own pages where it makes  
sense to them; no different to publishing with any other HTML element.  
Those experiments may influence brainstorming for specifying new  
patterns.

Like all new uses of microformats, ideas about uses of combined  
microformats should be documented on each microformat's *- 
brainstorming page.

Thanks,

Ben
From loertsch.thomas at guj.de  Thu Jun 25 06:53:39 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Thu Jun 25 06:53:52 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <C4333D95-4B47-4674-9CA7-37C8CBAA311C@ben-ward.co.uk>
Message-ID: <C6694E03.16B9%loertsch.thomas@guj.de>

hi all,

thanks for the nice discussion!

On 25.06.09 11:15, "Ben Ward" <lists@ben-ward.co.uk> wrote:

>> However, they might have gotten the idea that it's ok to do this,
>> because the two microformats share the fn property. So they could
>> have thought, why repeat it twice?
> 
> I don't agree, although we should acknowledge here that we're both
> second guessing another developer's intent. I don't think the scenario
> you describe is a concern, and we've never had any prior suggestion of
> it occurring. 

really? i would have done this without hesitation if my data had suggested
it.

>> I would suggest a page that describes precise what combinations of
>> microformats are allowed, e.g. that an adr inside hcard is ok, but a
>> recipe inside an hresume is not.
> 
> I might not be following you quite right here, I keep interpreting
> this sentence in opposite ways each time I read it. I'm going to
> answer both interpretations for completeness:
> 
> 1. I don't think there is any concept of 'allowed' vs. 'not'. There's
> obviously no specified relationship between Resum? and Recipe (at this
> time? cue every unemployed chef on the world wide web joining ?f-
> discuss? ha), but that doesn't mean a piece of content within that
> resume document couldn't be a recipe. A chef could include their
> favourite salad dressing recipe in their resum? as part of the
> description of some work experience. The example doesn't matter: There
> shouldn't be no restriction on describing one piece of structured
> data, independently of another, based on what the outer-most structure
> is.
> 
> In terms of ?f that have explicit function within another microformat,
> that is already documented as part of the specs. ADR is part of hCard,
> hAtom specifies authors must be hCard, hReview specifies that
> class="item vevent" means you're reviewing an event. And so on. Any
> unspecified combination should be treated as two discrete objects.
> 
> 2. On the flip side, if you mean that we should provide fuller
> specifications of what microformats do mean in combination, that's a
> different issue, but one that again there's limited demand for.
> Combinations (say, using hCal inside of hResume for experience) get
> worked out in response to use cases, either in the initial development
> of a spec or later, either way not pre-emptively. Using hCalendar for
> life-spans (in place of an hCard date-of-death field), was an example
> that came up a few years ago.
>
> People experiment with combinations in their own pages where it makes
> sense to them; no different to publishing with any other HTML element.
> Those experiments may influence brainstorming for specifying new
> patterns.
> 
> Like all new uses of microformats, ideas about uses of combined
> microformats should be documented on each microformat's *-
> brainstorming page.

i understand this as an attempt to let not get microformats too complicated.
to paraphrase you: "if there's a strong enough usecase add the element to
the microformat. otherwise there's no need for a rule either".
but in your response #1 you say that no combinations are forbidden. actually
i don't get your difficulties with peters proposal but rather have trouble
aligning your two answers :-)

the example of chefs and resumes and recipes is a good one. noone would ever
add the hrecipe vocab to hresume element set. but just besause the case may
be very rare doesn't make it useless or unimportant. it's, so to say, part
of the long tail of vocabulary usage. that's where general rules get really
helpful.

as a general rule i'd say that concise formats are advantageous and concise
rules how these formats can be combined are advantageous as well. trying to
avoid rules to keep things simple will convolut the vocabularies. adding to
many or to complicated rules would hinder comprehensibility.


On 25.06.09 10:02, "Toby A Inkster" <mail@tobyinkster.co.uk> wrote:
> 
> Related wiki page:
> http://microformats.org/wiki/compositing

as always: excellent, toby! i think this is a good road to go:
-  make clear where the problem lies,
-  add examples both for usefull cases and for no-no's
  (maybe also a rather comprehensible list of what combinations won't work).


in this spirit i would modify my proposal for hRecipe in the following way
(without going into great details here):

* keeping the core element set as focused to recipes as possible
* adding a "best practices" section on how to combine with other
vocabularies for popular additions to recipes like review, tagging, measure
* also warn of common pitfalls (e.g. direct to the corresponding section on
http://microformats.org/wiki/compositing)


cheers,
thomas



.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de




From loertsch.thomas at guj.de  Thu Jun 25 08:16:04 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Thu Jun 25 08:16:24 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
Message-ID: <C6696154.16BC%loertsch.thomas@guj.de>

On 24.06.09 16:23, "Brian Suda" <brian.suda@gmail.com> wrote:

> You should add this to the Wiki under the
> FAQs, then we can all iterate on the best answer.

i know that the wiki is regarded as the way to do things in this community
but i'd like to remind you that there is no mechanism in place to get
notification when a particular page is updated. anyway i do prefer mail for
discussions and wikis for results (temporary or permanent) but this absence
of a notification mechanism makes it particularily painful to keep up with
what's happening and tends to discourage participation to some extent (or
better: if you only want to participate to some extent).

cheers
thomas


.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de




From paul.m.wilkins at gmail.com  Thu Jun 25 15:50:16 2009
From: paul.m.wilkins at gmail.com (Paul Wilkins)
Date: Thu Jun 25 15:50:39 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <C6696154.16BC%loertsch.thomas@guj.de>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com> 
	<C6696154.16BC%loertsch.thomas@guj.de>
Message-ID: <be0a36470906251550g6ff0d2c4u5cc150409fa157b0@mail.gmail.com>

2009/6/26 Thomas Loertsch <loertsch.thomas@guj.de>:
> On 24.06.09 16:23, "Brian Suda" <brian.suda@gmail.com> wrote:
>
>> You should add this to the Wiki under the
>> FAQs, then we can all iterate on the best answer.
>
> i know that the wiki is regarded as the way to do things in this community
> but i'd like to remind you that there is no mechanism in place to get
> notification when a particular page is updated.

I beg to differ.

For individual pages, you can add particular pages to your watch list:
http://microformats.org/wiki/Special:Watchlist

For a more global view, you can use the recent changes page:
http://microformats.org/wiki/Special:RecentChanges

-- 
Paul Wilkins
From pmika at yahoo-inc.com  Thu Jun 25 16:33:36 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Thu Jun 25 16:34:13 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <C4333D95-4B47-4674-9CA7-37C8CBAA311C@ben-ward.co.uk>
References: <C667FC07.1686%loertsch.thomas@guj.de>	<21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<4A42D927.8080905@yahoo-inc.com>	<B56F2505-55A0-462A-A080-B9F245488E7B@ben-ward.co.uk>	<4A431368.8090506@yahoo-inc.com>
	<C4333D95-4B47-4674-9CA7-37C8CBAA311C@ben-ward.co.uk>
Message-ID: <4A440950.1010102@yahoo-inc.com>

Hi Ben,

I was thinking of something like Toby's page on compositioning which 
sets out possible, clearly OK and clearly suspicious combinations.

Cheers,
Peter

Ben Ward wrote:
> Hi Peter,
>
> On 24 Jun 2009, at 23:04, Peter Mika wrote:
>
>>> What I posit has happened is that at one point, answers.com marked 
>>> up the ?Years Active? part of that info box with dtstart and dtend.
>>
>> Yes, but let's assume they had the dtstart, i.e. a valid event and a 
>> card. Still, having an event named 'Kevin Bacon' is dubious.
>
> It's not a high quality object, I agree. But, it's valid. It describes 
> a timespan and that's a valid event.
>
>> However, they might have gotten the idea that it's ok to do this, 
>> because the two microformats share the fn property. So they could 
>> have thought, why repeat it twice?
>
> I don't agree, although we should acknowledge here that we're both 
> second guessing another developer's intent. I don't think the scenario 
> you describe is a concern, and we've never had any prior suggestion of 
> it occurring. With reference to this case:
>
>   * hCalendar does not have an `fn` property, no example here or 
> elsewhere would instruct someone to use `fn` in hCal.
>   * The mark-up here explicitly uses `summary` and `fn`. That "Kevin 
> Bacon" is an incomplete name for an event from a content quality 
> perspective is not in dispute, but the author explicitly made it the 
> summary of their event. They didn't add a second summary attribute 
> elsewhere in the content, expecting it to be amalgamated.
>
> I think it's most likely that the developer is just trying to describe 
> all the data they have available using the tools they have: There's an 
> hCard there and there's an event. Someone trying to parse his page 
> specifically could imply information from the hCard+hCalendar, and 
> that's cool, but at the core he's tried to describe his complex 
> content using the building blocks available.
>
> Either way, we can't be certain without consulting with them. I don't 
> think it's evidence of erroneous confusion.
>
>> I would suggest a page that describes precise what combinations of 
>> microformats are allowed, e.g. that an adr inside hcard is ok, but a 
>> recipe inside an hresume is not.
>
> I might not be following you quite right here, I keep interpreting 
> this sentence in opposite ways each time I read it. I'm going to 
> answer both interpretations for completeness:
>
> 1. I don't think there is any concept of 'allowed' vs. 'not'. There's 
> obviously no specified relationship between Resum? and Recipe (at this 
> time? cue every unemployed chef on the world wide web joining 
> ?f-discuss? ha), but that doesn't mean a piece of content within that 
> resume document couldn't be a recipe. A chef could include their 
> favourite salad dressing recipe in their resum? as part of the 
> description of some work experience. The example doesn't matter: There 
> shouldn't be no restriction on describing one piece of structured 
> data, independently of another, based on what the outer-most structure 
> is.
>
> In terms of ?f that have explicit function within another microformat, 
> that is already documented as part of the specs. ADR is part of hCard, 
> hAtom specifies authors must be hCard, hReview specifies that 
> class="item vevent" means you're reviewing an event. And so on. Any 
> unspecified combination should be treated as two discrete objects.
>
> 2. On the flip side, if you mean that we should provide fuller 
> specifications of what microformats do mean in combination, that's a 
> different issue, but one that again there's limited demand for. 
> Combinations (say, using hCal inside of hResume for experience) get 
> worked out in response to use cases, either in the initial development 
> of a spec or later, either way not pre-emptively. Using hCalendar for 
> life-spans (in place of an hCard date-of-death field), was an example 
> that came up a few years ago.
>
> People experiment with combinations in their own pages where it makes 
> sense to them; no different to publishing with any other HTML element. 
> Those experiments may influence brainstorming for specifying new 
> patterns.
>
> Like all new uses of microformats, ideas about uses of combined 
> microformats should be documented on each microformat's 
> *-brainstorming page.
>
> Thanks,
>
> Ben
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From singpolyma at singpolyma.net  Thu Jun 25 16:40:13 2009
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Thu Jun 25 16:40:20 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <C6696154.16BC%loertsch.thomas@guj.de>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<C6696154.16BC%loertsch.thomas@guj.de>
Message-ID: <20090625234013.GC3501@singpolyma-mini>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Somebody claiming to be Thomas Loertsch wrote:
> On 24.06.09 16:23, "Brian Suda" <brian.suda@gmail.com> wrote:
> 
> > You should add this to the Wiki under the
> > FAQs, then we can all iterate on the best answer.
> 
> i know that the wiki is regarded as the way to do things in this community
> but i'd like to remind you that there is no mechanism in place to get
> notification when a particular page is updated. anyway i do prefer mail for
> discussions and wikis for results (temporary or permanent) but this absence
> of a notification mechanism makes it particularily painful to keep up with
> what's happening and tends to discourage participation to some extent (or
> better: if you only want to participate to some extent).

Editing the wiki both updates IRC and there is an RSS feed at
<http://microformats.org/wiki/index.php?title=Special:RecentChanges&feed=rss>

- -- 
Stephen Paul Weber, @singpolyma
Please see <http://singpolyma.net> for how I prefer to be contacted.
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKRArdAAoJENEcKRHOUZzexcAQALUC7Lk83876U+fOl3w7rrCM
17jR6fwCBEvsSCbrb0H9A66HfdBBNwhzbdSk+cbgk2oyuy9teI+SlV6jTwQCCoxe
EGVvRPpQ4sMjXNjQ8iwtiI06S7//wM3Maimo6SdqVDu3EiQhnVSd/pevjS1h2YQE
DSpjqyDtrPsr4nOSVttmO6qi6d8dA8WT8ZUCl4z7773erdoU4qARo7clvTJ3li6X
KoTc3orLlazCh1XKG/7Pzc0XCFcP8QDsCOjNAWKYyv8nNeHZo6R2XISOHb67jOXF
deONlZa62VBm+SORS1HnwCMZxHDY79ikhPkxKPUQIrs+Gby5U8iP2DmuW0oDXXA2
oh+sP/dr3iZd7Z+UuRJOeL7jkodmuL/ZhLGaR3+aZRGT0HIpDRFfnO9akQe8f1jJ
KpKrVCelKlrDcFoE3Jj/bG7YKOMrADuIeGAMuQgpV2W1ueSMaggOn+oLnmdWvoiY
Rv9biNeGWRofb4fQ7ipWvhIanIHEqjAsuTJPTIv7KqP8BSaBN/kfslefztVuC932
TNhDdesKc9Q2X5Avk69rOR+5d0mMqB9ehlNBM1OTDKE9T14LBD13ssIJJLyjXAi7
5QIgposT9YcJ9r/lPlSXYJkITEkd5ZQAuzxiVbM4Xj2bSnrNo4WyOSG19TOmOn4V
dm5YcjmcrhA2Hd/eSAlw
=S23g
-----END PGP SIGNATURE-----
From pmika at yahoo-inc.com  Fri Jun 26 14:47:44 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Fri Jun 26 14:48:42 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <20090625234013.GC3501@singpolyma-mini>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini>
Message-ID: <4A454200.6010409@yahoo-inc.com>

Today I've seen the second case in point:

<ul class="ingredient hcard">

It seems like that the wiki at [1] actively encourages this.... but I 
fail to see why an ingredient would be either a person or an organization?

Note: from our perspective this is the same as having no markup at all: 
we can not really say whether the page is about a recipe or a person, 
and what's the relationship of the two.

Thanks,
Peter

[1] http://microformats.org/wiki/hrecipe
From pmika at yahoo-inc.com  Fri Jun 26 14:49:49 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Fri Jun 26 14:50:31 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A454200.6010409@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini>
	<4A454200.6010409@yahoo-inc.com>
Message-ID: <4A45427D.3060506@yahoo-inc.com>

Stronger, there is an actual example on the wiki that shows this... but 
this will be necessarily an ill-formed hcard given that there is no fn 
or n here:

<p class="ingredient hcard">
        <span class="value">500</span>
        <span class="type">gramme</span>
        potatoes, hard cooking.
    </p>

Thanks,
Peter

Peter Mika wrote:
> Today I've seen the second case in point:
>
> <ul class="ingredient hcard">
>
> It seems like that the wiki at [1] actively encourages this.... but I 
> fail to see why an ingredient would be either a person or an 
> organization?
>
> Note: from our perspective this is the same as having no markup at 
> all: we can not really say whether the page is about a recipe or a 
> person, and what's the relationship of the two.
>
> Thanks,
> Peter
>
> [1] http://microformats.org/wiki/hrecipe
>

From singpolyma at singpolyma.net  Fri Jun 26 15:12:15 2009
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Fri Jun 26 15:12:21 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A45427D.3060506@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini>
	<4A454200.6010409@yahoo-inc.com> <4A45427D.3060506@yahoo-inc.com>
Message-ID: <20090626221215.GB7949@singpolyma-mini>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Somebody claiming to be Peter Mika wrote:
> Stronger, there is an actual example on the wiki that shows this... but  
> this will be necessarily an ill-formed hcard given that there is no fn  
> or n here:
>
> <p class="ingredient hcard">
>        <span class="value">500</span>
>        <span class="type">gramme</span>
>        potatoes, hard cooking.
>    </p>

Also, because the root class of hCard is *not* "hcard"

- -- 
Stephen Paul Weber, @singpolyma
Please see <http://singpolyma.net> for how I prefer to be contacted.
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKRUe+AAoJENEcKRHOUZzeyEwQAJEqC+U8L7EM2+Lye4rCrbpy
A3jJZO+HbSEr0j9SWRrk8bBkclOd1IvbYe895t544PJr1/4z6WV372PGvdaiUm79
ewblyOK2WnbXjwHxvLeFE1v0hyyda0wnwpUiXVX9+PQ3KcXfUYshNtgs/07y6DxY
InzBv+MLu9GsmiKc9ji98qeksXtex+0udmOASHWfBbCvtjoBh9ofosyJP4pYlWd8
nGpVjWZflfhozX4+Jig2BRc+hn8+e1KPCj3s0+NOm4ZqkA3ps+rB0ldPH/QOGZ50
OMF6om9AeL7BImdkYIjGTCy8ey0PZSqFynEhWJHeQ5sWPjGE0X6EgBQXwwk2UOvF
5hniDROH7kL8i9WslVI0Ngm1oyRvHjuMOBWejNlQWZrI/dEaCdvRFRRlIZ+MssTj
fSM9ua/OLG3y5vpJJetF92lPpO8eajEzYEzYY3v/jPMmUyNgG8rIBytCvxruiGU2
hVSeBdEnVNwvzt1AXzlzlETMTGvp/N/HyaFBElqGc0bvRPd4706rAcsBFJLSCbpY
wio38rRwkBpLjNu6x5m+wCt12XN/VaxtdMNpuEa/EhujYM9Mj91XdP5L7Lr4FJdj
pgYqf2jb+Sk88CdaqK85gwot06byTUc8HYm5w0oodj3WyqYy3MZRVA5Z4YG6O5R1
dFOCk6zjQiQi+gA3aIH4
=0O2T
-----END PGP SIGNATURE-----
From pmika at yahoo-inc.com  Fri Jun 26 15:57:46 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Fri Jun 26 15:58:16 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <20090626221215.GB7949@singpolyma-mini>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>	<4A454200.6010409@yahoo-inc.com>
	<4A45427D.3060506@yahoo-inc.com>
	<20090626221215.GB7949@singpolyma-mini>
Message-ID: <4A45526A.8070804@yahoo-inc.com>

Not to mention that ;) Anyhow, my point is that this kind of 
compositioning seems to pop up, possibly because a strong emphasis on 
reuse... Nothing wrong with reuse of course, but it would be nice to set 
out the anti-patterns where reuse goes too far.

Cheers,
Peter

Stephen Paul Weber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Somebody claiming to be Peter Mika wrote:
>   
>> Stronger, there is an actual example on the wiki that shows this... but  
>> this will be necessarily an ill-formed hcard given that there is no fn  
>> or n here:
>>
>> <p class="ingredient hcard">
>>        <span class="value">500</span>
>>        <span class="type">gramme</span>
>>        potatoes, hard cooking.
>>    </p>
>>     
>
> Also, because the root class of hCard is *not* "hcard"
>
> - -- 
> Stephen Paul Weber, @singpolyma
> Please see <http://singpolyma.net> for how I prefer to be contacted.
> edition right joseph
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQIcBAEBCAAGBQJKRUe+AAoJENEcKRHOUZzeyEwQAJEqC+U8L7EM2+Lye4rCrbpy
> A3jJZO+HbSEr0j9SWRrk8bBkclOd1IvbYe895t544PJr1/4z6WV372PGvdaiUm79
> ewblyOK2WnbXjwHxvLeFE1v0hyyda0wnwpUiXVX9+PQ3KcXfUYshNtgs/07y6DxY
> InzBv+MLu9GsmiKc9ji98qeksXtex+0udmOASHWfBbCvtjoBh9ofosyJP4pYlWd8
> nGpVjWZflfhozX4+Jig2BRc+hn8+e1KPCj3s0+NOm4ZqkA3ps+rB0ldPH/QOGZ50
> OMF6om9AeL7BImdkYIjGTCy8ey0PZSqFynEhWJHeQ5sWPjGE0X6EgBQXwwk2UOvF
> 5hniDROH7kL8i9WslVI0Ngm1oyRvHjuMOBWejNlQWZrI/dEaCdvRFRRlIZ+MssTj
> fSM9ua/OLG3y5vpJJetF92lPpO8eajEzYEzYY3v/jPMmUyNgG8rIBytCvxruiGU2
> hVSeBdEnVNwvzt1AXzlzlETMTGvp/N/HyaFBElqGc0bvRPd4706rAcsBFJLSCbpY
> wio38rRwkBpLjNu6x5m+wCt12XN/VaxtdMNpuEa/EhujYM9Mj91XdP5L7Lr4FJdj
> pgYqf2jb+Sk88CdaqK85gwot06byTUc8HYm5w0oodj3WyqYy3MZRVA5Z4YG6O5R1
> dFOCk6zjQiQi+gA3aIH4
> =0O2T
> -----END PGP SIGNATURE-----
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>   

From brian.suda at gmail.com  Fri Jun 26 16:12:52 2009
From: brian.suda at gmail.com (Brian Suda)
Date: Fri Jun 26 16:12:55 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A454200.6010409@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini>
	<4A454200.6010409@yahoo-inc.com>
Message-ID: <21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>

On Fri, Jun 26, 2009 at 9:47 PM, Peter Mika<pmika@yahoo-inc.com> wrote:
> Today I've seen the second case in point:
>
> <ul class="ingredient hcard">
>
> It seems like that the wiki at [1] actively encourages this.... but I fail
> to see why an ingredient would be either a person or an organization?

--- to me, this just says any and all class values inside this UL
should be considered an hCard and/or ingredient. You could just as
easily do this:

<body class="ingredient hcard">

Then anything on that page with class values which correspond to
either of those vocabularies should be considered.

> Note: from our perspective this is the same as having no markup at all: we can not really say whether the page is about a recipe or a person, and what's the relationship of the two.

It is better than having no mark-up at all because you can say that
some data inside this UL is to be considered an hCard and some data
should be considered an ingredient. Each parser will need to look for
the class values it understands. An hCard parser will look for
class="fn" whereas an hRecipe parser will look for different values,
some might overlap some might not.

The only time you need to understand the relationship between the two
is when it is explicit in the format's design. hResume has things like
class="education vevent" those to are linked because the spec says so,
class="ingredient hcard" are not explicitly mentioned in the spec, it
would be no different if you had class="ingredient hcard important
error-message highlight aside" or any other class value. hRecipe or
hCard does not need to understand the other class values which are for
styling or for microformats or for other formats in the future.

Does that help clear-up any confusion?

-brian

-- 
brian suda
http://suda.co.uk
From pmika at yahoo-inc.com  Fri Jun 26 16:40:25 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Fri Jun 26 16:41:33 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>	<4A454200.6010409@yahoo-inc.com>
	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>
Message-ID: <4A455C69.6030302@yahoo-inc.com>

Hmm... what could possibly be the purpose of an hCard inside an 
ingredient? I discard cannibalism at this point.

Cheers,
Peter


Brian Suda wrote:
> On Fri, Jun 26, 2009 at 9:47 PM, Peter Mika<pmika@yahoo-inc.com> wrote:
>   
>> Today I've seen the second case in point:
>>
>> <ul class="ingredient hcard">
>>
>> It seems like that the wiki at [1] actively encourages this.... but I fail
>> to see why an ingredient would be either a person or an organization?
>>     
>
> --- to me, this just says any and all class values inside this UL
> should be considered an hCard and/or ingredient. You could just as
> easily do this:
>
> <body class="ingredient hcard">
>
> Then anything on that page with class values which correspond to
> either of those vocabularies should be considered.
>
>   
>> Note: from our perspective this is the same as having no markup at all: we can not really say whether the page is about a recipe or a person, and what's the relationship of the two.
>>     
>
> It is better than having no mark-up at all because you can say that
> some data inside this UL is to be considered an hCard and some data
> should be considered an ingredient. Each parser will need to look for
> the class values it understands. An hCard parser will look for
> class="fn" whereas an hRecipe parser will look for different values,
> some might overlap some might not.
>
> The only time you need to understand the relationship between the two
> is when it is explicit in the format's design. hResume has things like
> class="education vevent" those to are linked because the spec says so,
> class="ingredient hcard" are not explicitly mentioned in the spec, it
> would be no different if you had class="ingredient hcard important
> error-message highlight aside" or any other class value. hRecipe or
> hCard does not need to understand the other class values which are for
> styling or for microformats or for other formats in the future.
>
> Does that help clear-up any confusion?
>
> -brian
>
>   

From brian.suda at gmail.com  Fri Jun 26 17:24:10 2009
From: brian.suda at gmail.com (Brian Suda)
Date: Fri Jun 26 17:24:13 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A455C69.6030302@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini>
	<4A454200.6010409@yahoo-inc.com>
	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>
	<4A455C69.6030302@yahoo-inc.com>
Message-ID: <21e770780906261724s3d4284e2t1eedffa437b89ee@mail.gmail.com>

On Fri, Jun 26, 2009 at 11:40 PM, Peter Mika<pmika@yahoo-inc.com> wrote:
> Hmm... what could possibly be the purpose of an hCard inside an ingredient?
> I discard cannibalism at this point.

--- i think people are confusing the notion that the two must be
connected. It is just semantic mark-up so for instance i could have:

<p class="vcard ingredient">You will need to add <span class="unit">3
table spoons</span> of <span class="value">specially ground
spice</span> which can be picked up at <span class="fn org">XYZ
specialty shop</span></p>

Now, an hCard aware parser will find the shop, an hRecipe parser will
find the ingredient. The fact that both are on the <p> is irrelevant
in this situation.

This goes for any mixing of vocabularies. Microformats do not force
people to mark-up their html in any special way, so there will be
overlap which have no meaning to each other.

-brian

-- 
brian suda
http://suda.co.uk
From pmika at yahoo-inc.com  Fri Jun 26 21:33:33 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Fri Jun 26 21:34:40 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <21e770780906261724s3d4284e2t1eedffa437b89ee@mail.gmail.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>	<4A454200.6010409@yahoo-inc.com>	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>	<4A455C69.6030302@yahoo-inc.com>
	<21e770780906261724s3d4284e2t1eedffa437b89ee@mail.gmail.com>
Message-ID: <4A45A11D.1000202@yahoo-inc.com>

Hi Brian,

So even if we all agree to all this, minimally two changes needed to the 
example on the wiki:

-- hcard should be vcard
-- all required properties of the hcard should be present OR hcard 
should be removed

Would you edit it?

Thanks,
Peter

Brian Suda wrote:
> On Fri, Jun 26, 2009 at 11:40 PM, Peter Mika<pmika@yahoo-inc.com> wrote:
>   
>> Hmm... what could possibly be the purpose of an hCard inside an ingredient?
>> I discard cannibalism at this point.
>>     
>
> --- i think people are confusing the notion that the two must be
> connected. It is just semantic mark-up so for instance i could have:
>
> <p class="vcard ingredient">You will need to add <span class="unit">3
> table spoons</span> of <span class="value">specially ground
> spice</span> which can be picked up at <span class="fn org">XYZ
> specialty shop</span></p>
>
> Now, an hCard aware parser will find the shop, an hRecipe parser will
> find the ingredient. The fact that both are on the <p> is irrelevant
> in this situation.
>
> This goes for any mixing of vocabularies. Microformats do not force
> people to mark-up their html in any special way, so there will be
> overlap which have no meaning to each other.
>
> -brian
>
>   

From lists at ben-ward.co.uk  Sat Jun 27 01:10:23 2009
From: lists at ben-ward.co.uk (Ben Ward)
Date: Sat Jun 27 01:16:09 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A45A11D.1000202@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>	<4A454200.6010409@yahoo-inc.com>	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>	<4A455C69.6030302@yahoo-inc.com>
	<21e770780906261724s3d4284e2t1eedffa437b89ee@mail.gmail.com>
	<4A45A11D.1000202@yahoo-inc.com>
Message-ID: <B6F00980-27ED-4D62-A44A-112777E6EA07@ben-ward.co.uk>

On 26 Jun 2009, at 21:33, Peter Mika wrote:

> So even if we all agree to all this, minimally two changes needed to  
> the example on the wiki:
>
> -- hcard should be vcard
> -- all required properties of the hcard should be present OR hcard  
> should be removed
>
> Would you edit it?

Noting that Tantek has edited the hCard class out on the wiki. I think  
we should assume that this was an error in the draft (note that  
hRecipe is draft).

**I think** I understand what has happened here. Thomas, if this  
assumption isn't correct I apologise. However, I hope this explanation  
is valuable anyway in the context of this ?combining vocabularies?  
discussion, so please consider the following neutrally:

This discussion started from a mistaken understanding about combining  
vocabularies in microformats ? e.g. combining hcard with hreview to  
reuse terms like `fn`.

"combining" is a concept applied from a formal vocabulary context,  
where you would import two vocabulary namespaces into different  
prefixes to reuse terms. (e.g. importing dublin core and atom  
namespaces and using them in combination as part of some larger  
document mark-up). In XML, reusing vocabulary terms requires a formal  
reference, because when you use `dc:title` you're using _the same_  
`dc:title` as in every other use of Dublin Core.

In XML, this combining of vocabularies is a publishing-time operation.

In microformats, that concept doesn't exist. The sharing of terms  
between vocabularies is a simpler **design-time** decision. Where  
terms a new format has fields that share the same use with a term  
defined from a previous microformat, the term is re-used in the new  
vocabulary.

So, in hRecipe, `fn`, `type`, `value` and `photo` are not ?imported?  
from hcard, they are simply properties with the same name, because  
they are used the same way.

The hRecipe spec currently emphasises where terms have been reused  
from hCard (this is good, it clearly documents the design decisions of  
the draft). And, in the case of ingredient, it documents that `type`  
and `value` are reused from hcard (that's correct).

I think the example was using class="ingredient hcard" with the intent  
of explicitly referencing the hCard vocabulary for `type` and `value`.

However, that isn't necessary. `type` and `value`, are first-class  
members the hRecipe draft vocabulary, and the context of their use is  
indicated by the root class name `hrecipe`.

This is why I explain microformats as objects:

   `class="hrecipe"` means "this is a recipe object" not "import the  
recipe vocabulary".

I suspect this is the muddle that happened with the example, but even  
if not, I hope this explanation makes things a little clearer for  
those who switch between the different vocabulary models on the web.

Cheers,

Ben
From danbri at danbri.org  Sat Jun 27 02:29:39 2009
From: danbri at danbri.org (Dan Brickley)
Date: Sat Jun 27 02:29:47 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A454200.6010409@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>
	<4A454200.6010409@yahoo-inc.com>
Message-ID: <4A45E683.5000005@danbri.org>

On 26/6/09 23:47, Peter Mika wrote:
> Today I've seen the second case in point:
>
> <ul class="ingredient hcard">
>
> It seems like that the wiki at [1] actively encourages this.... but I
> fail to see why an ingredient would be either a person or an organization?

http://www.associatedcontent.com/article/283953/cannibal_recipes.html
http://uncyclopedia.wikia.com/wiki/Cannibalism
http://www.amazon.ca/Soup-Nuts-Cannibal-Lovers-Cookbook/dp/0684869845

sorry etc.,

Dan

> [1] http://microformats.org/wiki/hrecipe

From danbri at danbri.org  Sat Jun 27 03:20:42 2009
From: danbri at danbri.org (Dan Brickley)
Date: Sat Jun 27 03:25:51 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A455C69.6030302@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>	<4A454200.6010409@yahoo-inc.com>	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>
	<4A455C69.6030302@yahoo-inc.com>
Message-ID: <4A45F27A.7000308@danbri.org>

On 27/6/09 01:40, Peter Mika wrote:
> Hmm... what could possibly be the purpose of an hCard inside an
> ingredient? I discard cannibalism at this point.

Jokes aside - how about contact details for suppliers and manufacturers 
of rare or special ingredients? either for health reasons or for 
super-fancy cookery?

Dan


From pmika at yahoo-inc.com  Sun Jun 28 14:38:11 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Sun Jun 28 14:39:20 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A45F27A.7000308@danbri.org>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>	<4A454200.6010409@yahoo-inc.com>	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>	<4A455C69.6030302@yahoo-inc.com>
	<4A45F27A.7000308@danbri.org>
Message-ID: <4A47E2C3.2000507@yahoo-inc.com>

Hmmm.... what happened to designing for the 80/20 case? So why don't we 
have an ingredient class in FOAF?

Peter

Dan Brickley wrote:
> On 27/6/09 01:40, Peter Mika wrote:
>> Hmm... what could possibly be the purpose of an hCard inside an
>> ingredient? I discard cannibalism at this point.
>
> Jokes aside - how about contact details for suppliers and 
> manufacturers of rare or special ingredients? either for health 
> reasons or for super-fancy cookery?
>
> Dan
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From pmika at yahoo-inc.com  Sun Jun 28 14:44:46 2009
From: pmika at yahoo-inc.com (Peter Mika)
Date: Sun Jun 28 14:45:18 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <B6F00980-27ED-4D62-A44A-112777E6EA07@ben-ward.co.uk>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>	<C6696154.16BC%loertsch.thomas@guj.de>	<20090625234013.GC3501@singpolyma-mini>	<4A454200.6010409@yahoo-inc.com>	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>	<4A455C69.6030302@yahoo-inc.com>	<21e770780906261724s3d4284e2t1eedffa437b89ee@mail.gmail.com>	<4A45A11D.1000202@yahoo-inc.com>
	<B6F00980-27ED-4D62-A44A-112777E6EA07@ben-ward.co.uk>
Message-ID: <4A47E44E.8010302@yahoo-inc.com>

I agree with your analysis. Indeed over-emphasizing this reuse from 
hcard gives the impression that somehow the ingredient has to be an 
hcard. I would also add that it would make it easier for people to use 
the hrecipe format if the references to hcard and hatom would be removed 
or at least deemphasized, because it gives the reader the impression 
that one has to read or understand the hcard/hatom spec before starting 
with hrecipe, i.e. that it's not a standalone spec. Based on what you 
say, it should be, i.e. it should make sense without reference to 
hcard/hatom.

and thanks to Tantek for the editing....

Cheers,
Peter

Ben Ward wrote:
> On 26 Jun 2009, at 21:33, Peter Mika wrote:
>
>> So even if we all agree to all this, minimally two changes needed to 
>> the example on the wiki:
>>
>> -- hcard should be vcard
>> -- all required properties of the hcard should be present OR hcard 
>> should be removed
>>
>> Would you edit it?
>
> Noting that Tantek has edited the hCard class out on the wiki. I think 
> we should assume that this was an error in the draft (note that 
> hRecipe is draft).
>
> **I think** I understand what has happened here. Thomas, if this 
> assumption isn't correct I apologise. However, I hope this explanation 
> is valuable anyway in the context of this ?combining vocabularies? 
> discussion, so please consider the following neutrally:
>
> This discussion started from a mistaken understanding about combining 
> vocabularies in microformats ? e.g. combining hcard with hreview to 
> reuse terms like `fn`.
>
> "combining" is a concept applied from a formal vocabulary context, 
> where you would import two vocabulary namespaces into different 
> prefixes to reuse terms. (e.g. importing dublin core and atom 
> namespaces and using them in combination as part of some larger 
> document mark-up). In XML, reusing vocabulary terms requires a formal 
> reference, because when you use `dc:title` you're using _the same_ 
> `dc:title` as in every other use of Dublin Core.
>
> In XML, this combining of vocabularies is a publishing-time operation.
>
> In microformats, that concept doesn't exist. The sharing of terms 
> between vocabularies is a simpler **design-time** decision. Where 
> terms a new format has fields that share the same use with a term 
> defined from a previous microformat, the term is re-used in the new 
> vocabulary.
>
> So, in hRecipe, `fn`, `type`, `value` and `photo` are not ?imported? 
> from hcard, they are simply properties with the same name, because 
> they are used the same way.
>
> The hRecipe spec currently emphasises where terms have been reused 
> from hCard (this is good, it clearly documents the design decisions of 
> the draft). And, in the case of ingredient, it documents that `type` 
> and `value` are reused from hcard (that's correct).
>
> I think the example was using class="ingredient hcard" with the intent 
> of explicitly referencing the hCard vocabulary for `type` and `value`.
>
> However, that isn't necessary. `type` and `value`, are first-class 
> members the hRecipe draft vocabulary, and the context of their use is 
> indicated by the root class name `hrecipe`.
>
> This is why I explain microformats as objects:
>
>   `class="hrecipe"` means "this is a recipe object" not "import the 
> recipe vocabulary".
>
> I suspect this is the muddle that happened with the example, but even 
> if not, I hope this explanation makes things a little clearer for 
> those who switch between the different vocabulary models on the web.
>
> Cheers,
>
> Ben
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From tom at tommorris.org  Sun Jun 28 15:11:07 2009
From: tom at tommorris.org (Tom Morris)
Date: Sun Jun 28 15:11:12 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A47E2C3.2000507@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini>
	<4A454200.6010409@yahoo-inc.com>
	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>
	<4A455C69.6030302@yahoo-inc.com> <4A45F27A.7000308@danbri.org>
	<4A47E2C3.2000507@yahoo-inc.com>
Message-ID: <d375f00f0906281511q2148d2a1v54c824b2dc0683f7@mail.gmail.com>

On Sun, Jun 28, 2009 at 22:38, Peter Mika<pmika@yahoo-inc.com> wrote:
> Hmmm.... what happened to designing for the 80/20 case? So why don't we have
> an ingredient class in FOAF?
>

Well, I'd use 'food ingredient' from OpenCyc:
http://sw.opencyc.org/concept/Mx4rvVjaKpwpEbGdrcN5Y29ycA

And foaf:maker to point to a foaf:Agent, foaf:Person,
foaf:Organisation or vCard.

Or maybe the product manufacturer predicate from OpenCyc:
http://sw.opencyc.org/concept/Mx4rvVkAz5wpEbGdrcN5Y29ycA

What might be more useful is 'available from' - for instance, to say
that you should be able to get some exotic foodstuff from a particular
market or a supermarket chain. I mean, a particular ingredient may be
stocked by, say, Whole Foods, but you needn't pick out a specific
store.

-- 
Tom Morris
http://tommorris.org/
From jmyers at visi.com  Mon Jun 29 09:23:17 2009
From: jmyers at visi.com (Jay Myers)
Date: Mon Jun 29 09:23:20 2009
Subject: [uf-discuss] Revised hListing schema enhancements posted
In-Reply-To: <d375f00f0906281511q2148d2a1v54c824b2dc0683f7@mail.gmail.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com>
	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini>
	<4A454200.6010409@yahoo-inc.com>
	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com>
	<4A455C69.6030302@yahoo-inc.com> <4A45F27A.7000308@danbri.org>
	<4A47E2C3.2000507@yahoo-inc.com>
	<d375f00f0906281511q2148d2a1v54c824b2dc0683f7@mail.gmail.com>
Message-ID: <web-15208256@mailback2.g2host.com>

All,

I have posted a revised version of proposed schema 
enhancements on the hListing brainstorming page [1], which 
include three new attributes, links to analysis of the new 
proposed attributes, and a couple of modifications to 
existing attributes. Please post your comments to the 
brainstorming page.

[1] http://microformats.org/wiki/hlisting-brainstorming

Thanks,

Jay Myers
mobile: +1 612 296 5836
blog: http://jay.beweep.com
twitter: @jaymyers
skype: jaymmyers
From tantek at cs.stanford.edu  Mon Jun 29 15:58:18 2009
From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=)
Date: Mon Jun 29 15:58:41 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A47E2C3.2000507@yahoo-inc.com>
References: <21e770780906240723pa1560b3n2dd9ddcc39c5dc48@mail.gmail.com> 
	<C6696154.16BC%loertsch.thomas@guj.de>
	<20090625234013.GC3501@singpolyma-mini> 
	<4A454200.6010409@yahoo-inc.com>
	<21e770780906261612l40e2ba73j63502d8a5b290a7b@mail.gmail.com> 
	<4A455C69.6030302@yahoo-inc.com> <4A45F27A.7000308@danbri.org> 
	<4A47E2C3.2000507@yahoo-inc.com>
Message-ID: <60cb038a0906291558r55f73e54o4c5905cc5c382639@mail.gmail.com>

On Sun, Jun 28, 2009 at 2:38 PM, Peter Mika<pmika@yahoo-inc.com> wrote:
> Hmmm.... what happened to designing for the 80/20 case?

Indeed, that and other issues (see below)


> Dan Brickley wrote:
>>
>> On 27/6/09 01:40, Peter Mika wrote:
>>>
>>> Hmm... what could possibly be the purpose of an hCard inside an
>>> ingredient?
>>
>> how about contact details for suppliers and manufacturers of
>> rare or special ingredients? either for health reasons or for super-fancy
>> cookery?
>>
>> Dan

While it seems reasonable that someone might theoretically publish a
recipe which explicitly mentions a specific supplier or manufacturer
(for whatever reason), as provided above, this is a theoretical
example, and thus would benefit from citing one or more real world
examples per:

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

Please also feel free to document the theoretical example on the
hRecipe brainstorming page, and note explicitly that it is a
*theoretical example* so that it can be considered accordingly:

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


Tom Morris wrote:

>Well, I'd use ... [previous formats/vocabularies]

Please add previous formats or vocabularies that relate to a type of
content to the respective *-formats page, e.g. in this instance,
http://microformats.org/wiki/recipe-formats per

http://microformats.org/wiki/put-it-on-the-wiki#previous_formats_and_vocabularies


Thanks,

Tantek

-- 
http://tantek.com/
From lists at ben-ward.co.uk  Mon Jun 29 17:03:59 2009
From: lists at ben-ward.co.uk (Ben Ward)
Date: Mon Jun 29 17:04:03 2009
Subject: [uf-discuss] Re: [uf-new] Using external Data with Flash
In-Reply-To: <A41F2765-BBC9-4681-A2B4-88C23BE45B42@aol.com>
References: <A41F2765-BBC9-4681-A2B4-88C23BE45B42@aol.com>
Message-ID: <86946199-6234-4A3C-B3B5-B89D349585BF@ben-ward.co.uk>

Hi Konrad,

Thanks for getting interested in microformats!

First up, query and discussion threads should be directed to the microformats-discuss@microformats.org 
  mailing list, please; [microformats-new] is focused on the actual  
development of new formats, so your question won't necessarily have  
reached the right audience here. Thanks!

I'm crossposting this over to microformats-discuss for you, so any  
future replies should please drop ?f-new from the reply header. Thanks!

On 27 Jun 2009, at 17:08, Konrad R?pke wrote:

> I want to program a possibility to access an external file online on  
> a server with a Flashfile. Would that be possible also with an  
> hCalender file? Thanks for any help or recommendations.

Could you clarify a little what you want to do?

If you're trying to parse hCalendar within a Flash application, you  
might be able to reuse some of the JavaScript code from the Operator  
parser to create JavaScript objects. See http://microformats.org/wiki/operator

Cheers,

Ben
From loertsch.thomas at guj.de  Tue Jun 30 03:43:22 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Tue Jun 30 03:43:36 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <4A47E44E.8010302@yahoo-inc.com>
Message-ID: <C66FB8EA.1758%loertsch.thomas@guj.de>

Ah, my first megathread... sorry for the late response but I  was away over
the weekend. Peter, thanks for finding the bad in the hRecipe example on the
wiki! Ben, thanks for your very accurate analysis! Tantek, thanks for
updating the wiki!

On 28.06.09 23:44, "Peter Mika" <pmika@yahoo-inc.com> wrote:

> I agree with your analysis. Indeed over-emphasizing this reuse from
> hcard gives the impression that somehow the ingredient has to be an
> hcard. I would also add that it would make it easier for people to use
> the hrecipe format if the references to hcard and hatom would be removed
> or at least deemphasized,

You're right. I removed the references from the schema overview. That should
help quite a lot already.

> because it gives the reader the impression
> that one has to read or understand the hcard/hatom spec before starting
> with hrecipe, i.e. that it's not a standalone spec. Based on what you
> say, it should be, i.e. it should make sense without reference to
> hcard/hatom.

There's a lot of "this element must follow the conventions outlined in that
microformat" talk. When editing hRecipe I copied a lot from other formats
and this to me seemed the way they all do it - which indeed fostered my
misinterpretation that I'm actually reusing elements at run-time.

I'll try to copy (more of) the referenced conventions inline and make the
page more self-contained. But that isn't always as easy as it sounds: e.g.
"author" is reused from hAtom which itself states that "an Entry Author
element MUST be encoded in an hCard", which - if I got it right - leads to
the following construct:

    <div class="hrecipe">
        <p class="author vcard fn">Hans Wurst</p>

That's not exactly self-containing and standalone. But searchmonkey would
know how to parse it, right?


> Ben Ward wrote:
>> On 26 Jun 2009, at 21:33, Peter Mika wrote:
>> 
>> Noting that Tantek has edited the hCard class out on the wiki. I think
>> we should assume that this was an error in the draft (note that
>> hRecipe is draft).

Yes, it was indeed - my bad! I'll try to update a few more details of the
example. I welcome very much any scrutiny of the draft especially with
respect to it's conformance to the technical details of microformats!

>> **I think** I understand what has happened here. Thomas, if this
>> assumption isn't correct I apologise.

You are correct! Thanks again for the very helpful clarification! Although,
as I examplified above with the "author" element, things seem to be a little
more complicated in practice. Still working on it...

Cheers,
Thomas






>> However, I hope this explanation
>> is valuable anyway in the context of this ?combining vocabularies?
>> discussion, so please consider the following neutrally:
>> 
>> This discussion started from a mistaken understanding about combining
>> vocabularies in microformats ? e.g. combining hcard with hreview to
>> reuse terms like `fn`.
>> 
>> "combining" is a concept applied from a formal vocabulary context,
>> where you would import two vocabulary namespaces into different
>> prefixes to reuse terms. (e.g. importing dublin core and atom
>> namespaces and using them in combination as part of some larger
>> document mark-up). In XML, reusing vocabulary terms requires a formal
>> reference, because when you use `dc:title` you're using _the same_
>> `dc:title` as in every other use of Dublin Core.
>> 
>> In XML, this combining of vocabularies is a publishing-time operation.
>> 
>> In microformats, that concept doesn't exist. The sharing of terms
>> between vocabularies is a simpler **design-time** decision. Where
>> terms a new format has fields that share the same use with a term
>> defined from a previous microformat, the term is re-used in the new
>> vocabulary.
>> 
>> So, in hRecipe, `fn`, `type`, `value` and `photo` are not ?imported?
>> from hcard, they are simply properties with the same name, because
>> they are used the same way.
>> 
>> The hRecipe spec currently emphasises where terms have been reused
>> from hCard (this is good, it clearly documents the design decisions of
>> the draft). And, in the case of ingredient, it documents that `type`
>> and `value` are reused from hcard (that's correct).
>> 
>> I think the example was using class="ingredient hcard" with the intent
>> of explicitly referencing the hCard vocabulary for `type` and `value`.
>> 
>> However, that isn't necessary. `type` and `value`, are first-class
>> members the hRecipe draft vocabulary, and the context of their use is
>> indicated by the root class name `hrecipe`.
>> 
>> This is why I explain microformats as objects:
>> 
>>   `class="hrecipe"` means "this is a recipe object" not "import the
>> recipe vocabulary".
>> 
>> I suspect this is the muddle that happened with the example, but even
>> if not, I hope this explanation makes things a little clearer for
>> those who switch between the different vocabulary models on the web.


.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de




From loertsch.thomas at guj.de  Tue Jun 30 04:18:22 2009
From: loertsch.thomas at guj.de (Thomas Loertsch)
Date: Tue Jun 30 04:18:37 2009
Subject: [uf-discuss] mixing vocabularies
In-Reply-To: <20090625234013.GC3501@singpolyma-mini>
Message-ID: <C66FC11E.175A%loertsch.thomas@guj.de>

On 26.06.09 01:40, "Stephen Paul Weber" <singpolyma@singpolyma.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Somebody claiming to be Thomas Loertsch wrote:
>> On 24.06.09 16:23, "Brian Suda" <brian.suda@gmail.com> wrote:
>> 
>>> You should add this to the Wiki under the
>>> FAQs, then we can all iterate on the best answer.
>> 
>> i know that the wiki is regarded as the way to do things in this community
>> but i'd like to remind you that there is no mechanism in place to get
>> notification when a particular page is updated. anyway i do prefer mail for
>> discussions and wikis for results (temporary or permanent) but this absence
>> of a notification mechanism makes it particularily painful to keep up with
>> what's happening and tends to discourage participation to some extent (or
>> better: if you only want to participate to some extent).
> 
> Editing the wiki both updates IRC and there is an RSS feed at
> <http://microformats.org/wiki/index.php?title=Special:RecentChanges&feed=rss>

i'm so conservative, i like to have it all in my inbox :) watching an irc to
track just the hrecipe-related pages is not an option. watching the feed is
manageable but still it contains all the changes to every page on the wiki.
my personal tracking page forces me to visit it at least every 7 days -
which is a lot if the pages i watch don't change for months. when i became
editor of hrecipe i didn't want to make microformats the center of my life.
i would love if i could get just the hRecipe-related changes in my mailbox.
just that. of course this is just a wish and i'm well aware that everybody
here is volunteering - but it's a reasonable wish.

what i said about following (past) discussions on a mailinglist or a wiki
still holds: diff-ing through the history of a wiki page is a pain in the
ass... even compared to surfing a mailinglist archive on the web

cheers
thomas 

.
Thomas L?rtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas@guj.de