Hi Jeroen,
Please see my comments below:
Thanks.
John
-----Original Message-----
From: Jeroen Ticheler [mailto:Jeroen.Ticheler@anonymised.com]
Sent: Tuesday, 23 May 2006 8:28 PM
To: Hockaday John
Cc: acarboni@anonymised.com;
Subject: Re: [Geonetwork-devel] Inheritance between ISO 19139
XML document instancesSee below,
On May 23, 2006, at 7:46 AM, John.Hockaday@anonymised.com wrote:
In geonetwork 1 we had a separate table to store common
ResponsibleParty
elements but then we removed this option to keep things simple and to
allow the validation against our old DTD. If this possibility
is provided by
the new 19139 specification then I agree with you to use it.
Here issues
are only technical.The inheritance concept is not just for responsibleParty
elements. It is for
all elements. Its purpose is to reduce the amount of effort to enter
metadata as well as more closely link the metadata of relative
hierarchyLevels. For example, the information in a
'featureType' metadata
record could be exactly the same as the 'dataset' metadata
except that the
title and abstract are different. Therefore, the
'featureType' can inherit
the content of all the elements and then the content of the title and
abstract elements can be over written by the user using the
metadata editing
tool.Yes. I agree that the issues are only technical. ;--) ISO
1913 XSDs allow
for this inheritance by using the Xlink schema. Xlink allows
the content of
an element to receive the content of a reference element by
using a reference
to that element. I'm investigating how the ISO 19139 XSDs
actually do this.
I'll keep you informed on what I find out.Anyway, this feature is not planned. We are still missing
some important
features due to lack of money so I don't think we have the
resources to do that.I can understand that resources are limited and some other
features may seem
more important. However, I still need to stress that this is
an essential
function of any ISO 19115 metadata entry tool.This is for sure a very powerful property. However, I also
see a big problem in practical implementation if you want to
use that full flexibility... What will a sensible GUI look
like if you are allowed, as a user to pick any metadata
"object" available and kind of "glue" together your metadata
record?
A GUI would first ask the user if they want to inherit information from
another metadata record when the user asks to create a new metadata record.
The user would then search for a metadata record to inherit. Once that
metadata record is found then the user selects that metadata record to
inherit.
The content of the inherited metadata record will be shown in the fields of
the new (child) metadata record. It will have a new fileIdentifier but the
content of the parentIdentifier will be the content of the parent's
fileIdentifier. The user will probably be prompted to change the title if
they then try to store that new metadata record as is.
The user can go through all the elements (except the parentIdentifier) and
change them if they want to. For each of those changed elements the system
will remove the reference to the parent elements in the 'idref' or 'ref' (I
don't know which one yet but I will keep you informed) attribute for those
elements. The user can then save, validate and publish the new metadata
record.
When the user next opens that metadata record the content from the parent
metadata record will be placed into element fields in the GUI where the
'idref' or 'ref' attribute refer to the parent record. The content of the
other metadata elements will come from the new metadata records XML file.
A machine may be able to do this, but for a human
being this may simply be too complex?
It should be easier for the users because the content of the elements are
already filled out. They just have to add content for the elements that have
changed or for the elements that have no content in the parent metadata
record.
One solution I can see
coming in the future, but it will require quite some work, is
the updating of elements throughout a collection through CSW
transactions.
I see this being done in two ways. First is that at a set time, maybe during
the night, the system checks to see if the parent records of any children
records have changed. If they have then the children records will have the
content of the changed parent elements changed in their own elements.
Second, it may occur on the fly. Whenever a metadata record is accessed its
parent record is checked to see if it has been updated since the new metadata
record was created. If so then the content of the parent record is pushed
into the child's elements before the record is indexed or retrieved.
This is pretty simple stuff for the computers and software of today. We
humans just have to work out how to do it. ;--)
This may work on records that are created using
templates, so the content of an object is known. However, the
complications that brings about can be significant
Splitting out some essential metadata objects is an option
for sure, this would need work too, but I know there is more
interest in that. E.g. contacts and spatial reference systems
were mentioned as possible candidates.
These are obvious instances where inheritance is necessary. If it can be
done for the obvious ones then it should be achievable for all the others.
;--)
Ciao,
Jeroen