[
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 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.
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}}.
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 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.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
