I'll have a go at this ...
(it's friday - shouldn't I be drinking by now?)
Titia van der Werf wrote:
>
> ... I'm researching the possibilities of using the Relation
> element to define parent/child relationships between resources.
> I have a couple of questions I hope you will be able to answer:
>
> 1) What is the status of the following document: "Dublin Core Qualifiers"
> <http://www.roads.lut.ac.uk/Metadata/DC-Qualifiers.html> by John Knight
> and Martin Hamilton of the ROADS project, compared to the draft report of
> the Helsinki Relations Working Group? I think the type qualifiers for
> relation, proposed in the first document, e.g. IsParentOf, IsChildOf and
> IsMemberOf may be useful for our purposes. What is the view of the
> Helsinki working group on this proposal?
The Helsinki report is more current and is the closest that
we have to a reference document at this stage. The precise
procedures for ratifying the recommendations of working groups
as official recommendations for Dublin Core are still being
finalised. However, I recommend that you try to work with
the Helsinki list rather than the ROADS list.
I think that you will find that IsParentOf, IsChildOf and IsMemberOf
are probably generalisations of the cases recommended by the
Helsinki group, and that Helsinki terms can be used for
specific instances. If you have a need for the more generalised
relations, in some kind of knowledge-representation web, for
example, then I think that you will just need to make up
some equivalence rules. eg.
IsVersionOf, IsFormatOf, IsBasedOn are all "IsChildOf"
HasVersion, HasFormat, IsBasisFor are all "IsParentOf"
IsPartOf is similar to "IsMemberOf" etc etc
> 2) Is "sub-element" the same as "qualifier"? If not, what is the
> difference?
"qualifiers" includes:
* sub-elements (ie refining an element value by breaking it into parts
which need to be "summed" in some way to get the whole element)
* typed elements (ie refining an element definition by indicating
which version or "flavour" of that element is being used -
normally complete in itself and in a sense orthogonal to other
types of the same element)
* an indication of a particular restricted vocabulary or "scheme"
(and language), with associated definitions or semantics, used in
a particular expression of an element value. Dublin Core will
provide schemes for some elements (eg. DC.Type), but in general
externally defined schemes will be used.
> 3) What are the current ideas of DC developers about the granularity
> issue? For which "information entities" can/should metadata be created?
> What is a "logical document"? How do you define relations between files
> that together build one logical whole? Could you recommend
> any documentation which addresses these issues (from the DC community or
> outside it)?
DC is fundamentally for "simple resource discovery".
The answer to your question requires you to combine
that notion with some model of your clients ...
> 4) When you use HasPart / IsPartOf, this might mean that you get really
> long complicated lists of cross references. One piece of information
> might be used in several documents. One "parent" may have a lot of
> "children", and may itself be a "child" within the next hierarchical
> level. Is it feasable, in your opinion, to use this relation.type to
> reflect all those complicate hierarchical structures?
Perhaps not. DC is for resource discovery. It might
also be useful for knowledge representation and modelling,
but it is likely to be deficient for complex requirements
in this area.
--
__________________________________________________
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/
|