On Mon, 23 Mar 1998, Weibel,Stu wrote:
...
> OK... that's the easy part.
>
> Siggy... You propose, I believe, a basis for a compromise between the
> two position. Can you write up a synopsis highlighting them and put it
> out for discussion? ( I'm sorry to ask you to re-say what's been said,
> but articulating the two positions side by side in a concise fashion may
> help.).
In Summary:
-----------
The current Relations proposal is causing problems for implementors
and require an awkward syntax which requires extensive modification of
some existing software when used for metadata in a compact form.
The Relation report is the only one favouring an extended form of
metadata in a set of documents which all describe Core subelements in
a compact form.
I propose that the relations working party reverts to its original
report.
However, I also propose that the data modelling group should adopt
this dichotomy between metadata in extended and in compact form and
propose a semantics for metadata in extended form. This should be done
for all 15 elements, in a uniform way.
The Whole Story:
----------------
19 December last year, the Relation work party released their report
to this list. Read it on
<URL:http://www.roads.lut.ac.uk/lists/meta2/1997/12/0046.html>. The
proposal lists subelements the same way as the other subelement
groups, and follow the tradition since Canberra.
A few days later Simon Cox argued that the
".. simplest versions of the Dublin Core Relation element will
normally require two attributes:
1. the relation type - as summarised by David;
2. identification of the related resource.
This has syntax implications. (The _simplest_ version might
only have the identifier and dispense with the type ...)"
(<URL:http://www.roads.lut.ac.uk/lists/meta2/1997/12/0047.html>
David obviously liked the idea and this was put into the current
version report (cf: <URL:
http://purl.oclc.org/metadata/dublin_core/wrelationdraft.html>).
Why does this break with tradition and applications? To specify a
relation we now have to specify three things type, identification and
scheme. And hence we have taken a step away from the RFC 1 formulation
"An identifier of a second resource and its relationship to the
present resource. This element permits links between related
resources and resource descriptions to be indicated."
Hence, the Relation element should contain an identifier, and there
should be no need for a subelement with that name. The proposed
makes assumptions about an extended form of metadata.
As I pointed out earlier, there was opposition. And some confusion:
For instance Lars Eilebrecht asked how he should use the relation
element in his WWW pages.
we are using the DC element set for a project at our
university and I need to write some examples on how they are
used in HTML documents for our users...
But how do I add the information about the type
(i.e. IsBasedOn) of a DC.Relation element to a meta tag?
This isn't correct, isn't it?
<META NAME="DC.Relation"
SCHEME="URL"
CONTENT="IsBasedOn http://www.foo.bar/">
No answer appeared on the list from anyone responsible whithin the
relation work party, in spite of the fact that the question was a
brand new one.
Before DC4 in Canberra we would have written
<META NAME="DC.Relation"
CONTENT="(SCHEME=URL)(TYPE=IsBasedOn)http://www.foo.bar/">
But we all agreed that this was a less than excellent encoding.
>
> As for what the RFC says, if there is a problem that can be resolved by
> working out these positions, we can fix it. I am reluctant to continue
> niggling about these things, but better to eat crow while its young and
> tender.
>
I propose the following: The relations working party should revert to
their original report. However I also suggest that the data modelling
group should adopt this dichotomy between metadata in extended and in
compact form and propose a semantics for metadata in extended form.
The Relation report is not the only with problems. For very similar
reasons I would like to see some concertion between the date group and
the coverage group, such that we'll get a uniform semantics for
ranges. Someone pointed this out in Helsinki, but it hasen't happened
yet. FYI, the coverage people have discussed ranges at least since
Canberra, but the current Date proposal is simpler.
> Let me point out that interest in standardization of the Dublin Core is
> growing (and growing more important), and that provides us with an
> additional milestone towards which we might work.
Yours
Siggy
|