You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2013/03/03 21:46:24 UTC
Note on ongoing work
Hello all
There is some notes about the ongoing work in the
org.apache.sis.metadata package [1]. There is some aspects inherited
from Geotk, and others than I'm reconsidering. The main points inherited
from Geotk are:
* MetadataStandard represents a standard (mostly ISO 19115 for now)
defined by a set of interfaces.
* AbstractMetadata provides default implementation of equals(Object),
hashCode() and toString() using Java reflection. ISO 19115 alone
will about 100 classes, some of them with lot of properties, so
defining the above methods manually for each of them is quite
tedious. Using reflection also allow others things like providing
java.util.Map views over the metadata (not yet committed).
* ModifiableMetadata is an AbstractMetadata subclass with some utility
methods for the subclasses which are going to provide setter methods
in addition to getter methods. The utility methods is mostly about
copying the content of another metadata, getting an unmodifiable
copy of a metadata, and instantiating collections only when first
needed. The later could be seen as mechanic for subclasses only.
* The KeyNamePolicy, NullValuePolicy and TypeValuePolicy enumerations
control the behaviour of java.util.Map views (not yet committed).
The only "real metadata" example available at this time is
DefaultCitation. However the ~100 other metadata classes would be
similar to DefaultCitation, after the MetadataStandard /
AbstractMetadata / ModifiableMetadata foundation are sound enough. If
there is any thing to revisit, please let me know (the above classes are
not final, and tests are not yet committed).
Some aspects that I'm considering to revisit are:
* Synchronization strategy: if one looks at DefaultCitation, we can
see that all all getter and setter methods are synchronized. I'm not
sure that it is the more appropriate choice... Alternatives are no
synchronization (not necessarily a bad idea, it really depends how
we use metadata), or synchronization using
java.util.concurrent.lock.ReadWriteLock. The later approach is more
costly, so it could be selected only if the metadata are used in a
way that justify it. I don't have a clear answer to this question
yet. I'm trying to investigate how metadata are actually used in the
projects I'm aware of, in the hope to figure out what could be the
most appropriate synchronization strategy.
* "Intelligence" in metadata: right now, the metadata implementations
are just containers. However relationship exists between some ISO
19115 elements. For example the ISO 19115-2 MI_Platform.instrument
property [2] is a collection of instruments mounted on the platform,
and each instrument has a MI_Instrument.mountedOn property [3] which
point back to the platform on which the instrument is mounted.
Obviously setting the MI_Platform.instrument property has
implication on MI_Instrument.mountedOn, and conversely. There is
many other places in ISO 19115 metadata where one property could be
inferred from other properties. But Geotk does not have any
"intelligence" like that. I'm thinking about, possibly, putting such
"intelligence" in SIS. However sometime trying to be too clever is
counter-productive, the risk being that some rules may be too arbitrary.
I'm not really looking for an immediate answer to the above. They are
questions that may be explored progressively. But though are always welcome.
Martin
[1]
https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/metadata/package-summary.html
[2]
http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Platform.html#getInstruments%28%29
[3]
http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Instrument.html#getMountedOn%28%29
Re: Note on ongoing work
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On 3/5/13 2:44 AM, "Martin Desruisseaux" <ma...@geomatys.fr>
wrote:
>Hello all
>
>Le 03/03/13 22:08, Mattmann, Chris A (388J) a écrit :
>> I would be in favor of no synchronization yet. Let's let concrete use
>> cases drive the implementation of potentially complex and possibly
>>costly
>> behavior. Until we have one, let's just keep it simple for now.
>Right, I think that omitting synchronization is something to consider
>seriously.
+1
>
>Right now the Geotk code has the Java "synchronized" keyword in it. The
>proposed path is to first commit the code as it stands regarding
>synchronization, then eventually remove the "synchronized" keyword. That
>way, we would have a commit to revert if we want to restore back
>synchronization.
Yeah that's no problem -- I wouldn't consider it a revert just an update :)
>
>
>> Yep we have relationships like this in the Tika Metadata object
>>(creating
>> a new Metadata object creates an internal object, which in turn needs
>>to be
>> mapped back to the parent metadata object). These reflexive
>>relationships
>> make sense to add intelligence to set the appropriate hooks.
>In the "Instrument versus Platform" that I gave, it was a relatively
>straightforward "parent - child" relationship. But other ISO 19115
>elements may have more convolved relationship. For example in the
>org.opengis.metadata.identification.Identification interface (derived
>from ISO 19115 "MD_Identification"), is the "pointOfContacts" property a
>subset of the "citation.citedResponsiblyParties" property including only
>the instances having their "role" property set to "pointOfContact"?
Yep that's harder lol.
>
>I realize that what I just said above sound obscure... I will come back
>on those question on a case-by-case basis when the classes will be there.
Makes sense to me, I get it!
Cheers,
Chris
>
> Martin
>
Re: Note on ongoing work
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
Le 03/03/13 22:08, Mattmann, Chris A (388J) a écrit :
> I would be in favor of no synchronization yet. Let's let concrete use
> cases drive the implementation of potentially complex and possibly costly
> behavior. Until we have one, let's just keep it simple for now.
Right, I think that omitting synchronization is something to consider
seriously.
Right now the Geotk code has the Java "synchronized" keyword in it. The
proposed path is to first commit the code as it stands regarding
synchronization, then eventually remove the "synchronized" keyword. That
way, we would have a commit to revert if we want to restore back
synchronization.
> Yep we have relationships like this in the Tika Metadata object (creating
> a new Metadata object creates an internal object, which in turn needs to be
> mapped back to the parent metadata object). These reflexive relationships
> make sense to add intelligence to set the appropriate hooks.
In the "Instrument versus Platform" that I gave, it was a relatively
straightforward "parent - child" relationship. But other ISO 19115
elements may have more convolved relationship. For example in the
org.opengis.metadata.identification.Identification interface (derived
from ISO 19115 "MD_Identification"), is the "pointOfContacts" property a
subset of the "citation.citedResponsiblyParties" property including only
the instances having their "role" property set to "pointOfContact"?
I realize that what I just said above sound obscure... I will come back
on those question on a case-by-case basis when the classes will be there.
Martin
Re: Note on ongoing work
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On 3/3/13 12:46 PM, "Martin Desruisseaux"
<ma...@geomatys.fr> wrote:
>Hello all
>
>There is some notes about the ongoing work in the
>org.apache.sis.metadata package [1]. There is some aspects inherited
>from Geotk, and others than I'm reconsidering. The main points inherited
>from Geotk are:
>
> * MetadataStandard represents a standard (mostly ISO 19115 for now)
> defined by a set of interfaces.
> * AbstractMetadata provides default implementation of equals(Object),
> hashCode() and toString() using Java reflection. ISO 19115 alone
> will about 100 classes, some of them with lot of properties, so
> defining the above methods manually for each of them is quite
> tedious. Using reflection also allow others things like providing
> java.util.Map views over the metadata (not yet committed).
> * ModifiableMetadata is an AbstractMetadata subclass with some utility
> methods for the subclasses which are going to provide setter methods
> in addition to getter methods. The utility methods is mostly about
> copying the content of another metadata, getting an unmodifiable
> copy of a metadata, and instantiating collections only when first
> needed. The later could be seen as mechanic for subclasses only.
> * The KeyNamePolicy, NullValuePolicy and TypeValuePolicy enumerations
> control the behaviour of java.util.Map views (not yet committed).
>
>
>The only "real metadata" example available at this time is
>DefaultCitation. However the ~100 other metadata classes would be
>similar to DefaultCitation, after the MetadataStandard /
>AbstractMetadata / ModifiableMetadata foundation are sound enough. If
>there is any thing to revisit, please let me know (the above classes are
>not final, and tests are not yet committed).
+1 sounds good to me.
>
>Some aspects that I'm considering to revisit are:
>
> * Synchronization strategy: if one looks at DefaultCitation, we can
> see that all all getter and setter methods are synchronized. I'm not
> sure that it is the more appropriate choice... Alternatives are no
> synchronization (not necessarily a bad idea, it really depends how
> we use metadata), or synchronization using
> java.util.concurrent.lock.ReadWriteLock. The later approach is more
> costly, so it could be selected only if the metadata are used in a
> way that justify it. I don't have a clear answer to this question
> yet. I'm trying to investigate how metadata are actually used in the
> projects I'm aware of, in the hope to figure out what could be the
> most appropriate synchronization strategy.
I would be in favor of no synchronization yet. Let's let concrete use
cases
drive the implementation of potentially complex and possibly costly
behavior.
Until we have one, let's just keep it simple for now.
> * "Intelligence" in metadata: right now, the metadata implementations
> are just containers. However relationship exists between some ISO
> 19115 elements. For example the ISO 19115-2 MI_Platform.instrument
> property [2] is a collection of instruments mounted on the platform,
> and each instrument has a MI_Instrument.mountedOn property [3] which
> point back to the platform on which the instrument is mounted.
> Obviously setting the MI_Platform.instrument property has
> implication on MI_Instrument.mountedOn, and conversely. There is
> many other places in ISO 19115 metadata where one property could be
> inferred from other properties. But Geotk does not have any
> "intelligence" like that. I'm thinking about, possibly, putting such
> "intelligence" in SIS. However sometime trying to be too clever is
> counter-productive, the risk being that some rules may be too
>arbitrary.
Yep we have relationships like this in the Tika Metadata object (creating
a new
Metadata object creates an internal object, which in turn needs to be
mapped back to the
parent metadata object). These reflexive relationships make sense to add
intelligence
to set the appropriate hooks.
+1 to that.
Cheers,
Chris
>
>
>I'm not really looking for an immediate answer to the above. They are
>questions that may be explored progressively. But though are always
>welcome.
>
> Martin
>
>
>[1]
>https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/metadat
>a/package-summary.html
>[2]
>http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Platfor
>m.html#getInstruments%28%29
>[3]
>http://www.geoapi.org/3.0/javadoc/org/opengis/metadata/acquisition/Instrum
>ent.html#getMountedOn%28%29
>