tdwg / vocab

Vocabulary Maintenance Specification Task Group + SDS + VMS
11 stars 6 forks source link

Conventions for separating highly mutable components related to a standard #36

Closed baskaufs closed 8 years ago

baskaufs commented 8 years ago

I think there has been a consensus that highly mutable information should not be included within standards documents. This would include translation documents, links to ancillary materials, and URLs of endpoints or APIs that would be likely to change frequently. We have partially implemented this kind of separation in the DwC RDF Guide, which refers users to informative ancillary web pages and in the DwC Quick Guide, which refers users to the terms wiki.

In the draft, I've indicated that certain kinds of resources, such as translations and term labels in languages other than English, should be kept outside of the standards documents. However, I haven't successfully done that for access URLs for distributions (section 3.3.3.2). In the DCAT Recommendation, dcat:accessURL and dcat:downloadURL are included along with the other metadata for dcat:Distribution instances, so I included them in the list of metadata that should be provided for distributions. But probably those properties should be separated out in some way. How would we do that gracefully?

Does the specification need to be more specific about how links are to be made to ancillary documents and term labels in other languages?

see section 3.3.3.2

tucotuco commented 8 years ago

I think that if document maintenance allows for errata that do not have to go through an executive process, there is not much of an issue. There would not be a need to go through the standards process to keep links up to date.

On Sat, Apr 16, 2016 at 2:28 PM, Steve Baskauf notifications@github.com wrote:

I think there has been a consensus that highly mutable information should not be included within standards documents. This would include translation documents, links to ancillary materials, and URLs of endpoints or APIs that would be likely to change frequently. We have partially implemented this kind of separation in the DwC RDF Guide, which refers users to informative ancillary web pages and in the DwC Quick Guide, which refers users to the terms wiki.

In the draft, I've indicated that certain kinds of resources, such as translations and term labels in languages other than English, should be kept outside of the standards documents. However, I haven't successfully done that for access URLs for distributions (section 3.3.3.2). In the DCAT Recommendation, dcat:accessURL and dcat:downloadURL are included along with the other metadata for dcat:Distribution instances, so I included them in the list of metadata that should be provided for distributions. But probably those properties should be separated out in some way. How would we do that gracefully?

Does the specification need to be more specific about how links are to be made to ancillary documents and term labels in other languages?

see section 3.3.3.2

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/tdwg/vocab/issues/36

baskaufs commented 8 years ago

Here is some text from the 2016-05-04 meeting notes about this issue:

I have retained the requirement that standards documents be written in English. The text of Section 3.2.4 (Language) now reads:

“Standards documents must be written in English. Translations of standards documents are encouraged, but to simplify management of the standard they will be treated as ancillary documents that are not included in the standard.” The text of Sections 4.5 and 4.5.2 (regarding multilingual labels) has been left unchanged.

If standards documents and labels are translated into many languages (and I hope they are), requiring that all translations be immediately modified with every change to the standard introduces a burdensome requirement on the standards maintenance process - one that probably can’t be sustained given the volunteer nature of TDWG. With respect to changes in download and access URLs, as John W. said in his comment on issue #36, changes in those can be accomplished under an errata section of the change policy.