m |
m |
| Line 2: |
Line 2: |
| | | | |
| | ==Some initial thoughts== | | ==Some initial thoughts== |
| - | * The format should at is most basic be easily implemented by current listing sites without having to modify their existing setups (ie: tinkering with their SQL). For example: http://www.villagevoice.com/classifieds/index.php?page=ads&category=Employment&sort=1&database=0&a=0&class=4025 has a very simple data structure, one can imagine this simple data structure coming from an SQL database. If they need to alter their SQL to adapt to the microformat it will not be adopted (or at least not quickly). Ideally all it would took for current sites to adopt it is just a redesign. | + | * The format should at is most basic be easily implemented by current listing sites without having to modify their existing setups (ie: tinkering with their SQL). For example: http://www.villagevoice.com/classifieds/index.php?page=ads |
| - | * The format should be extendable enough to allow for specific data to be extracted from it so that specialized services ( format specific aggregators, social aggregators, collaborative filtering, discovery agents ) could be built on top of it.
| + | |
| - | * The format should be flexible enough to be easily added to current CMS and blogging systems.
| + | |
| - | * The format should be flexible enough to not interfeer with existing business models of stablished web based listing sites. For example a Job Listings site may get revenue from commissions on actual prospects found and contracted through their site. If the actual way of contacting the prospect is required in the format (rather than a link to the actual listing on their site), they might be weary of implementing the microformat (since it would take them out the loop, so to say). A similar argument could be made for other types of listings sites. However if they can implement a simple data structure that can then be traced to their sites, they would probably implement it since it would help in the discovery process of their listings (through aggregators or crawlers).
| + | |
| - | | + | |
| - | == A Basic Data Structure ==
| + | |
| - | * At its most basic web based listing schemas could be narrowed to:
| + | |
| - | ** name of the item
| + | |
| - | ** description (Some sites don´t even seem to have Title)
| + | |
| - | ** listing date
| + | |
| - | ** contact info. (hCard might be used for this)
| + | |
| - | * Contextual or Implied Info.
| + | |
| - | ** Regardless of the actual schemas that can be extracted from the html pages there is some information that is implied either contextually or by navigation in all of the examples found. For Example:
| + | |
| - | *** A listing on ebay.de implies ( contextually ) that the actual location of the listing in itself is in the country of Germany. Other examples: paris.craiglists.org, a classified ad on nytimes.com or (NY) globo.com.br (Brazil) or www.timeout.com (London).
| + | |
| - | *** A category or "Type" of the listing in itself is generally implied by navigation through the sites. For example: When accesing craiglist.org one chooses the type of listing one wants to see ( housing > housing wanted ). Some sites have specialized data structures depending on the type of listing (For example, it´s fairly common for Vehicles for sale to have a field for brand, model, year.)
| + | |
| - | ** This suggests that location and type should be included in the base format. (Deciding on this may be quite tricky. Particullarly Types, since locations can be extracted from Contact. )
| + | |
| - | | + | |
| - | == Extending the Base Structure By Listing Type==
| + | |
| - | * Once a basic format is decided, it could be extended to more specific types of data structures.
| + | |
| - | ** Type For Sale
| + | |
| - | *** Base
| + | |
| - | **** title could map to product name. (This mapping thing is just an idea, but it seems to be fairly common)
| + | |
| - | **** description could map to product description.
| + | |
| - | **** product category (may be part of the basic format category. No idea how to go with this.)
| + | |
| - | **** product condition (Used|New)
| + | |
| - | *** Optional
| + | |
| - | **** price ammount
| + | |
| - | **** price currency (currency is either specified or implied contextually when naming a Price. A price could be considered an specific ammount of an specific currency.)
| + | |
| - | **** photo (Optional, might be more than one *)
| + | |
| - | **** duration or expiry date of the offer.
| + | |
| - | **** availability (If there is more than one for sale, or even none.)
| + | |
| - | ** Type For Sale, Product Category = vehicle (May extend for sale)
| + | |
| - | *** brand
| + | |
| - | *** model
| + | |
| - | *** year
| + | |
| - | ** Type Wanted
| + | |
| - | *** title could map to product name.
| + | |
| - | *** description could map to product description.
| + | |
| - | *** duration or expiry date.
| + | |
| - | ** Type Job Offer
| + | |
| - | *** title could map to job category (seems to be a common practice)
| + | |
| - | *** description could map to job description
| + | |
| - | *** requirements
| + | |
| - | *** contract type (part time| full time | temp)
| + | |
| - | *** contact could map to company or recruiter
| + | |
| - | | + | |
| - | * More extended types should be considered...
| + | |
| - | | + | |
| - | == See Also ==
| + | |
| - | * [[listing-examples]]
| + | |
| - | * [[listing-brainstorming]]
| + | |
| - | * [[listing-formats]]
| + | |
