Hi Evert, Simon and list,
The email below is of special interest to our metadata editor project:
our client, Bureau of Rural Sciences, which is represented by Evert
wants to be able to have extensions to the standard being reflected in
the editor.
In order to have make the editor as generic as possible, our idea is the
following:
Special cases (like references to grid representations and reference
systems within digital transfer options) will be translated into an
extension XSD to the ISO 19139 that will be inserted in a local GN
instance. GN will pick up that extension automatically and will be
reflected in the 'internal representation' that is currently used for
building the current HTML form and also used as the basis for our XForm.
Of course the resulting metadata document would not match the standard
and will have to be translated back into ISO 19139 at some point.
The question is: which of the 3 solutions below are possible to
implement in GN and how much effort would be involved?
From the perspective of the client, solution 3 would be best: a new
table of relationships. Would that be picked up by GN automatically?
If not, would solution 2?
Thanks,
Roald
On Wed, 2008-06-04 at 15:28 +0930, Bleys, Evert - BRS wrote:
ISSUE:
How to deal with specific instances of one class that refer to only one
instance of another class.Context
ISO 19115 / ISO 19139 allows for multiple instances of a range of
classes.
ISO 19115 (non-exclusive list)
MD_Metadata has spatialRepresentationInfo [0..*], referenceSystemInfo
[0..1], identificationInfo [1..*], etc
MD_Distribution has distributionFormat [C..*], transferOptions [0..*],
etc
[ISO19139 allows for @id in the associated class for each of these]USE CASE:
A record may contain more than one MD_Identification -
MD_DataIdentification (DI), or SV_ServiceIdentification (SI)
When describing a closely coupled service this is logical
(conditionality of srv:operateOn)
(other cases are less obvious)
In one metadata record there could (often should be):
more than one MD_DigitalTransferOption(TO)
more than one MD_Format (DF)
more than one spatial Representation - MD_GridSpatialRepresenation
(GR), MD_VectorSpatialRepresenation (VR), etc
more than one MD_ReferenceSystem (RS)PROBLEM:
How to relate a specific TO with the appropriate DI/SI, DF, RS, GR,
and VRSOLUTIONS:
1) UGLY - build a @id in TO that when parsed yields the appropriate
DI/SI, DF, RS, GR, and VR
2) KLUDGY - build a schema to replace MD_DigitalTransferOptions
contains associations - allowing for referential
attribution (xlink:href)
for each of DI/SI, DF, RS, GR, and VR
(refer to
http://adl.brs.gov.au/metadata/gmd/BRS_transferOptions.xsd)
3) ACCEPTABLE - build a schema to replace MD_Metadata that contains a
[0..*] association to a new class
build new class that relates two and only two instances
of aggregate classes (use xs:IDREF)
(refer to
http://adl.brs.gov.au/metadata/gmd/BRS_metadataEntity.xsd)
OUTCOMES:
1) this is feasible, does not break ISO 19115 or ISO 19139 even if it
is not acceptable
Already in use see metadata accessible via http:/adl.brs.gov.au
2) This assumes that the only place that relationships are important is
in the MD_DigitalTransferOptions
If metadata is delivered in this form then need to report a set of
MD_MetadataExtensionInformation
but readily translatable into option 1 (thus no need to report a set
of MD_MetadataExtensionInformation)
3) Allows for previously undefined relationships to be described
Bit harder to manageQUESTION:
What next?Cheers
e
Evert Bleys
BRS Data Manager
Biosecurity and Information Sciences
Bureau of Rural Sciences
Department of Agriculture Fisheries and Forestry
GPO Box 855 CANBERRA CITY ACT 2601
Ph +61 (0)2 6272 5627------IMPORTANT - This message has been issued by The Department of Agriculture, Fisheries and Forestry (DAFF). The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. It is your responsibility to check any attachments for viruses and defects before opening or sending them on.
Any reproduction, publication, communication, re-transmission, disclosure, dissemination or other use of the information contained in this e-mail by persons or entities other than the intended recipient is prohibited. The taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error please notify the sender and delete all copies of this transmission together with any attachments. If you have received this e-mail as part of a valid mailing list and no longer want to receive a message such as this one advise the sender by return e-mail accordingly. Only e-mail correspondence which includes this footer, has been authorised by DAFF
-------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
--
Roald de Wit
Software Engineer
roald.dewit@anonymised.com
Commercial Support for Open Source GIS Software
http://lisasoft.com/LISAsoft/SupportedProducts/