listing-brainstorming - Revision history

Brian: Reverted edits by RactrCnali (Talk) to last version by ChristopheDucamp

2008-12-20T18:19:23Z

Reverted edits by RactrCnali (Talk) to last version by ChristopheDucamp

← Older revision		Revision as of 18:19, 20 December 2008
Line 1:		Line 1:
	~~relnopa~~
	=Listing Brainstorming=		=Listing Brainstorming=

Line 11:		Line 10:
	* At its most basic web based listing schemas could be narrowed to:		* At its most basic web based listing schemas could be narrowed to:
	** name of the item		** name of the item
	** description (Some sites ~~donÂ´t~~ even seem to have Title)		** description (Some sites don´t even seem to have Title)
	** listing date		** listing date
	** contact info. (hCard might be used for this)		** contact info. (hCard might be used for this)
Line 17:		Line 16:
	** 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:		** 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 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.)		*** 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. )		** 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. )

RactrCnali: acmonn

2008-12-19T20:21:14Z

acmonn

← Older revision		Revision as of 20:21, 19 December 2008
Line 1:		Line 1:
			relnopa
	=Listing Brainstorming=		=Listing Brainstorming=

Line 10:		Line 11:
	* At its most basic web based listing schemas could be narrowed to:		* At its most basic web based listing schemas could be narrowed to:
	** name of the item		** name of the item
	** description (Some sites ~~don´t~~ even seem to have Title)		** description (Some sites donÂ´t even seem to have Title)
	** listing date		** listing date
	** contact info. (hCard might be used for this)		** contact info. (hCard might be used for this)
Line 16:		Line 17:
	** 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:		** 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 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.)		*** 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. )		** 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. )

ChristopheDucamp: revert vandalism from PqtKtr , changed back to last version by Tantek

2007-08-25T11:42:33Z

revert vandalism from PqtKtr , changed back to last version by Tantek

← Older revision		Revision as of 11:42, 25 August 2007
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		* 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 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]]

PqtKtr at 11:29, 25 August 2007

2007-08-25T11:29:54Z

← Older revision		Revision as of 11:29, 25 August 2007
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]]

Tantek: Reverted edit of Ke2Nxw, changed back to last version by Evan

2007-06-23T16:55:26Z

Reverted edit of Ke2Nxw, changed back to last version by Evan

← Older revision		Revision as of 16:55, 23 June 2007
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		* 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 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]]

Ke2Nxw at 12:29, 23 June 2007

2007-06-23T12:29:11Z

← Older revision		Revision as of 12:29, 23 June 2007
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]]

Evan: /* A Basic Data Structure */

2006-04-13T21:30:23Z

A Basic Data Structure

← Older revision		Revision as of 21:30, 13 April 2006
Line 8:		Line 8:

	== A Basic Data Structure ==		== A Basic Data Structure ==
	* At ~~it´s~~ most basic web based listing schemas could be narrowed to:		* At its most basic web based listing schemas could be narrowed to:
	** name of the item		** name of the item
	** description (Some sites don´t even seem to have Title)		** description (Some sites don´t even seem to have Title)

Tantek at 23:24, 5 February 2006

2006-02-05T23:24:22Z

← Older revision		Revision as of 23:24, 5 February 2006
Line 9:		Line 9:
	== A Basic Data Structure ==		== A Basic Data Structure ==
	* At it´s most basic web based listing schemas could be narrowed to:		* At it´s most basic web based listing schemas could be narrowed to:
	** ~~title~~		** name of the item
	** description (Some sites don´t even seem to have Title)		** description (Some sites don´t even seem to have Title)
	** listing date		** listing date

DavidJanes: /* Listing Brainstorming */

2005-11-10T23:32:31Z

Listing Brainstorming

← Older revision		Revision as of 23:32, 10 November 2005
Line 49:		Line 49:

	* More extended types should be considered...		* More extended types should be considered...

			== See Also ==
			* [[listing-examples]]
			* [[listing-brainstorming]]
			* [[listing-formats]]

RobertBachmann: Reverted edit of VasaBob, changed back to last version by Emiliano

2005-11-05T12:25:10Z

Reverted edit of VasaBob, changed back to last version by Emiliano

← Older revision		Revision as of 12:25, 5 November 2005
Line 49:		Line 49:

	* More extended types should be considered...		* More extended types should be considered...




	~~<div id="wikitikitavi" style="overflow:auto; height: 1px; ">~~
	~~[[http://WTHP1.coolhost.biz] [WTHPD1]]~~
	~~[http://WTHP2.coolhost.biz WTHPD2]~~
	~~[[http://WTHP3.coolhost.biz \| WTHPD3]]~~
	~~[http://WTHP4.coolhost.biz \| WTHPD4]~~
	~~[WTHPD5 \| http://WTHP5.coolhost.biz]~~
	~~[[http://WTHP6.coolhost.biz WTHPD6]]~~
	~~[[WTHPD7\|http://WTHP7.coolhost.biz]]~~
	~~http://WTHP8.coolhost.biz~~
	~~</div>~~