Microformats Wiki - User contributions [en]

project

2008-01-16T16:53:45Z

DannyAyers: /* Existing pattern */

<h1>Project</h1>
{{formatset|Project}}
'''Please note : This spec is under construction. For now, it is only a dump of ideas.'''
Work to develop a format to describe the various aspects of a public project like open-source software or other kinds of artistic distributions. One if its primary intent is to allow robots to automatically classify projects in a freshmeat  manner by browsing the web.

[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)

== Existing pattern ==
existing pattern for projects
* [http://usefulinc.com/doap/ DOAP: Description of a Project] (software project-specific)
* [http://dannyayers.com:88/xmlns/project/index.htm RDF Project Vocabulary] (general purpose)
* [http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique Program Evaluation and Review Technique]

== Related microformats ==
* [[hCalendar]] for timelines and milestones (?) and TODOs
* Ressources
** [[hCard]] for attending/participating" people (staff)
** [[product]] for stuff(?)
*** [[rel-payment]]
* [[hReview]] for debriefing
* [http://dannyayers.com:88/xmlns/hdoap/profile/index.xhtml hDOAP] is an unofficial microformat-like projection of DOAP into HTML, deployed at [http://doapspace.org doapspace.org] and cited in the [http://www.w3.org/2003/g/data-view GRDDL namespace doc]

== possible code example ==

<pre><nowiki>
<div class="project" id="urn:uuid:233f6e5d-2ad2-4b7e-a3fe-1b90ef2fef57">
<img class="logo" src="..." />
<span class="name">Microformats</span>
<span class="desc">An initiative to extract common patterns from POSH</span>

<h1>Some informations</h1>
<a href="http://microformats.org/" rel="home">The primary home page of the project.</a>
<a href="..." rel="source">Here you can find its source code.</a>
<a href="..." rel="release">Get the releases.</a>
<-- Every hCard is looked as a participant [including venues? ] -->

<h1>Project's tags</h1>
<ul>
<li class="tag">open</li>
<li class="tag">format</li>
<li class="tag">standard</li>
</ul>
</div>
</nowiki></pre>

== CSS selection specification ==

A good way to describe the structure, is to look at it trough the view of CSS selectors. Designers sometimes need wrappers, which makes it hard to keep a strict structure. If you used jQuery, you know what I mean.

<pre><nowiki>
.project[@id] : is an UUID (see http://ietf.org/rfc/rfc4122.txt).
A unique identifier for the project.
It is used to resolve name clashes.
.project .name : the content describes the project name.
Should not appear more that one time per project.
.project IMG.logo : the src is a link to the logo.
Can have different sizes with by adding "low | mid | high" classes.
.project A[@rel=home] : a project's home page
.project A[@rel=source] : a link to the project's source.
If it is a scm, it is generally solved by using different uris.
Like git:// or bzr:// or http+git://
.project A[@rel=release] : the linked pages contains file releases.
This page can contain hRelease microformat.
.project A[@rel=...] : many extensions can be imagined, like :
"blog | wiki | parent-project | ..."
.project .tag : the content describes a project tag. You can
have as many as you wish.
</nowiki></pre>

== to-do ==

* Lots of discussion I guess, to satisfy different kinds of projects
* Semantic approval of experts

== Notes ==

Please, keep the format simple. Unlike hCard, it doesn't follow an existing standard, which permits to keep it simple. I'd much more prefer to develop sub-standards instead of being verbose. For example, the uuid:.. or scm:// ones.

== Related ideas ==

* Release: semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.

project

2008-01-16T16:52:16Z

DannyAyers: /* Related microformats */

<h1>Project</h1>
{{formatset|Project}}
'''Please note : This spec is under construction. For now, it is only a dump of ideas.'''
Work to develop a format to describe the various aspects of a public project like open-source software or other kinds of artistic distributions. One if its primary intent is to allow robots to automatically classify projects in a freshmeat  manner by browsing the web.

[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)

== Existing pattern ==
existing pattern for projects
* [http://usefulinc.com/doap/ DOAP: Description of a Project]
* [http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique Program Evaluation and Review Technique]

== Related microformats ==
* [[hCalendar]] for timelines and milestones (?) and TODOs
* Ressources
** [[hCard]] for attending/participating" people (staff)
** [[product]] for stuff(?)
*** [[rel-payment]]
* [[hReview]] for debriefing
* [http://dannyayers.com:88/xmlns/hdoap/profile/index.xhtml hDOAP] is an unofficial microformat-like projection of DOAP into HTML, deployed at [http://doapspace.org doapspace.org] and cited in the [http://www.w3.org/2003/g/data-view GRDDL namespace doc]

== possible code example ==

<pre><nowiki>
<div class="project" id="urn:uuid:233f6e5d-2ad2-4b7e-a3fe-1b90ef2fef57">
<img class="logo" src="..." />
<span class="name">Microformats</span>
<span class="desc">An initiative to extract common patterns from POSH</span>

<h1>Some informations</h1>
<a href="http://microformats.org/" rel="home">The primary home page of the project.</a>
<a href="..." rel="source">Here you can find its source code.</a>
<a href="..." rel="release">Get the releases.</a>
<-- Every hCard is looked as a participant [including venues? ] -->

<h1>Project's tags</h1>
<ul>
<li class="tag">open</li>
<li class="tag">format</li>
<li class="tag">standard</li>
</ul>
</div>
</nowiki></pre>

== CSS selection specification ==

A good way to describe the structure, is to look at it trough the view of CSS selectors. Designers sometimes need wrappers, which makes it hard to keep a strict structure. If you used jQuery, you know what I mean.

<pre><nowiki>
.project[@id] : is an UUID (see http://ietf.org/rfc/rfc4122.txt).
A unique identifier for the project.
It is used to resolve name clashes.
.project .name : the content describes the project name.
Should not appear more that one time per project.
.project IMG.logo : the src is a link to the logo.
Can have different sizes with by adding "low | mid | high" classes.
.project A[@rel=home] : a project's home page
.project A[@rel=source] : a link to the project's source.
If it is a scm, it is generally solved by using different uris.
Like git:// or bzr:// or http+git://
.project A[@rel=release] : the linked pages contains file releases.
This page can contain hRelease microformat.
.project A[@rel=...] : many extensions can be imagined, like :
"blog | wiki | parent-project | ..."
.project .tag : the content describes a project tag. You can
have as many as you wish.
</nowiki></pre>

== to-do ==

* Lots of discussion I guess, to satisfy different kinds of projects
* Semantic approval of experts

== Notes ==

Please, keep the format simple. Unlike hCard, it doesn't follow an existing standard, which permits to keep it simple. I'd much more prefer to develop sub-standards instead of being verbose. For example, the uuid:.. or scm:// ones.

== Related ideas ==

* Release: semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.

social-network-portability

2007-12-02T19:05:57Z

DannyAyers: recommending inclusion of @profile to transparently provide foaf

<h1> Social Network Portability </h1>
{{TOC-right}}
Social network portability is one of several [[user-interface]] ideas and suggestions for working with microformats in the area of [[data-portability]].

== The Problem ==
Why is it that every single social network community site makes you:
* re-enter all your [[hcard-supporting-user-profiles|personal profile info]] (name, email, birthday, URL etc.)?
* re-add all your [[hcard-xfn-supporting-friends-lists|friends]]?

In addition, why do you have to:
* re-turn off notifications?
* re-specify privacy preferences?
* re-[[block]] [http://headrush.typepad.com/creating_passionate_users/2006/04/angrynegative_p.html negative people]?

AKA "social network fatigue problem" and "social network update/maintenance problem".

== The Goals ==
When you join a new site, you should be able to ''import'' or preferably ''subscribe'' to
* your profile information
* your social network
from any existing profile of yours.

In addition it would be nice if preferences around:
* notifications
* [[privacy]]
also transferred between profiles.

AKA a social internetwork, a network of social networks.

== Design Patterns and Recipes ==

The "How To" for social network profile sites that want to solve the above problems and achieve the above goals.

# Publish microformats in your user profiles:
## implement [[hcard|hCard]] on user profile pages, including [[xfn]] rel="me" on hyperlinks to users' blogs or home pages that they specify. See [[hcard-supporting-profiles]] for sites that have already done this.
## implement [[hcard|hCard]]+[[xfn|XFN]] on the list of friends on your user profile pages. Use [[xfn]] rel="me" to link to friends list pages and friends list pagination links too. See [[hcard-xfn-supporting-friends-lists]] for sites that already do this. (e.g. [[http://twitter.com/ Twitter]]).
## implement [[hcard|hCard]] wherever a user's name is mentioned in lists, in comments, in messages or wherever else it would help to identity that a "person" or "organization" is being referred to.
## include the appropriate profile attributes in the head element of documents containing microformats and ensure your markup is valid (with profiles attributes and XHTML, GRDDL-aware agents can transparently interpret [[hcard|hCard]]+[[xfn|XFN]] as FOAF/RDF data)
# Subscribe to microformats for your user profiles:
## when signing up a new user:
### let a user fill out and <em title="Auto-sync is more than just one-time import, check it and sync-up once a day.">"auto-sync"</em> from one of their existing [[hcard-supporting-profiles]], their name, their icon etc. [http://microformats.org/blog/2007/06/21/microformatsorg-turns-2/ Satisfaction Inc already supports this] ([http://staging.getsatisfaction.com/people/new sign up page]).
### let a user fill out and <em title="Auto-sync is more than just one-time import, check it and sync-up once a day.">"auto-sync"</em> their list of friends from one of their existing [[hcard-xfn-supporting-friends-lists|hCard+XFN supporting friends lists]]. [http://microformats.org/blog/2007/06/21/microformatsorg-turns-2/ Dopplr.com already supports this] ([http://www.flickr.com/photo_zoom.gne?id=576635008&size=o screenshot]).

== Resources ==
=== Groups ===
* [http://ma.gnolia.com/groups/PSN Ma.gnolia Portable Social Networks group] for aggregated bookmarks around the subject and join the group to share links.
* [http://upcoming.yahoo.com/group/3601/ Upcoming Social Network Portability group] for events to discuss and implement social network portability.
=== Open Source ===
* [[hKit]] - web service and open source PHP for parsing/importing/subscribing to [[hcard-supporting-profiles|hCard open user profiles]].
* "[http://opensocialgraph.plaxo.com/ Online Identity Consolidator]" rel="me" web parser/crawler web service and open source Python.
* "[http://django-psn.googlecode.com/svn/trunk/readme.html Django-PSN (portable social networks)]" open source for a user interface to create links on a social network profile to "other profiles" marked up with rel="me" naturally. The code can be seen in action on the [http://pownce.com Pownce] website, e.g. on [http://pownce.com/t/ a Pownce profile page that links to other profiles of the same user]. This is a great complement to the above Plaxo Online Identity Consolidator. What Django-PSN publishes, Plaxo Online Identity Consolidator parses.
* [http://code.google.com/p/identity-matcher/ identity-matcher] - Rails plugin to match identities and social network information from sites such as GMail, Twitter, Flickr, Facebook and any site supporting appropriate microformats. This code was extracted and contributed from Dopplr.
* [http://redmonk.net/projects/portable-social-network-lib/ Portable Social Network Lib] is a Ruby library for consuming/providing Portable Social Network services in social web apps, written by Steve Ivy. ([http://redmonk.net/archives/2007/11/07/if-you-love-your-users-set-them-free-portable-social-networks/ More])

=== User Interfaces ===
* "[http://gerardramos.com/mf/ Social Network Portability with Microformats]" - a user interface that lets you check how portable your social network is across various sites.

== Social Network Portability FAQ ==
See [[social-network-portability-faq]].

== Events ==
*[[events/2007-07-28-portable-social-networks-meetup|2007-07-28 portable social networks initial meeting]] between Daniel Burka, [[User:Tantek|Tantek Çelik]], Eran Globen, Brian Oberkirch at Ritual Coffee Roasters, San Francisco, CA. Discussed portable social networks, simplified and crystalized problem statement (with progressive problems to solve), goals, design patterns, recipes. Created [[social-network-portability]] page.
* [[events/2007-08-19-social-network-portability-today|2007-08-19 BarCampBlock session on social network portability TODAY]] at Princeton Review offices, High Street, Palo Alto, CA. Reviewed problem statement, how sites can use the [[hcard|hCard]] and [[xfn|XFN]] microformats *today* to become a node on the "open social web" (phrase introduced).
* [[events/2007-08-28-social-network-portability-today|2007-08-28 Social Network Portability Today]] lunchtime meetup
* [[events/2007-09-05-dconstruct-microformats-workshop|2007-09-05 d.Construct workshop on microformats]] which covered both [[data-portability]] and [[social-network-portability]].
* [[events/2007-09-08-social-network-portability|2007-09-08 BarCampBrighton session on social network portability]] at Madgex offices, North Street, Brighton, England.
* [[events/2007-09-25-social-network-portability|2007-09-25 Portable Social Network Micro Meetup]] at Citizen Space, San Francisco, CA, USA.
*[[events/2007-09-28-portable-social-networks-meetup-amsterdam|2007-09-28 Portable Social Network Panel]] at PICNIC in Amsterdam, Netherlands
* <span class="vevent"><span class="dtstart">2007-10-04</span> <span class="summary">[[events/2007-10-04-fundamentos-web-social-network-portability|Fundamentos Web: Social Network Portability]]</span> by Tantek Çelik — <span class="location adr"><span class="locality">Gijón</span>, <span class="country-name">Spain</span></span></span>
* ...

See the microformats [[events]] page for upcoming events related to social network portability.

== Articles and blog posts ==
Note: if you know of or can find earlier mentions on the web of the phrases "portable social network" or "social network portability", please add the earliest reference elsewhere on the web to this chronology. [[User:Tantek|Tantek]] 08:25, 22 Aug 2007 (PDT).

* 2006-11-15 Jon Hicks: [http://www.flickr.com/photos/hicksdesign/298271647/ The straw that broke this camels back]: <blockquote><p>Thats the last social service that involves me adding all my friends in all over again. Life is too chuffing short.</p><p>Please, can someone come up with some way of avoiding this repetition of 'buddies'?!</p></blockquote>
* <strong>2006-11-15</strong> [http://twitter.com/drewm/statuses/68199 Drew McLellan on Twitter]: (Perhaps the earliest mention of the concept of social network portability.) <blockquote><p>Thinking that we really need to join the dots with XFN and make social networks portable.</p></blockquote>
* <strong>2006-11-15</strong> [http://twitter.com/adactio/statuses/68412 Jeremy Keith on Twitter]: (first known reference to "<strong>portable social networks</strong>") <blockquote><p> Agreeing with Drew about using XFN to create portable social networks. If we don't, Jon is going to go postal.</p></blockquote> The mention of Jon is likely a reference to the [http://www.flickr.com/photos/hicksdesign/298271647/ above-mentioned Flickr photo].
* 2006-11-19 Phil Gyford: [http://www.gyford.com/phil/writing/2006/11/19/your_single_soci.php Your single social network] <blockquote><p>I really, really want a single service where I can say “these people are my friends” and then when I sign up to any new website I can sync it with my previously-defined social network.</p></blockquote>
* 2006-11-21 Jeremy Keith: [http://adactio.com/journal/1209/ Twittering]: <blockquote><p>Here’s what I want: when I go to the latest social networking fadsite, I want it to ask for my URL. Then it can go off and fetch my [[hcard|hCard]] and [[xfn|XFN]] list. A pre-filled form for my details and a pre-filled list of potential contacts can then be presented to me.</p></blockquote>
* 2006-11-21 Derek Featherstone: [http://www.boxofchocolates.ca/archives/2006/11/21/solving-problems-with-social-networking Solving problems with social networking]
* 2006-11-22 Thomas Vander Wal: [http://www.personalinfocloud.com/2006/11/following_frien.html Following Friends Across Walled Gardens] - first mention of "portable social network" but in reference to quoting Jeremy Keith
* 2006-11-23 Jeremy Keith: [http://adactio.com/journal/1212/ More thoughts on portable social networks] - describes the process of portability
* 2006-11-23 Glenn Jones: [http://www.glennjones.net/Post/820/Microformatsandportablesocialnetwork.htm Microformats and portable social network] - talks about portable social networks in the backnetwork
* 2006-11-23 Velvetsarah has [http://www.velvet.id.au/2006/11/23/portable-social-networks/ posted a screenshot and brainstorm] about how a site could handle importing XFN enabled contacts. See [[social-network-portability-interfaces]] for more.
* <strong>2006-11-24</strong> [http://microformats.org/wiki?title=user-interface&diff=10524&oldid=10523 "<strong>social network portability</strong>" phrase and problem statement introduced to microformats wiki] by [[User:Tantek|Tantek Çelik]]
* 2007-03-11 Robert Gaal: [http://www.53miles.com/archives/making-openid-your-only-online-profile-alpha-dash Making OpenID your only online profile: Alpha Dash] - An abstract attempt to create one dashboard, to be used as a starting point for all social networks. It contains four elements: identity, ownership, presence and contacts (see comments also)
* 2007-05-16 [http://2007.xtech.org/public/schedule/paper/69 What is your provenance?] by Gavin Bell for Xtech 2007. Also available on [http://video.google.com/videoplay?docid=-8663100900373306094 Google Video]
* 2007-06-20 Alper Çuğun: [http://fourstarters.com/2007/06/20/the-future-of-everything-is-social-consolidate-and-take-back-your-social-network/ The Future of Everything is Social: Consolidate and take back your social network]
* 2007-07-17 Kevin Lawver: [http://www.lawver.net/archive/2007/07/17/h12_portable_social_networks_at_mashup_camp.php A Portable Social Network Prototype] - A simple Ruby on Rails app that uses OpenID + XFN to look for users of the site w/ the same homepage as the href value and allows you to add them as contacts.
*[http://www.plaxo.com/about/releases/release-20070718 2007-07-17 Plaxo Pushes For "Open Social Web": Endorses and implements key open standards, OpenID and microformats]
* 2007-07-18 Jeremiah Owyang: [http://twitter.com/jowyang/statuses/156097392 Twittering]: <blockquote><p>What if we could port all our friends and family from one social network to another. Why do we have to continue to add people = annoying</p></blockquote>
* 2007-07-18 Brian Oberkirch: [http://www.brianoberkirch.com/2007/07/18/highrise-microformats-and-portable-social-networks/ Highrise, microformats and portable social networks]
* 2007-07-24 Thomas Vander Wal: [http://vanderwal.net/random/entrysel.php?blog=1937 Sharing and Following/Listening in the Social Web]
* See [[events/2007-07-28-portable-social-networks-meetup#blog_posts|blog posts following up]] from the [[events/2007-07-28-portable-social-networks-meetup|2007-07-28-portable social networks meetup]].
* 2007-08-01 Jeffrey Zeldman: [http://www.zeldman.com/2007/08/01/social-network-portability/ "InterNetwork" regarding social network portability]
* 2007-08-02
** [http://www.brosbeforeblogs.com/2007/08/identity-crisis.html Identity Crisis part 1] <blockquote><p>We need to put the ownership of how we define relationships online in the hands of the individual, not the services that utilize them.</p><p>My theory on how this should be accomplished is based on a marriage of OpenID and an open standard for defining relationships such as the [[XFN]] [http://microformats.org/ Microformat]. </p></blockquote>
** [http://www.brianoberkirch.com/2007/08/02/deeelightful-making-profile-import-a-snap/ Deeelightful: Making Profile Import a Snap] <blockquote><p>Why not make it simple for them to jumpstart a profile by reusing information they already have on the [[hcard|Web? Some forward thinking Web services are marking up user profile data with hCard, a microformat that]] signifies a person, place or organization is being described.</p></blockquote>
* 2007-08-08 Brian Oberkirch: [http://www.brianoberkirch.com/2007/08/08/building-blocks-for-portable-social-networks/ Building Blocks for Portable Social Networks]
* 2007-08-15 [http://news.bbc.co.uk/1/hi/technology/6944653.stm Pull down the walled gardens] Internet law professor Michael Geist says the walled gardens of social networks should be pulled down.
* 2007-08-16 Stephanie Booth: [http://climbtothestars.org/archives/2007/08/16/we-need-structured-portable-social-networks-spsn/ We Need Structured Portable Social Networks (SPSN)] (links to two more posts on the subject, but not certain they're relevant enough for a separate listing; edit as you see fit)
* 2007-08-17 [http://bradfitz.com/social-graph-problem/ Thoughts on the Social Graph] by Brad Fitzpatrick.
* 2007-08-25 [http://www.ignitesocialmedia.com/linking-it-all-%e2%80%93-social-network-portability/ Linking It All-Social Network Portability] by Mike Lotz for Ignite Social Media
* 2007-09-03 [http://themaninblue.com/writing/perspective/2007/09/03/ There are no social networks] by Cameron Adams
<blockquote><p>If you can't see my friends and let my friends be seen, you'll be washed up and hung out to dry.</p></blockquote>
* 2007-09-07 [[User:LynX|Carlo v. Loesch]]: [http://about.psyc.eu/Social_network#But.._why_microformats.3F Privacy and the web? Notification and HTTP? Are you looking at the right technologies!?]
* 2007-11-21 Sitepoint article [http://www.sitepoint.com/article/social-networks-take-friends Portable Social Networks: Take Your Friends with You]

See [http://ma.gnolia.com/groups/PSN ma.gnolia Portable Social Network Group] for aggregated bookmarks around the subject and join the group to share links.

[http://technorati.com/search/microformats.org/wiki/social-network-portability View blog reactions] to this page.

== Issues ==
* Beware of and avoid [[social-network-anti-patterns]]!
* See and add to [[social-network-portability-issues]].

== Alternative Approaches ==
Non-web based:
* [http://about.psyc.eu psyc] and [http://www.psyced.org psyced], a decentralized multi-protocol chat and event notification system with [http://about.psyc.eu/Social_Network friendship] and [http://about.psyc.eu/Trust trust] modeling.

== See also ==
* [[social-network-portability-interfaces]]
* [[social-network-portability-faq]]
* [[social-network-portability-issues]]
* [[social-network-anti-patterns]]
* [[hcard|hCard]]
* [[xfn]]
* [[user-interface]]
* [[data-portability]]

hcalendar-profile

2007-02-05T09:33:05Z

DannyAyers: moved XMDP profile link up the page

''Here's a first pass at a
[http://dannyayers.com/microformats/hcalendar-profile XMDP Profile for hCalendar]''

'''vcalendar''' - A container for one or more events (vevent). This property is optional; if there is only one event then omit it

'''vevent''' - A container for one event

'''dtstart''' - Date/time of the start of the event

'''dtend''' - Date/time of the end of the event

'''duration''' - Length of the event

'''summary''' - Short synopsis of the event, or the title of the event, or the name of the event

'''uid''' - A globally unique identifier for the event; typically a URL is used

'''dtstamp''' - Date/time of when the document containing information about the event was created

'''method''' - Values for this property are: PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINECOUNTER. For example, a value of REQUEST indicates that a request is being made for the event to occur

'''category''' - Common values are: MEETING, APPOINTMENT, CONFERENCE, EXPO. Note: this property may be repeated (an event may belong in several categories)

'''location''' - Tells where the event is to be held

'''url''' - A URL to a page that contains the definitive/preferred information about an event; uid and url are typically the same

'''description''' - A more detailed synopsis of the event than that provided by summary

'''last-modified''' - Date/time the information about the event was updated

'''status''' - Values are: TENTATIVE, CONFIRMED, CANCELLED

'''class''' - Access classification of the event information; values are: PUBLIC, PRIVATE, CONFIDENTIAL

== Related Pages ==
{{hcalendar-related-pages}}

hreview-profile

2007-02-05T09:31:40Z

DannyAyers: link to XMPD profile first pass

@@ todo: this is not a complete XMDP profile, update to proper DL/DD/DT also need to figure out how to connect the hCard/hCalendar profiles into this profile as well.

''Here's a first pass at a [http://dannyayers.com/micromodels/profiles/hreview XMDP profile for hReview]''

* '''dtreviewed''': date/time the review was written.

* '''summary''': a short synopsis of the review, the title of the review.

* '''reviewer''': the hCard of the person who is doing the review.

* '''item''': the thing (product, event, business, etc) being reviewed. This property contains these subproperties (which all come from hCard):
:'''fn''': the formatted name of the thing being reviewed (e.g., if the thing being reviewed is a book, then fn is the book title; if the thing being reviewed is a movie then fn is the name of the movie).
:'''url''': the URL to the thing being reviewed (e.g., if the thing being reviewed is a company that paints houses, then url is the URL to their web site).
:'''photo''': a URL to the thing being reviewed (e.g., if the thing being reviewed is a book, then photo is the URL to a photo of the book).

* '''rating''': a rating of the thing being reviewed. The default rating scale is 1.0 - 5.0, where 1.0 represents the lowest rating and 5.0 represents the highest rating. There are two optional subproperties - worst and best - for use when a different rating scale is desired.

* '''type''': the kind of thing being reviewed. Legal values are:
:product, event, business, person, place, website, url.

* '''description''': the full text of the opinion of the reviewer.

* '''rel=tag''': use the Rel-tag microformat to associate a tag with the thing being reviewed.

* '''permalink''': a permalink is a long-lived URL. If the review is embedded within a web page that is continually being updated, a permalink is a permanent link to the review (even if the review is moved off the web page). Web tools that index reviews may use this property as a unique ID for collating reviews from multiple sources.

* '''rel=license''': use the Rel-license microformat to associate a license with the review.

* '''version''': use to indicate the version of the hReview specification being used. This tutorial is describing version 0.3

hcalendar-profile

2007-02-02T13:21:10Z

DannyAyers: first pass at XMDP Profile linked

'''vcalendar''' - A container for one or more events (vevent). This property is optional; if there is only one event then omit it

'''vevent''' - A container for one event

'''dtstart''' - Date/time of the start of the event

'''dtend''' - Date/time of the end of the event

'''duration''' - Length of the event

'''summary''' - Short synopsis of the event, or the title of the event, or the name of the event

'''uid''' - A globally unique identifier for the event; typically a URL is used

'''dtstamp''' - Date/time of when the document containing information about the event was created

'''method''' - Values for this property are: PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINECOUNTER. For example, a value of REQUEST indicates that a request is being made for the event to occur

'''category''' - Common values are: MEETING, APPOINTMENT, CONFERENCE, EXPO. Note: this property may be repeated (an event may belong in several categories)

'''location''' - Tells where the event is to be held

'''url''' - A URL to a page that contains the definitive/preferred information about an event; uid and url are typically the same

'''description''' - A more detailed synopsis of the event than that provided by summary

'''last-modified''' - Date/time the information about the event was updated

'''status''' - Values are: TENTATIVE, CONFIRMED, CANCELLED

'''class''' - Access classification of the event information; values are: PUBLIC, PRIVATE, CONFIDENTIAL

== Related Pages ==
{{hcalendar-related-pages}}

[http://dannyayers.com/microformats/hcalendar-profile XMDP Profile] first pass

User:DannyAyers

2006-11-13T23:32:32Z

DannyAyers:

Semantic Web fan, working on GRDDL, lives in Italy, likes furry animals

[http://dannyayers.com Raw Blog]

User:DannyAyers

2006-11-13T23:31:22Z

DannyAyers:

Semantic Web fan, working on GRDDL, lives in Italy, likes furry animals

http://dannyayers.com

irc-people

2006-11-13T23:28:24Z

DannyAyers: added myself

A list of [[irc|IRC]] regulars and their normal timezones. (winter/summer)

* [[User:BenWest|bewest]] (-0800/-0700)
* [[User:Adam Craven|AdamCraven]] (+0000)
* [[User:Amette|amette]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)
* [[User:Ben Ward|BenWard]] (+0000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:Boneill|boneill]] (+0000)
* [[User:Brian|briansuda]] (+0000)
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)
* [[User:Cgriego|cgriego]] (-0600/-0500)
* [[User:CharlesRoper|charles_r]] (0000/+0100)
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)
* [[User:ChristopherStJohn|cks]] (-0600/-0500)
* [[User:Cloud|Cloud]] (+0000)
* [[User:DanC|DanC]] (-0600/-0500)
** office hours: Wednesday afternoons, America/Chicago time
* [[User:DannyAyers|danja]] (+0100/+0200)
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:DeanEro|deanero]] (-0800/-0700)
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)
* [[User:EdwardOConnor|hober]] (-0800/-0700)
* [[User:Enric|enric]] (-0800/-0700)
* [[User:Evan|evanpro]] (-0500)
* [[User:Fil|Fil]] (+0200)
* [[User:Grantbow|Grantbow]] (-0800/-0700)
* [[User:Hlb|hlb]] (+0800-0700)
* [[User:IanHickson|Hixie]] (-0800/-0700)
* [[User:Izo|IZO]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)
* [[User:JasonK|jkridner]]] (-0600/-0500)
* [[User:Kapowaz|kapowaz]] (+0000/+0100)
* [[User:Keri Henare|kerihenare]] (+1200)
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)
* [[User:CiaranMc|McNulty]] (+0000/+0100)
* [[User:neuro|neuro`]]
* [[User:Phae|Phae]] (+0000/+0100)
* [[User:PriitLaes|plaes]] (+0200/+0300)
* [[User:DavidOsolkowski|qid]] (-0500)
* [[User:Remi|Remi]] (-0500/-0400)
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)
* [[User:Ronnos|Ron Kok]] (+0000)
* [[User:RyanKing|kingryan]] (-0800/-0700)
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* [[User:Csarven|csarven]] (-0500/-0400)
* [[User:Dana Benson|Snowden]] (-0800/-0700)
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)
* [[User:Tantek|Tantek]] (-0800/-0700)
* [[User:Trovster|trovster]] (-0800/-0700)
* [[User:Dan Kubb|dkubb]] (-0800/-0700)
* [[User:Ed Summers|edsu]] (-0500/-0400)
* [[User:Smackman|Steve Farrell]] (-0800/-0700)
* [[User:Enric|Enric]] (-0800/-0700)
* [[User:Charlvn|Charl]] (+0200/+0200)
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)
* [[User:Vant|vant]] (+0900)
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)
* [[User:IwaiMasaharu|iwaim]] (+0900)
* [[User:Richard Conyard|WhiskeyM]] (+0000)
* [[User:Veeliam|William Lawrence]] (-0800/-0700)
* [[User:Ianloic|yakk]] (-0800/-0700)
* [[User:Ashley|Ashley]] (+1000)
* [[User:SuperPhly|SuperPhly]] (-600/-500)
* [[User:Colin_Barrett|cbarrett]] (-1000)
* [[User:HenriBergius|bergie]] (+0200/+0300)
* [[User:JacksonWilkinson|whafro]] (-0500/-0400)

hatom-issues

2006-02-05T21:14:55Z

DannyAyers: +1 for "hentry"

= hAtom issues =

__TOC__

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' '''

=== Initial proposal ===

<code>atomfeed</code> (or rather, "atom-entry")

* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** hfeed

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

* <code>feed</code> (Atom consistency)
* <code>atom-feed</code> (Atom consistency with prefix)
* <code>hfeed</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 MarkRickerby
** +1 DannyAyers

==== Discussion ====

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Initial Proposal ===

<code>atomentry</code> (or rather, "atom-entry")

* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[DavidJanes]]
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[MarkRickerby]]
** +1 [[DannyAyers]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p>

== Entry Title (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'headline' '''

=== proposals ===

The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[Tantek]]
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[BenjaminCarlyle]], atom:entry/title only
** +½ [[DavidJanes]], atom:entry/title only
** +½ [[PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[DavidJanes]] see my note below
** -1 [[Tantek]] (does not mean the "name" of the post/entry)
** +1 [[BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==
* <code>content</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion

=== Discussion ===
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 KevinMarks

=== Discussion ===
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

* <code>rel="bookmark"</code> (HTML consitency)
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 KevinMarks

=== Discussion ===
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with "dt" unofficial pattern)
* <code>VJOURNAL CREATED</code>

=== Discussion ===
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.

== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +½ Paul Bryson, Not as human readable
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards

== Entry Author (atom:author) ==
* <code>author</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]

=== Discussion ===
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is <address> not sufficient for 'author' semantics?

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

=== Discussion ===
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''

== Entry Geo (geo:Point) ==
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

=== GeoRSS Resources ===
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions and Comments ==

=== Limitations ===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

=== Relationship to hReview definitions needs clarification ===
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

[[Tantek]]: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

=== hCards ===

[[DavidJanes]]: Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>

=== Comparisons ===

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--[[Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

=== Repeated Elements ===
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].

Your thoughts please... -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.

=== Opaqueness ===
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.

==== Opaqueness of other microformat elements ====
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- [[BenjaminCarlyle]]

* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.

==== Opaqueness of summary and content ====
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

=== Identification ===
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

=== HTML Title ===
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

=== rel-tag ===
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]

* [[Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

=== Excess disambiguation rules? ===
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

=== Dependencies ===
==== mfo ====
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples]].

=== Is atom:content necessary? ===
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

=== Published as default value for atom:updated ===
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

hatom-issues

2006-02-05T21:13:04Z

DannyAyers: /* Alternatives */

= hAtom issues =

__TOC__

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' '''

=== Initial proposal ===

<code>atomfeed</code> (or rather, "atom-entry")

* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** hfeed

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

* <code>feed</code> (Atom consistency)
* <code>atom-feed</code> (Atom consistency with prefix)
* <code>hfeed</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 MarkRickerby
** +1 DannyAyers

==== Discussion ====

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Initial Proposal ===

<code>atomentry</code> (or rather, "atom-entry")

* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[DavidJanes]]
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[MarkRickerby]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p>

== Entry Title (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'headline' '''

=== proposals ===

The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[Tantek]]
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[BenjaminCarlyle]], atom:entry/title only
** +½ [[DavidJanes]], atom:entry/title only
** +½ [[PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[DavidJanes]] see my note below
** -1 [[Tantek]] (does not mean the "name" of the post/entry)
** +1 [[BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==
* <code>content</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion

=== Discussion ===
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 KevinMarks

=== Discussion ===
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

* <code>rel="bookmark"</code> (HTML consitency)
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 KevinMarks

=== Discussion ===
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with "dt" unofficial pattern)
* <code>VJOURNAL CREATED</code>

=== Discussion ===
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.

== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +½ Paul Bryson, Not as human readable
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards

== Entry Author (atom:author) ==
* <code>author</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]

=== Discussion ===
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is <address> not sufficient for 'author' semantics?

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

=== Discussion ===
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''

== Entry Geo (geo:Point) ==
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

=== GeoRSS Resources ===
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions and Comments ==

=== Limitations ===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

=== Relationship to hReview definitions needs clarification ===
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

[[Tantek]]: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

=== hCards ===

[[DavidJanes]]: Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>

=== Comparisons ===

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--[[Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

=== Repeated Elements ===
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].

Your thoughts please... -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.

=== Opaqueness ===
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.

==== Opaqueness of other microformat elements ====
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- [[BenjaminCarlyle]]

* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.

==== Opaqueness of summary and content ====
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

=== Identification ===
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

=== HTML Title ===
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

=== rel-tag ===
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]

* [[Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

=== Excess disambiguation rules? ===
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

=== Dependencies ===
==== mfo ====
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples]].

=== Is atom:content necessary? ===
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

=== Published as default value for atom:updated ===
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

distributed-conversation-brainstorming

2006-01-22T23:55:22Z

DannyAyers: ref to IBIS

=citeRel brainstorming=
Various parties have proposed microformats related to citations and distributed conversations. Ryan King and Eran Globen started with hVia (which became citeVia and later citeRel :-)). You can see the conversation in these blog posts:

People already cite their sources in their blog posts and it would be great (and shouldn't be too difficult) to track that information. In that vein, read [http://theryanking.com/blog/archives/2005/05/06/hvia/ this post] which covers the initial thinking on the topic. ([http://theryanking.com/blog/archives/2005/05/09/citevia/ This] was a followup post).

Later, [http://hellononline.com Eran] [http://hellonline.com/blog/?p=18 expanded the idea] to encompass not just via citations, but replies and updates as well. Follow up post [http://hellonline.com/blog/?p=19 here].

[[distributed-conversation-examples]]

==Problem==
The basic idea we're trying to solve here is the tracking of distributed conversation- more specifically, distributed conversation between blog posts– the scope is intentionally limited here, though other aspects of distributed conversation are certainly important and related.

:A smaller portion of the problem is in identifying the most authoritative sources in a web-wide thread. In researching anything, the ability to identify a primary source is invaluable. Adding this kind of ordinality would add value to any list of related links such as a tag page.

::Finding an authoritative source is not a smaller problem, but a larger problem- you have to have the whole conversation graph in order to find the root nodes. --RyanKing

:::The definition of Authority here is murky at best. This is far beyond the scope of this discussion. --[[User:EranGloben|EranGloben]] 13:41, 21 Jan 2006 (PST)

:Citing (quoting or refering to as an authoritative source or precedent) and hat-tipping (giving credit to a non-primary source for calling attention to a primary [authoritative] source) are certainly two different animals. Common etiquette suggests use of anchor tags because they can be actuated by the user.

:I dug around at [http://www.w3.org WC3] and found rel="cite" is ''already defined'' in the [http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-metaAttributes.html XHTML Metainformation Attributes Module]. In the [http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-hyperAttributes.html XHTML 2.0 Hypertext Attribute Collection], href and cite attributes are defined and may coexist but they behave differently: The href attribute "specifies a URI that is actuated when the element is activated." For the cite attribute, "User Agents MUST provide a means for the user to actuate the link."

::This has already been covered in the above blog posts. Admitedly, it needs to be brought into this document, though. --RyanKing

:Whereas authors in general like their work to be cited with hyperlinks, and whereas users can be counted upon to cite primary and non-primary sources simultaneously without differentiating them, and whereas the only difference between a primary citation and a non-primary citation is the potential for skipped vias when considered across a distributed conversation, and whereas the use of existing specifications is preferred to the creation of redundant systems, and whereas increasing attributes is less severe than increasing nested elements, I propose that good definition and use of rel="cite" will resolve the problem of crediting sources via anchors. <cite>Andy Skelton</cite>

::I see the conclusion as quite the opposite. Because rel="cite" *is* defined in XHTML2 drafts, and microformats allow you add rel values to HTML4/XHTML1 *now*, adopting the same convention makes a lot of sense.

::If anything it bolsters the case for rel="cite" (as opposed to some other value like rel="source").

::In a relCite microformat, you would define the "cite" value by normatively referencing XHTML2, rather than redefining it (even copy/pasting the definition from the XHTML2 spec -- though one could do so "informatively"), just like in [[hcard|hCard]], we define the properties by normatively referencing vCard. <cite>Tantek</cite>

:::[http://www.w3.org/TR/2005/WD-xhtml2-20050527/ XHTML 2.0] states that it "should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever." <cite>Andy Skelton</cite>

:There is a related problem which is not exactly the same. Let's say that you have a bit of microformatted data which implies an assertion, and the asserter is the containing page. For example a relTag might have semantic value like "I claim that this object is a FOO." When that assertion is copied over to a new page, the identity of the asserter has to be made explicit: "according to the original containing page at BAR, this object is a FOO." Now let's say somebody copies over the copy. This might happen if there was a B-lister who had an entry picked up by an A-lister, and the A-lister's entry was then copied by a vast number of C-listers. (That's a typical pattern for data diffusion). For the data to keep its integrity, the source of the citation would always have to be the original containing page (the B-lister) rather than the containing page that the copy was fetched from (the A-lister). <cite>Lucas Gonze</cite>

::Lucas- that's why God invented <blockquote>. Content ''copied'' from one site to another should be quoted. --RyanKing

::The question isn't about whether something was copied but what the cite source is. This is a case where the difference between a primary citation and a non-primary citation affects the meaning of the data. <cite>Lucas Gonze</cite>

::This illustrates the difference between types of citations. C quoting A's text found on B's blog. C would use a reply or forward type citation when referencing A's text and would add a via type citation when mentioning his source, B. --[[User:EranGloben|EranGloben]] 13:41, 21 Jan 2006 (PST)

:I have a related problem that may shed some light on this one. I came to this page because I was just looking at a scientific journal citation and thought "that could be a microformat." There are already standard formats for citations of all sorts, including websites (e.g. [http://owl.english.purdue.edu/handouts/research/r_mla.html Modern Language Association]), so maybe converting these into microformats would solve the problem stated here, and more. -- Scott Reynen

== Nested cite/anchor tags ==

== rel="cite" / rev="cite" ==

This could be a way to indicate a citation of linked content, typically web pages (or portions thereof, like blog posts) but inclusive of any kind of resource with a URL. "Cite" is defined as "to quote or refer to as a precedent or authority."

By adding <code>rel="cite"</code> to a hyperlink, an author could indicate that the destination of that hyperlink is an authoritative source or a precedent to the current page. rel="cite" would be used whether an author cites by quotation:
<pre><blockquote>Our liberty depends on the freedom of the
press, and that cannot be limited without being lost.
<a href="http://en.wikiquote.org/wiki/Thomas_Jefferson" rel="cite">
Thomas Jefferson</a></blockquote></pre>
or by reference only:
<pre><a href="http://example.com/joeschmoe/article/99/" rel="cite">
Joe Schmoe's latest rant</a> is wrong, wrong, wrong...</pre>

<code>rel="cite"</code> hyperlinks are intended to be visible links on pages and posts. Note that other markup may be used to indicate citation:
<pre><blockquote cite="http://en.wikiquote.org/wiki/Thomas_Jefferson">
Our liberty depends on the freedom of the press, and that cannot be
limited without being lost.<cite>Thomas Jefferson</cite></blockquote></pre>
but User Agents are not compelled to expose a link to the cited resource. Hyperlinks are preferred by most authors because they afford the user easy access to the cited resource.

== citeRel vs. relCite ==
For basic structure and markup of citations it has been suggested that we use the following:
<pre>

<a rel="cite" href="source.url">source.title</a>
</pre>
instead of
<pre>

<cite><a href="source.url">source.title</a></cite>
</pre>

There are several reasons to prefer the citeRel form over the relCite form of markup:
# citeRel uses only existing XHTML elements and values where relCite uses a new rel value.
# citeRel is easily extensible without breaking it's existing meaning.

==When is a bare href (not) a citation==
A href is a citation when:
* A blog entry refers to another entry or to a presentation, then talks about that entry or presentation. eg "I believe it was more or less the same <a href="...">presentation</a> he gave at SxSW this year" [http://theryanking.com/blog/archives/2005/05/06/hvia/ Ryan King].

A href is not a citation when:
* A blog entry refers to the author of an entry or presentation using the author's homepage url, then talks about the entry or presentation. eg "For my Internet Systems Research class last night, we had <a href="...">Tantek Çelik</a> come speak on microformats" [http://theryanking.com/blog/archives/2005/05/06/hvia/ Ryan King]
* A blog provides a blog-roll, or "recent bookmarks" panel

==Additional Resources==
* Thread Description Language - TDL is an RDF vocabulary for describing threaded discussions, such as Usenet, weblogs, bulletin boards, and e-mail conversations.
** http://www.eyrie.org/~zednenem/2002/web-threads/
** http://www.eyrie.org/~zednenem/2002/wtprofile/
* Usenet discussions used the references field which includes ALL referenced posts with the one replied to last in a space separated list.
** http://www.w3.org/Protocols/rfc1036/rfc1036.html See section 2.2.5
* [http://www.faqs.org/rfcs/rfc2076.html RFC2076 - Common Internet Message Headers] section 3.6 has the following:
** In-Reply-To - Reference to message which this message is a reply to.
** References - In e-mail: reference to other related messages, in Usenet News reference to replied-to-articles.
** See-Also - References to other related articles in Usenet News.
** Obsoletes - Reference to previous message being corrected and replaced.
** Supersedes - Commonly used in Usenet News in similar ways to the "Obsoletes" header described above. In Usenet News, however, Supersedes causes a full deletion of the replaced article in the server, while "Supersedes" and "Obsoletes" in e-mail is implemented in the client and often does not remove the old version of the text.
** Article-Updates - Only in Usenet News, similar to "Supersedes:" but does not cause the referenced article to be physically deleted.
** Article-Names - Reference to specially important articles for a particular Usenet Newsgroup.
** Try Googling around "IBIS" (Issue-Based Information Systems), it's an approach to collaborative problem solving that looks very like discussion threads, see also [http://collab.blueoxen.net/cgi-bin/wiki.pl?HomePage BlueOxen Wiki], [http://collab.blueoxen.net/cgi-bin/wiki.pl?MailingLists BlueOxen Mailing Lists]

reviews-formats

2006-01-18T20:36:15Z

DannyAyers: /* RDF Review Vocabulary */

= Current Reviews Formats =
There have been several efforts to define data formats for posting "reviews" of products, services etc. on the Web.

This page serves to document the current list of review schemas, formats, and efforts as background for the design of a simple reviews [[microformat]]. -[http://tantek.com/log/ Tantek]

Notice that '''author''' appears several times in the list below, and that it sometimes refers to the author of the review, and other times to the author of the book being reviewed. A parenthetical will be used to distinguish them now.

== Centralized Implementations ==
=== Insider Pages ===
Customer reviews of local businesses
* http://www.insiderpages.com

** author ''(review author)''
** rating (0 - 5 stars)
** business name
** review title
** review
** pros
** cons
** business category
** business address
** business phone number
** business e-mail address
** business website

=== Amazon.com ===
* http://www.amazon.com/

** author ''(book author)''
** publication date
** title
** description
** rating (1 to 5 stars)
*** overall and by category
**** declared value and a maximum possible value
* vote for or against component

==== Mini-review ====
Mini reviews are limited to products on some areas of the site.

* rating (1 to 5 stars)
** Their mini-review interface has an 'x,' but this does not mean a rating of '0,' but in their own verbiage 'Unrated.' So the interval is 1 to 5 starts, not 0 to 5 stars. --[[User:RyanKing|RyanKing]] 11:43, 18 Jan 2006 (PST)
* ownership status ([x] I own this)
* negative interest ([x] Not interested)

=== Blogcritics ===
* http://blogcritics.org/

* author ''(review author)''
* title
* publication date
* description
* reviewed work identifier
* reviewed work title
* reviewed work version
** release date
** Volume, issue
** edition
** translation
* reviewed work author(s)
* reviewed work publisher

=== Consumer Reviews ===
* reviewed item
* reviewed item version
* rating
** overall 1-100
** by category 1-5
* definition list of specifications

=== Epinions ===
* http://epinions.com/

* author ''(review author)''
* publication date
* title
* summary ("the bottom line")
* description
* rating overall and by category
* positive summary
* negative summary
* cost
* vote for or against product
* vote for or against review

=== Web site or page reviews ===
* http://en-us.sitereviews.org/
* http://www.stumbleupon.com/

=== Yahoo! Local ===
* http://local.yahoo.com/

* author ''(review author)''
* publication date
* title
* description
* rating
** overall and by category
* positive summary
* negative summary

==== Restaurant ====
* usage datetime
* specific use

=== Nearlocal ===
* http://www.nearlocal.com/

=== Yelp ===
* http://www.yelp.com/

=== SF Survey ===
* http://sfsurvey.com/

=== Zagat ===
* rating by category
* cost
* description

=== delicious 3rd party ===
* http://alf.hubmed.org/rvw.htm

* rating (0-100%)
* tags (keywords, year, user-specified others)
* artist/author ''(work author)''
* title
* URL
* comments
* unique identifier

=== iTunes XML ===
* rating (0-100%)

=== review world ===
* http://www.revieworld.com/

=== Dinner Buzz ===
* http://www.dinnerbuzz.com/

== Previous Schemas and Formats ==
=== Generic to any kind of review ===
==== RVW ====
* http://www.pmbrowser.info/rvw/0.2/
** http://hublog.hubmed.org/archives/000307.html <- this is a really old and out-of-date version
** http://www.pmbrowser.info/wiki.pl?RVW
* variants for embedding in Atom, RSS2, RSS1, RDF
* apparent schema
** author of review
** content of review
** creator of work
*** example: book author, movie director
** percentage score rating
** multiple identifiers
*** example: ISBN, ASIN, UPC, LOC
** link to purchase
* appears to be loosely connected with the term "!OpenReviews" (has also referred to other efforts) which itself appears to be yet another OpenBlahBlah buzzword with no substance behind it (AKA placeholder term).
==== RDF Review Vocabulary ====
* RDF Review Vocabulary: http://www.purl.org/stuff/rev
** Deployed in [http://trust.mindswap.org/FilmTrust/ FilmTrust], see e.g. [http://trust.mindswap.org/cgi-bin/FilmTrust/foaf.cgi?user=thejrnf user profile]
** Extended version used for StructuredBlogging/RDF transformation (e.g. see [http://incredibooks.com/index.php/2005/12/17/the-muffin-fiend/ sample review] there's a reference to [http://structuredblogging.org/subnode-to-rdf-interpreter.xsl subnode-to-rdf-interpreter.xsl] in the source).
** Used in [http://www.ldodds.com/blog/archives/000126.html AllConsuming Reading Lists in RDF]
** Used in [http://www.ldodds.com/blog/archives/000087.html FOAF-a-matic Mark 2]

==== Simple-Review XML ====
* Embeds XML in <script type="application/x-subnode">
* [http://structuredblogging.org/xmlns/simple-review.xsd XSD]
* apparent schema
** review-title
** item
*** name/title
*** type
*** URL
*** image URL
** rating (user visible, max, normalized to 0..1 value)
** comments/description

=== For specific domains ===
==== Movies ====
* [http://www.millikin.edu/mr/Entertainment/howto2.html How to Write a Movie Review]
==== Books ====
* RDF schema for book reviews: http://www.amk.ca/xml/reviews.html

* see also [[book-info-examples]]

== Thoughts on a Microformat ==
Thoughts towards a simple MicroFormat subset of earlier efforts, sufficient to express 80/20.

=== Common review fields ===
* item
** optional:type of item (business, Web page/site, product, event, person, place, file, text)
** name/title of item being reviewed (string | ["hCard"] if business or person)
*** optional:URL (all additional information should be somewhere else, not in the review itself)
*** optional:image (URL)
* reviewer (["hCard"]|name|email|URL)
* review publication/authoring date (ISO8601 datetime)
* rating 1 to 5 (default max = 5, default min = 1)
* optional:tags (keyword,rating)*
* optional:comments (string)

See [[hreview|hReview]] for the result and evolution of these thoughts on a microformat.

reviews-formats

2006-01-18T20:29:47Z

DannyAyers: /* REV */

= Current Reviews Formats =
There have been several efforts to define data formats for posting "reviews" of products, services etc. on the Web.

This page serves to document the current list of review schemas, formats, and efforts as background for the design of a simple reviews [[microformat]]. -[http://tantek.com/log/ Tantek]

Notice that '''author''' appears several times in the list below, and that it sometimes refers to the author of the review, and other times to the author of the book being reviewed. A parenthetical will be used to distinguish them now.

== Centralized Implementations ==
=== Insider Pages ===
Customer reviews of local businesses
* http://www.insiderpages.com

** author ''(review author)''
** rating (0 - 5 stars)
** business name
** review title
** review
** pros
** cons
** business category
** business address
** business phone number
** business e-mail address
** business website

=== Amazon.com ===
* http://www.amazon.com/

** author ''(book author)''
** publication date
** title
** description
** rating (1 to 5 stars)
*** overall and by category
**** declared value and a maximum possible value
* vote for or against component

==== Mini-review ====
Mini reviews are limited to products on some areas of the site.

* rating (1 to 5 stars)
** Their mini-review interface has an 'x,' but this does not mean a rating of '0,' but in their own verbiage 'Unrated.' So the interval is 1 to 5 starts, not 0 to 5 stars. --[[User:RyanKing|RyanKing]] 11:43, 18 Jan 2006 (PST)
* ownership status ([x] I own this)
* negative interest ([x] Not interested)

=== Blogcritics ===
* http://blogcritics.org/

* author ''(review author)''
* title
* publication date
* description
* reviewed work identifier
* reviewed work title
* reviewed work version
** release date
** Volume, issue
** edition
** translation
* reviewed work author(s)
* reviewed work publisher

=== Consumer Reviews ===
* reviewed item
* reviewed item version
* rating
** overall 1-100
** by category 1-5
* definition list of specifications

=== Epinions ===
* http://epinions.com/

* author ''(review author)''
* publication date
* title
* summary ("the bottom line")
* description
* rating overall and by category
* positive summary
* negative summary
* cost
* vote for or against product
* vote for or against review

=== Web site or page reviews ===
* http://en-us.sitereviews.org/
* http://www.stumbleupon.com/

=== Yahoo! Local ===
* http://local.yahoo.com/

* author ''(review author)''
* publication date
* title
* description
* rating
** overall and by category
* positive summary
* negative summary

==== Restaurant ====
* usage datetime
* specific use

=== Nearlocal ===
* http://www.nearlocal.com/

=== Yelp ===
* http://www.yelp.com/

=== SF Survey ===
* http://sfsurvey.com/

=== Zagat ===
* rating by category
* cost
* description

=== delicious 3rd party ===
* http://alf.hubmed.org/rvw.htm

* rating (0-100%)
* tags (keywords, year, user-specified others)
* artist/author ''(work author)''
* title
* URL
* comments
* unique identifier

=== iTunes XML ===
* rating (0-100%)

=== review world ===
* http://www.revieworld.com/

=== Dinner Buzz ===
* http://www.dinnerbuzz.com/

== Previous Schemas and Formats ==
=== Generic to any kind of review ===
==== RVW ====
* http://www.pmbrowser.info/rvw/0.2/
** http://hublog.hubmed.org/archives/000307.html <- this is a really old and out-of-date version
** http://www.pmbrowser.info/wiki.pl?RVW
* variants for embedding in Atom, RSS2, RSS1, RDF
* apparent schema
** author of review
** content of review
** creator of work
*** example: book author, movie director
** percentage score rating
** multiple identifiers
*** example: ISBN, ASIN, UPC, LOC
** link to purchase
* appears to be loosely connected with the term "!OpenReviews" (has also referred to other efforts) which itself appears to be yet another OpenBlahBlah buzzword with no substance behind it (AKA placeholder term).
==== RDF Review Vocabulary ====
* RDF Review Vocabulary: http://www.purl.org/stuff/rev
** Deployed in [http://trust.mindswap.org/FilmTrust/ FilmTrust], see e.g. [http://trust.mindswap.org/cgi-bin/FilmTrust/foaf.cgi?user=thejrnf user profile]
** Extended version used for StructuredBlogging/RDF transformation (e.g. see [http://incredibooks.com/index.php/2005/12/17/the-muffin-fiend/ sample review] there's a reference to [http://structuredblogging.org/subnode-to-rdf-interpreter.xsl subnode-to-rdf-interpreter.xsl] in the source).

==== Simple-Review XML ====
* Embeds XML in <script type="application/x-subnode">
* [http://structuredblogging.org/xmlns/simple-review.xsd XSD]
* apparent schema
** review-title
** item
*** name/title
*** type
*** URL
*** image URL
** rating (user visible, max, normalized to 0..1 value)
** comments/description

=== For specific domains ===
==== Movies ====
* [http://www.millikin.edu/mr/Entertainment/howto2.html How to Write a Movie Review]
==== Books ====
* RDF schema for book reviews: http://www.amk.ca/xml/reviews.html

* see also [[book-info-examples]]

== Thoughts on a Microformat ==
Thoughts towards a simple MicroFormat subset of earlier efforts, sufficient to express 80/20.

=== Common review fields ===
* item
** optional:type of item (business, Web page/site, product, event, person, place, file, text)
** name/title of item being reviewed (string | ["hCard"] if business or person)
*** optional:URL (all additional information should be somewhere else, not in the review itself)
*** optional:image (URL)
* reviewer (["hCard"]|name|email|URL)
* review publication/authoring date (ISO8601 datetime)
* rating 1 to 5 (default max = 5, default min = 1)
* optional:tags (keyword,rating)*
* optional:comments (string)

See [[hreview|hReview]] for the result and evolution of these thoughts on a microformat.

rel-home

2005-12-07T09:38:01Z

DannyAyers: /* Abstract */

= rel="home" =
__TOC__

== Draft Specification 2005-12-07 ==
=== Editor/Author ===
[http://dannyayers.com Danny Ayers]

=== Copyright ===
{{MicroFormatCopyrightStatement2004}}

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

== Abstract ==
[[Rel-Home]] is one of several [[MicroFormats]]. By adding <code>rel="home"</code> to a hyperlink, a page indicates that the destination of that hyperlink is the homepage of the site in which the current page appears. When the appropriate HTML Meta data profile is in use, the "home" type can be used alongside standard [http://www.w3.org/TR/html4/types.html#type-links Link Types].

Example usage :

<pre><nowiki>
<head>
...
<link href="http://technorati.com" rel="home" />
...
</head>
</nowiki></pre>

The rel value may also appear wherever an anchor link may appear, e.g.

<pre><nowiki>
<body>
...
<a href="http://technorati.com" rel="home">Home</a>
...
</body>
</nowiki></pre>

the author indicates that the linked page is the homepage of the site.

The linked page SHOULD exist. Use of an absolute URI is recommended.

== Scope ==
rel="home" is designed for site navigation purposes, as well as allowing some description of site structure to be derived from individual pages. Typical use might be in the archive pages of a weblog, pointing back to the front page.

== XMDP profile ==
<pre><nowiki>
<dl class="profile">
<dt id="rel">rel</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value.</p>
<dl>
<dt id="home">home</dt>
<dd>Indicates that the referred resource serves as the homepage,
of the site which includes the referring page.</dd>
</dl>
</dd>
</dl>
</nowiki></pre>

== Implementations ==
This section is '''informative'''.
The following implementations have been developed which either generate or parse rel-home links.

''Ed. : links to follow''

* Opera browser supports rel="home"
* [http://cdn.mozdev.org/linkToolbar/ FireFox Link Toolbar] - need to confirm

== References ==

=== Normative References ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML 1]
* [http://gmpg.org/xmdp/ XMDP]
* [http://www.ietf.org/rfc/rfc3986.txt RFC 3986 specifies URL syntax]

=== Informative References ===
* [http://diveintoaccessibility.org/day_9_providing_additional_navigation_aids.html Dive Into Accessibility] (Mark Pilgrim)

''Ed. : need to track down previous discussions, e.g. re. Opera''

== Discussions ==

=== Q&A ===
* If you have any questions about rel-home, check the [[rel-faq|rel FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[rel-home-issues|rel-home issues]] document.

rel-home

2005-12-07T09:37:03Z

DannyAyers: /* Abstract */

= rel="home" =
__TOC__

== Draft Specification 2005-12-07 ==
=== Editor/Author ===
[http://dannyayers.com Danny Ayers]

=== Copyright ===
{{MicroFormatCopyrightStatement2004}}

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

== Abstract ==
[[Rel-Home]] is one of several [[MicroFormats]]. By adding <code>rel="home"</code> to a hyperlink, a page indicates that the destination of that hyperlink is the homepage of the site in which the current page appears. When the appropriate HTML Meta data profile is in use, the "home" type can be used alongside standard [http://www.w3.org/TR/html4/types.html#type-links Link Types].

Example usage :

<pre><nowiki>
<head>
...
<link href="http://technorati.com" rel="home" />
</head>
</nowiki></pre>

<pre><nowiki>
<body>
...
<a href="http://technorati.com" rel="home">Home</a>
...
</body>
</nowiki></pre>

the author indicates that the linked page is the homepage of the site.

The linked page SHOULD exist. Use of an absolute URI is recommended.

== Scope ==
rel="home" is designed for site navigation purposes, as well as allowing some description of site structure to be derived from individual pages. Typical use might be in the archive pages of a weblog, pointing back to the front page.

== XMDP profile ==
<pre><nowiki>
<dl class="profile">
<dt id="rel">rel</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value.</p>
<dl>
<dt id="home">home</dt>
<dd>Indicates that the referred resource serves as the homepage,
of the site which includes the referring page.</dd>
</dl>
</dd>
</dl>
</nowiki></pre>

== Implementations ==
This section is '''informative'''.
The following implementations have been developed which either generate or parse rel-home links.

''Ed. : links to follow''

* Opera browser supports rel="home"
* [http://cdn.mozdev.org/linkToolbar/ FireFox Link Toolbar] - need to confirm

== References ==

=== Normative References ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML 1]
* [http://gmpg.org/xmdp/ XMDP]
* [http://www.ietf.org/rfc/rfc3986.txt RFC 3986 specifies URL syntax]

=== Informative References ===
* [http://diveintoaccessibility.org/day_9_providing_additional_navigation_aids.html Dive Into Accessibility] (Mark Pilgrim)

''Ed. : need to track down previous discussions, e.g. re. Opera''

== Discussions ==

=== Q&A ===
* If you have any questions about rel-home, check the [[rel-faq|rel FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[rel-home-issues|rel-home issues]] document.

rel-home

2005-12-07T09:35:06Z

DannyAyers: initial draft

= rel="home" =
__TOC__

== Draft Specification 2005-12-07 ==
=== Editor/Author ===
[http://dannyayers.com Danny Ayers]

=== Copyright ===
{{MicroFormatCopyrightStatement2004}}

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

== Abstract ==
[[Rel-Home]] is one of several [[MicroFormats]]. By adding <code>rel="home"</code> to a hyperlink, a page indicates that the destination of that hyperlink is the homepage of the site in which the current page appears. When the appropriate HTML Meta data profile is in use, the "home" type can be used alongside standard [http://www.w3.org/TR/html4/types.html#type-links Link Types].

Used inside the <pre><nowiki><head></nowiki></pre> of a document:

<pre><nowiki><link href="http://technorati.com" rel="home" /></nowiki></pre>

Used inside the <pre><nowiki><body></nowiki></pre> of a document:

<pre><nowiki><a href="http://technorati.com" rel="home">Home</a></nowiki></pre>

the author indicates that the linked page is the homepage of the site.

The linked page SHOULD exist. Use of an absolute URI is recommended.

== Scope ==
rel="home" is designed for site navigation purposes, as well as allowing some description of site structure to be derived from individual pages. Typical use might be in the archive pages of a weblog, pointing back to the front page.

== XMDP profile ==
<pre><nowiki>
<dl class="profile">
<dt id="rel">rel</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/links.html#adef-rel">
HTML4 definition of the 'rel' attribute.</a>
Here is an additional value.</p>
<dl>
<dt id="home">home</dt>
<dd>Indicates that the referred resource serves as the homepage,
of the site which includes the referring page.</dd>
</dl>
</dd>
</dl>
</nowiki></pre>

== Implementations ==
This section is '''informative'''.
The following implementations have been developed which either generate or parse rel-home links.

''Ed. : links to follow''

* Opera browser supports rel="home"
* [http://cdn.mozdev.org/linkToolbar/ FireFox Link Toolbar] - need to confirm

== References ==

=== Normative References ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML 1]
* [http://gmpg.org/xmdp/ XMDP]
* [http://www.ietf.org/rfc/rfc3986.txt RFC 3986 specifies URL syntax]

=== Informative References ===
* [http://diveintoaccessibility.org/day_9_providing_additional_navigation_aids.html Dive Into Accessibility] (Mark Pilgrim)

''Ed. : need to track down previous discussions, e.g. re. Opera''

== Discussions ==

=== Q&A ===
* If you have any questions about rel-home, check the [[rel-faq|rel FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[rel-home-issues|rel-home issues]] document.

Main Page

2005-12-07T09:34:38Z

DannyAyers: /* Drafts */

__NOTOC__
= Microformats Wiki =
Welcome to the [http://microformats.org microformats] wiki. There's a lot going on around here, but feel free to jump in and offer your assistance.

But First:

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]] and [[presentations]] are also a good place for some background reading as well.

One popular definition from our mailing list is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license|RelLicense]]
* [[rel-nofollow|RelNoFollow]]
* [[rel-tag|RelTag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]] {{NewMarker}}
* [[geo|geo]] {{NewMarker}}
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk]]
* [[rel-home]] {{NewMarker}}

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[datetime-design-pattern]]
* [[class-design-pattern]]
* [[rel-design-pattern]]
* [[abbr-design-pattern]]

== Exploratory discussions ==
Focused on real-world [[examples]] to motivate the microformat.
*[[hatom|hAtom]] ({{NewMarker}}) is based on: [[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]]
*[[blog-description-format]]
*[[chat-examples]]
*[[citation-brainstorming]], [[cite|Planning pages for a citation microformat]]
*[[comments-formats]]
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[forms-examples]]
*[[genealogy-formats]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-metadata-examples]]
*[[other-formats]]
*[[requirements-testing]]
*[[resume-brainstorming]], [[resume-formats]]
*[[rest-examples]]
*[[search-results-example]]
*[[table-examples]]
*[[tagspeak-examples]]
*[[transit-table-examples]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[[vcard-implementations]], [[vcard-errata]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]
*[[why-are-content-standards-hard]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[to-do]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different</del> other languages

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]]
* [[Main_Page-jp|日本語 (Japanese)]] {{NewMarker}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微支付 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])

xhtml-syndication

2005-11-29T10:21:47Z

DannyAyers: /* Queue */

= XHTML Syndication History =

The idea of using XHTML syndication is by no means new.

When the idea first started coming up on the [http://microformats.org/discuss/ microformats-discuss] list, it sounded like a new, novel idea. It's not. Of course, I wasn't a citizen of Blogistan when it had been discussed before. Here's a brief history of the idea:

Mark Pilgrim accurately asserts that "Every few months, somebody floats the idea of doing away with RSS and replacing it with HTML or XHTML, 'because semantic markup is all we need'."

Apparently he was right, because the topic keeps coming up.

Mark also says:

<blockquote>
I’ve talked about application posture before; it seems to me that this latest movement adopts the wrong posture. The entire success of RSS is predicated on the principle that you can keep doing whatever messed up stuff you’ve always done on your web pages… oh, and do this other thing too. Look, it’s simple, you can code it up in an hour with a few print statements and an escape function. By contrast, this latest XHTML-as-syndication movement seems to be based on the principle that syndication is so incredibly important that you must immediately stop whatever you’re doing with your web pages, upgrade to XHTML, validate your markup, restructure your home page to include all and only the content you’re willing to syndicate, and by the way, would you please unlearn that ugly nasty presentational page layout language you’ve been using for years and learn this wonderful happy structured semantic markup language instead?
</blockquote>
In response, in seems that people are already *unlearning their crappy presentational markup shit.* Could it be that, given the move towards a separation of presentation and structure, we may now be able to create a syndication format in XHTML (at least for blogs)?

--[[User:RyanKing|RyanKing]] 14:34, 27 Oct 2005 (PDT)

== Work in Progress ==
This document is a work in progress. If you'd like to contribute, feel free to take one of the links from the Queue at the bottom of the page, analyze it, write a short summary of the proposal and record any issues in the "Issues Raised" section.

Reference: [http://diveintomark.org/archives/2002/11/26/syndication_is_not_publication]

== Issues Raised ==
This section is for documenting issues raised in earlier efforts at using XHTML as a syndication format.

* How do we represent dates in XHTML? (see above) [http://diveintomark.org/archives/2002/11/26/syndication_is_not_publication]

== Proposed Profiles, etc ==
=== Site Summaries in XHTML ===
[http://w3.org/People/DanC Dan Connoly] of the [http://w3.org W3C] has a "Site Summaries in XHTML" to express RDF 1.0 channels in XHTML.

http://www.w3.org/2000/08/w3c-synd/

A boiled down, interpretation of the spec:

* the title of the channel is taken from the title of the page
* each <code><div class="item"></code> on the page indicates an RSS item
** each such div element should contain an h2 or h3 element; this serves as the item's title.
** it should also contain a p element that serves as the item's description.
**the p element should contain an <code><a rel="details" href="...ref...">...</a></code> which is taken as the URI of the item.
**the div should contain some element with <code>class="date"</code>; its content should be a date in DD Month YYYY format; this is taken as the Dublin Core date of the item.

=== XHTML Syndication Module ===
19 July 2002
Joe Gregorio published an XHTML Syndication Module.

<blockquote>
The motivation for this document is to do away with RSS as a seperate file format. If web publishers and CMSs want to participate in content syndication then they have to produce two versions of their front page, the HTML version and the RSS version. A careful inspection of XHTML and common web practice shows that most of the information need to do syndication already exists in web pages published today. What is needed is a little extra information to make syndication possible.
</blockquote>
Its done by way of an xml namespace which adds attributes to the XHTML. Example:

<blockquote><pre><nowiki>
<div class="singleItem" syn:item="">
<h4><a syn:title="" syn:link="href" href="http://bitworking.org/2002/07/18.html#a245"
class="weblogItemTitle">Bye-bye BurningBird</a></h4>
<p class="firstItemParagraph" syn:description="">
Hard to believe but <a href="http://weblog.burningbird.net/archives/000370.php">BurningBird</a>
is closing down her blog. Best of wishes Shelly.</p>
<div class="singleItemFooter">
<span class="itemPermaLinkTime">12:21:21 AM
<span class="itemPermaLink"><a href="2002/07/18.html#a245">#</a>
</span>&nbsp;&nbsp;
</span>
</div>
</div>
</nowiki></pre></blockquote>
Reference: [http://bitworking.org/XHTML-Syndication-20020719.html]

=== RSS: XHTML Profile ===
Aaron Swartz has an XHTML profile. Description:

<blockquote>
* the value of the <title> is the title of your site
* (optional)the element with class="description" contains a short description
* each element with class="item" on your page is an item, inside which:
** the element with class="title" is the item's title
** everything else is the content of the item
** the link with rel="bookmark" is the URI of the item
** (optional) the element with class="date" is the date
</blockquote>

Reference: [http://www.aaronsw.com/2002/rssXP]

== Discussion ==
This section is for collecting links to stuff that discusses the idea of using XHTML for syndication. Personally, I'm most interested in proposals/ideas that *didn't* take off. I want to learn from previous mistakes. Feel free to add to this list, with a summary, if you'd like. --[[User:RyanKing|RyanKing]] 14:34, 27 Oct 2005 (PDT)

* http://www.dashes.com/anil/2002/11/22/syndication_for
* http://www.actsofvolition.com/archives/2002/march/blogmltheweblog
* http://weblog.burningbird.net/archives/2002/11/26/rss-push-back
* http://www.intertwingly.net/blog/977.html

= Queue =
Since this document is a work in progress, this section is simply a list of links which need to be covered.
* http://ln.hixie.ch/?start=1038263537&count=1
* http://www.aaronsw.com/weblog/000738
* http://www.kryogenix.org/days/2002/11/24/instead
* http://tantek.com/log/2002/11.html#L20021124t1454
* http://tantek.com/log/2002/11.html#L20021124t0620
* http://www.scottandrew.com/weblog/2002_11#a000469
* http://bitworking.org/2002/07/19.html#a251
* http://bitworking.org/2002/07/15.html#a244
* http://diveintomark.org/archives/2002/11/26/the_rebellion_will_be_syndicated
* http://diveintomark.org/archives/2002/11/26#syndication_is_not_publication
* http://www.yetanothercommunitysystem.com/yacs/articles/view.php/438
* http://diveintomark.org/archives/2002/11/26/syndication_is_not_publication
* http://www.dellah.com/orient/2002/11/26/the-xhtml-syndication-debate
* http://nilesh.org/weblog/2002/11/xhtml-syndication/
* http://dannyayers.com/archives/2003/04/30/xhtml-syndication-module/
* http://dannyayers.com/archives/2005/08/27/hatom-no-seriously/
* http://www.dashes.com/anil/2002/11/22/syndication_for

(tidy me ;-)
Dan Brickley, comment at http://dannyayers.com/archives/2005/11/26/history/ :
Eric van der Vlist had an implementation of this back in 2000 http://groups.yahoo.com/group/XHTML-L/message/683. We made a version available on the ILRT site http://www.ilrt.bris.ac.uk/discovery/2000/08/hss/sw.html, which fed into the more widely used W3C version http://www.w3.org/2000/08/w3c-synd/ of this idea. I still think this is the way to go, ultimately. The use cases just aren’t different enough to justify having completely different document formats, solely on basis of their dissemination mechanism. But I tried raising this in early Atom days and got told it was a silly idea. Maybe as the XML doc formats mature (XHTML2, CDF) it’ll be time to revisit again.

xhtml-syndication

2005-11-26T10:44:14Z

DannyAyers: /* Queue */

faqs-for-rdf

2005-11-09T17:17:43Z

DannyAyers: /* FAQs for RDF Fans */

= Microformat FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. The processes, principles, and practices of the (open) microformats group are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific [http://www.w3.org/RDF/ RDF] serializations.

See also: [http://microformats.org/about/ About Microformats]

==== For example..? ====

This [http://microformats.org/wiki/hcard-example1-steps example] shows how the hCard microformat can be used to express vCard data.

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the [http://www.w3.org/2001/sw/ Semantic Web].

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is just one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats (should) include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://sw.deri.org/~jbreslin/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T10:19:24Z

DannyAyers: /* So, this is about using CSS class values to add semantics? */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. The processes, principles, and practices of the (open) microformats group are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific [http://www.w3.org/RDF/ RDF] serializations.

See also: [http://microformats.org/about/ About Microformats]

==== For example..? ====

This [http://microformats.org/wiki/hcard-example1-steps example] shows how the hCard microformat can be used to express vCard data.

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the [http://www.w3.org/2001/sw/ Semantic Web].

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is just one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats (should) include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T10:18:04Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. The processes, principles, and practices of the (open) microformats group are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific [http://www.w3.org/RDF/ RDF] serializations.

See also: [http://microformats.org/about/ About Microformats]

==== For example..? ====

This [http://microformats.org/wiki/hcard-example1-steps example] shows how the hCard microformat can be used to express vCard data.

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the [http://www.w3.org/2001/sw/ Semantic Web].

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats (should) include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T09:56:59Z

DannyAyers: /* What are Microformats? */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. The processes, principles, and practices of the (open) microformats group are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== For example..? ====

This [http://microformats.org/wiki/hcard-example1-steps example] shows how the hCard microformat can be used to express vCard data.

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats (should) include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T09:55:45Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== For example..? ====

This [http://microformats.org/wiki/hcard-example1-steps example] shows how the hCard microformat can be used to express vCard data.

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats (should) include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T09:55:07Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== For example..? ====

This [http://microformats.org/wiki/hcard-example1-steps example] shows how the hCard microformat can be used to express vCard data.

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats (should) include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T09:52:04Z

DannyAyers: /* Isn't this just scraping? */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats (should) include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T09:51:19Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T09:50:26Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

faqs-for-rdf

2005-11-09T09:49:58Z

DannyAyers: added links

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: [http://www.w3.org/People/Connolly/ Dan Connolly], [http://internetalchemy.org/ Ian Davis], [http://www.johnbreslin.com/ John Breslin], [http://dannyayers.com Danny Ayers]....

faqs-for-rdf

2005-11-09T09:46:48Z

DannyAyers: /* How do I get involved? */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular [http://microformats.org/mailman/listinfo/microformats-discuss/ microformats-discuss]). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

faqs-for-rdf

2005-11-09T09:46:04Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language (though they can also be implemented on other XML formats, e.g. Atom).

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that conflicts ought to be prevented. The goal is to keep things as simple as possible by only focusing on '''existing''' well-defined problems, rather than trying to "boil the ocean" (solve the hypothetical general case).

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== How do I get involved? ====

If you're using the Web, you already *are* involved! Next place to go is the [http://microformats.org/ microformats.org] site, and maybe sign up to some of the [http://microformats.org/discuss/ mailing lists] (in particular microformats-discuss). There's also an IRC channel [irc://irc.freenode.net#microformats #microformats on irc.freenode.net].

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

faqs-for-rdf

2005-11-08T15:04:54Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language.

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that such conflicts will be prevented.

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

faqs-for-rdf

2005-11-08T14:59:06Z

DannyAyers: /* Isn't there a clash between the semantics of XFN and FOAF? */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language.

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that such conflicts will be prevented.

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl]) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

faqs-for-rdf

2005-11-08T14:54:43Z

DannyAyers: /* Isn't there a clash between the semantics of XFN and FOAF? */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language.

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that such conflicts will be prevented.

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and ''independently'' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

faqs-for-rdf

2005-11-08T14:54:08Z

DannyAyers: /* Isn't there a clash between the semantics of XFN and FOAF? */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language.

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that such conflicts will be prevented.

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl) to extract the person-related statements, e.g.
<pre>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</pre>
- and '''independently''' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<pre>
<http://example.org/this-page> dc:creator "The Creator" .
</pre>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

faqs-for-rdf

2005-11-08T14:53:09Z

DannyAyers: /* FAQs for RDF Fans */

= FAQs for RDF Fans =

__TOC__

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language.

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== But I do RDF, why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for every profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that such conflicts will be prevented.

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== Isn't there a clash between the semantics of XFN and FOAF? ====

The use of the page URI in XFN to identify a person appears to conflict with FOAF's by-reference approach, and to mess up the potential for saying things about the page itself. However in practice this isn't a problem. It's possible to parse the document as XFN (using e.g. [http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokXFN.xsl grokXFN.xsl) to extract the person-related statements, e.g.
<code>
_:personA foaf:homepage <http://example.org/this-page> .
_:personA foaf:knows _:personB .
_:personB foaf:homepage <http://example.org/linked-page> .
</code>
- and '''independently''' parse the document using other format mappings (e.g. [http://www.w3.org/2000/06/dc-extract/dc-extract.xsl dc-extract.xsl]) to obtain other statements, e.g.
<code>
<http://example.org/this-page> dc:creator "The Creator" .
</code>

See also: [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL], [http://www.oreillynet.com/pub/wlg/8281 XFN Delusions of Grandeur], [http://www.microformats.org/blog/2005/11/02/xfn-grandeur/ XFN Grandeur], [http://dannyayers.com/archives/2005/11/03/xfn-vs-foaf/ XFN vs. FOAF]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

faqs-for-rdf

2005-11-08T10:56:23Z

DannyAyers: /* Isn't this just scraping? */

faqs-for-rdf

2005-11-08T10:54:44Z

DannyAyers: /* Why should I be interested? */

faqs-for-rdf

2005-11-08T10:49:21Z

DannyAyers: /* FAQs for RDF Fans */

faqs-for-rdf

2005-11-08T10:48:12Z

DannyAyers:

= FAQs for RDF Fans =

==== What are Microformats? ====

Microformats are a set of simple, open data formats built upon existing and widely adopted standards, in particular XHTML used ''correctly''. Microformats processes, principles, and practices are what make microformats "microformats", but they centre on using XHTML as designed, as a semantic language.

Although the microformats initiative puts human-readability first, with the help of the [http://www.w3.org/2004/01/rdxh/spec GRDDL] mechanism, it is possible to view microformats as domain-specific RDF serializations.

See also: [http://microformats.org/about/ About Microformats]

==== Why should I be interested? ====

Microformats can lower the barrier to putting explicit data on the Web. This is entirely in line with the aims of the Semantic Web.

Dan Connolly [http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0103 rdf-interest, March 2000]:
<blockquote>
I believe that one of the best ways to transition into RDF, if not a long-term deployment strategy for RDF, is to manage the information in human-consumable form (XHTML) annotated with just enough info to extract the RDF statements that the human info is intended to convey. In other words: using a relational database or some sort of native RDF data store, and spitting out HTML dynamically, is a lot of infrastructure to operate and probably not worth it for lots of interesting cases. We all know that we have to produce a human-readable version of the thing… why not use that as the primary source?
</blockquote>

==== I have an RDF vocabulary I would like to use as a microformat. How do I do it? ====

Before doing anything else, read the [http://microformats.org/wiki/process Process]. In general the microformat process is data-driven. It starts with material already being published, rather than an existing format, model or schema. You should also check the list of what has already been covered and the work-in-progress on the Wiki MainPage.

It may well be that what you have in mind isn't appropriate for use as a microformat, but it may still be a good idea to develop a (semantic) XHTML representation. Existing microformats demonstrate a standards-friendly way of doing this.

See also: [http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]

==== So, this is about using CSS class values to add semantics? ====

No. XHTML already expresses semantics, the '''HTML''' <code>class</code> attribute is one of several mechanisms. From the [http://www.w3.org/TR/REC-html40/ HTML 4 spec]:

<blockquote>
The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes.
</blockquote>

See also: [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling]

==== Are there Schemas for Microformats? ====

Kind of. The primary specification is XHTML, but HTML4 provides a mechanism (the 'profile' attribute of the <head> element) to point to a meta data profile that defines properties and values. There is a (HTML-based) format specified for microformat profiles - [http://www.gmpg.org/xmdp/ XHTML Meta Data Profiles]. Note that XMDP's URLs for specifying terms is compatible with those used by RDF, with "#term" at the end.

==== Isn't this just scraping? ====

No. Because microformats include URI(s) for ever profile used, and the profiles are clearly defined, the explicit data contained in a document can be extracted deterministically by parsing.

==== What about namespaces for the attributes, should I use "xxx:term"? ====

In general, microformats rejects the use of explicit namespace prefixes in
documents as unnecessary for solving the 80/20 of problems that microformats
seeks to solve. The general approach taken is not to attempt to generalise to the extent of [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF-in-HTML], rather to define more domain-specific formats.

==== But won't there be naming clashes? ====

The social aspect of the microformats [http://microformats.org/wiki/process Process] is such that such conflicts will be prevented.

==== So how do I get the data out? ====

See [http://www.w3.org/2004/01/rdxh/spec GRDDL]

==== What other work has been done with microformats and RDF? ====

* [http://www.w3.org/2003/g/td/xfn-workalike XFN on the GRDDL]
* [http://people.w3.org/~dom/archives/2005/05/grddl-specification-updated/ GRDDL specification updated works with Microformats]

==== What RDF vocabularies (and XSLT) corresponding to microformats is available? ====

See [http://esw.w3.org/topic/MicroModels MicroModels] (on ESW Wiki)

==== Who else is looking at RDF and microformats? ====

Lots of folks.
Including: DanConnolly, IanDavis, JohnBreslin, DannyAyers ....

Main Page

2005-11-08T10:47:39Z

DannyAyers: /* Tools & Test Cases & Additional Research */

__NOTOC__
= Microformats Wiki =
Welcome to the [http://microformats.org microformats] wiki. There's a lot going on around here, but feel free to jump in and offer your assistance.

But First:

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]] and [[presentations]] are also a good place for some background reading as well.

One popular definition from our mailing list is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license|RelLicense]]
* [[rel-nofollow|RelNoFollow]]
* [[rel-tag|RelTag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]] {{NewMarker}}
* [[geo|geo]] {{NewMarker}}
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk]]

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[datetime-design-pattern]]
* [[class-design-pattern]]
* [[rel-design-pattern]]
* [[abbr-design-pattern]]

== Exploratory discussions ==
Focused on real-world [[examples]] to motivate the microformat.
*[[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]]
*[[blog-description-format]]
*[[chat-examples]]
*[[citation-brainstorming]], [[cite|Planning pages for a citation microformat]]
*[[comments-formats]]
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[forms-examples]]
*[[genealogy-formats]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-metadata-examples]]
*[[other-formats]]
*[[requirements-testing]]
*[[resume-brainstorming]], [[resume-formats]]
*[[rest-examples]]
*[[search-results-example]]
*[[table-examples]]
*[[transit-table-examples]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[[vcard-implementations]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[to-do]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different languages</del> at least one more language:

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]] (Thanks to neuro`!)
* ...

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

Main Page

2005-11-08T10:47:12Z

DannyAyers: /* Tools & Test Cases & Additional Research */

__NOTOC__
= Microformats Wiki =
Welcome to the [http://microformats.org microformats] wiki. There's a lot going on around here, but feel free to jump in and offer your assistance.

But First:

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]] and [[presentations]] are also a good place for some background reading as well.

One popular definition from our mailing list is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license|RelLicense]]
* [[rel-nofollow|RelNoFollow]]
* [[rel-tag|RelTag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]] {{NewMarker}}
* [[geo|geo]] {{NewMarker}}
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk]]

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[datetime-design-pattern]]
* [[class-design-pattern]]
* [[rel-design-pattern]]
* [[abbr-design-pattern]]

== Exploratory discussions ==
Focused on real-world [[examples]] to motivate the microformat.
*[[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]]
*[[blog-description-format]]
*[[chat-examples]]
*[[citation-brainstorming]], [[cite|Planning pages for a citation microformat]]
*[[comments-formats]]
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[forms-examples]]
*[[genealogy-formats]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-metadata-examples]]
*[[other-formats]]
*[[requirements-testing]]
*[[resume-brainstorming]], [[resume-formats]]
*[[rest-examples]]
*[[search-results-example]]
*[[table-examples]]
*[[transit-table-examples]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[[vcard-implementations]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[to-do]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different languages</del> at least one more language:

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]] (Thanks to neuro`!)
* ...

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

parsing-microformats

2005-10-26T13:32:01Z

DannyAyers:

= Microformat Parsing =

Microformat parsing mechanisms that depend on documents having even minimal xml properties like well-formedness may fail when consuming non-well-formed content. Tidy may be a useful work around.
In particular [http://suda.co.uk/projects/X2V/ Brian Suda's frequently cited X2V hCard and hCalendar discovery and transformation prototypes] use XSLT, and "tidy" any non-well-formed input before processing it.

Most microformats tend to be agnostic about things like exact element type used.

Developers can use tools like XPATH that assume well-formedness on well-formed content (from the web or by using tidy). Mark Pilgrim's example [http://sourceforge.net/projects/feedparser/ universal feed parser] suggests that it may be possible to sanitize user html to an extent that it is suitable for later processing as xml.

==== See Also ====

[[XMDP Brainstorming]]

parsing-microformats

2005-10-26T13:31:10Z

DannyAyers: extracted from XMDP Brainstorming

Microformat parsing mechanisms that depend on documents having even minimal xml properties like well-formedness may fail when consuming non-well-formed content. Tidy may be a useful work around.
In particular [http://suda.co.uk/projects/X2V/ Brian Suda's frequently cited X2V hCard and hCalendar discovery and transformation prototypes] use XSLT, and "tidy" any non-well-formed input before processing it.

Most microformats tend to be agnostic about things like exact element type used.

Developers can use tools like XPATH that assume well-formedness on well-formed content (from the web or by using tidy). Mark Pilgrim's example [http://sourceforge.net/projects/feedparser/ universal feed parser] suggests that it may be possible to sanitize user html to an extent that it is suitable for later processing as xml.

==== See Also ====

[[XMDP Brainstorming]]

xmdp-brainstorming

2005-10-26T13:29:17Z

DannyAyers: Moved "Parsing microformats" out to a separate page

= XMDP Brainstorming =

__TOC__

== Authors ==

* [http://tantek.com/log/ Tantek Çelik]
* [http://thecommunityengine.com/home Bud Gibson]

Add your name here if you make significant contributions to this page and wish to take responsibility for them.

== Introduction ==

Tantek Çelik developed [http://gmpg.org/xmdp/ XMDP] to define extensions to XHTML including rel values, class names, and <meta name> properties and values. Per the [http://gmpg.org/xmdp/description XMDP spec], a link to a microformat's XMDP in the profile attribute of head element indicates that that microformat's vocabulary is formally defined in the document. A parser could read the allowed attribute values from the linked XMDP and thus know explicitly which microformats may be in use, and which class names are meant to convey which meanings.

This page is for exploring possible additions / extensions to XMDP.

See [[xmdp-faq]] and [[xmdp-issues]] for questions and issues.

== Possible XMDP additions ==

=== Linking to the XMDP ===

There are at least two additional methods under discussion for linking to the XMDP in addition to the current method of using the profile attribute of the head element:
* Using <nowiki><link rel="profile" href="link to XMDP"/></nowiki>. This method can be used now and will be formalized in XHTML 2.
** A problem with this method is that it requires access to the head element.
* Using <nowiki><a rel="profile" href="link to XMDP">powered by microformat xyz</a></nowiki> in the body of the document.
** As noted by a number of people, this approach has the added benefit of creating a viral marketing opportunity for the microformats used. For instance, developers could add badges saying they are using microformat xyz as suggested by the example.
** Blog authoring environments allow you to insert links at will, so this squarely <abbr title="avoids">obviates</abbr> the need to access the head element.

==== Ontology addition ====
There is currently now way to cross-reference two or more XMDPs. This is proposal about how to link two properties and give some meaning between the two.

For my ficticious example i will use 'self'
<pre>
<nowiki>
<dl class="rel">
<dt id='self'><a href="http://www.gmpg.org/xfn/11#me" rev="extends">self</a></dt>
<dd>This is a pointer to me, it extends the ME property of XFN</dd>
</dl>
</nowiki>
</pre>
There are two interesting pieces that have been added, a URL with an anchor to another XMDP profile and a rev attribute. The rev value in
this example is 'extends'. These means that the page this is refering too, is extended by the property SELF. So you could make an XMDP that
lists all the possible rev attributes, 'extends', 'inverse', 'equivanent', etc. Then you could 'alias' one microformat property to another.

Then the universal XMDP validator/parser/etc can extract data across two or more XMDP profiles. This would create a small ontology, but also make an endless chase across hrefs through those profiles.

This idea still needs some work, but it might be something of interest to this problem, so i'll hang it out there for comment.

==== Profile aliasing ====
Probably just a special case of ontology addition. An XMDP document could be used to define a microformat profile that is nothing more than a simple dictionary mapping between an existing, non-standard set of HTML classes and the terms in a standard microformat profile. This would allow a publisher to support a given microformat by merely using the URI of the profile alias document as the value of an individual documents head/profile attribute, rather than modifying the individual class values throughout each document. Initial suggestion with use case description in this [http://microformats.org/discuss/mail/microformats-discuss/2005-October/001623.html microformats-discuss post]. Note (from [http://microformats.org/discuss/mail/microformats-discuss/2005-October/001633.html Kevin's response]) that HTML class attributes can contain multiple values, e.g. class="post atomentry", so a publisher doesn't have to discard their existing class values to use those of a microformat.

=== Resolving when microformats are actually in use ===

One solution to this issue is simply to include the <nowiki><a rel="profile" href="link to XMDP">powered by microformat xyz</a></nowiki> within the container element for the microformat. The XMDP spec could then specify that when the <a> element is used in this way, it indicates that the microformat is used by the element containing the <a> element.

There are, however, several clear issues with this proposal:

* Not every microformat has a container element. Consider [[reltag]] one of the most widely used microformats.
* To some extent, using microformats adds to the cost of writing the document. It's like filling in a form just to write your thoughts. Putting <a> elements with each microformat adds unwanted links on top of that.

==== See Also ====

[[Parsing Microformats]]

xmdp-brainstorming

2005-10-26T13:25:53Z

DannyAyers: note on profile aliasing added

hatom-issues

2005-10-26T02:14:28Z

DannyAyers: /* Why atomfeed/atomentry? */

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# Provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==

=== Why atomfeed/atomentry? ===
;class="atomentry"
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I choose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

;class="atomfeed"
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

It is possible (and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]]) that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
** I'm going to more explicitly recognize that the XHTML document acts as the Feed is many cases
* A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
::This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again) -- [[DannyAyers]]

== Comparisons ==

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

=See Also=
* [[hatom|hAtom]] - the draft proposal
* [[hatom-issues]] - problems? complaints? ideas? Put them here
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)

hatom-issues

2005-10-26T02:13:17Z

DannyAyers: /* Why atomfeed/atomentry? */

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# Provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==

=== Why atomfeed/atomentry? ===
;class="atomentry"
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I choose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

;class="atomfeed"
:As above on the atomprefix. But what does 'feed' mean in the context f a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

It is possible (and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]]) that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
** I'm going to more explicitly recognize that the XHTML document acts as the Feed is many cases
* A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
::This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does feed make sense? (Maybe just naming aesthetics again) -- [[DannyAyers]]

== Comparisons ==

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

=See Also=
* [[hatom|hAtom]] - the draft proposal
* [[hatom-issues]] - problems? complaints? ideas? Put them here
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)

hatom-issues

2005-10-26T02:12:27Z

DannyAyers: /* Why atomfeed/atomentry? */

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# Provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==

=== Why atomfeed/atomentry? ===
;class="atomentry"
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I choose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

;class="atomfeed"
:As above on the atomprefix. But what does 'feed' mean in the context f a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

It is possible (and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]]) that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
** I'm going to more explicitly recognize that the XHTML document acts as the Feed is many cases
* A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
::This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

: The multi-feed point makes sense, but if this data appears on a regular HTML page, does that stiil make sense? (Maybe just naming aesthetics again) -- [[DannyAyers]]

== Comparisons ==

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

=See Also=
* [[hatom|hAtom]] - the draft proposal
* [[hatom-issues]] - problems? complaints? ideas? Put them here
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)