hlisting-feedback - Revision history

Dryan at 17:31, 3 March 2011

2011-03-03T17:31:55Z

← Older revision		Revision as of 17:31, 3 March 2011
Line 280:		Line 280:
	== Listing Action for Legal Notices ==		== Listing Action for Legal Notices ==

	The State of Tennessee is considering a bill that allows municipalities to move their required legal notices online. A Chattanooga-based open government group is encouraging our city and county to use the [[hListing]] microformat when they implement their online notices. However, we don't feel that "announcement" really covers this category and would like to suggest adding "legal ~~notice~~" as an option for the action.		The State of Tennessee is considering a bill that allows municipalities to move their required legal notices online. A Chattanooga-based open government group is encouraging our city and county to use the [[hListing]] microformat when they implement their online notices. However, we don't feel that "announcement" really covers this category and would like to suggest adding "legal" as an option for the action.

	-- [[User:Dryan\|Dryan]] <abbr title="2011-03-03">2011-03-03</abbr>		-- [[User:Dryan\|Dryan]] <abbr title="2011-03-03">2011-03-03</abbr>

Dryan at 17:28, 3 March 2011

2011-03-03T17:28:48Z

← Older revision		Revision as of 17:28, 3 March 2011
Line 277:		Line 277:

	-- [[User:FineWolf\|FineWolf]] <abbr title="2010-09-17">2010-09-17</abbr>		-- [[User:FineWolf\|FineWolf]] <abbr title="2010-09-17">2010-09-17</abbr>

			== Listing Action for Legal Notices ==

			The State of Tennessee is considering a bill that allows municipalities to move their required legal notices online. A Chattanooga-based open government group is encouraging our city and county to use the [[hListing]] microformat when they implement their online notices. However, we don't feel that "announcement" really covers this category and would like to suggest adding "legal notice" as an option for the action.

			-- [[User:Dryan\|Dryan]] <abbr title="2011-03-03">2011-03-03</abbr>

FineWolf at 17:54, 17 September 2010

2010-09-17T17:54:47Z

← Older revision		Revision as of 17:54, 17 September 2010
Line 266:		Line 266:

	-- [[User:Codeguru413\|Codeguru413]] <abbr title="2010-07-10">2010-07-10</abbr>		-- [[User:Codeguru413\|Codeguru413]] <abbr title="2010-07-10">2010-07-10</abbr>


			== Primary / Secondary hListing ==

			The proposition right now is missing a way to specify which of the [[hListing]] available on a given page is considered as primary. This can become important when thinking about classifieds.

			An ad page may have an [[hListing]] for the product it is representing, but may also have multiple other [[hListing]] in a "Related ads" section. In a scenario like this, a crawler might decide which [[hListing]] to use with heuristics.

			Instead, I propose to introduce the class "primary" to tell crawlers that this particular [[hListing]] is the subject of the page. If no [[hListing]] is listed as "primary", the "primary" [[hListing]] is the first and only [[hListing]] present. If there are other [[hListing]] present and no [[hListing]] listed as "primary", those are considered not to be the subject of the page therefore not listed as such in a search result.

			-- [[User:FineWolf\|FineWolf]] <abbr title="2010-09-17">2010-09-17</abbr>

Codeguru413: /* RE: Item Info */

2010-07-10T20:36:36Z

RE: Item Info

← Older revision		Revision as of 20:36, 10 July 2010
Line 261:		Line 261:
	There is no encoding within the <abbr title="International Standard Book Number">ISBN</abbr> number that accounts for whether a book of a certain title is a softcover or hardcover, rather, merely because they are two separately published items from the same or different publishers, they will have different <abbr title="International Standard Book Number">ISBN</abbr>s. I believe that this is not the only microformat that has this issue. Others may be [[hReview]] and [[hProduct]]. I understand that many listings defer the notion of a unique item identifier; I only wish to raise awareness of the fact that <abbr title="International Standard Book Number">ISBN</abbr> numbers should not be used as a form of unique identification because there is not a 1:1 correspondence between a book title and an <abbr title="International Standard Book Number">ISBN</abbr>. This is especially problematic for [[hReview]] since that microformat is meant for aggregation. It is possible that reviews for a single title will be split across many different <em>books</em>—or <em>products</em>, if you like—even though the books are all the <em>same</em> title, just having different <abbr title="International Standard Book Number">ISBN</abbr>s. This makes it much more difficult to aggregate reviews for such items as books (ahem—or should I say, <em>titles</em> ;) ).		There is no encoding within the <abbr title="International Standard Book Number">ISBN</abbr> number that accounts for whether a book of a certain title is a softcover or hardcover, rather, merely because they are two separately published items from the same or different publishers, they will have different <abbr title="International Standard Book Number">ISBN</abbr>s. I believe that this is not the only microformat that has this issue. Others may be [[hReview]] and [[hProduct]]. I understand that many listings defer the notion of a unique item identifier; I only wish to raise awareness of the fact that <abbr title="International Standard Book Number">ISBN</abbr> numbers should not be used as a form of unique identification because there is not a 1:1 correspondence between a book title and an <abbr title="International Standard Book Number">ISBN</abbr>. This is especially problematic for [[hReview]] since that microformat is meant for aggregation. It is possible that reviews for a single title will be split across many different <em>books</em>—or <em>products</em>, if you like—even though the books are all the <em>same</em> title, just having different <abbr title="International Standard Book Number">ISBN</abbr>s. This makes it much more difficult to aggregate reviews for such items as books (ahem—or should I say, <em>titles</em> ;) ).

	-- [[User:Codeguru413\|Codeguru413]] 2010-07-05		-- [[User:Codeguru413\|Codeguru413]] <abbr title="2010-07-05">2010-07-05</abbr>

	Actually the <abbr title="International Standard Book Number">ISBN</abbr> used as a unique ID debate doesn't really apply to [[hListing]] or [[hProduct]] afterall—at least, not so far as the information pertaining to a book. The use of this microformat is for items for sale. Generally, you will sell a book, not a complete title! Therefore, the <abbr title="International Standard Book Number">ISBN</abbr> is appropriate for this type of microformat. However, reviews included with the [[hListing]] or [[hProduct]] for a book should avoid using the <abbr title="International Standard Book Number">ISBN</abbr> as an identifier per my original comments above. I think I will copy the main part of this comment on over to the appropriate [[hReview]] page where it is more applicable.		Actually the <abbr title="International Standard Book Number">ISBN</abbr> used as a unique ID debate doesn't really apply to [[hListing]] or [[hProduct]] afterall—at least, not so far as the information pertaining to a book. The use of this microformat is for items for sale. Generally, you will sell a book, not a complete title! Therefore, the <abbr title="International Standard Book Number">ISBN</abbr> is appropriate for this type of microformat. However, reviews included with the [[hListing]] or [[hProduct]] for a book should avoid using the <abbr title="International Standard Book Number">ISBN</abbr> as an identifier per my original comments above. I think I will copy the main part of this comment on over to the appropriate [[hReview]] page where it is more applicable.

	-- [[User:Codeguru413\|Codeguru413]] 2010-07-10		-- [[User:Codeguru413\|Codeguru413]] <abbr title="2010-07-10">2010-07-10</abbr>

Codeguru413: /* RE: Item Info */

2010-07-10T17:05:15Z

RE: Item Info

← Older revision		Revision as of 17:05, 10 July 2010
Line 261:		Line 261:
	There is no encoding within the <abbr title="International Standard Book Number">ISBN</abbr> number that accounts for whether a book of a certain title is a softcover or hardcover, rather, merely because they are two separately published items from the same or different publishers, they will have different <abbr title="International Standard Book Number">ISBN</abbr>s. I believe that this is not the only microformat that has this issue. Others may be [[hReview]] and [[hProduct]]. I understand that many listings defer the notion of a unique item identifier; I only wish to raise awareness of the fact that <abbr title="International Standard Book Number">ISBN</abbr> numbers should not be used as a form of unique identification because there is not a 1:1 correspondence between a book title and an <abbr title="International Standard Book Number">ISBN</abbr>. This is especially problematic for [[hReview]] since that microformat is meant for aggregation. It is possible that reviews for a single title will be split across many different <em>books</em>—or <em>products</em>, if you like—even though the books are all the <em>same</em> title, just having different <abbr title="International Standard Book Number">ISBN</abbr>s. This makes it much more difficult to aggregate reviews for such items as books (ahem—or should I say, <em>titles</em> ;) ).		There is no encoding within the <abbr title="International Standard Book Number">ISBN</abbr> number that accounts for whether a book of a certain title is a softcover or hardcover, rather, merely because they are two separately published items from the same or different publishers, they will have different <abbr title="International Standard Book Number">ISBN</abbr>s. I believe that this is not the only microformat that has this issue. Others may be [[hReview]] and [[hProduct]]. I understand that many listings defer the notion of a unique item identifier; I only wish to raise awareness of the fact that <abbr title="International Standard Book Number">ISBN</abbr> numbers should not be used as a form of unique identification because there is not a 1:1 correspondence between a book title and an <abbr title="International Standard Book Number">ISBN</abbr>. This is especially problematic for [[hReview]] since that microformat is meant for aggregation. It is possible that reviews for a single title will be split across many different <em>books</em>—or <em>products</em>, if you like—even though the books are all the <em>same</em> title, just having different <abbr title="International Standard Book Number">ISBN</abbr>s. This makes it much more difficult to aggregate reviews for such items as books (ahem—or should I say, <em>titles</em> ;) ).

	-- ~~<span class="vcard"><span class="fn">~~[~~http~~:~~//discoveringcode.blogspot.com <span class="url">codeguru413</span>~~]~~</span></span>~~ 2010-07-05		-- [[User:Codeguru413\|Codeguru413]] 2010-07-05

	Actually the <abbr title="International Standard Book Number">ISBN</abbr> used as a unique ID debate doesn't really apply to [[hListing]] or [[hProduct]] afterall—at least, not so far as the information pertaining to a book. The use of this microformat is for items for sale. Generally, you will sell a book, not a complete title! Therefore, the <abbr title="International Standard Book Number">ISBN</abbr> is appropriate for this type of microformat. However, reviews included with the [[hListing]] or [[hProduct]] for a book should avoid using the <abbr title="International Standard Book Number">ISBN</abbr> as an identifier per my original comments above. I think I will copy the main part of this comment on over to the appropriate [[hReview]] page where it is more applicable.		Actually the <abbr title="International Standard Book Number">ISBN</abbr> used as a unique ID debate doesn't really apply to [[hListing]] or [[hProduct]] afterall—at least, not so far as the information pertaining to a book. The use of this microformat is for items for sale. Generally, you will sell a book, not a complete title! Therefore, the <abbr title="International Standard Book Number">ISBN</abbr> is appropriate for this type of microformat. However, reviews included with the [[hListing]] or [[hProduct]] for a book should avoid using the <abbr title="International Standard Book Number">ISBN</abbr> as an identifier per my original comments above. I think I will copy the main part of this comment on over to the appropriate [[hReview]] page where it is more applicable.

	-- ~~<span class="vcard"><span class="fn">~~[~~http~~:~~//discoveringcode.blogspot.com <span class="url">codeguru413</span>~~]~~</span></span>~~ 2010-07-10		-- [[User:Codeguru413\|Codeguru413]] 2010-07-10

Codeguru413: /* RE: Item Info */

2010-07-10T17:03:28Z

RE: Item Info

← Older revision		Revision as of 17:03, 10 July 2010
Line 257:		Line 257:

	== RE: Item Info ==		== RE: Item Info ==
	As I was reading the draft spec, I came across ~~this~~ in the definition of the item info portion of hListing: "Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN ("url") for the item." If you look at [http://www.isbn.org ISBN.org]'s website, they warn strongly against using ~~ISBNs~~ as unique IDs because often times, a book with the same title may have different ~~ISBNs~~. Often, when we think of a book, what we really mean is a title. A book is just a particular publication of a title. As we know, books for a title can come in many different formats: softcover, hardcover, large print, illustrated, etc. Each publication will have a different ISBN.		As I was reading the draft spec, I came across the following in the definition of the item info portion of [[hListing]]: <i>"Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN ("url") for the item."</i> If you look at [http://www.isbn.org ISBN.org]'s website, they warn strongly against using <abbr title="International Standard Book Number">ISBN</abbr>s as unique IDs because often times, a book with the <em><strong>same title</strong></em> may have <em><strong>different</strong></em> <abbr title="International Standard Book Number">ISBN</abbr>s. Often, when we think of a book, what we really mean is a title. A book is just a particular publication of a title. As we know, books for a title can come in many different formats: softcover, hardcover, large print, illustrated, etc. Each publication will have a different <abbr title="International Standard Book Number">ISBN</abbr>.

	There is no encoding within the ISBN number that accounts for whether a book of a certain title is a softcover or hardcover, rather, merely because they are two separately published items from the same ~~publisher~~, they will have different ISBNs. In addition, perhaps a later printing is printed by another publishing company that subsumed the original publishing company. The reprint will definitely have a different ISBN in this case (since ISBN ~~numbers are tied to publishers)~~. I believe that this is not the only microformat that has this issue. Others may be hReview and hProduct. I understand that many listings defer the notion of a unique item identifier; I only wish to raise awareness of the fact that ISBN numbers should not be used as a form of unique identification because there is not a 1:1 correspondence between a book title and an ISBN. This is especially problematic for hReview since that microformat is meant for aggregation. It is possible that reviews for a single title will be split across many different "books~~"--~~or "products", if you like--even though the books are all the same title, just having different ~~ISBNs~~. This makes it much more difficult to aggregate reviews for such items as books (or~~--ahem,~~ should I say, titles ;) ).		There is no encoding within the <abbr title="International Standard Book Number">ISBN</abbr> number that accounts for whether a book of a certain title is a softcover or hardcover, rather, merely because they are two separately published items from the same or different publishers, they will have different <abbr title="International Standard Book Number">ISBN</abbr>s. I believe that this is not the only microformat that has this issue. Others may be [[hReview]] and [[hProduct]]. I understand that many listings defer the notion of a unique item identifier; I only wish to raise awareness of the fact that <abbr title="International Standard Book Number">ISBN</abbr> numbers should not be used as a form of unique identification because there is not a 1:1 correspondence between a book title and an <abbr title="International Standard Book Number">ISBN</abbr>. This is especially problematic for [[hReview]] since that microformat is meant for aggregation. It is possible that reviews for a single title will be split across many different <em>books</em>—or <em>products</em>, if you like—even though the books are all the <em>same</em> title, just having different <abbr title="International Standard Book Number">ISBN</abbr>s. This makes it much more difficult to aggregate reviews for such items as books (ahem—or should I say, <em>titles</em> ;) ).

	-- codeguru413 2010-07-05		-- <span class="vcard"><span class="fn">[http://discoveringcode.blogspot.com <span class="url">codeguru413</span>]</span></span> 2010-07-05

	Actually the ISBN used as a unique ID debate doesn't really apply to hListing afterall. The use of this microformat is for items for sale. Generally, you will sell a book, not a complete title! Therefore, the ISBN is appropriate. However, I think I will copy the main part of this comment on over to the hReview page where it is more applicable ~~since a review (for a "book"), typically, is on the title itself, and not on the particular book of the title~~.		Actually the <abbr title="International Standard Book Number">ISBN</abbr> used as a unique ID debate doesn't really apply to [[hListing]] or [[hProduct]] afterall—at least, not so far as the information pertaining to a book. The use of this microformat is for items for sale. Generally, you will sell a book, not a complete title! Therefore, the <abbr title="International Standard Book Number">ISBN</abbr> is appropriate for this type of microformat. However, reviews included with the [[hListing]] or [[hProduct]] for a book should avoid using the <abbr title="International Standard Book Number">ISBN</abbr> as an identifier per my original comments above. I think I will copy the main part of this comment on over to the appropriate [[hReview]] page where it is more applicable.

	-- codeguru413 2010-07-10		-- <span class="vcard"><span class="fn">[http://discoveringcode.blogspot.com <span class="url">codeguru413</span>]</span></span> 2010-07-10

Codeguru413: /* RE: Item Info */

2010-07-10T14:09:41Z

RE: Item Info

← Older revision		Revision as of 14:09, 10 July 2010
Line 262:		Line 262:

	-- codeguru413 2010-07-05		-- codeguru413 2010-07-05

			Actually the ISBN used as a unique ID debate doesn't really apply to hListing afterall. The use of this microformat is for items for sale. Generally, you will sell a book, not a complete title! Therefore, the ISBN is appropriate. However, I think I will copy the main part of this comment on over to the hReview page where it is more applicable since a review (for a "book"), typically, is on the title itself, and not on the particular book of the title.

			-- codeguru413 2010-07-10

Codeguru413: Added issue for item info

2010-07-06T01:56:33Z

Added issue for item info

← Older revision		Revision as of 01:56, 6 July 2010
Line 255:		Line 255:

	-- [[MicroAngelo]] 2009-01-15		-- [[MicroAngelo]] 2009-01-15

			== RE: Item Info ==
			As I was reading the draft spec, I came across this in the definition of the item info portion of hListing: "Unique item IDs (e.g. ISBNs, UPCs) MAY be represented as a URN ("url") for the item." If you look at [http://www.isbn.org ISBN.org]'s website, they warn strongly against using ISBNs as unique IDs because often times, a book with the same title may have different ISBNs. Often, when we think of a book, what we really mean is a title. A book is just a particular publication of a title. As we know, books for a title can come in many different formats: softcover, hardcover, large print, illustrated, etc. Each publication will have a different ISBN.

			There is no encoding within the ISBN number that accounts for whether a book of a certain title is a softcover or hardcover, rather, merely because they are two separately published items from the same publisher, they will have different ISBNs. In addition, perhaps a later printing is printed by another publishing company that subsumed the original publishing company. The reprint will definitely have a different ISBN in this case (since ISBN numbers are tied to publishers). I believe that this is not the only microformat that has this issue. Others may be hReview and hProduct. I understand that many listings defer the notion of a unique item identifier; I only wish to raise awareness of the fact that ISBN numbers should not be used as a form of unique identification because there is not a 1:1 correspondence between a book title and an ISBN. This is especially problematic for hReview since that microformat is meant for aggregation. It is possible that reviews for a single title will be split across many different "books"--or "products", if you like--even though the books are all the same title, just having different ISBNs. This makes it much more difficult to aggregate reviews for such items as books (or--ahem, should I say, titles ;) ).

			-- codeguru413 2010-07-05

MicroAngelo: /* Validator */ Blogmatrix appear defunct

2010-01-15T10:59:02Z

Validator: Blogmatrix appear defunct

← Older revision		Revision as of 10:59, 15 January 2010
Line 205:		Line 205:
	Perhaps to foster development of this type, someone (who knows a lot more about microformats than I) should put a validator type page out there. I realize that microformats, by their nature are a loose specification (it's not as strict as validating say an XML rss feed). But having something that I can use to at least verify that what I'm coding is actually recognized as an hListing by someone other than myself would be very helpful.		Perhaps to foster development of this type, someone (who knows a lot more about microformats than I) should put a validator type page out there. I realize that microformats, by their nature are a loose specification (it's not as strict as validating say an XML rss feed). But having something that I can use to at least verify that what I'm coding is actually recognized as an hListing by someone other than myself would be very helpful.
	-Andrew		-Andrew


	~~Blogmatrix have added hListing to their microformats parser [http://tools.blogmatrix.com/extract/ here]~~
	~~-d4rr3ll~~

	== Extraction of hProduct ==		== Extraction of hProduct ==

MicroAngelo: Question: How to deal with Availability Calendars for the Rental hListing scenario

2010-01-15T10:56:26Z

Question: How to deal with Availability Calendars for the Rental hListing scenario

← Older revision		Revision as of 10:56, 15 January 2010
Line 249:		Line 249:

	-- Michael Specht		-- Michael Specht

			== Ongoing Rental Availability Calendar ==

			Renting is a very common activity addressed by this microformat, and it appears to deal with it very well. However, I was wondering what is the correct way of marking up a common web element: an availability calendar? Say we have the month of February 2010 available, then that's quite easy: a single hListing from start to end. Then if someone books the second week: do we then have 3 hListings (1st week as free, 2nd week as booked, 3rd-4th weeks joined as free)?

			All 3 must be marked up with dtlisted as the day that they were created, the free chunks will have dtexpired set to the day that they begin (or end if you're happy to rent after the chunk has begun), and the taken week will have dtexpired as the day it was booked. However that leaves no room for the actual date data of the dates available for rent - surely a very common way of renting things (cars, accommodation, private jets etc.). Should we be using an hEvent inside the hListing (or vice versa)?

			It might make some sense to "chunk up" the dates that you will rent by, e.g. property is often rented on a whole weekly basis, and you could then have an hEvent for each "chunk". However things like cars and private jets are often rented by the day or hour... making the hEvent "chunks" seem prohibitively numerous. It would seem like we need an extra "period" property for hListing Rentals (e.g. weekly for apartments, daily for cars) and then have the smallest number of hListing-hEvent combos required to describe the current availability. This would allow for hEvents to cover multiple "periods" available for rent (e.g. the 3rd and 4th weeks from my original February 2010 example combined) while still allowing consuming systems to show that you can rent one or more of these periods without having to book the entire time covered by the hEvent. Or is there a better way?

			-- [[MicroAngelo]] 2009-01-15