Relations between Descriptive Information Content Entities and the entities involved in the prescribed processes #399
Replies: 10 comments
-
Which two types of participation do you need to represent?
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.
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:
|
Beta Was this translation helpful? Give feedback.
-
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: 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)). |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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) . |
Beta Was this translation helpful? Give feedback.
-
Mark and Ron, thanks for the clarification. It is very helpful. |
Beta Was this translation helpful? Give feedback.
-
As a further case, see discussion of File Formats that prescribe Software Files here: #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. |
Beta Was this translation helpful? Give feedback.
-
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 It seems to me that I can either prescribe the Person, the Role, or the Stasis. Directive ICE i mro:prescribes Person p 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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Thanks,
Beta Was this translation helpful? Give feedback.
All reactions