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 [email protected]<mailto:[email protected]>
Location<http://www.tno.nl/locations/DTS>
[cid:[email protected]]<http://www.tno.nl/>
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: [email protected] <[email protected]> Namens
Holger Knublauch
Verzonden: woensdag 1 september 2021 01:58
Aan: [email protected]
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.
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
On 2021-08-31 10:28 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:
(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 [email protected]<mailto:[email protected]>
Location<http://www.tno.nl/locations/DTS>
[cid:[email protected]]<http://www.tno.nl/>
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
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/9eedba7e10534409ac1eec4e3d3704b1%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/9eedba7e10534409ac1eec4e3d3704b1%40tno.nl?utm_medium=email&utm_source=footer>.
--
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
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/31454882-3bee-6ae1-1a58-62a3264c5ca2%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/31454882-3bee-6ae1-1a58-62a3264c5ca2%40topquadrant.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/65388471672b461e8fe91fe9f7d2c7cc%40tno.nl.
