Microformats Wiki - User contributions [en]

hnews

2009-12-23T16:56:06Z

Smyles: Corrected from "class name" to "rel value of" to match the brainstorming proposal

<entry-title>hNews 0.1</entry-title>
{{Template:DraftSpecification}}

hNews is a microformat for news content. hNews extends [http://microformats.org/wiki/hatom hAtom], introducing a number of fields that more completely describe a journalistic work. hNews also introduces another data format, [[principles-brainstorming#rel-principles_specification|rel-principles]], a format that describes the journalistic principles upheld by the journalist or news organization that has published the news item. hNews will be one of several open standards.
__TOC__
== Draft Specification ==

;Editor/Author
:[[:User:JonathanMalek|Jonathan Malek]] ([http://www.ap.org Associated Press])

;Contributors
:[[:User:Smyles|Stuart Myles]] ([http://www.ap.org Associated Press])
:[[:User:Martinjemoore|Martin Moore]] ([http://mediastandardstrust.org Media Standards Trust])
:[[:User:MarkNg|Mark Ng]] ([http://mediastandardstrust.org Media Standards Trust])
:[[:User:Tbmartinwiki|Todd B. Martin]] ([http://www.ap.org Associated Press])

=== Copyright ===
Per the public domain release on the authors' user pages ([[:User:JonathanMalek|Jonathan Malek]]) this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

=== Patents ===
{{MicroFormatPatentStatement}}

== Introduction ==
hNews is a microformat for identifying semantic information in news stories. It builds on [[hAtom]], while adding a number of fields that more completely define a journalistic work. hNews can be thought of as inheriting from [[hAtom]], since parsers and tools that do not understand the hNews extensions can still parse the [[hAtom]] content. However, those parsers and applications that understand hNews can enable a richer set of semantic actions on news stories.

{{rfc-2119-intro}}

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
hNews extends hAtom. As the hAtom draft format notes, "Atom provides a lot more functionality than we need for a 'blog post' microformat, so we've taken the minimal number of elements needed." News stories typically introduce more fields (for instance, the publishing organization) than the current 0.1 draft of hAtom, and those fields are very important when reading or evaluating a news story. We focus on those fields that enable the development of semantic actions around news: license, principles, dateline (geo) and source organization.

=== Schema ===
The hNews schema consists of the following:

* hNews ('''<code>hnews</code>''') and '''<code>hentry</code>'''. required. Using [[hAtom]].
** '''<code>source-org</code>'''. required. Using [[hCard]].[*]
** '''<code>dateline</code>'''. optional. Using text or [[hCard]].
** '''<code>geo</code>'''. optional. Using [[geo]].[*]
** '''<code>item-license</code>'''. recommended. Using a [[licensing-brainstorming#item_as_container|brainstorm proposal]].
** '''<code>principles</code>'''. recommended. Using the draft microformat [[principles-brainstorming#rel-principles_specification|rel-principles]].

[*] Some required elements have defaults if missing, see below.

=== Field and Element Details ===

==== hAtom Fields ====

===== Entry =====
* an hNews story {{must}} be encoded as an [[hAtom]] <code>hentry</code>.
* if an hNews story cannot be parsed as an [[hAtom]] <code>hentry</code>, it is invalid hNews.

==== Additional Fields ====

===== Source Organization =====
* a Source Organization element is identified by the class name <code>source-org</code>.
* Source Organization represents the originating organization for the news story.
* a Source Organization {{must}} be encoded in an [[hCard]].
* if the Source Organization is missing
** find the [[algorithm-nearest-in-parent]] element(s) with class name <code>source-org</code> and that is/are a valid [[hCard]]
** otherwise the entry is invalid hNews

===== Dateline =====
* a dateline element is identified by the class name <code>dateline</code>.
* dateline represents the location where the news story was written or filed (see [http://en.wikipedia.org/wiki/Dateline dateline] for more details).
* a dateline element {{may}} be encoded in an [[hCard]].
* a news story {{should}} have a dateline element.
* dateline sometimes also includes the publish date of the news story. In such cases, use the [[datetime-design-pattern]] to encode the date.

===== Geo =====
* a geo element is identified by the class name <code>geo</code>
* geo represents the geographic coordinates of relevant locations in the news story.
* a geo element should be encoded in a [[geo]].
* in those cases where the latitude and longitude represent the dateline, a variant of [[geo]] should be used (see [http://microformats.org/wiki/geo-brainstorming#Geo_improvements Geo Improvements] for an example).

===== License =====
* a license element is identified by the rel value of <code>item-license</code>.
* a license element {{must}} be encoded as described in this [http://microformats.org/wiki/licensing-brainstorming#item_as_container license brainstorm proposal].
* a news story {{should}} include a license element.

===== Principles =====
* a principles element is identified by <code>rel-principles</code>.
* principles represents the statement of principles and ethics used by the news organization that produced the news story.
* a principles element {{must}} be encoded in [[principles-brainstorming#rel-principles_specification|rel-principles]].
* a news story {{should}} include principles.
* principles {{should}} be linked to using the icons http://labs.ap.org/principles-button-blue.png or http://labs.ap.org/principles-book-blue.png.

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>

<dt>hnews</dt>
<dd>
Used to describe semantic information associated with news stories.
</dd>

<dt>source-org</dt>
<dd>
The originating organization for the news story.
</dd>

<dt>dateline</dt>
<dd>
Represents the location where the news story was filed.
</dd>

<dt>geo</dt>
<dd>
Represents geographic coordinates of relevant locations in the story.
</dd>

<dt>rel</dt>
<dd>
<dl>
<dt>item-license</dt>
<dd>
Represents the license for the story.
</dd>
</dl>
</dd>

<dt>rel</dt>
<dd>
<dl>
<dt>principles</dt>
<dd>
Represents the statement of principles and ethics used by the news organization that produced the news story.
</dd>
</dl>
</dd>

</dl>
</dd>
</dl>
</pre>

== Examples ==

See [[hnews-examples]].

=== Examples in the wild ===

See [[hnews-examples-in-wild]].

== Implementations ==

== References ==

=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0]
* [[hatom|hAtom]]
* [[hcard|hCard]]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag]]
* [[geo]]
* [[licensing-brainstorming#item_as_container_license|item-license brainstorm]]
* [http://newscredit.org/development/newscredit-specification/rel-principles-specification/ rel-principles]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

=== Informative References ===
* Other news efforts: see [[news-formats]].

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

=== Version 0.1 ===

Version 0.1 was drafted August 2008.

== Further Reading ==
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

== Related Pages ==
* hnews
* [[news-brainstorming]]: thoughts for improving hNews.
* [[hnews-faq|hNews FAQ]]: if you have any questions about hNews, check here, and if you don't find answers, add your questions!
* [[hnews-issues]]: please add any issues with the specification to the issues page.
* [[news-formats]]: existing news and news management schemas.
* [[news-examples]]: examples of news formats on the web.
** [[hnews-examples]]: examples of how to implement hNews.

[[Category:Draft Specifications]]
[[Category:hNews]]

hnews

2009-12-23T16:54:47Z

Smyles: Fixed the link for the rel item-license brainstorming proposal

<entry-title>hNews 0.1</entry-title>
{{Template:DraftSpecification}}

hNews is a microformat for news content. hNews extends [http://microformats.org/wiki/hatom hAtom], introducing a number of fields that more completely describe a journalistic work. hNews also introduces another data format, [[principles-brainstorming#rel-principles_specification|rel-principles]], a format that describes the journalistic principles upheld by the journalist or news organization that has published the news item. hNews will be one of several open standards.
__TOC__
== Draft Specification ==

;Editor/Author
:[[:User:JonathanMalek|Jonathan Malek]] ([http://www.ap.org Associated Press])

;Contributors
:[[:User:Smyles|Stuart Myles]] ([http://www.ap.org Associated Press])
:[[:User:Martinjemoore|Martin Moore]] ([http://mediastandardstrust.org Media Standards Trust])
:[[:User:MarkNg|Mark Ng]] ([http://mediastandardstrust.org Media Standards Trust])
:[[:User:Tbmartinwiki|Todd B. Martin]] ([http://www.ap.org Associated Press])

=== Copyright ===
Per the public domain release on the authors' user pages ([[:User:JonathanMalek|Jonathan Malek]]) this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

=== Patents ===
{{MicroFormatPatentStatement}}

== Introduction ==
hNews is a microformat for identifying semantic information in news stories. It builds on [[hAtom]], while adding a number of fields that more completely define a journalistic work. hNews can be thought of as inheriting from [[hAtom]], since parsers and tools that do not understand the hNews extensions can still parse the [[hAtom]] content. However, those parsers and applications that understand hNews can enable a richer set of semantic actions on news stories.

{{rfc-2119-intro}}

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
hNews extends hAtom. As the hAtom draft format notes, "Atom provides a lot more functionality than we need for a 'blog post' microformat, so we've taken the minimal number of elements needed." News stories typically introduce more fields (for instance, the publishing organization) than the current 0.1 draft of hAtom, and those fields are very important when reading or evaluating a news story. We focus on those fields that enable the development of semantic actions around news: license, principles, dateline (geo) and source organization.

=== Schema ===
The hNews schema consists of the following:

* hNews ('''<code>hnews</code>''') and '''<code>hentry</code>'''. required. Using [[hAtom]].
** '''<code>source-org</code>'''. required. Using [[hCard]].[*]
** '''<code>dateline</code>'''. optional. Using text or [[hCard]].
** '''<code>geo</code>'''. optional. Using [[geo]].[*]
** '''<code>item-license</code>'''. recommended. Using a [[licensing-brainstorming#item_as_container|brainstorm proposal]].
** '''<code>principles</code>'''. recommended. Using the draft microformat [[principles-brainstorming#rel-principles_specification|rel-principles]].

[*] Some required elements have defaults if missing, see below.

=== Field and Element Details ===

==== hAtom Fields ====

===== Entry =====
* an hNews story {{must}} be encoded as an [[hAtom]] <code>hentry</code>.
* if an hNews story cannot be parsed as an [[hAtom]] <code>hentry</code>, it is invalid hNews.

==== Additional Fields ====

===== Source Organization =====
* a Source Organization element is identified by the class name <code>source-org</code>.
* Source Organization represents the originating organization for the news story.
* a Source Organization {{must}} be encoded in an [[hCard]].
* if the Source Organization is missing
** find the [[algorithm-nearest-in-parent]] element(s) with class name <code>source-org</code> and that is/are a valid [[hCard]]
** otherwise the entry is invalid hNews

===== Dateline =====
* a dateline element is identified by the class name <code>dateline</code>.
* dateline represents the location where the news story was written or filed (see [http://en.wikipedia.org/wiki/Dateline dateline] for more details).
* a dateline element {{may}} be encoded in an [[hCard]].
* a news story {{should}} have a dateline element.
* dateline sometimes also includes the publish date of the news story. In such cases, use the [[datetime-design-pattern]] to encode the date.

===== Geo =====
* a geo element is identified by the class name <code>geo</code>
* geo represents the geographic coordinates of relevant locations in the news story.
* a geo element should be encoded in a [[geo]].
* in those cases where the latitude and longitude represent the dateline, a variant of [[geo]] should be used (see [http://microformats.org/wiki/geo-brainstorming#Geo_improvements Geo Improvements] for an example).

===== License =====
* a license element is identified by the class name <code>item-license</code>.
* a license element {{must}} be encoded as described in this [http://microformats.org/wiki/licensing-brainstorming#item_as_container license brainstorm proposal].
* a news story {{should}} include a license element.

===== Principles =====
* a principles element is identified by <code>rel-principles</code>.
* principles represents the statement of principles and ethics used by the news organization that produced the news story.
* a principles element {{must}} be encoded in [[principles-brainstorming#rel-principles_specification|rel-principles]].
* a news story {{should}} include principles.
* principles {{should}} be linked to using the icons http://labs.ap.org/principles-button-blue.png or http://labs.ap.org/principles-book-blue.png.

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>

<dt>hnews</dt>
<dd>
Used to describe semantic information associated with news stories.
</dd>

<dt>source-org</dt>
<dd>
The originating organization for the news story.
</dd>

<dt>dateline</dt>
<dd>
Represents the location where the news story was filed.
</dd>

<dt>geo</dt>
<dd>
Represents geographic coordinates of relevant locations in the story.
</dd>

<dt>rel</dt>
<dd>
<dl>
<dt>item-license</dt>
<dd>
Represents the license for the story.
</dd>
</dl>
</dd>

<dt>rel</dt>
<dd>
<dl>
<dt>principles</dt>
<dd>
Represents the statement of principles and ethics used by the news organization that produced the news story.
</dd>
</dl>
</dd>

</dl>
</dd>
</dl>
</pre>

== Examples ==

See [[hnews-examples]].

=== Examples in the wild ===

See [[hnews-examples-in-wild]].

== Implementations ==

== References ==

=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0]
* [[hatom|hAtom]]
* [[hcard|hCard]]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag]]
* [[geo]]
* [[licensing-brainstorming#item_as_container_license|item-license brainstorm]]
* [http://newscredit.org/development/newscredit-specification/rel-principles-specification/ rel-principles]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

=== Informative References ===
* Other news efforts: see [[news-formats]].

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

=== Version 0.1 ===

Version 0.1 was drafted August 2008.

== Further Reading ==
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

== Related Pages ==
* hnews
* [[news-brainstorming]]: thoughts for improving hNews.
* [[hnews-faq|hNews FAQ]]: if you have any questions about hNews, check here, and if you don't find answers, add your questions!
* [[hnews-issues]]: please add any issues with the specification to the issues page.
* [[news-formats]]: existing news and news management schemas.
* [[news-examples]]: examples of news formats on the web.
** [[hnews-examples]]: examples of how to implement hNews.

[[Category:Draft Specifications]]
[[Category:hNews]]

hnews-issues

2009-12-09T19:03:35Z

Smyles: /* Open Issues */

<h1> hNews issues </h1>

__TOC__

These are externally raised issues about [[hnews|hNews]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the draft.

'''IMPORTANT''': Please read the [[hnews-faq|hNews FAQ]] before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

See related [[hatom-issues]] and [[hcard-issues]].

== Template ==

{{issues-format}}

== Issues ==
=== Open Issues ===
<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-11-16</span> raised by <span class="fn">[[User:gut1975|Guthrie Collin]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Allowable number of item-licenses?</strong>. In the news world, different news companies sometimes share the copyright on specific works, and this arrangement results in two copyright statements appearing for one piece of content. Modeling this relationship in the hNews world would result in two or more "item-license" elements, with each item-license element potentially linking to a separate license for each news company. Hence, I think the hNews format should explicitly allow more than one item-license for each "hnews hentry" container. Thoughts?
** If as you say "In the news world, different news companies sometimes share the copyright on specific works, and this arrangement results in two copyright statements appearing for one piece of content" then please provide URLs to real world examples that demonstrate as such. Absent any such examples, we must not change hNews for an otherwise assumed to be theoretical example, per microformats [[process]] and [[principles]]. [[User:Tantek|Tantek]] 23:51, 16 November 2009 (UTC)
** Some examples are:<blockquote><p>[http://sports.yahoo.com/nhl/preview?gid=2006122911 Capitals-Devils Preview on Yahoo!] which was created under a joint arrangement between AP and STATS, Inc (scroll to page bottom).</p><p>[http://www.kcbd.com/global/story.asp?s=11520396 Colo. medical pot & taxes on KCBD 11 in Lubbock, TX] which was an AP story but since AP and some of its customers have special copyright arrangements, KCBD and its parent company also share copyright on the content (see bottom of page).</p></blockquote>As you can see, it's somewhat inefficient to have the license separate from the content in this way, and I think the hNews schema should permit multiple item-license elements for these situations. [[User:gut1975|Guthrie Collin]] 16:21, 17 November 2009 (UTC)
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-20</span> raised by <span class="fn">[[User:MilesD|Miles De Feyter]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">News, Commentary, and Opinion pieces as they relate to hNews</strong>. An interesting comment came up today when looking at how to use hNews on other AOL properties outside of our main news site, and that is, some of our sites are both news and commentary. Let's take our sports site for example http://www.fanhouse.com/

This site reports on sports news with article headlines such as:
[http://www.fanhouse.com/news/nfl/big-ben-tops-pass-rankings/723353 Big Ben tops pass rankings]

But fanhouse.com also has some obvious opinion pieces such as:
[http://kevin-blackistone.fanhouse.com/2009/10/19/ail-to-the-redskins-worst-run-franchise-on-the-planet/ Fail to the Redskins: Worst-Run Franchise on the Planet]

Currently we have one publishing system for all of our content within Fanhouse whether it be feed driven, in house publisher, news content, or commentary. So at the moment if one thing gets hNews it all does.

Have you given this situation thought? My initial thinking is that perhaps this is where a principles statement specific to Fanhouse could account for the different types of content being labeled hNews.
** Very glad you brought this up. We've given this alot of thought. I think your initial thinking is right. Right now the place to distinguish differences such as these (e.g. reporting from opinion) is within the principles statement. But this is something I think would benefit significantly from further development (i.e. the development of additional hNews criteria) [[User:Martinjemoore|Martin Moore]]
** I believe that hNews is applicable to many types of news, ranging from reporting facts, to analysis pieces, opinion and columns. It is not unusual for a given piece of news to be a mix of two or three "types". Really, the purpose of hNews is allow for the common structural components of news to be more clearly marked up. The exact content is less important than the form. However, I also see that there is also value for a publisher of hNews to be able to self-classify the "type" of content. One way to do this would be to use rel-tag to indicate how the publisher would like to describe the hNews-encoded content (as commentary, opinion, analysis, interview, satire or whatever). [[User:Smyles|Stuart Myles]]
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-14</span> raised by <span class="fn">[[User:MarkNg|MarkNg]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">adr for dateline</strong>. From [http://twitter.com/pigsonthewing/status/4831500605 Andy Mabbett on Twitter] : hNews microformat spec "dateline. optional. Using text or hCard" should read "dateline. optional. Using text, adr or hCard".
** Seems like a useful extra to me, any objections ? [[User:MarkNg|MarkNg]]
** Agreed, makes sense. --[[User:JonathanMalek|JonathanMalek]] 00:57, 15 October 2009 (UTC)
** +1 to addition of optional "adr" markup of "dateline", but should also allow "geo" markup of "dateline" as well. i.e. change: <blockquote><p>* a dateline element MAY be encoded in an hCard.</p></blockquote> to <blockquote><p>* a dateline element MAY be encoded with an [[adr]], [[geo]], or [[hCard]] on the same element.</p></blockquote> [[User:Tantek|Tantek]] 19:57, 15 October 2009 (UTC)
</div>
</div>

=== Resolved Issues ===

<div class="hentry">
{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-15</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">XMDP defines 'principles' incorrectly.</strong> The XMDP for hNews defines 'principles' as a class, whereas the rest of the draft refers to it as a link type (i.e. 'rel' value).
** ACCEPTED SPEC UPDATE. FIXED: thanks for pointing that out. I believe the updated profile reflects that correctly now. --[[User:JonathanMalek|JonathanMalek]] 15:37, 15 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-11-13</span> raised by <span class="fn">[[User:gut1975|Guthrie Collin]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">The item-license element is incorrectly described as a class</strong>. The XMDP profile and element description for item-license in hNews describes the element as a class attribute value, however, the [http://microformats.org/wiki/licensing-brainstorming#item_as_container Licensing Brainstorming] proposal describes this field as a link type. In addition, the hNews examples purport item-license as a link type. Which item-license description is correct?
** ACCEPTED SPEC UPDATE. FIXED: the correct description is as a link (rel). The profile has been updated to reflect that correctly. --[[User:JonathanMalek|JonathanMalek]] 18:44, 13 November 2009 (UTC)
</div>
</div>

=== Closed Issues ===
<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-09</span> raised by <span class="fn">Miles De Feyter</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Implementation of item-license as it relates to hNews</strong>. Reading through the item-license brainstorm it seems to indicate that "item-license" would need to be nested within something with the class of "item". So as this relates to hNews is the suggestion to then have an articles containing div have the three class names of "hnews hentry item"?
** At this point, Miles, that is correct (following the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] concept and guidance). I expect we'll see changes around item-license (it's still just brainstorming), but for the time being, the third class name "item" is needed. --[[User:JonathanMalek|JonathanMalek]] 16:25, 12 October 2009 (UTC)
** Added to [[hnews-faq]] --[[User:JonathanMalek|JonathanMalek]] 02:19, 14 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-09-28</span> raised by <span class="fn">[[User:MilesD|Miles De Feyter]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Principles as a requirement</strong>. Working for a publishing company that owns and operates a large number of different organizations I'd love to incorporate hNews within our publishing system. The hNews requirement for a principles statement could pose a problem though or at least make rolling out hNews a more involved process then it would be otherwise. The issue is, I would now have to go to each product owner and ask then to provide this principles statement to link to. So my concern is now rather then just making a change to the publishing system to support hNews there is this requirement for some supporting content. And due to the nature of the content I can only assume our legal dep. would need to sign off as well, further complicating the adoption of hNews.
** +1 I agree that the "principles" property (and probably all other others) should be optional. [[User:Tantek|Tantek]] 18:29, 29 September 2009 (UTC)
*** I think it's important to explain why principles is a requirement. hnews is essentially a specialization of hAtom. Its purpose is to distinguish news on the web. Hence the description of source organisation, license and principles. Of these, principles is the only one which consistently distinguishes news on the web from other content (eg. commercial, government). In the future it should be distinguished further by making the principles themselves machine readable (but that is for a later date). Most professional news organisations adhere to a Statement of Principles (e.g. see http://en.wikipedia.org/wiki/Journalism_ethics_and_standards and http://www.journalism.org/resources/ethics_codes). If a site wants to mark up its content but does not want to distinguish it as news, then wouldn't it be easiest to use hAtom? [[User:martinjemoore|Martin Moore]] 9:00, 20 September 2009 (UTC)
*** Having discussed this issue at length outside this brainstorming, we understand some of the concerns of the microformat community regarding 'must', but are still convinced of the criticality of principles to hNews - therefore recommend downgrading from 'must' to 'should'. [[User:martinjemoore|Martin Moore]] 14:00, 7 October 2009 (UTC)
**** Accepted and implemented in 0.1. In keeping with the general direction here, we've changed <code>item-license</code> as well, and would consider adopting the same with <code>source-org</code> as well, if it proves to present the same problems. --[[User:JonathanMalek|JonathanMalek]] 00:53, 15 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCalendar instead of dateline?</strong> Would an [[hCalendar]] event (which can contain an hCard location) make sense for a dateline, or is the 'date' part more often omitted?
** Confusingly, the journalistic term "dateline" isn't anything to do with a date or time. It is the location from which a report is filed and is generally the main location associated with a story. Generally, a dateline consists of a city (e.g. "Rome") but could be the name of a ship at sea or even a space station. [[User:Stuart Myles|Stuart Myles]] 21:12, 24 August 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCard instead of geo?</strong> Is geo really in use here, or would using an hCard (that can contain geo) be a better way of representing locations referred to in the story, as more human readable?
** The reason for geo being highlighted (as an optional field) is to promote at least one location identifier in the story--preferably the most appropriate single location on a map for that particular story. Geo does not have to be related to dateline, but in some [http://labs.ap.org/wiki/hNews examples] we've worked on, we show the two collapsed into a single field. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** For locations referred to in the story, I agree--publishers should be using [[hCard]] with the contained geo to markup the locations themselves. One of the concepts I've struggled with is drawing an admittedly arbitrary line between the metadata ''about'' a story from the metadata ''within'' a story. For the former, we've focused on simplicity and minimalism, primarily as a means to encourage adoption. That has meant preferring [[rel-tag]] over in-line entity extraction and markup using compound microformats. For the latter, we feel that the field is open: use whatever microformat fits your purpose, however you can--the more, the better. This lets publishers with minimal technology capabilities at least get started by tweaking a few templates in their CMS, while those more technically inclined aren't limited by the simplicity of the format to a paucity of data. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** Also, dateline can be text or [[hCard]], as noted in the [[news-brainstorming#Common_News_Fields|Common News Fields]] section. --[[User:JonathanMalek|JonathanMalek]] 18:17, 24 September 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">What is item-license?</strong> Using [[rel-license]] presumably?
** We're working off the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] discussions for this. Our concern with [[rel-license]] was its definition as applying to an entire page, rather than an item within a page. The current discussions around licensing definitely address that. --[[User:JonathanMalek|JonathanMalek]] 00:02, 25 August 2009 (UTC)
*** +1 using item-license for news-brainstorming makes sense. [[User:Tantek|Tantek]] 22:32, 27 August 2009 (UTC)
</div>
</div>

User:Smyles

2009-10-12T16:47:03Z

Smyles:

Stuart Myles - Deputy Director of Schema Standards at The Associated Press - http://twitter.com/smyles

User:Smyles

2009-10-12T16:43:37Z

Smyles: New page: http://twitter.com/smyles

http://twitter.com/smyles

licensing-brainstorming

2009-09-29T19:34:12Z

Smyles: /* class license without hyperlink */

<entry-title>Licensing Brainstorming</entry-title>

Brainstorming proposals toward a [[licensing]] microformat per the microformats [[process]].

== Discussion ==
Set of classes pertinent to supporting licensing and attribution requirements and complements. These classes could be used at webpage level or within relevant microformats, e.g., [[media-info]].

=== reuse limitations ===
[[rel-license]] has already been specified to apply to the entire document, and thus many current [[implementations]] (e.g. [[search engines]]) already assume that whenever they see rel="license" that it applies to the whole page.

If we tried to re-use [[rel-license]] in the licensing microformat to refer to part of a page or an external resource, existing implementations would mis-interpret such a use as applying to the whole page.

Thus in order to not break backward compatibility with existing rel-license implementations, if we want something like [[rel-license]] for the licensing microformat, we must use a new rel value.

=== table of possible properties ===
The first column may be too URL-centric, see notes for parent work, may apply to others.

<table border="1" cellpadding="3" cellspacing="2">
<tr><th>Overly descriptive strawman not intended to conform with any convention</th><th>[[existing-classes|Existing class(es)]]; source</th><th>Notes</th></tr>

<tr>
<td>work title</td>
<td>fn; hCard</td>
<td>See [[licensing-examples#Attribution_with_work_title|examples#title]]</td>
</tr>

<tr>
<td>attribution name, creator?</td>
<td>author; hAtom, [[hcard]]</td>
<td>Might be a vcard with fn, may also be an organization
<br/>See [[licensing-examples#Attribution_to_creator|examples#attribution]]</td>
</tr>

<tr>
<td>attribution url</td>
<td>url; hCard</td>
<td>An author might have a url, should this be taken as the attribution url? If a work has a url, should it be taken as the attribution url?
<br/>See [[licensing-examples#Attribution_with_link_required|examples#link]]</td>
</tr>

<tr>
<td>donation url</td>
<td>payment; rel-payment<br/>
offer; hListing</td>
<td>How to disambiguate from commercial licensing and purchase?
<br/>See [[licensing-examples#Donation_related_to_work|examples#donation]]</td>
</tr>

<tr>
<td>commercial licensing url</td>
<td>payment; rel-payment<br/>
sell, offer; hListing<br/>
copyright; HTML LinkType</td>
<td>How to disambiguate from donation and purchase?
<br/>See [[licensing-examples#Commercial_licensing|examples#commercial]]</td>
</tr>

<tr>
<td>purchase url</td>
<td>payment; rel-payment<br/>
sell, offer; hListing</td>
<td>How to disambiguate from donation and commercial licensing?
<br/>See [[licensing-examples#Purchase_related_media|examples#purchase]]</td>
</tr>

<tr>
<td>content hash</td>
<td>checksum, sha1; [[hash-examples]]</td>
<td>See [[licensing-examples#License_notice_with_content_hash|examples#hash]]</td>
</tr>

<tr>
<td>provenance url<td>
<td> See [[licensing-examples#Rights_provenance.2Fwarranty.2Fidemnification|examples#provenance]] </td>
</tr>

<tr>
<td>parent work <em>url?</em>, derivitave-source</td>
<td></td>
<td>Should this be a url? Maybe it should be a TBD "media" microformat which may be otherwise described.
<br/>See [[licensing-examples#Attribution_to_derivative.27s_source_work|examples#derivative]]<br/>
Probably should be a URL -- a uf can have a #URL if it has an id.</td>
</tr>

<tr>
<td>attribution, copied-source</td>
<td></td>
<td>Shows where the media was immediately copied from (not necessarily the same as its original source). Has the same challenges as derivative-source. Perhaps use the approach loosely outlined in [[licensing-brainstorming#Attribution_Challenges|Attribution Challenges]]</td>
</tr>

<tr>
<td>source</td>
<td></td>
<td>Like 'copied-source' but points to the original source.</td>
</tr>

</table>

=== Attribution Challenges ===
Tags dealing with specifying sources and tracking a piece of media's path through the Web (any of the -source tags above) are a little ambiguous in terms of what they can reference. For instance when specifying a derivative work it could be from another image on the Internet, in which case an URL would be appropriate, or it could be a quotation from a magazine or other "real" world source where an URL doesn't really work. Perhaps we can encourage the content of these 'media source' tags to be one of the following:
<table border="1" cellpadding="3">
<tr>
<th>Media source type</th>
<th>Format</th>
<th>Notes</th>
</tr>
<tr>
<td>Internet source</td>
<td>An URL</td>
<td></td>
</tr>
<tr>
<td>Person</td>
<td>[[hcard]]</td>
<td></td>
</tr>
<tr>
<td>Publication <br />(book, magazine, etc.)</td>
<td>[[citation]]</td>
<td>Citation appears to be heavily weighed towards academia but it looks like it should work for most purposes</td>
</tr>
<tr>
<td>Film/Video</td>
<td> ?? </td>
<td>I'm not sure about this one. Would citation stretch over visual media? Perhaps [[media-info]]?</td>
</tr>
</table>

=== containing vs being contained ===
Based on the markup in the [[licensing-examples]], in may be useful to consider two ways that licensing information could be expressed:
# A license microformat that contains the item on the page that is being licensed, as well as the license URL and attribution requirements (if any).
# A license microformat that contains just a link to the license URL, and has:
#* a) an ID reference to the item outside the licensing markup OR implied item applicability by a containing [[media-info]], [[hAtom]] hentry etc.
#* b) and contains OR has an ID reference to the attribution requirements (if any)

Both these options should be explored, and tried out with markup from actual [[licensing-examples]] to see which of today's use cases each option would work well/better with.

It may be that we want/need a licensing microformat that allows for either method (containing or being contained) of indicating the license.

== brainstorms ==
Various thoughts, proposals, strawman examples of how licensing information could be marked up.

=== class attribution ===
Perhaps there should be an 'attribution' class which might hint that a fn or url should be used for attribution? Something like (webpage scope):

<pre>
<nowiki>
<a class="url attribution fn" href="http://example.com">My First Cookbook</a>
<div class="author vcard">
<div class="fn attribution">J Doe</div>
</div>
<a rel="license" href="http://creativecommons.org/licenses/by/2.5/">(cc)</a>
<a rel="payment" href="http://paypal.com/...">don't let me starve</a>
</nowiki>
</pre>

==== media info with attribution ====
Here is an example of [[media-info]] with class 'attribution'.

<pre>
<nowiki>
<div class="media">
<img class="url attribution mediaitem" src="http://example.com/cake.jpg"/>
<span class="fn">Picture of a giant cake</span>
<div class="author vcard">
<div class="fn attribution">J Doe</div>
</div>
<a rel="license" href="http://creativecommons.org/licenses/by-nc/2.5/">(cc)</a>
<a rel="payment" href="http://paypal.com/...">don't let me <s>starve</s>eat cake</a>
<a rel="payment" href="http://artdelivery.example">buy this pic, framed</a>
<a rel="payment" href="http://photoclearing.example">get commercial rights</a>
...
</div>
</nowiki>
</pre>

=== reuse CC vocabulary ===
Here is an example using the Creative Commons vocabulary, with CamelCase conventions converted to dash separated lowercase words per microformats [[naming-principles]].

<pre><nowiki>
<div class="license">
<a rev="license" href="http://example.org/work">The work</a>
is licensed under the
<a rel="legal-code" href="http://example.org/foo">Foo License</a>.
Summary: it permits
<abbr title="derivative-works" class="permits">derivative works</abbr>
but requires
<abbr title="attribution" class="requires">attribution</abbr>.
The credit to give when reusing the work is
"<span class="vcard">
<a href="http://tobyinkster.co.uk" class="fn url attribution-name" rel="attribution-url">
Toby Inkster
</a>
</span>
".
</div>
</nowiki></pre>

The microformat could use the following terms:

* '''license''' {1} (root class name)
** legal-code ? (rel value, not class)
** ''more-permissions'' * (rel value, not class)
** ''permits'' * ("reproduction" | "distribution" | "derivative-works") "high-income-nation-use" and "sharing" are deprecated by Creative Commons, they were used in the retired DevNations and Sampling licences.
** ''requires'' * ("copyright-notices" | "attribution" | "share-alike" | "source-code")
** ''prohibits'' * ("commercial-use")
** ''jurisdiction'' * (text | hCard | adr)
** attribution-name ?
** attribution-url ? (rel value, not class)
** deprecated-on ? (ISO date)

The license linked to using rel="legal-code" (if any) should be taken to be the definitive license. When such a license is present, the "permits", "requires", "prohibits" and "jurisdiction" classes are taken to be merely advisory. When no "legal-code" license is linked to, these classes are definitive.

[[rel-license]] {{should}} be used to link from the work to the license (an ID attribute on the license will help). A license {{may}} link back to the work using rev="license", but forward links are preferred.

As an extension to the creative commons vocabulary (which focuses on open-source-like licenses) a payment URL {{may}} be linked to using an anchor element simultaneously carrying class="requires" and rel="payment". Example:

<pre><nowiki>
<a class="requires" rel="payment" href="https://payment.example.org">buy</a>
</nowiki></pre>

If [[rel-payment]] is used without a class of "requires", then the link is taken to be an optional payment link - i.e. a donation.

==== ccREL issues ====
<div class="discussion">
* '''license proliferation anti-pattern.''' The ''permits'', ''requires'', ''prohibits'' properties enable (and thus encourage) a combinatorial explosion in license proliferation, which is well known/understood to be a bad thing in open source circles as well as in/by the Creative Commons community itself - e.g. in a presentation on 2005-11-03, Lawrence Lessig indicated that license proliferation was a threat to [http://www.flickr.com/photos/tantek/85610375/ interoperability], and that that was one of the biggest problems that the open source and content communities needed to address. Note that this is an issue with ccREL itself, independent of the syntax, whether converted to microformats class names or not. [[User:Tantek|Tantek]] 21:50, 29 May 2009 (UTC)
** Doesn't "proliferation" indicate a measure of growth? I'm not sure I see that in the industry I work in (it may be applicable to other industries, or the open source community). In the industry I work in, licenses are prolific. With each business deal, it seems, there are new license terms and conditions. That's the measure as it stands today--nothing in an REL that I can see would proliferate licenses further. In fact, forcing current licenses into existing RELs (ccREL being just one) is a near futile effort. It ''forces'' simplification. When it comes down to it, it seems to me that expressing licenses in a REL that tools can parse and act on, enriching user experience, findability and interactiveness can only be a good thing. This isn't--I don't think--about license proliferation, as the licenses are already proliferated. Instead, this seems to be (and here, speaking from experience, so take it as anecdotal), about putting the cat back in the bag in many cases. Maybe just the industry I work in? [[User:JonathanMalek|Jonathan]]
*** Jonathan, it may be that the industry you work in, license proliferation is already a problem, in fact, one might even say that it was a problem ''before'' the creation of Creative Commons (CC), and that CC was in some part created to simplify/standardize on a small handful of licenses that would/could be easily understood and reused directly by content authors/creators/publishers *without* necessarily needing business deals (or lawyers potentially) to both *share* content, and *reuse* content. The point of fighting license proliferation is to both discourage *further* proliferation, and to make non-proliferation *easier* (cheaper) and thus more popular over time (as compared to one-off business deals etc.). In addition, technology should not be used to simply rubberstamp an existing practice (e.g. the microformats [[process]] itself contains a lot of critical analyses/simplifications of existing practices), and technology should especially not be used to promote what has been recognized as undesirable (even if common) practices, like license proliferation. [[User:Tantek|Tantek]] 03:45, 19 August 2009 (UTC)
*** regarding enriching user experience (UX), proliferation does the opposite (makes the user interface *worse*), as it forces users to try to understand more and more different variants of licenses. What actually enhances/enriches UX/UI is *re-use* of standard licenses which people are comfortable with. This has shown to be true in the open source world, in the wiki world (Wikipedia GFDL/CC-SA recent convergence demonstrates this), and in the content search world with the Creative Commons search interfaces that look for specific *licenses*, rather than expressions of rights. [[User:Tantek|Tantek]] 03:45, 19 August 2009 (UTC)
** The ''requires'' and ''prohibits'' properties should only be seen as refinements of the ''permits'' properties. ccREL is merely expressing licences, on top of copyright, so copyright is always the basis and thus all rights are reserved. Only permissions need to be expressed with ccREL. There is absolutely no need to fully model the permissions/prohibitions/requirements of Copyright. If you only plan to offer copyrighted content without any licenses applied to it, you may want to think about adding an "informative" statement like "all rights reserved". ccREL may not be useful in that case, except perhaps its ability to add cc+ additional information like payments, more permissions, etc. [[User:Patrickp|Patrickp]] 14:14, 18 August 2009 (UTC)
*** Even "refinements" can be viewed as divergence/proliferation and thus still contribute to the anti-pattern. [[User:Tantek|Tantek]] 19:27, 18 August 2009 (UTC)
*** "no need" is irrelevant - the point is that ccREL might even *enable* a specific piece of content to model any of numerous combinations of permissions/prohibitions/requirements, all of which amount to divergent/proliferant licenses, which makes those features undesirable. [[User:Tantek|Tantek]] 19:27, 18 August 2009 (UTC)
*** The only way to avoid content-specific license proliferation is to set the explicit design goal to *exclude* any rights enumeration related *features* (whether permits/prohibits/requires/optional or not), and to design a [[licensing]] microformat that instead only uses licenses by *reference*, with hyperlinks (e.g. to Creative Commons licenses as is existing common practice) to encourage data visibility, as the [[rel-license]] microformat has well established. [[User:Tantek|Tantek]] 19:27, 18 August 2009 (UTC)
* '''Rights Expression Language is proliferant framing''' - "REL" the specific unique aspect of the name of ccREL, "Rights Expression Language", encourages the framing that it is acceptable to *express* *rights* (more than one, hence combinatorics result) in a (computer) *language*. The effect is highly undesirable as documented in the '''license proliferation anti-pattern''' issue and thus we should not only discourage any re-use of ccREL in microformats, but also discourage any use of ccREL at all, as well as discourage development of a "rights" microformat, because all of those propagate the undesirable license proliferant frame of the "REL" portion of "ccREL". [[User:Tantek|Tantek]]
* '''enumerated values are a known i18n problem.''' The above mapping creates a new en-us content enumeration ('derivative-works', etc). Shown here in <code>abbr</code> form, which as in hCard, will not internationalize acceptably. As per the advice we given to page authors, further use of the [[value-class-pattern]] as a DRY-violating get-out for this should be an absolute last resort to specification authors too. (Personally, I'd favour declaring prescribed enumeration an anti-pattern for future development.) --[[User:BenWard|BenWard]] 22:28, 29 May 2009 (UTC)
** +1 I agree with Ben Ward, new enumerations will likely be problematic and should be avoided. -- [[User:Tantek|Tantek]] 18:02, 31 July 2009 (UTC)
</div>

=== rel item license ===
Since [[rel-license]] already applies to an entire page, we likely need another rel value to indicate that a license only applies to a specific item on or referenced by the page. Thus:

<code>rel="item-license"</code>

=== class license ===
Licensing information about an item could be contained in an element with class name "license", e.g.

<source lang=html4strict>
<div class="license">
This
<span class="item">
<a class="url" href="photo.jpg">photograph</a>
</span>
is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license
</a>.
</div>
</source>

=== class license without hyperlink ===
Licensing information about an item could be contained in an element with a class name "license", without a hyperlink to another page, e.g.

<source lang=html4strict>
<div class="license">
Copyright 1996, Example Corporation. All rights reserved.
No part of this work may be reproduced or used in any form, without prior written permission of the
publisher, except in the case of brief quotations embodied in reviews. Making copies of any part of this
work for any purpose other than your own personal use is a violation of United States copyright laws.
For information, contact Example Corporation, 555 East 555th Street, San Francisco, CA 16399.
</div>
</source>

=== class names license and attribution ===

Attribution information could be added with the above-mentioned class name 'attribution':

<source lang=html4strict>
<div class="license">
This
<span class="item">
<a class="url" href="photo.jpg">photograph</a>
</span>
is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license
</a>.
Please provide the following attribution with any re-use of the photo:
<div class="attribution">
Photo by Mary Smith.
</div>
</div>
</source>

with hyperlinks in attribution:

<source lang=html4strict>
<div class="license">
This
<span class="item">
<a class="url" href="photo.jpg">photograph</a>
</span>
is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license
</a>.
Please provide the following attribution with hyperlinks to the original and author with any re-use of the photo:
<div class="attribution">
<a href="photo.jpg">Photo</a>
by
<a href="http://mary.example.com/">Mary Smith</a>.
</div>
</div>
</source>

=== item as container ===
It may be possible to simplify even further and only use the containing class "item" with rel="item-license" to indicate the scope of the thing that is being licensed, the license, and any optional attribution.

;<span style="font-size:smaller">short URL for this section</span>
:http://tr.im/ufitc

Here is an example of a chunk of hypertext content that is being licensed:

<source lang=html4strict>
<div class="item">
<p>... blog post or article text content ...</p>
<p>This is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license</a>.
</p>
</div>
</source>

To specify a license on an external resource like a photograph, we can use a new class name "item-url" to identify the external resource as being the actual item:

<source lang=html4strict>
<div class="item">
This
<a class="item-url" href="photo.jpg">photograph</a>
is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license
</a>.
</div>
</source>

'''item-url details:'''
* Authors should provide one item-url for an external resource that is being licensed.
* If more than one item-url is provided, they are assumed to be copies/mirrors/versions (perhaps different resolutions) of the same item, and all have the same license and attribution terms (if any) applied to them, e.g. a link to the photo and embedding a thumbnail or small version of the photo:

<source lang=html4strict>
<div class="item">
This
<a class="item-url" href="photo.jpg">photograph:
<img class="item-url" href="smallphoto.jpg" alt="small version of a photograph" />
</a>
is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license
</a>.
</div>
</source>

==== item with attribution ====
Attribution information could be added with the class name 'attribution':

<source lang=html4strict>
<div class="item">
This
<a class="item-url" href="photo.jpg">photograph</a>
is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license
</a>.
Please provide the following attribution with any re-use of the photo:
<div class="attribution">
Photo by Mary Smith.
</div>
</div>
</source>

==== item with hyperlink attribution ====
With hyperlinks in attribution:

<source lang=html4strict>
<div class="item">
This
<a class="item-url" href="photo.jpg">photograph</a>
is licensed under a
<a rel="item-license" href="http://creativecommons.org/licenses/by-nc/2.0/deed.en">
Creative Commons attribution non-commercial 2.0 license
</a>.
Please provide the following attribution with hyperlinks to the original and author with any re-use of the photo:
<div class="attribution">
<a href="photo.jpg">Photo</a>
by
<a href="http://mary.example.com/">Mary Smith</a>.
</div>
</div>
</source>

== to do ==
* Examples with [[hAtom]] and [[hMedia]]

== see also ==
* [[licensing]]
* [[licensing-examples]]
* [[licensing-formats]]
* [[licensing-brainstorming]]

news-brainstorming

2009-08-24T21:15:24Z

Smyles: /* Common News Fields */

= News Brainstorming =

There have been several efforts to define data formats for news content. Almost all have focused on the interchange of news content between systems and organizations, and so contain dozens (if not hundreds) of fields that are targeted at "news management"--a mix of content management, metadata management, versioning and other operations undertaken by news organizations.

This page serves to document the brainstorming and ideas resulting from analysis of news examples from real world sites and systems for the design of a simple news [[microformat]]. - [[User:JonathanMalek|Jonathan Malek]]

__TOC__

== Contributors ==

* Jonathan Malek
* Stuart Myles
* Martin Moore
* Mark Ng
* Todd Martin

== See Also ==

* [[news-examples]]
* [[news-formats]]

== The Problem ==

While there are dozens of formats used on thousands of news sites, there is no single standardized format for presentation of news on the web. Having a standardized news format for web publishing would significantly benefit readers, aggregators, search engines and researchers alike. With no standard format for news, search engines are forced to parse unstructured data, and errors can be costly (see ''[http://www.wired.com/threatlevel/2008/09/six-year-old-st/ Wired.com], 2008'').

== Thoughts on a Microformat for News ==

We found significant overlap with [[hAtom]], and simplified an initial effort at a data format for news away from describing any fields already in [[hAtom]], or the superset [http://www.atomenabled.org/ Atom], with the expectation that future versions of that draft specification would approach feature parity. Instead, we focused on those news fields not in [[hAtom]].

In much the same way that one extends [http://www.atomenabled.org/ Atom], we are looking to extend [[hAtom]] with the most vital news-specific fields.

The fields we've selected are a combination of the common fields from many of the news formats currently in use, and the introduction of one new field, '''principles'''.

=== Common News Fields ===

* [[hAtom]] fields
* '''source-org''': the source organization for this particular news story--should be considered different from the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.source atom:source element] because it does not represent the source feed, but rather the source organization (and so should use [[hCard]]). We're using ''source-org'' to avoid name conflict with [[hAtom]] should the draft decide to include the ''atom:source'' element.
* '''dateline''': using text or [[hCard]], not to be confused with date (see [http://en.wikipedia.org/wiki/Dateline dateline] for more information).
** would an [[hCalendar]] event (which can contain an hCard location) make sense for a dateline, or is the 'date' part more often omitted? [[User:Kevin Marks|Kevin Marks]] 18:32, 24 August 2009 (UTC)
** Confusingly, the journalistic term "dateline" isn't anything to do with a date or time. It is the location from which a report is filed and is generally the main location associated with a story. Generally, a dateline consists of a city (e.g. "Rome") but could be the name of a ship at sea or even a space station. [[User:Stuart Myles|Stuart Myles]] 21:12, 24 August 2009 (UTC)
* '''geo''': using [[geo]], a simple way of providing the information necessary for services for readers around local news content
** is geo really in use here, or would using an hCard (that can contain geo) be a better way of representing locations referred to in the story, as more human readable? [[User:Kevin Marks|Kevin Marks]] 18:32, 24 August 2009 (UTC)
* '''item-license''': to express licensing around the item
** using [[rel-license]] presumably? [[User:Kevin Marks|Kevin Marks]] 18:32, 24 August 2009 (UTC)
* '''principles''': using the draft format [http://newscredit.org/development/newscredit-specification/rel-principles-specification/ rel-principles]

== Naming ==

Here are candidate names for a news microformat:

* hNews

news-examples

2009-08-13T20:51:38Z

Smyles: /* News on publisher sites */

= News Examples =

This page serves to document the current list of news examples from real world sites for the design of a simple news [[microformat]]. -[http://jonathanmalek.com/wp Jonathan Malek]

__TOC__

== Contributors ==

* Jonathan Malek
* Stuart Myles
* Martin Moore
* Mark Ng
* Ben Campbell

== The Problem ==
There have been several efforts to define data formats for textual news content: most focus on the exchange of news information between organizations, rather than the presentation of news on the web. Where presentation has been considered, it has more often than not been without a focus on exposing the semantic value present in each story. And finally, in those cases where there has been an effort to use a [[microformat]] or similar means of exposing semantic value (for example, using [[hAtom]] to markup a blog post), the data format does not fully describe the news story, leaving important data unparseable.

== Real World Examples ==

=== News hosted on aggregator sites ===

* [http://news.yahoo.com Yahoo! News]
** Source: Associated Press
*** Headline
*** [http://en.wikipedia.org/wiki/Byline Byline]
*** Source Organization
*** Updated date and time
*** Content
**** [http://en.wikipedia.org/wiki/Dateline Dateline]
*** Contributor declaration
*** License or Copyright statement
*** Categories
** Source: Reuters
*** Headline
*** Source Organization
*** Updated date and time
*** Content
**** [http://en.wikipedia.org/wiki/Dateline Dateline]
**** Entities (inline)
*** [http://en.wikipedia.org/wiki/Byline Byline]
*** Contributor declaration
*** License or Copyright statement
*** Categories
** Source: McClatchy Newspapers
*** Headline
*** Source Organization
*** [http://en.wikipedia.org/wiki/Byline Byline]
*** Updated date time
*** Content
**** [http://en.wikipedia.org/wiki/Dateline Dateline]
**** Entities (inline)
*** Contributor declaration
*** Related Stories

=== News on publisher sites ===

* [http://www.sacbee.com Sacramento Bee]
** Headline
** [http://en.wikipedia.org/wiki/Byline Byline]
*** Journalist contact
** Created (published) date time
** Updated date time
** Content
** Contributor declaration
** Categories (tags)
* [http://www.reuters.com Reuters]
** Headline
** Updated date time
** [http://en.wikipedia.org/wiki/Byline Byline]
*** Title
*** Contact
** Content
*** [http://en.wikipedia.org/wiki/Dateline Dateline]
*** Entities (inline)
** License or Copyright statement
* [http://www.nytimes.com New York Times]
** Headline
** [http://en.wikipedia.org/wiki/Byline Byline]
** Created date (no time)
** Content
*** [http://en.wikipedia.org/wiki/Dateline Dateline]
*** Entities (inline)
** Contributor declaration
** Related Stories/Past Coverage
* [http://www.guardian.co.uk The Guardian]
** Headline
** [http://en.wikipedia.org/wiki/Byline Byline]
** Created date and time
** Updated date time
** Content
*** [http://en.wikipedia.org/wiki/Dateline Dateline]
*** Entities (inline)
** Contributor declaration
** Article history
** Related Stories/Past Coverage

''Notes:'' Inline Entities can be thought of as a form of rel-tag inline with the rest of the story. Typically, the links take you to an "authority" page that contains a list of links to stories related to the entity.

== Analysis of Examples ==

=== Common news fields ===
* headline
* [http://en.wikipedia.org/wiki/Byline Byline]
* [http://en.wikipedia.org/wiki/Dateline Dateline]
* content
* published date time
* updated date time
* categories (tags)
* source organization (which may differ from journalist's organization)
* license

== See Also ==
* [[news-formats]]
* [[news-brainstorming]]

= Original news-examples rationale =

Microformats have many benefits for news reporting:

* Distributed Reporting

News can be reported on various platforms and services, and be identified, aggregated, and re-distributed to local aggregators and wire services.

* Pro-Am Journalism

Microformats allow anyone to report news without needing to use an exclusive or proprietary application. So long as other services can perform searches or real-time analysis of incoming items, news content can be recognized.

* Topical Filtration

As the volume of news increases, rel-tags and more news-specific microformats can be by topic-specific services to filter news content.

* Content-Type Filtration

Specific news-related content such as statistics and quotes can be laid out automatically into [http://en.wikipedia.org/wiki/Infographic infographics]
and generally better-formatted presentation.

news-formats

2009-08-13T19:11:56Z

Smyles: /* XML News */

== ANPA 1312 ==

In the late 1970's, the NAA [http://www.naa.org/ Newspaper Association of America] standardized the seven bit news text transmission spec as ANPA 1312. It is still widely used in North and South America to transmit news from agencies to newspapers and web sites.

== IPTC 7901 ==

[http://www.iptc.org/cms/site/index.html?channel=CH0109 IPTC 7901]

In the early 1980's, IPTC [http://www.iptc.org http://www.iptc.org] published the IPTC 7901 "Recommended Text Transmission Format" [http://www.iptc.org/std/IPTC7901/1.0/specification/7901V5.pdf IPTC 7901 1995 Spec in PDF]. IPTC 7901 is based on NAA's ANPA format, although it has better support for internationalization of text.

== NITF ==

[http://www.nitf.org http://www.nitf.org]

NITF is the IPTC's News Industry Text Format. This widely-used format defines the content and structure of news text articles using XML DTD and Schema. It allows for a rich set of metadata to be supplied about a news article, both in the envelope and embedded in the text.

== NewsML ==

[http://www.iptc.org/cms/site/index.html?channel=CH0106 NewsML 1]
[http://www.iptc.org/cms/site/index.html?channel=CH0111 NewsML-G2]

IPTC's NewsML is XML markup for specifying the structure and relationship metadata for the exchange of news items. IPTC continues to maintain both the original NewsML 1 and NewsML-G2, the latest version of NewsML, which is part of the family of G2 standards [http://www.iptc.org/cms/site/single.html?channel=CH0087&document=CMS1206527645546 IPTC G2 Standards]

== XML News ==

[http://www.xmlnews.org/XMLNews/ XML News]

XMLNews consists of two specifications - XMLNews-Story (a news text format, based in part on IPTC's NITF) and XMLNews-Meta (a format for news metadata format, which leverages W3C's RDF [http://www.w3.org/RDF/ W3C RDF]). Various news providers and aggregators have used XMLNews, although the specifications are no longer actively maintained.

== PRISM ==

[http://www.idealliance.org/industry_resources/intelligent_content_informed_workflow/prism Publishing Requirements for Industry Standard Metadata]

PRISM is a set of XML metadata standards originally created by a consortium of magazine publishers. The standard is now managed by IDEAlliance [http://www.idealliance.org/]. The format can be expressed in either XML or RDF and it leverages standard vocabularies and date type formats, including some from Dublin Core and ISO.

news-formats

2009-08-13T19:03:10Z

Smyles: /* NewsML */

news-formats

2009-08-13T18:51:23Z

Smyles: /* ANPA 1312 */

news-formats

2009-08-13T18:31:06Z

Smyles: New page: == NITF == [http://www.nitf.org http://www.nitf.org] NITF is the IPTC's News Industry Text Format. This widely-used format defines the content and structure of news text articles using X...

== NITF ==

[http://www.nitf.org http://www.nitf.org]

NITF is the IPTC's News Industry Text Format. This widely-used format defines the content and structure of news text articles using XML DTD and Schema. It allows for a rich set of metadata to be supplied about a news article, both in the envelope and embedded in the text.

== NewsML ==

[http://www.iptc.org/cms/site/index.html?channel=CH0106 NewsML 1]
[http://www.iptc.org/cms/site/index.html?channel=CH0111 NewsML-G2]

IPTC's NewsML is XML markup for specifying the structure and relationship metadata for the exchange of news items. IPTC continues to maintain both the original NewsML 1 and NewsML-G2, the latest version of NewsML, which is part of the family of G2 standards [http://www.iptc.org/cms/site/single.html?channel=CH0087&document=CMS1206527645546 IPTC G2 Standards]