Re: [uf-new] hProduct issues HP1-HP7

[Martin McEvoy]

Great start on a product microformat Paul,

Martin McEvoy wrote:

+ 1 from me on all  issues HP1-HP7

To be honest one of the issues highlighted by Manu,  the "p-v" 
property I don't quite understand ... what does it "mean" ?  the lack 
of examples and data concerns me too sorry.


OK I do understand  "p-v"  "property" - "value" what I don't understand 
is how I am supposed to use it?.


by Tenacious D

why doesn't this work?

by Released: class="value">November 14, 
2006


huh?

see: http://microformats.org/wiki/datetime-design-pattern

November 14, 
2006


looks better?

see http://microformats.org/wiki/hproduct#Examples_in_Production for example

Also the example is a bit complex  how about some minimal markup first? 
it might help us all get a grip of the basics first.


I think a product microformat is a good idea but you have to think a 
little more micro, which is simple, minimal and only covers the most 
commonly used properties occurring 80% or more of the time based on 
solid examples that illustrate your problem precisely. Once you have 
worked out what that is ask yourself has any of this been done before? 
no! that doesn't mean with just microformats Manu is the key developer 
of haudio and ended up finding that what he wanted to do would be much 
more practical in RDFa  it sounds a bit off putting but look elsewhere 
FIRST ...still not happy then we can talk about a microformat.


have a look at http://microformats.org/wiki/principles
and http://microformats.org/wiki/process

understand them (I'm not saying you don't) they offer some really good 
guidance on what to do next.


Best wishes.

--
Martin McEvoy

http://weborganics.co.uk/

"You may find it hard to swallow the notion that anything as large and apparently 
inanimate as the Earth is alive."
Dr. James Lovelock, The Ages of Gaia

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] hProduct issues HP1-HP7

[Martin McEvoy]

+ 1 from me on all  issues HP1-HP7

To be honest one of the issues highlighted by Manu,  the "p-v" property 
I don't quite understand ... what does it "mean" ?  the lack of examples 
and data concerns me too sorry.


Thanks

Tantek Celik wrote:

Thanks Manu for documenting some hProduct issues on the wiki.

I have added my comments to each one.

http://microformats.org/wiki/hproduct-issues

In short I agree that all of the issues raised so far are issues and went 
further on some of them.

Please follow-up on the wiki and also one email announcing a batch of new 
issues is sufficient. Let's try to keep emails to a minimum for notification 
only, and capture discussion/iteration on the wiki.

Thanks,

Tantek
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
  



--
Martin McEvoy

http://weborganics.co.uk/

"You may find it hard to swallow the notion that anything as large and apparently 
inanimate as the Earth is alive."
Dr. James Lovelock, The Ages of Gaia

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] re: Microformats support for aggregate reviews

[Othar Hansson]

Adding a new microformat for aggregate reviews seems like the wrong
direction to me, because we're adding one that will have strictly
fewer users than hReview itself.

Will we do the same for aggregates of everything?  products, listings,
events, etc. could all reasonably have aggregates to describe "what's
on a page".

Why don't we just define a trivial microformat "aggregate", which
contains one value "count", and can wrap any other microformat?  The
fields of the wrapped microformat get a new meaning: any given field
is meant to be an aggregate of all the other data associated with the
page.  E.g., a hypothetical price field should contain a price range.
A rating field should contain an aggregrate rating.  etc.

--Othar



On Fri, Feb 13, 2009 at 8:26 AM, Myers, Jay  wrote:
>
> Good morning Kavi,
>
> I am putting together an example this morning to post on the wiki. A
> couple of issues that I ran into with the "postcard" example we talked
> about earlier this week:
>
> -- hReview has a required item attribute. I decided to put an href
> around the stars that points to a product detail page url. It might not
> be the most solid workaround, but we can certainly work on that either
> through the format itself, or altering the html to include the name of
> the product.
> -- in many examples there is a total number of reviews. I have added the
> class "num" to identify this. Completely up for debate on the naming...
>
> I should be able to create more examples from other sites next week...
>
> Thanks,
>
> Jay
>
>
> Jay Myers
> Lead Web Development Engineer
> Online Solutions, BestBuy.com
> jay.my...@bestbuy.com
> (w) 612-291-4007
> (c) 612-296-5836
> (twitter) @jaymyers
> (skype) jaymmyers
> -Original Message-
> From: microformats-new-boun...@microformats.org
> [mailto:microformats-new-boun...@microformats.org] On Behalf Of Kavi
> Goel
> Sent: Wednesday, February 11, 2009 4:26 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] re: Microformats support for aggregate reviews
>
> Hi all,
>
> Here is a quick update on conversations around microformats aggregate
> reviews support. I've updated the aggregate-review-brainstorming wiki
> page based on our IRC conversation a few weeks ago:
> http://microformats.org/wiki/aggregate-review-brainstorming
>
> The short summary of the proposal that emerged from the discussion
> over IRC is as follows:
> - define a new microformat that contains two elements. 1) number of
> reviews, and 2) an embedded hReview
> - fields in the embedded hReview (i.e. rating, summary, item type)
> would refer to aggregate information. For example, the rating is the
> average rating across all reviews.
>
> Why this proposal?
> - the new microformat would contain only one element (at least in an
> initial version) to keep things simple according to the 80% rule
> - creating a new microformat rather than extending hReview provides
> flexibility to potentially add more aggregate-only fields in the
> future without cluttering hReview.
>
> If this approach seems like a good one, Jay Myers and/or I will also
> add a few examples of how this markup could look for some sites.
>
> One issue we ran into when trying to apply this to Best Buy and Amazon
> pages -- on many pages, the entire page is about a product, whereas
> only a section of the page is about the reviews. On the other hand,
> for sites like Yelp, the entire page is about the reviews, and only a
> section of the page is about the product spec. So it probably makes
> sense to allow embedded reviews in hProduct's as well as embedded
> hProduct's in hReview's depending on the hierarchy that naturally
> exists on the page.
>
> Kavi
>
>
> On Thu, Jan 22, 2009 at 4:02 PM, Kavi Goel  wrote:
> >
> > In order to move this discussion about aggregate reviews along, I'd
> > like to have a discussion over IRC. As a heads-up, I'll plan on
> > discussing alternatives around 2PM Pacific time tomorrow. For folks in
> > different timezones who will be out enjoying the nightlife, sleeping
> > or otherwise away from a computer, please feel encouraged to post
> > ideas via this email discussion or on the brainstorming wiki here:
> > http://microformats.org/wiki/aggregate-review-brainstorming
> >
> > Thanks,
> > Kavi
> >
> > On Wed, Jan 14, 2009 at 12:48 AM, Toby A Inkster
>  wrote:
> > >
> > > Jamie Rumbelow wrote:
> > >
> > >> See, comments like that lead me on to think that we need some form
> of
> > >> pagination system for microformats - pagination is much more
> popular among
> > >> sites these days and a rel="paginate" might come in handy.
> > >
> > > HTML already has perfectly good rel="next"/"prev" for that.
> > >
> > > http://www.w3.org/TR/REC-html40/types.html#type-links
> > >
> > > --
> > > Toby A Inkster
> > > 
> > > 
> > >
> > >
> > >
> > > ___
> > > microformats-new mailing list
> > > microformats-new@microformats.org
> >

Re: [uf-new] hProduct issues HP1-HP7

[Tantek Celik]

Thanks Manu for documenting some hProduct issues on the wiki.

I have added my comments to each one.

http://microformats.org/wiki/hproduct-issues

In short I agree that all of the issues raised so far are issues and went 
further on some of them.

Please follow-up on the wiki and also one email announcing a batch of new 
issues is sufficient. Let's try to keep emails to a minimum for notification 
only, and capture discussion/iteration on the wiki.

Thanks,

Tantek
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Issue HP3 - BUY vs. PAYMENT in hProduct

[이기수]

>From the payment page:


RelPayment is a microformat for making exchanges of support (be it
financial or otherwise) possible. By adding rel="payment" to a
hyperlink a page indicates that the destination of that hyperlink
provides a way to show or give support for the current page. For
example to give financial support to the owner of the current page.

One of the goals with this microformat is to give content aggregators
such as RSS readers a way to extract these support links and give them
special attention (such as displaying a standard button along with the
content).


First, this seems like a simple exercise for blogs, etc.; but the
transaction process for shopping sites is typically considerably more
complex.  Usually, the actual payment URI is toward the end of the
cart checkout process, the entry to which "buy" is intended to direct
to the beginning of.

Second, there is the potential for confusion when using payment, since
"payment" in the shopping space often refers to payment methods, e.g.,
credit card, check, etc.


On Tue, Feb 17, 2009 at 9:45 PM, Manu Sporny  wrote:
>
> http://microformats.org/wiki/hproduct-issues#HP3_-_BUY_duplicates_functionality_of_PAYMENT_from_hAudio
>
> hProduct seems to create a new term called BUY instead of re-using
> PAYMENT. What's the reasoning behind creating the new term vs. using the
> one that has already been invented?
>
> -- manu
>
> --
> Manu Sporny
> President/CEO - Digital Bazaar, Inc.
> blog: Scaling Past 100,000 Concurrent Web Service Requests
> http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1
> ___
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new



--
Paul Lee
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
+1 (650) 214-6612
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Issue HP7 - Abundance of vocabulary terms in hProduct

[이기수]

The examples aren't necessarily an accurate reflection of how
frequently attributes/data is used by retailers.  In practice,
model/mpn is used much more frequently than dimensions, both for
retailer websites as well as retailer submissions to search and
shopping engines.

Defer to those with more experience/other data on version.

On Tue, Feb 17, 2009 at 10:28 PM, Manu Sporny  wrote:
> http://microformats.org/wiki/hproduct-issues#HP7_-_Lots_of_vocabulary_terms.2C_does_the_data_really_back_this_up.3F
>
> There are currently 15 vocabulary terms in hProduct, but some of the
> terms don't seem to be backed up in the hProduct analysis[1].
>
> For example, MODEL shows up in 15% of the examples, but made it into the
> vocabulary. However, DIMENSIONS shows up in 51% of the examples, COLOR
> in 31% of the examples, but neither made it into the vocabulary. Why did
> that happen?
>
> Also - do we really think that VERSION is a good idea? Where on the page
> are we going to use this? Are we suggesting that page authors should
> version each of the hProduct instances? Does anybody actually use this
> in practice?
>
> -- manu
>
> [1]http://microformats.org/wiki/hproduct-examples#Analysis_of_Product.2FCommerce_Sites
>
> --
> Manu Sporny
> President/CEO - Digital Bazaar, Inc.
> blog: Scaling Past 100,000 Concurrent Web Service Requests
> http://blog.digitalbazaar.com/2008/09/30/scaling-webservices-part-1
> ___
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>



-- 
Paul Lee
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
+1 (650) 214-6612
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct

[이기수]

IIUC, part of the reason why hproduct has been under discussion for
quite awhile is b/c of the debate between p-v vs. more defined
attributes.  p-v is quite helpful b/c the attributes users care about
change over time.  Take cameras, for instance.  Did anyone care about
megapixels 10 years ago? etc.

On Wed, Feb 18, 2009 at 1:19 AM, David Janes  wrote:
> On Wed, Feb 18, 2009 at 1:12 AM, Manu Sporny  
> wrote:
>> http://microformats.org/wiki/hproduct-issues#HP6_-_P-V_seems_like_a_catch-all_for_hProduct
>>
>>
>> hProduct currently allows the author to use the P-V pattern for anything
>> that doesn't fit neatly into hProduct. While it is true that this is a
>> nice way to expand hProduct and see where future versions of hProduct
>> might need to be expanded, there is a danger that over-use of the P-V
>> pattern will result in weird issues between future Microformats.
>>
>> For example, if hProduct lists a number of P-Vs and another Microformat
>> starts using P-V heavily, there will be clashes between the overlapping
>> Microformats. These clashes will result in the wrong P-Vs being assigned
>> to the wrong object.
>>
>> It also seems a bit sloppy - using P-V may be a clear sign that the
>> problem being solved isn't small enough, or that you're attempting to
>> boil the oceans in a clever way. Anybody else have some thoughts about
>> the use or abuse of P-V in Microformats?
>
> I got hung up on this one too, wrote a post, deleted it. Thoughts:
>
> 1) my thinking is that the "semanticness" doesn't go down to the P and
> V, that we know that products have lists of property and values but at
> this level we _attach no meaning to the terms_ beyond the fact that
> they are there. And later on, if we decide (e.g.) that "Number of
> Wheels"/"4" has standardizable meaning, we can define
> "number-of-wheels" and add that as class value.
> 2) is this just not a DL? we are fine with that...
> 3) why not use a DL? I note alternatively that hAtom allows both H#
> and entry-title.
>
> Regards, etc...
>
> --
> David Janes
> Mercenary Programmer
> http://code.davidjanes.com
> ___
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>



-- 
Paul Lee
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
+1 (650) 214-6612
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct

[David Janes]

On Wed, Feb 18, 2009 at 1:12 AM, Manu Sporny  wrote:
> http://microformats.org/wiki/hproduct-issues#HP6_-_P-V_seems_like_a_catch-all_for_hProduct
>
>
> hProduct currently allows the author to use the P-V pattern for anything
> that doesn't fit neatly into hProduct. While it is true that this is a
> nice way to expand hProduct and see where future versions of hProduct
> might need to be expanded, there is a danger that over-use of the P-V
> pattern will result in weird issues between future Microformats.
>
> For example, if hProduct lists a number of P-Vs and another Microformat
> starts using P-V heavily, there will be clashes between the overlapping
> Microformats. These clashes will result in the wrong P-Vs being assigned
> to the wrong object.
>
> It also seems a bit sloppy - using P-V may be a clear sign that the
> problem being solved isn't small enough, or that you're attempting to
> boil the oceans in a clever way. Anybody else have some thoughts about
> the use or abuse of P-V in Microformats?

I got hung up on this one too, wrote a post, deleted it. Thoughts:

1) my thinking is that the "semanticness" doesn't go down to the P and
V, that we know that products have lists of property and values but at
this level we _attach no meaning to the terms_ beyond the fact that
they are there. And later on, if we decide (e.g.) that "Number of
Wheels"/"4" has standardizable meaning, we can define
"number-of-wheels" and add that as class value.
2) is this just not a DL? we are fine with that...
3) why not use a DL? I note alternatively that hAtom allows both H#
and entry-title.

Regards, etc...

-- 
David Janes
Mercenary Programmer
http://code.davidjanes.com
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new