[ 
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()}}.
* {{StandardOrderProcess.getOrderOptionType()}} could be inferred from 
{{getOrderOptions().getRecordType()}}.
* Adding a {{Source}} to {{ProcessStep.sources}} could automatically add the 
{{ProcessStep}} to {{Source.processSteps}} by weak reference, and conversely. A 
similar idea may apply to {{Platform}} and {{Instrument}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of 
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Distribution.formats}} may be inferred by the union of all contained 
{{DigitalTransferOptions.formats}}.
* {{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()}}.
* {{StandardOrderProcess.getOrderOptionType()}} could be inferred from 
{{getOrderOptions().getRecordType()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of 
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Distribution.formats}} may be inferred by the union of all contained 
{{DigitalTransferOptions.formats}}.
* {{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.



> 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()}}.
> * {{StandardOrderProcess.getOrderOptionType()}} could be inferred from 
> {{getOrderOptions().getRecordType()}}.
> * Adding a {{Source}} to {{ProcessStep.sources}} could automatically add the 
> {{ProcessStep}} to {{Source.processSteps}} by weak reference, and conversely. 
> A similar idea may apply to {{Platform}} and {{Instrument}}.
> * {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous 
> of {{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
> * {{Distribution.formats}} may be inferred by the union of all contained 
> {{DigitalTransferOptions.formats}}.
> * {{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.3.4#6332)

Reply via email to