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

Kinds as rdfs:subClassOf #196

Open
twalmsley opened this issue Feb 23, 2024 · 1 comment · May be fixed by #198
Open

Kinds as rdfs:subClassOf #196

twalmsley opened this issue Feb 23, 2024 · 1 comment · May be fixed by #198
Assignees

Comments

@twalmsley
Copy link
Collaborator

Instances of kind_of_X are new entity types, so as well as being rdf:type kind_of_X they should also be rdfs:subClassOf X.

E.g. for an instance of kind_of_organization the triples should be:

ex:1 rdf:type hqdm:kind_of_organization.
ex:1 rdfs:subClassOf hqdm:organization.
ex:1 hqdm:data_EntityName "National Government". # optional entity name

The ClassServices.createKindOfX() methods should add the rdfs:subClassOf X predicate.
Also, any entity that is a member_of_kind of, for example, ex:1 above, should also be rdf:type ex:1

E.g.:

ex:2 hqdm:member_of_kind ex:1.
ex:2 rdf:type ex:1.

This allows standard RDFS entailments to infer that:

  1. ex:1 is an rdfs:class
  2. ex:1 is of type hqdm:kind_of_organization and all its supertypes.
  3. ex:2 is of type organization and all of its supertypes.
  4. When read from a triple store by MagmaCore, ex:2 will implement the Organization interface and all of its super interfaces so instanceof Organization will be true and it can be cast to that type rather than simply being a Thing.

† I'm not sure how we enforce this, so some additional changes might need to be included to enforce this constraint, if it is even possible to do that.

@twalmsley twalmsley self-assigned this Feb 28, 2024
@twalmsley twalmsley linked a pull request Mar 1, 2024 that will close this issue
@twalmsley twalmsley linked a pull request Mar 1, 2024 that will close this issue
@twalmsley twalmsley changed the title KInds as rdfs:subClassOf Kinds as rdfs:subClassOf Mar 1, 2024
@GCHQDeveloper56
Copy link
Contributor

Sorry it as taken me a while to take a look at this. I agree that this is something we should be looking to address / accommodate. When Magma Core was originally created we took the decision to minimise reliance on external specifications to interpret/enforce the book from which we implemented the library. We tried to rely only on Developing High Quality Data Models by Matthew West, as documented except where there were errors, and implementing code that we had control over to assert what was documented. However, we did use RDF as we needed a database to store the records. One of the wrinkles that we introduced was using rdf:type. While this looks as if it is only part of the base RDF concept it is formally part of the RDF Schema (as linked). This was a compromise that gave the benefit of asserting a type-instance relation (types and their instances sound trivial, but turn out to be less-so). So, some questions for discussion:

  1. Are we happy relying on RDFS more?

  2. By using more of RDFS we open up the risk of RDF Semantics being adopted. This can introduce constraints that are not in accord with HQDM and ambiguity in interpretation (see the Elephant example in the RDF Primer. We already have this problem but will it cause additional issues?

  3. Another aspect of using the predicate rdfs:subClassOf is that it is also equivalent, in the way that Magma Core is implemented, to the EXPRESS "SUBTYPE OF" keyword (see it's use for the Entity Type organization. This is similar to the RDF version of HQDM you submitted to hqdmTop RDF. Is there a useful way to introduce these rdfs:subClassOf statements into MagmaCore all the way up to Thing?

I suggest that we discuss these. The changes you proposed look sound to me other than this.

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

Successfully merging a pull request may close this issue.

2 participants