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 > <[email protected]> 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 > > T +31888663107 > M +31630381220 > E [email protected] > Location > > > <image001.gif> > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use it > and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages. > > > > > Van: [email protected] <[email protected]> Namens > dprice > Verzonden: Thursday, November 21, 2019 2:44 PM > Aan: [email protected] > 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> > > > > > 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 > > > > On 21 Nov 2019, at 13:17, Jan Voskuil <[email protected]> wrote: > > 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 > > > From: [email protected] <[email protected]> On > Behalf Of dprice > Sent: 21 November 2019 13:45 > To: [email protected] > Subject: Re: [topbraid-users] Re: combining owl and skos > > 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 > > > > > On 21 Nov 2019, at 11:33, Jan Voskuil <[email protected]> wrote: > > 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 ; > . > > From: [email protected] <[email protected]> On > Behalf Of dprice > Sent: 21 November 2019 12:21 > To: [email protected] > Subject: Re: [topbraid-users] Re: combining owl and skos > > Hi Jan, > > I did what you said and Composer 6.3 Beta shows me the property and lets me > set the value: > > <image001.png> > > 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 > > > > > On 21 Nov 2019, at 08:51, Jan Voskuil <[email protected]> wrote: > > 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. > > > > > On Thursday, November 21, 2019 at 9:03:08 AM UTC+1, Bohms, H.M. (Michel) > 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 > > T +31888663107 > M +31630381220 > E [email protected] > 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: [email protected] <[email protected]> Namens Irene > Polikoff > Verzonden: Thursday, November 21, 2019 1:25 AM > Aan: [email protected] > Onderwerp: Re: [topbraid-users] Re: combining owl and skos > > 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. > > > On Nov 20, 2019, at 8:23 AM, dprice <[email protected]> wrote: > > 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 > > > On 20 Nov 2019, at 12:35, Irene Polikoff <[email protected]> wrote: > > I would think rdfs:Class, not owl:Class. > > > > On Nov 20, 2019, at 4:48 AM, dprice <[email protected]> wrote: > > Everything that is the rdfs:range of rdf:type is by-definition an owl:Class. > > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/141FBB70-87C7-4838-8187-7355B2559387%40topquadrant.com. > > UK +44 (0) 7788 561308 > US +1 (336) 283-0808 > > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/81C29C1A-50BD-4AFA-A7EF-8C85428056A4%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/761611f4-fc56-435f-8bdc-3421e24a0acd%40googlegroups.com. > > UK +44 (0) 7788 561308 > US +1 (336) 283-0808 > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/F0763C1F-8664-437C-9121-6328922872EA%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/AM4PR0301MB2131985419CF4448D71F7947E94E0%40AM4PR0301MB2131.eurprd03.prod.outlook.com. > > UK +44 (0) 7788 561308 > US +1 (336) 283-0808 > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/1B4A305C-6430-4785-9740-EF969CC97F70%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/AM4PR0301MB21314B2B7A311FBC5BC37797E94E0%40AM4PR0301MB2131.eurprd03.prod.outlook.com. > > UK +44 (0) 7788 561308 > US +1 (336) 283-0808 > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/24542A98-61A0-4655-8F8D-F90273237126%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/e1ff7c8843424e0d96d6d3b6fa5e18ce%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CDE0638B-DA1D-4572-8FD8-ACA8F78A0FCD%40topquadrant.com.
