Re: Re: [uf-discuss] rel=license and copyright
I don't think that makes any sense. You should make positive assertions about data, not negative ones... and why bother with a not-a-license schema? There's far too many negatives... as in licenses that it wouldn't be I think we ought only deal with what things *are* and not what they *aren't*. Chris On 11/17/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Andy, On 11/17/06, Andy Mabbett [EMAIL PROTECTED] wrote: I'm starting to look at using rel=license. Am I right in thing that it can be used to indicate that a page is NOT available under a license, as well as for those that are? For instance: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. I think that to indicate that something is NOT available under a certain license you'd really need something like a norel attribute. As in... a norel=license href=../a Or... you'd need a negative of the license token... maybe nolicense to use with the rel attribute... as in... a rel=nolicense href=../a See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] rel=license and copyright
Hello, On 11/17/06, Chris Messina [EMAIL PROTECTED] wrote: I don't think that makes any sense. You should make positive assertions about data, not negative ones... Why? Andy is in fact trying to make a negative assertion, of the license token. and why bother with a not-a-license schema? There's far too many negatives... as in licenses that it wouldn't be Andy might want to name one (or a few) specific licenses that it is not. I think we ought only deal with what things *are* and not what they *aren't*. That's fine, but they you need to put the negative into the token... as in nolicense or something like that. See ya Chris On 11/17/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Andy, On 11/17/06, Andy Mabbett [EMAIL PROTECTED] wrote: I'm starting to look at using rel=license. Am I right in thing that it can be used to indicate that a page is NOT available under a license, as well as for those that are? For instance: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. I think that to indicate that something is NOT available under a certain license you'd really need something like a norel attribute. As in... a norel=license href=../a Or... you'd need a negative of the license token... maybe nolicense to use with the rel attribute... as in... a rel=nolicense href=../a See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=license and citation
On Sat, 2006-11-18 at 07:16 +, Andy Mabbett wrote: hReview can use rel=license to show that the license, not the page itself, is available under a certain license. You meant ... to show that the contents of the hReview itself is licensed, not the page ... Why not do the page for citations, so that I can cite, say, a Wordsworth poem, and indicate that the poem, but not my page, is public domain? If you want to be symmetric with http://microformats.org/wiki/hReview#Field_details rel=license in a citation would be saying that the contents of the citation is licensed, not the cited work. On Sat, 2006-11-18 at 07:25 +, Andy Mabbett wrote: I'm starting to look at using rel=license. Am I right in thing that it can be used to indicate that a page is NOT available under a license, as well as for those that are? For instance: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. I'm not sure what the point of this would be as default copyright is ... the default, but I also don't know why rel=license couldn't be used to refer to a restrictive license statement, including one that says no rights are granted. -- http://wiki.creativecommons.org/User:Mike_Linksvayer ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: QnA microformat(s)
On 11/18/06, Korby Parnell [EMAIL PROTECTED] wrote: Hi-- I can't seem to find any information about question and answer microformats on microformats.org. Insofar as I'm new to this list, has there been any backchannel discussion about distributed QA systems and a microformat or microformats to support them? Hi Korby, I've not come across a QA specific format being mentioned before - so this is probably something new :) You could start gathering a few examples of QA systems out there (to understand what's already being done) and then take a look at how one might go about marking these with existing formats (if at all - can't simple Question/Answers be marked with definition lists alone?). F -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RE: QnA microformat(s)
Hello Korby, On 11/17/06, Korby Parnell [EMAIL PROTECTED] wrote: Hi-- I can't seem to find any information about question and answer microformats on microformats.org. Insofar as I'm new to this list, has there been any backchannel discussion about distributed QA systems and a microformat or microformats to support them? When you say QA... do you mean like a FAQ?... or a form with questions where someone has to fill in the answers. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Re: [uf-discuss] rel=license and copyright
The _link_ itself isn't a negative assertion; the negative assertion is in the rights conferered on others by the license that is linked to. Copyright Me, All Rights Reserved is a good a legal license a Free For All, Help Yourself. The URI could be to the copyright office. Regards, etc... David On 11/18/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello, On 11/17/06, Chris Messina [EMAIL PROTECTED] wrote: I don't think that makes any sense. You should make positive assertions about data, not negative ones... Why? Andy is in fact trying to make a negative assertion, of the license token. and why bother with a not-a-license schema? There's far too many negatives... as in licenses that it wouldn't be Andy might want to name one (or a few) specific licenses that it is not. I think we ought only deal with what things *are* and not what they *aren't*. That's fine, but they you need to put the negative into the token... as in nolicense or something like that. See ya Chris On 11/17/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Andy, On 11/17/06, Andy Mabbett [EMAIL PROTECTED] wrote: I'm starting to look at using rel=license. Am I right in thing that it can be used to indicate that a page is NOT available under a license, as well as for those that are? For instance: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. I think that to indicate that something is NOT available under a certain license you'd really need something like a norel attribute. As in... a norel=license href=../a Or... you'd need a negative of the license token... maybe nolicense to use with the rel attribute... as in... a rel=nolicense href=../a See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=license and copyright
Hello, On 11/18/06, Andy Mabbett [EMAIL PROTECTED] wrote: I'm starting to look at using rel=license. Am I right in thing that it can be used to indicate that a page is NOT available under a license, as well as for those that are? For instance: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. If it's not published under a certain licence but copyrighted (like in this case), you should use rel=copyright instead of rel-licence. The value copyright is a predefined linktype in HTML, (http://www.w3.org/TR/html4/types.html#type-links) and says that Refers to a copyright statement for the current document. So I think using rel-copyright would perfectly fit in. -- vant m. yak / [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=license and copyright
Of course. I retract my last message. Orthogonal issues. Regards, etc... On 11/18/06, kota the vantguarde [EMAIL PROTECTED] wrote: Hello, On 11/18/06, Andy Mabbett [EMAIL PROTECTED] wrote: I'm starting to look at using rel=license. Am I right in thing that it can be used to indicate that a page is NOT available under a license, as well as for those that are? For instance: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. If it's not published under a certain licence but copyrighted (like in this case), you should use rel=copyright instead of rel-licence. The value copyright is a predefined linktype in HTML, (http://www.w3.org/TR/html4/types.html#type-links) and says that Refers to a copyright statement for the current document. So I think using rel-copyright would perfectly fit in. -- vant m. yak / [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Clarification on hListing
I'm looking at the schema for hListing [1] and I have a question: is the item explicitly marked as class=item? It's not clear from the markup. Regards, etc... David [1] http://microformats.org/wiki/hlisting#Schema -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Clarification on hListing
On 11/18/06, David Janes [EMAIL PROTECTED] wrote: I'm looking at the schema for hListing [1] and I have a question: is the item explicitly marked as class=item? It's not clear from the markup. Yes, it is abit confusing and contracitory. In the schema it says Optional, but then in the Item Metadata it says: This required field MUST have at a minimum... The edgio.com uses hListing but their mark-up doesn't give any hints. http://www.edgeio.com/item/1807880-4266-Arsenal-St-Louis-MO-House-For-Rent-saint%20louis-missouri-usa-north%20america Dealtagger is another site: http://www.dealtagger.com/group/nikon_d50/ They do use the class=item, but also have an FN at the same level (it should be nested), and they do not uses the REQUIRED description. listing action is another one that confuses me, is that two words, one word listing-action or just a tag with some of the recommended values... it is required, but i don't see it in action on edgeio.com or Dealtagger I would bring-up these issues on the feedback page (http://microformats.org/wiki/hlisting-feedback) or create an issues page on the wiki (http://microformats.org/wiki/hlisting-issues) -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hThing microformat ... or design pattern
I would suggest there's a serious issue with what you've produced so far, insofar as you have seemed to come up with the microformat first rather than doing analysis of what's currently in use on the web and also what's currently being done in other microformats. For example, hListing and hReview already imply a design pattern for how items or products could be marked up [1]. If I understand what you've put on the wiki, your intention is that these existing microformats would have to be back-changed to conform to your proposed microformat. Other attributes, such as name, uri, image ... seem to have little relation to similar attributes already defined in other microformats [2]. Without having an -examples and -formats page and then -brainstorming based on that, it's difficult for me to understand why you are proposing a new vocabulary. Regards, etc... David [1] http://microformats.org/wiki/item-formats#Existing_Microformats [2] http://microformats.org/wiki/existing-classes On 11/17/06, Aaron Gustafson [EMAIL PROTECTED] wrote: David Janes wrote: I'm not sure if I'm that excited :-) but I definitely think there's a gap that can be filled (i.e. that hReview/hListing identify people directly but only things indirectly). It's possible, but this is very speculative, that this could simplify the path for creating new microformats like hWine. I am just joining the discussion list, so forgive me if what I rehash older discussions. Craig Cook and I had been working on hProduct somewhat in isolation and thought we should post the information we've created to get our ideas and thoughts out there. I see some sililarities with what is up on hItem, though I agree hItem may be a little too broad (see the earlier 'what is an item?' comments). I'd definitely advocate for hItem including information about its creator, and optionally its producer and vendor. These of course could be hCard entries or links, and I think it would give us a flexible way to include much of the information that felt very wine specific such as Vintage (aka, producer and production date). It seems as though an hItem's production and creation could also be considered events, so reusing hEvent here seems to make a lot of sense. What do you think? Is this more complicated than it needs to be, or is the reuse of other microformats here a good thing? Let's go through the examples and see what's frequently used, somewhat used and rarely or sporadically used. That will point the right direction I think. And, as per usual, I encourage everyone to contribute to the examples because that's one of the hardest and least thanked parts. Hmm, I think we really need to boil this down to its essence. With products, unless you want to go the route niche microformats like hWine or hBook, it makes sense to stick to a few key, repeatable fields, for example: * name * description * image * msrp * uri * brand The rest could be handled by a generic property value construct which we've called 'p-v' (and may honestly have usefulness outside the hProduct/hItem concept). Also, is this ground already being covered by hListing (which seems to be looking to include some of this info), or would you simply have hListings of events (hEvent), people (hCard), and things (hItem)? The latter, but we're data mining hListing/hReview to maximize reuse. IMHO, there are a few places I think hListing (and hReview for that matter) are reaching a bit beyond what should be their scope. This is where I think hProduct/hItem fits in. In other words, you could essentially script the linking of a product for sale in an hListing with a review of that product in hReview. I'd be interested in feedback on what Craig and I have posted so far and perhaps we can find a way to merge hItem and hProduct and suggest some augmentations to hListing and hReview to make some space for hProduct/hItem. We will be posting some of our examples shortly. Cheers, Aaron Aaron Gustafson Sr. Web Designer/Developer Easy! Designs, LLC 203-215-8829 O 203-230-0773 F [EMAIL PROTECTED] Easy! Designs, LLC 83 Treadwell St Hamden, CT 06517 http://www.easy-designs.net http://www.easy-reader.net ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=license and citation
In message [EMAIL PROTECTED], Mike Linksvayer [EMAIL PROTECTED] writes On Sat, 2006-11-18 at 07:16 +, Andy Mabbett wrote: hReview can use rel=license to show that the license, not the page itself, is available under a certain license. You meant ... to show that the contents of the hReview itself is licensed, not the page ... Indeed. Thank you. Why not do the page for citations, so that I can cite, say, a Wordsworth poem, and indicate that the poem, but not my page, is public domain? I also meant why not do the /same/ for citations... Goodness knows what happened to my typing, this morning... If you want to be symmetric with http://microformats.org/wiki/hReview#Field_details rel=license in a citation would be saying that the contents of the citation is licensed, not the cited work. Perhaps,; but that's unlikely to be the case - often, if not usually, a citation is fair use, regardless of the copyright or license state of the source. On Sat, 2006-11-18 at 07:25 +, Andy Mabbett wrote: I'm starting to look at using rel=license. Am I right in thing that it can be used to indicate that a page is NOT available under a license, as well as for those that are? For instance: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. I'm not sure what the point of this would be as default copyright is ... the default Yes, but /whose/ copyright? Consider, on one site: This page is a rel=license href=http://www.example.com/copyrightcopyright Example Ltd. 2006/a and may not be reproduced. This second page is a rel=license href=http://www.example2.com/copyrightcopyright Example2 Ltd. 2006/a and is used by permission. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel=license and copyright
In message [EMAIL PROTECTED], Charles Iliya Krempeaux [EMAIL PROTECTED] writes and why bother with a not-a-license schema? There's far too many negatives... as in licenses that it wouldn't be Andy might want to name one (or a few) specific licenses that it is not. No, thanks. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] PROPOSAL: keep it simple; make it extensible?
Rather than trying to devise a microformat (hThing or hItem) that can describe any thing (or at least any physical thing), with all the possible or probable properties that might entail: would it perhaps be better to define a re-usable wrapper, and say that any microformat(s) or properties inside that wrapper apply to that thing? Say: span class=hitem [hReview] [other uFs] /span Then apply secondary classes to the hItem as microformats are developed in future, say: span class=hitem wine [hReview] [other uFs] /span We could then use: span class=hitem span class=[property-name] span class=value[n]/span /span /span or span class=hitem span class=property span class=type[property-type]/span span class=value[n]/span /span /span for various properties or property-types (abv, say) as and when they're required: span class=hitem wine [hReview] span class=abv span class=value7.8/span /span /span or span class=hitem wine [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span Or, where no secondary class exists, parsers would simply infer that the properties apply to the item: span class=hitem [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span or could extract the nature of the item from a tag: span class=hitem a rel=tag class=hitem-type href=http://www.example.com/wineWine/a News [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span or class: span class=hitem span class=hitem-typeWine/span News [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span Such properties could then be proposed and agreed more speedily then entire uFs. Items could be nested, with any properties in the inner item applying to that, and not the outer item(s). Alternative names could be hThing or hObject. This post contains several blue sky proposals, which can be considered separately, if not as a whole. (Note: wine and abv are used for illustration only, and not to imply any endorsement or otherwise to the current wine proposal) -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] PROPOSAL: keep it simple; make it extensible?
The fact that this effort seems vague and non-specific to begin with seems to preclude it from ever gaining adoption; additionally, finding existing behavior would be a challenge, not to mention the limited semantic usefulness of knowing that something is a thing or item. What *specific* problem, captured in the wild, is this work looking to solve? Chris On 11/18/06, Andy Mabbett [EMAIL PROTECTED] wrote: Rather than trying to devise a microformat (hThing or hItem) that can describe any thing (or at least any physical thing), with all the possible or probable properties that might entail: would it perhaps be better to define a re-usable wrapper, and say that any microformat(s) or properties inside that wrapper apply to that thing? Say: span class=hitem [hReview] [other uFs] /span Then apply secondary classes to the hItem as microformats are developed in future, say: span class=hitem wine [hReview] [other uFs] /span We could then use: span class=hitem span class=[property-name] span class=value[n]/span /span /span or span class=hitem span class=property span class=type[property-type]/span span class=value[n]/span /span /span for various properties or property-types (abv, say) as and when they're required: span class=hitem wine [hReview] span class=abv span class=value7.8/span /span /span or span class=hitem wine [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span Or, where no secondary class exists, parsers would simply infer that the properties apply to the item: span class=hitem [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span or could extract the nature of the item from a tag: span class=hitem a rel=tag class=hitem-type href=http://www.example.com/wineWine/a News [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span or class: span class=hitem span class=hitem-typeWine/span News [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span Such properties could then be proposed and agreed more speedily then entire uFs. Items could be nested, with any properties in the inner item applying to that, and not the outer item(s). Alternative names could be hThing or hObject. This post contains several blue sky proposals, which can be considered separately, if not as a whole. (Note: wine and abv are used for illustration only, and not to imply any endorsement or otherwise to the current wine proposal) -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] PROPOSAL: keep it simple; make it extensible?
My current plan is (and has been) to keep it as simple as possible and _not_ to try to solve the everything problem. In particular, my current thinking is here [1] which basically says do the same thing with item from hReview/hListing as was done to adr and geo from hCard, add a missing field or two (description in particular) and then expect that future microformats (hWine) will composite on top of that. The property-name/property-value thing I think is totally out of scope for _I_ want to do! I understand the potential value of that and it's probably worth an entirely exporatory series of wikipage of it's own (and there's lots of examples that can be drawn upon from out on the net, plus the work that's been done on microformats-rest). If you think it's worth tackling, I'll certainly contribute examples from what I've seen on the net. I think that you've inverted the parent-child relationship between (say) a review and a item; that is, it is more natural to expect the item to be a child/attribute of the review rather than the other way around. Regards, etc... David [1] http://microformats.org/wiki/item-brainstorming#DavidJanes On 11/18/06, Andy Mabbett [EMAIL PROTECTED] wrote: Rather than trying to devise a microformat (hThing or hItem) that can describe any thing (or at least any physical thing), with all the possible or probable properties that might entail: would it perhaps be better to define a re-usable wrapper, and say that any microformat(s) or properties inside that wrapper apply to that thing? Say: span class=hitem [hReview] [other uFs] /span Then apply secondary classes to the hItem as microformats are developed in future, say: span class=hitem wine [hReview] [other uFs] /span We could then use: span class=hitem span class=[property-name] span class=value[n]/span /span /span or span class=hitem span class=property span class=type[property-type]/span span class=value[n]/span /span /span for various properties or property-types (abv, say) as and when they're required: span class=hitem wine [hReview] span class=abv span class=value7.8/span /span /span or span class=hitem wine [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span Or, where no secondary class exists, parsers would simply infer that the properties apply to the item: span class=hitem [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span or could extract the nature of the item from a tag: span class=hitem a rel=tag class=hitem-type href=http://www.example.com/wineWine/a News [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span or class: span class=hitem span class=hitem-typeWine/span News [hReview] span class=property span class=typeabv/span span class=value7.8/span /span /span Such properties could then be proposed and agreed more speedily then entire uFs. Items could be nested, with any properties in the inner item applying to that, and not the outer item(s). Alternative names could be hThing or hObject. This post contains several blue sky proposals, which can be considered separately, if not as a whole. (Note: wine and abv are used for illustration only, and not to imply any endorsement or otherwise to the current wine proposal) -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] PROPOSAL: keep it simple; make it extensible?
My primary goal is to document an existing behavior, that items are referred to and used in microformats today. If you'll care to look at the examples found so far and also the usage in existing microformats, you'll see that this is clearly an _existing behaviour_, insofar as hListing and hReview are used at all. A nice benefit is providing a vocabulary for _new_ microformats to refer to items in a consistent manner with _existing_ microformats. You'll note that I started this discussion talking about that we may just be looking at a design pattern, though as mentioned in my previous letter I think this is something on par with adr and geo, that is, an extraction from something that is already happening. Regards, etc... On 11/18/06, Chris Messina [EMAIL PROTECTED] wrote: The fact that this effort seems vague and non-specific to begin with seems to preclude it from ever gaining adoption; additionally, finding existing behavior would be a challenge, not to mention the limited semantic usefulness of knowing that something is a thing or item. What *specific* problem, captured in the wild, is this work looking to solve? Chris -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] PROPOSAL: keep it simple; make it extensible?
Fair enough. Awhile back I talked to Tantek about micro-patterns as opposed to data-bearing formats. This seems more a discussion of design patterns and templates than of formats, but I'll give the examples a look over. Chris On 11/18/06, David Janes [EMAIL PROTECTED] wrote: My primary goal is to document an existing behavior, that items are referred to and used in microformats today. If you'll care to look at the examples found so far and also the usage in existing microformats, you'll see that this is clearly an _existing behaviour_, insofar as hListing and hReview are used at all. A nice benefit is providing a vocabulary for _new_ microformats to refer to items in a consistent manner with _existing_ microformats. You'll note that I started this discussion talking about that we may just be looking at a design pattern, though as mentioned in my previous letter I think this is something on par with adr and geo, that is, an extraction from something that is already happening. Regards, etc... On 11/18/06, Chris Messina [EMAIL PROTECTED] wrote: The fact that this effort seems vague and non-specific to begin with seems to preclude it from ever gaining adoption; additionally, finding existing behavior would be a challenge, not to mention the limited semantic usefulness of knowing that something is a thing or item. What *specific* problem, captured in the wild, is this work looking to solve? Chris -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onamine.com http://blogmatrix.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Ma.gnolia Blog: JSON, HTML, and Microformats. Oh, My!
In case anyone missed it... something to play with and offer ideas for: http://ma.gnolia.com/blog/2006/11/14/json-html-and-microformats-oh-my Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hThing microformat ... or design pattern
To all: Well, looks like it's time for me to inject my two cents. I had planned to bring this to the group later when I had time to focus on it, but looks like the ship is sailing so I better get on board or left behind... BTW, I'm not presenting the following to be contrary to anyone else's comments, this are just a brief summary of my thoughts on the subject. I spent 12 years working on trying to create a database schema and taxonomy for the software products that we sold at Xtras, and one of the issues that always confounded me was the concept of a Product. I realized after much hard work that whereas an Item was easy to define because it had a price associated with it and hence other tangible attributes[1], a Product really was a marketing concept and hence ethereal and almost impossible to nail down in a taxonomy. (Tangible attributes = Licensing, media (cd/dvd/download), eligibility (full version/upgrade/comp. upgrade), etc. for my context, but in other contexts size, color, material, etc. and so much more.) I tried for years to model things with Product-Family and Product-Line and others, but nothing every really fit until I loosened my grip and just went with a more general concept of Saleable. The concept being that an Item is Saleable as is a Product, as are Product Familis, etc. So what I believe to be the best at capturing information about Products and Items is a recursible concept called Saleable. Hence I had planned to propose an hSaleable The top level schema for hSaleable would be the following with everything but Product as optional: * product = The name of the thing for sale (item, product, product family, etc.) * sku = Stock keeping unit (the website's unique human readable key for this item/product/etc.) * manufacturer/vendor/source = The company that creates this or where it is source (all of these valid) * description = Details about the product/item/etc. * srp - Suggested Retail Price for this product/item/etc. * price - Current price from this website for this product/item/etc. * official - If yes then this is the company with the authority to publish the official information (might be abused.) * part-no - the manufacturer/vendor/source's official part/reference number * serial-no - the serial number for this specific item (for one-of-a-kind items, i.e. for a used car: it's VIN) Beyond those, I envision a collection of name-value pairs that could be named any (or all) of these names: facts/specs/details/attributes. These would be used to specify things like color, size, material, licensing, etc. (I like the work attributes the best, but that wording might be confused with the usage of HTML element attributes.) The following are two examples (one from software and another from automobiles) with varying uses of the schema. Both are taken from real world pages albeit with slight augmentation in order to display more schema feature in just these two examples: = Software: Shows two levels of nesting, facts, etc = div class=saleable span style=visibility:hidden span class=officialyes/span span class=part-noipworks/span /span h2 Product Purchasing Options for a href=http://www.nsoftware.com/order/?filter=ipworks; class=url span class=product span class=vendor/n software/span's IP*Works! /span /a /h2 table tr thPart #/th thProduct/th thPrice/th /tr span class=saleable span style=visibility:hidden a href=http://www.nsoftware.com/order/options.aspx?part=IPN6-A; class=url span class=productIP*Works! V6 .NET Edition/span span class=part-noIPN6-A/span /a /span tr span class=saleable td class=part-noIPN6-A/td td b p class=productIP*Works! V6 .NET Edition - Full Version/p /b p span class=fact title=licensingOne Development Workstation/span , span class=fact title=licensingRoyalty-Free Distribution/span /p /td
