search

Sveino / Inst4CIM-KG

Instance of CIM Knowledge Graph
Apache License 2.0
5 stars 1 forks source link

define needed reasoning #50

Open VladimirAlexiev opened 2 months ago

VladimirAlexiev commented 2 months ago

@Sveino talks of "RDFSPlus" and the repo refers to http://mlwiki.org/index.php/RDFS-Plus, but

So instead, let's specify explicitly what reasoning is needed by CIM.

rdfs:subClassOf

owl:inverseOf

SymmetricProperty ?

inverseOf is a SymmetricProperty. Having Symmetric reasoning will facilitate inverse reasoning, even if inverseOf is stated on only one direction.

This defect appears only for dcat:Dataset.publisher - dcat:Dataset.Resource11:

PREFIX cims: <http://iec.ch/TC57/1999/rdf-schema-extensions-19990926#>
select * {
  ?x cims:inverseRoleName ?y
  filter not exists {?y cims:inverseRoleName ?x}
}

Symmetric reasoning is a subset of inverse reasoning (symmetric props are self-inverses), so we can accomplish the same if we just have this axiom:

inverseOf inverseOf inverseOf

Nothing else

Sveino commented 2 months ago

I agree that RDFS-Plus might not be well defined, and we should make sure that we know which one we should support. There is primary two aims:

  1. Remove the need for using cims #26 (as one example)
  2. Limited the owl support to what can be supported (or needed to be supported) by on OOP bases application

The minimum support is:

What we would need to considerer:

VladimirAlexiev commented 2 months ago

@Sveino What vocabulary you use and what reasoning you want (need for particular use cases) are different things.

VladimirAlexiev commented 2 months ago

makes sense to distinguish a "step" prop vs its transitive closure.

Unfortunately RDF doesn't make a distinction between direct and inferred rdfs:subClassOf and rdf:type.

The CIM class hierarchy is deep and includes many abstract classes. To fetch the specific (directly asserted) type of a power system resource, queries will need to use database-specific extensions. As per https://github.com/w3c/sparql-dev/issues/124:

I bet vendors will not jump with joy at this complication.

This is an example that "there is such thing as TOO MUCH reasoning": one should always consider the specific consequences of using specific reasoning.