idnits 2.17.1 draft-nottingham-atomtriples-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 325. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2008) is 5779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft D. Beckett 4 Intended status: Informational June 30, 2008 5 Expires: January 1, 2009 7 AtomTriples: Embedding RDF Statements in Atom 8 draft-nottingham-atomtriples-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 1, 2009. 35 Abstract 37 This specification describes AtomTriples, a set of Atom extension 38 elements for embedding RDF statements in Atom documents (both element 39 and feed), and declaring how they can be derived from existing 40 content. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 46 3. Embedded Statements . . . . . . . . . . . . . . . . . . . . . . 3 47 3.1. The at:md Element . . . . . . . . . . . . . . . . . . . . . 4 48 3.2. The subject Attribute . . . . . . . . . . . . . . . . . . . 4 49 4. Derived Statements . . . . . . . . . . . . . . . . . . . . . . 4 50 4.1. The at:feedmap Element . . . . . . . . . . . . . . . . . . 5 51 4.2. The at:entrymap Element . . . . . . . . . . . . . . . . . . 5 52 4.3. The at:map Element . . . . . . . . . . . . . . . . . . . . 5 53 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 56 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . . . 8 61 1. Introduction 63 This specification describes AtomTriples, a set of Atom [RFC4287] 64 extension elements for embedding RDF 65 [W3C.WD-rdf-syntax-grammar-20031010] statements in Atom documents 66 (both element and feed), as well as declaring how they can be derived 67 from existing content. 69 Statements can be embedded directly as RDF/XML using the at:md 70 element at the feed or entry level. Additionally, a feed can declare 71 that specific Atom elements (or extensions) can be parsed into RDF 72 statements using the at:feedmap element (for metadata attached to a 73 feed) or an at:entrymap element (for metadata attached to entries). 75 The semantics of a property that appears in both places (e.g., in a 76 feed-level at:md as well as derived from a at:feedmap) is undefined; 77 presumably, they would be added to the model as two separate 78 statements. 80 Likewise, the mechanics of combining metadata from multiple instances 81 of the same entry, or from multiple feed documents, is out of the 82 scope of this specification. 84 2. Notational Conventions 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 All XML elements in this specification use the the namespace URI 91 [W3C.REC-xml-names-19990114] 92 "http://purl.org/syndication/atomtriples/1". In this document, that 93 URI is mapped to the "at" prefix. 95 Unless specified otherwise, AtomTriples elements MAY contain foreign 96 markup, which SHOULD be handled according as it is in the Atom 97 syndication format. 99 3. Embedded Statements 101 RDF statements can be directly embedded in Atom feeds and entries as 102 RDF/XML using the at:md element. 104 3.1. The at:md Element 106 The at:md element MAY occur as a child of atom:feed or atom:entry, 107 and contains any number of RDF statements which MUST serialised as 108 RDF/XML. It MAY occur in a given context any number of times. 110 The subject of these statements is, by default, the value of the 111 atom:id element in the same context (atom:element or atom:feed). 112 However, this behaviour MAY be overridden by specifying the subject 113 attribute. 115 After the subject is determined, the contents SHOULD be processed as 116 a propertyEltList in [W3C.WD-rdf-syntax-grammar-20031010]. 118 3.2. The subject Attribute 120 When present, the subject attribute indicates how to derive the RDF 121 subject of statements sourced from the element it is attached to. 123 It MUST contain a URI which MUST be interpreted as a link relation; 124 the first such occurrence of an atom:link element in the same context 125 as its parent element with that relation (in lexical order) will 126 indicate the URI to use as the subject. 128 For example, 130 131 Atom-Powered Robots Run Amok 132 133 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 134 2003-12-13T18:30:02Z 135 Some text. 136 137 138 139 141 indicates that the subject of statements in this entry is 142 "http://example.org/2003/12/13/atom03" (because Atom links default to 143 the "alternate" relation). 145 This specification does not define the semantics of the subject 146 attribute when a suitable link cannot be found. 148 4. Derived Statements 150 Atom documents can declare mappings of existing content to RDF 151 statements using the at:feedmap and at:entrymap elements. 153 4.1. The at:feedmap Element 155 The at:feedmap element MAY occur as a child of atom:feed, and MUST 156 NOT occur more than once. It MAY contain any number of at:map 157 elements which indicate mappings for feed-level element contents to 158 statements, within the scope of the feed document it occurs in. 160 4.2. The at:entrymap Element 162 The at:entrymap element MAY occur as a child of atom:feed, and MAY 163 occur as the child of atom:entry in an Atom Entry Document. It MUST 164 NOT occur more than once, and MAY contain any number of at:map 165 elements which indicate mappings for entry-level element contents to 166 statements, within the scope of the document it occurs in. 168 4.3. The at:map Element 170 The at:map element indicates how an element in a given context 171 (either feed or entry, depending on use) maps to RDF statements. Its 172 content MUST be an XML QName, and indicates the element that is being 173 mapped. It MUST have a property attribute that MUST be a URI, which 174 associates the element in the appropriate context with the given RDF 175 property. 177 For example, 179 atom:title 182 indicates that the atom:title element's content should be mapped to 183 the http://purl.org/dc/elements/1.1/title property. Given the entry 185 186 http://example.com/a 187 Test 188 190 and the map above as a child of at:entrymap, the following triple 191 would be implied; 193 "Test" . 195 The exact URI to use as the subject of the statements derived by 196 mapping is, by default, the value of the atom:id element in the same 197 context. However, this behaviour MAY be overridden by specifying the 198 subject attribute. 200 By default, the content of the given element will be converted to an 201 RDF Literal if it contains no markup, and to an XML Literal if it 202 does. This behaviour may be modified by future revisions of this 203 specification. 205 5. Example 207 209 Example Feed 210 211 2003-12-13T18:30:02Z 212 213 John Doe 214 215 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 216 217 218 219 220 221 222 223 atom:title 224 225 226 227 atom:title 229 231 232 Atom-Powered Robots Run Amok 233 234 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 235 2003-12-13T18:30:02Z 236 Some text. 237 238 239 241 242 243 244 245 6. Security Considerations 247 The security considerations for these extensions are the union of 248 those that apply to processing both Atom and RDF. 250 7. IANA Considerations 252 This document has no actions for IANA. 254 8. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 260 Format", RFC 4287, December 2005. 262 [W3C.REC-xml-names-19990114] 263 Bray, T., Hollander, D., and A. Layman, "Namespaces in 264 XML", W3C REC REC-xml-names-19990114, January 1999. 266 [W3C.WD-rdf-syntax-grammar-20031010] 267 Beckett, D., "RDF/XML Syntax Specification (Revised)", W3C 268 LastCall WD-rdf-syntax-grammar-20031010, October 2003. 270 Appendix A. Acknowledgements 272 The authors would like to thank Hong Zhang for his help and feedback; 273 they take all responsibility for errors and omissions. 275 Authors' Addresses 277 Mark Nottingham 279 Email: mnot@pobox.com 280 URI: http://www.mnot.net/ 282 Dave Beckett 284 Email: dave@dajobe.org 285 URI: http://www.dajobe.org/ 287 Full Copyright Statement 289 Copyright (C) The IETF Trust (2008). 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 298 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 299 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 300 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Intellectual Property 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org.