right owl2shacl-mapping?

21 views
Skip to first unread message

Bohms, H.M. (Michel)

unread,
Aug 31, 2021, 8:28:09 AM8/31/21
to topbrai...@googlegroups.com

(we were looking for an approach not needing rdfs-entailment)

 

sml:AllDisjointClasses_1

  a owl:AllDisjointClasses ;

  owl:members (

      sml:PhysicalObject

      sml:InformationObject

      sml:Activity

      sml:Event

      sml:State

    ) ;

.

 

In shacl (?):

 

sml:DisjointClassesShape_1 a sh:NodeShape ;

  sh:targetSubjectsOf rdf:type ;

  sh:property [

    sh:path ( rdf:type [ sh:zeroOrMorePath rdfs:subClassOf ] ) ;

    sh:qualifiedValueShape [

      sh:in (

        sml:PhysicalObject

        sml:InformationObject

        sml:State

        sml:Event

        sml:Activity

      ) ;

    ] ;

    sh:qualifiedMaxCount 1 ;

  ] ;

.

 

Any issues with this mapping?

 

Thx Michel

 

 

 

Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability

T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
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.

 

David Price

unread,
Aug 31, 2021, 9:46:28 AM8/31/21
to topbrai...@googlegroups.com
I don’t like creating a separate instance to control disjointedness as it’s not immediately visible in the relevant class form. The NodeShape being proposed has the same issue.

I usually use a pattern like this:

unnamed:Thing_1
  rdf:type owl:Class ;
  rdfs:subClassOf owl:Thing ;
  owl:disjointWith unnamed:Thing_2 ;
  owl:disjointWith unnamed:Thing_3 ;

and then EDG owl2shacl does this: For each owl:disjointWith from class A to B, create one constraint at A with the pattern sh:not [ sh:class B ].

You could generate sh:not from the approach you mention too, of course. I did not test the mentioned approach but it does appear that it or something similar would work.

Also, if Advanced SHACL is supported in your tools a TripleRule could likely handle this need.


Cheers,
David

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/9eedba7e10534409ac1eec4e3d3704b1%40tno.nl.


Bohms, H.M. (Michel)

unread,
Aug 31, 2021, 9:54:51 AM8/31/21
to topbrai...@googlegroups.com

Hi David

 

Your solution (as generated) needs quite some code in case of more than two items and also in a distributed way.

We hoped to cover it with more generic template code…

 

Wrt shacl AF: if we can do it in shacl core (being a recommendation) that would be preferred. Furthermore I would not quickly see how to define a triple rule that does the same as the shacl core nodeshape proposal.

 

(I do see your visibility issue though…)

 

Gr michel

 

 

Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability

T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
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.

Holger Knublauch

unread,
Aug 31, 2021, 7:58:02 PM8/31/21
to topbrai...@googlegroups.com

This (interesting) design may work technically, but it can be very slow because it will traverse all rdf:type triples everywhere and use a rather complex algorithm with nested (qualified) shapes. A better solution would indeed start with exactly the instances of one of those classes. The solution that David mentioned certainly works OK if you have few disjoint classes each, but for long lists even the OWL 2 standard introduced a more compact syntax, using owl:AllDisjointClasses.

I guess the syntactically ideal replacement would be to declare a reusable constraint component using SHACL-SPARQL (which is part of the SHACL standard 1.0). You could even leave the existing owl:DisjointClasses in place, but I don't like that they are using rdf:Lists which would need to be traversed repeatedly and that is very slow too. owl:members here should simply point at the classes IMHO.

But something like that should be fine:

sml:AllDisjointClasses_1
    a sh:NodeShape ;
    sh:targetClass sml:PhysicalObject, sml:InformationObject, sml:Activity, sml:Event, sml:State ;
    dash:allDisjoint true .

where dash:allDisjoint would be a constraint component that would walk through the targetClasses of $currentShape in $shapesGraph.

How many such cases (of large disjointness clusters) do you actually have? Is this even a sensible concept... I mean how would this exclude anyone else from adding more classes that you don't know about yet. If you want to close off your instances, just give them a sh:maxCount 1 on rdf:type.

Holger

--

Bohms, H.M. (Michel)

unread,
Sep 1, 2021, 2:51:07 AM9/1/21
to topbrai...@googlegroups.com, Miltos Gatzios, Lucas Verhelst

Hi Holger

 

The pattern I showed is a proposal by someone as a replacement for our current:

 

sml:AllDisjointClassesShape_1

  a sh:NodeShape ;

  sh:targetSubjectsOf rdf:type ;

  sh:property [

    sh:path rdf:type ;

    sh:qualifiedValueShape [

      sh:zeroOrMorePath rdfs:subClassOf ;

      sh:in (

        sml:PhysicalObject

        sml:InformationObject

        sml:State

        sml:Event

        sml:Activity

      ) ;

    ] ;

    sh:qualifiedMaxCount 1 ;

  ] ;

.

 

Would the current way be less cumbersome to check?

 

How applied? In our current CEN SML ontology we have one such dimension for the main archetypes (as above) and for some of them some orthogonal dimensions with less items (#2): planned/realized, space/object, functional/technical).

 

That is also the reason multiple typing is always relevant and cannot be closed (ie ‘maxcard rdf:type being 1’ is not possible).

 

dash:allDisjoint would be an interesting  but ‘limited standard’ option I guess…isn’t there room in the evolving (in future more standard) shacl-af for such a construct?

 

Michel

 

 

Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability

T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
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.

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Holger Knublauch
Verzonden: woensdag 1 september 2021 01:58
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] right owl2shacl-mapping?

 

This (interesting) design may work technically, but it can be very slow because it will traverse all rdf:type triples everywhere and use a rather complex algorithm with nested (qualified) shapes. A better solution would indeed start with exactly the instances of one of those classes. The solution that David mentioned certainly works OK if you have few disjoint classes each, but for long lists even the OWL 2 standard introduced a more compact syntax, using owl:AllDisjointClasses.

Holger Knublauch

unread,
Sep 1, 2021, 11:08:52 PM9/1/21
to topbrai...@googlegroups.com, Miltos Gatzios, Lucas Verhelst


On 2021-09-01 4:51 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:

Hi Holger

 

The pattern I showed is a proposal by someone as a replacement for our current:

 

sml:AllDisjointClassesShape_1

  a sh:NodeShape ;

  sh:targetSubjectsOf rdf:type ;

  sh:property [

    sh:path rdf:type ;

    sh:qualifiedValueShape [

      sh:zeroOrMorePath rdfs:subClassOf ;

      sh:in (

        sml:PhysicalObject

        sml:InformationObject

        sml:State

        sml:Event

        sml:Activity

      ) ;

    ] ;

    sh:qualifiedMaxCount 1 ;

  ] ;

.

 

Would the current way be less cumbersome to check?

That looks equally slow as it applies to all rdf:type triples. Better to target exactly the instances of the classes in question, and the sh:targetClass approach that I outlined would do that.

 

How applied? In our current CEN SML ontology we have one such dimension for the main archetypes (as above) and for some of them some orthogonal dimensions with less items (#2): planned/realized, space/object, functional/technical).

 

That is also the reason multiple typing is always relevant and cannot be closed (ie ‘maxcard rdf:type being 1’ is not possible).

 

dash:allDisjoint would be an interesting  but ‘limited standard’ option I guess…isn’t there room in the evolving (in future more standard) shacl-af for such a construct?

dash:allDisjoint can already be expressed in SHACL 1.0 but not in Core but SHACL-SPARQL.

There is no point in waiting for a SHACL 1.1 or SHACL-AF becoming official as W3C would require multi-year processes for that and nobody has even started those processes.

Holger


Bohms, H.M. (Michel)

unread,
Sep 2, 2021, 3:19:19 AM9/2/21
to topbrai...@googlegroups.com, Miltos Gatzios, Lucas Verhelst

Thx clear!

 

So…how could we define the dash:allDisjoint …. ?

Holger Knublauch

unread,
Sep 2, 2021, 6:48:42 PM9/2/21
to topbrai...@googlegroups.com, Miltos Gatzios, Lucas Verhelst


On 2021-09-02 5:19 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:

Thx clear!

 

So…how could we define the dash:allDisjoint …. ?

I wanted to leave this as an exercise to the reader, but it didn't take long so here you are, including a test case.

If you find this useful in practice, I could add this to a future version of the dash namespace.

Holger

allDisjoint.test.ttl
allDisjoint.ttl
Reply all
Reply to author
Forward
0 new messages