role_and_domain not helpful?

[Peter.denno]

Hi,

I might reasonably define a "test package" as a "specification" used in "testing."

Part4: specification = "a definition of one or more aspects of one or more physical objects or activities"
Part4: "testing" = "Validating that a physical object satisfies specified criteria; typically by verification of a property value of the physical object"

In defining the test package in Part2 machinery I suppose I would use class_of_participation:

ENTITY class_of_participation
SUBTYPE OF (class_of_composition_of_individual);
SELF\class_of_composition_of_individual.class_of_part : participating_role_and_domain;
SELF\class_of_composition_of_individual.class_of_whole : class_of_activity;
END_ENTITY; -- class_of_participation

The trouble is that nothing in Part 4 is a role_and_domain, much less a participating_role_and_domain. Things like specification are classes (class_of_abstract_object). Though there is a nice philosophical observation there -- recognizing that one use of a class is a to specify a role -- I wonder what use that observation has in information modelling, where pretty much the only use of a class is to specify a role. So what is the value of role_and_domain?

- Peter

[HansTeijgeler]

Hi Peter,

A test package is "involved by reference" because it does not physically participate in the testing activity, it is referred to.

Following Parts 7 and 8 we represent that information with a template. The one that should be used here can be found at http://www.15926.org/templatespecs/CL-ACTIV-03.xml.

You are right, there isn't any instance of RoleAndDomain or ParticipatingRoleAndDomain in the RDL yet. The need for them will result from the usage of the templates. Since these templates are in the process of validation and MMT approval, there is no usage yet, other that in pilot projects.

As you can see from the template specification, that RoleAndDomain will not end up in the RDL, because we define the Role and the Domain explicitly.

Regards,
Hans

[Peter.denno]

Hi Hans,

> You are right, there isn't any instance of RoleAndDomain or ParticipatingRoleAndDomain in the RDL yet. The need for them will result from the usage of the templates. Since these templates are in the process of validation and MMT approval, there is no usage yet, other that in pilot projects.

> As you can see from the template specification, that RoleAndDomain will not end up in the RDL, because we define the Role and the Domain explicitly.

I'm not sure I follow. Using that template I can assert something about a particular test package, say "tp-123 is involved by reference in an activity 'testing of system-123' in the role of 'test package'" But where do I have the opportunity to say that a "test package" (RDL object) is a "specification" (RDL object) involved in "testing" (RDL object). That's an axiom I think is worth having (in the RDL); it helps define "test package."

Some other minor questions. Expanding the template using the example asserts:

ClassOfActivity("Welding of Line RZ17801")
ClassOfActivity("to be generated")
Specialization("to be generated" "Welding of Line RZ17801") -- I see this in the diagram, not the logic.
Class("API Standard 1104")
Role("Applicable Standard")
RoleAndDomain(<skolem-for-r&d>)
exists ?y (SpecializationByDomain(?y)
hasSubclass(?y <skolem-for-r&d>)
hasSuperclass(?y "API Standard 1104"))
exists ?z (SpecializationByRole(?z)
hasSubclass(?z <skolem-for-r&d>)
hasSuperclass(?z "Applicable Standard"))
exists ?x3 (ClassOfInvolvementByReference(?x3)
hasClassOfInvolved(?x3 <skolem-for-r&d>)
hasClassofInvolver(?x3 "to be generated"))

- What is the purpose of "to be generated" ?
- The diagram suggests Specialization("to be generated" "Welding of Line RZ17801") but I don't see it in the logic. Is that a bug?

Best regards,
Peter

[HansTeijgeler]

Hi Peter,

Let me take your listing and apply that for your test package:

ClassOfActivity("Testing")
ClassOfActivity("to be generated") (see below)
Specialization("to be generated" "Welding of Line RZ17801") -- I see this in the diagram, not the logic. (see below)
Class("Test Package")
Role("Instruction")
RoleAndDomain(<skolem-for-r&d>)
exists ?y (SpecializationByDomain(?y)
hasSubclass(?y <skolem-for-r&d>)
hasSuperclass(?y "Test Package"))
exists ?z (SpecializationByRole(?z)
hasSubclass(?z <skolem-for-r&d>)
hasSuperclass(?z "Instruction"))
exists ?x3 (ClassOfInvolvementByReference(?x3)
hasClassOfInvolved(?x3 <skolem-for-r&d>)
hasClassofInvolver(?x3 "to be generated"))

You forgot the Cardinalities.

About the "to be generated"
In many templates you will find the remark "ID to be generated automatically".
First please read http://15926.org/publications/general-d ... /index.htm
The subclass of the UrClass cannot be found in any application data base. You will find the ID of the UrClass (e.g. P-101). So when you map your data you list the ID of the UrClass plus a randomly generated ID for the subclass. The latter ID is required for collecting it in an EnumeratedSetOfClass (an OIM).
You will find a similar approach with temporal parts. There the ID of the temporal part is required to be able to terminate the validity of the information in which that temporal part plays a role.

Finally a response to your question about the way a concept like Test Package is represented in the RDL.
So far the RDL is, for the most, still a taxonomy/dictionary, where the definitions are given in a natural language. That is fine for now, but in due course, when the necessary templates have been approved, those definitions will be translated to Part7/8 template instances, thereby doing exactly what you described.

Regards,
Hans

[Peter.denno]

Hi Hans,

Thanks for the explanation and pointer to the discussion of ur-Class.
There is one last point that concerns me.

You said "A test package is 'involved by reference' because it does not physically participate in the testing activity, it is referred to."

I didn't use involvement by reference because I wanted to cover the possibility that the test package is updated in testing. But even that does not seem necessary to justify "participation." At the very least, the test package is directing the course of testing. Similarly, (1) see the "cup machine" "participation" in the cup forming process of figure 54 of Part 2. -- the machine is "directing" the process (2) see "type 167 instrument" participating in an activity in figure 150.

From P2: EXAMPLE A conversation that refers to the Roman Empire is an activity that relates to the Roman Empire by an involvement_by_reference. -- That doesn't sound like what I intended.

Some ontologies (e.g. SUMO) make a distinction between objects that are not changed in an activity and those that are. And they have axioms backing up the definitions (not shown below).

(disjointRelation resource result instrument)

resource = "(&%resource ?PROCESS ?RESOURCE) means that ?RESOURCE is present at the beginning of ?PROCESS, is used by ?PROCESS, and as a consequence is changed by ?PROCESS.

result = "(result ?PROCESS ?OUTPUT) means that ?OUTPUT is a product of ?PROCESS. For example, house is a &%result in the following proposition: Eric built a house.")

instrument = "(instrument ?PROCESS ?TOOL) means that ?TOOL is used by an agent in bringing about ?PROCESS and that ?TOOL is not changed by ?PROCESS.

Absent some axioms about involvement, I think it is debatable whether "involvement by reference" or "participation" should be used -- and ultimately the interpretation will be ambiguous. Are there plans to write axioms for part 2 classes and relations themselves? I think there is a similar lack of guidance (and I suppose inconsistent usage) of indirect_property and probably others.

Best regards,
Peter

[HansTeijgeler]

Hi Peter,

Similarly, (1) see the "cup machine" "participation" in the cup forming process of figure 54 of Part 2.

[HT] The cup machine is physically involved.

see "type 167 instrument" participating in an activity in figure 150.

[HT] The instrument is physically involved as well.

Some ontologies (e.g. SUMO) make a distinction between objects ......

[HT] I guess so, but we aren't dealing with SUMO.

Absent some axioms about involvement, I think it is debatable whether "involvement by reference" or "participation" should be used -- and ultimately the interpretation will be ambiguous.

[HT]If you want to use 15926 you'll have to

Are there plans to write axioms for part 2 classes and relations themselves?

[HT] Not that I know of. Could you give a narrative description of such an axiom?

I think there is a similar lack of guidance (and I suppose inconsistent usage) of indirect_property

[HT] The difference between Property and IndirectProperty is indeed unclear to some, but that may be caused by not reading Part 2 carefully. A simple way to find out is to ask yourself the question whether the property can be physically measured. In case of doubt consult the RDL (although at present there may be a few glitches there).

To return to the starting point of this thread, the 15926 model is far more expressive than SUMO of IDEF or any other methodology, because of the (Participating)RoleAndDomain that allows you to define, for each thing that it involved-by-reference or participating what it role in the activity is.

Regards,
Hans

[Peter.denno]

Hi Hans,

[HT] The difference between Property and IndirectProperty is indeed unclear to some, but that may be caused by not reading Part 2 carefully.

Well, I don't think that the problem in my case. Here's what Part 2 says:

4.5.4.3.3 Indirect Property
"In this part of ISO 15926, indirect_property shall be used when simple classification by a property is not possible. This arises when the property is derived or deemed from the properties of the possible_individual or from properties of particular parts of the possible_individual ."

5.2.26.3 indirect_property
"A property is indirect when it does not apply directly to the possible_individual to which it applies, but is derived from some process.

NOTE A property is indirect because it does not directly apply. There can only be one temperature that a thing has (at a time), so a Maximum Allowable Working Temperature is not its temperature, but an indirect property derived from doing some tests or calculations to determine its value (as opposed to it being a current measurement). This is what makes it indirect."

Twice above it says essentially that "indirect" means "not direct." I always suspected that.

Regarding "derived or deemed from the properties" I wonder in the context of F=ma, if I know any two of F,m and a, don't I know the third? So which is derived?

I don't find your suggestion ("whether the property can be physically measured") to be very satisfying either. Doesn't that depend on circumstances? Technology? Nonetheless, I think I know what you are after. "Maximum Allowable Working Temperature" describes a property of a design; a design is an abstraction; abstractions do not have temperatures. Now the problem I'm having with 15926 is that indirect_property.possessor is a possible_individual not an abstract_object. Were the range of the property abstract_object (abstract_object suitably defined*), application of indirect_property would be more straightforward and we could rely on automated tools to validate well-formedness. With that thought, I'll respond to your other question, about example axioms that might serve to define part 2 entities: One could say (borrowing from SUMO) that a thing is an abstract_object iff "it has neither a spatial nor temporal location." But how one says in 15926 that something has a location in time or space isn't obvious to me.

* Footnote on "suitably defined": Paraphrasing SUMO again, "encodings" of instances of abstract objects can be said to exist in a time or place. An example "encoding" is a CAD file.