Dear colleagues
as follow up of what Javier suggested to keep in contact with OGC, I also wanted to draw your attention that there is the EU Inspire Initiative : http://www.ec-gis.org/inspire/
INSPIRE PROPOSAL
Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL establishing an infrastructure for spatial information in the Community (INSPIRE) {SEC(2004) 980} (presented by the Commission)
I have subscribed to their mailing list earlier this year. There were not many mails in the begining, but lately I received the outcomes of their first big meeting. As far as I could judge they comply to OGC standards. I might thus be interested to keep an eye on this too ... http://www.ec-gis.org/inspire/reports.cfm
Regards
Pat
Renato De Giovanni renato@cria.org.br wrote: Hello Javier,
We did try to point out some reasons for not using WFS in the protocol integration report, but I'm not sure if that was explicit enough. From your list below I believe only the last two reasons are true.
Remember that one of the reasons for the existence of BioCASe was that ABCD wanted to be something completely independent (DarwinCore elements need to extend abstract protocol elements from DiGIR). By using WFS, ABCD would probably need to be split into one or more "feature types" and it would not be independent anymore. This issue is very well-described in the first link that Roger sent us yesterday when it talks about composability.
Besides that, what would be the best candidate for a feature in ABCD? Probably the "unit". And in this case, how could WFS return metadata about a collection of "unit features" as part of a search response? Maybe there's some way to do this by extending the WFS protocol, and I'm not sure how much work would be involved. But that's something we haven't even considered during the integration process. We mainly concentrated on the possibility of using WFS exactly as it was.
For other standards like SDD and TCS I really can't imagine people changing the schemas into small pieces of data and making all of them inherit from GML features - unless there's some very strong reason for that.
Another important difference at that time was that WFS couldn't produce custom structures, as it was possible with DiGIR and now with the optional custom output models in TAPIR.
I think these were the main reasons (including the absence of inventories, as Markus mentioned).
Anyway, I think it's important to have this kind of interaction with them and to always keep checking if there's any possibility to better integrate the two initiatives and to share code, knowledge, etc.
Regards, -- Renato
On 28 Nov 2005 at 16:39, Javier de la Torre wrote:
Dear all,
I am still sending emails with these guys working with OGC standards and some times I have difficulties to explain why we are not using WFS for sharing our data. I check at the report from Renato and Markus and did not find explicit reasons, but I will try to put mines and please let me know if you find other reasons why do you think WFS is not the way to go... For sure I do not mean WFS as it is right now, but extending WFS to meet our needs.
-OGC is a big consortium and it would be difficult to get our needs inserted in the standards. So if no one is going to worry about how we extend why should we worry about following them.
-With WFS we would have to adapt our schemas to GML application schemas (that is substitution groups and we have to extend AbstractFeautureType). We would not like to have to change our standards described in XML schemas.
-Standards like SDD can not make use of GML, mainly because WFS is a service for retrieving features of one single thing and not the relations between them.
Do you agree with that or you want to add more reasons?
Thanks.
Javier.
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
--------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free.