Hi all,
To resume, two types of links could be defined in regard of standards :
1 / the relation between two metadata : child / parent (dataset/series) or Service 19119 MD / Data 19139 MD. The standards include a reference between these metatada files.
2 / the relation between a part of the metadata and a repository (SRS, thesaurus, responsability parties,..). Currently these repository is used with a approach of "copy-paste" a element in the XML file. The issue is not the purpose of the standards and it's more a software specification. A solution could be the use of ebXML implementation or to work with a relational database. Indeed, the solution of xlink/xinclude seems to be more efficient in the case of GN.
And we could perhaps merge the point 1) and 2) with the use of xlink/xinclude to include the reference between two metadata files.
So, the "jump" forward the implementation of xlink mechanism seems me mandatory.. I could include the implementation in the next version of Geosource but the development will not start before march 2008...
Cia,
Pierre
-----Message d'origine-----
De : geonetwork-users-bounces@lists.sourceforge.net [mailto:geonetwork-users-bounces@lists.sourceforge.net] De la part de Jeroen Ticheler
Envoyé : mardi 8 janvier 2008 07:54
À : John.Hockaday@anonymised.com; François Prunayre
Cc : geonetwork-users@lists.sourceforge.net
Objet : Re: [GeoNetwork-users] "Duplicate" metadata, Datasets and Series [SEC=UNCLASSIFIED]
Hi both,
Indeed xlink (or xinclude) could be what we use internally. What goes out to others would be the fully merged metadata document. In the editor, a system very much like the prototype sub-template system could be used, or what BRGM implemented for SRS in geosource (!?).
What we should work on is to define the main metadata objects that we want to store as separate entities. Things like the contacts, SRS, citations et cetera.
Do we want such implementation to be generic with respect to these objects? And if so, how generic to ensure we can build a usable user interface at the front end? Should we store the duplicates as templates? Should they be stored in separate tables, or simply be flagged as objects in the metadata table?
Once we have agreement on those aspects and possibly others, we can define what the implementation should look like.
Implementation of the ebXML meta model seems to move us in such direction and vice versa 
Ciao, Jeroen
On Jan 3, 2008, at 12:23 AM, John.Hockaday@anonymised.com wrote:
Hi Francois,
Although it hasn't been implemented yet the proper use of reusing
duplicate information in metadata records is the xlink attribute.Although one can use the parentIdentifier to identify the
fileIdentifier of the parent metadata record, I don't know of anyway
for the content of the parent metadata record to be included into the
child metadata record other than xlink.It may be possible for some Australians to look at incorporating xlink
into GeoNetwork. However we won't have that discussion until March
2008 and the outcomes of that discussion may be that it won't be done.I hope that this helps.
John
-----Original Message-----
From: geonetwork-users-bounces@lists.sourceforge.net
[mailto:geonetwork-users-bounces@lists.sourceforge.net] On Behalf Of
Francois-Xavier Prunayre
Sent: Wednesday, 2 January 2008 8:50 PM
To: geonetwork-users@lists.sourceforge.net
Subject: [GeoNetwork-users] "Duplicate" metadata, Datasets and SeriesHi list, I'm looking for some advice/comments on how to deal with
"duplicate" metadata between datasets and series.I've to deal with more and more datasets and sometimes metadata are
more or less the same between datasets (ie. only title, point of
contact and bbox are different). These metadata are edited by
different organisations and sometimes in different catalogues.It looks like we could set up control on the metadata editing /
search tools between a "master" metadata and childs metadata in order
to have easy editing for user but it seems quite difficult and
complex to do so
: some sections in read-only, some sections not ...Maybe a more generic approach could be to use relationship between
series and datasets as defined in ISO and then set up a MD_Metadata
composed of a series which has 0..n MD_Metadata :
gmd:series/gmd:DS_Series/gmd:composedOf/gmd:DS_DataSet/gmd:has
/gmd:MD_MetadataThen could we described the dataset completely in the DS_Series
element or having a gmd:MD_Metadata element pointing to another
metadata using the uuid attribute ? This uuid could be in the local
node or even in another remote node. Then how to resolve uuid ? Use
of xlink:href could be better ...Anybody using such mechanism ? Comments are welcomed.
Thanks.Francois
--------------------------------------------------------------
-----------
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork----------------------------------------------------------------------
---
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/
projects/geonetwork
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
**********************************************************************************************
Pensez à l'environnement avant d'imprimer ce message
Think Environment before printing
Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) désigné
(s)
comme tel(s).
En cas de réception par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu.
L'absence de virus a été vérifiée à l'émission, il convient néanmoins de s'assurer de l'absence de
contamination à sa réception.
The contents of this email and any attachments areconfidential. They are intended for the named recipient
(s)
only.
If you have received this email in error please notifythe system manager or the sender immediately and do
not
disclose the contents to anyone or make copies.
eSafe scanned this email for viruses, vandals and malicious content.
**********************************************************************************************