Re: Notes on the latest draft.
On Wed, 20 Jul 2005, James Cerra wrote: Aristotle Pagaltzis, Thanks for the clarifications. Section 1.2: http://www.w3.org/2005/Atom I guess consistancy is not a requirement of the Atom spec. By convention, this should be all lowercase. Existing software I'm not sure who said this should be all lowercase but I don't understand the concern. Only programmers will be hand-keying a namespace. Most programming languages are case sensitive; XML is case sensitive; if a programmer can't spell, how can s/he be a successful programmer of XML tools? Genuinely baffled, -rcc for Atom 0.3 has to be recoded for Atom 1.0, so this change has no real cost. It does â in terms of time, for putting another draft through the process. Opposed with the cost of all the spelling errors that the general public will make? The cost to fix it now is marginal compared with the cost over decades of Atom 1.0 feeds. Individually these changes may not warrent a new draft, but together I think they warrant inclusion if, for some other reason, a new draft is drafted. Section 3.2.2: -- The atom:uri element's content conveys an IRI associated with the person. Person constructs MAY contain an atom:uri element, but MUST NOT contain more than one. The content of atom:uri in a Person construct MUST be an IRI reference. There is no reason *not* to change this to atom:id. It is lazy and dangerous to have an element lie about the type of its content. Furthermore, the whole point of atom:uri is the same as atom:id - to identify the thing they refer to (author or entry) - and their content is likewise identical. This is really a homepage link. It serves a totally different purpose from atom:id, and using the same term for the two would be dangerous. You might be right but then it should be named atom:homepage. Calling it atom:uri is misleading. I guess my main complaint about Atom right now is that it feels like there is little consistency with regard to the name and structure of elements. That makes it harder for humans to understand than it has to be. (An important point I think, since humans create the software and misunderstandings often create the hardest bugs to work around.) Section 4.2.6: -- In other words, relative IRIs are forbidden and thus no interaction with xml:base is possible either. Oversight on my part. Got it. -- Jimmy Cerra https://nemo.dev.java.net Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs --
Re: Author and contributor
+1 make atom:author plural +1 keep atom:contributor - Robin Cover
Re: the atom:copyright element
On Sun, 8 May 2005, Roger B. wrote: A rights description might talk about trademarks, registered trademarks, service marks, and so forth: different from copyright. Isolating this statement creates a misrepresentation of the argument for using the label rights. The quoted statement is a reminder that copyright is only ONE kind of right typically treated as intellectual property right. However, the more substantive argument for using the label rights is that users nowadays want to express an intent about permissions for usage (particular usages, in particular usage contexts, by particular classes of corporate entities, with particular financial restrictions, etc), and these expression for permission fall outside the realm of copyright. I made a survey of the major metadata specifications in use, as well as a number of syndication formats: most of them formally recognize the difference between rights and copyright with respect to digital works. I won't bother this Atom list with a list of such specifications/standards, beause it's (apparently) irrelevant. One example, might help, in case the examples already given (Dublin Core, dc:rights etc, and Open Archive Initiative) [1] are unclear. A new example is IPTC's NewsML [2]. Here's a summary of NewsML followed by a summary of the NewsML documentation explaining why the markup language uses a 'RightsMetadata' markup element, and not just 'copyright' NewsML, according to the developers, is the versatile News Markup Language for global news exchange. NewsML is designed to provide a media-independent, structural framework for multi-media news. It's used by Business Wire, Reuters, and many others (e.g., Agence France Presse, ANA, ANSA, Japan Newspaper Publishers Editors Association NSK, JCN Newswire, MarketWire, PA News, PR Newswire, SDA/ATS, The Irish Times, United Press International, Wall Street Journal Online). NewsML can be applied at all stages in the (electronic) news lifecycle. Typical use would include: (1) in and between editorial systems; (2) between news agencies and their customers; (3) between publishers and news aggregators; (4) and between news service providers and end users. Hopefully, it's obvious why Atom and NewsML often appear in the same list of technologies for news syndication. NewsML and Atom both have markup elements for metadata; NewsML has a few more than Atom's 15x, but the idea is the same: there's content and metadata (about content). In the NewsML documentation for metadata markup elements, the distinction is made between copyrights and usage rights: arguably, forcing all rights information into copyright is suboptimal, as well as simply incorrect with respect to bodies of law that govern these concepts. NewsML documentation: [4] 4.1.1 Classes of metadata NewsML divides the world of Metadata at the NewsComponent level into four classes: 1) Administrative Metadata: information about a package of news objects, or about the creation of the content contained in or referenced by the constituents of the NewsComponent. 2) Descriptive Metadata: information about the content contained in or referenced by the constituents of the NewsComponent. 3) Rights Metadata: information about the copyrights and usage rights of the content contained in or referenced by the constituents 4) Miscellaneous: other metadata... The RightsMetadata element contains information about the rights pertaining to the constituents of a NewsComponent, and any relevant usage rights that have been granted by the copyright holder to other parties. There's the difference, as articulated by NewsML, very similar to the markup terms used by Dublin Core, OAI-PMH, and a large number of other syndication/metadata formats: copyright is a narrow legal term that distinct from usage rights and other kinds of rights that are commonly expressed for Internet resources. Robin: In my opinion, the only place an atom:copyright should appear is at the feed level, Interesting: the Atom spec does not seem to share this point of view, if I have read it correctly Cheers, -rcc as an assertion of ownership of the feed document itself. Rights statements relating to individual entries should live within the content, particularly references to trademarks and the like. So I guess I'm -1 on atom:rights. -- Roger Benningfield [1] http://www.imc.org/atom-syntax/mail-archive/msg14944.html [2] http://www.newsml.org/pages/index.php [3] http://www.newsml.org/pages/whouse_main.php [4] http://www.newsml.org/IPTC/NewsML/1.2/documentation/NewsML_1.2-doc-Guidelines_1.00.pdf --
the atom:copyright element
The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'. Since this element name change is not likely to have any secondary ramifications that would affect other areas of the format design, it should be harmless. Using the element name 'atom:rights', as argued below, could enhance interoperability and avoid some unforeseen and unintended legal implications that may emerge from use of the term (copyright). The term copyright has an established legal meaning -- or rather, set of established legal meanings, in various languages and jurisdictions, whereas rights is capable of a generic meaning that extends to the rights of readers (consumers) as well as to the rights of authors (creators). Why should the Atom spec support the latter and not the former? I agree with 99% of earlier list postings [0] to the effect that: DRM is a snakepit; we don't want to come anywhere near it; DRM patent terrorism is a scourge; rights management constructs per se DO NOT belong in the Atom design, etc. So, I do not advocate 'atom:rights' over 'atom:copyright' because I want Atom to support rights management (enforcement), but because I think using 'atom:copyright' gives privilege to the wrong set of stakeholders, and potentially leads to a legal mess. The label rights has no clear association with intellectual property law(s); by its genericity, it would allow for and support the (established) concept of IP rights claim + prohibition against copy/reuse/CreateDerivativeWork, which roughly == copyright, while allowing other concepts like you're free to use this, please include some kind of attribution for the source, thanks! Stated otherwise, a declaration like (version -08 example) copyrightCopyright (c) 2003, Mark Pilgrim/copyright serves the need of an author to assert IP ownership and to (possibly) discourage certain -- but unclear -- uses of the embedding Atom entry/feed. A declaration copyright... /copyright does nothing to encourage syndication, or to clearly communicate that the content of an Atom feed/entry may be re-used freely, by permission. Two other major initiatives have recognized that rights properly belong to users/readers as well as to authors, and have registered this opinion in the technical design of XML markup vocabularies: the Open Archives Initiative (OAI) [4] and Dublin Core Metadata Initiative (DCMI) [5]. OAI supports a model for federated databases and unified search engines that access archives at hundreds of digital libraries and archive centers; DCMI's Dublin Core metadata model has been adopted for use in many HTML, XHTML, and XML markup applications. Formal specifications from both organizations allow generic rights markup elements that contain free-form text as well as by-reference (URI) pointers to resources that document the relevant rights -- which users are free to consult or ignore. I believe the Atom spec can do this similarly (and minimally) with an 'atom:rights' element in place of 'atom:copyright'. It can do so optimally by allowing one (optional) generic URI reference to a resource that documents the rights statement(s) from the creator of an Atom feed/entry. Something non-legal, like 'rightsDescription=URI'. I predict that if the Atom spec does not make this kind of accommodation to support this widely attested requirement, multiple (incompatible) ad hoc solutions will be invented, alongside widespread abuse of the 'atom:copyright' element. Surely, multiple (incompatible) ad hoc solutions will be invented ANYWAY, but providing the basic markup construct in the Atom syntax spec would point users in the right direction, rather than leaving them directionless. In making this request for WG reconsideration of the appropriateness of the element name 'atom:copyright', I respect the fact that the The Atom Syndication Format specification is in last call [6], near that finish line and onto the last lap [7]. Thanks, Robin Cover OASIS XML Cover Pages http://xml.coverpages.org/ PS [Bob Wyman,] Note that I have not referenced the Creative Commons or (machine-readable) licenses at all in the above. While I approve of both, I think any such use should be a decision left to an Atom author -- and I do not think it should be the role of the Atom spec designers to positively *prevent* an Atom author from referencing a machine-readable license in an unambiguous manner if s/he wishes to do so. Surely, enabling an Atom author to clearly declare her/his intent is preferable to enforcing intentional prose ambiguity through spec constraints. == Excursus on OAI and DCMI models for rights == I would *NOT* recommend modeling any Atom design after the OAI and DCMI designs, specifically, and I would *NOT* suggest that Atom recommend any behavior with respect
