Hi Kai, This is a complex topic and I do not have enough context of your use case. Conceptually, there is a difference between the "design specification" and the real thing that is based on the design specification. I believe this is what you are trying to do. Let me try to explain this through examples:
1. There is a design for a model of a car e.g., Audi Q4. This design was created at some point in time by some group of designers and engineers. There was a date on which the first car based on the spec was manufactured. There are some factories that can build cars of this model. The model (design spec) has certain characteristics and parameters e.g., the type of transmission, how quickly it accelerates, after how many miles it needs to be serviced. Then, there are actual cars built based on this design. Each car, besides the parameters based on the design spec, has its own, more unique parameters e.g., the date it was manufactured, when it was last serviced, how many miles are on its odometer. These cars are not the instances of the design, they are more like occurrences of it in the world. The set they belong to - the set of all manufactured Audi A4 cars. Some of the properties of the design spec are not “transferred” to the instances e.g., the team that designed the model had no direct involvement with the individual car you may drive, the date when manufacturing started is different from the date when your car was manufactured, etc. 2. There is a concept of a disease such as, let’s say, chicken Pox. It has properties e.g., the average duration, suggested treatments, when it was first discovered and, possibly, by whom, etc. Then, there are occurrences of this disease in actual people. They will not have the average duration. Instead, they will have the actual duration. And there will be other properties e.g, who is the patient, who is his doctor, etc. With this, again, one could think of a class disease and a taxonomy of disease specifications where Chicken Pox is an instance with its characteristics and, in parallel, classes for disease occurrences e.g., all occurrences of the actual chicken pox illnesses in the world. With this, I do not think there is an issue of weak semantics. Strictly speaking, semantics would be correct. The rdf:type relationship does not convey the exactly correct semantics in this case. You would need to pick the values from the “design spec” instance that are inherited by default by the occurrence of the spec. Because, as explained above, generally, not all values are. Having said all of this, every modeling pattern has its own implications which can be positive and negative. Hope this helps, Irene > On Nov 2, 2021, at 4:30 AM, Kai Liu <[email protected]> wrote: > > Hi Irene, > > thanks for the suggestion. I tried to create a class "RealParameter" to > represent the Quantity with property values and then created an instance > called "SPR000-srate" in the ontology. Afterwards, I changed the srate > property shape from attribute to relationship and set the default value to > the "SPR000-srate". > > In the data graph, I created a new instance "new_srate" of "RealParameter" > and assigned different values to title, unit and value fields. By default, it > takes the value "SPR000-srate", but I was able to swtich the value to > "new_srate". I see several drawbacks, however: > > 1) In the ontology, I would end up with creating thousands of "RealParameter" > instances. In my domain, I have to model several thousands such classes to > represent a modeling library, and some classes have up to 20 parameters. > 2) I can only override the value by switching the whole object. It is not > possible to only override for example unit and take the value from the > default title. I have to copy the title value from the default instance to > the new instance even if it is not changed at all. > > This is how it looks like with this approach: > > <srate-default-par.png> > > I was thinking of modelling these classes as taxonomy after I saw your > teaching video about taxonomy. However, my current business problem is > creating instances of these classes and override values. If these > classes/parameters would be all concepts, I would need to create some custom > relationship (e.g. conformsTo) between them and their instances, since both > are individuals from RDF ponit of view. The semantics would be very weak. How > about your opinion? > > Best regards, Kai > > Irene Polikoff schrieb am Dienstag, 2. November 2021 um 01:01:49 UTC+1: > Yes, reification would let you cut the number of property shapes to just 22: > 20 for the different properties that will hold values of your > quantities/measurements plus the two for the title and the unit of measure. > > However, you would not be able to specify a default value as you would only > have a single property shape for the unit of measure property. > > Another option is to have a class Quantity with properties value, unit of > measure and title. Then, properties like srate become relationships and you > would be creating new instances for each quantity. I think you should then be > able to specify a default value for the srate/unit sequential path, but, > without trying this out, I am not sure how practical this would be I.e., how > well it would work in the EDG UI. > > >> On Nov 1, 2021, at 7:34 PM, Kai Liu <[email protected] >> <applewebdata://70EB2C6F-14C9-4412-B778-68E55D7E0792>> wrote: >> >> In EDG, I have a class "Spring", on which a parameter "srate" of type float >> should be defined. It has a default value. In addition, this parameter >> should also carry some metadata, e.g. a default title "spring rate", a >> default unit "N/m". The instances of this class can then override these >> default values. > >> >> Currenlty, I defined for each of these metadata a separate attribute: >> "srate.title" of type string, "srate.unit" of type string and specified >> default values for them. I am wondering whether there is a modeling pattern >> to better cope with this problem, since I have classes with 20 parameters, >> and for which I need to define 60 attributes. Moreover, there are no >> semantic relationship between srate, srate.title and srate.unit. They are >> related just with the naming convention. >> > >> I tried to use Reification (statements about statements) to model this, but >> I was not able to set the default values for the title and unit in the >> ontology. >> >> Thanks. >> > >> Kai >> >> A screenshot of the property (attribute) definition: >> > >> <srate.png> >> >> >> The configuration of this parameter in the instance: >> > >> <srate-instance.png> >> >> >> >> >> >> -- >> 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] >> <applewebdata://70EB2C6F-14C9-4412-B778-68E55D7E0792>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/972303f0-d963-41a9-9acc-5ef45193be59n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/972303f0-d963-41a9-9acc-5ef45193be59n%40googlegroups.com?utm_medium=email&utm_source=footer>. >> <srate.png> >> <srate-instance.png> > > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/2925ec83-395a-400e-b126-348646eb791an%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/2925ec83-395a-400e-b126-348646eb791an%40googlegroups.com?utm_medium=email&utm_source=footer>. > <srate-default-par.png> -- 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/07FCD78C-345F-4BFF-8EEA-EA1611BA6720%40topquadrant.com.
