sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SIS-110) Add some intelligence in metadata implementation
Date Wed, 03 Jul 2013 13:55:19 GMT

    [ https://issues.apache.org/jira/browse/SIS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698974#comment-13698974
] 

Martin Desruisseaux commented on SIS-110:
-----------------------------------------

We had only one "automatic property" prior this JIRA task: {{OnlineResource.protocol}}. The
automatic inference of this property value has been removed from the JDK7 branch at revision
1499404 because it was the only automatic property, and we may want a more global though about
how we will give user control on property inference.

To restart this work, developer can undo the change at revision 1499404 as a starting point.

                
> 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}}.
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message