Hi Wouter,
Many thanks for raising these issues. I'll comment each one below...
-indexing preferences frequency in the documentation states @Frequency (starting with uppercase), the schema uses @frequency. I assume I have to implement @frequency.
You're right. I've just fixed the specification and I plan to release a new version during the next weeks.
-dc:language is mandatory. What to do with data that is not language specific? Example: we are going to use Tapir for sharing lists of scientific names. Should the language be Latin in that case? We think about using specifying English (eng) as default in that case. The recommendation is to use IANA Language subtags. Probably better to recommend the languages from ethnologue.org (3-letter abbreviations). This because the data can be in much more languages then the IANA Languages, for instance common names in extinct languages. This is different from the xml:lang attribute, which is primarily for application development.
I agree with you, and I think it should not be a problem for the existing applications if we make these changes:
- Make dc:language an optional element. - Change the cardinality of dc:language to "unbounded". - Change the recommendation about the content of dc:language by including ethnologue codes as another option (probably the main option). Note that it will still be just a recommendation, not a normative statement.
I'll wait to see if there's some feedback about this before making the changes.
-the example for an accesspoint is http://example.net/tapir.cgi I think this may be misleading, it would perhaps be better to use http://example.net/tapir.cgi/yourdatasource as example.
This one I think it's OK to keep it as it is. A TAPIR accesspoint is just an URL, so it's really up to the provider to decide which pattern to use.
Thanks again, -- Renato