hrecipe-issues - Revision history

ChristopheDucamp: Reverted edits by I MADE THOUSANDS OF ACCOUNTS IN MICROFORMATS WIKI GO TO CHECK OUT THE USER LIST ([[User talk:I MADE THOUSANDS OF ACCOUNTS IN MICROF

2013-09-22T11:09:18Z

Reverted edits by I MADE THOUSANDS OF ACCOUNTS IN MICROFORMATS WIKI GO TO CHECK OUT THE USER LIST ([[User talk:I MADE THOUSANDS OF ACCOUNTS IN MICROF

Show changes

I MADE THOUSANDS OF ACCOUNTS IN MICROFORMATS WIKI GO TO CHECK OUT THE USER LIST at 02:59, 22 September 2013

2013-09-22T02:59:37Z

Show changes

Tantek: Reverted edits by Gowrvw (Talk) to last version by Ironsidevsquincy

2013-08-25T19:49:48Z

Reverted edits by Gowrvw (Talk) to last version by Ironsidevsquincy

Show changes

Gowrvw at 19:38, 25 August 2013

2013-08-25T19:38:13Z

Show changes

Ironsidevsquincy at 15:59, 3 June 2010

2010-06-03T15:59:31Z

← Older revision		Revision as of 15:59, 3 June 2010
Line 118:		Line 118:
	BBC food has a problem whereby they'd like to show duration of preparation time with a minimum/maximum value. In plain english : "This recipe takes between 10 and 30 minutes to prepare". Google Rich Snippets provides a mechanism to show min/max in prepTime (although at the moment their visual preview is failing to accurately display these values) - how could we make it easier to specify min/max duration values in hRecipe? Reuse of duration is available, but is that sufficient? ISO time has been recommended for use, but this kind of value is not an interval of time.		BBC food has a problem whereby they'd like to show duration of preparation time with a minimum/maximum value. In plain english : "This recipe takes between 10 and 30 minutes to prepare". Google Rich Snippets provides a mechanism to show min/max in prepTime (although at the moment their visual preview is failing to accurately display these values) - how could we make it easier to specify min/max duration values in hRecipe? Reuse of duration is available, but is that sufficient? ISO time has been recommended for use, but this kind of value is not an interval of time.
	* Could you post URLs to [[recipe-examples]] of real world recipe (perhaps from BBC) that have preparation time with minimum/maximum and perhaps expected/average durations in the visible content? Having the actual content and existing markup to view/analyze would greatly help inform a better solution. [[User:Tantek\|Tantek]] 18:25, 29 April 2010 (UTC)		* Could you post URLs to [[recipe-examples]] of real world recipe (perhaps from BBC) that have preparation time with minimum/maximum and perhaps expected/average durations in the visible content? Having the actual content and existing markup to view/analyze would greatly help inform a better solution. [[User:Tantek\|Tantek]] 18:25, 29 April 2010 (UTC)
			** Pretty much all of the BBC recipes have ranges for cooking/prep times, e.g. [http://www.bbc.co.uk/food/recipes/macaronicheese_83521 Macaroni Cheese] (cook time: min 0, max 30 mins; prep time: min 10 mins, max 30 mins), [http://www.bbc.co.uk/food/recipes/roastedchickenbreast_93803 Roasted chicken breast] (cook time: min 0, max 30 mins; prep time: min 1 hrs, max 2 hrs). Currently we're just taking the max value as the time value. [[User:Ironsidevsquincy\|Ironsidevsquincy]] 16:56, 3 June 2010 (UTC)
	</div>		</div>
	</div>		</div>

Tantek: need examples of approximate durations, typos

2010-04-29T18:25:10Z

need examples of approximate durations, typos

← Older revision		Revision as of 18:25, 29 April 2010
Line 51:		Line 51:
	"photo" was definitely less used than there were photos added to recipes. And I know a lot of people who, when showed 2 recipes, one with and one without photo, almost certainly choose the one with photo. So IMHO it should stay.		"photo" was definitely less used than there were photos added to recipes. And I know a lot of people who, when showed 2 recipes, one with and one without photo, almost certainly choose the one with photo. So IMHO it should stay.

	"yield" was used surprisingly seldomly. Isn't it an essential addition to the ingredients list? Maybe the yield is often self-explanatory, maybe this reflects the fact, that also the value and type of ingredients wasn't marked up most of the time. 'Smallishness' would certainly suggest to omit all the three: "value", "type" and yield". People seem to feel that the "ingredient" field naturally holds information not only about the name of the ingredient but about type and value too and don't bother to mark these up ~~explicitely~~. Again for big sites which generate their content from databases the cost-benefit ratio is totally different...		"yield" was used surprisingly seldomly. Isn't it an essential addition to the ingredients list? Maybe the yield is often self-explanatory, maybe this reflects the fact, that also the value and type of ingredients wasn't marked up most of the time. 'Smallishness' would certainly suggest to omit all the three: "value", "type" and yield". People seem to feel that the "ingredient" field naturally holds information not only about the name of the ingredient but about type and value too and don't bother to mark these up explicitly. Again for big sites which generate their content from databases the cost-benefit ratio is totally different...

	"duration" would be a candidate for removal as well. But still, ~~remeber~~ that this list only reflects usage of the elements. An information of duration was part of the recipe more often than it was marked up as such.		"duration" would be a candidate for removal as well. But still, remember that this list only reflects usage of the elements. An information of duration was part of the recipe more often than it was marked up as such.

	"tag" obviously didn't get used much and is maybe strong enough on it's own. People add tags no matter if they are part of a vocabulary, and the rel-tag pattern is certainly easy enough to grasp and straightforward to implement.		"tag" obviously didn't get used much and is maybe strong enough on it's own. People add tags no matter if they are part of a vocabulary, and the rel-tag pattern is certainly easy enough to grasp and straightforward to implement.
Line 116:		Line 116:
	<div class="hentry">{{OpenIssue}}		<div class="hentry">{{OpenIssue}}
	<span class="entry-summary author vcard"><span class="published">2010-04-28</span> raised by <span class="fn">[[User:Phae\|Phae]]</span></span><div class="entry-content discussion issues">* <strong class="entry-title">Describing variable durations of preparation time.</strong>.		<span class="entry-summary author vcard"><span class="published">2010-04-28</span> raised by <span class="fn">[[User:Phae\|Phae]]</span></span><div class="entry-content discussion issues">* <strong class="entry-title">Describing variable durations of preparation time.</strong>.
	BBC food has a problem whereby they'd like to show duration of ~~preperation~~ time with a minimum/maximum value. In plain english : "This recipe takes between 10 and 30 minutes to prepare". Google Rich Snippets provides a mechanism to show min/max in prepTime (although at the moment their visual preview is failing to accurately display these values) - how could we make it easier to specify min/max duration values in hRecipe? Reuse of duration is available, but is that ~~sufficiant~~? ISO time has been recommended for use, but this kind of value is not an interval of time.		BBC food has a problem whereby they'd like to show duration of preparation time with a minimum/maximum value. In plain english : "This recipe takes between 10 and 30 minutes to prepare". Google Rich Snippets provides a mechanism to show min/max in prepTime (although at the moment their visual preview is failing to accurately display these values) - how could we make it easier to specify min/max duration values in hRecipe? Reuse of duration is available, but is that sufficient? ISO time has been recommended for use, but this kind of value is not an interval of time.
			* Could you post URLs to [[recipe-examples]] of real world recipe (perhaps from BBC) that have preparation time with minimum/maximum and perhaps expected/average durations in the visible content? Having the actual content and existing markup to view/analyze would greatly help inform a better solution. [[User:Tantek\|Tantek]] 18:25, 29 April 2010 (UTC)
	</div>		</div>
	</div>		</div>

Phae: /* issues */ min/max durations query

2010-04-29T13:57:30Z

issues: min/max durations query

← Older revision		Revision as of 13:57, 29 April 2010
Line 111:		Line 111:
	* <strong class="entry-title">Reconsidering semantic of <code>published</code> over ‘<code>created</code>’</strong>. I think the reuse of <code>published</code> from [[hAtom]] may be incorrect. Given its use in hAtom, <code>published</code> represents the date and time that the content was originally published to the page. In the case of a recipe, it seems that you would instead want to represent the date that the recipe was authored/created, which is subtly different. The publication of a recipe on a web page is something that should be done with hAtom itself (publishing an <code>hEntry</code> that contains the recipe), but the recipe itself would contain the date that ''the recipe itself'' was created. e.g. <samp>I came up with this recipe for mashed potato in <span class='created'><span class='value-title' title='2008-08'>last summer</span></span></samp>. I'm totally open to ideas about this, but my feeling is that it's unnecessary to represent the publication date since that should be represented by a complete hAtom entry. Do we think that <code>created</code> as described here falls inside the 80:20?		* <strong class="entry-title">Reconsidering semantic of <code>published</code> over ‘<code>created</code>’</strong>. I think the reuse of <code>published</code> from [[hAtom]] may be incorrect. Given its use in hAtom, <code>published</code> represents the date and time that the content was originally published to the page. In the case of a recipe, it seems that you would instead want to represent the date that the recipe was authored/created, which is subtly different. The publication of a recipe on a web page is something that should be done with hAtom itself (publishing an <code>hEntry</code> that contains the recipe), but the recipe itself would contain the date that ''the recipe itself'' was created. e.g. <samp>I came up with this recipe for mashed potato in <span class='created'><span class='value-title' title='2008-08'>last summer</span></span></samp>. I'm totally open to ideas about this, but my feeling is that it's unnecessary to represent the publication date since that should be represented by a complete hAtom entry. Do we think that <code>created</code> as described here falls inside the 80:20?
	** I agree with your interpretation of "published" versus "created". "published" is not used very often on it's own (see above) and I'm sure "created" would be used much less so - because it often is very difficult to determine when a recipe was created, when it was modified enough to count as newly created, from where (and when) it originated etc. IMO "published" MAY be out of the 80:20, but "created" certainly IS. You raise a point though that I'm thinking heavily about right now. I'm pondering if it would be wise to move most of the properties that are currently marked as "experimental" out of the draft and refer to them only (but explicitly) as possibly useful additions to a hRecipe. I would then add hReview as well and, from the 'experimental' properties, only leave "Nutrition" within the property set of hRecipe. But I need to think about that a little more. Anyway: I think your point is valid but should be part of a broader approach. --[[User:ThomasLoertsch\|ThomasLoertsch]] 15:09, 2 July 2009 (UTC)		** I agree with your interpretation of "published" versus "created". "published" is not used very often on it's own (see above) and I'm sure "created" would be used much less so - because it often is very difficult to determine when a recipe was created, when it was modified enough to count as newly created, from where (and when) it originated etc. IMO "published" MAY be out of the 80:20, but "created" certainly IS. You raise a point though that I'm thinking heavily about right now. I'm pondering if it would be wise to move most of the properties that are currently marked as "experimental" out of the draft and refer to them only (but explicitly) as possibly useful additions to a hRecipe. I would then add hReview as well and, from the 'experimental' properties, only leave "Nutrition" within the property set of hRecipe. But I need to think about that a little more. Anyway: I think your point is valid but should be part of a broader approach. --[[User:ThomasLoertsch\|ThomasLoertsch]] 15:09, 2 July 2009 (UTC)
			</div>
			</div>

			<div class="hentry">{{OpenIssue}}
			<span class="entry-summary author vcard"><span class="published">2010-04-28</span> raised by <span class="fn">[[User:Phae\|Phae]]</span></span><div class="entry-content discussion issues">* <strong class="entry-title">Describing variable durations of preparation time.</strong>.
			BBC food has a problem whereby they'd like to show duration of preperation time with a minimum/maximum value. In plain english : "This recipe takes between 10 and 30 minutes to prepare". Google Rich Snippets provides a mechanism to show min/max in prepTime (although at the moment their visual preview is failing to accurately display these values) - how could we make it easier to specify min/max duration values in hRecipe? Reuse of duration is available, but is that sufficiant? ISO time has been recommended for use, but this kind of value is not an interval of time.

	</div>		</div>
	</div>		</div>

Tantek: concur with Toby's recent "value" subproperty issue and suggested resolution.

2010-03-25T17:30:25Z

concur with Toby's recent "value" subproperty issue and suggested resolution.

← Older revision		Revision as of 17:30, 25 March 2010
Line 152:		Line 152:
	#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.		#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
	#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk\|TobyInk]] 20:32, 29 December 2008 (UTC)		#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk\|TobyInk]] 20:32, 29 December 2008 (UTC)
	#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek\|Tantek]] 20:54, 15 January 2009 (UTC)		#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not use duplicates of each property in a singular and plural form. [[User:Tantek\|Tantek]] 20:54, 15 January 2009 (UTC)
	#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek\|Tantek]] 20:54, 15 January 2009 (UTC)		#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek\|Tantek]] 20:54, 15 January 2009 (UTC)
	#*** Semantically the reuse of "duration" is okay. RFC 2445 permits multiple duration values "if the property permits" so that should be fine too. If the syntactic differences can be worked out the way Tantek suggests above than it's okay with me to re-use "duration". I'm just not sure if it helps usability to overload properties in such a way but that ay be another discussion on it's own. [[User:ThomasLoertsch\|ThomasLoertsch]] 15:00, 16 January 2009 (UTC)		#*** Semantically the reuse of "duration" is okay. RFC 2445 permits multiple duration values "if the property permits" so that should be fine too. If the syntactic differences can be worked out the way Tantek suggests above than it's okay with me to re-use "duration". I'm just not sure if it helps usability to overload properties in such a way but that ay be another discussion on it's own. [[User:ThomasLoertsch\|ThomasLoertsch]] 15:00, 16 January 2009 (UTC)
Line 195:		Line 195:
	*** Suggestion: remove these subproperties from the ingredient and nutrition properties. [[User:TobyInk\|TobyInk]] 15:44, 25 March 2010 (UTC)		*** Suggestion: remove these subproperties from the ingredient and nutrition properties. [[User:TobyInk\|TobyInk]] 15:44, 25 March 2010 (UTC)
	</div>		</div>
			**** +1 I concur with Toby's analysis and recommendation. [[User:Tantek\|Tantek]] 17:30, 25 March 2010 (UTC)

	== closed issues ==		== closed issues ==

TobyInk: /* hrecipe. Proposal for Draft 0.2 */ value and type are used strangely

2010-03-25T15:44:21Z

hrecipe. Proposal for Draft 0.2: value and type are used strangely

← Older revision		Revision as of 15:44, 25 March 2010
Line 191:		Line 191:
	* '''''tag'''''. optional. 1 or more. [ ''experimental'' ].		* '''''tag'''''. optional. 1 or more. [ ''experimental'' ].
	--[[User:ThomasLoertsch\|ThomasLoertsch]] 11:01, 10 February 2009 (UTC)		--[[User:ThomasLoertsch\|ThomasLoertsch]] 11:01, 10 February 2009 (UTC)

			** <strong id="issue-20100325">The above seems to use ''value'' very differently to other microformats</strong>. In other microformats it's used for [[value-class-pattern\|value excerpting]] in most properties (i.e. the ''value'' class is used to indicate which text should be parsed with the rest being ignored); and in a handful of particular properties (e.g. hCard tel, email, adr, label) it's used in the ''value''+''type'' combination to indicate the main text that should be parsed while ''type'' refines the meaning of the property. In a recipe ingredient, the main idea to get across would be the ingredient itself (e.g. eggs, whisky, cardamom), so if ''value'' were to be used, you'd expect it to be more like this: <code><li class="ingredient">2 <span class="value">eggs</span>, lightly whisked</li></code>. Wrapping <code>class=value</code> around the '2' is fairly at odds with how that class is used in other microformats. [[User:TobyInk\|TobyInk]] 15:44, 25 March 2010 (UTC)
			*** Suggestion: remove these subproperties from the ingredient and nutrition properties. [[User:TobyInk\|TobyInk]] 15:44, 25 March 2010 (UTC)
	</div>		</div>

Tantek: issues page itself is not a draft spec

2009-10-10T07:04:24Z

issues page itself is not a draft spec

← Older revision		Revision as of 07:04, 10 October 2009
Line 241:		Line 241:
	* [[recipe-issues]]		* [[recipe-issues]]
	towards the development of this draft.		towards the development of this draft.

	~~[[Category:Draft Specifications]]~~