shacl-rep?

[Bohms, H.M. (Michel)]

Is there a shacl counterpart for:

[

  a owl:AllDisjointClasses ;

  owl:members (

      smls:PhysicalObject

      smls:InformationObject

      smls:State

      smls:Event

      smls:TemporalRegion

      smls:SpatialRegion

      smls:Activity

    ) ;

].

 

Thx Michel

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location   This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

 

[Irene Polikoff]

Declaring disjoint classes is typically done when you are targeting your model for DL reasoning. DL reasoners rely on it and perform better with it. Outside of DL, it is seldom done.

You could, using inverse path on rdf:type say that for instances of smls:PhysicalObject, you can not have {?x a smls:InformationObject}, etc. You would do this for every class.

> On Mar 9, 2020, at 2:55 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:
>
> Is there a shacl counterpart for:
> [
> a owl:AllDisjointClasses ;
> owl:members (
> smls:PhysicalObject
> smls:InformationObject
> smls:State
> smls:Event
> smls:TemporalRegion
> smls:SpatialRegion
> smls:Activity
> ) ;
> ].
>
> Thx Michel
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E michel...@tno.nl
> Location
>
>

> <image001.gif>

> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
>
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/32830e3367084dfbabe6fc80390c3962%40tno.nl.

[Holger Knublauch]

Can any of them have multiple types at all? If not, just set sh:maxCount 1 at rdf:type.

As Irene indicated the scenario wasn't deemed important enough by the SHACL WG to include a built-in constraint type into the core language. However, it would be possible to define a custom constraint component in SHACL-SPARQL.

Holger

--

[Bohms, H.M. (Michel)]

Hi Holger

 

Would this become a global PropertyShape then?

 

For the smls upper ontology itself it holds but in general not for the userdefined ontologies importing smls.

(which will have subclasses for say PhysicalObject that are non-disjunst).

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/05a8285a-0491-0057-63e9-42fd4c1f245b%40topquadrant.com.

[David Price]

I think I investigated this a while back and if you really need disjointedness checked, then the best answer was to generate an sh:SPARQLConstraint from each owl:disjointWith statement and have that report a violation. I never finished the task, but that was the recommendation at the time. The complication in the general case is that you cannot just look at rdf:type(s) of the individual, you have to search up the superclasses to check for the class stated in the owl:disjointWith statement.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/70f21a2c16a847a88361cf890bacc73e%40tno.nl.

[Irene Polikoff]

That in itself does not necessarily require SHACL SPARQL. 

Instead, a complex path could be used - https://www.w3.org/TR/shacl/#property-path-zero-or-more.e.g., a path such as ^rdf:type/rdfs:subClassOf*

smls:InformationObject-invType

  a sh:PropertyShape ;

  sh:path (

      [

        sh:inversePath rdf:type ;

      ]

      [

        sh:zeroOrMorePath rdfs:subClassOf ;

      ]

    ) ;

  sh:hasValue smls:InformationObject ;

Throw in sh:not for this particular case to say that a smls:PhysicalObject can’t conform to this. Also, sh:or to cover other classes.

[Holger Knublauch]

Hi Michel,

I am attaching a solution that should work for the general case. It defines a NodeShape that has owl:AllDifferent as its target class, and then does pairwise comparison of all mentioned classes, and then reports instances that have multiple of those types:

on

alldifferent:AllDifferent1
  rdf:type owl:AllDifferent ;
  rdfs:label "All different1" ;
  owl:members (
      schema:Person
      schema:Product
      schema:Event
    ) .

and sample instance

alldifferent:CarPerson
  rdf:type schema:Person ;
  rdf:type schema:Vehicle ;
  rdfs:label "Car Person" .

The main shape is

alldifferent:AllDifferentShape
  rdf:type sh:NodeShape ;
  rdfs:label "All different shape" ;
  sh:sparql [
      sh:message "{?class1} and {?class2} cannot share instances but {?value} has types {?type1} and {?type2}" ;
      sh:prefixes <http://example.org/alldifferent> ;
      sh:select """SELECT $this ?class1 ?class2 (?instance AS ?value) ?type1 ?type2
WHERE {
    {
        $this owl:members ?membersList .
        # Go through all combinations
        ?members rdf:rest*/rdf:first ?class1 .
        ?members rdf:rest*/rdf:first ?class2 .
        FILTER (?class1 != ?class2) .
        FILTER (str(?class1) < str(?class2)) # Avoid duplicates in both directions
    }
    ?type1 rdfs:subClassOf* ?class1 .
    ?instance a ?type1 .
    ?instance a ?type2 .
    ?type2 rdfs:subClassOf* ?class2 .
}""" ;
    ] ;
  sh:targetClass owl:AllDifferent ;
.

This solution simply reuses the OWL vocabulary, so you don't need to change your model. Any similar solution would need to introduce another vocabulary, so for those who don't want to reuse owl:AllDifferent here, just make up your own instance vocabulary.

HTH

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/70f21a2c16a847a88361cf890bacc73e%40tno.nl.

[Bohms, H.M. (Michel)]

Guess that becomes even more troublesome for “allddisjointclasses clause...

 

I hope for a nodeshape level construct like:

every instance of the target class is not a member of class X

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAOQ%3D4f55NDk71jnfiQP0VReLffbxHWBwXWFcCYCdu%3DQJtWdBGw%40mail.gmail.com.

[Bohms, H.M. (Michel)]

 

Thx

 

One thing I do not understand…why ^rdf:type and not just rdf:type?

 

Assume I have object :o1 and classes :PO (PhysicalObject) and :SPO (SpecializedPhysicalObject) and IO (InformationObject)

 

So if “:o1 rdf:type :IO” I want t make sure its not of type PO or any recursive subclass of PO like SPO.

 

Isnt this then :

 

NOT

{

 

smls:InformationObject-invType

  a sh:PropertyShape ;

  sh:path (

      [

        sh:path rdf:type ;

      ]

      [

        sh:zeroOrMorePath rdfs:subClassOf ;

      ]

    ) ;

  sh:hasValue smls:InformationObject ;

}

 

 

 

 

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Irene Polikoff
Verzonden: Tuesday, March 10, 2020 2:58 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] shacl-rep?

 

That in itself does not necessarily require SHACL SPARQL. 

--

You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/E0526AA2-DCC7-4111-BC56-263F1C9A1856%40topquadrant.com.

[Bohms, H.M. (Michel)]

 

Looks nice

But

 

Wrt

owl:AllDifferent

 

did you mean?:

 

owl:AllDisjointClasses

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/75d31960-9bb6-129b-cdbf-1a40701118a4%40topquadrant.com.

[Holger Knublauch]

On 11/03/2020 8:05 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:

 

Looks nice

But

 

Wrt

owl:AllDifferent

 

did you mean?:

 

owl:AllDisjointClasses

Ah yes of course...

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f7b248a9676d413caa56a13dfa37d219%40tno.nl.

[Irene Polikoff]

Yes, you are right. I was thinking of two or three possible solutions at the same time and got them a bit mixed up.

You can use sh:not and drop the inverse if your target are all class members.

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/95cd83fc695243bf8705d06e3dbce4c9%40tno.nl.

[Bohms, H.M. (Michel)]

One more issue

 

Normally I would use RDFS+SHACL without owl

 

Now I have to keep however owl:AllDisjointClasses and its instances because it is the targetclass.

 

Guess there no way around this?

 

Or could I attach the shacl shape to the available classes somehow:

 

smls:PhysicalObject a rdfs:Class .

smls:InformationObject a rdfs:Class .

smls:Activity a rdfs:Class .

Etc.

 

Or does this actually go into the direction of Irene’s solution?

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/deba74f0-7d8c-5ed6-99a4-99419291d5e5%40topquadrant.com.

[Irene Polikoff]

Holger’s solution assumes that your starting point is OWL - you have OWL axioms and are trying to detect contradictions to it using SHACL.

My solution does not assume this. 

I have to go back to the question as to why make this constraint at all? This style of modeling is specific to OWL (for reasons related to how tableau reasoners operate) and is absent from any other modeling language I could think of e.g., XML Schema, JSON Schema, UML, EntityRelationships, etc.

One reason this is uncommon outside of OWL is because if you have different objects, their characteristics (properties and property values) will be different. And any possible issue are likely to be caught as a result of it - through other property shapes. For example, if you say that people must have father and a mother and organizations must have ‘year established’ and you have a resource that is both a person and an organization, you will get a violation one way or another. Another reason is that these kind of errors in data are pretty unusual. Data will come from some sources that typically have different data structures and identity for the different type of objects.

What are you trying to accomplish? It may be that in your data, you want each resource to have only one rdf:type statement. You can do it with sh:maxCount on rdf:type. You may want to say that if a resource is a member of class X transitively, it can’t be a member of any class that is not a subclass of X. This would allow multiple types, but all resolving to the same parent class.

If you do want, for some reason, to stay with the disjoint idea, then you have the solution I described where you would need for each class explicitly specify disjoint classes. If you want something more terse ala owl:AllDisjointClasses where you can say that a list of classes is all disjoint, then Holger’s solution. It is generic in that it can work with any ontology but it relies on having some statements that identify the list of disjoint classes. Holger used OWL vocabulary for these statements. You could invent your own vocabulary and modify the query accordingly.

On Mar 11, 2020, at 12:55 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

One more issue

 

Normally I would use RDFS+SHACL without owl

 

Now I have to keep however owl:AllDisjointClasses and its instances because it is the targetclass.

 

Guess there no way around this?

 

Or could I attach the shacl shape to the available classes somehow:

 

smls:PhysicalObject a rdfs:Class .

smls:InformationObject a rdfs:Class .

smls:Activity a rdfs:Class .

Etc.

 

Or does this actually go into the direction of Irene’s solution?

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

<image001.gif>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Holger Knublauch
Verzonden: Wednesday, March 11, 2020 11:35 AM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] shacl-rep?

 

 

On 11/03/2020 8:05 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:

 

Looks nice

But

 

Wrt

owl:AllDifferent

 

did you mean?:

 

owl:AllDisjointClasses

Ah yes of course...

Holger

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

<image001.gif>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Holger Knublauch
Verzonden: Tuesday, March 10, 2020 11:11 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] shacl-rep?

 

Hi Michel,

I am attaching a solution that should work for the general case. It defines a NodeShape that has owl:AllDifferent as its target class, and then does pairwise comparison of all mentioned classes, and then reports instances that have multiple of those types:

<image002.png>

Thx Michel

 

<image001.gif>

<image001.gif>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/3321adc8b15e4cc391acdc3c0b23afa8%40tno.nl.

[Bohms, H.M. (Michel)]

 

Holger’s solution assumes that your starting point is OWL - you have OWL axioms and are trying to detect contradictions to it using SHACL.

 

My solution does not assume this. 

 

> yes, I see. Guess holger’s approach applied to explicit rdfs classes will be similar to your solution, right?

 

I have to go back to the question as to why make this constraint at all? This style of modeling is specific to OWL (for reasons related to how tableau reasoners operate) and is absent from any other modeling language I could think of e.g., XML Schema, JSON Schema, UML, EntityRelationships, etc.

 

One reason this is uncommon outside of OWL is because if you have different objects, their characteristics (properties and property values) will be different. And any possible issue are likely to be caught as a result of it - through other property shapes. For example, if you say that people must have father and a mother and organizations must have ‘year established’ and you have a resource that is both a person and an organization, you will get a violation one way or another. Another reason is that these kind of errors in data are pretty unusual. Data will come from some sources that typically have different data structures and identity for the different type of objects.

 

What are you trying to accomplish? It may be that in your data, you want each resource to have only one rdf:type statement. You can do it with sh:maxCount on rdf:type. You may want to say that if a resource is a member of class X transitively, it can’t be a member of any class that is not a subclass of X. This would allow multiple types, but all resolving to the same parent class.

 

> in our (use) case we exchange data according to ontologies (often called object type libraries in nl) that share a common top level taxonomy (smls).

> in the exchange we want to check the disjointness for classes in the top level or subclasses (say: the ‘archetypes’)

> still there can be multiple typing in the OTL (under the same smls archetype)

> maxCount=1 is therefore “too restrictive”

> we have 4 profiles: SKOS, RDFS, RDF+OWL, RDFS+SHACL

> so for data verification we are in the last one and that is the context of my question (so no owl here)

 

 

If you do want, for some reason, to stay with the disjoint idea, then you have the solution I described where you would need for each class explicitly specify disjoint classes. If you want something more terse ala owl:AllDisjointClasses where you can say that a list of classes is all disjoint, then Holger’s solution. It is generic in that it can work with any ontology but it relies on having some statements that identify the list of disjoint classes. Holger used OWL vocabulary for these statements. You could invent your own vocabulary and modify the query accordingly.

 

> indeed when I talked about a ‘work around’ I was thinking about something like that, but maybe also not elegant

> guess your way would be more applicable then....

 

> thx for your extensive answers! Michel

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/15F69A4B-777D-4172-B9BB-0B72D17492F9%40topquadrant.com.

[Irene Polikoff]

On Mar 11, 2020, at 2:35 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

Holger’s solution assumes that your starting point is OWL - you have OWL axioms and are trying to detect contradictions to it using SHACL.

 

My solution does not assume this. 

 

> yes, I see. Guess holger’s approach applied to explicit rdfs classes will be similar to your solution, right?

Holger’s solution requires that there is a statement like this:

example:AllDisjoint1
  rdf:type owl:AllDisjointClasses ;
  rdfs:label "All disjoint 1" ;

  owl:members (
      schema:Person
      schema:Product
      schema:Event
    ) .

I don’t think it matters to this example whether schema:Person is rdfs:Class or owl:Class. I do not believe Holger's SPARQL query uses the fact that something is of type owl:Class. Even if it did, it could be changed accordingly.

Further, instead of using owl:AllDisjoint and owl:members, it could also be

example:AllDisjoint1
  rdf:type my:AllDisjointClasses ;
  rdfs:label "All disjoint 1" ;
  my:members (

      schema:Person
      schema:Product
      schema:Event
    ) .

I have to go back to the question as to why make this constraint at all? This style of modeling is specific to OWL (for reasons related to how tableau reasoners operate) and is absent from any other modeling language I could think of e.g., XML Schema, JSON Schema, UML, EntityRelationships, etc.

 

One reason this is uncommon outside of OWL is because if you have different objects, their characteristics (properties and property values) will be different. And any possible issue are likely to be caught as a result of it - through other property shapes. For example, if you say that people must have father and a mother and organizations must have ‘year established’ and you have a resource that is both a person and an organization, you will get a violation one way or another. Another reason is that these kind of errors in data are pretty unusual. Data will come from some sources that typically have different data structures and identity for the different type of objects.

 

What are you trying to accomplish? It may be that in your data, you want each resource to have only one rdf:type statement. You can do it with sh:maxCount on rdf:type. You may want to say that if a resource is a member of class X transitively, it can’t be a member of any class that is not a subclass of X. This would allow multiple types, but all resolving to the same parent class.

 

> in our (use) case we exchange data according to ontologies (often called object type libraries in nl) that share a common top level taxonomy (smls).

> in the exchange we want to check the disjointness for classes in the top level or subclasses (say: the ‘archetypes’)

> still there can be multiple typing in the OTL (under the same smls archetype)

> maxCount=1 is therefore “too restrictive”

I do not have enough info on what your model looks like - what are the instance and what are the classes and how they are used. One idea could be to consider giving your classes different types e.g., smls:PhysicalObject a smls:PhysicalObjectClass.

We use this in EDG models where each EDG class is an instance of edg:AssetClass. But this is going beyond what I would have time to discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2d4227bd90514e178cec9db8330e9cdd%40tno.nl.