Re: [uf-new] Issue HP3 - BUY vs. PAYMENT in hProduct
Paul Lee (이기수) wrote: From the payment page: quote 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). /quote 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. Hrm, I tend to disagree with your reading of payment. We use payment in the same way that you intend to use it in hAudio - to point to a URL that starts the purchase process. 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. I think payment-method refers to the various payment methods, not payment. The argument for buy is a difficult one to make because there already exists something for the purpose that you describe in Microformats - payment. hAudio defines payment like so: http://microformats.org/wiki/haudio#Purchase_.28Payment.29 specifically, The URI MUST point to the beginning of a purchase process for the hAudio. I don't see why you can't re-use that term instead of minting a new one. -- 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
Re: [uf-new] Issue HP7 - Abundance of vocabulary terms in hProduct
Paul Lee (이기수) wrote: 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. I would expect many people on this list would have an issue if I made the following statement: The hAudio examples aren't necessarily an accurate reflection of how frequently the ISRC is used by retailers. In practice, ISRC is used quite frequently and should be in the vocabulary. The reason uFers should have an issue with this statement is because I'm asserting something that isn't backed up by the examples that have been gathered for hAudio - there is no hard data behind it. In the Microformats community, if you can't show hard usage data for a vocabulary term, it should not be a part of the vocabulary. If you don't have enough data to prove that model/mpn is used more than 15% of the time, you are going to have a very hard time convincing this group that it belongs in a vocabulary. -- 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
Re: [uf-new] Issue HP6 - P-V seems like a catch-all for hProduct
Paul Lee (이기수) wrote: 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. Don't try to future-proof your vocabulary - if there isn't enough data to back up a vocabulary term, it doesn't belong in a Microformat. One of the principles that this whole community is built around is proving that vocabulary term usage in-the-wild has reached a critical mass and thus needs to be standardized. The nice thing about vocabulary development is that it is a continuous process... if you miss an important vocabulary term now, you can always put it in later. It's much more costly to remove vocabulary terms from a vocabulary if they are not used. For example, if printable becomes a reality for a large range of plastic products (due to the proliferation of high-quality, low-cost 3D printers), then the term can be added to the product vocabulary when that happens. Not before. I understand your argument for p-v, however, if every Microformat used it we would start to have a high number of collisions when interleaving Microformats on a page. There are two arguments against using p-v: 1. It is an attempt to future-proof a vocabulary that isn't based on any hard data. 2. It increases the likely-hood of vocabulary term collisions. To put it another way - if we are going to allow 'p-v', hAudio will have support for it immediately... and then people will have a nasty time interleaving hAudio+hProduct. If you'd like an example of this issue, I'd be happy to give one. -- 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
One issue per thread (was: Re: [uf-new] hProduct issues HP1-HP7)
Tantek Celik wrote: 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. The reason I put each of these in a separate e-mail is to separate issues out into manage-able threads of discussion. I do admit that it's a personal preference, but threaded discussion seems to be a fairly accepted method of working through spec issues. I realize that your preference is to edit the wiki and not respond via e-mail, but it's not clear to me how this is a better method of refining these specs, especially when we're just discussing things. I see that the mailing list rules have been updated as a result of my posts: http://microformats.org/wiki/mailing-lists#Avoid_sending_one_message_per_issue_raised Could you please explain why it's better to discourage per-issue threads on the mailing list and instead direct people to the wiki? Why are we discouraging one form of recorded communication over another? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. twitter: http://twitter.com/manusporny ___ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
