How to structure standards page?

[peterdesmet]

@baskaufs the new TDWG website will have pages for (at least the current) standards. Question:

1. Should these pages be the landing pages for these standards?

   • Advantage: one place to control this information + still possible to dereference for machine-readable content
   • Disadvantage: requires specific format that might be less inviting for newcomers. On the other hand, I'm not what the page should contain if it is not a landing page + I guess we can always add info to the required content.

2. If we decide that these are landing pages, how would you structure the required information? See for example this page as a first attempt for the SDS page.

[baskaufs]

@peterdesmet I think that it makes sense to have the standards landing pages be on the regular TDWG website. My main reason is that I'm a big fan of not changing IRIs nor breaking web links. For years, we have advertised IRIs of the form http://www.tdwg.org/standards/147 (i.e. in the www.tdwg.org subdomain) as the "permanent URL" for the standard. So I think we should take that seriously and make the standards landing pages dereference to the pages on the TDWG website (implied by the "www" even if that actually gets masked, although probably it shouldn't be since the current website URLs have it).

For the sake of simplicity, the IRIs for all of the other metadata pages that the SDS says should exists probably should, be in the rs.tdwg.org subdomain. For vocabulary terms, that's already the case (ac:, dwc:, and dwciri: namespace terms). The advantage of that would be that a single server script could generate all of the required pages in all of the require serializations (including HTML). For dereferencing of current DwC and AC vocabulary terms, they could redirect to the current style of quick reference guides, but the many obsolete terms, term lists, vocabularies, versions, and other stuff that practically no human will actually look at very often, the script could generate minimal, boring HTML about them. At least, that's how I've been thinking about it.

I agree with you that you could put other stuff on the landing pages besides what is required. But realistically, I don't think it matters a lot because I think in the future, most people will be going to the quick reference guide or something similar to actually look stuff up. People will probably land on the landing pages less often, and if they do, a prominent feature probably should be a link to direct them to the quick reference guide. For the standards that are mostly comprised of documents, the landing page should list how they can be accessed in various formats (i.e. distributions).

I've actually spent a lot of time in the last week gathering information about the old "prior" standards, such as author URIs, various versions, how the actual documents can be accessed, etc. I'm not quite done with it yet, but maybe I will be by next week. I think I'll have a clearer picture of what needs to be on those pages when I'm done with that.

I'm not sure how one would handle the machine-readable dereferencing for the standards landing pages on the web site (www.tdwg.org). Probably there could just be static pages for them in JSON-LD, RDF/XML, and Turtle since they wouldn't change much. So if the content negotiation could be handled, it wouldn't be that hard to serve static files.