Microformats Wiki - User contributions [en]

distributed-conversation-brainstorming

2005-08-15T21:12:29Z

LucasGonze: /* Problem */

=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].

==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

: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>

== 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.

==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/

media-metadata-examples

2005-08-11T00:24:36Z

LucasGonze: /* Offline Media */

This is an exploratory page to be used for storage of various multimedia metadata profiles currently in use around the web. As this is a very, very early exploration, we should include as many types of multimedia as possible in the opening discussion - but please be sure to place your profiles in the correct portion of this page.

= Purpose of this exploration (or : The Problem) =

The purpose of the studies on this page is to determine the feasibility and demand for a flexible, semantic markup format for providing metadata alongside linked multimedia files. Typically, this metadata is stored within the header of the media file itself - which has massive implications for any application where metadata is to be indexed, searched, or made externally accessible. Of course, even if you could easily access the correct portions of a media file remotely, you'd still have to cope with a multitude of open and proprietary metadata formats, each with it's own distinct fieldset, nomenclature and storage method.

This study aims to make a start at solving this problem.

== Contributors ==

These folks have contributed real-world examples and research to this document, and are interested in helping with a solution.

* Christopher Allen
* Dougal Campbell
* Dr. Ernie
* Rohit Khare
* Ryan King
* Kevin Marks
* Lisa Rein
* Danski

If you contribute new real-world examples or research, and wish to help with a solution, please add your name as well.

= Examples on the Web today =

* ...
* ...

= Current / Previous Standards =

== Still image ==

* [http://www.exif.org/Exif2-2.PDF EXIF]
* [http://www.tasi.ac.uk/2000/09/rdfmeta/ RDF for self-describing images]
* [http://archive.dstc.edu.au/RDU/staff/jane-hunter/PNG/paper.html An Indexing and Querying System for Online Images Based on the PNG Format and Embedded Metadata]
* [http://www.w3.org/TR/photo-rdf/ Describing and retrieving photos using RDF and HTTP]

== Audio ==

* [http://www.id3.org/ ID3v2]

* iTunes
** Album : String
** Artist : String
** Beats Per Minute : Number
** Bit Rate : Number
** Comment : Blob
** Composer : String
** Genre : String or Foreign ID
** Disc Number : Number
** Kind : Proprietary - could be implimented as MIME type
** My Rating : Number < 5 (actually an integer from the range 0-100. 1-5 "stars" implemented by incrementing by 20)
** Sample Rate : Number
** Size : Number
** Time : Number
** Track Number : Number
** Year : Number
**Additional metadata used internally by the application : Date Added (Timestamp), Date Modified (Timestamp), Equalizer (foreign ID), Play Count (Number), Grouping (Internal)
**Noteable absences : Tags, [[rel-license|License]], Copyright year. Also note common complaints about [http://www.everything2.com/index.pl?node_id=1707402 ID3 and classical music].

* [http://www.xspf.org/ XSPF]
** album
** creator
** duration
** info
** title
** trackNum

== Podcasts ==

* '''iTunes podcast:''' http://phobos.apple.com/static/podcast_specifications.pdf
(HTML version of spec: [http://labs.commerce.net/~rohit/How%20To%20Publish%20a%20Podcast%20on%20iTunes%20Music%20Store.html local archive], [http://labs.commerce.net/~rohit/iTunesRSS.html updated version from Apple Chapter Tool Beta docs], [http://phobos.apple.com/static/iTunesRSS.html online copy at Apple])

iTunes release 4.9 was widely heralded as an advance for mainstream acceptance of podcasting. However, while some advocates resist even the fragment of a trademarked name in the label for the phenomenon, the use of "itunes:" in the namespace is one of many design decisions in Apple's original specification that became focal points of debate. While Apple has a tradition of working on breakthrough features very quietly, they have been open to public input after its initial release. Many [http://daringfireball.net/2005/07/podcast_pocket other bloggers] have [http://usefulinc.com/edd/blog/contents/2005/06/28-rss-apple-itunes/read chronicled] [http://www.intertwingly.net/blog/2005/07/05/Insensitive-iTunes some of the feedback], as well as some [http://tantek.com/log/2005/07.html#d10t0130 face-to-face discussions].

A mailing list may be coming soon...

* '''Media RSS:''' http://search.yahoo.com/mrss

Media RSS has [http://www.ysearchblog.com/archives/000111.html been in the works longer], but doesn't have the overnight-adoption advantage of iTunes. However, it has a much broader ambit, including [http://www.ysearchblog.com/archives/000060.html video]; and a much broader [http://groups.yahoo.com/group/rss-media/ community of interest].

=== A Podcasting Microformat? ===

The best starting point for understanding these two proposals is [http://www.w3.org/2005/07/media-and-rss W3C's summary table, by Karl Dubost].

There are (at least) two paths to consider when 'porting' these proposals into Microformats:
# '''Standalone.''' What is the most straightforward rendering of each proposal into XHTML? This keeps the interests of the developers of ''consuming'' applications foremost: how can the migration be made as painless as possible?
# '''Refactored.''' Given the existing core of Microformats, what is the minimal (!) necessary to add on to RelLicense, RelTag, hReview, and so forth? This favors (we'd hope) content ''publishing'' applications: how can the marginal migration costs of adding media be made as painless as possible.

Mapping the existing specs requires understanding the data definitions set forth in each specification, and finding the optimal equivalents (where available). The following is a partial summary of one possible mapping:

{| border="1" cellpadding="5" cellspacing="0" style="border:1px solid grey;"
|+ Comparing existing proposals
! Aspect !! Apple !! Yahoo! !! Microformat?
|-
| '''Categorization'''
|| <itunes:category> <itunes:keywords>
|| <media:category>
|| [[rel-tag | RelTag]] - requires a way to do sub categories?
|-
| '''Rating''' || <itunes:explicit>|| <media:adult> || [[rel-tag | RelTag]]
|-
| '''Description''' ||<itunes:subtitle> <itunes:summary>|| <media:text> || XHTML (e.g. < blockquote > )
|-
| '''Authorship'''
|| <itunes:author> <itunes:owner> <itunes:name> <itunes:email>
|| <media:credit>
|| <cite> [[hcard|hCard]]
|-
| '''Metadata''' || <itunes:duration> <itunes:image>|| <media:thumbnail> <media:hash> 
<media:content
url="http://www.foo.com/movie.mov"
fileSize="12216320"
type="video/quicktime"
isDefault="true"
expression="full"
bitrate="128"
framerate="25"
duration="185"
height="200"
width="300" />
|| ''needs a new microformat'' e.g., <dt> <dd>
|-
| '''Licensing''' || <itunes:block> <copyright> <link>|| Not explicitly mentioned || [[rel-license | RelLicense]]
|-
|}

== Video ==
* [http://www.exif.org/Exif2-2.PDF EXIF] - (Yes, the spec deals with video taken by still cameras. -- RyanKing)
* [http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm MPEG-7] - MPEG-7, formally named "Multimedia Content Description Interface", is a standard for describing the multimedia content data that supports some degree of interpretation of the information meaning, which can be passed onto, or accessed by, a device or a computer code. (Very powerful, but you have to pay for documentation -- [[User:ChristopherA|ChristopherA]] 01:53, 29 Jun 2005 (PDT))
* [http://www.w3.org/AudioVideo/ SMIL] - Synchronized Multimedia Integration Language (SMIL, pronounced "smile") enables simple authoring of interactive audiovisual presentations. (Not exactly video, but has a lot of useful video-related features in it. -- [[User:ChristopherA|ChristopherA]] 01:55, 29 Jun 2005 (PDT))
* [[video-metadata-model| Video Metadata Model - a starting point]]

== Interactive ==
* [http://www.w3.org/Graphics/SVG/ SVG]
* [http://www.w3.org/AudioVideo/ SMIL]
* QTVR?

== Offline Media ==
* [http://xspf.org XSPF] (media may be either offline or online)

=== Printed Publications (books/magazines) ===
* [http://amazon.com/ Amazon]

=== Movies ===
* [http://imdb.com/ IMDB]
* [http://amazon.com/ Amazon]

=== Music ===
* [http://freedb.org/ FreeDB]
* [http://musicbrainz.org/ MusicBrainz]
* [http://amazon.com/ Amazon]

== Comments ==

* See separate [[media-metadata-issues]] document.

distributed-conversation-brainstorming

2005-07-30T03:04:59Z

LucasGonze: /* Problem */

=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].

==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.

: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."

: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>

== 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.

==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/

distributed-conversation-brainstorming

2005-07-30T03:03:26Z

LucasGonze: added note on copying of asssertions

=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].

==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.

: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."

: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 ID of the original containing page 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>

== 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.

==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/

media-metadata-examples

2005-07-29T20:44:36Z

LucasGonze: /* Comments */

This is an exploratory page to be used for storage of various multimedia metadata profiles currently in use around the web. As this is a very, very early exploration, we should include as many types of multimedia as possible in the opening discussion - but please be sure to place your profiles in the correct portion of this page.

= Purpose of this exploration (or : The Problem) =

The purpose of the studies on this page is to determine the feasibility and demand for a flexible, semantic markup format for providing metadata alongside linked multimedia files. Typically, this metadata is stored within the header of the media file itself - which has massive implications for any application where metadata is to be indexed, searched, or made externally accessible. Of course, even if you could easily access the correct portions of a media file remotely, you'd still have to cope with a multitude of open and proprietary metadata formats, each with it's own distinct fieldset, nomenclature and storage method.

This study aims to make a start at solving this problem.

== Contributors ==

These folks have contributed real-world examples and research to this document, and are interested in helping with a solution.

* Christopher Allen
* Dougal Campbell
* Dr. Ernie
* Rohit Khare
* Ryan King
* Kevin Marks
* Danski

If you contribute new real-world examples or research, and wish to help with a solution, please add your name as well.

= Examples =

== Still image ==

* [http://www.exif.org/Exif2-2.PDF EXIF]
* [http://www.tasi.ac.uk/2000/09/rdfmeta/ RDF for self-describing images]
* [http://archive.dstc.edu.au/RDU/staff/jane-hunter/PNG/paper.html An Indexing and Querying System for Online Images Based on the PNG Format and Embedded Metadata]
* [http://www.w3.org/TR/photo-rdf/ Describing and retrieving photos using RDF and HTTP]

== Audio ==

* [http://www.id3.org/ ID3v2]

* iTunes
** Album : String
** Artist : String
** Beats Per Minute : Number
** Bit Rate : Number
** Comment : Blob
** Composer : String
** Genre : String or Foreign ID
** Disc Number : Number
** Kind : Proprietary - could be implimented as MIME type
** My Rating : Number < 5
** Sample Rate : Number
** Size : Number
** Time : Number
** Track Number : Number
** Year : Number
**Additional metadata used internally by the application : Date Added (Timestamp), Date Modified (Timestamp), Equalizer (foreign ID), Play Count (Number), Grouping (Internal)
**Noteable absences : Tags, [[rel-license|License]], Copyright year. Also note common complaints about [http://www.everything2.com/index.pl?node_id=1707402 ID3 and classical music].

* XSPF
** album
** creator
** duration
** info
** title
** trackNum

== Podcasts ==

* '''iTunes podcast:''' http://phobos.apple.com/static/podcast_specifications.pdf
(HTML version of spec: [http://labs.commerce.net/~rohit/How%20To%20Publish%20a%20Podcast%20on%20iTunes%20Music%20Store.html local archive], [http://labs.commerce.net/~rohit/iTunesRSS.html updated version from Apple Chapter Tool Beta docs], [http://phobos.apple.com/static/iTunesRSS.html online copy at Apple])

iTunes release 4.9 was widely heralded as an advance for mainstream acceptance of podcasting. However, while some advocates resist even the fragment of a trademarked name in the label for the phenomenon, the use of "itunes:" in the namespace is one of many design decisions in Apple's original specification that became focal points of debate. While Apple has a tradition of working on breakthrough features very quietly, they have been open to public input after its initial release. Many [http://daringfireball.net/2005/07/podcast_pocket other bloggers] have [http://usefulinc.com/edd/blog/contents/2005/06/28-rss-apple-itunes/read chronicled] [http://www.intertwingly.net/blog/2005/07/05/Insensitive-iTunes some of the feedback], as well as some [http://tantek.com/log/2005/07.html#d10t0130 face-to-face discussions].

A mailing list may be coming soon...

* '''Media RSS:''' http://search.yahoo.com/mrss

Media RSS has [http://www.ysearchblog.com/archives/000111.html been in the works longer], but doesn't have the overnight-adoption advantage of iTunes. However, it has a much broader ambit, including [http://www.ysearchblog.com/archives/000060.html video]; and a much broader [http://groups.yahoo.com/group/rss-media/ community of interest].

=== A Podcasting Microformat? ===

The best starting point for understanding these two proposals is [http://www.w3.org/2005/07/media-and-rss W3C's summary table, by Karl Dubost].

There are (at least) two paths to consider when 'porting' these proposals into Microformats:
# '''Standalone.''' What is the most straightforward rendering of each proposal into XHTML? This keeps the interests of the developers of ''consuming'' applications foremost: how can the migration be made as painless as possible?
# '''Refactored.''' Given the existing core of Microformats, what is the minimal (!) necessary to add on to RelLicense, RelTag, hReview, and so forth? This favors (we'd hope) content ''publishing'' applications: how can the marginal migration costs of adding media be made as painless as possible.

Mapping the existing specs requires understanding the data definitions set forth in each specification, and finding the optimal equivalents (where available). The following is a partial summary of one possible mapping:

{| border="1" cellpadding="5" cellspacing="0" style="border:1px solid grey;"
|+ Comparing existing proposals
! Aspect !! Apple !! Yahoo! !! Microformat?
|-
| '''Categorization'''
|| <itunes:category> <itunes:keywords>
|| <media:category>
|| [[rel-tag | RelTag]] - requires a way to do sub categories?
|-
| '''Rating''' || <itunes:explicit>|| <media:adult> || [[rel-tag | RelTag]]
|-
| '''Description''' ||<itunes:subtitle> <itunes:summary>|| <media:text> || XHTML (e.g. < blockquote > )
|-
| '''Authorship'''
|| <itunes:author> <itunes:owner> <itunes:name> <itunes:email>
|| <media:credit>
|| <cite> [[hcard|hCard]]
|-
| '''Metadata''' || <itunes:duration> <itunes:image>|| <media:thumbnail> <media:hash> 
<media:content
url="http://www.foo.com/movie.mov"
fileSize="12216320"
type="video/quicktime"
isDefault="true"
expression="full"
bitrate="128"
framerate="25"
duration="185"
height="200"
width="300" />
|| ''needs a new microformat'' e.g., <dt> <dd>
|-
| '''Licensing''' || <itunes:block> <copyright> <link>|| Not explicitly mentioned || [[rel-license | RelLicense]]
|-
|}

== Video ==
* [http://www.exif.org/Exif2-2.PDF EXIF] - (Yes, the spec deals with video taken by still cameras. -- RyanKing)
* [http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm MPEG-7] - MPEG-7, formally named "Multimedia Content Description Interface", is a standard for describing the multimedia content data that supports some degree of interpretation of the information meaning, which can be passed onto, or accessed by, a device or a computer code. (Very powerful, but you have to pay for documentation -- [[User:ChristopherA|ChristopherA]] 01:53, 29 Jun 2005 (PDT))
* [http://www.w3.org/AudioVideo/ SMIL] - Synchronized Multimedia Integration Language (SMIL, pronounced "smile") enables simple authoring of interactive audiovisual presentations. (Not exactly video, but has a lot of useful video-related features in it. -- [[User:ChristopherA|ChristopherA]] 01:55, 29 Jun 2005 (PDT))

== Interactive ==
* [http://www.w3.org/Graphics/SVG/ SVG]
* [http://www.w3.org/AudioVideo/ SMIL]
* QTVR?

== Offline Media ==
* [http://xspf.org XSPF]

=== Printed Publications (books/magazines) ===
* [http://amazon.com/ Amazon]

=== Movies ===
* [http://imdb.com/ IMDB]
* [http://amazon.com/ Amazon]

=== Music ===
* [http://freedb.org/ FreeDB]
* [http://musicbrainz.org/ MusicBrainz]
* [http://amazon.com/ Amazon]

== Comments ==

The project being proposed here is a mishmash of issues -- a little metadata, a little syndication, a little playlisting. The goals need to be more focused. --LucasGonze

media-metadata-examples

2005-07-29T02:22:03Z

LucasGonze: /* Comments */

This is an exploratory page to be used for storage of various multimedia metadata profiles currently in use around the web. As this is a very, very early exploration, we should include as many types of multimedia as possible in the opening discussion - but please be sure to place your profiles in the correct portion of this page.

= Purpose of this exploration (or : The Problem) =

The purpose of the studies on this page is to determine the feasibility and demand for a flexible, semantic markup format for providing metadata alongside linked multimedia files. Typically, this metadata is stored within the header of the media file itself - which has massive implications for any application where metadata is to be indexed, searched, or made externally accessible. Of course, even if you could easily access the correct portions of a media file remotely, you'd still have to cope with a multitude of open and proprietary metadata formats, each with it's own distinct fieldset, nomenclature and storage method.

This study aims to make a start at solving this problem.

== Contributors ==

These folks have contributed real-world examples and research to this document, and are interested in helping with a solution.

* Christopher Allen
* Dougal Campbell
* Dr. Ernie
* Rohit Khare
* Ryan King
* Kevin Marks
* Danski

If you contribute new real-world examples or research, and wish to help with a solution, please add your name as well.

= Examples =

== Still image ==

* [http://www.exif.org/Exif2-2.PDF EXIF]
* [http://www.tasi.ac.uk/2000/09/rdfmeta/ RDF for self-describing images]
* [http://archive.dstc.edu.au/RDU/staff/jane-hunter/PNG/paper.html An Indexing and Querying System for Online Images Based on the PNG Format and Embedded Metadata]
* [http://www.w3.org/TR/photo-rdf/ Describing and retrieving photos using RDF and HTTP]

== Audio ==

* [http://www.id3.org/ ID3v2]

* iTunes
** Album : String
** Artist : String
** Beats Per Minute : Number
** Bit Rate : Number
** Comment : Blob
** Composer : String
** Genre : String or Foreign ID
** Disc Number : Number
** Kind : Proprietary - could be implimented as MIME type
** My Rating : Number < 5
** Sample Rate : Number
** Size : Number
** Time : Number
** Track Number : Number
** Year : Number
**Additional metadata used internally by the application : Date Added (Timestamp), Date Modified (Timestamp), Equalizer (foreign ID), Play Count (Number), Grouping (Internal)
**Noteable absences : Tags, [[rel-license|License]], Copyright year. Also note common complaints about [http://www.everything2.com/index.pl?node_id=1707402 ID3 and classical music].

* XSPF
** album
** creator
** duration
** info
** title
** trackNum

== Podcasts ==

* '''iTunes podcast:''' http://phobos.apple.com/static/podcast_specifications.pdf
(HTML version of spec: [http://labs.commerce.net/~rohit/How%20To%20Publish%20a%20Podcast%20on%20iTunes%20Music%20Store.html local archive], [http://labs.commerce.net/~rohit/iTunesRSS.html updated version from Apple Chapter Tool Beta docs], [http://phobos.apple.com/static/iTunesRSS.html online copy at Apple])

iTunes release 4.9 was widely heralded as an advance for mainstream acceptance of podcasting. However, while some advocates resist even the fragment of a trademarked name in the label for the phenomenon, the use of "itunes:" in the namespace is one of many design decisions in Apple's original specification that became focal points of debate. While Apple has a tradition of working on breakthrough features very quietly, they have been open to public input after its initial release. Many [http://daringfireball.net/2005/07/podcast_pocket other bloggers] have [http://usefulinc.com/edd/blog/contents/2005/06/28-rss-apple-itunes/read chronicled] [http://www.intertwingly.net/blog/2005/07/05/Insensitive-iTunes some of the feedback], as well as some [http://tantek.com/log/2005/07.html#d10t0130 face-to-face discussions].

A mailing list may be coming soon...

* '''Media RSS:''' http://search.yahoo.com/mrss

Media RSS has [http://www.ysearchblog.com/archives/000111.html been in the works longer], but doesn't have the overnight-adoption advantage of iTunes. However, it has a much broader ambit, including [http://www.ysearchblog.com/archives/000060.html video]; and a much broader [http://groups.yahoo.com/group/rss-media/ community of interest].

=== A Podcasting Microformat? ===

The best starting point for understanding these two proposals is [http://www.w3.org/2005/07/media-and-rss W3C's summary table, by Karl Dubost].

There are (at least) two paths to consider when 'porting' these proposals into Microformats:
# '''Standalone.''' What is the most straightforward rendering of each proposal into XHTML? This keeps the interests of the developers of ''consuming'' applications foremost: how can the migration be made as painless as possible?
# '''Refactored.''' Given the existing core of Microformats, what is the minimal (!) necessary to add on to RelLicense, RelTag, hReview, and so forth? This favors (we'd hope) content ''publishing'' applications: how can the marginal migration costs of adding media be made as painless as possible.

Mapping the existing specs requires understanding the data definitions set forth in each specification, and finding the optimal equivalents (where available). The following is a partial summary of one possible mapping:

{| border="1" cellpadding="5" cellspacing="0" style="border:1px solid grey;"
|+ Comparing existing proposals
! Aspect !! Apple !! Yahoo! !! Microformat?
|-
| '''Categorization'''
|| <itunes:category> <itunes:keywords>
|| <media:category>
|| [[rel-tag | RelTag]] - requires a way to do sub categories?
|-
| '''Rating''' || <itunes:explicit>|| <media:adult> || [[rel-tag | RelTag]]
|-
| '''Description''' ||<itunes:subtitle> <itunes:summary>|| <media:text> || XHTML (e.g. < blockquote > )
|-
| '''Authorship'''
|| <itunes:author> <itunes:owner> <itunes:name> <itunes:email>
|| <media:credit>
|| <cite> [[hcard|hCard]]
|-
| '''Metadata''' || <itunes:duration> <itunes:image>|| <media:thumbnail> <media:hash> 
<media:content
url="http://www.foo.com/movie.mov"
fileSize="12216320"
type="video/quicktime"
isDefault="true"
expression="full"
bitrate="128"
framerate="25"
duration="185"
height="200"
width="300" />
|| ''needs a new microformat'' e.g., <dt> <dd>
|-
| '''Licensing''' || <itunes:block> <copyright> <link>|| Not explicitly mentioned || [[rel-license | RelLicense]]
|-
|}

== Video ==
* [http://www.exif.org/Exif2-2.PDF EXIF] - (Yes, the spec deals with video taken by still cameras. -- RyanKing)
* [http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm MPEG-7] - MPEG-7, formally named "Multimedia Content Description Interface", is a standard for describing the multimedia content data that supports some degree of interpretation of the information meaning, which can be passed onto, or accessed by, a device or a computer code. (Very powerful, but you have to pay for documentation -- [[User:ChristopherA|ChristopherA]] 01:53, 29 Jun 2005 (PDT))
* [http://www.w3.org/AudioVideo/ SMIL] - Synchronized Multimedia Integration Language (SMIL, pronounced "smile") enables simple authoring of interactive audiovisual presentations. (Not exactly video, but has a lot of useful video-related features in it. -- [[User:ChristopherA|ChristopherA]] 01:55, 29 Jun 2005 (PDT))

== Interactive ==
* [http://www.w3.org/Graphics/SVG/ SVG]
* [http://www.w3.org/AudioVideo/ SMIL]
* QTVR?

== Offline Media ==
* [http://xspf.org XSPF]

=== Printed Publications (books/magazines) ===
* [http://amazon.com/ Amazon]

=== Movies ===
* [http://imdb.com/ IMDB]
* [http://amazon.com/ Amazon]

=== Music ===
* [http://freedb.org/ FreeDB]
* [http://musicbrainz.org/ MusicBrainz]
* [http://amazon.com/ Amazon]

== Comments ==

Having spent a lot of time in this area, and seeing the stage this work is at, I'm a bit skeptical of this project. The project being proposed here is a mishmash of issues -- a little metadata, a little syndication, a little playlisting. A sprinkling of microformat dust isn't going to simplify the underlying research. At the least this project needs to be slimmed down quite a lot. --LucasGonze

media-metadata-examples

2005-07-29T02:18:58Z

LucasGonze:

This is an exploratory page to be used for storage of various multimedia metadata profiles currently in use around the web. As this is a very, very early exploration, we should include as many types of multimedia as possible in the opening discussion - but please be sure to place your profiles in the correct portion of this page.

= Purpose of this exploration (or : The Problem) =

The purpose of the studies on this page is to determine the feasibility and demand for a flexible, semantic markup format for providing metadata alongside linked multimedia files. Typically, this metadata is stored within the header of the media file itself - which has massive implications for any application where metadata is to be indexed, searched, or made externally accessible. Of course, even if you could easily access the correct portions of a media file remotely, you'd still have to cope with a multitude of open and proprietary metadata formats, each with it's own distinct fieldset, nomenclature and storage method.

This study aims to make a start at solving this problem.

== Contributors ==

These folks have contributed real-world examples and research to this document, and are interested in helping with a solution.

* Christopher Allen
* Dougal Campbell
* Dr. Ernie
* Rohit Khare
* Ryan King
* Kevin Marks
* Danski

If you contribute new real-world examples or research, and wish to help with a solution, please add your name as well.

= Examples =

== Still image ==

* [http://www.exif.org/Exif2-2.PDF EXIF]
* [http://www.tasi.ac.uk/2000/09/rdfmeta/ RDF for self-describing images]
* [http://archive.dstc.edu.au/RDU/staff/jane-hunter/PNG/paper.html An Indexing and Querying System for Online Images Based on the PNG Format and Embedded Metadata]
* [http://www.w3.org/TR/photo-rdf/ Describing and retrieving photos using RDF and HTTP]

== Audio ==

* [http://www.id3.org/ ID3v2]

* iTunes
** Album : String
** Artist : String
** Beats Per Minute : Number
** Bit Rate : Number
** Comment : Blob
** Composer : String
** Genre : String or Foreign ID
** Disc Number : Number
** Kind : Proprietary - could be implimented as MIME type
** My Rating : Number < 5
** Sample Rate : Number
** Size : Number
** Time : Number
** Track Number : Number
** Year : Number
**Additional metadata used internally by the application : Date Added (Timestamp), Date Modified (Timestamp), Equalizer (foreign ID), Play Count (Number), Grouping (Internal)
**Noteable absences : Tags, [[rel-license|License]], Copyright year. Also note common complaints about [http://www.everything2.com/index.pl?node_id=1707402 ID3 and classical music].

* XSPF
** album
** creator
** duration
** info
** title
** trackNum

== Podcasts ==

* '''iTunes podcast:''' http://phobos.apple.com/static/podcast_specifications.pdf
(HTML version of spec: [http://labs.commerce.net/~rohit/How%20To%20Publish%20a%20Podcast%20on%20iTunes%20Music%20Store.html local archive], [http://labs.commerce.net/~rohit/iTunesRSS.html updated version from Apple Chapter Tool Beta docs], [http://phobos.apple.com/static/iTunesRSS.html online copy at Apple])

iTunes release 4.9 was widely heralded as an advance for mainstream acceptance of podcasting. However, while some advocates resist even the fragment of a trademarked name in the label for the phenomenon, the use of "itunes:" in the namespace is one of many design decisions in Apple's original specification that became focal points of debate. While Apple has a tradition of working on breakthrough features very quietly, they have been open to public input after its initial release. Many [http://daringfireball.net/2005/07/podcast_pocket other bloggers] have [http://usefulinc.com/edd/blog/contents/2005/06/28-rss-apple-itunes/read chronicled] [http://www.intertwingly.net/blog/2005/07/05/Insensitive-iTunes some of the feedback], as well as some [http://tantek.com/log/2005/07.html#d10t0130 face-to-face discussions].

A mailing list may be coming soon...

* '''Media RSS:''' http://search.yahoo.com/mrss

Media RSS has [http://www.ysearchblog.com/archives/000111.html been in the works longer], but doesn't have the overnight-adoption advantage of iTunes. However, it has a much broader ambit, including [http://www.ysearchblog.com/archives/000060.html video]; and a much broader [http://groups.yahoo.com/group/rss-media/ community of interest].

=== A Podcasting Microformat? ===

The best starting point for understanding these two proposals is [http://www.w3.org/2005/07/media-and-rss W3C's summary table, by Karl Dubost].

There are (at least) two paths to consider when 'porting' these proposals into Microformats:
# '''Standalone.''' What is the most straightforward rendering of each proposal into XHTML? This keeps the interests of the developers of ''consuming'' applications foremost: how can the migration be made as painless as possible?
# '''Refactored.''' Given the existing core of Microformats, what is the minimal (!) necessary to add on to RelLicense, RelTag, hReview, and so forth? This favors (we'd hope) content ''publishing'' applications: how can the marginal migration costs of adding media be made as painless as possible.

Mapping the existing specs requires understanding the data definitions set forth in each specification, and finding the optimal equivalents (where available). The following is a partial summary of one possible mapping:

{| border="1" cellpadding="5" cellspacing="0" style="border:1px solid grey;"
|+ Comparing existing proposals
! Aspect !! Apple !! Yahoo! !! Microformat?
|-
| '''Categorization'''
|| <itunes:category> <itunes:keywords>
|| <media:category>
|| [[rel-tag | RelTag]] - requires a way to do sub categories?
|-
| '''Rating''' || <itunes:explicit>|| <media:adult> || [[rel-tag | RelTag]]
|-
| '''Description''' ||<itunes:subtitle> <itunes:summary>|| <media:text> || XHTML (e.g. < blockquote > )
|-
| '''Authorship'''
|| <itunes:author> <itunes:owner> <itunes:name> <itunes:email>
|| <media:credit>
|| <cite> [[hcard|hCard]]
|-
| '''Metadata''' || <itunes:duration> <itunes:image>|| <media:thumbnail> <media:hash> 
<media:content
url="http://www.foo.com/movie.mov"
fileSize="12216320"
type="video/quicktime"
isDefault="true"
expression="full"
bitrate="128"
framerate="25"
duration="185"
height="200"
width="300" />
|| ''needs a new microformat'' e.g., <dt> <dd>
|-
| '''Licensing''' || <itunes:block> <copyright> <link>|| Not explicitly mentioned || [[rel-license | RelLicense]]
|-
|}

== Video ==
* [http://www.exif.org/Exif2-2.PDF EXIF] - (Yes, the spec deals with video taken by still cameras. -- RyanKing)
* [http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm MPEG-7] - MPEG-7, formally named "Multimedia Content Description Interface", is a standard for describing the multimedia content data that supports some degree of interpretation of the information meaning, which can be passed onto, or accessed by, a device or a computer code. (Very powerful, but you have to pay for documentation -- [[User:ChristopherA|ChristopherA]] 01:53, 29 Jun 2005 (PDT))
* [http://www.w3.org/AudioVideo/ SMIL] - Synchronized Multimedia Integration Language (SMIL, pronounced "smile") enables simple authoring of interactive audiovisual presentations. (Not exactly video, but has a lot of useful video-related features in it. -- [[User:ChristopherA|ChristopherA]] 01:55, 29 Jun 2005 (PDT))

== Interactive ==
* [http://www.w3.org/Graphics/SVG/ SVG]
* [http://www.w3.org/AudioVideo/ SMIL]
* QTVR?

== Offline Media ==
* [http://xspf.org XSPF]

=== Printed Publications (books/magazines) ===
* [http://amazon.com/ Amazon]

=== Movies ===
* [http://imdb.com/ IMDB]
* [http://amazon.com/ Amazon]

=== Music ===
* [http://freedb.org/ FreeDB]
* [http://musicbrainz.org/ MusicBrainz]
* [http://amazon.com/ Amazon]

== Comments ==

Having spent a lot of time in this area, and seeing the stage this work is at, I'm a bit skeptical of this project. The project being proposed here is a mishmash of issues -- a little ID3, a little RSS, a little XSPF. A sprinkling of microformat dust isn't going to simplify things, and I don't know of any members of the microformats community interested in marrying the problem for a couple years. At the least this project needs to be slimmed down quite a lot. --LucasGonze