Make editors configurable

[BigBlueHat]

First, @iherman thank you for building this tool!

Second, would you want to see editorial info for the vocabulary provided in the vocab section of the YAML? And if so, do you have a preferred vocab for those terms?

Mainly, I'd like to avoid having a separate template file for each vocab.

The goal is to manage this information from the YAML: https://github.com/w3c/yml2vocab/blob/e39e64cde680dc6df6e1aeee4ff31b46c5328f01/example/template.html#L21-L39

[iherman]

Well... I do not believe we can have a single template file. There are vocabulary specific parts in the generated vocabulary files in HTML, and pushing all of them into the yml file is, in my view, a stretch. The most obvious example is the alternate text of the diagrams; if they are not in the template file, then they have to be in the yml file, although, strictly speaking, that is not part of the vocabulary specification.

The editors' list is a little bit simpler of course, but I am not sure it is worth the trouble to push that into the yml file (unless we want to add additional metadata about the editors into the turtle and json-ld versions of the vocabulary.)

[BigBlueHat]

I think the editor information existing in the other exports would be nice, but agree about the fact that it may still end up with a separate template file per vocabulary regardless.

Thanks for considering it!

[BigBlueHat]

Maybe we could use something like this file instead: https://github.com/w3c/vc-di-ecdsa-test-suite/blob/main/respecConfig.json

[iherman]

@BigBlueHat as promised, I gave it some thought. It is possible to extend the yml file by adding something like:

vocab:
  - id: cred
    value: https://w3.org/2018/credentials#
    editors: 
      - name: Manu Sporny
        affiliation: 
          name: Digital Bazaar
          url: https://digitalbazaar.com/
        id: http://manu.sporny.org/
        w3cid: 41758
        note: "v1.0, v2.0"
      - name: Ivan Herman
        affiliation:  
          name: W3C 
          url: https://www.w3.org
        w3cid: 7382
        note: "v2.0"

then generate the respec header entry for editors, and add something like this to the vocabulary itself:

cred: a owl:Ontology ;
    dc:title """Verifiable Credentials Vocabulary v2.0"""@en ;
    dc:description """RDFS [[RDF-SCHEMA]] vocabulary used by the Verifiable Credentials [[VC-DATA-MODEL]]"""@en ;
    rdfs:seeAlso <https://www.w3.org/TR/vc-data-model-2.0/> ;
    dc:date "2023-08-12"^^xsd:date ;
    schema:editors (
        [
            schema:name "Manu Sporny" ;
            schema:affiliation [
                schema:name "Digital Bazaar" ;
                schema:identifier <https://digitalbazaar.com/>
            ] ;
            schema:identifier <http://manu.sporny.org/>
        ],
        [
            schema:name "Ivan Herman" ;
            schema:affiliation [
                schema:name "W3C" ;
                schema:identifier <https://www.w3.org>
            ] ;
            schema:identifier <http://www.w3.org/People/Ivan>
        ],
    )
.

To implement this? The most boring part is to extend the JSON Schema file (used for the checking of the yml file) to include the full vocabulary used by respec. Then part of the editors' entry should be converted into schema, and the converted data added to the exported ttl/jsonld versions. Finally, the respec structure for the template should be modified by adding the editors' name.

The only addition, to today's situation, is that the editors would be added to the exported ttl/jsonld part. As we agreed, the separate vocabulary-specific template file remains, that we cannot avoid (which was your initial motivation). The real question is: is this really worth it? Does any human really look at the ttl/jsonld version of the vocabulary? My prediction is that the answer to this question is: "no". After all, the role of the vocabulary is for RDF/OWL reasoners, not for humans. If any human really looks at the ttl/jsonld version to find such metadata, he/she might as well look at the HTML+RDFa version which contains that type of information and more.

So... I am unconvinced of the necessity of this, honestly.

[iherman]

I will close this. Having had this discussion, I do not think it is worth doing it; it does not add too much to what is necessary to be done anyway.