Abstract
Suggest equivalences between terms in the Atom and Dublin Core/FOAF vocabularies to assist interoperability.
Status
Open
Rationale
It has been noted that many of the Atom terms have direct equivalents in other vocabularies. The consensus seems to be that in the interests of simplicity these terms are redefined in the Atom namespace. This reduces opportunities for interoperability with systems that use the other vocabularies. However it is often possible to map between different vocabularies, and the addition of the following suggested equivalences should help in the definition of such mappings.
Proposal
Unless anyone objects in the near future, I'll refactor this so it can appear as an appendix --DannyAyers
Take a look at how DocBook does it, as an example. -- KenMacLeod
The addition of the following lines to the text:
-
3.2.1 "atom:name" Element
An Atom agent MAY consider atom:name equivalent to foaf:name [FOAF]
-
3.2.2 "atom:url" Element
An Atom agent MAY consider atom:url equivalent to foaf:homepage [FOAF]
-
3.2.3 "atom:email" Element
An Atom agent MAY consider atom:email equivalent to foaf:mbox [FOAF]
-
3.4.4 "title" Attribute
An Atom agent MAY consider atom:title equivalent to dc:title [DC]
-
4.3 "atom:title" Element
An Atom agent MAY consider atom:title equivalent to dc:title [DC]
-
4.5 "atom:author" Element
An Atom agent MAY consider atom:author equivalent to dc:creator [DC]
-
4.6 "atom:contributor" Element
An Atom agent MAY consider atom:contributor equivalent to dc:contributor [DC]
-
4.7 "atom:tagline" Element
An Atom agent MAY consider atom:tagline equivalent to dc:description [DC]
-
4.8 "atom:id" Element
An Atom agent MAY consider atom:id equivalent to dc:identifier [DC]
-
4.10 "atom:copyright" Element
An Atom agent MAY consider atom:copyright equivalent to dc:rights [DC]
-
4.11 "atom:info" Element
An Atom agent MAY consider atom:info equivalent to dc:description [DC]
-
4.12 "atom:modified" Element
An Atom agent MAY consider atom:modified equivalent to dcterms:modified [DCTERMS]
-
4.13.1 "atom:title" Element
An Atom agent MAY consider atom:title equivalent to dc:title [DC]
-
4.13.2 "atom:link" Element
An Atom agent MAY consider atom:link equivalent to dc:relation [DC]
-
4.13.3 "atom:author" Element
An Atom agent MAY consider atom:author equivalent to dc:creator [DC]
-
4.13.4 "atom:contributor" Element
An Atom agent MAY consider atom:contributor equivalent to dc:contributor [DC]
-
4.13.5 "atom:id" Element
An Atom agent MAY consider atom:id equivalent to dc:identifier [DC]
-
4.13.6 "atom:modified" Element
An Atom agent MAY consider atom:modified equivalent to dcterms:modified [DCTERMS]
-
4.13.7 "atom:issued" Element
An Atom agent MAY consider atom:issued equivalent to dcterms:issued [DCTERMS]
-
4.13.8 "atom:created" Element
An Atom agent MAY consider atom:created equivalent to dcterms:created [DCTERMS]
-
4.13.9 "atom:summary" Element
An Atom agent MAY consider atom:summary equivalent to dcterms:abstract [DCTERMS]
-
4.13.10 "atom:content" Element
Impacts
None.
The term MAY is used throughout, the mappings are only advisory.
Notes
In practice it may be desirable to use different relationships between the Atom terms and their suggested equivalence. This will depend on the system in which the mapping is carried out.
The equivalences suggested here are based on those described by Ian Davis in "The Nucleus of Atom" :
http://internetalchemy.org/2004/03/theNucleusOfAtom
It may also be desirable to provide mappings to RSS entities, though as that is likely to be more controversial it's not covered here.
Comments/Revisions
Norm Walsh has reservations over the following:
atom:url/foaf:homepage
atom:tagline/dc:description
* atom:generator/dc:publisher
atom:link/dc:relation
atom:summary/dcterms:abstract
and notes: "No equivalence is suggested for 4.13.10 atom:content."
* generator/publisher was indupitably a bad fit (it's been pointed out elsewhere - Eric Scheid?), so that one's been pulled.
It's also been suggested that the mapping are listed together rather than distributed throughout the spec.
[MarkNottingham] This would fit better in a non-normative appendix, and would be easier to read. Otherwise, seems reasonable.
Agreed. I think Randy's type notes would be useful in there too, I'll refactor asap --DannyAyers
Content Type Equivalence
See DCMI schemas, FOAF spec
[RandyCharlesMorin] Let me clarify that some of the elements named herein are not all content type equivalent. By content type equivalent, I mean, the schema for the equivalent elements match. A list of matches and mismatches can be found here:
-
atom:person/name and foaf:name - ok
-
atom:person/url and foaf:homepage - ok
-
atom:person/email and foaf:mbox - ok
-
atom:link/@title and dc:title - attribute in atom, element in Dublin Core
-
atom:feed/title and dc:title - content types differ
-
atom:feed/author and dc:creator - content types differ
-
atom:feed/contributor and dc:contributor - content types differ
-
atom:feed/tagline and dc:description - content types differ
-
atom:feed/id and dc:identifier - ok
-
atom:feed/copyright and dc:rights - ok
-
atom:feed/info and dc:description - content types differ
-
atom:feed/modified and dcterms:modified - must be UTC in atom
-
atom:entry/title and dc:title - content types differ
-
atom:entry/link and dc:relation - content types differ
-
atom:entry/author and dc:creator - content types differ
-
atom:entry/contributor and dc:contributor - content types differ
-
atom:entry/id and dc:identifier - ok
-
atom:entry/modified and dcterms: modified - ok
-
atom:entry/issued and dcterms:issued - ok
-
atom:entry/created and dcterms:created - ok
-
atom:entry/summary and dcterms:abstract - content types differ
(copied from here)