Data model conflates list operators with lists

[msporny]

The data model currently does not follow naming conventions used by other VCs. For example:

ListOperatorInformation: Provides a set of information about the owner of the trusted list.

Why is the issuer property not used for this value?

TSLVersionIdentifier: Specifies the version of the trusted list format.

This conflates the list format with the issuer. The change suggestion in https://github.com/w3c-ccg/verifiable-issuers-verifiers/pull/29/files#r2308310350 would effectively mean "This issuer has a list format of", which seems like the wrong way to model this information. The context will already provide the format information to anyone looking at the credential.

TSLSequenceNumber: Sequence number of the trusted list, starting at 1, incremented at each release. It shall not be re-cycled to "1" or to any value lower than the value of the trusted list currently in force.

Again, conflates the list information with the issuer/list operator information.

TSLType: Specifies the type of the trusted list. For lists that conform to this specification it shall be set to "https://w3c.org/ccg/TSLv1".

Conflates list type with context URL, which already provides the type and version.

ListOperatorName: Name of the entity responsible for establishing, publishing, signing, and maintaining the trusted list.

Why was schema.org/name not used?

ListOperatorAddress: Postal address of the legal entity or mandated organization identified by the list operator name.

Why was schema.org/address not used?

LOElectronicAddress: Email address of the list operator.

Why was schema.org/email not used?

LOWebSite: Website URI of the list operator.

Why was schema.org/url not used?

ListName: Name under which the list operates.

Why was schema.org/name not used?

ListInformationURIs: Set of URIs for obtaining list-specific information, such as its scope, context, policies, rules, etc.

Conflates information about the list with information about the list operator. Why was a set of URLs not re-used? This seems to be human-readable information and thus not largely helpful to a system.

ListTerritory: Country or territory where the trusted list is established, preferably as ISO country codes.

Conflates information about the list with information about the list operator. This also presumes that geographical boundaries are how applicability of a list is determined. This is just one consideration -- and is why JSONSchema was used to do the matching (far more flexible) than attempting to establish applicability based on region.

PolicyOrLegalNotice: Policy or legal notice concerning the list's status or legal requirements.

Conflates list with list operator. If this is not machine readable, it's likely to cause problems as it's not clear if one can use the list or not without greater ramifications.

IssuedAt: UTC date/time when the trusted list was issued.

Conflates list with list operator. Why was validFrom not used?

NextUpdate: UTC date/time by which an update of the trusted list will be available, or null for a closed trusted list.

Conflates list with list operator. Why was validFrom not used?

DistributionPoints: Locations where the current trusted list is published and where updates can be found.

This should be expressed via the id field for the list.

... and so on. The current data model has some fundamental problems that, if not addressed, will lead to a bad fit with the VC ecosystem.

[David-Chadwick]

The data model currently does not follow naming conventions used by other VCs. For example:

ListOperatorInformation: Provides a set of information about the owner of the trusted list.
Why is the issuer property not used for this value?

Two points. First this object specifies information about both the list operator and the list. So the top level object could be named "ListInformation" rather than "ListOperatorInformation", but then you might argue why is information about the list operator included in the ListInformation object. So do you have a better name for the top level object? Second, the term issuer refers to the issuer of the verifiable credential who is being mentioned in a trusted list i.e. a list subject. Remember that this is a data model. So different terms are needed for the subject in the list and the owner/operator of the list. It is not appropriate to use the term issuer to refer to two different entities.

TSLVersionIdentifier: Specifies the version of the trusted list format.
This conflates the list format with the issuer. 
The change suggestion in https://github.com/w3c-ccg/verifiable-issuers-verifiers/pull/29/files#r2308310350 
would effectively mean "This issuer has a list format of", which seems like the wrong way to model 
this information.  The context will already provide the format information to anyone looking at the credential.

It is anticipated that there may be different list formats standardised as the work evolves. So a list operator may have several standard list format versions to choose from. Hence this field.

TSLSequenceNumber: Sequence number of the trusted list, starting at 1, incremented at each release. 
It shall not be re-cycled to "1" or to any value lower than the value of the trusted list currently in force.

Again, conflates the list information with the issuer/list operator information.

Not so, because the top level object contains information about both the list and the list operator.

TSLType: Specifies the type of the trusted list. For lists that conform to this specification it shall be set to 
"https://w3c.org/ccg/TSLv1".
Conflates list type with context URL, which already provides the type and version.

It is true that we have included the version number in the type of the trusted list. So one could argue (as you have done) that the version data is duplicated. But there is no rule mandating that the version number must be in the type field. We could add a rule to this effect, and then remove the "TSLVersionIdentifier". But we have done it this way to be consistent with the existing ETSI standard.

ListOperatorName: Name of the entity responsible for establishing, publishing, signing, and 
maintaining the trusted list.
Why was schema.org/name not used?

Because the schema.org/name is too generic and does not provide any semantics for the name. The name of who or what? The list or the list operator?

ListOperatorAddress: Postal address of the legal entity or mandated organization identified by 
the list operator name.
Why was schema.org/address not used?

Ditto above.

LOElectronicAddress: Email address of the list operator.
Why was schema.org/email not used?

Ditto above

LOWebSite: Website URI of the list operator.
Why was schema.org/url not used?

Ditto above

ListName: Name under which the list operates.
Why was schema.org/name not used?

Ditto above. You have now answered your own question by wanting two properties to be given the same name

ListInformationURIs: Set of URIs for obtaining list-specific information, such as its scope, 
context, policies, rules, etc.
Conflates information about the list with information about the list operator. 

Remember that the top level object is meant to contain information about both the list and the list operator

Why was a set of URLs not re-used? This seems to be human-readable information and thus not
 largely helpful to a system.

Sorry I dont follow this comment.

ListTerritory: Country or territory where the trusted list is established, preferably as ISO country codes.
Conflates information about the list with information about the list operator.

As already stated this is intentional.

 This also presumes that geographical boundaries are how applicability of a list is determined. This is just one 
consideration -- and is why JSONSchema was used to do the matching (far more flexible) than 
attempting to establish applicability based on region.

In Europe, where the ETSI standard was produced, then the lists are country based. So perhaps this is an example of where the EU focus of ETSI is not appropriate for a W3C standard.

PolicyOrLegalNotice: Policy or legal notice concerning the list's status or legal requirements.
Conflates list with list operator. If this is not machine readable, it's likely to cause problems 
as it's not clear if one can use the list or not without greater ramifications.

This document does not say whether the notice is machine readable or not. That is up to the users of this document to decide.

IssuedAt: UTC date/time when the trusted list was issued.
Conflates list with list operator. Why was validFrom not used?

Because this is what ETSI uses. But we can easily change it to validFrom.

NextUpdate: UTC date/time by which an update of the trusted list will be available, 
or null for a closed trusted list.
Conflates list with list operator. Why was validFrom not used?

Can easily change to validFrom.

DistributionPoints: Locations where the current trusted list is published and where updates can be found.
This should be expressed via the id field for the list.

There currently is no id field defined for the list. Also id and location are two different concepts. So please do not conflate them. I have an ID but my location is not fixed.

... and so on. The current data model has some fundamental problems that, if not addressed, will lead to a bad fit with the VC ecosystem.

It is greatly appreciated that you are providing comments on this draft data model, and we would expect the VCWG to change the data model considerably once many more experts review it and want their various requirements to be met. Your comments are hopefully the first of many.

[David-Chadwick]

This issue was discussed at the meeting on 3 September 25 and there was agreement that separating the multi-type top level object (of list operator and list) into two separate peer top level objects would resolve this issue (although it would break with the existing ETSI model).

[TallTed]

@David-Chadwick —

Please revisit your #35 (comment), and change the markup. Using codefences (```, or `, or 4-(or more)-spaces, or a tab) to quote prior comments often (as in this case) makes those comments more difficult if not impossible to read. Also note, GitHub does not persist codefences to a "quote reply" (found in the 3-dot menu at upper right of each comment).

Please use the > quote marker, as you would in email, with multiple instances indicating deeper quotes (e.g., > 1, > > 2, > > > 3). (Also note, if you had used the "quote reply" option, this would have been handled for you -- double-quoting your original comment, single-quoting @msporny's reply to you.)

[David-Chadwick]

@TallTed I find it OK to read my comments on Manu's issues. So I do not propose to make the edits. Also this issue is virtually resolved since we understand the problem and the solution