Well, I seem to have mangled badly the wishes of two, maybe three of the
working groups.... (at least I got your attention, eh?)
John Kunze has set me straight on a couple of date issues... especially
my mangling of DC.Date.Valid... Uncle, already.
David Bearman and Simon Cox have weighed in strongly for exactly two
relation elements (Relation.Type and Relation.Identifier). I'm happy
with this part of the solution (please, don't ask the obvious
question... I';m embarrassed enough).
I still have a very strong concern, however... that is, what is the list
of relation tyupes we want to recommend... My own feeling is that those
generated by the working group are overly difficult to explain and,
though very reasonable for certain varieties of metadata, are probably
NOT DC-Simple attribute values? Please guide me
Another DC-simple issue... are we to recommend SOURCE is simply an
identifier for DC-SIMPLE, or adopt the Source.AnyOtherElement approach
as Simon (rightly, I believe) reminds us should be valid.
On Coverage, I await Mary's reasoned voice... and others.
Please keep in mind here there are two branches here... DC-Simple and
Qualified DC... please make clear which side of my head is to recieve
the brickbats.
stu
-----Original Message-----
From: Simon Cox [SMTP:[log in to unmask]]
Sent: Tuesday, January 27, 1998 8:23 PM
To: Weibel,Stu
Cc: [log in to unmask];
[log in to unmask]; David Bearman
Subject: Subelements: RELATION
Weibel,Stu wrote:
> ...
> 4.3.13 RELATION
>
> The RELATION element logically requires three components: two
entities
> and a named relationship that links them. The base entity is
the
> resource described by the metadata. The target entity is
separate
> object that should be identified in an unambiguous way with a
> globally
> unique identifier (see the IDENTIFIER element).
Wow!!! - to me this looks like a considerable development from
what had emerged from the WG. Two main things jump out:
1. we only found TWO components for Relation -
Relationship type
(12 enumerated cases, representing two-way
versions of only 6 distinct classes of
relationship)
Identifier for related resource
(your "target entity" above - and adding the
cross-reference to IDENTIFIER in the sentence
describing the "target entity" is highly
confusing
- see my next comment)
2. your "base entity" is sematically identical to the basic
DC:Identifier (ie the identifier for the present resource).
Would I be right in interpreting the insertion of this as
a _required_ component of Relation is implicitly a way of
getting around the "optional" possibility for DC:Identifier?
If this is really what is going on then that is a poor
excuse for such a big change.
>
> ... Unqualified relation specifications should chose from
> among the following relation types for DC-Simple applications:
>
>
> Relation.IsPartOf [TARGET RESOURCE IDENTIFIER]
> Relation.HasPart [TARGET RESOURCE IDENTIFIER]
> Relation.IsVersionOf [TARGET RESOURCE IDENTIFIER]
> Relation.HasVersion [TARGET RESOURCE IDENTIFIER]
3. Why is this list so much reduced from the
12 classes of relationship type that was identified
by the Relation WG?
4. (See also above) I really don't understand
the keywords [TARGET RESOURCE IDENTIFIER] in this
context - what are each of these supposed to hold?
This all looks very different to what I had
interpreted as the outcome of the Relation WG.
Although we did not do syntax, using the
dot notation I would suggest that a better
representation would have just two sub-elements
[Type, Identifier] used as in the following example:
for the resource where
DC:Identifier = "paper.html"
a relationship would be asserted using
DC:Relation.Type = "isFormatOf" (... from the enumerated list)
DC:Relation.Identifier = "paper.doc".
Bundling in the unqualified form of DC would thus result in:
DC:Identifier = "paper.html"
DC:Relation = "isFormatOf, paper.doc"
which still makes sense!
--
__________________________________________________
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/
|