OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Discussion Requested: ODF <dc:creator> conflicts


This is all interesting, I'm sure, but I'm not seeing what the problem is. 
 Is there any application that is currently having difficulty with these 
elements, or who is unsure of what they can put down in these values?  Is 
there some interoperability problem someone is having with ODF documents 
and another Dublin Core processing application that hinges on differing 
nuances for what dc:creator means?

It really looks like this as just strings from what any program can make 
of them.  The distinction between "entity primarily responsible for making 
the content of the resource" and "the person who last modified the 
document" is entirely in the human domain.  I can't think of any existing 
word processor that is capable of distinguishing these two.  It is really 
just a librarian versus content author perspective difference.  Dublin 
core states it from the librarian/curator perspective, and ODF states it 
from the document author perspective.  But these are different sides of 
the same coin, not necessarily in conflict.

-Rob


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 04/01/2009 
01:34:30 PM:

> From:
> 
> "Dennis E. Hamilton" <dennis.hamilton@acm.org>
> 
> To:
> 
> "ODF TC List" <office@lists.oasis-open.org>
> 
> Date:
> 
> 04/01/2009 01:36 PM
> 
> Subject:
> 
> [office] Discussion Requested: ODF <dc:creator> conflicts
> 
> I am requesting discussion on a problem with conflicts around 
> <dc:creator> as it is used in ODF.  The conflicts apply to both ODF 
> 1.1 and ODF 1.2 cd01-rev01.
> 
> I would like the discussion to proceed in two parts:
> 
>  1. Reaching agreement on the problem and need for a remedy (or not), 
> 
>  2. Depending on agreement about the problem, reaching agreement on 
> the remedy and how it is introduced. 
> 
> Here are my current thoughts on both:
> 
> 1. THE PROBLEM AND NEED FOR A REMEDY
> 
> SUMMARY: 
> 
> The ODF 1.1 and 1.2 (cd01-rev01) specifications make modifications 
> to the interpretation of namespace elements under a namespace that 
> the ODF TC and OASIS have no authority to modify.  In addition, the 
> modification is inconsistent with the uses of the particular 
> namespace element in different parts of the ODF specification and 
> interferes with any intention to rely on the same elements as 
> officially described by the legitimate authority.
> 
> PLEASE NOTE: There is an additional concern that may derail any 
> simple resolution:  THE USE OF "namespace" BY DCMI HAS NOTHING TO DO
> WITH XML NAMESPACES. (see 3, below). 
> 
> DETAILS:
> 
> 1.1 In ODF 1.1 section 3.7.1, Creator, the following statement is made:
> 
>      The <dc:creator> element specifies the name of the person who last
>      modified the document. The name of this element was chosen for 
>      compatibility with the Dublin Core, but this definition of 
"creator"
>      used here differs from Dublin Core, which defines creator as "An 
>      entity primarily responsible for making the content of the 
resource." 
>      In OpenDocument terminology, the last person to modify the document 

>      is primarily responsible for making the content of the document.
> 
> 1.2 The element at issue is, per ODF 1.1 section 1.3, Namespaces, 
> Table 3, and per the RNG Schema, 
> 
>      <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/";>
> 
> 1.3 That is, section 3.7.1 makes an inadmissible modification of a 
> namespace over which the ODF TC and OASIS have no authority.  (See 
> 1.6, below, for the finesse in ODF 1.2 cd01-rev01.)
> 
> 1.4 This situation is further complicated, in ODF 1.1, by the 
> introduction of <dc:creator> as a content element of the 
> <office:annotation> element (section 12.1).  The defined usage is 
> provided in section 12.1.1:
> 
>      The optional <dc:creator> element described in section 3.1.7 
specifies
>      the author of the annotation.
> 
> In this case, it is clear that the intended interpretation is to 
> identify the entity that created the annotation (along with the date
> and time of that creation), and not "the last person to modify the 
document."
> 
> 1.5 Similarly, ODF 1.1 specifies <dc:creator> as a content element 
> of the <office:change-info> element, defined in section 12.3 under 
Creator:
> 
>      The <dc:creator> element as described in section 3.1.7 specifies 
the 
>      name of the author who changed the document.
> 
> In this case, the wording is ambiguous.  Evidently, the element is 
> intended to identify the author of a particular change, not "the 
> last person to modify the document."
> 
> 1.6 In ODF 1.2 cd01-rev01, <cd:creator> is defined in section 3.3.2.7:
> 
>      The <dc:creator> element specifies the name of the person who last 
>      modified a document (<office:meta>), who created an annotation 
>      (<office:annotation>), who authored a change 
(<office:change-info>). 
> 
>      Note: The name of this element was chosen for compatibility with 
>      Dublin Core metadata, but this definition of "creator" used here 
>      differs from Dublin Core, which defines creator as "An entity 
>      primarily responsible for making the content of the resource." 
>      In OpenDocument terminology, the last person to modify the document
>      is primarily responsible for making the content of the document.
> 
> 1.7 The ODF 1.2 committee draft confines the modification of the 
> Dublin Core Element Set 1.1 namespace element to a note.  However, 
> the descriptive statement continues to make mutually-inconsistent 
> interpretations of the element and at least one is clearly 
> inconsistent with the definition in the Dublin Core Metadata Set 1.1.
> 
>  2. POSSIBLE REMEDY
> 
>  2.1 In addition to it being, I believe, seriously inappropriate to 
> redefine an element from a namespace not under OASIS and ODF TC 
> authority, it also creates the small problem of when that namespace 
> and its elements are desired to be used in exactly the way defined 
> under the Dublin Core Elements 1.1 specification (for example, in 
> arbitrary <office:meta> content elements either under the normative 
> ODF 1.1 schema or as foreign extensions under the ODF 1.2 schema and
> conformance clause).  There is no technical confusion in RDF 
> annotations, because a CURI of the form "dc:creator" is an attribute
> value shorthand for a URI, not an XML element or attribute name. 
> Consequently, the ODF interpretation can *never* be the intended 
> interpretation of the CURI or the unabbreviated URI "http://
> purl.org/dc/elements/1.1/creator".
> 
>  2.2 The <office:meta> <dc:creator> interpretation is implemented 
> heavily in production software that supports ODF.  This has been 
> confirmed in some feature-support inspection tests created at the OIC 
TC.
> 
>  2.3 One remedy is along the following lines:
> 
>    * Deprecate all use of <dc:creator> in ODF 1.2, making note of 
> the practice in <office:meta> and the recommended replacement there.
> (Note the special concerns and alternative in 3, below, and what 
> that might require as a remedy.)
> 
>    * Add the namespace "http://purl.org/dc/terms/"; to the ODF 1.2 
> cd01-rev01 section 1.3 Table 4 in addition to the namespace binding 
> for prefix "dc".  Bind the prefix "dcterm" to the DC terms namespace
> in the RNG Schema and throughout the exposition of the specification. 
> 
>    * In the RNG Schema and in the specification, add the element 
> <meta:last-modifier> as a content choice of <office:meta>, defining 
> it to serve the purpose of the deprecated <dc:creator> element here.
> 
>    * For <office:annotation> and <office:change-info> introduce 
> <dcterm:contributor> as the replacement for the deprecated 
> <dc:creator> content element of those elements.  Although I still 
> have a sinking feeling about using DCMI elements here, if they are 
> usable, <dcterm:contributor> seems to be the closest match.
> 
>    * The note about special practices in the ODF community should be
> ditched entirely.
> 
> 3. BIGGER WORRIES
> *****************
> 
> Although the remedy in (2.3) may seem too drastic, I fear we have a 
> bigger problem.  There needs to be careful analysis of the DCMI 
> specifications and any related standards that have been promulgated 
> concerning the use of Dublin Core terms.  Here's what worries me:
> 
> 3.1 In the Dublin Core specifications, the terms "namespace" and 
> "element" ARE NOT USED IN THE TECHNICAL XML SENSE.  The use of 
> Namespace by DCMI is not in the sense of XML Namespace, and the use 
> of element and the term for the element is not in the sense of an 
> XML Namespace local name.
> 
> 3.2 Now, it is common to see strings like "dc:creator" and 
> "dcterm:contributor" in many places in XML documents, especially in 
> RDF annotations.  THAT USAGE HAS NOTHING TO DO WITH NAMES IN XML 
> NAMESPACES.  Those occurrences are as attribute *values* and in all 
> cases they are CURI-coded shorthand for URIs, not names of XML-
> namespace members.
> 
> 3.3 I thought that maybe the DCMI material simply didn't connect the
> dots to XML and left it to others, except there is the following 
> very clear statement that DCMI namespace is meant and it has 
> *nothing* to do with XML namespaces [1: section 1]:
> 
>      "This documentation is maintained by the DCMI Usage Board in 
>      accordance with the DCMI Namespace Policy [NAMESPACE]. The 
>      namespace policy says that DCMI terms are identified using 
>      Uniform Resource Identifiers (URIs). In accordance with the
>      principle that distinct URIs should be assigned to distinct 
>      resources, the policy sets limits on the range of editorial 
>      changes that may allowably be made to the official labels, 
>      definitions, and usage comments associated with DCMI terms. 
>      By policy, any changes of meaning judged 'likely to have a 
>      substantial impact on either machine processing of DCMI terms
>      or the functional semantics of the terms' must trigger the 
>      creation of a new, distinct term with a new, distinct URI."
> 
> 3.4 The DCMI Namespace Policy goes further to emphasize that this is
> a DCMI-specialized use of the term "namespace" [2: section 1]:
> 
>      All terms used in metadata descriptions that conform to the 
>      DCMI Abstract Model [DCAM] must be assigned a unique URI. 
>      For convenience, the term URIs that are assigned and managed
>      by the DCMI are grouped into collections known as DCMI 
>      namespaces. This document describes how term URIs are allocated
>      by DCMI and the policies associated with DCMI namespaces.
> 
> 3.5 So, apparently, there is no XML namespace defined by DMCI and 
> the use of the DMCI URIs as namespace identifiers apparently has no 
> standing as an use of Dublin Core elements.  Unless some other 
> standard has created such an use (and using those URIs as XML 
> namespace URIs), the use in ODF is a mistake.
> 
> 3.6 Although the remedy in (2.3) might seem severe, the absence of 
> any DMCI establishment of an XML namespace for a URI under their 
> authority suggests that we might need to do something quite 
> different and even more painful:
> 
>   * Deprecate all use of so-called Dublin Core XML Namespace URIs in
> the ODF specification (having no impact on use in RDF CURI values, 
> however, but those uses must be accompanied by an appropriate XML 
> namespace binding).
> 
>   * Introduce a new, OASIS authorized ODF namespace for ODF XML 
> elements whose interpretations are specializations of Dublin Core 
> metadata elements.
> 
>   * One might bind the new namespace to prefix "dc" as a way to 
> smooth things over.  Just to avoid confusion, the ODF RDF metadata 
> specification should use a different prefix for CURI use (dcterm 
> would work and is preferable for other reasons).
> 
> 3.7 If there is some standard out there that does establish 
> authoritative use of an XML namespace identified via the DMCI URI 
> (as opposed to merely for use in a CURI, an xmlns binding hack), 
> would someone please find it.
> 
> Unfortunately, this is *not* an April Fools Day joke. 
> 
> [1] DCMI Usage Board.  DCMI Metadata Terms.  DCMI Recommendation, 
> Dublin Core Metadata Initiative, 2008-01-14.  Available at <http://
> dublincore.org/documents/2008/01/14/dcmi-terms/>
> 
> [2] Andy Powell, Harry Wagner (eds.).  Namespace Policy for the 
> Dublin Core Metadata Initiative (DCMI).  DCMI Recommendation, Dublin
> Core Metadata Initiative, 2007-07-02.  Available at <http://
> dublincore.org/documents/2007/07/02/dcmi-namespace/>
> 
> 
> 
> 
>  - Dennis
> 
> Dennis E. Hamilton
> ------------------
> NuovoDoc: Design for Document System Interoperability 
> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]