cnaroda
== Schema Issues ==

=== Item ===

* is class="item" a part of the spec? It is not clear from the highlight in the proposal.
* if it is, is it optional (as in the [[hlisting-proposal#Schema|schema]]) or required (as implied by the item [[hlisting-proposal#Item_Metadata|item metadata]] section). My feeling is that it should be required

-- [[DavidJanes]] 2006-11-18

=== Listing Action ===

* "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

-- [[BrianSuda]] 2006-11-18

=== Make Info/Photo fields Optional ===

WordPress has a great WYSIWYG editor that lets you drag & drop images.
But the only semantic identification it uses is the HTML <img> element.
So how do we get a photo to be identified from all the images inside the description?

1. Manually edit the HTML that WordPress creates to add the class.
2. Add another UI doubling the one already used by WordPress, sans drag & drop, strictly for images designated as photos.
3. Tag every single image as photo.
4. Have the crawler interpret every single image as photo.

I'm not sure we want to push the complexity to the edge, that's like asking people to create only valid XHTML pages and not rendering anything that refuses to validate. This is about humans first, machines second. If complexity needs to exist, it should be not in the blog, but in the crawlers.

-- Assaf Arkin

== Default Action ==
I think it's good form to have a default for every required field, since someone out there is going to drop any given requried field in the land of microformats. In that spirit, the default for listing type is offer, since wanted ads are << 10% in the real world. What I don't know is what the default action should be; the most neutral of them is ''announce'', which I am using in my parser.

-- Rohit

== Donations ==

Sell and Rent are obvious enough verbs; what does Trade mean, though? Barter? And what about one-sided gifts, like donations or "free to recycle"? Should we replace Trade and offer Donate in its place?

-- Rohit

== Desire to Inherit Context ==

When it comes to blog posting, Iâd like to see us address the following:

1. '''Less is more'''. Or in reverse, people are lazy, and the less fields they need to fill in order to sell a couch or find a date, the more they'll use the plugin. So I'm trying to visualize how this plays in with the user interface and how we can keep it as simple as possible.

2. '''DRY'''. We want to capture as much information as possible from what is already available in the blog post. We already have summary (title), listing date/time (post date/time), permalink, author information, tags/categories.

3. '''Keep it simple'''. And here I'm talking about setup and being able to extend your blog's functionality without too much fuss. This one is a bit more tricky, so I'll go into details.

WordPress uses templates to render the blog post. The template then calls the WordPress API to render the title, a second call to render the content, and another call to render any additional metadata (e.g.
publish date, categories, author). These separate calls allow people to play with the formatting and apply any styling they like.

The way uPress works, is by processing the blog post before it goes back to the filter, creating the hEvent (to be: hListing) element around it, and adding any relevant fields into the blog post. So what you fill in the form, finds its way to the post content. As a result, setting up the plugin requires two steps: drop it to the plugins directory, and activate.

Unfortunately, I only get to process the content of the post. I can't easily include the title inside the hListing element, or any other metadata about the post, even though I have access to it. If I duplicate that information, the post stops being readable. And to wrap the entire post (not just body) inside a microformat element, I need to tweak the template. Except people use different templates, and I can't tweak all of them.

So the more context we use, the better the plugin becomes.

-- Assaf Arkin

== '''On hReview''' ==

This draft was heavily influenced by hReview. That's a good thing. We donât want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.

But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.

We want to appeal to the wide populace of bloggers who just want to get stuff done. Rather than put the burden on millions of bloggers out there, we should place the burden on the few companies developing crawlers.

What would Tantek say? I think he'd ask us to focus on use cases, real examples. I'm presenting one such example. The use case involves a blogger who just wants to sell something on their blog, with the minimum amount of effort and cognitive friction. They want the listing to be discovered, aggregated and searched by others.

-- Assaf Arkin

== '''Neighborhood Name''' ==

With the exception of housing, most classified listings donât contain a specific address (e.g., if Iâm selling my couch, you donât need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).

This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)

-- Craig Donato & Assaf Arkin

== '''Listing Action, Listing Type, Item Type''' ==

We heavily debated how to classify a listing. Search engines or marketplaces typically need to understand what type of listing it is (e.g., personal ad, house for sale, music) to effectively reference or index a listing.

We initially considered proposing a single category field that contained tags (in addition to the tags field). Not only did this seem duplicative, it also seemed like too much of a good thing. In a previous project, Assaf managed to successfully overload everything into tags (including dates and locations), and run time-based and location-based searches, and ended up concluding it's a bad idea.

We eventually decided to propose the use three parametric field that when used together could define any type of listing independent of the words use to describe. These ended up being: listing-type (are you offering something or looking for something; listing-action (are you trying to sell, rent, or announce something); and item type (what item is referenced by the action such as a job opening, product, housing). By making small modifications to this vocabulary, users can specify an extremely wide range of potential transactions. This seemed more feasible given that the UI used to produce the hListing could abstract some of this from the user (as Assaf demonstrated in his demo plugin).

For example:

{|
!Desired Transaction
!Listing Type
!Listing Action
!Item Type
|-
|Merchandise For Sale
|Offer
|Sell
|Product
|-
|Looking to Buy Merchandise
|Wanted
|Sell
|Product
|-
|Selling Tickets
|Offer
|Sell
|Event
|-
|Apartment For Rent
|Offer
|Rent
|Housing
|-
|Looking for Apartment
|Wanted
|Rent
|Housing
|-
|Room for Rent (Roommate)
|Offer
|Rent
|Housing
|-
|Looking for a Date
|Offer||Wanted
|Announce, Meet
|-
|Job Opening
|Offer
|Announce
|Opening
|-
|Looking for a Job (Resume)
|Wanted
|Announce
|Opening
|-
|Music Lessons
|Offer
|Service
|Business
|-
|Trade Couch for TV
|Offer
|Trade
|Product
|-
|Pet for Adoption
|Offer
|Announce
|Animal?
|}
-- Craig Donato

== Vertical ==
Adding "vertical" to the schema would take this idea a lot further and would add enough flexibility to kill off the need for further formats like hJob etc. Specific verticals could be set (jobs, real estate, rentals, auto, other) with additional fields added as subsets of each vertical.

* vertical: rentals
* listing type: offer
* item type: house (vs. appartment)
* listing action: rent

-- [[User:AaronMentele|Aaron Mentele]] (2006-12-26)

== Eliminate Item Type ==

Can we eliminate item type and simply use tags? Or perhaps inferred item type from the item info?

== hClassified? ==

There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station?

== What about retail? ==

Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?

== Retail ==

Funnily enough, hProduct is always something that I've thought about.

I'd be bold enough to say that it will be one of the main uses of microformats in the future. Imagine the amount of shops, price comparison, product review and many more type of sites. It doesn't have to be for profit, it could just be someones product, on their site, that they are displaying.

I'd be willing to help and continue development of a spec for 'hProduct'.

Adam Craven

== Thubnail Class ==
Hello. I'm not sure I understand everything correctly, but from reading the hListing proposal it seems that one should put pictures of the listed subject into the "photo" class. I'm wondering if also we may wish to have a "thumnail" class or perhaps something like "photo-thumbnail" to denote thumbnail images.
-Andrew

== Validator ==
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

== Extraction of hProduct ==

I think it would be wise to extract product information into [[hproduct|hProduct]] and simply maintain the listing for listing-specific data (such as actual price/suggested price, location, timeframe, etc.).

Also, regarding price, I think going with the currency microformat makes sense, but I also think there should be specifics around the type of price being shown. For instance, there is a MSRP which is tied to the product (and ''should'' be in hProduct), then there is the asking price (or in the case of cars, the dealer invoice, sticker price, etc.). Perhaps going the route of

<pre><nowiki>
<abbr class="currency" title="USD">$</abbr>3.00
</nowiki></pre>

would make more sense?
- Aaron Gustafson

== Use for Microphilanthropy and Volunteer listings ==

Adding 'Donate', as Rohit suggested, would open up hListing for use by microphilanthropy sites like www.Kiva.org or www.DonorsChoose.org (I work there.) See here for an example of one of our listings:

http://www.donorschoose.org/donors/proposal.html?id=64964

So an organization seeking a donation would format it Listing Type: Wanted, Listing Action: Donate, Listing Item: Cash

Someone looking to donate an old PC would format it Listing Type: Offer, Listing Action: Donate, Listing Item: Product

An organization trying to find a volunteer would have Listing Type: Wanted, Listing Action: Donate, Listing Item: Service

Note that some organizations (like Kiva) are doing microloans, instead of microphilanthropy. So in addition to Sell, Rent, Trade, Meet, Announce, and Donate, "Loan" would be useful as a Listing Action. (Could also be useful for facilitating borrowing relationships of items.)

One other addition to hListing that might be useful in this context is Cost. In a commercial setting (say, you're trying to sell a used item on eBay), Cost would represent what you paid for the item. So Price - Cost would get you the markup (or markdown). In a philanthropic context, Cost would represent the cost to make a project happen. If the project were already partially funded, then Price < Cost, and Price / Cost would give you the % remaining to completely fund that project. (Many microphilanthropy sites bundle lots of donations to make up one project.)

-- Mike Everett-Lane

== Job listings ==

The discussion over on the [http://microformats.org/wiki/job-listing-brainstorming Job Listing microformat page] discusses the possibility of using the hlisting format instead of creating a new format.

While jobs can be described using Listing Type="Offer", Listing Action = "Announce" and Item Type ="Opening". Additional mark ups are required to meet the basic job board usages. For example Australian job boards all have Industries, Salary ranges, types of jobs, and a URL for the application. Being able to incorporate these key elements into the hlisting spec would be great.

-- 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

== 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

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

hlisting-feedback

2010-07-06T01:56:33Z

Codeguru413: Added issue for item info

cnaroda
== Schema Issues ==

=== Item ===

* is class="item" a part of the spec? It is not clear from the highlight in the proposal.
* if it is, is it optional (as in the [[hlisting-proposal#Schema|schema]]) or required (as implied by the item [[hlisting-proposal#Item_Metadata|item metadata]] section). My feeling is that it should be required

-- [[DavidJanes]] 2006-11-18

=== Listing Action ===

* "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

-- [[BrianSuda]] 2006-11-18

=== Make Info/Photo fields Optional ===

WordPress has a great WYSIWYG editor that lets you drag & drop images.
But the only semantic identification it uses is the HTML <img> element.
So how do we get a photo to be identified from all the images inside the description?

1. Manually edit the HTML that WordPress creates to add the class.
2. Add another UI doubling the one already used by WordPress, sans drag & drop, strictly for images designated as photos.
3. Tag every single image as photo.
4. Have the crawler interpret every single image as photo.

I'm not sure we want to push the complexity to the edge, that's like asking people to create only valid XHTML pages and not rendering anything that refuses to validate. This is about humans first, machines second. If complexity needs to exist, it should be not in the blog, but in the crawlers.

-- Assaf Arkin

== Default Action ==
I think it's good form to have a default for every required field, since someone out there is going to drop any given requried field in the land of microformats. In that spirit, the default for listing type is offer, since wanted ads are << 10% in the real world. What I don't know is what the default action should be; the most neutral of them is ''announce'', which I am using in my parser.

-- Rohit

== Donations ==

Sell and Rent are obvious enough verbs; what does Trade mean, though? Barter? And what about one-sided gifts, like donations or "free to recycle"? Should we replace Trade and offer Donate in its place?

-- Rohit

== Desire to Inherit Context ==

When it comes to blog posting, Iâd like to see us address the following:

1. '''Less is more'''. Or in reverse, people are lazy, and the less fields they need to fill in order to sell a couch or find a date, the more they'll use the plugin. So I'm trying to visualize how this plays in with the user interface and how we can keep it as simple as possible.

2. '''DRY'''. We want to capture as much information as possible from what is already available in the blog post. We already have summary (title), listing date/time (post date/time), permalink, author information, tags/categories.

3. '''Keep it simple'''. And here I'm talking about setup and being able to extend your blog's functionality without too much fuss. This one is a bit more tricky, so I'll go into details.

WordPress uses templates to render the blog post. The template then calls the WordPress API to render the title, a second call to render the content, and another call to render any additional metadata (e.g.
publish date, categories, author). These separate calls allow people to play with the formatting and apply any styling they like.

The way uPress works, is by processing the blog post before it goes back to the filter, creating the hEvent (to be: hListing) element around it, and adding any relevant fields into the blog post. So what you fill in the form, finds its way to the post content. As a result, setting up the plugin requires two steps: drop it to the plugins directory, and activate.

Unfortunately, I only get to process the content of the post. I can't easily include the title inside the hListing element, or any other metadata about the post, even though I have access to it. If I duplicate that information, the post stops being readable. And to wrap the entire post (not just body) inside a microformat element, I need to tweak the template. Except people use different templates, and I can't tweak all of them.

So the more context we use, the better the plugin becomes.

-- Assaf Arkin

== '''On hReview''' ==

This draft was heavily influenced by hReview. That's a good thing. We donât want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.

But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.

We want to appeal to the wide populace of bloggers who just want to get stuff done. Rather than put the burden on millions of bloggers out there, we should place the burden on the few companies developing crawlers.

What would Tantek say? I think he'd ask us to focus on use cases, real examples. I'm presenting one such example. The use case involves a blogger who just wants to sell something on their blog, with the minimum amount of effort and cognitive friction. They want the listing to be discovered, aggregated and searched by others.

-- Assaf Arkin

== '''Neighborhood Name''' ==

With the exception of housing, most classified listings donât contain a specific address (e.g., if Iâm selling my couch, you donât need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).

This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)

-- Craig Donato & Assaf Arkin

== '''Listing Action, Listing Type, Item Type''' ==

We heavily debated how to classify a listing. Search engines or marketplaces typically need to understand what type of listing it is (e.g., personal ad, house for sale, music) to effectively reference or index a listing.

We initially considered proposing a single category field that contained tags (in addition to the tags field). Not only did this seem duplicative, it also seemed like too much of a good thing. In a previous project, Assaf managed to successfully overload everything into tags (including dates and locations), and run time-based and location-based searches, and ended up concluding it's a bad idea.

We eventually decided to propose the use three parametric field that when used together could define any type of listing independent of the words use to describe. These ended up being: listing-type (are you offering something or looking for something; listing-action (are you trying to sell, rent, or announce something); and item type (what item is referenced by the action such as a job opening, product, housing). By making small modifications to this vocabulary, users can specify an extremely wide range of potential transactions. This seemed more feasible given that the UI used to produce the hListing could abstract some of this from the user (as Assaf demonstrated in his demo plugin).

For example:

{|
!Desired Transaction
!Listing Type
!Listing Action
!Item Type
|-
|Merchandise For Sale
|Offer
|Sell
|Product
|-
|Looking to Buy Merchandise
|Wanted
|Sell
|Product
|-
|Selling Tickets
|Offer
|Sell
|Event
|-
|Apartment For Rent
|Offer
|Rent
|Housing
|-
|Looking for Apartment
|Wanted
|Rent
|Housing
|-
|Room for Rent (Roommate)
|Offer
|Rent
|Housing
|-
|Looking for a Date
|Offer||Wanted
|Announce, Meet
|-
|Job Opening
|Offer
|Announce
|Opening
|-
|Looking for a Job (Resume)
|Wanted
|Announce
|Opening
|-
|Music Lessons
|Offer
|Service
|Business
|-
|Trade Couch for TV
|Offer
|Trade
|Product
|-
|Pet for Adoption
|Offer
|Announce
|Animal?
|}
-- Craig Donato

== Vertical ==
Adding "vertical" to the schema would take this idea a lot further and would add enough flexibility to kill off the need for further formats like hJob etc. Specific verticals could be set (jobs, real estate, rentals, auto, other) with additional fields added as subsets of each vertical.

* vertical: rentals
* listing type: offer
* item type: house (vs. appartment)
* listing action: rent

-- [[User:AaronMentele|Aaron Mentele]] (2006-12-26)

== Eliminate Item Type ==

Can we eliminate item type and simply use tags? Or perhaps inferred item type from the item info?

== hClassified? ==

There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station?

== What about retail? ==

Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?

== Retail ==

Funnily enough, hProduct is always something that I've thought about.

I'd be bold enough to say that it will be one of the main uses of microformats in the future. Imagine the amount of shops, price comparison, product review and many more type of sites. It doesn't have to be for profit, it could just be someones product, on their site, that they are displaying.

I'd be willing to help and continue development of a spec for 'hProduct'.

Adam Craven

== Thubnail Class ==
Hello. I'm not sure I understand everything correctly, but from reading the hListing proposal it seems that one should put pictures of the listed subject into the "photo" class. I'm wondering if also we may wish to have a "thumnail" class or perhaps something like "photo-thumbnail" to denote thumbnail images.
-Andrew

== Validator ==
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

== Extraction of hProduct ==

I think it would be wise to extract product information into [[hproduct|hProduct]] and simply maintain the listing for listing-specific data (such as actual price/suggested price, location, timeframe, etc.).

Also, regarding price, I think going with the currency microformat makes sense, but I also think there should be specifics around the type of price being shown. For instance, there is a MSRP which is tied to the product (and ''should'' be in hProduct), then there is the asking price (or in the case of cars, the dealer invoice, sticker price, etc.). Perhaps going the route of

<pre><nowiki>
<abbr class="currency" title="USD">$</abbr>3.00
</nowiki></pre>

would make more sense?
- Aaron Gustafson

== Use for Microphilanthropy and Volunteer listings ==

Adding 'Donate', as Rohit suggested, would open up hListing for use by microphilanthropy sites like www.Kiva.org or www.DonorsChoose.org (I work there.) See here for an example of one of our listings:

http://www.donorschoose.org/donors/proposal.html?id=64964

So an organization seeking a donation would format it Listing Type: Wanted, Listing Action: Donate, Listing Item: Cash

Someone looking to donate an old PC would format it Listing Type: Offer, Listing Action: Donate, Listing Item: Product

An organization trying to find a volunteer would have Listing Type: Wanted, Listing Action: Donate, Listing Item: Service

Note that some organizations (like Kiva) are doing microloans, instead of microphilanthropy. So in addition to Sell, Rent, Trade, Meet, Announce, and Donate, "Loan" would be useful as a Listing Action. (Could also be useful for facilitating borrowing relationships of items.)

One other addition to hListing that might be useful in this context is Cost. In a commercial setting (say, you're trying to sell a used item on eBay), Cost would represent what you paid for the item. So Price - Cost would get you the markup (or markdown). In a philanthropic context, Cost would represent the cost to make a project happen. If the project were already partially funded, then Price < Cost, and Price / Cost would give you the % remaining to completely fund that project. (Many microphilanthropy sites bundle lots of donations to make up one project.)

-- Mike Everett-Lane

== Job listings ==

The discussion over on the [http://microformats.org/wiki/job-listing-brainstorming Job Listing microformat page] discusses the possibility of using the hlisting format instead of creating a new format.

While jobs can be described using Listing Type="Offer", Listing Action = "Announce" and Item Type ="Opening". Additional mark ups are required to meet the basic job board usages. For example Australian job boards all have Industries, Salary ranges, types of jobs, and a URL for the application. Being able to incorporate these key elements into the hlisting spec would be great.

-- 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

== 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