Hi Luca:
I have replied inline - thanks for taking the time to look at this. If
it helps you can check out the source code and
try creating a few test cases.
This is a good time for us to be talking about the design and making
sure it meets your needs.
Hi all,
today I discussed with Paolo Rizzi about the possible problems which
might arise when using our metadata infrastructure model against the
latest GML specs and the latest developements/proposals from you on
Feature /FeatureType/schema model.
I updated the following page with a brief explanation of the metadata
model we used to develop all the metadata infrastructure:
http://www.geotools.org/Meta+Information+Infrastructure
Thank you for that - I do need to ask one question - and it may come
down to a language difference between us.
You list the following GeoTools FeatureType limitations:
1. Primary keys
2. Associations between feature types
3. Inheritance between FT
As being the reason for your use of a Metadata model.
The language question is this. FeatureType *is* metadata about the
feature data. In addition applications also like to track *metadata*
about other aspects of the data (like keywords, description and so on).
Eventually we need the facility to handle both: FeatureType and
Application specific metadata.
I would like to confirm that if we fix these problems in GeoTools there
will be less work for your Metadata model to do?
And now for your list ....
1. Primary Keys
There is an interesting relationship between Primary Keys and FeatureID.
We have focused mostly on keeping the process of FID generation opaque,
and often primary keys used to generate the FID end up "hidden". The
thought being that FeatureID is supposed to handle this task.
2. Assoications
Gabriel also brought up this issue, and it is what getID is used for.
Specifically it was phrased in terms of "References", and was not
limitied to Features (a reference could also be to a Geometry). The
long and short of it was to capture Feature associations as a Choice
between a Feature and a Reference<Feature>.
3. Inheritance between FT
I think this one is well covered, we went with an "override" idea and
are providing guidelines for XMLSchema style extention and restriction.
This metamodel works fine with the old FeatureType/AttributeType ->
Feature/Attribute model.
You should be okay with the new system then, indeed when working with
simple content like shapefiles and databases you should not notice the
difference.
As this metadata model is widely used in our codebase for all the
schema & data handling / transaction / validation / catalog
operations, our main concern is keeping the greatest backward
compatibility, yet allowing for further enhancements of the model
like nested features, ChoiceSchemas, Complexes and so on -
enhancements who have been discussed recently and still are being
discussed.
We did have an IRC meeting in which we decided to break backwards
compatability in order
to fix the model. I would like to go halfway with you on this, set up
the old interfaces/implementations
as extentions of the new model and depricate them.
We may not be able to get 100% backwards compatibility (not should we
try), but offering a sensible
upgrade path will need to be part of the adoption plan.
At a first glance it seems that many contraints which come directly
from adopting GML specs, are likely to cause troubles - i.e. having
an ID at the Geometry (thus attribute) level, or allowing for
multiple instances of the same atomic attribute. In other cases a
mapping can be easily found - nested Features can be represented by
associations, for example.
It seems my description of associations was not required :-) I initial
had Geometry as a ComplexAttribute (as you can query it with XPath),
Gabriel asked me to make it extend Attribute and thus ID moved to
Attribute. AttributeType does record if ID is allowed to be null - that
is not all Attributes have/need an ID (and the Type system tells you so).
If we are willing to get into GeoServer / GeoTools all the work which
prizzi has done/ is doing on transaction and meta engine, we should
be sure that Feature model and metadata structure are compatible.
As mentioned above it is my hope that the two can compliment each
other. One of the reasons we did not know to talk to was a poor
assumption: I assumed you were fixing the "Application metadata problem"
- I did not know you were using it to "patch up" the holes in the
geotools feature model.
I like the idea of metadata giving us the ability to share different
views of the same data - like the ideas exposed for the
ComplexDataStore.
Hopefully Gabriel will have more to say on that side of things. Sharing
views on the same data is ill defined by the specifications right now -
they are supposed to have the same feature ID, even though the
FeatureType will be different (!)
In the next days (when I'll find the time, alas) I'll try to dig more
in the GML specs and in your proposals (I find hard to understand the
separation between Type and Schema), and see if we can tailor the
metadata model to the new specs in a painless way. Meanwhile, any
comment will be greatly appreciated.
Commented, one thing we can do (since both yourself and Gabriel are in
Europe), is set up a time for a break out IRC session. That is like a
geotools meeting, but less formal, and we can choose a time when it is
daylight for all of us.
Thanks for your feedback,
Jody
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
