This is a follow-up to the issues list from my mail of 1998-07-23
(quoted below).
Latest version of DC.Type position paper is now at
http://www.agcrc.csiro.au/projects/3018CO/metadata/dc_tf/type_3.html
-----------
There have been no additional substantial issues raised.
1. Off-line and Surrogates
Additional discussion including examination of some examples
has shown that the 1:1 principal can be used consistently,
although there are some fine distinctions to be made at times.
A recent CIMI meeting raised some related issues.
However, no proposals to change the position paper for
DC.Type have emerged to date.
2. Data -> Dataset
I have changed this in the latest draft.
3. Image
There have been no comments supporting a change of this token to graphic, so I have reverted to "image" in the latest draft.
4. Video + Film
It appears to be accepted that these are a subdivision of
"image" rather than a type in their own right.
5. Reference to Previous work
Discussion are continuing.
-------------
Here is the 1998-07-23 message regarding DC.Type issues:
>
> One week has elapsed since the position paper on DC.Type
> from the Type & Format working group was posted.
>
> I have detected the following issues raised:
>
> ------------------------
>
> 1. Off-line and Surrogates
>
> The 1:1 principle is still not fully understood,
> in particular in regard to _off-line_ resources.
> We need to develop more examples illustrating the use of
> DC metadata for both physical objects _and_ digital surrogates of these.
>
> ------------------------
>
> 2. Data
>
> There is a concern that "data" is not sufficiently distinctive.
> The definition could be improved by adding the adjective
> _structured_ in order to differentiate it from
> _unstructured_ things that are "text".
>
> Perhaps change the token to "dataset".
>
> ------------------------
>
> 3. Image and other symbolic notations
>
> Questions about where _maps_ and _musical_notation_ fit
> exposed the need to improve the definition and examples for "image".
> Perhaps use "symbolic visual representation".
> This type should also not be restricted to 2D.
>
> Perhaps change the token to "graphic".
>
> ------------------------
>
> 4. Video
>
> Is video OK as "image/graphic" ...?
>
> What is video?
> i. format rather than type information ...?
> ii. "moving pictures" - in which case type "image/graphic" is fine
> iii. "moving pictures with sound" - this is the compound/mixed issue:
> use an additional DC.Type="sound" if the sound is a major aspect.
> (NB. lots of video (particularly on the web) is silent.)
>
> Lots of the classifications are not strictly orthogonal anyway.
> The parsimony principle argues against adding types willy-nilly.
>
> ---------------------
>
> I've posted a new version of the DC.Type position paper
> revised by me to incorporate some of these changes at
>
> http://www.agcrc.csiro.au/projects/3018CO/metadata/dc_tf/type_2.html
>
> ---------------------
>
> 5. Previous work
>
> Meanwhile, Erik Jul has observed that the list of Types is not
> properly grounded in an analysis of previous related work
> in this area. This has two implications:
> (i) the taxonomy may not be fully robust
> (ii) there is a risk of a credibility gap wrt some of our target communities
>
> Rebecca and I have fessed up and thought about this a little.
> Here's my attempt at a summary of the points raised:
>
> - "Type" is not alone in DC in proposing semantics without
> explicitly indicating antecedents
> - the DC community has frequently appeared to reinvent such a wheel,
> but this is not necessarily totally wierd since a cross
> community "lingua franca" needs to encompass more general
> concepts than those of any specific community
> - this DC simple list is unusual in that it does attempt to cover
> such a wide range with such a small number of terms;
> besides, it has stood up to most empirical tests over a number of months now
> - some specific comparisons have been attempted (MARC)
> but was found to be rather difficult since there was a
> correspondence with multiple MARC fields,
> frequently dealing with different levels of granularity
> - the problem will almost certainly be less stark for more
> refined DC with external vocabularies used explicitly through "schemes"
>
> Meanwhile:
>
> Erik:
> > there must be a handful of reference
> > sources, dictionaries, standards whose entries we we examine, compile,
> > and compare. MARC is one. There are others. First step would be to
> > compile a list of potential resources. Sounds like a good reference
> > question for a librarian somewhere.
>
> Rebecca:
> > With that said, it is probably worth the effort. The
> > problem of course is, who has time? Not a good excuse, I know. Maybe we
> > need a game plan and each of us take various groups to see what they've
> > done.
>
> I think (hope) Rebecca and Erik are working on it ...
--
__________________________________________________
Dr Simon Cox - Australian Geodynamics Cooperative Research Centre
CSIRO Exploration & Mining, PO Box 437, Nedlands, WA 6009 Australia
T: +61 8 9389 8421 F: +61 8 9389 1906 [log in to unmask]
http://www.ned.dem.csiro.au/SimonCox/
|