[tdwg-tapir] OGC standards and TAPIR
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.
Before we jump in bed with GML (which I have been in favour of in the past) it is worth looking at the other side.
This is an interesting article/opinion on GML:
And somewhere down this page is a blog by a guy talking to Ron Lake about getting RDF stuff in GML or visa versa which makes good reading.
http://danbri.org/words/category/general/
If we think about integration of technologies then it seems to me that we want to be able to plug into as many other domains as possible. If some one wants to pass information around about people or buildings or DNA along side herbarium specimen data then we should not make up a schema for it the user should be able to use any of a whole bunch of widely acceptable, cross domain ontologies/vocabularies. They should pick the one most suitable to them.
If we go with pure GML then we may end up having to invent or port things to it that aren't of interest to the geographic community. GML may be a bunch of cartographers trying to invent their own semantic web. GML applications may be nearly as far away from plugging in to "everything else" as we are.
So maybe a one night stand or an open marriage but not total commitment unless we can see a path to more generic W3C standards - is what I'm thinking at the moment.
All the best,
Roger
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
Hi all,
Do not misunderstand me. I did not want to mean that it could be a good idea to join the OGC and use their standards. I am in a parallel discussion with someone from the OGC community and I wanted to have some arguments...
In projects like Geoserver and in deegree (open source implementations of WFS) they have to deal with the same problems we have of mapping relational databases to user schemas (that is GML application schemas for them). It would be great to be able to share code and ideas with them, but I know this may be more work than not contact at all... They have already some OS libraries, like Geotools, for dealing with OGC protocols, in the same way we are going to create libraries for TAPIR. Being involved in bigger communities like this one could benefit us, right now there is no one apart of us interested in our software. But again I am not sure if this would not actually mean more work and less flexibility... and in any case we are probably too deep in our things to consider something like this, so I do not want to open this discussion and better concentrate in finishing what we have.
Just for your knowledge I have to say that I think we are more advance than Geoserver, at least, in solving the mapping problem :) Just for you to feel better jeje.
Javier.
On 28/11/2005, at 17:47, Roger Hyam wrote:
Before we jump in bed with GML (which I have been in favour of in the past) it is worth looking at the other side.
This is an interesting article/opinion on GML:
And somewhere down this page is a blog by a guy talking to Ron Lake about getting RDF stuff in GML or visa versa which makes good reading.
http://danbri.org/words/category/general/
If we think about integration of technologies then it seems to me that we want to be able to plug into as many other domains as possible. If some one wants to pass information around about people or buildings or DNA along side herbarium specimen data then we should not make up a schema for it the user should be able to use any of a whole bunch of widely acceptable, cross domain ontologies/ vocabularies. They should pick the one most suitable to them.
If we go with pure GML then we may end up having to invent or port things to it that aren't of interest to the geographic community. GML may be a bunch of cartographers trying to invent their own semantic web. GML applications may be nearly as far away from plugging in to "everything else" as we are.
So maybe a one night stand or an open marriage but not total commitment unless we can see a path to more generic W3C standards - is what I'm thinking at the moment.
All the best,
Roger
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
--
Roger Hyam Technical Architect Taxonomic Databases Working Group
http://www.tdwg.org roger@tdwg.org
+44 1578 722782
Javier,
I wasn't meaning to suggest not cooperating with OGC based technologies, sharing code/applications etc - this would all be great. My comments were more high level about how we represent our knowledge domain and that we shouldn't compromise on interoperability. If we were to re-tool our standards then I am not convinced at the moment (though the jury is still out) that we should re-tool them to GML.
All the best,
Roger
Javier de la Torre wrote:
Hi all,
Do not misunderstand me. I did not want to mean that it could be a good idea to join the OGC and use their standards. I am in a parallel discussion with someone from the OGC community and I wanted to have some arguments...
In projects like Geoserver and in deegree (open source implementations of WFS) they have to deal with the same problems we have of mapping relational databases to user schemas (that is GML application schemas for them). It would be great to be able to share code and ideas with them, but I know this may be more work than not contact at all... They have already some OS libraries, like Geotools, for dealing with OGC protocols, in the same way we are going to create libraries for TAPIR. Being involved in bigger communities like this one could benefit us, right now there is no one apart of us interested in our software. But again I am not sure if this would not actually mean more work and less flexibility... and in any case we are probably too deep in our things to consider something like this, so I do not want to open this discussion and better concentrate in finishing what we have.
Just for your knowledge I have to say that I think we are more advance than Geoserver, at least, in solving the mapping problem :) Just for you to feel better jeje.
Javier.
On 28/11/2005, at 17:47, Roger Hyam wrote:
Before we jump in bed with GML (which I have been in favour of in the past) it is worth looking at the other side.
This is an interesting article/opinion on GML:
And somewhere down this page is a blog by a guy talking to Ron Lake about getting RDF stuff in GML or visa versa which makes good reading.
http://danbri.org/words/category/general/
If we think about integration of technologies then it seems to me that we want to be able to plug into as many other domains as possible. If some one wants to pass information around about people or buildings or DNA along side herbarium specimen data then we should not make up a schema for it the user should be able to use any of a whole bunch of widely acceptable, cross domain ontologies/ vocabularies. They should pick the one most suitable to them.
If we go with pure GML then we may end up having to invent or port things to it that aren't of interest to the geographic community. GML may be a bunch of cartographers trying to invent their own semantic web. GML applications may be nearly as far away from plugging in to "everything else" as we are.
So maybe a one night stand or an open marriage but not total commitment unless we can see a path to more generic W3C standards - is what I'm thinking at the moment.
All the best,
Roger
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
--
Roger Hyam Technical Architect Taxonomic Databases Working Group
http://www.tdwg.org roger@tdwg.org
+44 1578 722782
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
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.
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.
participants (4)
-
Javier de la Torre -
Patricia Mergen -
Renato De Giovanni -
Roger Hyam