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.

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

Inference logic requirements are vague #259

Open
kelvinqian00 opened this issue Jun 9, 2022 · 1 comment
Open

Inference logic requirements are vague #259

kelvinqian00 opened this issue Jun 9, 2022 · 1 comment

Comments

@kelvinqian00
Copy link

kelvinqian00 commented Jun 9, 2022

The section Part Three: Communication and Processing describes requirements for inference logic to be implemented by Profile Servers:

A Profile Server will include inference logic for the following, at minimum: all SKOS predicate relationships, and profile:concepts, profile:templates, and profile:patterns being subproperties of the inverse of skos:inScheme.

However, these requirements are currently vague and/or impractical.

  • This sentence can technically be interpreted in two ways (and while common sense would favor one interpretation, it should not be this vague in the spec):
    • "(all SKOS predicate relations should be implemented) AND (profile:concepts, profile:templates, and profile:patterns should be subproperties of the inverse of skos:inScheme)"
    • "all SKOS predicate relations AND profile:concepts AND profile:templates AND profile:patterns should be subproperties of the inverse of skos:inScheme."
  • A logical interpretation of "profile:concepts, profile:templates, and profile:patterns being subproperties of the inverse of skos:inScheme" would entail that the inferencer should add (for example) the triple <conceptId> skos:inScheme <profileId>. Is this the intent of that phrase? If so, it would be clearer to state that explicitly; if not, it would be useful to give a concrete example of the intended inference.
  • What exactly is the intent of all SKOS predicate relationships being inferred? Assuming that this means "applying any and all entailments from the SKOS model as inference rules," trying to implement this may cause practical implementation issues:
    • Applying the rule A skos:related B -> B skos:related A* (as well as similar ones for skos:broader and skos:narrower) would add inferred triples that are indistinguishable from triples added by the author.
    • Rules such as A skos:relatedMatch B -> B skos:relatedMatch A** will affect Concepts in multiple graphs.
    • Should rules for non-relational predicates like A skos:definition B -> A skos:note B*** be implemented?

As such, I believe this sentence should be expanded into its own section on inference requirements, with an explicit list of inference rules that MUST be implemented and preferably with some examples.

Entailments from the SKOS specification:
* S23: skos:related is an instance of owl:SymmetricProperty
** S44: skos:relatedMatch is an instance of owl:SymmetricProperty
*** S17: skos:definition is a subproperty of skos:note

@andyjohnson
Copy link
Collaborator

Per our July 19th, 2022 meeting, we also aren't seeing a ton of value in the SKOSs predicate relationships. I would be curious if anyone has a use case where there is value in classifying these within xAPI Profiles, especially to the point of requiring SKOs relationships.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants