Hi Irene, yes, the application that I am trying to build is related to product design, i.e. "product design specification" vs. "configured product in real world". Your explanation as well as the Audi example helped me a lot to reflect to the domain I am dealing with and now I believe I have a better understanding about the semantics of this type. Thanks a lot.
Best regards, Kai Irene Polikoff schrieb am Dienstag, 2. November 2021 um 16:46:25 UTC+1: > 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 <tjro...@gmail.com> 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 <tjro...@gmail.com> 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 topbraid-user...@googlegroups.com. >> 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 topbraid-user...@googlegroups.com. > > 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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c1046d6d-b30f-4e9f-aa01-d33a91ce68f2n%40googlegroups.com.
