CommonCoreOntologies icon indicating copy to clipboard operation
CommonCoreOntologies copied to clipboard

Relations between Descriptive Information Content Entities and the entities involved in the prescribed processes

Open aellenhicks opened this issue 6 years ago • 10 comments

When a Directive Information Content Entities prescribes a process, there are many ways in which Continuants can be participants in those processes, and we would like at least two distinct ways of representing different types of participation in the would-be processes.

For example, it's clear from the examples on prescribes that a blue prints can prescribe a building. The more far-reaching plan to build something can include the blue print, the building, and a specific construction company. However, only the building is the output or objective of that plan.

I read the definition of prescribes (below) to mean that if a DICE prescribes an Continuant, then the DICE is a model for a Continuant of that type. So the blue print prescribes the building by virtue of being a model for the building. The plan to build something does not prescribe the construction company since it is not a model for a Construction Company. Instead it specifies that a construction company should participate in the prescribed process in a manner that is more like use than modeling.

However, it has been brought to my attention, that this may not be the intended reading of the definition of prescribes.

prescribes: For all types T1 and T2, if T1 prescribes T2, then there is some instance of T1, t1, that serves as a rule or guide to some instance of T2, t2 (if T2 is a type of bfo:Occurrent) or that serves as a model for some instance of T2, t2 (if T2 is a type of bfo:Continuant).

My question is two-fold:

  1. If a DICE prescribes a Continuant, is that limited to cases where the DICE models the continuant?
  2. How does CCO handle the distinction between the DICE being a model for some end product and the DICE specifying the use of some existing Continuant without it being a model for it?

Thanks,

aellenhicks avatar Dec 10 '19 21:12 aellenhicks

When a Directive Information Content Entities prescribes a process, there are many ways in which Continuants can be participants in those processes, and we would like at least two distinct ways of representing different types of participation in the would-be processes.

Which two types of participation do you need to represent?

If a DICE prescribes a Continuant, is that limited to cases where the DICE models the continuant?

That is correct. If a Directive ICE prescribes a continuant, our view is that the Directive is about a prototypical instance of that type, i.e, the thing that would exist and built to conform to the model. Another DICE is needed to represent how to achieve conformance with the model, one which prescribes the procedure to go about creating the thing as specified by the model.

But, many models of continuants include information about expected behaviors of continuants, say, how a disposition is realized, e.g, a car’s maximum speed. In this case, the graph that gets created to represent that model will need to instantiate a realizing process. The DICE in this case is about the car and its modal participation in a process wherein the speed and the fact the value associated with the speed is the maximum is represented.

How does CCO handle the distinction between the DICE being a model for some end product and the DICE specifying the use of some existing Continuant without it being a model for it?

In the first case we prescribe the continuant itself, and then build out a modal graph for representing the information associated with the specifications for that continuant. In the second case, we prescribe the process (the use) and then build out the graph to represent the specifics of that usage, what and how, who, duration, or sequence, etc.

Perhaps a simplified example would help:

directive-123 mro:prescribes artifact-123 ; cco:designated_by name-123
artifact-123 mro:has_quality weight-123
weight-123 mro:measured_by measurement-123
measurement-123 mro:has_value “200kg”
name-123 cco:has_value “my model”
directive-234 mro:prescribes process-234 ; cco:designated_by name-234
process-234 mro:has_participant artifact-234, agent-234
agent-234 cco:designated_by name-456 ; mro:uses artifact-234
artifact-234 mro:prescribed_by directive-345
directive-345 cco:designated_by name-345
name-234 cco:has_value “my plan”
name-345 cco:has_value “my model”
name-456 cco:has_value “barry”

mark-jensen avatar Dec 17 '19 17:12 mark-jensen

Hey Mark,

I’m getting a little confused between a) the characterization of cco:prescribes and b) best practice for using cco:prescribes.

From your response, the following appears to be true: If X cco:prescribes Y and Y is a continuant, then X is a model for Y.

However, if that is correct, is it also then correct that CCO provides no in-spec way to say “The instructions specify this hammer shall be used in a future process” without creating a modal graph that represents a modal process in which the hammer is modally used?

Cards on the table: I like the modal relations ontology a lot, but most of the time I don’t need that level of detail, and I don’t want to be required to use it in cases where I have a simple need to relate stuff listed in a plan to the plan itself when the plan specifies that something or other ought to participant in a process in some or another way. I would use a different relation like ‘designates’ or ‘is about’, but ‘prescribes’ is the only one with the correct mind-to-world direction of fit.

To restate: if I have a plan that says I need this hammer to create a bird house, I want to be able to only assert:

‘Plan1 cco:prescribes hammer1’

and have it be a best practice but not a requirement to also state:
‘Plan1 cco:prescribes ActofBirdCreation1; hammer1 mro:participates_in ActofBirdCreation1’ or ‘Plan1 mro:prescribes ActofBirdCreation1; hammer1 mro:participates_in ActofBirdCreation1’.

In many cases, I would take the latter statements as implied, in ellipsis, by the first, with a change to the definition that carves out a third possible meaning, such as:

where DICE(x) cco:prescribes Continuant(y) and DICE(x) is not a model for Continuant(y), then DICE(x) cco:prescribes Continuant(y) is equivalent to DICE(x) cco:prescribes Continuant(y) and DICE(w) cco:prescribes Process(z) and ((x ro:participant_in z) or (x mro:participant_in z)) and ((x =w) or (x ≠w)).

neilotte avatar Dec 19 '19 21:12 neilotte

So why not Plan1 prescribes BirdHouseCreation1. Hammer is used in BirdHouseCreation1, Nails are used in BirdHouseCreation1, PortionOfWhitePaint is used... If I was going to take a shortcut I'd prefer this than having a bunch of triples with Plan1 as the subject and the prescribed process and artifacts as objects.

rorudn avatar Dec 19 '19 21:12 rorudn

To follow up a bit on this. Recall that the purpose of the CCO is not to provide a data model for a particular application but rather to enable integration of data across a large number of applications. That purpose is not well served by making changes to the CCO based upon pragmatic needs such as the one you describe. There is of course nothing wrong with taking a short cut for your particular needs and if interoperability is still a requirement just have an expansion process that can take you from your data model shortcut to the full model provided by the CCO.

rorudn avatar Dec 19 '19 22:12 rorudn

Hey Ron (thanks for jumping in here and happy holidays). To your first comment, I think that works in cases where I'm ingesting data about processes that have occurred, but not the case where the processes have not. The objection is to the requirement to use MRO in cases of planned future action to relate plans to continuants using cco:prescribes.

(As an aside: MRO is not presently imported by allcore, so if it really is required in order to use cco:prescribes for future tasks, shouldn't this be noted somewhere? None of the examples or definition in the files addresses this, and it isn't in any of the CCO documentation.)

Regarding 'That purpose is not well served by making changes to the CCO based upon pragmatic needs such as the one you describe.' --well, I'm aware CCO is a mid-level ontology and wouldn't make this request unless I thought my pragmatic need was a general one that other users will have, particularly those that are altogether wary of using MRO. Also, CCO has made other pragmatic choices (is__text_value vs. is_tokenized_by, for instance) so it's not like such decisions are totally out of bounds.

neilotte avatar Dec 20 '19 14:12 neilotte

Hi Mark, Neil, and Ron. And thanks for the good discussion on this.

Mark, thanks for the nice and clear example. My only questions is when does one use cco:prescribes and when does one use mro:prescribes?

Neil, I do not think the participation relation alone is strong enough to make the distinction that we need here. If I build a house, the house participates in the building process as do I, my hammer, etc.

Also, I'm not sure why we would need to include 'and ((x =w) or (x ≠w))' in the formalization since ((x =w) or (x ≠w)) is a tautology.

I will be on vacation until January 5th, so will follow up again when I return.

aellenhicks avatar Dec 20 '19 15:12 aellenhicks

By including '((x =w) or (x ≠w))', my intention was to convey that the DICE that prescribes the process and the DICE that prescribes the continuant that participates in the process may or may not be the same. I admit this could have been put more clearly.

As to the concern about the participation relation--agreed. When we want to be very specific about the contents of plans, the use of the MRO outlined by Mark above would be one way. I'm concerned here about when we (and presumably others) don't need to be that specific (and don't want to represent modal processes) .

neilotte avatar Dec 20 '19 20:12 neilotte

Mark and Ron, thanks for the clarification. It is very helpful.

aellenhicks-jhuapl avatar Feb 04 '20 15:02 aellenhicks-jhuapl

As a further case, see discussion of File Formats that prescribe Software Files here: https://github.com/CommonCoreOntology/CommonCoreOntologies/issues/29

The takeaway was that only if one wanted or needed to explicitly represent the process of implementing the format for a software file was it necessary to do so. Otherwise, could just say the file format prescribes the software file instance. I don't know if this takeaway is contradicted by anything said here.

neilotte avatar Feb 26 '20 20:02 neilotte

Are there any more strategies to decide which entity in a graph is the best target for a prescribes relation?

Take this example of a graph that I want a Directive ICE to prescribe:

Person p mro:has_role Role r Role r mro:role_of Person p Person p mro:participates_in Stasis s Stasis s mro:has_participant Person p Role r mro:participates_in Stasis s Stasis s mro:has_participant Role r

It seems to me that I can either prescribe the Person, the Role, or the Stasis.

Directive ICE i mro:prescribes Person p Directive ICE i mro:prescribes Role r Directive ICE i mro:prescribes Stasis s

None of the three seems to me at first sight to be more the target of a model than the others.

My (probably incomplete) understanding of prescribes would also allow i to mro:prescribe two of the entities or all three.

nklsbckmnn avatar Apr 18 '21 17:04 nklsbckmnn