Create a use case and requirement for "central" authoritative validation rules

[aisaac]

Created on request from @nicholascar for "generating a cogent Use Case in time for a 2PWD"

In w3c/dxwg#273 (between w3c/dxwg#273 (comment) and w3c/dxwg#273 (comment)) the notion of different levels of conformance was proposed, together with the idea that one of these levels is the 'most authoritative' one, which can be seen as a 'center' for validation rules.

[nicholascar]

I have proposed some Roles that might cover off on this, see this so-far un-merged branch of the Roles vocab:

https://raw.githack.com/w3c/dxwg/roles-update/profilesont/resource_roles.html

There, the 'central' validation rules might have the Role Full Constraints and then other non-central resources others. Note the narrower Concept of Full Constraints being Aggregated Constraints which, if present, would be 'more' central.

[aisaac]

@nicholascar the link above doesn't resolve!

Without seeing: yes a Role is probably a solution that meets the requirement. And I'm not sure that an Aggregated Constraints can be more central than Full Constraints, in fact I'd expect that Aggregated Constraints that are more central should probably be Full Constraints too ;-)

Anyway I guess the main question for now is, do we accept this new requirement?

[kcoyle]

I don't think this is a requirement that we can successfully define. Instead, I see this as something to be resolved in the future with a more complete definition of profiles. To me this is a basic weakness of the model, and I think a different model would be needed to resolve it.

As an example, a non-actionable PDF file could be considered the authoritative statement of the profile, and if "constraints" (full or otherwise) are expected to be actionable, then there is no way to say that the PDF is the authoritative statement of the profile. There also may be more than one file that is considered "full constraints" (i.e. both ShEx and SHACL and maybe Schematron), so "full constraints" cannot define the central authority.

I say we drop this entirely since I don't think we are prepared to develop a more comprehensive model. The relative meaning of the various resources in PROF will continue to be ambiguous.

[nicholascar]

@aisaac just use the gh-pages link now that the branch has been merged: https://w3c.github.io/dxwg/profilesont/resource_roles.html

Aggregated Constraints are just narrower than Full Constraints with Full Constraints serving as a ‘central’ constraints Resource.

I also removed Validation and Conformance Test which just duplicated Full Constraints in intention so now, for constraints, there is way to emulate centrality via completeness.

@kcoyle re your “non-actionable PDF” example: there is a Specification role and you can use that to indicate precisely what you described.

@kcoyle re multiple Full Constraints resources (ShEx, SHACL etc.): just use Full Constraints role multiple times! It’s just like a book with ONE title oh but it’s given in English and Dutch.

So I think the Roles approach works well here!

If we do as @aisaac suggests and move some roles into the Ontology document, we can include examples there of use to cover these cases.

[kcoyle]

@nicholascar I don't think you understand what we mean by "authoritative" - it comes out of library jargon, so maybe we haven't been clear. Out of any number of files that either describe, support or implement a profile (or anything else, for that matter) the authoritative one is the one whose content is the final word. It's THE standard that you go by. Let's say you have a profile, and it has a document which is authoritative (PDF, Word, XML, SHACL, ShEx, whatever). Then you create another file that also attempts to say what is in the authoritative file, let's say a SHACL file based on an authoritative PDF file. The rules encoded in the SHACL file are intended to be faithful renditions of the authoritative document. However, if there are questions about the content of the SHACL file you return to the authoritative document to determine what is correct. If there are differences, the meaning in the authoritative document is the "true" one. All of the supporting files to the profile are judged against the authoritative file. See also my response to Peter in email which explains why this would imply the need for intra-resource relationships - relationships between profile resources and the authoritative resource, and potentially relationships between the non-authoritative resources and each other when they have been derived in that way.

The specification role is not sufficient, because there can be multiple specifications; nothing about being a specification indicates the ONE authoritative source of information. This is also true for the role of full constraints. As for your "book with one title" - OMG, there is so much to say about the relationship between translations, but your analogy here does not hold; translations are not = original texts, and are not considered authoritative - as with going from a written, authoritative standard to something like SHACL or ShEx, there are always some minor or major differences from the original, which is why an authoritative version is so important.

I guess the easiest way to describe it is: among all of the resources in a profile graph, one must be the standard by which all others are judged so that there is a basis for quality control. Does that make sense?

[kcoyle]

I can't believe I missed the most obvious analogy/explanation: W3C recommendations. With normative documents (normative ~= authoritative), and non-normative examples, code, and translations. That's probably the easiest example to understand. With W3C standards it is always the case that for each standard there is one normative/authoritative document although there can be many other related files. Also analogous is that normative documents are rarely (if ever?) written as code, and that coded forms of the recommendation (such as the various forms of SHACL in ttl, JSON-LD, etc.; or the ttl that accompanies the DCAT-AP) are non-normative. Also, all W3C documents are written in English and all translations are non-normative.

So the concept of "authoritative validation rules" is really the same as the concept of W3C recommendations - that there is one and only one normative/authoritative version. In many cases it will be a language document. All other related versions are non-normative. I think that should make this idea clear, does it not?

This doesn't mean that PROF has to do this. In fact, as I say above, I think this is a fairly big issue and might well take PROF in a direction that it should not go - at least, not at this time. I think PROF represents a different line of thinking than what I've described (and we haven't begun to think through the implications!), and if it meets the needs of folks then there's no reason to force it in a different direction.

[nicholascar]

I get the general concept of authoritative (I work in a Federal government after all!).

The Geoscience Australia profile, of ISO19115-1, certainly has an authoritative resource: it's the PDF that is taken as absolute. Other resources like schematron validators, XSD schema & vocabs (code lists) exist too but they are subservient to the PDF.

So, a stab at a way forward:

• in Guidance we say something about a task for profile designers being to indicate which, of the potentially many resources in their profile, is authoritative
• then in the ontology we can create a new Role to indicate an authoritative resource with wording that aligns with Guidance
  This could simple be a new role called AuthoritativeSpecification or similar, if you expect Specification to invite multiple use

We could, although this might be difficult, specify in the ontology that if AuthoritativeSpecification is used, it can only be used once for a Profile thus avoiding intra-resource relationships if we want to avoid such things.

[nicholascar]

An addendum to my comment above: although we may specify a role for an authoritative resource and people may expect to use that with things like PDF, in our (CSIRO) data consulting to government, we are moving to get machein-redable versions of things to be the authoritative resources e.g. mining tenement reporting data submitted to the Queensland Geological Survey must validate against a SHACL shapes graph which is normative and the description of requirements, a PDF, is only informative.

This is perhaps a fundamental shift from English to formal languages for authority/conformance assessment.

[rob-metalinkage]

note that this doesnt affect the ontology - model works fine if (and only if) we retain the role classification of resources. This is why originally such roles are defined in a separate resource - but we could include some canonical terms for common roles in the ontology because we feel they will meet the majority of cases. We need to have a little sprint to define these... but the identified needs and use cases are met, noting more detailed use cases around different combinations of authority and completeness could be devised.

[kcoyle]

I still say we should not go there, and I still think that a suitable solution needs to be more than adding a role for "authoritative". Let's skip this and move on with what we have.

[nicholascar]

Moved to 3PWD Milestone for addressing later.

[nicholascar]

The vocabulary supports implementers creating a role for "central" authoritative validation rules but there is no motivating Use Case for this to be specifically addressed in the vocabulary itself therefore closing.

[aisaac]

@nicholascar any pointer on this? I'd be happy to review!

[aisaac]

@nicholascar actually whatever pointer you give I'm not sure we can close the issue based on that. There is no formal use case nor requirement (this was actually the goal of the issue: formalizing a need, not an answer!) so it's really tricky to close it.

Maybe we can be creative and follow @plehegar 's advice in today's call: how about marking the PROF features about 'authoritative' validation as a "feature at risk", documenting the fact that the use case and requirement couldn't be formalized in our UCR doc?

This could allow not to drop what's been done in PROF now, to document the rationale for it (via a pointer to this issue in PROF), to close this issue and to not endanger the fate of PROF in case the feature draws more criticism. And still to reflect that at least one of us (@kcoyle) has expressed strong reservation about it (which in turn could incite others to weigh in during the CR phase)

I also feels (but I may be wrong) that @kcoyle 's doubts on the relevance of the role discussed in the issue would be properly handled in the context of w3c/dxwg#1049 . I.e. I expect that w3c/dxwg#1049 could be used to decide on the fate of the role discussed here, even after we close this issue.

@nicholascar @rob-metalinkage @kcoyle @pwin is it something that we could live with?

[rob-metalinkage]

I think I can live with it - IMHO the roles should be a small set of uncontroversial ones and an extension mechanism - but its other people who keep wanting to see how to perform this function, and its a valid one. IMHO the problem is in debates going off track by continually mixing up the resources and the notional profile - rather than actually focussing on the roles resources have w.r.t. profiles in available examples.

[kcoyle]

To me this is more than a role issue in the sense that roles are being used in PROF; it is inherently an issue with the model of PROF. It has to do with whether there is any way to measure "correctness" between separate expressions of the profile. As I explain above, if I have a set of documents that could potentially harbor contradictions between them I have no way to establishing correctness if they are all of equal "truth". To me this is an inherent flaw in establishing a set of things to represent what is essentially designed to be a standard, rather than a dominant "true" thing with auxiliary items that can be measured against the standard. (This is analogous to the W3C practice of having only one version of a document considered the "true" document, usually the English-language one, and all others are considered non-standard.)

I'm not sure this can be a feature at risk because it speaks to the underlying model not a feature based on the model. If it can be shown that the current underlying model could support this, then I suppose it could be a feature at risk. As it is, I do not see that PROF supports a profile as a standard.

[rob-metalinkage]

@kcoyle - thats a matter for constraint languages - PROF is not attempting to reinvent that wheel but to model the relationships between such things and various expressions. Its model is demonstrably able to handle all the requirements that are identified for these relationships, and any measure of correctness or expressivity issues in constraints languages or guidance documents or any other useful resource is well and truly out of scope of the model.

does "support a profile as a standard" have any grounding in any identified requirement - i cannot hazard a guess at what it might mean. At this stage you have not identified any specific problem in the model against the requirements it is addressing .

[kcoyle]

No, it isn't a matter for constraint languages. W3C standards are not constraint languages - such as DCAT. The profiles in my environment often do not have constraint languages but are still considered standards.

[rob-metalinkage]

OK - this needs to be looked at differently:
a) W3C publishes several different constraint languages - some explicitly called constraint languages such as SHACL - and others which are specifications which constrain usages or semantics of other syntaxes - RDFS and OWL for example constrain the RDF model. anyway this really isnt worth arguing about because it doesnt change anything.

If your chosen "constraint language" is english, or some profile of it such as https://tools.ietf.org/html/rfc2119 - its (probably) not a machine readable one - but it may still express validatable constraints.

i agree with the comment "I say we drop this entirely since I don't think we are prepared to develop a more comprehensive model. "

and re-assert that I think this particular statement indicates the discussion has drifted off scope:
" It has to do with whether there is any way to measure "correctness" between separate expressions of the profile. As I explain above, if I have a set of documents that could potentially harbor contradictions between them I have no way to establishing correctness if they are all of equal "truth".

that said - i wonder if there is a better pathway to the a solution here:

1. "specification" role might be too hard to define and we drop it - people can always redefine it later because the model allows it - and frankly it doesnt add much canonical machine processing value.
2. add another property of resources to indicate "normative" vs "informative" - allowed to multi-valued and not disjoint so wordy documents that contain normative and informative clauses can be flagged as both

either way - this has little to do with the resolution of this issue - either such a Use Case is supplied or its not. This issue may be held open - but its not relevant to the 3PWD milestone now as no UC has been supplied in time. If anyone wants to pursue a specific improvement based on the discussions then open a new targetted issue for the improvement and generate a PR with a reviewable proposal and/or add it as an agenda item to the meetings.

[kcoyle]

This issue is indeed asking for a use case. However, what I have presented is a technical objection, much like the technical objection to "token" in conneg. Technical objections do not need use cases, so perhaps the title here is not ideal. Also, we are way beyond use cases at this point, but technical arguments have no deadline. I could put this in as a comment on the next publication. I'm not sure if I will do it individually, or perhaps in concert with a number of problems that DCMI has noted. In any case, I see a strong technical question to the concepts behind the design of the vocabulary, and I believe I can back up my views using examples like W3C standards (which arguments I believe you have misunderstood, based on your comments immediately above).

[nicholascar]

Removing "due-for-closing" uless @kcoyle decides to raise other issues for the points mentioned above and allow this to be closed.

[aisaac]

@nicholascar before the discussion drifts away, what do you think of my suggestions at https://github.com/w3c/dxwg/issues/597#issuecomment-527651215 ?