Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Not All Properties Contain Types #487

Closed
8 tasks done
kchason opened this issue Sep 29, 2022 · 1 comment · Fixed by #490
Closed
8 tasks done

Not All Properties Contain Types #487

kchason opened this issue Sep 29, 2022 · 1 comment · Fixed by #490
Labels
bug
Milestone
UCO 1.1.0

Comments

@kchason
Copy link
Contributor

kchason commented Sep 29, 2022 •
edited by ajnelson-nist
Loading

Untyped Properties in UCO

During the generation of automated CASE Bindings, it was discovered that 2 properties do not contain types and per discussion with @ajnelson-nist, default to an unrestricted range.

These properties are:

Coordination

  • Tracking in Jira ticket OC-280
  • Administrative review completed, proposal announced to Ontology Committees (OCs) on 2022-11-07
  • Solution announced to OCs on 2022-11-07
  • Solutions Approval to be discussed in OC meeting, 2022-11-17
  • Solutions Approval vote occurred, passing, on 2022-11-17
  • Solutions development phase completed.
  • Implementation merged into develop
  • Milestone linked
  • Documentation logged in pending release page
@kchason kchason added the bug label Sep 29, 2022
@ajnelson-nist ajnelson-nist added this to the UCO 1.0.1 milestone Oct 11, 2022
@kchason kchason mentioned this issue Oct 12, 2022
Merged
11 tasks
@ajnelson-nist ajnelson-nist linked a pull request Nov 7, 2022 that will close this issue
Issue 487: Property Type Updates #490
Merged
11 tasks
ajnelson-nist added a commit to kchason/UCO that referenced this issue Nov 7, 2022
@ajnelson-nist
Add missed datatype constraints, and adapt from contextual properties
347b3e0 
The previous patch noted `observable:byteStringValue` had no associated
range on the property definition, and assigned `xsd:string`.  Likewise,
`observable:destinationFlags` received a range of `xsd:string`.

This patch makes two overriding assignments.

First, `xsd:base64Binary` is now ranged `observable:byteStringValue`,
due to another associated property in the class using this property
(`ExtractedString`).  `observable:stringValue` already uses
`xsd:string`.  It did not seem appropriate to also use `xsd:string` on
a property for representing byte strings.

Note that base64binary's lexical space is defined in XML Schema
Datatypes to use the alphabet in Section 3 of RFC 3548.  In other words,
the alternative "URL and Filename Safe Alphabet" is not supported by XML
Schema Datatypes, hence neither by OWL, hence neither by UCO.

Second, `destinationFlags` is used on `TCPConnectionFacet`, alongside a
property `sourceFlags` that has a datatype cstraint of `xsd:hexBinary`.
To maintain symmetry with the "nearby" property, `destinationFlags` will
use `xsd:hexBinary`.

It is fair to raise a concern of introducing both OWL "Binary" datatypes
in this patch.  However, the user-experience estimation is that the flag
fields will often be short data payloads, while the extracted string
fields could carry more heft than would be appropriate to bear with
`xsd:hexBinary`.

No effects were observed on Make-managed files.

References:
* https://datatracker.ietf.org/doc/html/rfc3548#section-3
* https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#base64Binary
* https://www.w3.org/TR/owl2-syntax/#Binary_Data
* ucoProject#487

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist ajnelson-nist modified the milestones: UCO 1.0.1, UCO 1.1.0 Nov 7, 2022
ajnelson-nist added a commit to casework/CASE-Archive that referenced this issue Nov 7, 2022
@ajnelson-nist
Bump UCO unstable pointer
2769fa8 
No effects were observed on Make-managed files.

References:
* ucoProject/UCO#487

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/CASE-Examples that referenced this issue Nov 7, 2022
@ajnelson-nist
Bump unstable pointers
273cd15 
No effects were observed in Make-managed files.

References:
* ucoProject/UCO#487

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Nov 7, 2022
@ajnelson-nist
Bump UCO unstable pointers
11da953 
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#487

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
ajnelson-nist added a commit to casework/casework.github.io that referenced this issue Nov 7, 2022
@ajnelson-nist
Regenerate Make-managed files
675ad05 
References:
* ucoProject/UCO#487

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>
@ajnelson-nist
Copy link
Contributor

We will treat this as a fast-track vote, rather than a bugfix. What nudged it just over the line for me was:

  • In a broad sense, adding constraints where there were none before is a backwards-incompatible change. Users no longer have total freedom to supply anything they want in those properties, such as "☃" (unicode snowman) for observable:destinationFlags. But, absence of a constraint was a bug.
    • Do we have any community members interested in posting a UCO review shape to catch this class of bug---that is, confirming that every owl:DatatypeProperty has a range, and that there is at least one sh:PropertyShape with that range as a constraint? (Any who try this should limit the review to be for rdfs:ranges that are IRIs, not blank nodes.)
  • Looking at the datatypes supplied in the PR's first patch, I saw fit to use other datatypes, including one UCO has not used to date. See this commit for documentation.

So, we should have a chance to discuss this before voting in the fix for the missing-constraints bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
UCO 1.1.0
Development

Successfully merging a pull request may close this issue.

Issue 487: Property Type Updates kchason/UCO
2 participants
@kchason @ajnelson-nist