How to document used schema version in dataset metadata?
|Status:||New||Start date:||22 Jun 2015|
|Assignee:||Michael Lutz||% Done:|
|Proposed change or action:|
Investiagte how to document in a data set's metadata, which schema version is used by the data set.
If this is possible this should be proposed for consideration in the update of the MD guidelines currently carried out in MIWP-8.
#2 Updated by Michael Östling about 5 years ago
- Assignee changed from Michael Östling to Michael Lutz
A short summary of how Application schema have been handled in previous documents as I see it, I'm not fully aware of the history regarding the requirements for this element.
In some of the previous versions of the data specifications (eg Protected Sites (PS) version 3.0) The application schema (name and version) was inserted as an optional dataset level metadata element (see chapter 8.1.5).
This has in later versions (Eg Protected Sites version 3.2) been removed and the Application Schema has instead been documented in the metadata element MD_Format.
MD_Format format have here been used for implementing the required element encoding which is one of the six interoperability elements from the regulation.
One of the tasks in the work of MIWP-8 has been to move the six interoperability elements from dataspecifications and instead document these fully inside TG Metadata.
While these elements was moved into TG Metadata we have also changed the implementation instructions for MD_Format. It is no longer recommended to use
MD_Format to report application schema name and version since that is beyoynd the scope of MD_Format.
So for reporting Schema version one suggestion would be to use the original suggested element 320. MD_ApplicationSchemaInformation
One other option to avoid adding a new element (application schema) would be to use similar approach as we discuss for other reports. That would be to add
an extra conformance report referencing the registry or schema repository (eg http://inspire.ec.europa.eu/schemas/ps/3.0/ProtectedSites.xsd) where each version of Schema for each data specification are handled.
I'm not sure of that is taking the conformance reporting to far.
For an individual dataset we then would need the following conformance reports:
- One that reference the regulation with pass=true/false
- One or more that reference the dataspecifications and it's different ATS clauses with pass=true/false
- One that reference the Schema respository with reference to specific Schema version for the data specification with pass=true/false
We can lift this into the discussions in MIWP-8
#4 Updated by Marc Leobet almost 5 years ago
in France we will probably use the "Conformity" fields. We have yet define that this would have to be used for national specifications and/or templates :"The reference to different specifications such as the national ones can complement. Concretely, this means creating a dataset from the template data set provided, for example, by a national standardisation organisation, or comparing a particular data series to this template."
This has the value to do not add anything to the regulation.
#5 Updated by Peter Kochmann almost 5 years ago
German metadata guidelines consider DQ_ConformanceResult for expressing the logical schema in the dataset as well. We thought of multiple instances: At least you need to have a conformity statement citing the IR 1089/2010 (interoperability). In addition it's recommended to have a conformity statement citing the data specification including version and date to express which data schema is considered within the dataset. It's not intended to have an additional citation of the not supported schema version (with pass = FALSE) as well when already fulfilling another one.
We didn't consider the MD_ApplicationSchemaInformation for this. Because there's no common metadata profile in Germany we can't expect this element to exist in participating catalogues. In the latest profile recommendation of the surveying ressort this element is flagged as optional. So it may be considered in several catalogue implementations little by little but still can't be presumed basically!
#6 Updated by Antonio Rotundo almost 5 years ago
In Italian metadata profile the approach is similar than the German one. At least one conformity statement (through DQ_ConformanceResult) with the citation of Regulation 1089/2010 is required and more conformity statements with the citation of other data specifications (not only INSPIRE specs) are recommended. The version of the specifications can be included in the title element, but no recommendation is given on that.
We didn't even consider the MD_ApplicationSchemaInformation.
#7 Updated by Michael Östling almost 5 years ago
I would like one clarification on this.
As I understand it (but I could got this wrong) a single version of each dataspecification eg
Protected Sites version 3.2
Could be delivered by either xml-schema version 3 or 4
If that is the case having only a conformance report for the TG version does not specify the XML-schema.
The comments I see above indicate that each version of the dataspecifications uniquely indentifies what xml-schema that are used.
Is that the case or do we have to separately specify the XML-schema?
#8 Updated by André Schneider almost 5 years ago
In Switzerland (www.geocat.ch) we plan eventually to do this:
- describe with metadata the schema version
- link the metadata of the ressource with the metadata of the schema version, using MD_AggregateInformation (MD_AssociatedRessource in ISO 19115-1)
#9 Updated by Peter Kochmann almost 5 years ago
Up to now I wasn't aware that different schema versions can reference the same edition of data specification. So the question of Michael Ö is crucial!
The statement whether it is schema version 3.0 or 4.0 I consider to be an additional one. So maybe two instances of DQ_ConformanceResult (the first for the particular edition of data specification; the second for supported schema version) could be useful?
#10 Updated by Michael Lutz almost 5 years ago
The question of data specification vs. xml schema versions is indeed important. Every version of a data spec should point to only one schema version.
With the publication of the new schemas (v4.0), we should therefore actually publish a bug fix version 3.x.1 of all data specificaitons, where the encoding section points to the new schema version instead.
We have not done this yet mainly for the work it would involve (updating 34 documents). But I guess, for the sake of clarity it cannot be avoided. In the meantime, we will track this change request in the Redmine issue tracker (see corrigenda pages, e.g. https://ies-svn.jrc.ec.europa.eu/projects/thematic-clusters/issues?query_id=27).