Jane,
this update was previously posted to the list, but just in case you didn't
see it:
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/
Debbie Campbell
Metadata Coordinator
National Initiatives And Collaboration Branch
ph. 02 6262 1673
fx. 02 6273 1180
e-mail [log in to unmask]
http://purl.nla.gov.au/metaweb/home
> ----------
> From: Jane Rundquist[SMTP:[log in to unmask]]
> Sent: Monday, 31 August 1998 7:29 AM
> To: [log in to unmask]
> Subject: DC Element "Type"
>
> Hi,
>
> I am interested in the status of the enumerated list approach for the DC
> element "Type". The "Syntax" paper on it says that " For the sake
> of interoperability, Type should be selected from an enumerated
> list that is currently under development in the workshop series" This
> page
> used to also say "See http://sunsite.berkeley.edu/Metadata/types.html for
> current thinking on the application of this element" which is how I got to
> this page.
>
> I checked the "Workshop" section at
> http://purl.oclc.org/metadata/dublin_core/ and it doesn't list any
> workshops going on or give any links to the enumerated list. Is this a
> "Catch 22?"
>
> Any information would be greatly appreciated. I am doing work with
> various
> govt agencies to try and bring currently accepted DC metadata standards to
> their online documents.
>
> Thank-you.
>
>
>
>
>
>
|