Forwarded belatedly on behalf of Shigeo Sugimoto, who in the middle of mail
account changeover.
------- Forwarded Message
Stu and Andy,
On Mon, 8 Sep 2003 14:36:06 -0400, [log in to unmask] wrote:
>> As for the thread... I am wondering where, if anywhere, a dumb-down rule
>> should be articulated in the abstract model.
Dumb-down is a key concept to understand the Dublin Core. Although
in the Andy's document it is described in the section of "Simple Dublin
Core Model", I think it would be reasonable to describe it in a separate
section.
>> Is there a coherent way to express the notion that, if an application
>> encounters a non-DCMI term, then the value of that term is to be (a)
>> interpreted as a dumbed-down (un-qualified) term, or (b) ignored, or
>> (c)...something else?
>>
>> Or is this simply better left to another document on mixing namespaces?
In my understanding, mixing namespace is a key concept of DC which
is originated from the Warwick Framework. In this sense,
the issue should be a part of the basic abstract model of DC.
On the other hand, from this viewpoint of what-should-be-documented,
I re-read the document and some questions came up in my mind;
1. Who are target readers?
2. What is the difference of "Simple DC" and "Simple DC Model"?
3. Why "application profile" is not included in the document?
1. Who are target readers?
I think if the target is data-model people who has computer science
backgrounds more formal flavor would be required.
If the target is more general audience this style looks fine with me.
Since I read the document from a CS-based viewpoint, I tend to feel
that clearer separation of semantic and structural (or syntactic)
features is required.
2. What is the difference of "Simple DC" and "Simple DC Model"?
"Simple DC" is an ISO standard. On the other hand, "Qualified DC" is
rather fuzzy term because the set of DC terms is an open-set and
also because usually each application has its own structural
constraints, e.g. "mandatory", "optional" and "repeatable".
If "Simple DC Model" is intended to explain a metadata model without
qualifiers, I prefer to use "Unqualified DC Model". And, "Unqualified
DC" covers 16 elements.
(In my understanding, the CORES project led by Rachel, Tom and others
are using "Unqualified DC" in their registry.)
3. Why "application profile" is not included in the document?
At DC conferences, we find many profiles for specific applications.
From this point, I think "application profile" is a key concept to
use DC in real applications. Also, "application profile" is
used to metadata terms difined in different metadata schemas.
On the other hand, I understand that "application profile" is still
a fuzzy term. In my understanding, an application profile could include,
(1) a set of metadata terms (i.e., elements and qualifiers) used in
the application,
(2) structural constraints applied on the metadata terms, e.g. optional,
repeatable, mandatory, and
(3) guidelines to write/encode element values.
I think (1) and (2) could be a part of the abstract model for DC.
(From this viewpoint, "Simple DC" can be exlained as a profile defined
based on the DC element set...)
I hope I'm not misunderstand or missing the point of discussion.
Thank you,
-- Shigeo
------- End of Forwarded Message
|