The two forms in which the draft working group report was first aired and
the final report was subsequently released are semanitically exactly the
same. The form in which the two are expressed is different, frankly,
because the latter is clearer. The working group, as I stated earlier, did
not discuss and has not taken a position on, syntax.
In Helsinki we agreed that Relation had two elements - Type and Identifier.
The working group developed a preliminary scheme for Relation Type. Period.
It seems to me that Sigfrid wants to return to a position that existed
before Helsinki when relation did mot have these two elements. I don't
think we can do that, regardless of how the syntax issues are ultimately
handled.
.At 12:32 PM 3/24/98 +0100, Sigfrid Lundberg wrote:
>
>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
>
>
>
David Bearman
President
Archives & Museum Informatics
5501 Walnut St., Suite 203
Pittsburgh, PA 15232
tel. +1-412-683-9775; fax +1-412-683-7366
http://www.archimuse.com
|