Hi All,
I hope my mistakes for this year are over. ;--)
To answer Jeroen's question about which components should be reusable or
available using xlink, I believe that any object that can have an xlink
attribute according to the XSDs should be available. We just don't know what
the GN clients want and so we should give them whatever is officially
available. That way no-one can complain except maybe the code writers who
have to implement this. ;--)
Some examples of those elements that can have an xlink attribute are:
gmd:contact
gmd:contactInfo
gmd:phone
gmd:address
gmd:locale
gmd:spatialRepresentationInfo
gmd:axisDimensionProperties
gmd:axisDimensionProperties
gmd:cornerPoints
gmd:referenceSystemInfo
gmd:referenceSystemIdentifier
...
Etc.
There is no need to list the rest because that information can be obtained
from the XSDs and is dependent on the XML implementation of the profile.
How can the application resolve the xlinks?
------------------------------
Here is an example of the use of an xlink:
<gmd:contact
xlink:href="http://asdd.ga.gov.au/asdd/work/ISOmetadata/GAOpenDaySeries.xml#G
ADetails"/>
And here is where the contact information is found:
<gmd:CI_ResponsibleParty id="GADetails">
...
</gmd:CI_ResponsibleParty>
So theoretically the application only has to download the XML document
referenced in the xlink, extract the content of the XML element that contains
and id value of "GADetails" and then insert that into the referencing element
in the referencing XML document. In the example above it would be
<gmd:contact>.
Of course the application has to identify if the content of the referenced
xlink is equal to the structure of the referencing object. This could be
resolved by the validation process.
In the above example the metadata record is directly available by a URL.
However, I expect that the xlink references in GN should be using a URL that
calls GN and passes the fileIdentifier as a parameter. For example:
http://hostname:portnumber/geonetworkService?fileIdentifier="uuidNumber"#GADe
tails
The software should call up the XML document delivered by GeoNetwork
identified by the uuidNumber of the fileIdentifier and then extract and
deliver the element identified by the "id" attribute with content of
"GADetails".
There are many questions to answer in this implementation such as, what URIs
are allowed? Do we allow URNs? If so how are they resolved to an actual web
service? I would suggest that we keep it simple to start with. Also, what
happens if the called XML element also has sub elements which have xlink
references? I suggest that these should also be resolved at time of access
so that xlink is a cascading process. Another questions is what does the
application do if the id or uuidNumber do not exist? Etc.
How can the application determine what elements should be reusable?
--------------------------------------------------------------------
It's all in the attributes. If an element can have a "id" attribute and it
also has a parent element that can have an "xlink" attribute then it should
be storable as a reusable element. For example, gmd:CI_Date can have an
"id" attribute and its parent "gmd:date" can have an "xlink" attribute.
Therefore it should be storable as a reusable component.
I expect that you immediately worry about some elements that may not be
suitable as reusable elements such as "gmd:MD_DataIdentification" because why
would you want to have duplicate gmd:identificationInfo? The answer is "not
likely" but it is a possibility that an organisation would want to have the
exact same metadata record but with a different metadataStandardName. For
example, I may want to show a metadata record in "ANZLIC Metadata Profile"
metadataStandardName format and the same information in "Australian Marine
Community Profile" metadataStandardName. The only thing that would change
are the fileIdentfiers because they are unique and some of the structure
elements that are appropriate for the "Australian Marine Community Profile".
I believe that there are better ways to present metadata information in two
profiles such as using XSLTs and doing on the fly transformations. However,
it may be something that an organisation may want for their particular
business rules and who are we to prevent that?
Configuration of reusable elements.
------------------------------------
It is now logical to discuss what elements should be restricted to not be
reusable? This will be determined by the business rules of the organisation
using GN. As shown in the previous section, if the organisation believes
that there should not be duplicate "gmd:MD_DataIdentification"s then they can
remove this element from some sort of configuration file that has been
generated by processing the XSDs of the available profile. It may be the
case where the organisation may want to make an element reusable in one
profile and not reusable in another so each profile should have a 'reusable
elements' configuration file.
I have probably made this reply too long but it is something that will have
to be considered when xlink is implemented.
Thanks.
John
-----Original Message-----
From: Lagarde Pierre [mailto:P.Lagarde@anonymised.com]
Sent: Tuesday, 8 January 2008 7:16 PM
To: Jeroen Ticheler; Hockaday John; François Prunayre
Cc: geonetwork-users@lists.sourceforge.net
Subject: RE: [GeoNetwork-users] "Duplicate" metadata,
Datasets and Series [SEC=UNCLASSIFIED]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 versaCiao, 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 Series
>>
>>
>> Hi 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_Metadata
>>
>> Then 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.n
et/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.
*****************************************************************************
*****************
Ciao, Jeroen