owl restrictions for individuals?
Bohms, H.M. (Michel)
In asset management/modelling we often see the need to define groups of (many) things that are not (yet) fully explicitly modelled.
Ie a rdfs:Bag instance where not all rdfs:member’ s are known explicitly.
Such ‘implicit groups’ as we call them, we would like to represent using OWL restriction classes in owl (and later also shacl shapes) that are used to classify such group instances.
Typically all examples we see is using such restriction classes for subclassing on class-level.
So now the idea is to use them for classifying instances.
Would that be possible within TBC/EDG?
In my perception, such instance-level constraint was only a shacl-benefit.
But now one of my partners says that this can be done with owl restrictions too.
Here is a sketch of the proposal:
Not that the restriction R (left side) is related to the instance of the group #1 working on its member property.
Note also its is a nested restriction: onClass has further subrestrictions.
If allowed (owl full?) and practically working in TBC/EDG, it would be a very nice language-level approach, better than own inventions like an own hasReferenceIndividual relationship etc.
Thx Michel
|
||||||||||||||||
Bohms, H.M. (Michel)
Hereby also the actual code example for modelling implicit groups of assets.
(via a nested constraint for an individual)
Example: a road crash barrier having associated an implicit group of 300 yellow km-signs.
No complaints from TBC.
Still special way of modelling, comments welcome.
# baseURI: https://w3id.org/igtest/owl/def
# imports: https://w3id.org/nen2660/owl/def
@prefix nen2660: https://w3id.org/nen2660/def# .
@prefix owl: http://www.w3.org/2002/07/owl# .
@prefix quantitykind: http://qudt.org/vocab/quantitykind/ .
@prefix qudt: http://qudt.org/schema/qudt/ .
@prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# .
@prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@prefix skos: http://www.w3.org/2004/02/skos/core# .
@prefix unit: http://qudt.org/vocab/unit/ .
@prefix wn: https://w3id.org/wegennetwerk/def# .
@prefix xsd: http://www.w3.org/2001/XMLSchema# .
@prefix ig: https://w3id.org/igtest/def# .
https://w3id.org/igtest/owl/def
a owl:Ontology ;
owl:imports https://w3id.org/nen2660/owl/def ;
.
ig:GeleideConstructie a owl:Class ;
.
ig:HectometerPaal a owl:Class ;
.
ig:GCnoorderZijberm-hm15dot-hm25dot3 a ig:GeleideConstructie ;
ig:hasGroupedParts ig:HMPgroup_1 ;
.
ig:HMPgroup_1 a rdfs:Container ;
a [a owl:Restriction ;
owl:onProperty rdfs:member;
owl:qualifiedCardinality 300 ;
owl:onClass [ rdfs:subClassOf ig:HectometerPaal;
rdfs:subClassOf [
a owl:Restriction;
owl:hasvalue "Geel";
owl:onProperty ig:kleur] ] ] ;
.
ig:hasGroupedParts a owl:ObjectProperty ;
rdfs:range rdfs:Container ;
.
ig:kleur a owl:DatatypeProperty ;
rdfs:range xsd:string ;
.
|
||||||||||||||||
--
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/8dcd808efee34cb7aac43463f7051a2c%40tno.nl.
David Price
From: 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com>
Sent: Friday, October 8, 2021 12:52 PM
To: topbrai...@googlegroups.com
Subject: [topbraid-users] owl restrictions for individuals?In asset management/modelling we often see the need to define groups of (many) things that are not (yet) fully explicitly modelled.Ie a rdfs:Bag instance where not all rdfs:member’ s are known explicitly.Such ‘implicit groups’ as we call them, we would like to represent using OWL restriction classes in owl (and later also shacl shapes) that are used to classify such group instances.Typically all examples we see is using such restriction classes for subclassing on class-level.So now the idea is to use them for classifying instances.Would that be possible within TBC/EDG?In my perception, such instance-level constraint was only a shacl-benefit.But now one of my partners says that this can be done with owl restrictions too.Here is a sketch of the proposal:
<image002.png>
Not that the restriction R (left side) is related to the instance of the group #1 working on its member property.Note also its is a nested restriction: onClass has further subrestrictions.If allowed (owl full?) and practically working in TBC/EDG, it would be a very nice language-level approach, better than own inventions like an own hasReferenceIndividual relationship etc.Thx Michel
Scientist Specialist
Structural Reliability
--
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/8dcd808efee34cb7aac43463f7051a2c%40tno.nl.
--
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/316603ffe60c4eaa8715f65c13325f2d%40tno.nl.
Bohms, H.M. (Michel)
Hi David
Thx for your view.
Personally I think the rdfs containers captures at least some generic “grouping” semantics.
I would not like to redefine that myself (own group classes, member relations etc.).
On the other hand we might misuse this way a mechanism meant for explicit grouping for implicit grouping.
In any case the practical need is really there in asset mngt. People do not want to model (in their view) all the details from others.
In the example: they want to be able to model the groups of things having typical properties and the group having properties like an amount of members, total cost, etc. without the need to be able to explicitly point to the members.
In that sense our pattern could fulfil those needs: we have a group (container), we do not model explicit members, but add other properties to the group (like total cost) and are able to put restrictions on their members (like ‘all should be yellow’). So we capture the typical member data in a restriction without having the (explicit) members themselves….that might be special too….
Anyway, we’ll consider, thx
|
|
|
| ||||
| ||||||||
.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/207CE8D6-ECA3-4C44-831F-52B48C77E935%40topquadrant.com.
David Price
On 13 Oct 2021, at 13:00, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:
Hi DavidThx for your view.Personally I think the rdfs containers captures at least some generic “grouping” semantics.I would not like to redefine that myself (own group classes, member relations etc.).On the other hand we might misuse this way a mechanism meant for explicit grouping for implicit grouping.In any case the practical need is really there in asset mngt. People do not want to model (in their view) all the details from others.In the example: they want to be able to model the groups of things having typical properties and the group having properties like an amount of members, total cost, etc. without the need to be able to explicitly point to the members.In that sense our pattern could fulfil those needs: we have a group (container), we do not model explicit members, but add other properties to the group (like total cost) and are able to put restrictions on their members (like ‘all should be yellow’). So we capture the typical member data in a restriction without having the (explicit) members themselves….that might be special too….Anyway, we’ll consider, thx
Scientist Specialist
Structural Reliability
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/61d63163224444fb987d87b75748378d%40tno.nl.
Bohms, H.M. (Michel)
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D54448E4-FC87-48D4-9743-AC72412E3477%40topquadrant.com.
Bohms, H.M. (Michel)
Hi David
My owl experiment:
I would have expected a warning about the maxcard being 3 but having 4 members in the data.
(note that in real there will be no explicit members, just here to check the logic…).
Gr michel
|
|
|
| ||||
| ||||||||
David Price
On 18 Oct 2021, at 09:26, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:
Hi DavidMy owl experiment:
I would have expected a warning about the maxcard being 3 but having 4 members in the data.(note that in real there will be no explicit members, just here to check the logic…).Gr michel
Scientist Specialist
Structural Reliability
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/bcf9c28b2ced4d1eb76e3fb7f22866d9%40tno.nl.
Bohms, H.M. (Michel)
Hi David
This is new for me 😊
Anyway, I ticked the box:
An I did get results, but all related to the imported vaem, qudt etc.
But no results related to my cardinality constraint combined with the 4 values.
Anyway I think this is reasonable since it could only have derived:
(HMP_1 owl:sameAs HMP_2 or HMP_1 owl:sameAs HMP3 or … etc.) ie “ two of the 4 are the same”)
But I guess this is way beyond DL because of the “ ORs” …
The SHACL variant I will not test…..since it will always result in an error: because of implicit group definitions there are no members (or just some explicit known members). So checking cardinality=3 will always result in a problem.
Gr Michel
|
|
|
| ||||
.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/E06F01EC-AC34-4219-A6F7-A73FF7DDECB2%40topquadrant.com.
Bohms, H.M. (Michel)
Ok see what you mean now…n o DL but only shacl0implemneted subset…so ignore my first remark
Anyway even less to expect indeed…..
|
||||||||||||||||
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/3ff8146fb0b94980a0328049bfb767c5%40tno.nl.
Irene Polikoff
On Oct 18, 2021, at 4:41 AM, David Price <dpr...@topquadrant.com> wrote:
Hi Michel,
Tthe TopBraid rules engine is based on SHACL, not OWL, so Composer does not come with an embedded DL reasoner (i.e. you should not have expected any result testing your model this way).Cheers,
David
On 18 Oct 2021, at 09:26, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:Hi DavidMy owl experiment:
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/E06F01EC-AC34-4219-A6F7-A73FF7DDECB2%40topquadrant.com.
Irene Polikoff
On Oct 18, 2021, at 9:48 AM, Irene Polikoff <ir...@topquadrant.com> wrote:
Irrespective of this, OWL is open world. There are no warnings on max car finality unless there is an explicit statement that each member is different from all others.