This is a long mail. Therefore I give a brief summary up here:
Simon gives good background information including elucidating glimpses
from the datamodel work party. As regards his defence for the
Identifier as belonging to the substructure of Relation, I still
maintain my criticism, though.
Simon acknowledges that
"the word 'identifier' is not really a new sub-element, it is
more or less what was earlier meant by 'value' ..."
The agreed function of sub-elements are to provide a method for
step-wise refinement of an elements semantics. Hitherto we have been
used to making only one refinement per step. Here we are forced to
make two. On the other hand 'Identifier' doesn't really refine. Simon
fails to explain why it is there. To me it seems as very premature
attempt to get things in line with what is going on in the data
modelling group.
So this is what I think having read Simons views:
1. Since David ensures us that the original report is semantically
equivalent with the current (period), and Simon that function of the
indentifier is not a sub element, Therefore I maintain that it be
removed from the Relation WG report.
2. However, I do agree with Misha that we should really reconsider
the use of DC.this.and.that in documents describing semantics of
sub-elements. The dot notation helps doing things in HTML, SOIF and
other simple line-based encodings, but it doesn't help us understand.
Actually, I think this should start with RFC3.
Here comes the details:
On Fri, 27 Mar 1998, Simon Cox wrote:
> Ralf Schimmer wrote:
> >
> > Listening to Misha's strong disapproval, I think it is about time to
> > jump in and articulate some equally strong support for what Sigfrid
> > has very vigorously put forward over the past few days.
>
> I guess I'll add a few comments in support of David and Misha
> (and myself?).
>
Please do!
>
> I think that the problem here is largely about separating
> syntax from semantics. Work in the dc-datamodel working
> group has been particularly useful in refining this,
> primarily by using apparently syntax-neutral arc-node
> diagrams for most recent discussions. The difficulty
> of maintaining the separation has nevertheless not been
> absent from the discussions there.
I'll _tentatively_ accept the assertion that arc-node diagrams are
syntax-neutral.
>
>
> Taking the RELATION problem first, as the location of the
> current discussion and thus providing a convenient canonical
> example.
>
> I would summarize the _intention_ of the report
> (http://purl.oclc.org/metadata/dublin_core/wrelationdraft.html)
> as follows:
>
> "DC:RELATION will normally have two items of information,
> a relationship type and an identifier for the related resource,
> and it will usually be possible to selected a value for
> the relationship type from the recommended list."
I note the colon between DC and RELATION, which I do not regard as
syntax neutral ;-)
>
> This is only semantics and deliberately avoids syntax.
>
> Yes - there was a change from the earliest draft of the
> report to the final version. The report _initially_ used
> a version of the dot.syntax to express the idea, but syntax
> was later removed from the report in order not to prejudice
> synchronisation with ideas from ongoing work in the datamodel wg.
I'm unhappy with that, because it confuses things. Please remember
that there are at least _two_ processes underway. First the finalizing
of the core set of qualifiers and subelements.
That does not mean that data model wg should not look forward and
addressing novel problems and resolve old ones.
> I do not think it was intended to suggest that the dot-syntax
> which appeared initially (and persists in the draft RFC3
> http://www.roads.lut.ac.uk/lists/meta2/1998/02/0002.html )
> was _necessarily_ wrong at this stage, it was just that the
> dot.syntax is partly implementation dependent, being particularly
> suited to HTML, and the WG was really looking at semantics.
>
> Also please note that the word "identifier" is not really a
> new sub-element, it is more or less what was earlier meant
> by "value", but in the context of "extended" DC, at least as
> discussed in the datamodel wg, the word "value" more
> generally to mean the information on any RHS of metadata
> assignments, in the sense of
This a point where we disagree completely. My interpretation of what
the Canberra qualifier concept is that we have a tree structure where
each nod may comprise 4-tuples of (type,scheme,lang,value), where
'value' is only implied and may be a pointer to another node. This is
basically the way things are implemented in the Z39.50 tagsets-G and
M, or how we are trying to implement it here in Lund.
>
> attribute = value
>
> so it is more convenient to use specific names in discussion,
> eg in the current context, ie
>
> "type" = value
> "identifier" = value .
>
Bearing in mind what the point I tried to make above, you might now
understand why I think you have done something dirtier than just
introducing a new sub-element: You've even extended the set of
Canberran qualifiers. I'm not claiming that my view of the qualifiers
is the only one, but that it is a reasonable one and that other very
important players have understood it similarly. Therefore I think that
we must be very careful before starting adding things like that
identifier thingy (be it a qualifier, sub-element or whatever).
Hitherto the attributes used this way has been type, scheme and lang.
>
> Instantiations of DC in currently supported HTML are sometimes
> not capable of expressing the full richness of the DC datamodel.
> The absence of a explicit grouping mechanism is particularly
> problematic. DC RELATION is deceptive - only having two
> recommended sub-elements it is possible to hide these
Please, you claimed above that 'identifier' wasn't really a new
sub-element. The Relations report does claim so. You have to make up
your mind!
As I see it there are two properties of DC-syntaxes that we need to
take into account. Grouping is one of them, nesting is another.
Any extended form must support both.
> within one <meta > element by appending one of the values
> to the attribute name and putting the other in the atribute
> value - as in the early draft and illustrated by Sigfrid.
> But when you have elements which need more than two sub-elements,
> this trick is not possible.
We've seen ample evidence for this the last few days. There are cases
where this is less obvious. Today we see notation like 'x-subelement'.
This is clearly a dirty trick for doing things like
Relation:
type: IsBasedOn
scheme: my buggy addition
value:
type:x-buggy
scheme: URL
value: http://foo.bar.com
Here we qualify a structured sub-element with a scheme, because that
sub-element need some kind of authority control.
>
> This is not to say that we should make such tricks to shoe-horn
> extended DC in HTML illegal, but we probably need to be careful
> when doing this.
I surely agree
>
> In particular it is possible to write rules about how to
> express extended DC, as described in the DC datamodel,
> in a dot.syntax notation:
> * element and sub-element names represent labels on the arcs
> in the arc-node graph,
> * values represent the contents of leaf-nodes,
So why on earth invent a special container for the value for the case
of Relation.
> * dots represent empty nodes.
To me the dots represents arcs:
Creator --Now I'm going to tell you about-->PersonalName
> Then if we find ourselves using the dot.syntax in a way
> that is clearly different to this, we must look at it very
> closely to decide if the gains outweigh the losses.
To me it is important that the core set of subelements should be
expressable in dot notation. They are the ones which are well known and for
which there are no need for a scheme for a sub element.
>
> How to compress the information from extended DC to
> basic DC is another question which I think it is possible
> to write similar simple rules for.
Provided that we have a small well defined set of attributes or "left
hand sides". That set of left-hand-sides should be used the same way
for all 15 elements We agreed on such a set in Canberra.
> This is the true location of the current dispute/discussion:
> to re-iterate, the datamodel imputes a strict meaning to
> dot.syntax expressions of extended DC, whereas constructions
> such as Relation.IsBasedOn appear to be using the dot.syntax
> in a distinctly different way.
Could you develop that.
The only thing that makes it impossible to say Relation.IsBasedON is
the inclusion of that identifier 'thingy', which wasn't really a
sub-element anyway. Given that, you have to explain to me the
difference between
<meta name="DC.Relation"
content="IsBasedOn http://foo.bar.com">
<meta name="DC.Relation.IsBasedOn"
content="http://foo.bar.com">
The former requires some extra elseifs in my code, and makes the ugly
html-kludge if possibly even uglier.
> We need to resolve whether we will insist on the
> strict interpretation of the dot.syntax for DC in HTML -
> or whether we also sanction other usages, which in some
> cases are already widely deployed.
>
> In this regard the current RFC's and draft RFC's are
> suffering a synchronisation problem. In particular,
> RFC3 does not take much account of the datamodel
In my view the RFC3 should _not_ take into acount the datamodel. The
glimpse of the datamodel work we see in the Relation report is an
"ugly duckling". We all hope that it will grow up to swan. We have to
make swans of all the ducklings eventually.
We should really reconsider the use of DC.this.and.that in documents
describing semantics of sub-elements, though. The dot notation helps
doing things in HTML, SOIF and other simple line-based encodings, but
it doesn't help us understand. I think we should start with RFC-3.
> work, and the use of the dot.syntax largely
> pre-dates the strict interpretation or rules for
> constructing extended dot.elements which I have
> sketched above.
>
>
> There is also clearly a process issue here:
> Sigfrid appears to be concerned that "decisions" made
> in plenary session appear to have been overturned by
> "recommendations" emanating from a later working group.
> Fair point, I guess, but I will defend the recommendations
> as being more consistent with other subsequent discoveries.
I'm concerned by this, when it is combined complete unwillingness to
discuss things with other people than those involved in the group. I
had to start a flame war before you were willing to even listen. And I
still maintain that the more resent discoveries have prematurely
merged into relations report.
>
> Discussions about RELATION were rarely far from the surface
> at Helsinki, as a corollary of the growing acceptance of
> the importance of the 1:1 principle. Formally this led to
> one of the three break-out groups being specifically on
> RELATION, with a report on their deliberations presented
> in plenary. It was agreed in plenary that RELATION work
> would continue on a list.
>
> One of the first things that came up in discussion was
> that the definition of the RELATION element that had
> been used up to that time - ie an ID for the related resource
> - needs supplementation with information specifying the
> nature of the relationship in order to make it properly useful.
> Thus, any RELATION actually needs two pieces of information,
> an ID and a relationship indicator. In the subsequent work
> on the list, a recommended set of relationship indicators
> was developed (12 in all, representing two directions of six
> relationships). This is the point at which the RELATION wg
> ceased its deliberation and presented its report.
The list of relations should satisfy most needs and builds upon a good
and stringent analysis. As far as I'm concerned it has never been
under dispute.
>
>
> I hope this all clarifies rather than confuses.
You have elucidating things, but I'm not satisfied, though. The
status of the not-reeally-a-sub-element is _very_ fuzzy
Identifier. Therefore it would be a good idea to remove 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/
>
|
