[jira] [Updated] (SIS-110) Add some intelligence in metadata implementation

["Martin Desruisseaux (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SIS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Desruisseaux updated SIS-110:
------------------------------------

    Description: 
ISO 19115 seems to have some redundancies in metadata information. For example:

* {{Identification.pointOfContact}} ↔ {{Identification.citation.citedResponsibleParty}} (collection of {{ResponsibleParty}}): the former could be defined as a subset of the later where the {{ResponsibleParty.role}} attribute is set to {{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}} (collection of {{ResponsibleParty}}): the former is the contact responsible for the metadata, while the later is the contact responsible for the _resource_ described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred from the later.
* {{Georectified.checkPointAvailability}} ↔ ({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the former could be set to {{true}} if any of the later attribute is non-null. There is many other {{fooAvailability}} attribute like that one - all of them may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of {{getLinkage()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of {{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Metadata.locale}} may need to contain all locales used by every {{InternationalString}} instances in the metadata tree. This is needed since the {{locale}} attribute in {{<gml:LocalizedCharacterString>}} is a reference to a locale defined in {{<PT_Locale>}} (SIS-137).

h3. As an optional mechanism

We could provide some optional mechanism (to be enabled only if desired) where, if a value was not explicitly given for some attributes, a default value is automatically inferred from other attribute. For example:

* If no value was explicitly given to {{Metadata.contact}}, returns {{Metadata.identificationInfo.pointOfContact}}.
* If no value was explicitly given to {{Metadata.identificationInfo.pointOfContact}}, returns a filtered list of {{Metadata.identificationInfo.citation.citedResponsibleParty}} where {{role}} = {{POINT_OF_CONTACT}}.

Note the cascading of the above two inference mechanisms.

h3. Impact on other code
If the {{Metadata.pointOfContact}} property become automatically calculated, then we should remove the duplication done in the NetCDF metadata reader.


  was:
ISO 19115 seems to have some redundancies in metadata information. For example:

* {{Identification.pointOfContact}} ↔ {{Identification.citation.citedResponsibleParty}} (collection of {{ResponsibleParty}}): the former could be defined as a subset of the later where the {{ResponsibleParty.role}} attribute is set to {{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}} (collection of {{ResponsibleParty}}): the former is the contact responsible for the metadata, while the later is the contact responsible for the _resource_ described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred from the later.
* {{Georectified.checkPointAvailability}} ↔ ({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the former could be set to {{true}} if any of the later attribute is non-null. There is many other {{fooAvailability}} attribute like that one - all of them may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of {{getLinkage()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of {{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Metadata.locale}} may need to contains all locales used by every {{InternationalString}} instances in the metadata tree. This is needed since the {{locale}} attribute in {{<gml:LocalizedCharacterString>}} is a reference to a locale defined in {{<PT_Locale>}} (SIS-137).

h3. As an optional mechanism

We could provide some optional mechanism (to be enabled only if desired) where, if a value was not explicitly given for some attributes, a default value is automatically inferred from other attribute. For example:

* If no value was explicitly given to {{Metadata.contact}}, returns {{Metadata.identificationInfo.pointOfContact}}.
* If no value was explicitly given to {{Metadata.identificationInfo.pointOfContact}}, returns a filtered list of {{Metadata.identificationInfo.citation.citedResponsibleParty}} where {{role}} = {{POINT_OF_CONTACT}}.

Note the cascading of the above two inference mechanisms.

h3. Impact on other code
If the {{Metadata.pointOfContact}} property become automatically calculated, then we should remove the duplication done in the NetCDF metadata reader.



> Add some intelligence in metadata implementation
> ------------------------------------------------
>
>                 Key: SIS-110
>                 URL: https://issues.apache.org/jira/browse/SIS-110
>             Project: Spatial Information Systems
>          Issue Type: Improvement
>          Components: Metadata
>    Affects Versions: 0.3
>            Reporter: Martin Desruisseaux
>            Priority: Minor
>
> ISO 19115 seems to have some redundancies in metadata information. For example:
> * {{Identification.pointOfContact}} ↔ {{Identification.citation.citedResponsibleParty}} (collection of {{ResponsibleParty}}): the former could be defined as a subset of the later where the {{ResponsibleParty.role}} attribute is set to {{Role.POINT_OF_CONTACT}}.
> * {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}} (collection of {{ResponsibleParty}}): the former is the contact responsible for the metadata, while the later is the contact responsible for the _resource_ described by the metadata. However in practice this is often the same contact.
> * {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred from the later.
> * {{Georectified.checkPointAvailability}} ↔ ({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the former could be set to {{true}} if any of the later attribute is non-null. There is many other {{fooAvailability}} attribute like that one - all of them may be candidate to such automatic inference.
> * {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
> * {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of {{getLinkage()}}.
> * {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of {{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
> * {{Metadata.locale}} may need to contain all locales used by every {{InternationalString}} instances in the metadata tree. This is needed since the {{locale}} attribute in {{<gml:LocalizedCharacterString>}} is a reference to a locale defined in {{<PT_Locale>}} (SIS-137).
> h3. As an optional mechanism
> We could provide some optional mechanism (to be enabled only if desired) where, if a value was not explicitly given for some attributes, a default value is automatically inferred from other attribute. For example:
> * If no value was explicitly given to {{Metadata.contact}}, returns {{Metadata.identificationInfo.pointOfContact}}.
> * If no value was explicitly given to {{Metadata.identificationInfo.pointOfContact}}, returns a filtered list of {{Metadata.identificationInfo.citation.citedResponsibleParty}} where {{role}} = {{POINT_OF_CONTACT}}.
> Note the cascading of the above two inference mechanisms.
> h3. Impact on other code
> If the {{Metadata.pointOfContact}} property become automatically calculated, then we should remove the duplication done in the NetCDF metadata reader.



--
This message was sent by Atlassian JIRA
(v6.1#6144)