[tdwg-tag] Final changes in TAPIR

[renato at cria.org.br]

Dear all,

There are just two items left on the list of possible changes before
submitting TAPIR to the TDWG standards track:

1) Allow custom operations to be declared as part of capabilities.

I would suggest to simply include a new custom slot for this in the schema
in case someone needs to use it in the future.

2) Allow dump files to be declared.

This has been discussed some time ago in the TAPIR mailing list but we
didn't come to a final conclusion.

Since some networks are starting to harvest data by fetching entire dump
files, I think it's important to allow TAPIR services to declare any dump
files that may be available. Fetching a dump file from a provider and
using incremental harvesting in later interactions with the service will
probably be the most efficient approach.

Since TAPIR generates XML output, it makes more sense to me to see dump
files in XML. However, Tim/Markus (GBIF) are proposing another format for
dump files using tab/csv files together with a metafile. It should be easy
to allow both options when declaring a dump file in TAPIR capabilities,
but I don't think it's the role of TAPIR to define specific formats. We
can probably use something like this to declare dump files:

<archives>
  <archive format="" location="" outputModel=""/>
  ...
</archives>

Where format could be "xml" or any custom term, and outputModel would be
optional (only used with "xml" format). Things like date when the dump
file was generated and whether it's gzipped or not could be additional
attributes, but in most cases this can be discovered through the protocol
used to retrieve the file, so in principle I would not include the
attributes.

Please let me know if this is an acceptable solution or if you have any
different thoughts. Also let me know if you have any other ideas or
suggestions about TAPIR in general. This is the time.

I would like to finally submit specification & schema to the standards
track in the beginning of the week.

Best Regards,
--
Renato


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.