[tdwg-tapir] Minor changes
m.doering at bgbm.org
Fri May 18 17:59:58 CEST 2007
as you might have guessed all your proposed changes are fine with me.
Regarding the metadata variables I would make all existing metadata
values available as TAPIR variables. Maybe we can leave out the
indexing preferences. This would mean to add dc:subject,
dct:bibliographicCitation and dct:modified
I am not sure yet how you will retrieve metadata values for
RelatedEntities though. There might be multiple and do you have a
simple rule in mind what to do in that case? That's the case for all
On 15.05.2007, at 16:03, Renato De Giovanni wrote:
> Dear all,
> Yesterday I finally managed to produce valid ABCD output from an
> of TapirLink that has mapped DarwinCore concepts. It could be
> possible to
> achieve this before by using a simplified XML Schema for ABCD, but I
> wanted to use the official one. The corresponding output model
> (inside our
> repository under cs/dwc/1.4/models) still needs to include more
> between ABCD and DarwinCore elements, but it already works with the
> important concepts.
> One of the things that I needed to do was to create more environment
> variables to be used by output models, because there are mandatory
> elements in ABCD that don't correspond to any DarwinCore concept.
> they do correspond to TAPIR metadata elements.
> The current TAPIR specification recognizes the following environment
> I created these new ones in TapirLink, not only because of ABCD but
> for the RSS2 output model:
> If the specification doesn't include these variables, they will remain
> unofficial and this situation may not be good for future
> So one of the things I would like to suggest is to include these
> in the controlled vocabulary defined by TAPIR.
> Please let me know if this is OK and if you have more suggestions.
> (Markus, sometime ago there was the idea of including all TAPIR
> as environment variables so that they could also be returned in search
> responses, would you like to suggest more variables?).
> Remember that TAPIR environment variables are optional (providers
> need to support them) and extensible (providers can define new
> if they want to).
> Here are two other minor changes suggested to the protocol and
> raised by
> issues that were found during the development of TAPIR tools for
> the GISIN
> * Restrict POST requests to "application/x-www-form-urlencoded" (the
> default POST encoding). Reason: TAPIR requests can include multiple
> parameters with the same name ("concept" and "tagname" in the
> operation) but some languages like PHP cannot handle this properly
> - only
> the last parameter becomes available from the $_REQUEST global
> In these cases it is necessary to manually extract the parameters
> and this
> doesn't seem to be an easy task if POST is used with
> "multipart/form-data". Since this last encoding is mostly used for
> large quantities of binary data, which is definitely not the case of a
> TAPIR request, I think we can safely avoid it.
> * Include an optional attribute "alias" in output models and query
> templates that are advertised in capabilities responses. The CNS
> configuration file already allows aliases for output models and query
> templates, but these are not present in capabilities responses as it
> happens with concept and schema aliases.
> Please let me know if you have any comments, suggestions or
> objections to
> these changes, otherwise I'll take the liberty to make them in the
> few days.
> Best Regards,
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
More information about the tdwg-tag