Modelling Property Ranges in Part7 and Part8
-
- Posts: 13
- Joined: Thu Mar 08, 2012 8:37 am
- Location: Haarlem, the Netherlands
Re: Modelling Property Ranges in Part7 and Part8
Hans,
Could you please elaborate on "The link between the design and the individual is via this hasDefined subtype of ClassOfRelationship (also with connection, assembly, etc)."? As it's not obvious to me as well why you need that separate role (perhaps it is already obvious to Victor after your reply ).
Why cannot it be skolemized? Do not see a reason to declare it explicitly as you can easily restore the appropriate diagram without it if you have the other roles.
Could you please elaborate on "The link between the design and the individual is via this hasDefined subtype of ClassOfRelationship (also with connection, assembly, etc)."? As it's not obvious to me as well why you need that separate role (perhaps it is already obvious to Victor after your reply ).
Why cannot it be skolemized? Do not see a reason to declare it explicitly as you can easily restore the appropriate diagram without it if you have the other roles.
-
- Posts: 283
- Joined: Sun Jan 22, 2012 10:02 pm
Re: Modelling Property Ranges in Part7 and Part8
Hi Mike,
Re First Posting
Re Second Posting
Regards,
Hans
Re First Posting
[HT] If you make it explicit you still have the choice to launch a direct query or to use theorem provers and other sophisticated stuff to dig up that object. The KISS principle, so to say . By the way, the ID for the hasDefined can be generated automatically, so it does not add a burden to the mapping.Could you please elaborate on "The link between the design and the individual is via this hasDefined subtype of ClassOfRelationship (also with connection, assembly, etc)."? As it's not obvious to me as well why you need that separate role (perhaps it is already obvious to Victor after your reply).
Why cannot it be skolemized? Do not see a reason to declare it explicitly as you can easily restore the appropriate diagram without it if you have the other roles.
Re Second Posting
[HT] In Part 2 I read: "A <temporal_bounding> is an <assembly_of_individual> that indicates that the part <event> is a temporal boundary of the whole <possible_individual>.". The point in time is a subtype of event.On the first diagram I believe you need to change the role of PointInTime to whole instead of part. Doesn't make sense otherwise.
[HT] See response on your first posting. By the way, the ID for the temporal part can also be generated automatically, so it does not add a burden to the mapping.Also, assuming that at a particular point in time you only have one temporal part of possible individual (or is it not the case?) - do you actually need a separate hasPossessor role? Can you not unambiguously deduce the appropriate individual if you have hasTemporalWhole and the time stamp?
Regards,
Hans
Re: Modelling Property Ranges in Part7 and Part8
No, the need for a hasDefined role is not yet clear for me.
All the temporal issues (arising from the need to enhance the model during the design time) can be resolved through ur-class specialization indeed. However the relationship (CoR) which signifies the kind of indirect property in question doesn't change. As we don't use universal or existential restrictions on the sides of the hasIndirectPropertyType, we can add all all the tuples to the same class. We are interested in only one aspect - whether it is DESIGN PRESSURE or MAXIMUM ALLOWED PRESSURE indirect property. We don't need subclasses of relationship to separate property ranges or ur-class subclasses.
There is no logical contradiction to hide this subclass in the axiom, as Mikhail had suggested. But I can not see any ontological reason to do it. As I've tried to explain, I can not identify in any legacy tool data model known to me two separate values which can be mapped to these two template roles. With such role in the signature the template is just unusable for my cases - I don't have data to instantiate two roles.
All the temporal issues (arising from the need to enhance the model during the design time) can be resolved through ur-class specialization indeed. However the relationship (CoR) which signifies the kind of indirect property in question doesn't change. As we don't use universal or existential restrictions on the sides of the hasIndirectPropertyType, we can add all all the tuples to the same class. We are interested in only one aspect - whether it is DESIGN PRESSURE or MAXIMUM ALLOWED PRESSURE indirect property. We don't need subclasses of relationship to separate property ranges or ur-class subclasses.
There is no logical contradiction to hide this subclass in the axiom, as Mikhail had suggested. But I can not see any ontological reason to do it. As I've tried to explain, I can not identify in any legacy tool data model known to me two separate values which can be mapped to these two template roles. With such role in the signature the template is just unusable for my cases - I don't have data to instantiate two roles.
-
- Posts: 283
- Joined: Sun Jan 22, 2012 10:02 pm
Re: Modelling Property Ranges in Part7 and Part8
Hi Victor,
Tell me how you terminate a temporal part.
So, for instance, you have a temporal part with a temperature of 70 degrees C, and now the next temporal part with 75.
You need to end the 70C one.
Unless you have automatically generated its ID you have to do some esoteric stuff to generate an ID on the fly when you want to end it.
So please enlighten me.
Regards,
Hans
Tell me how you terminate a temporal part.
So, for instance, you have a temporal part with a temperature of 70 degrees C, and now the next temporal part with 75.
You need to end the 70C one.
Unless you have automatically generated its ID you have to do some esoteric stuff to generate an ID on the fly when you want to end it.
So please enlighten me.
Regards,
Hans
-
- Posts: 283
- Joined: Sun Jan 22, 2012 10:02 pm
Re: Modelling Property Ranges in Part7 and Part8
Hi Victor,
One instance of ClassOfIndirectProperty that relates the whole world seems a bit confusing to me.
We put on record that V-101 has a design pressure of 100 barg, that V-102 has a maximum allowable working pressure of 120 barg, etc Each of the two instances of ClassOfIndirectProperty carries its own information. Would it be the same instance in both cases, your software may conclude that V-101 has a maximum allowable working pressure of 120 barg.
Regards,
Hans
[HT] OK, I forgot to classify the Specialization relationship with a End1UniversalRestriction and End2UniversalRestriction. See Figure 23 of Part 7.All the temporal issues (arising from the need to enhance the model during the design time) can be resolved through ur-class specialization indeed. However the relationship (CoR) which signifies the kind of indirect property in question doesn't change. As we don't use universal or existential restrictions on the sides of the hasIndirectPropertyType, we can add all all the tuples to the same class. We are interested in only one aspect - whether it is DESIGN PRESSURE or MAXIMUM ALLOWED PRESSURE indirect property. We don't need subclasses of relationship to separate property ranges or ur-class subclasses.
One instance of ClassOfIndirectProperty that relates the whole world seems a bit confusing to me.
We put on record that V-101 has a design pressure of 100 barg, that V-102 has a maximum allowable working pressure of 120 barg, etc Each of the two instances of ClassOfIndirectProperty carries its own information. Would it be the same instance in both cases, your software may conclude that V-101 has a maximum allowable working pressure of 120 barg.
Regards,
Hans
Re: Modelling Property Ranges in Part7 and Part8
Hans,
I'm supporting your suggestion on ur-class. But we are discussing here the question of an explicit role for a ClassOfIndirectProperty in a template signature.
We've "P-101 ur-class". We've its two specializations: "P-101 class created 01.01.2012" and "P-101 class created 02.01.2012". We've two PropertyRanges "70-14C" and "75-79C". "P-101 class created 01.01.2012" is connected to "70-14C" and "P-101 class created 02.01.2012" to "75-79C".
The class "P-101 class created 01.01.2012" is declared deprecated together with all its relationships, we don't need explicitly define all possible links to its properties for a single goal - to find them all and declare ended.
If your plans are to be able to end only some of the relationships - that's fine. You have to create each hasDefined instance explicitly. But this approach makes ur-classes unnecessary. As far as I understand - it is one global approach, or another.
I'm supporting your suggestion on ur-class. But we are discussing here the question of an explicit role for a ClassOfIndirectProperty in a template signature.
We've "P-101 ur-class". We've its two specializations: "P-101 class created 01.01.2012" and "P-101 class created 02.01.2012". We've two PropertyRanges "70-14C" and "75-79C". "P-101 class created 01.01.2012" is connected to "70-14C" and "P-101 class created 02.01.2012" to "75-79C".
The class "P-101 class created 01.01.2012" is declared deprecated together with all its relationships, we don't need explicitly define all possible links to its properties for a single goal - to find them all and declare ended.
If your plans are to be able to end only some of the relationships - that's fine. You have to create each hasDefined instance explicitly. But this approach makes ur-classes unnecessary. As far as I understand - it is one global approach, or another.
Re: Modelling Property Ranges in Part7 and Part8
Hans,
I had made too broad statement about universal restrictions, shame on me. The problem is indeed solved much simpler by skolemized entity, the only problem I see is its presence in the template signature.
I had made too broad statement about universal restrictions, shame on me. The problem is indeed solved much simpler by skolemized entity, the only problem I see is its presence in the template signature.
-
- Posts: 13
- Joined: Thu Mar 08, 2012 8:37 am
- Location: Haarlem, the Netherlands
Re: Modelling Property Ranges in Part7 and Part8
Agreed. Sorry for confusion.HansTeijgeler wrote: In Part 2 I read: "A <temporal_bounding> is an <assembly_of_individual> that indicates that the part <event> is a temporal boundary of the whole <possible_individual>.". The point in time is a subtype of event.?
But you haven't convinced me so far that you actually need those explicit roles...
-
- Posts: 283
- Joined: Sun Jan 22, 2012 10:02 pm
Re: Modelling Property Ranges in Part7 and Part8
Not so fast!
First Victor:
OK, your class P-101 has 100 templates related to it (not uncommon). Then you change one template. You deprecate that class P-101 and its 100 templates and recreate the 99 templates that were not changed. You keep doing so for thousands of classes, and you need a petabyte server, I'd guess.
But I am open for your suggestion. That is easy for me, because I am not actually implementing it. What is the opinion of the software guys?
Then Mike:
Again, I am not implementing this. If you, and the other implementers think that it is acceptable that you can only find those objects by means of OWL tools, and not with RDF tools, then I surrender. So folks, speak up!
It may also be that I completely misunderstood you, of course. Perhaps Onno can tell the story about the OWL and the frog.
First Victor:
OK, your class P-101 has 100 templates related to it (not uncommon). Then you change one template. You deprecate that class P-101 and its 100 templates and recreate the 99 templates that were not changed. You keep doing so for thousands of classes, and you need a petabyte server, I'd guess.
But I am open for your suggestion. That is easy for me, because I am not actually implementing it. What is the opinion of the software guys?
Then Mike:
Again, I am not implementing this. If you, and the other implementers think that it is acceptable that you can only find those objects by means of OWL tools, and not with RDF tools, then I surrender. So folks, speak up!
It may also be that I completely misunderstood you, of course. Perhaps Onno can tell the story about the OWL and the frog.
Re: Modelling Property Ranges in Part7 and Part8
Hans,
Template statements are as eternal as all other items in 15926 world. You can deprecate an identified relationship if available, or you can deprecate template instance, but the only ontologically true solution is an ur-class. Which has the problem you just described.
Template statements are as eternal as all other items in 15926 world. You can deprecate an identified relationship if available, or you can deprecate template instance, but the only ontologically true solution is an ur-class. Which has the problem you just described.