Linked Data Vocabulary as registry

[iherman]

(Originally raised by @samuelweiler in w3c/strategy#262 (comment); moved here with permission.)

It's good that defining algorithms is out of scope, but my experience is that the use of an algorithm requires a few words of explanation, much as https://w3c-ccg.github.io/security-vocab/#Ed25519VerificationKey2018 and https://tools.ietf.org/html/rfc8080#section-3 show "here's how we format the key". Typically I want those definitions to be in their own documents, so it's (relatively) easy to add new ones. (I also want them to be more well-defined than I see in https://w3c-ccg.github.io/security-vocab/) Which brings us to:

Registries. I haven't been following the recent Process changes around registries, but it looks like Linked Data Security Vocabulary (LDSV) is, in fact, a registry. Only it's a registry that contains the above explanation (albeit only by example). I think it might be better to create a registry - including specifying update criteria - and then create docs that populate initial values. In the IETF, it's possible to do both at once, creating the registry in the same doc that defines initial values (see the later paragraphs of https://tools.ietf.org/html/rfc5155#section-11: "This document creates a new IANA registry...")
I don't know that w3c's registry stuff will look like. Perhaps we should say, as a work/scope item: the WG will create a registry and populate initial values, without being clear what that document is going to be? @plehegar ?

[iherman]

You are right: the Linked Data Vocabulary is indeed a registry, even if the document does require some clean-up. And the non-normative deliverables section includes:

• A Linked Data Security Registry, containing Linked Data related cryptographic terms, including, but not limited to, terms used for RDF Dataset Canonicalization, Linked Data Proofs, and Linked Data Signatures.

The question may be whether this should be published as a normative specification (with an eye to the upcoming process changes) or remain non-normative. The reason we thought of keeping it non-normative is to avoid feature/focus creep in the charter; indeed, that document includes terms that are, strictly speaking, not related to signatures. Turning the registry into a normative one might be the subject of a continuation working group that would follow this one when its work is completed.

[iherman]

Looking at this again...

At present, we do have

• a (normative) deliverable for the Linked Data Security Vocabulary. The content of that deliverable is only to define the terms (classes, properties, etc) that are to be used to express a Linked Data Signature
• a (non-normative and optional) deliverable for a Linked Data Security Registry

Ideally one may consider merging the two documents into a "Registry" document as envisaged by the new process. However, at this point, it is not clear whether and how this would be possible.

To be very specific: Would it be acceptable to add a note into the charter into, say, the section on "Other Deliverables" saying something like:

If, during the chartered period of the Working Group, the next version of the W3C Process is adopted, incorporating the concept of a Registry Track, the Working Group will consider publishing the Linked Data Security Vocabulary Recommendation with an additional Registry Section incorporating the terms planned in the Linked Data Security Registry.

Two questions:

1. @plehegar, @wseltzer: what say you? Would that be acceptable in a charter today?
2. @msporny @pchampin: are we ready for the extra effort to get there (ie, we would have to define the registry process "normatively")?

[pchampin]

I don't think that the whole vocabulary is supposed to be a registry (a large part of it will be "closed", I expect), but obviously some part of this vocabulary will be open for extensions, and should use the Registry Track if that's possible at this stage.

[iherman]

I don't think that the whole vocabulary is supposed to be a registry (a large part of it will be "closed", I expect), but obviously some part of this vocabulary will be open for extensions, and should use the Registry Track if that's possible at this stage.

This becomes a detail but... a registry document would play two roles:

1. Be the place where new terms can be added with a minimal necessary bureaucracy
2. Be the place where all terms are collected for an easy reference to end users

In this respect, adding normative terms to the registry (clearly marked as normative) probably a good idea.

But we are running way ahead here...

[samuelweiler]

As in the opening comment, my expectation is that it is not enough to just have a list - a registry. Adding algorithms to such a list typically requires a (hopefully brief) specification, not of the mathematics, but of the details - things like padding, wrapping, maybe other data marshaling details. An example is https://tools.ietf.org/html/rfc4868. The WG may need to create both the registry and the (brief) specification docs that go with each entry in the registry.

I'm not sure if any change in the charter is needed for that, but could you (collectively) confirm that we're thinking along the same lines?

[iherman]

I do not believe the charter change is needed for this. The charter refers to the possible new W3C process to come, insofar as adopting the registry document concept. That requires more than just a list.

Regardless: yes, the registry is not just a list, it also has to have documentation of each feature (or a reference thereof).