[tdwg-tapir] OGC standards and TAPIR

Patricia Mergen p_mergen at yahoo.com
Wed Nov 30 08:59:31 CET 2005

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/
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 ... 

Renato De Giovanni <renato at 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 

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.


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 at lists.tdwg.org

 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20051129/19fed610/attachment.html 

More information about the tdwg-tag mailing list