Mind you, there is a little bit of guidance given by Dublin Core, in their
"Usage Guide" (http://dublincore.org/documents/usageguide/)
Quoting from that guide:
"Creators should be listed separately, preferably in the same order that
they appear in the publication. Personal names should be listed surname or
family name first, followed by forename or given name. When in doubt, give
the name as it appears, and do not invert.
In the case of organizations where there is clearly a hierarchy present,
list the parts of the hierarchy from largest to smallest, separated by
full stops and a space. If it is not clear whether there is a hierarchy
present, or unclear which is the larger or smaller portion of the body,
give the name as it appears in the item.
If the Creator and Publisher are the same, do not repeat the name in the
Publisher area. If the nature of the responsibility is ambiguous, the
recommended practice is to use Publisher for organizations, and Creator
for individuals. In cases of lesser or ambiguous responsibility, other
than creation, use Contributor."
But for 99% of the documents out there, the application is just going to
slap in whatever user name the application has convenient, most likely the
name of the logged in user, or even the name of the user who installed the
application or the operating systems. Most users don't know that this
field is filled in for them automatically, and they never see it or change
it.
So the most we can really ask for is to have some sensible way of encoding
this metadata for the few who know enough and care enough to override the
application defaults.
-Rob
"Dennis E. Hamilton" <>
07/02/2008 02:40 PM
Please respond to
<>
To
<>
cc
"'Dave Pawson'" <>
Subject
RE: [office-comment] 1.2 para 3.1.7
I have been thinking of this, along with Alex Brown's comment and what I
trust was a humorous comment about GUIDs.
It strikes me that the way to offer a specific grounding of a Dublin Core
element would be by some sort of "subclassing" of that element. (The
semantics have to be preserved, the syntax and the pragmatics can be more
specific and constrained.)
Now, I am not sure how one enacts such an arrangement (and I'd be shocked
to learn that any schema system could formalize it). I wonder whether the
ODF 1.2 support for RDF is of any help in this regard. Hmm ...
- Dennis
PS: Patrick, Dublin Core has already defined, last time I checked,
subcases of <creator> (or <creator> is a subcase, I forget) for variants
on authorship, editing, approval, etc. I agree that if one is going to
use someone else's namespace, their definitions and only their definitions
are what matters.
Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability
mailto: | gsm:+1-206.779.9430
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org
-----Original Message-----
http://lists.oasis-open.org/archives/office-comment/200807/msg00020.html
From: Dave Pawson [mailto:]
Sent: Wednesday, July 02, 2008 08:48
To:
Subject: Re: [office-comment] 1.2 para 3.1.7
2008/7/2 Patrick Durusau <>:
http://lists.oasis-open.org/archives/office-comment/200807/msg00019.html
[ ... ]
>> If the semantics are different from dublin core please use a different
>> element name.
>> There is no point in diluting DC semantics.
> Is this a principle you would suggest being applied to all the "foreign"
> elements/attributes in ODF 1.2?
[ ... ].
I'm recommending that if you use dublin core,
use dublin core semantics, as they describe.
> The reason I ask is that if you review the comments I have made on the
> latest draft for the attributes, you will find that we depart from
standards
> where we use their attributes more than now and again.
I believe that should be deprecated.
> My personal preference is for use/citation without modification but we
are
> hardly writing on a clean slate with ODF 1.2 and so there may be
> modifications that we simply acknowledge as going to persist over time
or
> that we plan to change in some future release.
I believe this to be wrong.
Previous bad practice is no reason to continue it.
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
--
This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe:
Unsubscribe:
List help:
List archive: http://lists.oasis-open.org/archives/office-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
--
This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe:
Unsubscribe:
List help:
List archive: http://lists.oasis-open.org/archives/office-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
