Thanks Tom, -- and Karen and Pete
I don't see this as a big issue, but to try to explain my comment about
language a bit further. It makes sense to me why dc made the decision
to assign a non-literal range to dcterms:language. And I can see why
dcterms:created is assigned a literal range.
But I was putting myself in the shoes of someone new to DC and DCAM who
is looking at that table in section 5 and has just read through the
decision process for selecting terms, where it's been decided that we're
going to select from a controlled list of codes. I think they might be
confused by the way dcterms:language and dcterms:created are summarised
in the table. Ie, both dcterms:created and dcterms:language have
value string=YES
SES URI=YES
But one has a literal value and the other doesn't.
And if I'm new to DC, I could be thinking at this stage, well, why did
dc make one a literal and not the other? I see the answer is what you
just said and it's explained well in the Appendix under RDF Property
Semantics, but as someone else said, maybe they won't get that far.
So would this be a correct way to put it?
'dcterms:language has a non-literal range to accommodate the choice of
URI or value string. In this profile we want to represent it as a value
string, specifically the three-letter codes listed in the international
standard ISO 639-3 for the representation of names of languages (such as
"eng" for "English") together with the syntax encoding scheme
dcterms:ISO639-3 as a datatype.'
__
Re DCAM ... and Karen's wishing it dead. ;-) I think some sort of common
model is essential for interoperability between metadata standards and
DCAM is general enough and flexible enough to do that. I've found it
hard going and at first couldn't see why it was needed. But I can now
really see the value in it and I definitely think it's worth persisting
in your efforts to explain and reach out with documents like this.
Irvin
Irvin Flack
Metadata Librarian
Centre for Learning Innovation
NSW Department of Education and Training
-----Original Message-----
From: Thomas Baker [mailto:[log in to unmask]]
Sent: Saturday, 29 November 2008 12:32 AM
To: Flack, Irvin
Cc: [log in to unmask]
Subject: Re: [Public Comment] DCAP Guidelines
On Fri, Nov 28, 2008 at 12:41:57PM +1100, Flack, Irvin wrote:
> One specific comment: in the context of the MyBookCase example, it's
not
> clear why the dcterms:language property should take a non-literal
value,
> given that a literal value would seem to do the job adequately in this
> context. I know this is covered by the later note "When using an
> existing property, the choice between a literal and non-literal range
> will usually be mandated by the official definition" but I don't think
> it's clear why dc originally decided a non-literal is required for
that
> property.
Thank you very much for the comment!
While it is true that one might typically identify a language
using a three-letter code from ISO 639-3 or tag from RFC
4646 -- a string with a datatype (Syntax Encoding Scheme) --
giving dcterms:language a "literal" range would have _limited_
the property to be used with a value string.
With a non-literal range, dcterms:language can be used not just
with a value string, but also (or alternatively) with a URI
identifying the language. choice, Defining dcterms:language
with a non-literal range makes the property more flexible to
use because it accommodates this choice.
Tom
--
Dr. Thomas Baker <[log in to unmask]>
Director, Specifications and Documentation
Dublin Core Metadata Initiative
**********************************************************************
This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**********************************************************************
|