Aaron,
On Thu, 22 Feb 2001, Aaron Swartz wrote:
> You seem to be confusing the argument. There are two issues involved here:
>
> 1) Specializing Dublin Core
> The DC-15 pick out some very basic terms about resources, however, these
> terms can be specified quite deeply. We should not prevent people from
> specializing these terms as long as what they do is a true specialization
> (that is that all answers for the specialization are valid answers for the
> unspecialized form -- I believe this is called the dumb-down rule). Allowing
> this specialization to be built on top of DC is a win for everyone.
Yes. As you say, that is idea behind the dumb-down principle.
> 2) Having Dublin Core Point to Resources
> Most current uses of Dublin Core have used the elements resolve in text
> strings. However, it is also important that we allow them to resolve to
> other first-class resources (what has been called an "INTNODE") which have
> their own properties (which may be Dublin Core elements). It is also useful
> to allow this method to be converted to a simple text string, and the Dublin
> Core should provide a method for doing so.
There is no inherent limit to the HASA attributes one can associate
with an entity seen as a first-class resource. As you say, and those
attributes could include Dublin Core elements -- but those attributes
could just as easily be medical (BMI: 27), biological (Species:
Afarensis), legal (Status: Widow), or biographic (Hobby:
Basket-weaving).
Saying "The default value construct allows one to associate an
arbitrary graph of such attributes with a Dublin Core element in the
encoded metadata of an application" is different from saying that the
elements of that arbitrary graph are attributes of the Dublin Core
element itself.
If we were to see these arbitrary concept spaces as definitive of the
Dublin Core element itself, we would have to re-define Creator (for
example) as "any set of biological, legal, medical, biographic, or
metaphysical attributes associated with the entity primarily
responsible for making the content of the resource".
The current focus of Dublin Core on "appropriate literals" is already
far from trivial. As librarians like to remind us, for example, there
are entire sections of AACR2 devoted to defining conventions for
forming proper names consistently as strings (e.g., between Thai,
Spanish, and Ukrainian).
Standardization of entire attribute sets is a whole new dimension and
an exponentially more intractable problem. Not that it is not useful
to seek harmonization within legal, medical, etc communities on
attribute sets for entities -- but this takes us far away from the idea
and method of simple metadata for resource discovery.
> It is also useful
> to allow this method to be converted to a simple text string, and the Dublin
> Core should provide a method for doing so.
I think we need to be careful of wording here:
1) What needs to be "converted" to a simple text string? Not the
"method" -- I assume to mean "the INTNODE". And I assume you are
not suggesting we develop complex algorithms to take arbitrary sets
of attributes as input and produce "appropriate literal" text
strings as output. Rather, I take you to mean that one would need
to require that the INTNODE of a DC element contain a default value
that already holds an appropriate literal. If so, then yes.
2) "The Dublin Core" (element set) would not itself do the providing,
of course, but DCMI -- or perhaps even W3C.
Tom
_______________________________________________________________________________
Dr. Thomas Baker [log in to unmask]
GMD Library
Schloss Birlinghoven +49-2241-14-2352
53754 Sankt Augustin, Germany fax +49-2241-14-2619
|