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
|
|||||||||||||||||
|
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.
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.
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.
--
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/f0949410-8879-47a8-96a7-535938ec117b%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f0949410-8879-47a8-96a7-535938ec117b%40googlegroups.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.
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)
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/46867241-2A13-43E7-9DE2-33942F6FCC93%40topquadrant.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?
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:ClassEagle-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.
:x rdf:type :Eagle rdf:type :Species rdf:type owl:Class
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.
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 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>
: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.
On 20 Nov 2019, at 09:02, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:Hi JanThx 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
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b8a57330f4cb4fe3bda600a863bf6407%40tno.nl.
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….
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)
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.
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.
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
|
|||||||||||||||||
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D243ECC7-47D3-4628-B8E2-CD95EC3A74C9%40topquadrant.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/FE61B72C-3CC3-4FE6-B4C2-3F32112C1A04%40topquadrant.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?
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.
Guess RDFS is in no way influencing the use of RDF semantics (ie not constraining like owl dl)?
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.
Gr michel
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2f1de15a3b1d4759948ab67af197f8e7%40tno.nl.
.....
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.”
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4C0D516A-08C0-40BC-AC9E-B3859893916B%40topquadrant.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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/141FBB70-87C7-4838-8187-7355B2559387%40topquadrant.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/59C5654B-C504-4DEA-B6C0-9B589B8158BD%40topquadrant.com.
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.
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
|
|
|
|||||||||
|
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:
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/81C29C1A-50BD-4AFA-A7EF-8C85428056A4%40topquadrant.com.
David
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/141FBB70-87C7-4838-8187-7355B2559387%40topquadrant.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/59C5654B-C504-4DEA-B6C0-9B589B8158BD%40topquadrant.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.
Thx Jan
Current NTA pattern for L2 has no punning. Your alternative (option 3) also hasn’t. 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/761611f4-fc56-435f-8bdc-3421e24a0acd%40googlegroups.com.
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.
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 ;
.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/F0763C1F-8664-437C-9121-6328922872EA%40topquadrant.com.
On 21 Nov 2019, at 12:33, Jan Voskuil <jan.v...@taxonic.com> wrote:
<image001.png>
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/AM4PR0301MB2131985419CF4448D71F7947E94E0%40AM4PR0301MB2131.eurprd03.prod.outlook.com.
<image001.png>
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/AM4PR0301MB2131985419CF4448D71F7947E94E0%40AM4PR0301MB2131.eurprd03.prod.outlook.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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/fc4a73c7bab54b9fb948280f0a763673%40tno.nl.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/1B4A305C-6430-4785-9740-EF969CC97F70%40topquadrant.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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/AM4PR0301MB21314B2B7A311FBC5BC37797E94E0%40AM4PR0301MB2131.eurprd03.prod.outlook.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/AM4PR0301MB21314B2B7A311FBC5BC37797E94E0%40AM4PR0301MB2131.eurprd03.prod.outlook.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 other’s 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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/24542A98-61A0-4655-8F8D-F90273237126%40topquadrant.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
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/BC5A0ABB-B03F-4421-9264-1B64422D746F%40topquadrant.com.
I have the feeling we are not understanding each other.
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 other’s 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 skosNot 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>
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/e1ff7c8843424e0d96d6d3b6fa5e18ce%40tno.nl.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/24542A98-61A0-4655-8F8D-F90273237126%40topquadrant.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 other’s 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>
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/e1ff7c8843424e0d96d6d3b6fa5e18ce%40tno.nl.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/3a4b92159747497e8d6f810bce86c3b7%40tno.nl.
<ALT-ComplexPropertyPatterns.docx>
Hi David
Too easy....
But ok, over and out.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/85E9D502-9B28-4DE3-8E83-47EE05C62D93%40topquadrant.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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CDE0638B-DA1D-4572-8FD8-ACA8F78A0FCD%40topquadrant.com.
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
--
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/5d98489d-89dc-47f8-9c37-c072774a4d5d%40googlegroups.com.