pattern:PatternExpression is erroneously encoded as a datatype and class

[ajnelson-nist]

Bug description

The class pattern:LogicalPattern constrains the predicate pattern:patternExpression to have a "range" of pattern:PatternExpression [sic.].

https://github.com/ucoProject/UCO/blob/1.2.0/ontology/uco/pattern/pattern.ttl#L20-L35

pattern:LogicalPattern
	a
		owl:Class ,
		sh:NodeShape
		;
	rdfs:subClassOf pattern:Pattern ;
	rdfs:label "LogicalPattern"@en ;
	rdfs:comment "A logical pattern is a grouping of characteristics unique to an informational pattern expressed via a structured pattern expression following the rules of logic."@en ;
	sh:property [
		sh:datatype pattern:PatternExpression ;
		sh:maxCount "1"^^xsd:integer ;
		sh:nodeKind sh:Literal ;
		sh:path pattern:patternExpression ;
	] ;
	sh:targetClass pattern:LogicalPattern ;
	.

pattern:patternExpression (the predicate) is a owl:DatatypeProperty, so it is expected to have a range of some literal.

https://github.com/ucoProject/UCO/blob/1.2.0/ontology/uco/pattern/pattern.ttl#L59-L64

pattern:patternExpression
	a owl:DatatypeProperty ;
	rdfs:label "patternExpression"@en ;
	rdfs:comment "An explicit logical pattern expression."@en ;
	rdfs:range pattern:PatternExpression ;
	.

But, pattern:PatternExpression (capital P) is a owl:Class, not rdfs:Datatype:

https://github.com/ucoProject/UCO/blob/1.2.0/ontology/uco/pattern/pattern.ttl#L48-L57

pattern:PatternExpression
	a
		owl:Class ,
		sh:NodeShape
		;
	rdfs:subClassOf core:UcoInherentCharacterizationThing ;
	rdfs:label "PatternExpression"@en ;
	rdfs:comment "A pattern expression is a grouping of characteristics unique to an explicit logical expression defining a pattern (e.g., regular expression, SQL Select expression, etc.)."@en ;
	sh:targetClass pattern:PatternExpression ;
	.

This is an OWL 2 DL error. Classes cannot be datatypes, and datatype properties cannot have class ranges.

I came across this while trying to figure out how to use pattern:LogicalPattern to represent a regular expression substitution command, s/foo/bar/g.

To the original drafters of pattern:Pattern: How was this supposed to work? Can somebody please provide a demonstration for that s/... regular expression I gave above, from which we can go back and fix PatternExpression?

Steps to reproduce

Please see snippets above.

Requirements

Requirement 1

UCO's SHACL constraints must remain consistent with OWL design constraints, particularly around object properties versus datatype (literal-value) properties. (This is not a new requirement.)

Requirement 2

pattern:patternExpression and pattern:PatternExpression must be mutually consistent with one another. Currently, patternExression is a datatype property with range PatternExpression, but PatternExpression is a owl:Class, not rdfs:Datatype.

Risk / Benefit analysis

Benefits

Having pattern:PatternExpression established and stable will enable further "downstream" specialization. See e.g. #550 (under draft).

Risks

The pattern namespace was not demonstrated before being included in UCO 1.0.0. If a demonstration is not provided, it will be unclear if freshly-chosen design will be satisfactory.

Competencies demonstrated

Competency 1

Pending demonstration

Competency Question 1.1

Pending demonstration

Result 1.1

Pending demonstration

Solution suggestion

• Change pattern:patternExpression to an owl:ObjectProperty.
• Change corresponding SHACL constraints around pattern:patternExpression.
• Add test to find errant applications of sh:datatype attempting to constrain to owl:Classes.

Coordination

• Tracking in Jira ticket OCUCO-299

• Administrative review completed, proposal announced to Ontology Committees (OCs) on 2023-11-20
• Requirements to be discussed in OC meeting, 2023-11-28
• Requirements Review vote occurred, passing, on 2023-11-28
• Requirements development phase completed.
• Solution announced to OCs on 2024-05-01
• Solutions Approval to be discussed in OC meeting, 2024-05-30
• Solutions Approval vote occurred, passing, on 2024-05-30
• Solutions development phase completed.
• Backwards-compatible implementation merged into develop for the next release (N/A)
• develop state with backwards-compatible implementation merged into develop-2.0.0 (N/A)
• Backwards-incompatible implementation merged into develop-2.0.0
• Milestone linked
• Documentation logged in pending release page
• Prerelease publication: CASE develop branch updated to track UCO's updated develop branch (N/A)
• Prerelease publication: CASE develop-2.0.0 branch updated to track UCO's updated develop-2.0.0 branch

[ajnelson-nist]

It seems #550 is built on PatternExpression being an owl:Class. @sbarnum and/or @Bradichus , do you have input on this issue (562)? Should pattern:patternExpression be an owl:ObjectProperty?

[ajnelson-nist]

I suspect that this bug fix will be a backwards-incompatible change, because a property will need to change its OWL property-class. Thus, I'm putting it on the UCO 2.0.0 track.

[ajnelson-nist]

PR 566 has been filed to address this issue. The PR includes a test that detects this OWL+SHACL error pattern. Fortunately, the test only reports this one occurrence.

Note: 566 was written not having seen a demonstration of PatternExpression.

[ajnelson-nist]

Another note on the implementation in PR # 566 : It includes a new OWL test that UCO 1.x.0 fails, and can't be corrected in a backwards-compatible manner. I've not filed another PR to backport this test to 1.x.0 because, due to a logistical need for SHACL validation (where the ontology T-Box is necessarily mixed into the instance data A-Box), all runs of UCO's SHACL rules would report this error in the ontology, no matter the input data. This feels, to me, like a sufficiently unsatisfactory user experience that we should wait until UCO 2.0.0.

[ajnelson-nist]

@plbt5 requested in PR 259 on the CASE website that the new OWL shape get a description comment.

@plbt5 , how about:

uco-owl:sh-datatype-objects-shape
    sh:description "This shape enforces that the sh:datatype constraining predicate does not bind an OWL class for a literal-valued constraint."@en ;
    .

[ajnelson-nist]

A vote described in the meeting as a Solutions Approval vote was held 2023-11-28, and passed by the attending members.

However, in the email announcement, Jira tracking, and on the GitHub Issue, the pending vote was described to be a Requirements Review vote.

Because the solution is incomplete, I am going to “Split the difference” and consider this to be a passed Requirements Review vote.

The solution can’t be complete until the class being modified receives a demonstration.

[ajnelson-nist]

The solution from today's call:

• pattern:PatternExpression should be removed/permanently deprecated.
• The datatype constraint on LogicalPattern should be set to xsd:string.
• The rdfs:range on patternExpression should be set to xsd:string.

[ajnelson-nist]

@plbt5 requested in PR 259 on the CASE website that the new OWL shape get a description comment.

@plbt5 , how about:

uco-owl:sh-datatype-objects-shape
    sh:description "This shape enforces that the sh:datatype constraining predicate does not bind an OWL class for a literal-valued constraint."@en ;
    .

@plbt5 , do you have a response to this suggestion?

[plbt5]

Did I request documentation? That's so out of character.

…

On Wed, 1 May 2024, 16:37 Alex Nelson, ***@***.***> wrote: @plbt5 <https://github.com/plbt5> requested in PR 259 on the CASE website <casework/casework.github.io#259> that the new OWL shape get a description comment. @plbt5 <https://github.com/plbt5> , how about: uco-owl:sh-datatype-objects-shape sh:description "This shape enforces that the sh:datatype constraining predicate does not bind an OWL class for a literal-valued ***@***.*** ; . @plbt5 <https://github.com/plbt5> , do you have a response to this suggestion? — Reply to this email directly, view it on GitHub <#562 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAWGQOT64ONLRUG7IP5463ZAD42VAVCNFSM6AAAAAA7K2FVE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGU3DAMJVGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[plbt5]

Agree with suggested comment.

[ajnelson-nist]

Agree with suggested comment.

Added, thank you.