[GeoNetwork-devel] Multiple root elements? (Formerly Config.xml for languages)

Hi Tim,

Thanks for your reply. It's great to see someone else looking into the
details of the ISO 19100 standards. ;--) Any way, here are my comments:

Firstly the 05-015 document that you state is an OGC Discussion Document and
not an OGC Standard. It is *definitely not* an ISO standard. ISO standards
seem to have a more rigorous acceptance process which may eliminate some of
the errors that I have found in the OGC 05-015 discussion paper. Such as:

1. ISO 19115 identifies in section 6.5 "Core metadata for geographic
datasets". There are many more hierarchyLevel types that ISO 19115 can be
used to define metadata. The hierarchyLevel of "dataset" is just one of
those and this type is what is used for the "Core metadata for geographic
datasets".

It may be very difficult to define a Geographic Bounding Box for metadata of
a hierarchyLevel of "featureType" unless one was to use the entire earth. It
is not necessary to know where a "featureType" will be used while it is being
defined. However, once that "featureType" is used to instantiate a "feature"
then the metadata for that "feature" should have a Geographic Bounding Box.

For example, a "featureType" of bridge can be defined without knowing where
in the world a bridge will be used. However, once a bridge feature is
defined, eg. "Sydney Harbour Bridge", then the location of that feature
should be defined.

2. Following on from there I disagree with the set of Core metadata for OGC
Web Services (OCW) as shown in Table 2 and discussed in section 6.3 of OGC
05-015. First of all a web service should be using ISO 19119 which is an
extension of the ISO 19115 for Services. The hierarchyLevel of an OCW should
be "service" as defined in ISO 19115. "Core metadata for geographic
datasets" are *not* for a hierarchyLevel of "service". Hence topicCategory
is not mandatory. It is optional. Logically the datasets that a web service
delivers should have a topicCategory but certainly not the web service
itself. Each time I add the delivery of a dataset, which has a different
topicCategory, via a web service I would have to add that topicCategory to
the metadata of that web service. This is not a practical way of doing
things and thank fully was not prescribed by the ISO 19115 and ISO 19119
standards. Core metadata is only for geographic "dataset"s and not other
hierarchyLevel types.

Following on from this, how does one practically define metadata for an item
that may be related to many datasets (and other hierarchyLevel types)? This
leads into the discussion about root elements.

The MD_AggregrateInformation class can be used to identify what resources
were used for a dataset. However this is for the development of that
particular item and may be difficult to maintain. Why not use the
DS_Aggregate defined in section 6.2 of ISO 19115?

Take for instance a platform. It can exist by itself without ever collecting
any data. (Take the Mars Beagle ;--)). It is an item and therefore should
have an ISO 19115 metadata entry with a hierarchyLevel of
"collectionPlatform" so that people and applications can find out that it
exists and how to use it. But what about all the data, and hence metadata,
that a platform and its sensors can deliver? Do we keep on editing its
metadata entry each time data is delivered from this platform? That would be
very difficult to maintain.

Also, the data itself may be deemed more important than the sensor or
platform so the metadata for each of the data collected by this sensor should
be available as separate items.

This is where the DS_Aggregate comes into play. We create an XML record for
the platform which has a root element of DS_Platform. We create metadata for
each of the data that the platform delivers with a root element of
MD_Metadata plus the platform itself and its sensors. We then add to the
DS_Platform XML references (hopefully using Xlink) to each of the MD_Metadata
records of the sensors and the data that the sensors deliver. The
DS_Platform XML record only needs to have references to the metadata using
the "has" element, which is a reference to the MD_Metadata_PropertyType and
the MD_Metadata. Hence DS_Platform is the root element that defines the
application of the platform its sensors and their collection of data.

Now for the reusable entities. Our organisation will have at least a million
metadata records. Currently there are only about 700 metadata records for
the "dataset"s but we will have metadata records for the "featureType"s,
"feature"s, "attributeType"s, "attribute"s, etc. Each of these metadata
records will have a metadata contact organisation of "Geoscience Australia"
with all its contact details.

It would be ludicrous to expect someone to type in those contact details for
each of those million records and imagine the furore if the telephone number
changed. Hence, we have the contact details in one entity data type called
CI_ResponsibleParty. This is then referenced (hopefully using Xlink) from
each of the million metadata records. If the phone number changes then we
only have to edit one phone number and it will be changed in the million
metadata records.

Also, the contact details for our organisation will exist even if we don't
have any metadata records. Hence, the CI_ResponsibleParty can exist without
needing a parent MD_Metadata record. Hence, the XML for our organisation's
contact details would be CI_ResponsibleParty. This could also be used by
other XML documents, eg. XHTML, if the CI_ResponsibleParty class was
referenced by the XSDs that generated the XHTML.

This concept can apply to all the ISO 19115 entity classes and hence each
class could have its own root element and be referenced from other XML
documents using Xlink.

I hope that this helps.

Please see other comments below:

Thanks.

John

-----Original Message-----
From: Tim Jacobs [mailto:jacobs_tim100@anonymised.com]
Sent: Wednesday, 3 January 2007 6:42 PM
To: Hockaday John; acarboni@anonymised.com;
geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Config.xml for languages

Hi Andrea and John,

Sorry, but I have to disagree with this.
Yes, ISO 19139's XML structure allows for many root elements
(MD_Metadata,
but also DS_Dataset,
DS_Aggregate and even small items like contact info elements).

However, according to OGC document "05-015" on Imagery
Metadata, in chapter
6.2 "Core metadata", a structure of required core metadata
elements is
given, which starts with a MD_Metadata element. In the text,
it says that
the shown hierarchy is "prescribed by ISO 19115", so I assume
ISO 19115
prescribes the use of MD_Metadata as root element.

No. The 'hierarchy is "prescribed by ISO 19115"' is the hierarchLevel of
"dataset" which is defined in the MD_ScopeCode code list. It isn't
prescribing that the MD_Metadata element is to be used as the root.

That section also has the wrong understanding of "core metadata". (See
explanation at beginning.)

If someone really wants to describe a DS_Dataset, or an aggregate of
datasets (DS_Aggregate), or
one of the GMX extensions thereof (MX_Dataset or
MX_Aggregate), the required
structure is like this:
<MD_Metadata>
   <....>
   <describes>
      <DS_Dataset> or <MX_Dataset>
      <.....>
</MD_Metadata>

Yes. That is one way to define the metadata for a DS_Dataset but Figure 3 in
section 6.2 of ISO 19115 shows that the relations between MD_Metadata and
DS_DataSet and DS_Aggregate are in both directions. Therefore, a DS_DataSet
can have many MD_Metadata records. Similarly with a DS_Aggregate, although
it is an abstract class and needs to be instanciated with DS_Sensor .....
etc. etc.

for a simple dataset and
<MD_Metadata>
   <....>
   <series>
      <DS_Aggregate> or <MX_Aggregate>
         <composedOf>
             <DS_Dataset> or <MX_Dataset>
         <composedOf>
             <DS_Dataset> or <MX_Dataset>
         <composedOf>
             <DS_Dataset> or <MX_Dataset>
         <.....>
</MD_Metadata>

Ditto.

<MD_Metadata> can even "describe" multiple -unassociated-
datasets (via
multiple <describes> elements) or refer to multiple series of
aggregated
datasets, if I'm not mistaken.

Best regards,

Tim

>From: <John.Hockaday@anonymised.com>
>To:
<acarboni@anonymised.com>,<geonetwork-devel@lists.sourceforge.net>
>Subject: Re: [GeoNetwork-devel] Config.xml for languages
>Date: Wed, 3 Jan 2007 16:07:32 +1100
>
>Hi Andrea,
>
>There is a list of ISO 639-2 country codes at:
>
>http://www.loc.gov/standards/iso639-2/ISO-639-2_values_8bits.txt
>
>Please note that they are in a pipe "|" delimited text list.
They should
>be
>converted to XML to be used as an ISO 19139 XML codeList. I.E.
>"CT_CodelistCatalogue" XML type.
>
>Regarding the root element of metadata. The DS_DataSet is a
valid root
>element if it is an aggregate of dataset and metadata
records. The trouble
>with the ISO 19139 implementation is that there can be many
root elements
>depending on what object is being described. This is
identified in the ISO
>19115 UML by the use of aggregation associations and not composition
>associations. For example,
>
> MD_Metadata is the root element when one metadata
record is being
>described,
> DS_DataSet is the root element when the dataset and aggregated
>metadata records are being described,
> CI_ResponsibleParty is the root element when a
CI_ResponsibleParty is
>being described.
>
>These can all exist as individual XML document instances and
hence can be
>referenced using the Xlink element when an XML document
instance is being
>created. That is, this XML document instance contains these
XML document
>instances.
>
>This probably doesn't help you with your implementation but
I don't think
>that you should limit the root element to MD_Metadata if it is at all
>possible. I'm sure there will be someone out there who, in
the future,
>will
>want to describe a DS_DataSet and will complain (like I did
for MD_Metadata
>;--)) that GeoNetwork doesn't allow it to be defined. Once we start
>defining
>"series", "dataset", "featureType" and "feature" etc. XML
metadata records
>we will want to start relating them to each other.
>
>We can discus this more if you like but I expect that you
have got the
>idea.
>
>Thanks for listening. I have always found the developers on
this list to
>be
>very accommodating if at all possible.
>
>Thanks again.
>
>
>John
>
> > -----Original Message-----
> > From: geonetwork-devel-bounces@lists.sourceforge.net
> > [mailto:geonetwork-devel-bounces@lists.sourceforge.net] On
> > Behalf Of Andrea Carboni
> > Sent: Wednesday, 3 January 2007 11:12 AM
> > To: geonetwork-devel@lists.sourceforge.net
> > Subject: Re: [GeoNetwork-devel] Config.xml for languages
> >
> >
> > Hi John,
> >
> > we are glad to have your feedback and we try to make changes
> > you suggest
> > as we can. I have just changed the metadata root element from
> > DS_DataSet
> > to MD_Metadata and I will address the language codes before
> > the final version.
> >
> > Looking into the 19139 schema, I have found that into the
> > codelist files there
> > are only 2 languages (english and francaise). Does anybody
> > have a list of those
> > codes (better in the same 19139 codelist format with
short names) ?
> >
> > Cheers,
> > Andrea
> >
> >
> > > Hi All,
> > >
> > > First of all happy new year.
> > >
> > > Secondly, I would just like to point out that ISO 19115
> > stipulates in the
> > > data dictionary that ISO 639-2 should be used for the
> > "language" element .
> > > That is, the three letter code for languages. EG. "eng".
> > >
> > > Probably now is a good time to switch to the three letter
> > code. Just a
> > > suggestion. ;--)
> > >
> > > Thanks.
> > >
> > >
> > > John
> >
> > --------------------------------------------------------------
> > -----------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the
> > chance to share your
> > opinions on IT & business topics through brief surveys -
and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge
>&CID=DEVDEV
>_______________________________________________
>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
>
>-------------------------------------------------------------
------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the
chance to share
>your
>opinions on IT & business topics through brief surveys - and
earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforg

e&CID=DEVDEV

_______________________________________________
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

_________________________________________________________________
All things trendy for Windows Live Messenger ...
http://entertainment.msn.be/funwithmessenger

Hi John,

Thanks for your reply. It's great to see someone else looking into the
details of the ISO 19100 standards. ;--) Any way, here are my comments:

Unfortunately, I don't have all the details of the standards at hand, but I'm willing to learn more about them. For starters, it would be nice for me to have more details on ISO 19115.

Basically, what I did was download a few documents about the standards and the latest
XSDs from ISO 19119. From that, I defined metadata XMLs that describe the data products
that my company delivers, which are basically sets of geolocated datasets, derived from satellite
measurements.

If I understand you correctly, the root element actually depends on what you're describing.
If it's a dataset, then MD_Metadata as root is fine. If it's something else, like your contact information, a measurement platform, or a web service, then other root elements are needed and
the structure of OGC 05-015 doesn't apply.

This certainly explains why ISO 19119 XSDs define almost all elements at the same level in the XML hierarchy (which is clearly done so that they can all be root elements), which seemed inconvenient from my point of view. Thanks for this clarification.

Your second point is that, hopefully using XLink, we can tie together the metadata of different types (i.e. provide a reference to the platform's metadata from the XML that describes a dataset delivered by that platform, but not vice-versa, to avoid having to update the platform's metadata each time it delivers a new dataset). Right?

In fact, I was looking into using XLink to avoid some of the redundancy in my XMLs that describe datasets. However, from my investigations, it seems that XLink is currently very poorly supported in for instance browsers. Hence, I concluded to not use it for the time being, allthough it's an official W3C standard and should thus be adopted in some way by the main browsers in the future.
So I'm wondering how this can be tackled for GN.

Best regards and thanks again for the clarifications.

Tim

_________________________________________________________________
Did you know that Windows Live Messenger is accesible on your mobile as from now? http://get.live.com/messenger/mobile