combining owl and skos

43 views
Skip to first unread message

Bohms, H.M. (Michel)

unread,
Oct 8, 2019, 11:31:08 AM10/8/19
to topbrai...@googlegroups.com, lars.w...@triona.se

 

In:

https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html

 

its is said:

To illustrate these patterns, let's start with the following semi-formal conceptualisation:

ex:mountains rdf:type skos:Concept;

  skos:prefLabel "Mountains"@en.

 

ex:himalayas rdf:type skos:Concept;

  skos:prefLabel "Himalayas"@en;

  skos:broader ex:mountains.

 

ex:everest rdf:type skos:Concept;

  skos:prefLabel "Everest"@en;

  skos:broader ex:himalayas.

Overlay SKOS with OWL

In this pattern, we use OWL to overlay additional semantics on the same vocabulary, e.g. by adding the following triples:

ex:mountains rdf:type owl:Class.

 

ex:himalayas rdf:type owl:Class;

  rdfs:subClassOf ex:mountains.

 

ex:everest rdf:type ex:himalayas.

If the two sets of triples are merged, then this pattern necessarily leads to an OWL Full representation, because an instance of skos:Concept might also be an instance of owl:Class.

 

 

Is the red statement really true? And if yes, is it really an issue here?

 

(maybe it was under owl1 but under owl2 not different?)

 

thx for advice, Michel

 

 

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

+31888663107
+31630381220
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

unread,
Oct 8, 2019, 12:22:39 PM10/8/19
to topbrai...@googlegroups.com, lars.w...@triona.se
Question that I find important in the presence of such merging of models or re-use of the URIs in the different context is what the modeler is trying to accomplish.

rdfs:subClassOf has clear semantics:

1. Both subjects and object are classes
2. Classes describe sets of instances that are class members. By describe, we mean identify properties they may have and property values using formal KR languages such as OWL and SHACL. Another, alternative way to describe a class is by enumerating a complete, finite list of its members. If a modeler is not clear what are the instances of a class she is describing, she should not be declaring it a class.
3. All instances of the subject class are also instances of the object class.
4. Everything said about members of the object class using OWL restrictions or SHACL constraints applies to the members of the subject class. For example, if Mountain is a class and Himalayas a subclass of it and we used a constraint to say that mountains have elevation and it must be numeric, then the same is true for every instance of Himalayas.

Skos:broader has no clear semantics other than it connects two concepts. 

Nothing else is defined and one could use skos:broader to build any hierarchy for any purpose. For example, a real (implied) relationship may be partitive  (e.g., Germany is part of European Union or Engine is a part of a Car) or is-a (e.g., Human is a Mammal) or something else or even a mixture of different relationships: Joe Smith’s BMW (in instance of a car) has model BMW 230i (an instance of Car Model class) which is part of BMW 2 Series (an instance of Car Series class) which is manufactured by BMW (an instance of Organization or an instance of a Brand, depending on what you are modeling and for what reasons). In a SKOS Taxonomy, we may commonly see BMW 230i skos:broader BMW 2 Series skos:broader BMW.

I can't think of reasons for wanting to connect two classes that are already connected by rdfs:subClassOf relationship with skos:broader relationship. The underlying question is really about whether the same resource should/could be both, an OWL Class and an instance of skos:Concept. Saying that the same resource is a class and an instance is called punning.

Restrictions on punning have been relaxed in OWL-2 because new algorithms were designed that would ensure that DL processing did not get into a tizzy when punning is done a certain way. This is quite academic anyhow since there are very few DL reasoners in the world and no one uses them outside of academia.

Personally, I believe that situations where punning may make sense are extremely rare. Human language is imprecise and it is common for us to use the same word when we mean different things. As people, we understand what is meant through the context of conversation. We know when a person is talking about BMW 230i as a set of all cars that have this model or when they talk about it as an instance of a car model. These are two different things in the world and they have different properties. 

Computers can’t make the contextual distinction if we use the same URI for two different things. Modelers should be precise in the meaning of a resource they are identifying and describing if their models are intended for machine processing.


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

dprice

unread,
Oct 8, 2019, 12:44:28 PM10/8/19
to topbrai...@googlegroups.com, Lars Wikstrom
The SKOS spec says: "The SKOS data model is formally defined in this specification as an OWL Full ontology” 

However, OWL Full is an OWL 1 term and OWL 2 Direct Semantics added meta-modelling aka punning. So, if an OWL 1 Full ontology only had a “problem” that OWL 2 punning handles then, I think that OWL 1 Full ontology fits into the OWL 2 DS profile.

I’ve not looked at or thought about any of this in detail until this reply, so take this with a grain of salt - but I *think* the specific example is handled by punning:

ex:everest rdf:type ex:himalayas rdf:type skos:Concept  rdf:type owl:Class

I’ve not tested that with any tools, just looks ok via an eye test compared to the spec text example [1]:

:x rdf:type :Eagle rdf:type :Species rdf:type owl:Class

Anyway, in general I think that SKOS and OWL 2 *may* live together OK if your specific use of SKOS Concept, broader, etc. results in cases of *only* OWL 2 meta-modelling (i.e. no other structure appears that is beyond OWL 2 Direct Semantics). 

However, there are imaginable cases where that’s not the case - SKOS lets you violate OWL 2 DS with no complaints.

Finally, WRT “is it really an issue” no matter what the specs say => that depends entirely on how you are using SKOS and the characteristics of your tools. 

If your scenario requires the use of a DL reasoner and SKOS causes that reason any problems, then yes … it is an issue. 

If you’re not using a DL reasoner or that reasoner behaves as expected even with SKOS in the scope, then perhaps not an issue.

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

Jan Voskuil

unread,
Nov 19, 2019, 10:33:48 AM11/19/19
to TopBraid Suite Users
A very late after-burner (I am currently involved in similar discussions and stumbled upon this thread by accident):
Have a look at Uschold's "Demystifying OWL". It is a good read, especially the two pages on punning.
While there is little to add to what Irene and David have said, I think it is important to stress that when people say things like "I have a set of triples, and these imply OWL Full", what really is being said is that there is a deep and serious problem with the model being used. OWL Full does not solve these problems, nor does it cause interesting things to happen. It only guides an OWL-inferencer around the underlying problems, so that it does not break down. The original intention of the underlying model is not achieved, however. Introspective tools will not behave as expected. Irene's example about the BMW 240i is hard in any formal language, because of type theory being counter-intuitive. There is nothing one can do about that. Instead of trying to out-smart the semantics of RDF, it is most often better to bite the bullet and solve the issue in the model itself --- and accept the added complexity.

dprice

unread,
Nov 19, 2019, 11:54:34 AM11/19/19
to topbrai...@googlegroups.com

On 19 Nov 2019, at 15:24, Jan Voskuil <jan.v...@taxonic.com> wrote:

A very late after-burner (I am currently involved in similar discussions and stumbled upon this thread by accident):
Have a look at Uschold's "Demystifying OWL". It is a good read, especially the two pages on punning.
While there is little to add to what Irene and David have said, I think it is important to stress that when people say things like "I have a set of triples, and these imply OWL Full", what really is being said is that there is a deep and serious problem with the model being used. OWL Full does not solve these problems, nor does it cause interesting things to happen. It only guides an OWL-inferencer around the underlying problems, so that it does not break down. The original intention of the underlying model is not achieved, however. Introspective tools will not behave as expected. Irene's example about the BMW 240i is hard in any formal language, because of type theory being counter-intuitive. There is nothing one can do about that. Instead of trying to out-smart the semantics of RDF, it is most often better to bite the bullet and solve the issue in the model itself --- and accept the added complexity.


Hi Jan,

Personally, I think that characterisation goes a bit too far although the core sentiment is a good approach.

Technically, all "OWL Full” really means is that the model uses logic that is, for example, based in First Order Logic [1] rather than in Description Logic [2]. Using DL often means the modeller has chosen “decidability” over “representational capability” wrt their model. That’s fine if DL is sufficient to model your domain of interest. But, what if it’s not? 

There are certainly cases where the use of first order logic models and engines have solved real-world problems. 

I imagine most folks don’t know that “The relational model (RM) for database management is an approach to managing data using a structure and language consistent with first-order predicate logic,” (quote from https://en.wikipedia.org/wiki/Relational_model)

There’s even an ISO standard logic language supporting for those cases - Common Logic [3] is an ISO standard that “provide for the expression of arbitrary first-order logical sentences”.  

There are also standard data models, ISO 15926-2 [4] for example, that are based in higher-than-DL order logic (full disclosure, with previous employers I worked in ISO on 15926 and ISO 10303 STEP). 

I agree that there are many, many, many “bad” models in industry. However, there are plenty of quality models that use logic higher than DL - they just require more expertise to create and use (e.g. logicians may be needed in the project). I happen to have studied math and have been surprised at times to find ontologist/modelers who don’t understand any of this stuff because they never studied set theory or logic. These more complex ideas require some background education/knowledge in order to use them properly. However, I’m sure you know the quote: Everything Should Be Made as Simple as Possible, But Not Simpler.

Apologies for the long reply and all the links. Just something to which I happen to have had quite a bit of exposure, although am not truly an expert, as I spent a lot of time debating academics and logicians in ISO-land when working for IBM.

Cheers,
David

[1] ISO/IEC 24707:2018. Information technology — Common Logic (CL) — A framework for a family of logic-based languages


[2] First-order Logic


[3] Description Logic


[4] ISO 15926-2:2003. Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 2: Data model


--
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.

Jan Voskuil

unread,
Nov 19, 2019, 2:20:34 PM11/19/19
to TopBraid Suite Users
Thanks David, you are right. I did follow some courses on possible world semantics, Montague semantics, higher order logics and the like, and although this is now ancient history (for me) I should have known and phrased my concerns differently. In any case thanks for the references, these are highly relevant to the discussions I am currently taking part in: Linked Building Data community and a related Dutch standard that Michel is working on a lot.

I guess, though, that the problem is not DL vs FOL but type theory. The spec to which you refer in your original comment says:
The OWL 2 Direct Semantics treats the different uses of the same name as completely separate, as is required in DL reasoners.
Does the same not also hold for FOL-reasoners?

So <mountain>-the-concept and <mountain>-the-class are different objects. Same for your example

:x rdf:type :Eagle rdf:type :Species rdf:type owl:Class

Eagle-the-species is a different thing than eagle-the-individual, so from these statements it cannot be concluded that :x is an instance of something that, in turn, is a species. And if that spurious conclusion is NOT intended, then why not use two different names? 

Or would a FOL-reasoner infer the intended conclusion? I am beginning to have doubts so I am curious.

And, contrary to may earlier statements about tools going berserk, TBC handles punning quite nicely. So I retract that. So when you open the infamous DCTERMS ontology and open it in TBC, you will find that AgentClass is defined as a Class and a subClassOf Class. Instances of AgentClass are neatly shown as classes not individuals, althought they are both (but not at the same time). That said, I keep having a rather queasy feeling when I see this.

Capture.PNG



Of course all this is not intended to suggest that FOL does not solve real problems. It does, and so do more powerful logical systems. 

And I do remember the discussions we had in which you propose to treat different levels of modelness in separate graphs. That would also be an instance of punning, but one in which one can systematically separate out the different meanings in contexts that are explicitly marked as different. Still a lot to process, but at least it becomes tractable what is what when.

My general penchant is that SHACL offers a wealth of tactics to do metamodeling in a much more elegant way than with OWL (let alone punning). A good example was pointed out by Holger to me earlier today: dash:composite. I believe SHACL is seriously underused in tackling the hairier problems in information modelling on the semantic web.
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

Jan Voskuil

unread,
Nov 20, 2019, 3:42:07 AM11/20/19
to TopBraid Suite Users
The example is not correct but I created a small example that is. TBC works fine with punning. Of course :myCar rdf:type :TeslaModelS :type :CarModel means that :myCar does not inherit any properties from :CarModel. 

Capture.PNG

Bohms, H.M. (Michel)

unread,
Nov 20, 2019, 4:02:51 AM11/20/19
to topbrai...@googlegroups.com

Hi Jan

 

Thx for the extra input here.

Could there still be a case for owl full (actually as I see it (?): being no restrictions on the use of RDF + added owl clauses)

Where there is no use of reasoners, say just for specification sake....(think nta option 2 ...).

 

Or would you say: if an owl reasoner cannot be applied, the semantics is actually so poor that there is no other useful application too?

 

Thx Michel

--

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.

Bohms, H.M. (Michel)

unread,
Nov 20, 2019, 4:08:40 AM11/20/19
to topbrai...@googlegroups.com

Just read this one below..

So my reply was on using owl full for representational capability (like adding triples (next to say rdfs:domain, rdfs:range) to a height being an owl:DatatypeProperty)

dprice

unread,
Nov 20, 2019, 4:23:39 AM11/20/19
to topbrai...@googlegroups.com
On 20 Nov 2019, at 08:42, Jan Voskuil <jan.v...@taxonic.com> wrote:

The example is not correct but I created a small example that is. TBC works fine with punning. Of course :myCar rdf:type :TeslaModelS :type :CarModel means that :myCar does not inherit any properties from :CarModel. 

<Capture.PNG>



On Tuesday, November 19, 2019 at 8:20:34 PM UTC+1, Jan Voskuil wrote:
Thanks David, you are right. I did follow some courses on possible world semantics, Montague semantics, higher order logics and the like, and although this is now ancient history (for me) I should have known and phrased my concerns differently. In any case thanks for the references, these are highly relevant to the discussions I am currently taking part in: Linked Building Data community and a related Dutch standard that Michel is working on a lot.

I guess, though, that the problem is not DL vs FOL but type theory. The spec to which you refer in your original comment says:
The OWL 2 Direct Semantics treats the different uses of the same name as completely separate, as is required in DL reasoners.
Does the same not also hold for FOL-reasoners?

Nope. There are, of course, flavours of FOL reasoners too, but classes having classes as members is supported and the thing in question is the same thing whether a class or member - if that’s the question. It’s just set theory where sets are allowed to be members of sets.


So <mountain>-the-concept and <mountain>-the-class are different objects. Same for your example

:x rdf:type :Eagle rdf:type :Species rdf:type owl:Class

Eagle-the-species is a different thing than eagle-the-individual, so from these statements it cannot be concluded that :x is an instance of something that, in turn, is a species. And if that spurious conclusion is NOT intended, then why not use two different names? 

Or would a FOL-reasoner infer the intended conclusion? I am beginning to have doubts so I am curious.

I’m confused by that the “it cannot be concluded” comment on:

:x rdf:type :Eagle rdf:type :Species rdf:type owl:Class

:x is an :Eagle
:Eagle is a :Species
:Species is a owl:Class

clearly asserts that “:x is an instance of something that, in turn, is a species” as far as FOL interpretations are concerned. There is no inference to be made wrt x: itself.  :Eagle a owl:Class would be inferred though.

Maybe I missed the real question?


And, contrary to may earlier statements about tools going berserk, TBC handles punning quite nicely. So I retract that. So when you open the infamous DCTERMS ontology and open it in TBC, you will find that AgentClass is defined as a Class and a subClassOf Class. Instances of AgentClass are neatly shown as classes not individuals, althought they are both (but not at the same time). That said, I keep having a rather queasy feeling when I see this.

Capture.PNG





Blending a domain model with the modelling language itself is indeed something to question (e.g. It may be correct but is it necessary? Does it cause anyone or any engine a problem?).  It may be it’s there to support query or some other not-100%-clear usage, so hard to be definitive.

Of course all this is not intended to suggest that FOL does not solve real problems. It does, and so do more powerful logical systems. 

And I do remember the discussions we had in which you propose to treat different levels of modelness in separate graphs. That would also be an instance of punning, but one in which one can systematically separate out the different meanings in contexts that are explicitly marked as different. Still a lot to process, but at least it becomes tractable what is what when.

My general penchant is that SHACL offers a wealth of tactics to do metamodeling in a much more elegant way than with OWL (let alone punning). A good example was pointed out by Holger to me earlier today: dash:composite. I believe SHACL is seriously underused in tackling the hairier problems in information modelling on the semantic web.

Agree SHACL’s a nice language. It’s focus is data constraint rather than inference. That’s often not a problem because “adding logically inferred data to existing data” is a less common business need than “validating my existing data, and only that data”.

FWIW UML has a very similar construct to dash:composite, so it’s definitely a useful idea.

Cheers,
David

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/c471470a-12cd-436d-ba19-f5e46ba76e05%40googlegroups.com.
<Capture.PNG>

Bohms, H.M. (Michel)

unread,
Nov 20, 2019, 4:36:47 AM11/20/19
to topbrai...@googlegroups.com

 

:x is an :Eagle

:Eagle is a :Species

:Species is a owl:Class

 

clearly asserts that “:x is an instance of something that, in turn, is a species” as far as FOL interpretations are concerned. There is no inference to be made wrt x: itself.  :Eagle a owl:Class would be inferred though.

 

> that is an interesting example.....I would argue that there should be no inference here! rdf:type is not transitive I assume....

 

 

 

 

 

Blending a domain model with the modelling language itself is indeed something to question (e.g. It may be correct but is it necessary? Does it cause anyone or any engine a problem?).  It may be it’s there to support query or some other not-100%-clear usage, so hard to be definitive.

 

> that is I think covering my example of adding properties to properties (other example of than punning)

 



Of course all this is not intended to suggest that FOL does not solve real problems. It does, and so do more powerful logical systems. 

 

And I do remember the discussions we had in which you propose to treat different levels of modelness in separate graphs. That would also be an instance of punning, but one in which one can systematically separate out the different meanings in contexts that are explicitly marked as different. Still a lot to process, but at least it becomes tractable what is what when.

 

> indeed: in my example: the world of property definition and the world of property usage....

 

My general penchant is that SHACL offers a wealth of tactics to do metamodeling in a much more elegant way than with OWL (let alone punning). A good example was pointed out by Holger to me earlier today: dash:composite. I believe SHACL is seriously underused in tackling the hairier problems in information modelling on the semantic web.

 



 

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.

dprice

unread,
Nov 20, 2019, 4:38:16 AM11/20/19
to topbrai...@googlegroups.com

On 20 Nov 2019, at 09:02, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Hi Jan
 
Thx for the extra input here.
Could there still be a case for owl full (actually as I see it (?): being no restrictions on the use of RDF + added owl clauses)
Where there is no use of reasoners, say just for specification sake....(think nta option 2 ...).
 
Or would you say: if an owl reasoner cannot be applied, the semantics is actually so poor that there is no other useful application too?

To be clear, I think you mean the following:

If a DL/Direct Semantics reasoner cannot be applied, then is the semantics of the model considered too poor for a useful application?

Clearly, industry says No to that as a general question as there are FOL languages, models and tools, for example. WRT OWL itself, the RDF Semantics spec is a formal definition of what you’re calling OWL Full, so it’s semantics are clear. See https://www.w3.org/TR/owl2-rdf-based-semantics/

However, there are clearly usage scenarios where the answer is Yes (e.g. if going beyond DL means the reasoner fails and your business app somehow depends on it working and that reasoner is the best tool available to you). 

There is no always-the-case answer to these questions, just like there’s no always-the-case when deciding between using a graph database, an RDB and a Big Data tool.

Jan mentioned SHACL, and one of the best things about SHACL, and it’s predecessor SPIN, is that apps can make use of “rules” to make inferences that are not limited to a specific logic.  You can even use a programming language underneath to do complex math and use that in your inferences. 

Holger’s also got a nice demo of using Machine Learning to infer business rules from a SHACL model and data, so we’re exploring lots of tools for inferring data as part of a knowledge graph-based environment.

Cheers,
David

 
Thx Michel
 
 
 
 
 
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

dprice

unread,
Nov 20, 2019, 4:48:04 AM11/20/19
to topbrai...@googlegroups.com
On 20 Nov 2019, at 09:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 
:x is an :Eagle
:Eagle is a :Species
:Species is a owl:Class
 
clearly asserts that “:x is an instance of something that, in turn, is a species” as far as FOL interpretations are concerned. There is no inference to be made wrt x: itself.  :Eagle a owl:Class would be inferred though.
 
> that is an interesting example.....I would argue that there should be no inference here! rdf:type is not transitive I assume….

Transitivity is not the basis for the inference. rdf:type itself is the basis. Everything that is the rdfs:range of rdf:type is by-definition an owl:Class.

 
 
 
 
 
Blending a domain model with the modelling language itself is indeed something to question (e.g. It may be correct but is it necessary? Does it cause anyone or any engine a problem?).  It may be it’s there to support query or some other not-100%-clear usage, so hard to be definitive.
 
> that is I think covering my example of adding properties to properties (other example of than punning)
 


That’s a much more “interesting” discussion in the OWL/semantics world. Punning/ClassOfClass is simple by comparison. Lots of approaches depending on the specific business need.  FWIW in TopBraid EDG 6.3 the idea of “reification" is being introduced to address that business need, from the release notes:

Support for Reification

Users can now annotate facts with additional statements. This can, for example, support capturing a provenance of a business term definition or an effective date for any value. Annotations can be made for any property value – relationship or attribute. Properties that can be reified and the kind of annotations that can be made are identified in ontology models.

Technically, EDG now supports RDF* data model. Annotations can be queried in SPARQL. To ensure standards compliance and interoperability when data is exported in RDF from EDG, reified statements are exported as RDF statements.


The 6.3 Beta is available for download.

Cheers,
David


Of course all this is not intended to suggest that FOL does not solve real problems. It does, and so do more powerful logical systems. 
 
And I do remember the discussions we had in which you propose to treat different levels of modelness in separate graphs. That would also be an instance of punning, but one in which one can systematically separate out the different meanings in contexts that are explicitly marked as different. Still a lot to process, but at least it becomes tractable what is what when.
 
> indeed: in my example: the world of property definition and the world of property usage....
 
My general penchant is that SHACL offers a wealth of tactics to do metamodeling in a much more elegant way than with OWL (let alone punning). A good example was pointed out by Holger to me earlier today: dash:composite. I believe SHACL is seriously underused in tackling the hairier problems in information modelling on the semantic web.
 


 
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.

Bohms, H.M. (Michel)

unread,
Nov 20, 2019, 5:45:08 AM11/20/19
to topbrai...@googlegroups.com

Thx very clear.

And indeed I was thinking too: if I go owl full (adding properties next to rdfs:domain etc.), ok my DL reasoner breaks but I can still do many usefull shacl/sparql things...

 

General subissue: we always talk about RDF and OWL (and OWL full having RDF semantics) but how does RDFS exactly fit in here?

Guess RDFS is in no way influencing the use of RDF semantics (ie not constraining like owl dl)?

 

Gr michel

 

 

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

+31888663107
+31630381220
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.

 

 

 

 

Bohms, H.M. (Michel)

unread,
Nov 20, 2019, 5:57:30 AM11/20/19
to topbrai...@googlegroups.com



On 20 Nov 2019, at 09:36, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

 

:x is an :Eagle

:Eagle is a :Species

:Species is a owl:Class

 

clearly asserts that “:x is an instance of something that, in turn, is a species” as far as FOL interpretations are concerned. There is no inference to be made wrt x: itself.  :Eagle a owl:Class would be inferred though.

 

> that is an interesting example.....I would argue that there should be no inference here! rdf:type is not transitive I assume….

 

Transitivity is not the basis for the inference. rdf:type itself is the basis. Everything that is the rdfs:range of rdf:type is by-definition an owl:Class.


> AHH, of course...not because x a y a z means x a z!

 

 

 

 

 

Blending a domain model with the modelling language itself is indeed something to question (e.g. It may be correct but is it necessary? Does it cause anyone or any engine a problem?).  It may be it’s there to support query or some other not-100%-clear usage, so hard to be definitive.

 

> that is I think covering my example of adding properties to properties (other example of than punning)

 

 

 

That’s a much more “interesting” discussion in the OWL/semantics world. Punning/ClassOfClass is simple by comparison. Lots of approaches depending on the specific business need.  FWIW in TopBraid EDG 6.3 the idea of “reification" is being introduced to address that business need, from the release notes:

Support for Reification

Users can now annotate facts with additional statements. This can, for example, support capturing a provenance of a business term definition or an effective date for any value. Annotations can be made for any property value – relationship or attribute. Properties that can be reified and the kind of annotations that can be made are identified in ontology models.

Technically, EDG now supports RDF* data model. Annotations can be queried in SPARQL. To ensure standards compliance and interoperability when data is exported in RDF from EDG, reified statements are exported as RDF statements.

> that is very interesting!! Do you actually now support rdf:statement or really the RDF* extension?

> this dev. could even shine new light on our current modelling choices involing objectification I guess....(now needed because of meta-data needs and current rdf reification having issues)

 

The 6.3 Beta is available for download.

 

Cheers,

David





Of course all this is not intended to suggest that FOL does not solve real problems. It does, and so do more powerful logical systems. 

 

And I do remember the discussions we had in which you propose to treat different levels of modelness in separate graphs. That would also be an instance of punning, but one in which one can systematically separate out the different meanings in contexts that are explicitly marked as different. Still a lot to process, but at least it becomes tractable what is what when.

 

> indeed: in my example: the world of property definition and the world of property usage....

 

My general penchant is that SHACL offers a wealth of tactics to do metamodeling in a much more elegant way than with OWL (let alone punning). A good example was pointed out by Holger to me earlier today: dash:composite. I believe SHACL is seriously underused in tackling the hairier problems in information modelling on the semantic web.

 




 

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/663cc4990f1a4c048f13630a8c0e58fe%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.

dprice

unread,
Nov 20, 2019, 6:15:52 AM11/20/19
to topbrai...@googlegroups.com

On 20 Nov 2019, at 10:45, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Thx very clear.
And indeed I was thinking too: if I go owl full (adding properties next to rdfs:domain etc.), ok my DL reasoner breaks but I can still do many usefull shacl/sparql things...
 
General subissue: we always talk about RDF and OWL (and OWL full having RDF semantics) but how does RDFS exactly fit in here?

RDFS has a interpretation spec, which is therefore “included" in what OWL interpretation spec says since OWL subsumes all of RDFS, but it’s not necessary to use OWL in order to use (or reuse) RDFS. In fact the RDFS spec says:

This specification does not attempt to enumerate all the possible forms of representing the meaning of RDF classes and properties. Instead, the RDF Schema strategy is to acknowledge that there are many techniques through which the meaning of classes and properties can be described. Richer vocabulary or 'ontology' languages such as OWL [OWL2-OVERVIEW], inference rule languages and other formalisms (for example temporal logics) will each contribute to our ability to capture meaningful generalizations about data in the Web.

Formal interpretation spec is at:



Guess RDFS is in no way influencing the use of RDF semantics (ie not constraining like owl dl)?

Correct. In fact the spec says:

This document is intended to provide a clear specification of RDF Schema to those who find the formal semantics specification [RDF11-MT] daunting. Thus, this document duplicates material also specified in the RDF Semantics specification. Where there is disagreement between this document and the RDF Semantics specification, the RDF Semantics specification should be taken to be correct.


Cheers,
David


 
Gr michel
 
 
 
 
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

Bohms, H.M. (Michel)

unread,
Nov 20, 2019, 6:31:52 AM11/20/19
to topbrai...@googlegroups.com

.....

Guess RDFS is in no way influencing the use of RDF semantics (ie not constraining like owl dl)?

 

Correct. In fact the spec says:

 

This document is intended to provide a clear specification of RDF Schema to those who find the formal semantics specification [RDF11-MT] daunting. Thus, this document duplicates material also specified in the RDF Semantics specification. Where there is disagreement between this document and the RDF Semantics specification, the RDF Semantics specification should be taken to be correct.

> and also a good hint at that is there:

 

“RDFS does not partition the universe into disjoint categories of classes, properties and individuals. Anything in the universe can be used as a class or as a property, or both, while retaining its status as an individual which may be in classes and have properties. Thus, RDFS permits classes which contain other classes, classes of properties, properties of classes, etc. As the axiomatic triples above illustrate, it also permits classes which contain themselves and properties which apply to themselves. A property of a class is not necessarily a property of its members, nor vice versa.”

Irene Polikoff

unread,
Nov 20, 2019, 7:35:09 AM11/20/19
to topbrai...@googlegroups.com
I would think rdfs:Class, not owl:Class.

dprice

unread,
Nov 20, 2019, 8:23:50 AM11/20/19
to topbrai...@googlegroups.com
Because of things like “owl:Thing rdf:type owl:Class”, owl:disjointWith rdfs:domain/rdfs:range owl:Class, etc. I think it's owl:Class, but I’ve never looked at a specific reasoner’s behaviour in detail. May even vary from reasoner to reasoner.

Cheers,
David

--
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.

Irene Polikoff

unread,
Nov 20, 2019, 7:24:47 PM11/20/19
to topbrai...@googlegroups.com
RDFS says:

rdf:type rdfs:range rdfs:Class.

Given

:x a :Eagle.
:Eagle a :Species.
:Species a owl:Class.

A tool that implements RDFS inferencing will conclude

:Eagle a rdfs:Class.
:Species a rdfs:Class.

If you add OWL into the mix, you may get

:Species rdfs:subClassOf owl:Thing.
:Eagle a owl:Thing.
owl:Nothing rdfs:subClassOf :Eagle.

Possibly, :Eagle a owl:NamedIndividual. I believe it has the same class extension as owl:Thing.

I can’t think of any other inferences entailed by the 3 triples above.

To be clear, I would not recommend this approach to data modeling. I also have to admit that I find this discussion pretty esoteric and largely irrelevant.

Irene Polikoff

unread,
Nov 20, 2019, 7:29:31 PM11/20/19
to topbrai...@googlegroups.com
Typo correction below

owl:Nothing rdfs:subClassOf :Species.

On Nov 20, 2019, at 7:24 PM, Irene Polikoff <ir...@topquadrant.com> wrote:

RDFS says:

rdf:type rdfs:range rdfs:Class.

Given

:x a :Eagle.
:Eagle a :Species.
:Species a owl:Class.

A tool that implements RDFS inferencing will conclude

:Eagle a rdfs:Class.
:Species a rdfs:Class.

If you add OWL into the mix, you may get

:Species rdfs:subClassOf owl:Thing.
:Eagle a owl:Thing.
owl:Nothing rdfs:subClassOf :Species.

Bohms, H.M. (Michel)

unread,
Nov 21, 2019, 3:03:08 AM11/21/19
to topbrai...@googlegroups.com

 

Hi Irene,

 

Wrt your To be clear, I would not recommend this approach to data modeling. I also have to admit that I find this discussion pretty esoteric and largely irrelevant.”

 

 

We find this pattern/need very often in practice (multi-level typing). Catalogue products beings instances that are instantiated again for a client, properties defined with meta-data, instantiated again for actual properties of things, etc. etc. People use very different ways of dealing with it using punning, rdf:Property as range, objectproperties iso rdf:type having similar semantic intentions etc. etc. So I guess its important to know for certain variants what is actually inferred or not etc. I was glad the issue was brought up (again) by Jan. The start of the issue was actually a question of some clients on how to best combine say RDFS/OWL and SKOS since sometimes the thing modelled then could be both an instance and a class and the w3c spec sayd his would lead to owl full which might have been true for owl1 but not for owl2.

 

Greetings Michel

 

 

 

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

+31888663107
+31630381220
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 Irene Polikoff
Verzonden: Thursday, November 21, 2019 1:25 AM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] Re: combining owl and skos

 

RDFS says:

Jan Voskuil

unread,
Nov 21, 2019, 3:51:03 AM11/21/19
to TopBraid Suite Users
The bottom line is that you should try this in TBC. Create the classes CarModel,BMW320i and TeslaModelS. Assert that the latter two instantiate the first. Create instances of the BMW and the Tesla. Define some properties for CarModel.

TBC will not display the properties on the instance forms. This behaviour is typical of introspective tools. 

Therefore, in my opinion at least, it would be a bad idea to promote metaclasses and punning as a viable pattern in proposed standards like NEN8035. Level 2 and 3 property modelling (objectified and doubly objectified properties) do not at all require metaclasses, they can be easily modelled within DL using standard patterns that everybody understands, and that are supported by generic tools. Level 2 and 3 add complexity as a trade-off against expressivity. 

There is no such thing as a free lunch. The clever ways people come up with to obtain L2 expressivity without the complexity invariably involve punning. If anything, however, punning introduces much more complexity than most people are aware of. I guess this is why the punning discussion keeps coming up, and why we need to continue arguing against it. Of course while keeping in mind that patterns such as those David proposes do have value in the specific cases they are designed for.

David



To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

--
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 topbrai...@googlegroups.com.

--
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 topbrai...@googlegroups.com.

Bohms, H.M. (Michel)

unread,
Nov 21, 2019, 4:23:51 AM11/21/19
to topbrai...@googlegroups.com

 

Thx Jan

 

Current NTA pattern for L2 has no punning. Your alternative (option 3) also hasnt. Only alternative option 2 does I guess.

 

Well it has:

 

ex:height a owl:DatatypeProperty ;

  bsc:hasQuantityKind quantitykind:Length ;

  bsc:hasUnit unit:M ;

  rdfs:range xsd:decimal .

 

which I guess has at least similar effects like punning. (?).

 

Still quite some people like the option 2 (since it does need less own language-level things as in option 1 and also no restriction-way of modelling metadata as in option 3). Just collecting good arguments why option 2 is no good idea as alternative for 1.

 

gr michel

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/761611f4-fc56-435f-8bdc-3421e24a0acd%40googlegroups.com.

Jan Voskuil

unread,
Nov 21, 2019, 5:00:04 AM11/21/19
to TopBraid Suite Users
The problem with the snippet is that it is not L2 at all.
With L2 we objectify properties so that we can ad extra information about the property object instance.
For instance, "observed by Paul", "has low reliability".
Tying in with this is Jesse's observation about it being desirable to add information about units at the same instance level, not at the class level (following best practices used at the Kadaster, but also in OpenPHACTS).

The snippet below says that in all cases where ex:height is used, the unit is meter. (Not at the class level, but at the property instance level, which may sound confusing ---- just note that ex:height is an instance of owl:DatatypeProperty).

In the original example I think someone wrote { ex:height ex:isObservedBy "Paul" }. This then holds for all occurrences of ex:height, which is obviously not what is intended. 

Thus, the example is an L1 model. -j

dprice

unread,
Nov 21, 2019, 6:21:26 AM11/21/19
to topbrai...@googlegroups.com
Hi Jan,

I did what you said and Composer 6.3 Beta shows me the property and lets me set the value:


carModelName is defined like this:

unnamed:carModelName
  rdf:type owl:DatatypeProperty ;
  rdfs:domain unnamed:CarModel ;
  rdfs:range xsd:string ;
.

I do not understand the specific references to standards being made in your change with Michel, but Composer does support punning (i.e. creating classes with properties that are members of other classes where those properties are defined).

Cheers,
David

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/761611f4-fc56-435f-8bdc-3421e24a0acd%40googlegroups.com.

Jan Voskuil

unread,
Nov 21, 2019, 6:33:22 AM11/21/19
to topbrai...@googlegroups.com

Yes, when you are looking at the form for the BMW class (individual).

But now make an instance of the BMW called “CarDavid” and look at the form.

The properties defined for CarModel are not shown. -j

 

# baseURI: http://www.example.org/punning_example

# prefix: pex

 

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix pex: <http://www.tooi.org/punning_example#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

 

<http://www.example.org/punning_example>

  a owl:Ontology ;

  owl:versionInfo "Created with TopBraid Composer" ;

.

pex:BMW-320i

  a pex:CarModel ;

  a owl:Class ;

  pex:listPrice 29000 ;

  rdfs:subClassOf owl:Thing ;

.

pex:CarModel

  a owl:Class ;

  rdfs:subClassOf owl:Thing ;

.

pex:CarSandeep

  a pex:TeslaModelS ;

.

pex:CarStella

  a pex:BMW-320i ;

.

pex:TeslaModelS

  a pex:CarModel ;

  a owl:Class ;

  rdfs:subClassOf owl:Thing ;

.

pex:fiscalValue

  a owl:DatatypeProperty ;

  rdfs:domain pex:BMW-320i ;

  rdfs:range xsd:decimal ;

.

pex:listPrice

  a owl:DatatypeProperty ;

  rdfs:domain pex:CarModel ;

  rdfs:range xsd:integer ;

.

Jan Voskuil

unread,
Nov 21, 2019, 6:38:32 AM11/21/19
to topbrai...@googlegroups.com
(Sorry, the prefix mapping pex needs to be fixed)

Sent from my iPhone

On 21 Nov 2019, at 12:33, Jan Voskuil <jan.v...@taxonic.com> wrote:



<image001.png>

dprice

unread,
Nov 21, 2019, 7:45:22 AM11/21/19
to topbrai...@googlegroups.com
Hi Jan,

My test in 6.3: 
I’d made a class called ActualCar and assigned it as domain of properties. I did that since CarModel instances may come and go but actual cars share many properties you don’t want to redefine all the time (e.g. build date or identification number).
I then made instances of CarModel also be subclasses of ActualCar and it all worked just fine in Composer 6.3 Beta.

To test your problem I started 6.2.5:

Opened punning example and tried deleting the punning bits until I could get it to work so I could figure out the cause. 
I never did because there’s something odd happening … the form doesn’t show the pex:fiscalValue even after I’ve deleted everything related to punning.

I started 6.3 Beta and tried your full punning example … it works fine.

Jan - I think you’ve been the victim of an odd bug in Composer 6.2.x for this edge case that’s fixed in 6.3 Beta.

Cheers,
David


<image001.png>

Irene Polikoff

unread,
Nov 21, 2019, 7:58:50 AM11/21/19
to topbrai...@googlegroups.com
Michel,

I am not aware of any real life, production applications that use DL reasoning. Thus, I do not see the question about what may be inferred by such reasoner, as very practical. On the other hand, the meaning of OWL and RDFS statements (how they should be interpreted) is defined in terms of inference entailment. DL vs Full is not really that important. The meaning does not change.

If someone builds a custom application that works against a model they develop, they control the behavior of that application and can make it interpret the model anyway they decide.

If they expect some off the shelf software to be able to work well with such models and interpret the model and data in the way they think it should be interpreted, they may be disappointed. If they expect others, outside of their group, to understand the meaning of their model and data, they may also be disappointed. They may also run into some walls and create unnecessary complexities that will require various inventions, solutions and workarounds.

I agree with the points made by Jan.

Further, I believe in most cases models like this are created because 1) creators do not understand the Semantic Web standards and the modeling patterns/options available to them 2) creators starting point was a model built using some other modeling framework/language that did not have the same options and semantics as let’s say OWL or even RDF. They do a one to one conversion without rethinking how it may be different given a different semantic system.

On Nov 21, 2019, at 3:03 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

Hi Irene,

 

Wrt your To be clear, I would not recommend this approach to data modeling. I also have to admit that I find this discussion pretty esoteric and largely irrelevant.”

 

 

We find this pattern/need very often in practice (multi-level typing). Catalogue products beings instances that are instantiated again for a client, properties defined with meta-data, instantiated again for actual properties of things, etc. etc. People use very different ways of dealing with it using punning, rdf:Property as range, objectproperties iso rdf:type having similar semantic intentions etc. etc. So I guess its important to know for certain variants what is actually inferred or not etc. I was glad the issue was brought up (again) by Jan. The start of the issue was actually a question of some clients on how to best combine say RDFS/OWL and SKOS since sometimes the thing modelled then could be both an instance and a class and the w3c spec sayd his would lead to owl full which might have been true for owl1 but not for owl2.

 

Greetings Michel

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

+31888663107
+31630381220
michel...@tno.nl

Location

 

Jan Voskuil

unread,
Nov 21, 2019, 8:17:44 AM11/21/19
to topbrai...@googlegroups.com

David, Thanks for digging, but I have been running 6.3 all the time.

The scenario you describe works because you avoid the block posed by the triple sequence of rdf:type by using multiple inheritance. That’s a good way of avoiding the block, but it shows nothing that is of service.

 

In the example graph I sent, the idea is that listPrice is a general property that every individual (at the lowest level of modelness) should have. Therefore, it has CarModel as domain. As expected, it does not show up in CarSandeep or CarStella.

 

(Of course it does show up in the forms for individuals one level up in the modelness hierarchy: BMW320i does have a listPrice, as does TeslaModelS).

 

I defined fiscalValue as a property with BMW320i as domain, so it is expected to show up in CarStella (which is a BMW) but not in CarSandeep (which is a Tesla).

 

So if I want listPrice to show up at the lowest level, then I must define its domain as the union of all classes that are an instance of CarModel. Defining the domain as the class CarModel does not work. Best, -j

Bohms, H.M. (Michel)

unread,
Nov 21, 2019, 8:38:22 AM11/21/19
to topbrai...@googlegroups.com

What I replied earlier:

 

rdf:type is I assume non-transitive

a type b type c does not imply a type c, so there is no inheritance from c to a.

(and yes the multiple inheritance by David corrects that but also changes the model)

 

Enabling inheritance (for the same model) would indeed ask for a union of classes having this property instead of its metaclass

dprice

unread,
Nov 21, 2019, 8:44:27 AM11/21/19
to topbrai...@googlegroups.com
Not sure what version of 6.3 you’re running, but in Beta this is what I see with your punning example. The edit is because I added a value, I did not change your model other than to fix the prefix.






As Irene said, this edge case is not typical of what industry does. For example, in the real world the apps/people who manage the CarModel instances are not the apps/people who manage the data about actual cars. So, this example is not “real” in any sense. In most cases, lots of processing would be necessary to take the “class library” that is the CarModel instances and use that as the basis for a useful app for people managing data about actual cars.

At the moment, we’re just talking about technical features of Composer. I still don’t quite understand what you think isn’t working in 6.3 Beta, but if you/Michel want to figure that out I suggest we do that *outside* this forum since we’re definitely into the weeds wrt most people’s needs.

i.e. Let’s end this here and if there are specific concerns please just email me outside this forum.

Cheers,
David

Bohms, H.M. (Michel)

unread,
Nov 21, 2019, 9:02:01 AM11/21/19
to topbrai...@googlegroups.com

Wrt your

As Irene said, this edge case is not typical of what industry does. For example, in the real world the apps/people who manage the CarModel instances are not the apps/people who manage the data about actual cars. So, this example is not “real” in any sense. In most cases, lots of processing would be necessary to take the “class library” that is the CarModel instances and use that as the basis for a useful app for people managing data about actual cars.

 

This is very true BUT it gives a lot of problems.

 

Within one organization we work for there are 2 groups of people reflecting these 2 worlds. Doing their thing without even knowing each other.

This is really a missed opportunity since the instances of the one are the classes of the other. True knowledge and data modelling integration has to combine them and reuse each others views. At least that is what we are trying to promote...but then we unfort. run into this multi-type level modelling with all its issues.....

 

The knowledge guys are modelling inspection techniques for a type of bridge. The other guys are modelling a specific bridge. Clearly we want the knowledge of inspection techniques to become available to the actual bridges in NL.....well it is exactly the BMW type/instance modelling situation now for bridges....

 

So also here the inheritance situation is very important: can I assume a optimal inspection technique for a certain damagetype for a steel bridge is also inherted by our Van Brienenoord Bridge? Or do I have to define a union of all types of bridges first, or...etc.

 

Gr michel

Bohms, H.M. (Michel)

unread,
Nov 21, 2019, 9:04:44 AM11/21/19
to topbrai...@googlegroups.com

Irene

 

I have the feeling we are not understanding each other.

 

I will try to go bottom up.

 

For a standard we are trying to provide a pattern for (complex) property modelling that enables the modelling of meta-properties on instance level (height123 measuredby Irene) and definition level (height hasQuantityKind Length)

Besides that we also want to provide a simple variant using directly the language constructs, hence in owl:owl:Datatype property (sometimes people are not interested in meta-data at all).

 

We now have three options on the table:

Option 1 is currently proposed in standard (influenced by the current way of modelling properties in IFC of buildingSmart International).

Essence of complex: we define a class Property and a class PropertyDef. The first one is instantiated with height123, the second with height. The latter is related via an objectproperty to the def. The first one is what we call objectification to compensate for current RDF power. This is also what W3C LBD OPM calls level 2(1xobjectification)

Option 2 was proposed by a Dutch software vendor called Semmtech.

Essence of complex: skip the PropertyDef. Simply refer via the hasPropertyDef to the simple variant! But than the meta data has to be put at a datatype property (hencfe my questions on use of reasoners etc.)

Option 3 was proposed by Taxonic/Jan.

Essence: also skip PropertyDef and subclass Property into Height and specify def.level metadata as constraints (esp. in shacle).

 

Technically they are all possible but having pro and cons wrt:

- use of reasoners

- reuse of existing language elements

- simplicity

- etc. etc.

 

And yes, by even asking these questions I would qualify as creators do not understand the Semantic Web standards and the modeling patterns/options available to them” (since I did not start from another modelling language) but I happily run this risk hoping for an open world interpretation allowing some third category 😊

 

Michel

 

 

 

 

 

 

 

 

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

+31888663107
+31630381220
michel...@tno.nl

Location

 

cid:image001.gif@01D5A078.597D6F10

ALT-ComplexPropertyPatterns.docx

dprice

unread,
Nov 21, 2019, 9:19:13 AM11/21/19
to topbrai...@googlegroups.com
Hi Michel,

Seems your org may have some deep and interesting issues to confront.

At this stage, my point is mainly that this forum is not the appropriate venue for serious discussion of those issues to happen.

Your reply to Irene in a separate email that:

I have the feeling we are not understanding each other.

is clear evidence of that fact.

Cheers,
David

On 21 Nov 2019, at 14:01, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Wrt your
As Irene said, this edge case is not typical of what industry does. For example, in the real world the apps/people who manage the CarModel instances are not the apps/people who manage the data about actual cars. So, this example is not “real” in any sense. In most cases, lots of processing would be necessary to take the “class library” that is the CarModel instances and use that as the basis for a useful app for people managing data about actual cars.
 
This is very true BUT it gives a lot of problems.
 
Within one organization we work for there are 2 groups of people reflecting these 2 worlds. Doing their thing without even knowing each other.
This is really a missed opportunity since the instances of the one are the classes of the other. True knowledge and data modelling integration has to combine them and reuse each others views. At least that is what we are trying to promote...but then we unfort. run into this multi-type level modelling with all its issues.....
 
The knowledge guys are modelling inspection techniques for a type of bridge. The other guys are modelling a specific bridge. Clearly we want the knowledge of inspection techniques to become available to the actual bridges in NL.....well it is exactly the BMW type/instance modelling situation now for bridges....
 
So also here the inheritance situation is very important: can I assume a optimal inspection technique for a certain damagetype for a steel bridge is also inherted by our Van Brienenoord Bridge? Or do I have to define a union of all types of bridges first, or...etc.
 
Gr michel
 
 
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

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 dprice
Verzonden: Thursday, November 21, 2019 2:44 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] Re: combining owl and skos
 
Not sure what version of 6.3 you’re running, but in Beta this is what I see with your punning example. The edit is because I added a value, I did not change your model other than to fix the prefix.
 
<image004.png>

Jan Voskuil

unread,
Nov 21, 2019, 9:25:41 AM11/21/19
to topbrai...@googlegroups.com

Agree, let’s not use this forum, and the screenshot shows: no listPrice in the form, because this is defined as a property of CarModels. -j

Irene Polikoff

unread,
Nov 21, 2019, 9:26:42 AM11/21/19
to topbrai...@googlegroups.com
As David said, transformation will be required.

Using the same URI for conceptually different things (a specification or design of a bridge, a set of all bridges based on a given design and a specific bridge) is not the best way to connect these worlds.

Given the need for the transformation, you can use the conceptual model instance to create a new class resource. Let’s say a class of Eagles and use a property of your choice to connect it with the Eagle that is an instance of a class Species. 

You can then specify characteristics and parameters intended for the class at the Eagle specie level as normal RDF triples. For example, the fact that eagles can have weight. You do need a model for making such statements because you may need to be able to specify a datatype, number if possible cakes, etc.

 In creating Eagle class, you could then transform them into appropriate class/property constraints on the class.

You can also use the connection between the instance of a specie and a class to infer anything you see as needed to be inferred. Yes, this will require specific rules. And you could use it to check instances of the class for their conformance to the spec e.g., given that Eagle as a specie has an average weight, does my Eagle’s weight fall in that range? 

A straight inheritance of such value would make no sense. The average or min/max weight of my Eagle is not the average or a range for the specie. If such values were tracked, they would be the average and min/max over the lifespan of my Eagle.



On Nov 21, 2019, at 9:01 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Wrt your

As Irene said, this edge case is not typical of what industry does. For example, in the real world the apps/people who manage the CarModel instances are not the apps/people who manage the data about actual cars. So, this example is not “real” in any sense. In most cases, lots of processing would be necessary to take the “class library” that is the CarModel instances and use that as the basis for a useful app for people managing data about actual cars.

 

This is very true BUT it gives a lot of problems.

 

Within one organization we work for there are 2 groups of people reflecting these 2 worlds. Doing their thing without even knowing each other.

This is really a missed opportunity since the instances of the one are the classes of the other. True knowledge and data modelling integration has to combine them and reuse each others views. At least that is what we are trying to promote...but then we unfort. run into this multi-type level modelling with all its issues.....

 

The knowledge guys are modelling inspection techniques for a type of bridge. The other guys are modelling a specific bridge. Clearly we want the knowledge of inspection techniques to become available to the actual bridges in NL.....well it is exactly the BMW type/instance modelling situation now for bridges....

 

So also here the inheritance situation is very important: can I assume a optimal inspection technique for a certain damagetype for a steel bridge is also inherted by our Van Brienenoord Bridge? Or do I have to define a union of all types of bridges first, or...etc.

 

Gr michel

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

+31888663107
+31630381220
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 dprice
Verzonden: Thursday, November 21, 2019 2:44 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] Re: combining owl and skos

 

Not sure what version of 6.3 you’re running, but in Beta this is what I see with your punning example. The edit is because I added a value, I did not change your model other than to fix the prefix.

 

<image004.png>

Irene Polikoff

unread,
Nov 21, 2019, 9:42:16 AM11/21/19
to topbrai...@googlegroups.com
Agree with David and Jan.

There are various options and possibilities with pros and cons.

The forum is not the right vehicle for such discussions. I am assuming that conversations you are having about design options with your colleagues and Semtech are not primarily through sone email group forum. This is just ineffective.

If you are interested in TQ consulting on model design or other topics, this could be arranged.

If you are interested in using TQ products to support a project and need a demo/PoC, this can also be arranged - for EDG. We do not normally do it for TBC.

The best approach to initiate these conversations is by contacting sales.

If you want to have some deep interactions on this topic with either Jan or David as individuals because you share interests, this would likely involve more than emails and should be arranged directly with them.
<ALT-ComplexPropertyPatterns.docx>

Bohms, H.M. (Michel)

unread,
Nov 21, 2019, 9:46:13 AM11/21/19
to topbrai...@googlegroups.com

 

Hi David

 

Too easy....

 

But ok, over and out.

Bohms, H.M. (Michel)

unread,
Nov 21, 2019, 10:07:40 AM11/21/19
to topbrai...@googlegroups.com

 

As David said, transformation will be required.

 

> yes, this is one of the options we have (delete one rdf:type and build a promotor )

> this as an potential approach we harmonize with a GIS-based standard in NL that starts with MOF instantiates UML and LD meta en then promotes the MOF instances to a metamodel, seame trick on next layer till data.

 

> if there is one thing I learned from our discussion is that for:

 

CarModel / BridgeModel a class

a

Tesla / Van Brienenoord a class

a

MyTesla

 

The Tesla seems one but is having two faces each facing a different world (intension versus extension).

 

> thx for your tips here

 

A straight inheritance of such value would make no sense. The average or min/max weight of my Eagle is not the average or a range for the specie. If such values were tracked, they would be the average and min/max over the lifespan of my Eagle.

> I agree.....

> thx MIchel

David






https://groups.google.com/group/topbraid-users/attach/4a0389c7b9c83/image001.gif?part=0.1&view=1&authuser=0

Rob Atkinson

unread,
Nov 21, 2019, 6:06:09 PM11/21/19
to TopBraid Suite Users


Accepting this isnt the right forum, there are some interesting and important architectural issues here - so what is the right forum (where TQ architects can be engaged to either explain best practices or consider roadmap)

I'll take the opportunity to point to some W3C work I've been involved with, which is aimed at enabling Linked Data environments to expose the same objects using different data models (aka "profiles") - https://w3c.github.io/dxwg/connegp/

 in my view the issue of transformability to useful forms and reasoning envelopes needs to be separated from graph closure with owl imports - use owl:imports only for the profile of OWL you wish to support - and explore virtualisation of graphs via transformations for other purposes.

for example - using a SKOS visualisation (or a EDG lineagegram for that matter) is perfectly sensible for a SKOS view of an rdfs: class hierarchy (skos:Concepts are conceptually broader then RDFS or OWL Classes)

TBC already has all the tools - SHACL transforms, and SparqlMotion which has a virtual graph reflecting execution state, and ui:spin tempGraphs etc - AFAICT it just lacks a means to surface virtual graphs and metadata about them.


RA
On Wednesday, 9 October 2019 02:31:08 UTC+11, Bohms, H.M. (Michel) wrote:

 

In:

https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html

 

its is said:

To illustrate these patterns, let's start with the following semi-formal conceptualisation:

ex:mountains rdf:type skos:Concept;

  skos:prefLabel "Mountains"@en.

 

ex:himalayas rdf:type skos:Concept;

  skos:prefLabel "Himalayas"@en;

  skos:broader ex:mountains.

 

ex:everest rdf:type skos:Concept;

  skos:prefLabel "Everest"@en;

  skos:broader ex:himalayas.

Overlay SKOS with OWL

In this pattern, we use OWL to overlay additional semantics on the same vocabulary, e.g. by adding the following triples:

ex:mountains rdf:type owl:Class.

 

ex:himalayas rdf:type owl:Class;

  rdfs:subClassOf ex:mountains.

 

ex:everest rdf:type ex:himalayas.

If the two sets of triples are merged, then this pattern necessarily leads to an OWL Full representation, because an instance of skos:Concept might also be an instance of owl:Class.

 

 

Is the red statement really true? And if yes, is it really an issue here?

 

(maybe it was under owl1 but under owl2 not different?)

 

thx for advice, Michel

 

 

 

 

Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

+31888663107
+31630381220
michel...@tno.nl

Location

 

Irene Polikoff

unread,
Nov 23, 2019, 2:19:52 AM11/23/19
to topbrai...@googlegroups.com
Hi Rob,

The best way to submit requirements is through the support portal that you have access to. Customer and partner requirements are key inputs to the roadmap.

Once you submit a specific requirement, we get in touch to clarify it as needed.

With respect to best practices, we do our best to communicate these through a variety of means - webinars, videos, training materials, documentation and also in answering questions on this forum. However, the devil is in details. The application of best practices becomes most clear when discussed in a context of a specific solution and its needs. The more concrete, the better. With EDG customers, we can engage in deeper conversations with more bandwidth - the use cases have more commonality and the support cost structure allows us to do this. With TBC customers such deep individual conversations are typically not possible without a project that can fund them.

As for the original topic of this conversation, SHACL is a great tool for defining different views into resources. You can create different Node Shapes that are targeting the same resource. If you have been playing with 6.3, you have probably already seen that the same graph can be queried using different shapes.


I do, however, think that applying different shapes to a resource is best to be limited to a situation when it is a conceptually the same resource and we simply need different views into it. 

Examples in this e-mail thread were about different resources. Eagle as an instance of a specie is not the same as a set of all eagles in the world. A car design/model is not the same as a set of cars of that design/model. Influenza as a disease is not the same as all occurrences of influenza sicknesses in specific people. Mt. Everest is not a member of a class Himalayas. These are related things, but they are not the same and relationship between them is not rdf:type and it is not rdfs:subClassOf. Himalayas is a mountain range. Mountain ranges contain peaks. Mt. Everest is a mountain peak that is part of Himalayas range. When we use skos:broader, we can organize different things in different ways for whatever purposes we need. We can combine in a single taxonomy different relationships. The ontological commitment of skos:broader is minimal. rdf:type and rdfs:subClassOf, on the other hand, carry very specific ontological commitments.

I know that there are people who find these differences and distinctions obvious. I also know that there are people who do not. Some philosophers (like Barry Smith, for example) made a career, a life long work of explaining that a set of physical occurrences of some phenomena in a world is different (and belongs to a different ontological space) from a description of the phenomena. The fact that books are written and continue to be written on this topic means that not everyone finds this difference intuitively clear. People who do not, may believe that using the same URI will make things simpler and will somehow solve some problems. One e-mail from me or a long chain of e-mails or even long conversations face to face, will not change this. 

I want to be practical. Whatever we specify in models will always, by definition, be a reduction of the real world. If it makes achieving some goals easier and still serves the needs, by all means - go for it. I do not think that in this case it does make anything easier. I see no benefit in reusing the same URIs for different things. On contrary, practically speaking, I see downsides to doing this. I also think that giving them different URIs is not hard. With semantic standards, we have a lot of flexibility, richness and power. We can easily connect these resources without requiring the use of the same URIs. If I am asked for a design advice, my advice will be based on this view. Other people are free to approach solving their design problems in a different way. 

With respect to virtual graphs, there is always a question of how much transformation is needed, how quickly it needs to be done, how large is data involved, etc. TopBraid EDG supports property value rules using SHACL. These are dynamic transformations and they are a great tool for our customers in some use cases. 

Regards,

Irene

--
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.

Rob Atkinson

unread,
Nov 24, 2019, 2:31:25 AM11/24/19
to TopBraid Suite Users
Thanks Irene

will aim to submit a requirement once I've had more experience with the grahpqL stuff in 6.3 :-)
Reply all
Reply to author
Forward
0 new messages